Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

2017-04-24 11:10+0100, Suzuki K Poulose: > The KVM uses mmu_notifier (wherever available) to keep track > of the changes to the mm of the guest. The guest shadow page > tables are released when the VM exits via mmu_notifier->ops.release(). > There is a rare chance that the mmu_notifier->release

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On Tue, Apr 25, 2017 at 11:41:39AM -0600, Baicar, Tyler wrote: > I originally had this as a notifier, but Will requested to remove the > notifier. That conversation is here: https://lkml.org/lkml/2017/1/18/1018 Yeah, he mentioned on IRC. I just think notifiers would be the cleaner thing but

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On 4/25/2017 11:21 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be

[PATCH 2/2] KVM: arm64: Restore host physical timer access on hyp_panic()

When KVM panics, it hurridly restores the host context and parachutes into the host's panic() code. At some point panic() touches the physical timer/counter. Unless we are an arm64 system with VHE, this traps back to EL2. If we're lucky, we panic again. Add a __timer_save_state() call to KVMs

[PATCH 0/2] KVM: arm/arm64: Restore host physical timer access on panic

Hi! On arm64, with a single CPU when I trigger hyp_panic() with the guest registers loaded, I get two traces: [ 8736.164022] Kernel panic - not syncing: HYP panic: [ 8736.164022] PS:62c9 PC:80a841e8 ESR:9646 [ 8736.164022] FAR:0880 HPFAR:00800800

[PATCH 1/2] KVM: arm: Restore banked registers and physical timer access on hyp_panic()

When KVM panics, it hurridly restores the host context and parachutes into the host's panic() code. This looks like it was copied from arm64, the 32bit KVM panic code needs to restore the host's banked registers too. At some point panic() touches the physical timer/counter, this will trap back to

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote: > That seems like something that should be done outside of these patches (if > added to the kernel at all). The decoding for this information would all be > vendor specific, so I'm not sure if we want to pollute the EFI code with >

[kvmtool PATCH v10 13/15] arm: setup SPI IRQ routing tables

Since we soon start using GSI routing on ARM platforms too, we have to setup the initial SPI routing table. Before the first call to KVM_SET_GSI_ROUTING, the kernel holds this table internally, but this is overwritten with the ioctl, so we have to explicitly set it up here. The routing is actually

[kvmtool PATCH v10 14/15] extend GSI IRQ routing to take a device ID

For ITS emulation we need the device ID along with the MSI payload and doorbell address to identify an MSI, so we need to put it in the GSI IRQ routing table too. There is a per-VM capability by which the kernel signals the need for a device ID, so check this and put the device ID into the routing

[kvmtool PATCH v10 03/15] irq: move IRQ routing into irq.c

The current IRQ routing code in x86/irq.c is mostly implementing a generic KVM interface which other architectures may use too. Move the code to set up an MSI route into the generic irq.c file and guard it with the KVM_CAP_IRQ_ROUTING capability to return an error if the kernel does not support

[kvmtool PATCH v10 04/15] MSI-X: update GSI routing after changed MSI-X configuration

When we set up GSI routing to map MSIs to KVM's GSI numbers, we write the current device's MSI setup into the kernel routing table. However the device driver in the guest can use PCI configuration space accesses to change the MSI configuration (address and/or payload data). Whenever this happens

[kvmtool PATCH v10 15/15] arm64: enable GICv3-ITS emulation

With everything in place for the ITS emulation add a new option to the --irqchip parameter to allow the user to specify --irqchip=gicv3-its to enable the ITS emulation. This will trigger creating the FDT node and an ITS register frame to tell the kernel we want ITS emulation in the guest.

[kvmtool PATCH v10 06/15] PCI: Only allocate IRQ routing entry when available

If we need to inject an MSI into the guest, we rely at the moment on a working GSI MSI routing functionality. However we can get away without IRQ routing, if the host supports MSI injection via the KVM_SIGNAL_MSI ioctl. So we try the GSI routing first, but if that fails due to a missing IRQ

[kvmtool PATCH v10 01/15] FDT: use static phandles

The current implementation of fdt__alloc_phandle() suffers from being implemented in a static inline function situated in a header file. This will only create expected results within a single compilation unit. It seems a bit over the top to use a function to allocate phandles, when at the end of

[kvmtool PATCH v10 00/15] kvmtool: arm: ITS emulation and GSI routing support

Hi, another update to the ITS emulation series for kvmtool. This addresses the comments Marc and Jean-Philippe had on the last version (thanks for that!): I moved the DevID feature detection to avoid static variables, rewrote the error path on creating IRQ routes and extended the MMIO reservation

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On 25/04/2017 15:22, Marc Zyngier wrote: > On 25/04/17 13:51, Daniel Lezcano wrote: >> On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote: >>> On 25/04/17 10:49, Daniel Lezcano wrote: On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote: >>> >>> [...] >>> >> +static

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On 25/04/17 13:51, Daniel Lezcano wrote: > On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote: >> On 25/04/17 10:49, Daniel Lezcano wrote: >>> On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote: >> >> [...] >> > +static inline void setup_timings(struct irq_desc *desc,

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Tue, Apr 25, 2017 at 12:22:30PM +0200, Christoffer Dall wrote: > On Tue, Apr 25, 2017 at 11:49:27AM +0200, Daniel Lezcano wrote: > > [...] > > > > > > > The idle code is very much *not* aware of anything concerning that guest > > > timer. > > > > Just for my own curiosity, if there are two

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote: > On 25/04/17 10:49, Daniel Lezcano wrote: > > On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote: > > [...] > > >>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction > >>> *act) > >>> +{ > >>> + /*

Re: [PATCH] arm64: Add ASM modifier for xN register operands

On Mon, Apr 24, 2017 at 12:13:45PM -0700, Matthias Kaehlcke wrote: > El Mon, Apr 24, 2017 at 06:34:14PM +0100 Will Deacon ha dit: > > On Mon, Apr 24, 2017 at 06:22:51PM +0100, Ard Biesheuvel wrote: > > > AIUI, Clang now always complains for missing register width modifiers, > > > not just for

Re: [PATCH v5 01/22] KVM: arm/arm64: Add ITS save/restore API documentation

On 14 April 2017 at 11:15, Eric Auger wrote: > Add description for how to access ITS registers and how to save/restore > ITS tables into/from memory. > > Signed-off-by: Eric Auger > Acked-by: Peter Maydell thanks -- PMM

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote: [ ... ] > Maybe you could explain why you think this interrupt is relevant to what > you're trying to achieve? > >>> > >>> If this interrupt does not happen on the host, we don't care. > >> > >> All interrupts happen on the

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On 16/04/17 20:52, Kees Cook wrote: Was there a conclusion to this discussion? I didn't see anything definitive in the thread... Notes below... On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann wrote: [Fixed linux-arm-kernel mailing list address, sorry for the duplicate, I'm not

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Tue, Apr 25, 2017 at 08:38:56AM +0100, Marc Zyngier wrote: > On 24/04/17 20:59, Daniel Lezcano wrote: > > On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote: > >> On 24/04/17 19:59, Daniel Lezcano wrote: > >>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote: > On

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On 24/04/17 20:59, Daniel Lezcano wrote: > On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote: >> On 24/04/17 19:59, Daniel Lezcano wrote: >>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote: On 24/04/17 15:01, Daniel Lezcano wrote: > In the next changes, we track

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, Apr 24, 2017 at 10:52 PM, Kees Cook wrote: > On Mon, Apr 24, 2017 at 1:30 PM, Arnd Bergmann wrote: >> How about this approach then: >> >> - To keep it simple, we update the README.rst to say that a minimum >> gcc-4.3 is required, while recommending