Re: [PATCH v13 10/12] qdev: check callback takes the property child as third argument
On 04/29/2015 01:12 PM, Paolo Bonzini wrote: I think reverting is better since you need a respin and Peter offered to touch the code later. OK Thanks Eric Paolo ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v13 10/12] qdev: check callback takes the property child as third argument
On 29/04/2015 10:37, Eric Auger wrote: This should be an unref. oups yes. Thanks! Do I keep this series or do I revert to sysbus irq connect irq temporary patch as per Peter's last email? I think reverting is better since you need a respin and Peter offered to touch the code later. Paolo ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [Qemu-devel] [RFC PATCH 0/3] KVM: Introduce KVM_MEM_UNCACHED
On Wed, Apr 29, 2015 at 10:19:55AM +0100, Peter Maydell wrote: On 29 April 2015 at 10:03, Alexander Graf ag...@suse.de wrote: On 18.03.15 20:10, Andrew Jones wrote: Introduce a new memory region flag, KVM_MEM_UNCACHED, which is needed by ARM. This flag informs KVM that the given memory region is typically mapped by the guest as uncached. KVM for ARM then maps that region as uncached for userspace as well, in order to keep coherency. I finally managed to give this a spin and immediately ran into an unaligned access trap: Thanks! And err.. sorry it broke. [ 116.509976] Unhandled fault: alignment fault (0x9261) at 0x03ffb130 Program received signal SIGBUS, Bus error. [Switching to Thread 0x3ffb317ecb0 (LWP 1956)] 0x03ffb685ed68 in memset () from /lib64/libc.so.6 (gdb) bt #0 0x03ffb685ed68 in memset () from /lib64/libc.so.6 #1 0x02c013ec in memset (__len=optimized out, __ch=0, __dest=optimized out) at /usr/include/bits/string3.h:90 #2 vbe_ioport_write_data (opaque=0x2aaabbd3600, addr=optimized out, val=65) at /usr/src/debug/qemu-2.3.0-rc4/hw/display/vga.c:739 #3 0x02be07dc in memory_region_write_accessor (mr=optimized out, addr=optimized out, value=optimized out, size=optimized out, shift=optimized out, mask=optimized out) at /usr/src/debug/qemu-2.3.0-rc4/memory.c:430 [...] This appears to be because the KVM_MEM_UNCACHED flag confusingly isn't marking the memory as Normal-Noncacheable but as Device-nGnRnE (aka Strongly Ordered). You can't unalignedly access Device memory (and so you can't use the usual userspace memcpy, memset, etc). Did we really want Device-nGnRnE memory here? If we did can we have a less confusing name for the flag? I hadn't considered the other side-effects of going with device vs. normal memory. I'll change patch 3/3 with 31c31 + pte = set_pte_bit(pte, L_PTE_MT_UNCACHED); --- + pte = set_pte_bit(pte, L_PTE_MT_WRITEBACK); 166c166 + pte = set_pte_bit(pte, PTE_ATTRINDX(MT_DEVICE_nGnRnE)); --- + pte = set_pte_bit(pte, PTE_ATTRINDX(MT_NORMAL_NC)); I've left this on the backburner too long, but I can pick it back up on Monday. I still haven't looked at Paolo's mmu notifier suggestion yet either. I'll start looking at that as well. Thanks, drew [for the non-ARM folk, nGnRnE == no gathering of accesses, no reordering, no early-write-acknowledgement.] thanks -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [Qemu-devel] [PATCH v13 01/12] linux-headers: update headers according to 4.1-rc0
On 04/29/2015 12:36 PM, Christian Borntraeger wrote: Am 28.04.2015 um 18:51 schrieb Eric Auger: This includes, among other things, VFIO platform driver and irqfd/arm. Signed-off-by: Eric Auger eric.au...@linaro.org --- v12 - v13: - update for 4.1-rc0 headers If you have a chance to update the subject before the pull request, its 4.1-rc1 instead of 4.1-rc0. Hi Christian, thanks I will update. Best Regards Eric Christian ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support
On Wed, Apr 29, 2015 at 10:18:18AM +0100, Alex Bennée wrote: Christoffer Dall christoffer.d...@linaro.org writes: On Tue, Apr 28, 2015 at 03:37:01PM +0100, Alex Bennée wrote: Christoffer Dall christoffer.d...@linaro.org writes: On Tue, Apr 28, 2015 at 10:34:12AM +0100, Peter Maydell wrote: On 28 April 2015 at 09:42, Alex Bennée alex.ben...@linaro.org wrote: Peter Maydell peter.mayd...@linaro.org writes: Does the kernel already have a conveniently implemented inject exception into guest lump of code? If so it might be less effort to do it that way round, maybe. So you pointed out we can't just re-inject the exceptions we get as we need to map from things like ESR_ELx_EC_WATCHPT_LOW to ESR_ELx_EC_WATCHPT_CUR before re-injection. Of course if it is as simple as modifying the ESR_EL1 register and returning +ve in the handle_exit path then I can do that but I assumed if any other wrangling needs doing it should be done in userspace. Well, somebody's got to do it, and it's the same amount of work either way (fiddling with ESR, making sure we direct the guest to the right exception vector entry point, maybe a few other things). We already have code in the kernel to inject data/instruction aborts, but not sure how much benefit there is in re-using that. It's up to you really, but I think the kernel code should be clear about what the intention is so that we don't end up in a situation where: (1) The intended behavior is unclear/vague, and (2) it doesn't actually work in practice so nobody can follow the code. Certainly there are some cases where the kernel doesn't have all the information. For example it doesn't know if the soft break was inserted by the guest or the host. That to me favours the let userspace deal with the ugly approach. Not sure I follow. If it's an exception for the guest, then that must be because the guest put in the breakpoint instruction, right? No the host can add breakpoint instructions as well. They both generate the same (redirected) exception to the hypervisor which then has to figure out who planted the breakpoint and where the eventual exception will be handled. I understand this; let's just rewind here. If you've concluded that the exception is for the guest, then the guest must have placed the breakpoint instruction there, correct? Otherwise, the exception is for the hypervisor and the discussion about how to inject an exception for the guest is invalid. Or are you talking about the corner case where the host uses a soft breakpoint to get a breakpoint on an instruction which is also a breakpoint in the guest? However, that's a separate discussion from that of *how* userspace or the kernel then injects an exception to the guest. By using some QEMU TCG functionality or by QEMU calling back into KVM and asking it to inject an exception for it. I don't know if there is explicit TCG functionality to use but QEMU can set the registers and PC up for exception entry and re-enter KVM. I also understand this. I think Peter's point was exactly that if we have existing code somewhere which we can reuse, then we should consider reusing it. Again, I don't care particularly which way, I just want the expected working behavior to be clearly defined. -Christoffer ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support
Christoffer Dall christoffer.d...@linaro.org writes: On Tue, Apr 28, 2015 at 03:37:01PM +0100, Alex Bennée wrote: Christoffer Dall christoffer.d...@linaro.org writes: On Tue, Apr 28, 2015 at 10:34:12AM +0100, Peter Maydell wrote: On 28 April 2015 at 09:42, Alex Bennée alex.ben...@linaro.org wrote: Peter Maydell peter.mayd...@linaro.org writes: Does the kernel already have a conveniently implemented inject exception into guest lump of code? If so it might be less effort to do it that way round, maybe. So you pointed out we can't just re-inject the exceptions we get as we need to map from things like ESR_ELx_EC_WATCHPT_LOW to ESR_ELx_EC_WATCHPT_CUR before re-injection. Of course if it is as simple as modifying the ESR_EL1 register and returning +ve in the handle_exit path then I can do that but I assumed if any other wrangling needs doing it should be done in userspace. Well, somebody's got to do it, and it's the same amount of work either way (fiddling with ESR, making sure we direct the guest to the right exception vector entry point, maybe a few other things). We already have code in the kernel to inject data/instruction aborts, but not sure how much benefit there is in re-using that. It's up to you really, but I think the kernel code should be clear about what the intention is so that we don't end up in a situation where: (1) The intended behavior is unclear/vague, and (2) it doesn't actually work in practice so nobody can follow the code. Certainly there are some cases where the kernel doesn't have all the information. For example it doesn't know if the soft break was inserted by the guest or the host. That to me favours the let userspace deal with the ugly approach. Not sure I follow. If it's an exception for the guest, then that must be because the guest put in the breakpoint instruction, right? No the host can add breakpoint instructions as well. They both generate the same (redirected) exception to the hypervisor which then has to figure out who planted the breakpoint and where the eventual exception will be handled. However, that's a separate discussion from that of *how* userspace or the kernel then injects an exception to the guest. By using some QEMU TCG functionality or by QEMU calling back into KVM and asking it to inject an exception for it. I don't know if there is explicit TCG functionality to use but QEMU can set the registers and PC up for exception entry and re-enter KVM. What am I missing? -Christoffer -- Alex Bennée ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH v14 02/10] hw/vfio/platform: vfio-platform skeleton
Minimal VFIO platform implementation supporting register space user mapping but not IRQ assignment. Signed-off-by: Kim Phillips kim.phill...@linaro.org Signed-off-by: Eric Auger eric.au...@linaro.org --- v13 - v14: - fix ENAMETOOLONG error path sign v12 - v13: - check device name does not contain any / - handle case where readlink fully fills the buffer - in vfio_map_region declare size as uint64_t v11 - v12: - add x-mmap property definition, without which the default value of vbasedev.allow_mmap is false, hence preventing the reg space from being mapped. v10 - v11: x Take into account Alex Bennee's comments: - use g_malloc0_n instead of g_malloc0 - use block declarations when possible - rework readlink returned value treatment - use g_strlcat in place of strncat x use g_snprintf in place of snprintf x correct error handling in vfio_populate_device, in case of flag not corresponding to platform device x various cosmetic changes v9 - v10: - vfio_populate_device no more called in common vfio_get_device but in vfio_base_device_init v8 - v9: - irq management is moved into a separate patch to ease the review - VFIO_DEVICE_FLAGS_PLATFORM is checked in vfio_populate_device - g_free of regions added in vfio_populate_device error label - virtualID becomes 32b v7 - v8: - change proto of vfio_platform_compute_needs_reset and sets vbasedev-needs_reset to false there - vfio_[un]mask_irqindex renamed into vfio_[un]mask_single_irqindex - vfio_register_irq_starter renamed into vfio_kick_irqs we now use a reset notifier instead of a machine init done notifier. Enables to get rid of the VfioIrqStarterNotifierParams dangling pointer. Previously we use pbus first_irq. This is no more possible since the reset notifier takes a void * and first_irq is a field of a const struct. So now we pass the DeviceState handle of the interrupt controller. I tried to keep the code generic, reason why I did not rely on an architecture specific accessor to retrieve the gsi number (gic accessor as proposed by Alex). I would like to avoid creating an ARM VFIO device model. I hope this model model can work on other archs than arm (no multiple intc?); wouldn't it be simpler to keep the previous first_irq parameter and relax the const constraint. v6 - v7: - compat is not exposed anymore as a user option. Rationale is the vfio device became abstract and a specialization is needed anyway. The derived device must set the compat string. - in v6 vfio_start_irq_injection was exposed in vfio-platform.h. A new function dubbed vfio_register_irq_starter replaces it. It registers a machine init done notifier that programs starts all dynamic VFIO device IRQs. This function is supposed to be called by the machine file. A set of static helper routines are added too. It must be called before the creation of the platform bus device. v5 - v6: - vfio_device property renamed into host property - correct error handling of VFIO_DEVICE_GET_IRQ_INFO ioctl and remove PCI related comment - remove declaration of vfio_setup_irqfd and irqfd_allowed property.Both belong to next patch (irqfd) - remove declaration of vfio_intp_interrupt in vfio-platform.h - functions that can be static get this characteristic - remove declarations of vfio_region_ops, vfio_memory_listener, group_list, vfio_address_spaces. All are moved to vfio-common.h - remove vfio_put_device declaration and definition - print_regions removed. code moved into vfio_populate_regions - replace DPRINTF by trace events - new helper routine to set the trigger eventfd - dissociate intp init from the injection enablement: vfio_enable_intp renamed into vfio_init_intp and new function named vfio_start_eventfd_injection - injection start moved to vfio_start_irq_injection (not anymore in vfio_populate_interrupt) - new start_irq_fn field in VFIOPlatformDevice corresponding to the function that will be used for starting injection - user handled eventfd: x add mutex to protect IRQ state list manipulation, x correct misleading comment in vfio_intp_interrupt. x Fix bugs thanks to fake interrupt modality - VFIOPlatformDeviceClass becomes abstract - add error_setg in vfio_platform_realize v4 - v5: - vfio-plaform.h included first - cleanup error handling in *populate*, vfio_get_device, vfio_enable_intp - vfio_put_device not called anymore - add some includes to follow vfio policy v3 - v4: [Eric Auger] - merge of vfio: Add initial IRQ support in platform device to get a full functional patch although perfs are limited. - removal of unrealize function since I currently understand it is only used with device hot-plug feature. v2 - v3: [Eric Auger] - further factorization between PCI and platform (VFIORegion, VFIODevice). same level of functionality. = v2: [Kim Philipps] - Initial Creation of the device supporting register space mapping --- hw/vfio/Makefile.objs | 1 + hw/vfio/platform.c | 288
[PATCH v14 10/10] hw/vfio/platform: add irqfd support
This patch aims at optimizing IRQ handling using irqfd framework.
Instead of handling the eventfds on user-side they are handled on
kernel side using
- the KVM irqfd framework,
- the VFIO driver virqfd framework.
the virtual IRQ completion is trapped at interrupt controller
This removes the need for fast/slow path swap.
Overall this brings significant performance improvements.
Signed-off-by: Alvise Rigo a.r...@virtualopensystems.com
Signed-off-by: Eric Auger eric.au...@linaro.org
Reviewed-by: Alex Benneealex.ben...@linaro.org
---
v13 - v14:
- use connect_irq_notifier
- remove trace_vfio_platform_start_eventfd
v12 - v13:
- setup the new mechanism for starting irqfd, based on
LinkPropertySetter override
- use kvm_irqchip_[add,remove]_irqfd_notifier new functions: no need
to bother about gsi (hence virtualID could be removed with small
change in trace-events)
v10 - v11:
- Add Alex' Reviewed-by
- introduce kvm_accel in this patch and initialize it
v5 - v6
- rely on kvm_irqfds_enabled() and kvm_resamplefds_enabled()
- guard KVM code with #ifdef CONFIG_KVM
v3 - v4:
[Alvise Rigo]
Use of VFIO Platform driver v6 unmask/virqfd feature and removal
of resamplefd handler. Physical IRQ unmasking is now done in
VFIO driver.
v3:
[Eric Auger]
initial support with resamplefd handled on QEMU side since the
unmask was not supported on VFIO platform driver v5.
Conflicts:
hw/vfio/platform.c
---
hw/vfio/platform.c | 107
include/hw/vfio/vfio-platform.h | 2 +
trace-events| 1 +
3 files changed, 110 insertions(+)
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 51b9391..a5246ab 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -26,6 +26,7 @@
#include hw/sysbus.h
#include trace.h
#include hw/platform-bus.h
+#include sysemu/kvm.h
/*
* Functions used whatever the injection method
@@ -51,6 +52,7 @@ static VFIOINTp *vfio_init_intp(VFIODevice *vbasedev,
intp-pin = info.index;
intp-flags = info.flags;
intp-state = VFIO_IRQ_INACTIVE;
+intp-kvm_accel = false;
sysbus_init_irq(sbdev, intp-qemuirq);
@@ -61,6 +63,13 @@ static VFIOINTp *vfio_init_intp(VFIODevice *vbasedev,
error_report(vfio: Error: trigger event_notifier_init failed );
return NULL;
}
+/* Get an eventfd for resample/unmask */
+ret = event_notifier_init(intp-unmask, 0);
+if (ret) {
+g_free(intp);
+error_report(vfio: Error: resample event_notifier_init failed eoi);
+return NULL;
+}
QLIST_INSERT_HEAD(vdev-intp_list, intp, next);
return intp;
@@ -315,6 +324,95 @@ static int vfio_start_eventfd_injection(VFIOINTp *intp)
return ret;
}
+/*
+ * Functions used for irqfd
+ */
+
+#ifdef CONFIG_KVM
+
+/**
+ * vfio_set_resample_eventfd - sets the resamplefd for an IRQ
+ * @intp: the IRQ struct handle
+ * programs the VFIO driver to unmask this IRQ when the
+ * intp-unmask eventfd is triggered
+ */
+static int vfio_set_resample_eventfd(VFIOINTp *intp)
+{
+VFIODevice *vbasedev = intp-vdev-vbasedev;
+struct vfio_irq_set *irq_set;
+int argsz, ret;
+int32_t *pfd;
+
+argsz = sizeof(*irq_set) + sizeof(*pfd);
+irq_set = g_malloc0(argsz);
+irq_set-argsz = argsz;
+irq_set-flags = VFIO_IRQ_SET_DATA_EVENTFD | VFIO_IRQ_SET_ACTION_UNMASK;
+irq_set-index = intp-pin;
+irq_set-start = 0;
+irq_set-count = 1;
+pfd = (int32_t *)irq_set-data;
+*pfd = event_notifier_get_fd(intp-unmask);
+qemu_set_fd_handler(*pfd, NULL, NULL, NULL);
+ret = ioctl(vbasedev-fd, VFIO_DEVICE_SET_IRQS, irq_set);
+g_free(irq_set);
+if (ret 0) {
+error_report(vfio: Failed to set resample eventfd: %m);
+}
+return ret;
+}
+
+static void vfio_start_irqfd_injection(SysBusDevice *sbdev, qemu_irq irq)
+{
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIOINTp *intp;
+bool found = false;
+
+QLIST_FOREACH(intp, vdev-intp_list, next) {
+if (intp-qemuirq == irq) {
+found = true;
+break;
+}
+}
+assert(found);
+
+/* Get to a known interrupt state */
+qemu_set_fd_handler(event_notifier_get_fd(intp-interrupt),
+NULL, NULL, vdev);
+
+vfio_mask_single_irqindex(vdev-vbasedev, intp-pin);
+qemu_set_irq(intp-qemuirq, 0);
+
+if (kvm_irqchip_add_irqfd_notifier(kvm_state, intp-interrupt,
+ intp-unmask, irq) 0) {
+goto fail_irqfd;
+}
+
+if (vfio_set_trigger_eventfd(intp, NULL) 0) {
+goto fail_vfio;
+}
+if (vfio_set_resample_eventfd(intp) 0) {
+goto fail_vfio;
+}
+
+/* Let'em rip */
+vfio_unmask_single_irqindex(vdev-vbasedev, intp-pin);
+
+intp-kvm_accel = true;
+
+trace_vfio_platform_start_irqfd_injection(intp-pin,
+ event_notifier_get_fd(intp-interrupt),
+
[PATCH v14 05/10] hw/arm/sysbus-fdt: enable vfio-calxeda-xgmac dynamic instantiation
This patch allows the instantiation of the vfio-calxeda-xgmac device
from the QEMU command line (-device vfio-calxeda-xgmac,host=device).
A specialized device tree node is created for the guest, containing
compat, dma-coherent, reg and interrupts properties.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v12 - v13:
- use platform_bus_get_mmio_addr instead of deprecated mmio[0] property.
Thanks to Bharat who pointed this issue out.
- use cpu_to_be32 to mmio_base size (Vikram report)
v10 - v11:
- add dma-coherent property to calxeda midway xgmac node (fix)
- use qemu_fdt_setprop to add reg property instead of
qemu_fdt_setprop_sized_cells_from_array
- commit message rewording
v8 - v9:
- properly free resources in case of errors in
add_calxeda_midway_xgmac_fdt_node
v7 - v8:
- move the add_fdt_node_functions array declaration between the device
specific code and the generic code to avoid forward declarations of
decice specific functions
- rename add_basic_vfio_fdt_node into
add_calxeda_midway_xgmac_fdt_node
v6 - v7:
- compat string re-formatting removed since compat string is not exposed
anymore as a user option
- VFIO IRQ kick-off removed from sysbus-fdt and moved to VFIO platform
device
---
hw/arm/sysbus-fdt.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 3038b94..3d67acf 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -26,6 +26,8 @@
#include sysemu/device_tree.h
#include hw/platform-bus.h
#include sysemu/sysemu.h
+#include hw/vfio/vfio-platform.h
+#include hw/vfio/vfio-calxeda-xgmac.h
/*
* internal struct that contains the information to create dynamic
@@ -53,11 +55,81 @@ typedef struct NodeCreationPair {
int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
} NodeCreationPair;
+/* Device Specific Code */
+
+/**
+ * add_calxeda_midway_xgmac_fdt_node
+ *
+ * Generates a simple node with following properties:
+ * compatible string, regs, interrupts, dma-coherent
+ */
+static int add_calxeda_midway_xgmac_fdt_node(SysBusDevice *sbdev, void *opaque)
+{
+PlatformBusFDTData *data = opaque;
+PlatformBusDevice *pbus = data-pbus;
+void *fdt = data-fdt;
+const char *parent_node = data-pbus_node_name;
+int compat_str_len, i, ret = -1;
+char *nodename;
+uint32_t *irq_attr, *reg_attr;
+uint64_t mmio_base, irq_number;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIODevice *vbasedev = vdev-vbasedev;
+
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
+nodename = g_strdup_printf(%s/%s@% PRIx64, parent_node,
+ vbasedev-name, mmio_base);
+qemu_fdt_add_subnode(fdt, nodename);
+
+compat_str_len = strlen(vdev-compat) + 1;
+qemu_fdt_setprop(fdt, nodename, compatible,
+ vdev-compat, compat_str_len);
+
+qemu_fdt_setprop(fdt, nodename, dma-coherent, , 0);
+
+reg_attr = g_new(uint32_t, vbasedev-num_regions*2);
+for (i = 0; i vbasedev-num_regions; i++) {
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
+reg_attr[2*i] = cpu_to_be32(mmio_base);
+reg_attr[2*i+1] = cpu_to_be32(
+memory_region_size(vdev-regions[i]-mem));
+}
+ret = qemu_fdt_setprop(fdt, nodename, reg, reg_attr,
+ vbasedev-num_regions*2*sizeof(uint32_t));
+if (ret) {
+error_report(could not set reg property of node %s, nodename);
+goto fail_reg;
+}
+
+irq_attr = g_new(uint32_t, vbasedev-num_irqs*3);
+for (i = 0; i vbasedev-num_irqs; i++) {
+irq_number = platform_bus_get_irqn(pbus, sbdev , i)
+ + data-irq_start;
+irq_attr[3*i] = cpu_to_be32(0);
+irq_attr[3*i+1] = cpu_to_be32(irq_number);
+irq_attr[3*i+2] = cpu_to_be32(0x4);
+}
+ ret = qemu_fdt_setprop(fdt, nodename, interrupts,
+ irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
+if (ret) {
+error_report(could not set interrupts property of node %s,
+ nodename);
+}
+g_free(irq_attr);
+fail_reg:
+g_free(reg_attr);
+g_free(nodename);
+return ret;
+}
+
/* list of supported dynamic sysbus devices */
static const NodeCreationPair add_fdt_node_functions[] = {
+{TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node},
{, NULL}, /* last element */
};
+/* Generic Code */
+
/**
* add_fdt_node - add the device tree node of a dynamic sysbus device
*
--
1.8.3.2
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH v14 03/10] hw/vfio/platform: add irq assignment
This patch adds the code requested to assign interrupts to
a guest. The interrupts are mediated through user handled
eventfds only.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v13 - v14:
- remove virtualID field in header
v12 - v13:
- start user-side eventfd handling at realize time
- remove start_irq_fn
v10 - v11:
- use block declaration when possible
- change order of vfio_platform_eoi vs vfio_intp_interrupt
- introduce vfio_intp_inject_pending_lockheld following Alex Bennee
comments
- remove unmasking/masked when setting up VFIO signaling
- remove unused kvm_accel member in VFIOINTp struct
- add flags member in VFIOINTp in order to properly discriminate
edge/level-sensitive IRQs; unmask the physical IRQ only in case of
level-sensitive IRQ
- some comment rewording
v8 - v9:
- free irq related resources in case of error in vfio_populate_device
---
hw/vfio/platform.c | 331 +++-
include/hw/vfio/vfio-platform.h | 31
trace-events| 7 +
3 files changed, 368 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 7bc7629..51b9391 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -22,10 +22,299 @@
#include qemu/range.h
#include sysemu/sysemu.h
#include exec/memory.h
+#include qemu/queue.h
#include hw/sysbus.h
#include trace.h
#include hw/platform-bus.h
+/*
+ * Functions used whatever the injection method
+ */
+
+/**
+ * vfio_init_intp - allocate, initialize the IRQ struct pointer
+ * and add it into the list of IRQs
+ * @vbasedev: the VFIO device handle
+ * @info: irq info struct retrieved from VFIO driver
+ */
+static VFIOINTp *vfio_init_intp(VFIODevice *vbasedev,
+struct vfio_irq_info info)
+{
+int ret;
+VFIOPlatformDevice *vdev =
+container_of(vbasedev, VFIOPlatformDevice, vbasedev);
+SysBusDevice *sbdev = SYS_BUS_DEVICE(vdev);
+VFIOINTp *intp;
+
+intp = g_malloc0(sizeof(*intp));
+intp-vdev = vdev;
+intp-pin = info.index;
+intp-flags = info.flags;
+intp-state = VFIO_IRQ_INACTIVE;
+
+sysbus_init_irq(sbdev, intp-qemuirq);
+
+/* Get an eventfd for trigger */
+ret = event_notifier_init(intp-interrupt, 0);
+if (ret) {
+g_free(intp);
+error_report(vfio: Error: trigger event_notifier_init failed );
+return NULL;
+}
+
+QLIST_INSERT_HEAD(vdev-intp_list, intp, next);
+return intp;
+}
+
+/**
+ * vfio_set_trigger_eventfd - set VFIO eventfd handling
+ *
+ * @intp: IRQ struct handle
+ * @handler: handler to be called on eventfd signaling
+ *
+ * Setup VFIO signaling and attach an optional user-side handler
+ * to the eventfd
+ */
+static int vfio_set_trigger_eventfd(VFIOINTp *intp,
+eventfd_user_side_handler_t handler)
+{
+VFIODevice *vbasedev = intp-vdev-vbasedev;
+struct vfio_irq_set *irq_set;
+int argsz, ret;
+int32_t *pfd;
+
+argsz = sizeof(*irq_set) + sizeof(*pfd);
+irq_set = g_malloc0(argsz);
+irq_set-argsz = argsz;
+irq_set-flags = VFIO_IRQ_SET_DATA_EVENTFD | VFIO_IRQ_SET_ACTION_TRIGGER;
+irq_set-index = intp-pin;
+irq_set-start = 0;
+irq_set-count = 1;
+pfd = (int32_t *)irq_set-data;
+*pfd = event_notifier_get_fd(intp-interrupt);
+qemu_set_fd_handler(*pfd, (IOHandler *)handler, NULL, intp);
+ret = ioctl(vbasedev-fd, VFIO_DEVICE_SET_IRQS, irq_set);
+g_free(irq_set);
+if (ret 0) {
+error_report(vfio: Failed to set trigger eventfd: %m);
+qemu_set_fd_handler(*pfd, NULL, NULL, NULL);
+}
+return ret;
+}
+
+/*
+ * Functions only used when eventfds are handled on user-side
+ * ie. without irqfd
+ */
+
+/**
+ * vfio_mmap_set_enabled - enable/disable the fast path mode
+ * @vdev: the VFIO platform device
+ * @enabled: the target mmap state
+ *
+ * enabled = true ~ fast path = MMIO region is mmaped (no KVM TRAP);
+ * enabled = false ~ slow path = MMIO region is trapped and region callbacks
+ * are called; slow path enables to trap the device IRQ status register reset
+*/
+
+static void vfio_mmap_set_enabled(VFIOPlatformDevice *vdev, bool enabled)
+{
+int i;
+
+trace_vfio_platform_mmap_set_enabled(enabled);
+
+for (i = 0; i vdev-vbasedev.num_regions; i++) {
+VFIORegion *region = vdev-regions[i];
+
+memory_region_set_enabled(region-mmap_mem, enabled);
+}
+}
+
+/**
+ * vfio_intp_mmap_enable - timer function, restores the fast path
+ * if there is no more active IRQ
+ * @opaque: actually points to the VFIO platform device
+ *
+ * Called on mmap timer timout, this function checks whether the
+ * IRQ is still active and if not, restores the fast path.
+ * by construction a single eventfd is handled at a time.
+ * if the IRQ is still active, the timer is re-programmed.
+ */
+static void vfio_intp_mmap_enable(void *opaque)
+{
+VFIOINTp *tmp;
+VFIOPlatformDevice *vdev = (VFIOPlatformDevice
[PATCH v14 08/10] intc: arm_gic_kvm: set the qemu_irq/gsi mapping
The arm_gic_kvm now calls kvm_irqchip_set_qemuirq_gsi to build
the hash table storing qemu_irq/gsi mappings. From that point on
irqfd can be setup directly from the qemu_irq using
kvm_irqchip_add_irqfd_notifier.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v2 - v3:
- kvm_irqchip_add_qemuirq_irqfd_notifier renamed into
kvm_irqchip_add_irqfd_notifier
---
hw/intc/arm_gic_kvm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/intc/arm_gic_kvm.c b/hw/intc/arm_gic_kvm.c
index e1952ad..28506e3 100644
--- a/hw/intc/arm_gic_kvm.c
+++ b/hw/intc/arm_gic_kvm.c
@@ -554,6 +554,11 @@ static void kvm_arm_gic_realize(DeviceState *dev, Error
**errp)
*/
i += (GIC_INTERNAL * s-num_cpu);
qdev_init_gpio_in(dev, kvm_arm_gic_set_irq, i);
+
+for (i = 0; i s-num_irq - GIC_INTERNAL; i++) {
+qemu_irq irq = qdev_get_gpio_in(dev, i);
+kvm_irqchip_set_qemuirq_gsi(kvm_state, irq, i);
+}
/* We never use our outbound IRQ lines but provide them so that
* we maintain the same interface as the non-KVM GIC.
*/
--
1.8.3.2
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH v14 00/10] KVM platform device passthrough
This series aims at enabling KVM platform device passthrough. On kernel side, the vfio platform driver is needed, available from 4.1-rc1 onwards. This series now only relies on the following QEMU series, for dynamic instantiation of the VFIO platform device from qemu command line: [1] [PATCH v12 0/4] machvirt dynamic sysbus device instantiation http://comments.gmane.org/gmane.comp.emulators.kvm.arm.devel/886 Both series are candidate for QEMU 2.4 and available at http://git.linaro.org/people/eric.auger/qemu.git (branch vfio_integ_v14) The series was tested on Calxeda Midway (ARMv7) where one xgmac is assigned to KVM host while the second one is assigned to the guest. Wiki for Calxeda Midway setup: https://wiki.linaro.org/LEG/Engineering/Virtualization/Platform_Device_Passthrough_on_Midway History: v13 - v14: - remove v13 9, 10, 11 patch files and replace them by a single patch file sysbus: add irq_routing_notifier. - in skeleton, fix ENAMETOOLONG sign - remove VFIOINTp virtualID in add irq assignment patch file - removed trace_vfio_platform_start_eventfd v12 - v13: - header update but same update was already sent by Cornelia - Rework VFIO signaling irqfd setup: restored 2-step setup featuring eventfd setup on realize and then irqfd setup on irq binding. - irqfd setup now uses kvm_irqchip_add_irqfd_notifier and sysbus irq_set_hook override. This leads to the introduction of 6 patch files enabling those 2 features. Paolo advised to introduce kvm_irqchip_add_irqfd_notifier series in the VFIO one. I did the same for irq_set_hook series but if it is better I can submit it aside. - above changes made possible to remove x hw/vfio/platform: add capability to start IRQ propagation x hw/arm/virt: start VFIO IRQ propagation - in sysbus-fdt.c, use platform_bus_get_mmio_addr instead of deprecated mmio[0] property. Thanks to Bharat who pointed this issue out. also cpu_to_be32 was used for size and base (Vikram input) . - in skeleton misc corrections following Alex review. v11-v12: - add x-mmap property definition, without which the default value of vbasedev.allow_mmap is false, hence preventing the reg space from being mmapped. v10-v11: - rebase onto v2.3.0-rc0 (mainly related to PCIe support in virt) - add dma-coherent property for calxeda midway (fix revealed by removal of kernel-side vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1) - virt modifications to start VFIO IRQ forwarding are now in a separate patch - rearrange linux header exports (those are still partial exports waiting for definitive 4.1-rc0) - take into account Alex Benn??e comments: - use g_malloc0_n instead of g_malloc0 - use block declarations when possible - rework readlink returned value treatment - use g_strlcat in place strncat - re-arrange mutex locking for multiple IRQ support (user-side handled eventfds) - use g_snprintf instead of snprintf - change the order of functions to avoid pre-declaration in platform.c - add flags in VFIOINTp struct to detect whether the IRQ is automasked - some comment rewriting v9-v10: - rebase on vfio: cleanup vfio_get_device error path, remove vfio_populate_device: vfio_populate_device no more called in vfio_get_device but in vfio_base_device_init - update VFIO header according to vfio platform driver v13 (no AMBA) v8-v9: - rebase on 2.2.0 and machvirt dynamic sysbus instantiation v10 - v8 1-11 were pulled - patch files related to forwarding are moved in a seperate series since it depends on kernel series still in RFC. - introduction of basic VFIO platform device split into 3 patch files to ease the review (hope it will help). - add an author in platform.c - add deallocation in vfio_populate_device error case - add patch file doing the VFIO header sync - use VFIO_DEVICE_FLAGS_PLATFORM in vfio_populate_device - rename calxeda_xgmac.c into calxeda-xgmac.c - sysbus-fdt: add_calxeda_midway_xgmac_fdt_node g_free in case of errors - reword of linux-headers patch files v7-v8: - rebase on v2.2.0-rc3 and integrate Add skip_dump flag to ignore memory region during dump - KVM header evolution with subindex addition in kvm_arch_forwarded_irq - split [PATCH v7 03/16] hw/vfio/pci: introduce VFIODevice into 4 patches - vfio_compute_needs_reset does not return bool anymore - add some comments about exposed MMIO region and IRQ in calxeda xgmac device - vfio_[un]mask_irqindex renamed into vfio_[un]mask_single_irqindex - rework IRQ startup: former machine init done notifier is replaced by a reset notifier. machine file passes the interrupt controller DeviceState handle (not the platform bus first irq parameter). - sysbus-fdt: - move the add_fdt_node_functions array declaration between the device specific code and the generic code to avoid forward declarations of decice specific functions - rename add_basic_vfio_fdt_node into add_calxeda_midway_xgmac_fdt_node emphasizing the fact it is xgmac specific v6-v7: - fake injection test
[PATCH v14 01/10] linux-headers: update headers according to 4.1-rc1
This updates linux-headers against master 4.1-rc1 (commit
b787f68c36d49bb1d9236f403813641efa74a031).
This includes, among other things, VFIO platform driver and
irqfd/arm.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v13 - v14:
- update to precise 4.1-rc1, precise the commit and change the title
v12 - v13:
- update for 4.1-rc0 headers
v10 - v11:
- only includes header modifications related to vfio platform
driver v14 and not those related to
vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1
Signed-off-by: Eric Auger eric.au...@linaro.org
---
include/standard-headers/linux/virtio_balloon.h | 28 +++-
include/standard-headers/linux/virtio_blk.h | 8 +-
include/standard-headers/linux/virtio_ids.h | 1 +
linux-headers/asm-arm/kvm.h | 9 +-
linux-headers/asm-arm64/kvm.h | 9 +-
linux-headers/asm-mips/kvm.h| 164 +++-
linux-headers/asm-s390/kvm.h| 4 +
linux-headers/asm-x86/hyperv.h | 2 +
linux-headers/linux/kvm.h | 66 +-
linux-headers/linux/vfio.h | 2 +
10 files changed, 223 insertions(+), 70 deletions(-)
diff --git a/include/standard-headers/linux/virtio_balloon.h
b/include/standard-headers/linux/virtio_balloon.h
index 799376d..88ada1d 100644
--- a/include/standard-headers/linux/virtio_balloon.h
+++ b/include/standard-headers/linux/virtio_balloon.h
@@ -25,6 +25,7 @@
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE. */
+#include standard-headers/linux/types.h
#include standard-headers/linux/virtio_ids.h
#include standard-headers/linux/virtio_config.h
@@ -51,9 +52,32 @@ struct virtio_balloon_config {
#define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
#define VIRTIO_BALLOON_S_NR 6
+/*
+ * Memory statistics structure.
+ * Driver fills an array of these structures and passes to device.
+ *
+ * NOTE: fields are laid out in a way that would make compiler add padding
+ * between and after fields, so we have to use compiler-specific attributes to
+ * pack it, to disable this padding. This also often causes compiler to
+ * generate suboptimal code.
+ *
+ * We maintain this statistics structure format for backwards compatibility,
+ * but don't follow this example.
+ *
+ * If implementing a similar structure, do something like the below instead:
+ * struct virtio_balloon_stat {
+ * __virtio16 tag;
+ * uint8_t reserved[6];
+ * __virtio64 val;
+ * };
+ *
+ * In other words, add explicit reserved fields to align field and
+ * structure boundaries at field size, avoiding compiler padding
+ * without the packed attribute.
+ */
struct virtio_balloon_stat {
- uint16_t tag;
- uint64_t val;
+ __virtio16 tag;
+ __virtio64 val;
} QEMU_PACKED;
#endif /* _LINUX_VIRTIO_BALLOON_H */
diff --git a/include/standard-headers/linux/virtio_blk.h
b/include/standard-headers/linux/virtio_blk.h
index 12016b4..cd601f4 100644
--- a/include/standard-headers/linux/virtio_blk.h
+++ b/include/standard-headers/linux/virtio_blk.h
@@ -58,7 +58,7 @@ struct virtio_blk_config {
uint32_t size_max;
/* The maximum number of segments (if VIRTIO_BLK_F_SEG_MAX) */
uint32_t seg_max;
- /* geometry the device (if VIRTIO_BLK_F_GEOMETRY) */
+ /* geometry of the device (if VIRTIO_BLK_F_GEOMETRY) */
struct virtio_blk_geometry {
uint16_t cylinders;
uint8_t heads;
@@ -117,7 +117,11 @@ struct virtio_blk_config {
#define VIRTIO_BLK_T_BARRIER 0x8000
#endif /* !VIRTIO_BLK_NO_LEGACY */
-/* This is the first element of the read scatter-gather list. */
+/*
+ * This comes first in the read scatter-gather list.
+ * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated,
+ * this is the first element of the read scatter-gather list.
+ */
struct virtio_blk_outhdr {
/* VIRTIO_BLK_T* */
__virtio32 type;
diff --git a/include/standard-headers/linux/virtio_ids.h
b/include/standard-headers/linux/virtio_ids.h
index 284fc3a..5f60aa4 100644
--- a/include/standard-headers/linux/virtio_ids.h
+++ b/include/standard-headers/linux/virtio_ids.h
@@ -39,5 +39,6 @@
#define VIRTIO_ID_9P 9 /* 9p virtio console */
#define VIRTIO_ID_RPROC_SERIAL 11 /* virtio remoteproc serial link */
#define VIRTIO_ID_CAIF12 /* Virtio caif */
+#define VIRTIO_ID_INPUT18 /* virtio input */
#endif /* _LINUX_VIRTIO_IDS_H */
diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 0db25bc..c98e4dc 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -195,9 +195,16 @@ struct kvm_arch_memory_slot {
#define KVM_ARM_IRQ_CPU_IRQ0
#define KVM_ARM_IRQ_CPU_FIQ1
-/* Highest supported SPI, from
[PATCH v14 06/10] kvm: rename kvm_irqchip_[add, remove]_irqfd_notifier with gsi suffix
Anticipating for the introduction of new add/remove functions taking
a qemu_irq parameter, let's rename existing ones with a gsi suffix.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
hw/s390x/virtio-ccw.c | 8
hw/vfio/pci.c | 6 +++---
hw/virtio/virtio-pci.c | 4 ++--
include/sysemu/kvm.h | 7 ---
kvm-all.c | 7 ---
kvm-stub.c | 7 ---
6 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index ed75c63..55a74fa 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -1238,8 +1238,8 @@ static int virtio_ccw_add_irqfd(VirtioCcwDevice *dev, int
n)
VirtQueue *vq = virtio_get_queue(vdev, n);
EventNotifier *notifier = virtio_queue_get_guest_notifier(vq);
-return kvm_irqchip_add_irqfd_notifier(kvm_state, notifier, NULL,
- dev-routes.gsi[n]);
+return kvm_irqchip_add_irqfd_notifier_gsi(kvm_state, notifier, NULL,
+ dev-routes.gsi[n]);
}
static void virtio_ccw_remove_irqfd(VirtioCcwDevice *dev, int n)
@@ -1249,8 +1249,8 @@ static void virtio_ccw_remove_irqfd(VirtioCcwDevice *dev,
int n)
EventNotifier *notifier = virtio_queue_get_guest_notifier(vq);
int ret;
-ret = kvm_irqchip_remove_irqfd_notifier(kvm_state, notifier,
-dev-routes.gsi[n]);
+ret = kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state, notifier,
+dev-routes.gsi[n]);
assert(ret == 0);
}
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index cd15b20..938f584 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -596,7 +596,7 @@ static void vfio_add_kvm_msi_virq(VFIOMSIVector *vector,
MSIMessage *msg,
return;
}
-if (kvm_irqchip_add_irqfd_notifier(kvm_state, vector-kvm_interrupt,
+if (kvm_irqchip_add_irqfd_notifier_gsi(kvm_state, vector-kvm_interrupt,
NULL, virq) 0) {
kvm_irqchip_release_virq(kvm_state, virq);
event_notifier_cleanup(vector-kvm_interrupt);
@@ -608,8 +608,8 @@ static void vfio_add_kvm_msi_virq(VFIOMSIVector *vector,
MSIMessage *msg,
static void vfio_remove_kvm_msi_virq(VFIOMSIVector *vector)
{
-kvm_irqchip_remove_irqfd_notifier(kvm_state, vector-kvm_interrupt,
- vector-virq);
+kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state, vector-kvm_interrupt,
+ vector-virq);
kvm_irqchip_release_virq(kvm_state, vector-virq);
vector-virq = -1;
event_notifier_cleanup(vector-kvm_interrupt);
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index c7c3f72..3be7fad 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -477,7 +477,7 @@ static int kvm_virtio_pci_irqfd_use(VirtIOPCIProxy *proxy,
VirtQueue *vq = virtio_get_queue(vdev, queue_no);
EventNotifier *n = virtio_queue_get_guest_notifier(vq);
int ret;
-ret = kvm_irqchip_add_irqfd_notifier(kvm_state, n, NULL, irqfd-virq);
+ret = kvm_irqchip_add_irqfd_notifier_gsi(kvm_state, n, NULL, irqfd-virq);
return ret;
}
@@ -491,7 +491,7 @@ static void kvm_virtio_pci_irqfd_release(VirtIOPCIProxy
*proxy,
VirtIOIRQFD *irqfd = proxy-vector_irqfd[vector];
int ret;
-ret = kvm_irqchip_remove_irqfd_notifier(kvm_state, n, irqfd-virq);
+ret = kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state, n, irqfd-virq);
assert(ret == 0);
}
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 197e6c0..0f28d6f 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -413,9 +413,10 @@ void kvm_irqchip_release_virq(KVMState *s, int virq);
int kvm_irqchip_add_adapter_route(KVMState *s, AdapterInfo *adapter);
-int kvm_irqchip_add_irqfd_notifier(KVMState *s, EventNotifier *n,
- EventNotifier *rn, int virq);
-int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
+int kvm_irqchip_add_irqfd_notifier_gsi(KVMState *s, EventNotifier *n,
+ EventNotifier *rn, int virq);
+int kvm_irqchip_remove_irqfd_notifier_gsi(KVMState *s, EventNotifier *n,
+ int virq);
void kvm_pc_gsi_handler(void *opaque, int n, int level);
void kvm_pc_setup_irq_routing(bool pci_enabled);
void kvm_init_irq_routing(KVMState *s);
diff --git a/kvm-all.c b/kvm-all.c
index 4ec153d..42bb923 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1368,14 +1368,15 @@ int kvm_irqchip_update_msi_route(KVMState *s, int virq,
MSIMessage msg)
}
#endif /* !KVM_CAP_IRQ_ROUTING */
-int kvm_irqchip_add_irqfd_notifier(KVMState *s, EventNotifier *n,
- EventNotifier *rn, int virq)
+int kvm_irqchip_add_irqfd_notifier_gsi(KVMState *s, EventNotifier *n,
+ EventNotifier *rn,
[PATCH v14 09/10] sysbus: add irq_routing_notifier
Add a new connect_irq_notifier notifier in the SysBusDeviceClass. This
notifier, if populated, is called after sysbus_connect_irq.
This mechanism is used to setup VFIO signaling once VFIO platform
devices get attached to their platform bus, on a machine init done
notifier.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v2 - v3:
- rename irq_routing_notifier into connect_irq_notifier
v1 - v2:
- duly put the notifier in the class and not in the device
---
hw/core/sysbus.c| 6 ++
include/hw/sysbus.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index b53c351..2d22aec 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -109,7 +109,13 @@ qemu_irq sysbus_get_connected_irq(SysBusDevice *dev, int n)
void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
{
+SysBusDeviceClass *sbd = SYS_BUS_DEVICE_GET_CLASS(dev);
+
qdev_connect_gpio_out_named(DEVICE(dev), SYSBUS_DEVICE_GPIO_IRQ, n, irq);
+
+if (sbd-connect_irq_notifier) {
+sbd-connect_irq_notifier(dev, irq);
+}
}
/* Check whether an MMIO region exists */
diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index d1f3f00..e80b26d 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -41,6 +41,7 @@ typedef struct SysBusDeviceClass {
/* public */
int (*init)(SysBusDevice *dev);
+void (*connect_irq_notifier)(SysBusDevice *dev, qemu_irq irq);
} SysBusDeviceClass;
struct SysBusDevice {
--
1.8.3.2
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v14 01/10] linux-headers: update headers according to 4.1-rc1
On 04/29/2015 05:19 PM, Cornelia Huck wrote: On Wed, 29 Apr 2015 15:51:58 +0100 Eric Auger eric.au...@linaro.org wrote: This updates linux-headers against master 4.1-rc1 (commit b787f68c36d49bb1d9236f403813641efa74a031). This includes, among other things, VFIO platform driver and irqfd/arm. Signed-off-by: Eric Auger eric.au...@linaro.org --- v13 - v14: - update to precise 4.1-rc1, precise the commit and change the title v12 - v13: - update for 4.1-rc0 headers v10 - v11: - only includes header modifications related to vfio platform driver v14 and not those related to vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1 Signed-off-by: Eric Auger eric.au...@linaro.org --- include/standard-headers/linux/virtio_balloon.h | 28 +++- include/standard-headers/linux/virtio_blk.h | 8 +- include/standard-headers/linux/virtio_ids.h | 1 + linux-headers/asm-arm/kvm.h | 9 +- linux-headers/asm-arm64/kvm.h | 9 +- linux-headers/asm-mips/kvm.h| 164 +++- linux-headers/asm-s390/kvm.h| 4 + linux-headers/asm-x86/hyperv.h | 2 + linux-headers/linux/kvm.h | 66 +- linux-headers/linux/vfio.h | 2 + 10 files changed, 223 insertions(+), 70 deletions(-) Not trying to be a pain, but have you figured out why the virtio-input header is missing for you? Yep sorry I need to clean my untracked files in my git :-( Eric ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v14 01/10] linux-headers: update headers according to 4.1-rc1
On Wed, 29 Apr 2015 15:51:58 +0100 Eric Auger eric.au...@linaro.org wrote: This updates linux-headers against master 4.1-rc1 (commit b787f68c36d49bb1d9236f403813641efa74a031). This includes, among other things, VFIO platform driver and irqfd/arm. Signed-off-by: Eric Auger eric.au...@linaro.org --- v13 - v14: - update to precise 4.1-rc1, precise the commit and change the title v12 - v13: - update for 4.1-rc0 headers v10 - v11: - only includes header modifications related to vfio platform driver v14 and not those related to vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1 Signed-off-by: Eric Auger eric.au...@linaro.org --- include/standard-headers/linux/virtio_balloon.h | 28 +++- include/standard-headers/linux/virtio_blk.h | 8 +- include/standard-headers/linux/virtio_ids.h | 1 + linux-headers/asm-arm/kvm.h | 9 +- linux-headers/asm-arm64/kvm.h | 9 +- linux-headers/asm-mips/kvm.h| 164 +++- linux-headers/asm-s390/kvm.h| 4 + linux-headers/asm-x86/hyperv.h | 2 + linux-headers/linux/kvm.h | 66 +- linux-headers/linux/vfio.h | 2 + 10 files changed, 223 insertions(+), 70 deletions(-) Not trying to be a pain, but have you figured out why the virtio-input header is missing for you? ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support
Christoffer Dall christoffer.d...@linaro.org writes: On Wed, Apr 29, 2015 at 10:18:18AM +0100, Alex Bennée wrote: Christoffer Dall christoffer.d...@linaro.org writes: On Tue, Apr 28, 2015 at 03:37:01PM +0100, Alex Bennée wrote: Christoffer Dall christoffer.d...@linaro.org writes: On Tue, Apr 28, 2015 at 10:34:12AM +0100, Peter Maydell wrote: On 28 April 2015 at 09:42, Alex Bennée alex.ben...@linaro.org wrote: Peter Maydell peter.mayd...@linaro.org writes: Does the kernel already have a conveniently implemented inject exception into guest lump of code? If so it might be less effort to do it that way round, maybe. snip Certainly there are some cases where the kernel doesn't have all the information. For example it doesn't know if the soft break was inserted by the guest or the host. That to me favours the let userspace deal with the ugly approach. Not sure I follow. If it's an exception for the guest, then that must be because the guest put in the breakpoint instruction, right? No the host can add breakpoint instructions as well. They both generate the same (redirected) exception to the hypervisor which then has to figure out who planted the breakpoint and where the eventual exception will be handled. I understand this; let's just rewind here. If you've concluded that the exception is for the guest, then the guest must have placed the breakpoint instruction there, correct? Otherwise, the exception is for the hypervisor and the discussion about how to inject an exception for the guest is invalid. But only userspace has enough information to make that conclusion (after searching the list of breakpoints it added to the code). So from userspace we can: - re-enter KVM telling it to re-route the exception it just delivered to userspace somehow or - make the changes to deliver the exception in userspace and re-enter KVM as normal. It seems to me if we have already exited into userspace it may as well clean up if it has all the information it needs? Or are you talking about the corner case where the host uses a soft breakpoint to get a breakpoint on an instruction which is also a breakpoint in the guest? I think in this case host debugging just wins. However, that's a separate discussion from that of *how* userspace or the kernel then injects an exception to the guest. By using some QEMU TCG functionality or by QEMU calling back into KVM and asking it to inject an exception for it. I don't know if there is explicit TCG functionality to use but QEMU can set the registers and PC up for exception entry and re-enter KVM. I also understand this. I think Peter's point was exactly that if we have existing code somewhere which we can reuse, then we should consider reusing it. I'm not sure such code exists. The only injection code I know of in KVMs handle_exit code where a +ve return value signals KVM to deliver the exception to the guest. This is used by the hvc and svc handlers after calling kvm_inject_undefined() and the wfx handler which advances the PC first. Again, I don't care particularly which way, I just want the expected working behavior to be clearly defined. I think it makes sense to do it in userspace. I have the kernels inject_fault code for reference for what needs setting up but I'll see if I can find anything in QEMU that already handles this for some other thing (although I don't think it does at first glance). -- Alex Bennée ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
