Re: [PATCH kvm-unit-tests] x86: fix last commit
On 01/08/2015 23:20, Bandan Das wrote: Actually it should be using the RTC alarm to wake itself up. But the firmware changed recently and the ACPI PMBASE moved from 0xb000 to 0x600. Try this (untested): Ah thanks! your patch works for me. Is this one of the static entries in the ACPI tables ? I am wondering if we can read this value so it works for everybody. Yes, it's PM1a_STS from the PM1a_EVT block; the pointer is in the FADT. x86/s3.c already has code to look for the FADT, so a fix should be easy. On top of that we should move the ACPI tables to a header and the parsing code to lib/x86, so that the vmexit test can use it to find the PM_TMR address. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [kvm-unit-tests PATCH v5 09/11] arm: query /dev/kvm for maximum vcpus
On Fri, Jul 31, 2015 at 09:17:12PM +0200, Andrew Jones wrote: On Fri, Jul 31, 2015 at 04:53:59PM +0100, Alex Bennée wrote: From: Alex Bennée a...@bennee.com The previous $(getconf _NPROCESSORS_CONF) isn't correct as the default maximum VCPU configuration is 4 on arm64 machines which typically have more actual cores. The kernel should probably bump that up to 8, but that's an aside, as it wouldn't resolve the general issue. For this patch, I don't think we need a C utility as we can probe with QEMU, and thus just need a script. $QEMU -machine virt,accel=kvm -smp 9 Number of SMP cpus requested (9), exceeds max cpus supported by machine `virt' (8) The script can live in $root/scripts/, which is a directory recently created for standalone test support. I decided to take a stab at this and came up with https://github.com/rhdrjones/kvm-unit-tests/commit/336d87338da86a0e7f2018a1e509b606b9a2baa2 Thanks, drew -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [kvm-unit-tests PATCH v5 04/11] arm/run: introduce usingkvm var and use it
On Fri, Jul 31, 2015 at 04:53:54PM +0100, Alex Bennée wrote: This makes the script a little cleaner by only checking for KVM support in one place. If KVM isn't available we can fall back to TCG emulation and echo the fact to the screen rather than let QEMU complain. Signed-off-by: Alex Bennée alex.ben...@linaro.org Reviewed-by: Andrew Jones drjo...@redhat.com To work with mkstandalone (which is in upstream's next branch), we need some additions to this patch. See https://github.com/rhdrjones/kvm-unit-tests/commit/be290c1d49c72dd100ab066a11c4ef6fa9017a1c Thanks, drew -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [kvm-unit-tests PATCH v5 00/11] My current MTTCG tests
On Fri, Jul 31, 2015 at 04:53:50PM +0100, Alex Bennée wrote: Hi, This is the current state of my MTTCG tests based on the KVM's unit testing framework. The earlier patches in the series have already been reviewed and will (with the exception of the emacs patch) be making their way upstream. There are a couple of addition to library functions: - printf %u suppport - flush_tlb_page for arm and arm64 - a generic prng from CCAN The two actual tests are: - tlbflush-test - barrier-test The latter barrier test hangs the current -v6 MTTCG patch set in both excl and acqrel modes and will make a good torture test for Alvise's atomic patch set. I suspect the load/store ordering issues will show up better once tested on a weak-ordered backend. I'm open to suggestions for other tests worth adding to show up the issues. The github tree can be found at: https://github.com/stsquad/kvm-unit-tests/tree/current-mttcg-tests Alex Bennée (11): arm/run: set indentation defaults for emacs README: add some CONTRIBUTING notes configure: emit HOST=$host to config.mak arm/run: introduce usingkvm var and use it lib/printf: support the %u unsigned fmt field lib/arm: add flush_tlb_page mmu function new arm/tlbflush-test: TLB torture test arm/unittests.cfg: add the tlbflush tests arm: query /dev/kvm for maximum vcpus new: add isaac prng library from CCAN new: arm/barrier-test for memory barriers General comment; please remove 'new' from your patch summaries. The lib/arm prefix is OK, but I've been using 'arm/arm64:' for all arm/arm64 patches, whether they're lib or tests. Thanks, drew README | 26 ++ arm/barrier-test.c | 206 +++ arm/run | 19 +++- arm/tlbflush-test.c | 194 arm/unittests.cfg| 26 +- arm/utils/kvm-query.c| 41 + config/config-arm-common.mak | 18 +++- configure| 2 + lib/arm/asm/mmu.h| 11 +++ lib/arm64/asm/mmu.h | 8 ++ lib/printf.c | 13 +++ lib/prng.c | 162 ++ lib/prng.h | 82 + 13 files changed, 801 insertions(+), 7 deletions(-) create mode 100644 arm/barrier-test.c create mode 100644 arm/tlbflush-test.c create mode 100644 arm/utils/kvm-query.c create mode 100644 lib/prng.c create mode 100644 lib/prng.h -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/15] KVM: arm64: implement MSI injection in ITS emulation
On 31/07/15 14:22, Eric Auger wrote:
Salut Eric,
On 07/10/2015 04:21 PM, Andre Przywara wrote:
When userland wants to inject a MSI into the guest, we have to use
our data structures to find the LPI number and the VCPU to receive
the interrupt.
Use the wrapper functions to iterate the linked lists and find the
proper Interrupt Translation Table Entry. Then set the pending bit
in this ITTE to be later picked up by the LR handling code. Kick
the VCPU which is meant to handle this interrupt.
We provide a VGIC emulation model specific routine for the actual
MSI injection. The wrapper functions return an error for models not
(yet) implementing MSIs (like the GICv2 emulation).
We also provide the handler for the ITS INT command, which allows a
guest to trigger an MSI via the ITS command queue.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/its-emul.c | 65
+
virt/kvm/arm/its-emul.h | 2 ++
virt/kvm/arm/vgic-v3-emul.c | 1 +
4 files changed, 69 insertions(+)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 323c33a..9e1abf9 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -149,6 +149,7 @@ struct vgic_vm_ops {
int (*map_resources)(struct kvm *, const struct vgic_params *);
bool(*queue_lpis)(struct kvm_vcpu *);
void(*unqueue_lpi)(struct kvm_vcpu *, int irq);
+int (*inject_msi)(struct kvm *, struct kvm_msi *);
};
struct vgic_io_device {
diff --git a/virt/kvm/arm/its-emul.c b/virt/kvm/arm/its-emul.c
index 89534c6..a1c12bb 100644
--- a/virt/kvm/arm/its-emul.c
+++ b/virt/kvm/arm/its-emul.c
@@ -323,6 +323,55 @@ static bool handle_mmio_gits_idregs(struct kvm_vcpu
*vcpu,
}
/*
+ * Translates an incoming MSI request into the redistributor (=VCPU) and
+ * the associated LPI number. Sets the LPI pending bit and also marks the
+ * VCPU as having a pending interrupt.
+ */
+int vits_inject_msi(struct kvm *kvm, struct kvm_msi *msi)
+{
+struct vgic_dist *dist = kvm-arch.vgic;
+struct vgic_its *its = dist-its;
+struct its_itte *itte;
+int cpuid;
+bool inject = false;
+int ret = 0;
+
+if (!vgic_has_its(kvm))
+return -ENODEV;
+
+if (!(msi-flags KVM_MSI_VALID_DEVID))
+return -EINVAL;
I am currently reworking the GSI routing series according to latest
comments (flag usage on userside and removal of EXTENDED_MSI type on
kernel side as you suggested). Given the data path,
kvm_send_userspace_msi (kvm_msi*)
|_ kvm_set_msi (kvm_kernel_irq_routing_entry *)
|_ kvm-arch.vgic.vm_ops.inject_msi (kvm_msi *)
the above check is useless I think since in kvm_set_msi I need to
populate a kvm_msi struct from a kernel routing entry struct. The kernel
routing entry struct has no info about the validity of devid so I
systematically sets the flag in kvm_msi.
I am still dubious about not storing the KVM_MSI_VALID_DEVID info
somewhere in the kernel routing entry struct.
When I reworked our code to only use a flag and not a separate routing
type I ended up with the flag only guarding assignments, which wouldn't
hurt if done unconditionally (since they are all u32's). So the whole
usage of the flag is somewhat in jeopardy now.
Either the eventual MSI consumer requires a DevID (ITS emulation, which
will not work without it) or the consumer does not care at all and can
totally ignore it (GICv2m). So I think we can always pass on the DevID
field and let the final function decide whether to use it or not. But
somehow this doesn't sound right to me, so maybe I am missing something
here?
Cheers,
Andre.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping
On 31/07/15 13:59, Eric Auger wrote:
Hi Andre,
On 07/11/2015 01:17 AM, Andre Przywara wrote:
On 09/07/15 09:22, Eric Auger wrote:
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 following Andre's
advice
---
arch/arm/kvm/Kconfig| 1 +
virt/kvm/arm/vgic-v2-emul.c | 12
2 files changed, 13 insertions(+)
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 151e710..0f58baf 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -31,6 +31,7 @@ config KVM
select KVM_VFIO
select HAVE_KVM_EVENTFD
select HAVE_KVM_IRQFD
+ select HAVE_KVM_MSI
I wonder if this requires some more code to only advertise
KVM_CAP_SIGNAL_MSI if userland actually sets up a GICv2M?
Otherwise userland could get the idea of being able to inectj MSIs
without the guest actually being prepared for that (because the GICv2M
driver did not initialize).
Not sure I get what you mean here. By directly transforming the user
provided MSI msg into an SPI ID, do we really have to care about GICv2M?
By user provided message you mean from user space? So this is an
emulated device, which the guest programs with an MSI payload and a
doorbell address at least? So how would a guest know these things
without having a MSI capable interrupt controller?
Or are we talking about different things here?
Cheers,
Andre.
Best Regards
Eric
Cheers,
Andre.
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQ_ROUTING
depends on ARM_VIRT_EXT ARM_LPAE ARM_ARCH_TIMER
diff --git a/virt/kvm/arm/vgic-v2-emul.c b/virt/kvm/arm/vgic-v2-emul.c
index 1390797..43013cc 100644
--- a/virt/kvm/arm/vgic-v2-emul.c
+++ b/virt/kvm/arm/vgic-v2-emul.c
@@ -478,6 +478,17 @@ static bool vgic_v2_queue_sgi(struct kvm_vcpu *vcpu,
int irq)
}
/**
+ * Emulates GICv2M MSI injection by injecting the SPI ID matching
+ * the msi data
+ * @kvm: pointer to the kvm struct
+ * @msi: the msi struct handle
+ */
+static int vgic_v2m_inject_msi(struct kvm *kvm, struct kvm_msi *msi)
+{
+ return kvm_vgic_inject_irq(kvm, 0, msi-data, 1);
+}
+
+/**
* kvm_vgic_map_resources - Configure global VGIC state before running any
VCPUs
* @kvm: pointer to the kvm struct
*
@@ -566,6 +577,7 @@ void vgic_v2_init_emulation(struct kvm *kvm)
dist-vm_ops.add_sgi_source = vgic_v2_add_sgi_source;
dist-vm_ops.init_model = vgic_v2_init_model;
dist-vm_ops.map_resources = vgic_v2_map_resources;
+ dist-vm_ops.inject_msi = vgic_v2m_inject_msi;
kvm-arch.max_vcpus = VGIC_V2_MAX_CPUS;
}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] KVM: x86: set TMR when the interrupt is accepted
Paolo Bonzini wrote on 2015-07-31: On 31/07/2015 01:26, Zhang, Yang Z wrote: Do not compute TMR in advance. Instead, set the TMR just before the interrupt is accepted into the IRR. This limits the coupling between IOAPIC and LAPIC. Uh.., it back to original way which is wrong. You cannot modify the apic page(here is the TMR reg) directly when the corresponding VMCS may be used at same time. Where is this documented? The TMR is not part of the set of virtualized APIC registers (TPR, PPR, EOI, ISR, IRR, ICR+ICR2; SDM 29.1.1). Only virtualized APIC register reads use the virtual TMR registers (SDM 29.4.2 or 29.5), but these just read data from the corresponding field in the virtual APIC page. It's not only for virtual apic page. All data structures that is used by VMCS(either directly inside in VMCS or referenced by pointer in a VMCS) need follow this rule: 24.11.4 Software Access to Related Structures In addition to data in the VMCS region itself, VMX non-root operation can be controlled by data structures that are referenced by pointers in a VMCS (for example, the I/O bitmaps). While the pointers to these data structures are parts of the VMCS, the data structures themselves are not. They are not accessible using VMREAD and VMWRITE but by ordinary memory writes. Software should ensure that each such data structure is modified only when no logical processor with a current VMCS that references it is in VMX non-root operation. Doing otherwise may lead to unpredictable behavior (including behaviors identified in Section 24.11.1). Paolo Best regards, Yang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers
On Fri, 2015-17-07 at 10:46:58 UTC, Thomas Huth wrote: The EPOW interrupt handler uses rtas_get_sensor(), which in turn uses rtas_busy_delay() to wait for RTAS becoming ready in case it is necessary. But rtas_busy_delay() is annotated with might_sleep() and thus may not be used by interrupts handlers like the EPOW handler! This leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is enabled: BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:496 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6 Call Trace: [c0007ffe7b90] [c0807670] dump_stack+0xa0/0xdc (unreliable) [c0007ffe7bc0] [c00e1f14] ___might_sleep+0x134/0x180 [c0007ffe7c20] [c002aec0] rtas_busy_delay+0x30/0xd0 [c0007ffe7c50] [c002bde4] rtas_get_sensor+0x74/0xe0 [c0007ffe7ce0] [c0083264] ras_epow_interrupt+0x44/0x450 [c0007ffe7d90] [c0120260] handle_irq_event_percpu+0xa0/0x300 [c0007ffe7e70] [c0120524] handle_irq_event+0x64/0xc0 [c0007ffe7eb0] [c0124dbc] handle_fasteoi_irq+0xec/0x260 [c0007ffe7ef0] [c011f4f0] generic_handle_irq+0x50/0x80 [c0007ffe7f20] [c0010f3c] __do_irq+0x8c/0x200 [c0007ffe7f90] [c00236cc] call_do_irq+0x14/0x24 [c0007e6f39e0] [c0011144] do_IRQ+0x94/0x110 [c0007e6f3a30] [c0002594] hardware_interrupt_common+0x114/0x180 Fix this issue by introducing a new rtas_get_sensor_fast() function that does not use rtas_busy_delay() - and thus can only be used for sensors that do not cause a BUSY condition (which should be the case for the sensor that is queried by the EPOW IRQ handler). Signed-off-by: Thomas Huth th...@redhat.com Reviewed-by: Nathan Fontenot nf...@linux.vnet.ibm.com Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/1c2cb594441d02815d30 cheers -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] KVM: x86: set TMR when the interrupt is accepted
Paolo Bonzini wrote on 2015-07-31: On 31/07/2015 04:49, Steve Rutherford wrote: Oh... Yeah. That's a damn good point, given that the interrupt can be injected from another thread while one is in that guest vcpu. Easiest time to update the TMR should be on guest entry through vcpu_scan_ioapic, as before. The best way to go is probably to ditch the new per vcpu EOI exit bitmap, and just update/use the TMR. There's no reason to duplicate that data in the representation of the apic (I suspect that the duplication was inspired by my mistaken notion of the TMR). The IOAPIC exit check can use the TMR instead. Based upon my reading of the SDM, the only reason that the eoi exit bitmaps are not the exact same as the TMR is that it is possible to have virtual-interrupt delivery enabled /without/ an apic access page (Note: V-ID = EOI exit bitmap enabled). Yang, do you happen to know if that is the case? [Note: Just looked back at the old code for updating the EOI exit bitmaps, which for some reason was configured to trigger EOI exits for all IOAPIC interrupts, not just level-triggered IOAPIC interrupts. Which is weird, and I believe totally unecessary.] The RTC interrupt needs to trigger an EOI exit with the in-kernel IOAPIC, in order to detect coalesced interrupts. This is necessary to avoid severe time drift in Windows guest. Correct! EOI exit bitmap is not absolutely same with TMR. Some interrupts (especially timer interrupt) which is edge trigger but need a notification when it got injected into guest. Paolo Best regards, Yang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
