From ee11f7a8227bcd9cb8d8141fa8f6a0352f7c0c68 Mon Sep 17 00:00:00 2001 From: Gonglei Date: Thu, 3 Apr 2014 13:18:23 +0800 Subject: pci-assign: Fix a bug when map MSI-X table memory failed When mmapping memory for the MSI-X table failsthe dev->msix_table is not set to NULL and assigned_dev_unregister_msix_mmio() will cause a segfault when trying to munmap it. Signed-off-by: Gonglei Arei Reviewed-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini Signed-off-by: Gonglei --- hw/i386/kvm/pci-assign.c | 1 + 1 file changed, 1 insertion(+) (limited to 'hw') diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index e55421a..0572821 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i386/kvm/pci-assign.c @@ -1664,6 +1664,7 @@ static void assigned_dev_register_msix_mmio(AssignedDevice *dev, Error **errp) MAP_ANONYMOUS|MAP_PRIVATE, 0, 0); if (dev->msix_table == MAP_FAILED) { error_setg_errno(errp, errno, "failed to allocate msix_table"); + dev->msix_table = NULL; return; } -- cgit v1.1 From 639973a4740f38789057744b550df3a175bc49ad Mon Sep 17 00:00:00 2001 From: "Michael S. Tsirkin" Date: Mon, 28 Apr 2014 17:02:21 +0300 Subject: pci-assign: limit # of msix vectors KVM only supports MSIX table size up to 256 vectors, but some assigned devices support more vectors, at the moment attempts to assign them fail with EINVAL. Tweak the MSIX capability exposed to guest to limit table size to a supported value. Signed-off-by: Michael S. Tsirkin Tested-by: Gonglei Cc: qemu-stable@nongnu.org Acked-by: Alex Williamson Signed-off-by: Paolo Bonzini --- hw/i386/kvm/pci-assign.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'hw') diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index 0572821..de33657 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i386/kvm/pci-assign.c @@ -1300,6 +1300,7 @@ static int assigned_device_pci_cap_init(PCIDevice *pci_dev, Error **errp) if (pos != 0 && kvm_device_msix_supported(kvm_state)) { int bar_nr; uint32_t msix_table_entry; + uint16_t msix_max; verify_irqchip_in_kernel(&local_err); if (local_err) { @@ -1315,9 +1316,10 @@ static int assigned_device_pci_cap_init(PCIDevice *pci_dev, Error **errp) } pci_dev->msix_cap = pos; - pci_set_word(pci_dev->config + pos + PCI_MSIX_FLAGS, - pci_get_word(pci_dev->config + pos + PCI_MSIX_FLAGS) & - PCI_MSIX_FLAGS_QSIZE); + msix_max = (pci_get_word(pci_dev->config + pos + PCI_MSIX_FLAGS) & + PCI_MSIX_FLAGS_QSIZE) + 1; + msix_max = MIN(msix_max, KVM_MAX_MSIX_PER_DEV); + pci_set_word(pci_dev->config + pos + PCI_MSIX_FLAGS, msix_max - 1); /* Only enable and function mask bits are writable */ pci_set_word(pci_dev->wmask + pos + PCI_MSIX_FLAGS, @@ -1327,9 +1329,7 @@ static int assigned_device_pci_cap_init(PCIDevice *pci_dev, Error **errp) bar_nr = msix_table_entry & PCI_MSIX_FLAGS_BIRMASK; msix_table_entry &= ~PCI_MSIX_FLAGS_BIRMASK; dev->msix_table_addr = pci_region[bar_nr].base_addr + msix_table_entry; - dev->msix_max = pci_get_word(pci_dev->config + pos + PCI_MSIX_FLAGS); - dev->msix_max &= PCI_MSIX_FLAGS_QSIZE; - dev->msix_max += 1; + dev->msix_max = msix_max; } /* Minimal PM support, nothing writable, device appears to NAK changes */ -- cgit v1.1 From 7b4d915e11ae7afb2d42a8cae90db26bc0c142b8 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 19 Mar 2013 14:17:18 +0100 Subject: apic: do not accept SIPI on the bootstrap processor SIPI interrupts are ignored on the bootstrap. Never accept one. Cc: Andreas Faerber Reviewed-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini --- hw/intc/apic_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hw') diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c index 7137653..ce3d903 100644 --- a/hw/intc/apic_common.c +++ b/hw/intc/apic_common.c @@ -200,7 +200,7 @@ void apic_init_reset(DeviceState *dev) s->initial_count = 0; s->initial_count_load_time = 0; s->next_time = 0; - s->wait_for_sipi = 1; + s->wait_for_sipi = !cpu_is_bsp(s->cpu); if (s->timer) { timer_del(s->timer); -- cgit v1.1 From 4700a316df7d2cdcd256dcd64a10cec643f4dfa1 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 5 Mar 2013 15:04:36 +0100 Subject: pc: port 92 reset requires a low->high transition The PIIX datasheet says that "before another INIT pulse can be generated via [port 92h], [bit 0] must be written back to a zero. This bug is masked right now because a full reset will clear the value of port 92h. But once we implement soft reset correctly, the next attempt to enable the A20 line by setting bit 1 (and leaving the others untouched) will cause another reset. Reviewed-by: Anthony Liguori Reviewed-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini --- hw/i386/pc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'hw') diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 07de238..e6369d5 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -471,11 +471,12 @@ static void port92_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { Port92State *s = opaque; + int oldval = s->outport; DPRINTF("port92: write 0x%02x\n", val); s->outport = val; qemu_set_irq(*s->a20_out, (val >> 1) & 1); - if (val & 1) { + if ((val & 1) && !(oldval & 1)) { qemu_system_reset_request(); } } -- cgit v1.1