Re: [PATCH 07/29] nVMX: Hold a vmcs02 for each vmcs12
On 02/03/2011 02:57 PM, Nadav Har'El wrote:
On Sun, Jan 30, 2011, Avi Kivity wrote about Re: [PATCH 07/29] nVMX: Hold a vmcs02
for each vmcs12:
..
+static int nested_create_current_vmcs(struct kvm_vcpu *vcpu)
+{
...
+ if (vmx-nested.vmcs02_num= NESTED_MAX_VMCS)
+ return -ENOMEM;
I asked to replace this by dropping the entire vmcs02_list (or perhaps
just its tail).
Hi, here is a completely rewritten patch.
Now we make no guarantee to keep one vmcs02 for each vmcs12. Rather, we
have a limited pool of vmcs02. If we can find the same vmcs02 that we
previously used for the current vmcs12. Otherwise, we can take any of them
(we take the least recently used) and just use that. Of course, if the
pool is not yet fool, we can also allocate a new vmcs02.
The current default size for the pool is 1, meaning that we just keep one
vmcs02 (per vcpu) for use in any L2, potentially many of them. Because in
this version prepare_vmcs02 each time sets all vmcs02 fields, and doesn't
try to avoid setting rarely modified fields, there's nothing to gain by
trying to start from the previous vmcs02 used to run a certain L2.
In the future, when we do have an optimized prepare_vmcs02 which doesn't
set every field each time, it will make sense to increase the pool size.
Subject: [PATCH 07/29] nVMX: Introduce vmcs02: VMCS used to run L2
We saw in a previous patch that L1 controls its L2 guest with a vcms12.
L0 needs to create a real VMCS for running L2. We call that vmcs02.
A later patch will contain the code, prepare_vmcs02(), for filling the vmcs02
fields. This patch only contains code for allocating vmcs02.
In this version, prepare_vmcs02() sets *all* of vmcs02's fields each time we
enter from L1 to L2, so keeping just one vmcs02 for the vcpu would have
sufficed: It could be reused even when L1 runs multiple L2 guests.
However, in future versions we'll probably want to add an optimization where
vmcs02 fields that rarely change will not be set each time. For that reason
it is beneficial to keep around several vmcs02s of L2 guests that have
recently run, so that potentially we could run these L2s again more quickly
because less vmwrites to vmcs02 will be needed.
This patch adds to each vcpu a vmcs02 pool, vmx-nested.vmcs02_pool,
which remembers the vmcs02s last used to run up to VMCS02_POOL_SIZE L2s.
Because in the current version prepare_vmcs02() sets all vmcs02 fields no
matter what we start with, we choose VMCS02_POOL_SIZE=1. I.e., one vmcs02
is allocated (and loaded onto the processor), and it is reused to enter any
L2 guest. In the future, when prepare_vmcs02() is optimized not to set all
fields every time, VMCS02_POOL_SIZE should be increased.
Thanks, that looks much nicer.
--
error compiling committee.c: too many arguments to function
--
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: Windows 64-bit troubles with user space irqchip
On 02/03/2011 04:15 PM, Gleb Natapov wrote: Maybe this is true for the in-kernel model, but I don't see the issue (anymore) for the way user space works. With patch below I can boot Windows7. diff --git a/hw/apic.c b/hw/apic.c index 146deca..fdcac88 100644 --- a/hw/apic.c +++ b/hw/apic.c @@ -600,7 +600,7 @@ int apic_get_interrupt(DeviceState *d) intno = get_highest_priority_int(s-irr); if (intno 0) return -1; -if (s-tpr intno= s-tpr) +if ((s-tpr 4) (intno 4)= (s-tpr 4)) return s-spurious_vec 0xff; reset_bit(s-irr, intno); set_bit(s-isr, intno); That still allows interrupts that have higher priority than the TPR, but lower priority than interrupts in the ISR to be injected. I think we need to use the PPR here (same as apic_update_irq()). -- error compiling committee.c: too many arguments to function -- 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: Windows 64-bit troubles with user space irqchip
On Sun, Feb 06, 2011 at 12:26:40PM +0200, Avi Kivity wrote: On 02/03/2011 04:15 PM, Gleb Natapov wrote: Maybe this is true for the in-kernel model, but I don't see the issue (anymore) for the way user space works. With patch below I can boot Windows7. diff --git a/hw/apic.c b/hw/apic.c index 146deca..fdcac88 100644 --- a/hw/apic.c +++ b/hw/apic.c @@ -600,7 +600,7 @@ int apic_get_interrupt(DeviceState *d) intno = get_highest_priority_int(s-irr); if (intno 0) return -1; -if (s-tpr intno= s-tpr) +if ((s-tpr 4) (intno 4)= (s-tpr 4)) return s-spurious_vec 0xff; reset_bit(s-irr, intno); set_bit(s-isr, intno); That still allows interrupts that have higher priority than the TPR, but lower priority than interrupts in the ISR to be injected. I think we need to use the PPR here (same as apic_update_irq()). We shouldn't get here if isr is non-empty, but see the patch I posted today to qemu-devel. It does what you say anyway. -- Gleb. -- 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 03/13] AMD IOMMU emulation
On Fri, Feb 04, 2011 at 01:32:57AM +0200, Eduard - Gabriel Munteanu wrote: This introduces emulation for the AMD IOMMU, described in AMD I/O Virtualization Technology (IOMMU) Specification. Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro --- Makefile.target |2 +- hw/amd_iommu.c | 694 +++ hw/pc.c |2 + hw/pci_ids.h|2 + hw/pci_regs.h |1 + 5 files changed, 700 insertions(+), 1 deletions(-) create mode 100644 hw/amd_iommu.c diff --git a/Makefile.target b/Makefile.target index e5817ab..4b650bd 100644 --- a/Makefile.target +++ b/Makefile.target @@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o obj-i386-y += debugcon.o multiboot.o -obj-i386-y += pc_piix.o dma_rw.o +obj-i386-y += pc_piix.o dma_rw.o amd_iommu.o obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o # shared objects diff --git a/hw/amd_iommu.c b/hw/amd_iommu.c new file mode 100644 index 000..6c6346a --- /dev/null +++ b/hw/amd_iommu.c @@ -0,0 +1,694 @@ +/* + * AMD IOMMU emulation + * + * Copyright (c) 2011 Eduard - Gabriel Munteanu + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include pc.h +#include hw.h +#include pci.h +#include qlist.h +#include dma_rw.h + +/* Capability registers */ +#define CAPAB_HEADER0x00 +#define CAPAB_REV_TYPE0x02 +#define CAPAB_FLAGS 0x03 +#define CAPAB_BAR_LOW 0x04 +#define CAPAB_BAR_HIGH 0x08 +#define CAPAB_RANGE 0x0C +#define CAPAB_MISC 0x10 + +#define CAPAB_SIZE 0x14 +#define CAPAB_REG_SIZE 0x04 + +/* Capability header data */ +#define CAPAB_FLAG_IOTLBSUP (1 0) +#define CAPAB_FLAG_HTTUNNEL (1 1) +#define CAPAB_FLAG_NPCACHE (1 2) +#define CAPAB_INIT_REV (1 3) +#define CAPAB_INIT_TYPE 3 +#define CAPAB_INIT_REV_TYPE (CAPAB_REV | CAPAB_TYPE) +#define CAPAB_INIT_FLAGS(CAPAB_FLAG_NPCACHE | CAPAB_FLAG_HTTUNNEL) +#define CAPAB_INIT_MISC (64 15) | (48 8) +#define CAPAB_BAR_MASK ~((1UL 14) - 1) + +/* MMIO registers */ +#define MMIO_DEVICE_TABLE 0x +#define MMIO_COMMAND_BASE 0x0008 +#define MMIO_EVENT_BASE 0x0010 +#define MMIO_CONTROL0x0018 +#define MMIO_EXCL_BASE 0x0020 +#define MMIO_EXCL_LIMIT 0x0028 +#define MMIO_COMMAND_HEAD 0x2000 +#define MMIO_COMMAND_TAIL 0x2008 +#define MMIO_EVENT_HEAD 0x2010 +#define MMIO_EVENT_TAIL 0x2018 +#define MMIO_STATUS 0x2020 + +#define MMIO_SIZE 0x4000 + +#define MMIO_DEVTAB_SIZE_MASK ((1ULL 12) - 1) +#define MMIO_DEVTAB_BASE_MASK (((1ULL 52) - 1) ~MMIO_DEVTAB_SIZE_MASK) +#define MMIO_DEVTAB_ENTRY_SIZE 32 +#define MMIO_DEVTAB_SIZE_UNIT 4096 + +#define MMIO_CMDBUF_SIZE_BYTE (MMIO_COMMAND_BASE + 7) +#define MMIO_CMDBUF_SIZE_MASK 0x0F +#define MMIO_CMDBUF_BASE_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_CMDBUF_DEFAULT_SIZE8 +#define MMIO_CMDBUF_HEAD_MASK (((1ULL 19) - 1) ~0x0F) +#define MMIO_CMDBUF_TAIL_MASK MMIO_EVTLOG_HEAD_MASK + +#define MMIO_EVTLOG_SIZE_BYTE (MMIO_EVENT_BASE + 7) +#define MMIO_EVTLOG_SIZE_MASK MMIO_CMDBUF_SIZE_MASK +#define MMIO_EVTLOG_BASE_MASK MMIO_CMDBUF_BASE_MASK +#define MMIO_EVTLOG_DEFAULT_SIZEMMIO_CMDBUF_DEFAULT_SIZE +#define MMIO_EVTLOG_HEAD_MASK (((1ULL 19) - 1) ~0x0F) +#define MMIO_EVTLOG_TAIL_MASK MMIO_EVTLOG_HEAD_MASK + +#define MMIO_EXCL_BASE_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_EXCL_ENABLED_MASK (1ULL 0) +#define MMIO_EXCL_ALLOW_MASK(1ULL 1) +#define
Re: [PATCH 01/13] Generic DMA memory access interface
On Fri, Feb 04, 2011 at 01:32:55AM +0200, Eduard - Gabriel Munteanu wrote:
This introduces replacements for memory access functions like
cpu_physical_memory_read(). The new interface can handle address
translation and access checking through an IOMMU.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
Makefile.target |2 +-
hw/dma_rw.c | 124 +++
hw/dma_rw.h | 157
+++
3 files changed, 282 insertions(+), 1 deletions(-)
create mode 100644 hw/dma_rw.c
create mode 100644 hw/dma_rw.h
diff --git a/Makefile.target b/Makefile.target
index e15b1c4..e5817ab 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o
obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
obj-i386-y += debugcon.o multiboot.o
-obj-i386-y += pc_piix.o
+obj-i386-y += pc_piix.o dma_rw.o
obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
# shared objects
diff --git a/hw/dma_rw.c b/hw/dma_rw.c
new file mode 100644
index 000..ef8e7f8
--- /dev/null
+++ b/hw/dma_rw.c
@@ -0,0 +1,124 @@
+/*
+ * Generic DMA memory access interface.
+ *
+ * Copyright (c) 2011 Eduard - Gabriel Munteanu
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include dma_rw.h
+#include range.h
+
+static void dma_register_memory_map(DMADevice *dev,
+dma_addr_t addr,
+dma_addr_t len,
+target_phys_addr_t paddr,
+DMAInvalidateMapFunc *invalidate,
+void *invalidate_opaque)
+{
+DMAMemoryMap *map;
+
+map = qemu_malloc(sizeof(DMAMemoryMap));
+map-addr = addr;
+map-len= len;
+map-paddr = paddr;
+map-invalidate = invalidate;
+map-invalidate_opaque = invalidate_opaque;
+
+QLIST_INSERT_HEAD(dev-mmu-memory_maps, map, list);
+}
+
+static void dma_unregister_memory_map(DMADevice *dev,
+ target_phys_addr_t paddr,
+ dma_addr_t len)
+{
+DMAMemoryMap *map;
+
+QLIST_FOREACH(map, dev-mmu-memory_maps, list) {
+if (map-paddr == paddr map-len == len) {
+QLIST_REMOVE(map, list);
+free(map);
+}
+}
+}
+
+void dma_invalidate_memory_range(DMADevice *dev,
+ dma_addr_t addr,
+ dma_addr_t len)
+{
+DMAMemoryMap *map;
+
+QLIST_FOREACH(map, dev-mmu-memory_maps, list) {
+if (ranges_overlap(addr, len, map-addr, map-len)) {
+map-invalidate(map-invalidate_opaque);
+QLIST_REMOVE(map, list);
+free(map);
+}
+}
+}
+
+void *dma_memory_map(DMADevice *dev,
+ DMAInvalidateMapFunc *cb,
+ void *opaque,
+ dma_addr_t addr,
+ dma_addr_t *len,
+ int is_write)
+{
+int err;
+target_phys_addr_t paddr, plen;
+
+if (!dev || !dev-mmu) {
+return cpu_physical_memory_map(addr, len, is_write);
+}
+
+plen = *len;
+err = dev-mmu-translate(dev, addr, paddr, plen, is_write);
+if (err) {
+return NULL;
+}
+
+/*
+ * If this is true, the virtual region is contiguous,
+ * but the translated physical region isn't. We just
+ * clamp *len, much like cpu_physical_memory_map() does.
+ */
+if (plen *len) {
+*len = plen;
+}
+
+/* We treat maps as remote TLBs to cope with stuff like AIO. */
+if (cb) {
+
Re: [PATCH 04/13] ide: use the DMA memory access interface for PCI IDE controllers
On Fri, Feb 04, 2011 at 01:32:58AM +0200, Eduard - Gabriel Munteanu wrote:
Emulated PCI IDE controllers now use the memory access interface. This
also allows an emulated IOMMU to translate and check accesses.
Map invalidation results in cancelling DMA transfers. Since the guest OS
can't properly recover the DMA results in case the mapping is changed,
this is a fairly good approximation.
Note this doesn't handle AHCI emulation yet!
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
How about not changing ahci then, and failing initialization
if an mmu is present?
---
dma-helpers.c | 23 ++-
dma.h |4 +++-
hw/ide/ahci.c |3 ++-
hw/ide/internal.h |1 +
hw/ide/macio.c|4 ++--
hw/ide/pci.c | 18 +++---
6 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/dma-helpers.c b/dma-helpers.c
index 712ed89..29a74a4 100644
--- a/dma-helpers.c
+++ b/dma-helpers.c
@@ -10,12 +10,13 @@
#include dma.h
#include block_int.h
-void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint)
+void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint, DMADevice *dma)
{
qsg-sg = qemu_malloc(alloc_hint * sizeof(ScatterGatherEntry));
qsg-nsg = 0;
qsg-nalloc = alloc_hint;
qsg-size = 0;
+qsg-dma = dma;
}
void qemu_sglist_add(QEMUSGList *qsg, target_phys_addr_t base,
@@ -73,12 +74,23 @@ static void dma_bdrv_unmap(DMAAIOCB *dbs)
int i;
for (i = 0; i dbs-iov.niov; ++i) {
-cpu_physical_memory_unmap(dbs-iov.iov[i].iov_base,
- dbs-iov.iov[i].iov_len, !dbs-is_write,
- dbs-iov.iov[i].iov_len);
+dma_memory_unmap(dbs-sg-dma,
+ dbs-iov.iov[i].iov_base,
+ dbs-iov.iov[i].iov_len, !dbs-is_write,
+ dbs-iov.iov[i].iov_len);
}
}
+static void dma_bdrv_cancel(void *opaque)
+{
+DMAAIOCB *dbs = opaque;
+
+bdrv_aio_cancel(dbs-acb);
+dma_bdrv_unmap(dbs);
+qemu_iovec_destroy(dbs-iov);
+qemu_aio_release(dbs);
+}
+
static void dma_bdrv_cb(void *opaque, int ret)
{
DMAAIOCB *dbs = (DMAAIOCB *)opaque;
@@ -100,7 +112,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
while (dbs-sg_cur_index dbs-sg-nsg) {
cur_addr = dbs-sg-sg[dbs-sg_cur_index].base + dbs-sg_cur_byte;
cur_len = dbs-sg-sg[dbs-sg_cur_index].len - dbs-sg_cur_byte;
-mem = cpu_physical_memory_map(cur_addr, cur_len, !dbs-is_write);
+mem = dma_memory_map(dbs-sg-dma, dma_bdrv_cancel, dbs,
+ cur_addr, cur_len, !dbs-is_write);
if (!mem)
break;
qemu_iovec_add(dbs-iov, mem, cur_len);
diff --git a/dma.h b/dma.h
index f3bb275..2417b32 100644
--- a/dma.h
+++ b/dma.h
@@ -14,6 +14,7 @@
//#include cpu.h
#include hw/hw.h
#include block.h
+#include hw/dma_rw.h
typedef struct {
target_phys_addr_t base;
@@ -25,9 +26,10 @@ typedef struct {
int nsg;
int nalloc;
target_phys_addr_t size;
+DMADevice *dma;
} QEMUSGList;
-void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint);
+void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint, DMADevice *dma);
void qemu_sglist_add(QEMUSGList *qsg, target_phys_addr_t base,
target_phys_addr_t len);
void qemu_sglist_destroy(QEMUSGList *qsg);
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 968fdce..aea06a9 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -993,7 +993,8 @@ static int ahci_populate_sglist(AHCIDevice *ad,
QEMUSGList *sglist)
if (sglist_alloc_hint 0) {
AHCI_SG *tbl = (AHCI_SG *)prdt;
-qemu_sglist_init(sglist, sglist_alloc_hint);
+/* FIXME: pass a proper DMADevice. */
+qemu_sglist_init(sglist, sglist_alloc_hint, NULL);
for (i = 0; i sglist_alloc_hint; i++) {
/* flags_size is zero-based */
qemu_sglist_add(sglist, le64_to_cpu(tbl[i].addr),
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index 697c3b4..3d3d5db 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -468,6 +468,7 @@ struct IDEDMA {
struct iovec iov;
QEMUIOVector qiov;
BlockDriverAIOCB *aiocb;
+DMADevice *dev;
};
struct IDEBus {
diff --git a/hw/ide/macio.c b/hw/ide/macio.c
index c1b4caa..654ae7c 100644
--- a/hw/ide/macio.c
+++ b/hw/ide/macio.c
@@ -79,7 +79,7 @@ static void pmac_ide_atapi_transfer_cb(void *opaque, int
ret)
s-io_buffer_size = io-len;
-qemu_sglist_init(s-sg, io-len / MACIO_PAGE_SIZE + 1);
+qemu_sglist_init(s-sg, io-len / MACIO_PAGE_SIZE + 1, NULL);
qemu_sglist_add(s-sg, io-addr, io-len);
io-addr += io-len;
io-len = 0;
@@ -141,7 +141,7 @@ static void pmac_ide_transfer_cb(void *opaque, int ret)
s-io_buffer_index = 0;
s-io_buffer_size =
Re: [PATCH 01/13] Generic DMA memory access interface
On Fri, Feb 04, 2011 at 01:32:55AM +0200, Eduard - Gabriel Munteanu wrote:
This introduces replacements for memory access functions like
cpu_physical_memory_read(). The new interface can handle address
translation and access checking through an IOMMU.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
Makefile.target |2 +-
hw/dma_rw.c | 124 +++
hw/dma_rw.h | 157
+++
3 files changed, 282 insertions(+), 1 deletions(-)
create mode 100644 hw/dma_rw.c
create mode 100644 hw/dma_rw.h
diff --git a/Makefile.target b/Makefile.target
index e15b1c4..e5817ab 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o
obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
obj-i386-y += debugcon.o multiboot.o
-obj-i386-y += pc_piix.o
+obj-i386-y += pc_piix.o dma_rw.o
Does this need to be target specific?
obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
# shared objects
diff --git a/hw/dma_rw.c b/hw/dma_rw.c
new file mode 100644
index 000..ef8e7f8
--- /dev/null
+++ b/hw/dma_rw.c
@@ -0,0 +1,124 @@
+/*
+ * Generic DMA memory access interface.
+ *
+ * Copyright (c) 2011 Eduard - Gabriel Munteanu
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include dma_rw.h
+#include range.h
+
+static void dma_register_memory_map(DMADevice *dev,
+dma_addr_t addr,
+dma_addr_t len,
+target_phys_addr_t paddr,
+DMAInvalidateMapFunc *invalidate,
+void *invalidate_opaque)
+{
+DMAMemoryMap *map;
+
+map = qemu_malloc(sizeof(DMAMemoryMap));
+map-addr = addr;
+map-len= len;
+map-paddr = paddr;
+map-invalidate = invalidate;
+map-invalidate_opaque = invalidate_opaque;
+
+QLIST_INSERT_HEAD(dev-mmu-memory_maps, map, list);
+}
+
+static void dma_unregister_memory_map(DMADevice *dev,
+ target_phys_addr_t paddr,
+ dma_addr_t len)
+{
+DMAMemoryMap *map;
+
+QLIST_FOREACH(map, dev-mmu-memory_maps, list) {
+if (map-paddr == paddr map-len == len) {
+QLIST_REMOVE(map, list);
+free(map);
+}
+}
+}
+
+void dma_invalidate_memory_range(DMADevice *dev,
+ dma_addr_t addr,
+ dma_addr_t len)
+{
+DMAMemoryMap *map;
+
+QLIST_FOREACH(map, dev-mmu-memory_maps, list) {
+if (ranges_overlap(addr, len, map-addr, map-len)) {
+map-invalidate(map-invalidate_opaque);
+QLIST_REMOVE(map, list);
+free(map);
+}
+}
+}
+
+void *dma_memory_map(DMADevice *dev,
+ DMAInvalidateMapFunc *cb,
+ void *opaque,
+ dma_addr_t addr,
+ dma_addr_t *len,
+ int is_write)
+{
+int err;
+target_phys_addr_t paddr, plen;
+
+if (!dev || !dev-mmu) {
+return cpu_physical_memory_map(addr, len, is_write);
+}
+
+plen = *len;
+err = dev-mmu-translate(dev, addr, paddr, plen, is_write);
+if (err) {
+return NULL;
+}
+
+/*
+ * If this is true, the virtual region is contiguous,
+ * but the translated physical region isn't. We just
+ * clamp *len, much like cpu_physical_memory_map() does.
+ */
+if (plen *len) {
+*len = plen;
+}
+
+/* We treat maps as remote TLBs to cope
Re: [PATCH 2/3] AMD IOMMU support
On Fri, Feb 04, 2011 at 01:24:14AM +0200, Eduard - Gabriel Munteanu wrote:
This initializes the AMD IOMMU and creates ACPI tables for it.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
src/acpi.c | 84
src/config.h |3 ++
src/pci_ids.h |1 +
src/pci_regs.h |1 +
src/pciinit.c | 29 +++
5 files changed, 118 insertions(+), 0 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 18830dc..fca152c 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -196,6 +196,36 @@ struct srat_memory_affinity
u32reserved3[2];
} PACKED;
+/*
+ * IVRS (I/O Virtualization Reporting Structure) table.
+ *
+ * Describes the AMD IOMMU, as per:
+ * AMD I/O Virtualization Technology (IOMMU) Specification, rev 1.26
+ */
+
+struct ivrs_ivhd
+{
+u8type;
+u8flags;
+u16 length;
+u16 devid;
+u16 capab_off;
+u32 iommu_base_low;
+u32 iommu_base_high;
+u16 pci_seg_group;
+u16 iommu_info;
+u32 reserved;
+u8entry[0];
+} PACKED;
+
+struct ivrs_table
+{
+ACPI_TABLE_HEADER_DEF/* ACPI common table header. */
+u32iv_info;
+u32reserved[2];
+struct ivrs_ivhd ivhd;
+} PACKED;
+
prefix with amd_iommu_ or amd_ then ?
#include acpi-dsdt.hex
static void
@@ -579,6 +609,59 @@ build_srat(void)
return srat;
}
+#define IVRS_SIGNATURE 0x53525649 // IVRS
+#define IVRS_MAX_DEVS 32
+static void *
+build_ivrs(void)
+{
+int iommu_bdf, iommu_cap;
+int bdf, max, i;
+struct ivrs_table *ivrs;
+struct ivrs_ivhd *ivhd;
+
+/* Note this currently works for a single IOMMU! */
Meant to be a FIXME?
How hard is it to fix? Just stick this in a loop?
+iommu_bdf = pci_find_class(PCI_CLASS_SYSTEM_IOMMU);
+if (iommu_bdf 0)
+return NULL;
+iommu_cap = pci_find_capability(iommu_bdf, PCI_CAP_ID_SEC);
+if (iommu_cap 0)
+return NULL;
+
+ivrs = malloc_high(sizeof(struct ivrs_table) + 4 * IVRS_MAX_DEVS);
+ivrs-iv_info = pci_config_readw(iommu_bdf, iommu_cap + 0x12) ~0x000F;
+
+ivhd = ivrs-ivhd;
+ivhd-type = 0x10;
+ivhd-flags = 0;
+ivhd-length= sizeof(struct ivrs_ivhd);
+ivhd-devid = iommu_bdf;
+ivhd-capab_off = iommu_cap;
+ivhd-iommu_base_low= pci_config_readl(iommu_bdf, iommu_cap + 0x04)
+ 0xFFFE;
+ivhd-iommu_base_high = pci_config_readl(iommu_bdf, iommu_cap + 0x08);
+ivhd-pci_seg_group = 0;
+ivhd-iommu_info= 0;
+ivhd-reserved = 0;
+
+i = 0;
+foreachpci(bdf, max) {
+if (bdf == ivhd-devid)
+continue;
+ivhd-entry[4 * i + 0] = 2;
+ivhd-entry[4 * i + 1] = bdf 0xFF;
+ivhd-entry[4 * i + 2] = (bdf 8) 0xFF;
+ivhd-entry[4 * i + 3] = ~(1 3);
+ivhd-length += 4;
+if (++i = IVRS_MAX_DEVS)
+break;
+}
+
+build_header((void *) ivrs, IVRS_SIGNATURE,
+ sizeof(struct ivrs_table) + 4 * i, 1);
+
+return ivrs;
+}
+
static const struct pci_device_id acpi_find_tbl[] = {
/* PIIX4 Power Management device. */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, NULL),
@@ -625,6 +708,7 @@ acpi_bios_init(void)
ACPI_INIT_TABLE(build_madt());
ACPI_INIT_TABLE(build_hpet());
ACPI_INIT_TABLE(build_srat());
+ACPI_INIT_TABLE(build_ivrs());
u16 i, external_tables = qemu_cfg_acpi_additional_tables();
diff --git a/src/config.h b/src/config.h
index 6356941..0ba5723 100644
--- a/src/config.h
+++ b/src/config.h
@@ -172,6 +172,9 @@
#define BUILD_APIC_ADDR 0xfee0
#define BUILD_IOAPIC_ADDR 0xfec0
+#define BUILD_AMD_IOMMU_START 0xfed0
+#define BUILD_AMD_IOMMU_END 0xfee0/* BUILD_APIC_ADDR */
+
#define BUILD_SMM_INIT_ADDR 0x38000
#define BUILD_SMM_ADDR0xa8000
#define BUILD_SMM_SIZE0x8000
diff --git a/src/pci_ids.h b/src/pci_ids.h
index e1cded2..3cc3c6e 100644
--- a/src/pci_ids.h
+++ b/src/pci_ids.h
@@ -72,6 +72,7 @@
#define PCI_CLASS_SYSTEM_RTC 0x0803
#define PCI_CLASS_SYSTEM_PCI_HOTPLUG 0x0804
#define PCI_CLASS_SYSTEM_SDHCI 0x0805
+#define PCI_CLASS_SYSTEM_IOMMU 0x0806
#define PCI_CLASS_SYSTEM_OTHER 0x0880
#define PCI_BASE_CLASS_INPUT 0x09
diff --git a/src/pci_regs.h b/src/pci_regs.h
index e5effd4..bfac824 100644
--- a/src/pci_regs.h
+++ b/src/pci_regs.h
@@ -208,6 +208,7 @@
#define PCI_CAP_ID_SHPC 0x0C/* PCI Standard Hot-Plug Controller */
#define PCI_CAP_ID_SSVID0x0D/* Bridge subsystem vendor/device ID */
#define PCI_CAP_ID_AGP3 0x0E/* AGP Target
Re: [PATCH 2/3] AMD IOMMU support
On Sun, Feb 06, 2011 at 01:47:57PM +0200, Michael S. Tsirkin wrote:
On Fri, Feb 04, 2011 at 01:24:14AM +0200, Eduard - Gabriel Munteanu wrote:
Hi,
[snip]
+/*
+ * IVRS (I/O Virtualization Reporting Structure) table.
+ *
+ * Describes the AMD IOMMU, as per:
+ * AMD I/O Virtualization Technology (IOMMU) Specification, rev 1.26
+ */
+
+struct ivrs_ivhd
+{
+u8type;
+u8flags;
+u16 length;
+u16 devid;
+u16 capab_off;
+u32 iommu_base_low;
+u32 iommu_base_high;
+u16 pci_seg_group;
+u16 iommu_info;
+u32 reserved;
+u8entry[0];
+} PACKED;
+
+struct ivrs_table
+{
+ACPI_TABLE_HEADER_DEF/* ACPI common table header. */
+u32iv_info;
+u32reserved[2];
+struct ivrs_ivhd ivhd;
+} PACKED;
+
prefix with amd_iommu_ or amd_ then ?
This should be standard nomenclature already, even if IVRS is AMD
IOMMU-specific.
#include acpi-dsdt.hex
static void
@@ -579,6 +609,59 @@ build_srat(void)
return srat;
}
+#define IVRS_SIGNATURE 0x53525649 // IVRS
+#define IVRS_MAX_DEVS 32
+static void *
+build_ivrs(void)
+{
+int iommu_bdf, iommu_cap;
+int bdf, max, i;
+struct ivrs_table *ivrs;
+struct ivrs_ivhd *ivhd;
+
+/* Note this currently works for a single IOMMU! */
Meant to be a FIXME?
How hard is it to fix? Just stick this in a loop?
I suspect a real BIOS would have these values hardcoded anyway,
according to the topology of the PCI bus and which IOMMUs sit where. You
already mentioned the possibility of multiple IOMMU capabilities in the
same function/bus, in which case there's probably no easy way to guess
it from SeaBIOS.
[snip]
+static void amd_iommu_init(u16 bdf, void *arg)
+{
+int cap;
+u32 base_addr;
+
+cap = pci_find_capability(bdf, PCI_CAP_ID_SEC);
+if (cap 0) {
+return;
+}
There actually can be multiple instances of this
capability according to spec.
Do we care?
Hm, perhaps we should at least assign a base address there, that's easy.
As for QEMU/KVM usage we probably don't need it.
+
+if (amd_iommu_addr = BUILD_AMD_IOMMU_END) {
+return;
+}
+base_addr = amd_iommu_addr;
+amd_iommu_addr += 0x4000;
+
+pci_config_writel(bdf, cap + 0x0C, 0);
+pci_config_writel(bdf, cap + 0x08, 0);
+pci_config_writel(bdf, cap + 0x04, base_addr | 1);
+}
+
static const struct pci_device_id pci_class_tbl[] = {
/* STORAGE IDE */
PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_1,
@@ -279,6 +302,10 @@ static const struct pci_device_id pci_class_tbl[] = {
PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_BRIDGE_PCI,
pci_bios_init_device_bridge),
+/* AMD IOMMU */
Makes sense to limit to AMD vendor id?
I don't think so, I assume any PCI_CLASS_SYSTEM_IOMMU device would
implement the same specification, considering these ids have been
assigned by PCI-SIG.
+PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_SYSTEM_IOMMU,
+ amd_iommu_init),
+
/* default */
PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID, pci_bios_allocate_regions),
@@ -408,6 +435,8 @@ pci_setup(void)
pci_region_init(pci_bios_prefmem_region,
BUILD_PCIPREFMEM_START, BUILD_PCIPREFMEM_END - 1);
+amd_iommu_addr = BUILD_AMD_IOMMU_START;
+
pci_bios_init_bus();
int bdf, max;
--
1.7.3.4
Thanks for your review, I read your other comments and will resubmit
once I fix those issues.
Eduard
--
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 2/3] AMD IOMMU support
On Sun, Feb 06, 2011 at 03:41:45PM +0200, Eduard - Gabriel Munteanu wrote:
On Sun, Feb 06, 2011 at 01:47:57PM +0200, Michael S. Tsirkin wrote:
On Fri, Feb 04, 2011 at 01:24:14AM +0200, Eduard - Gabriel Munteanu wrote:
Hi,
[snip]
+/*
+ * IVRS (I/O Virtualization Reporting Structure) table.
+ *
+ * Describes the AMD IOMMU, as per:
+ * AMD I/O Virtualization Technology (IOMMU) Specification, rev 1.26
+ */
+
+struct ivrs_ivhd
+{
+u8type;
+u8flags;
+u16 length;
+u16 devid;
+u16 capab_off;
+u32 iommu_base_low;
+u32 iommu_base_high;
+u16 pci_seg_group;
+u16 iommu_info;
+u32 reserved;
+u8entry[0];
+} PACKED;
+
+struct ivrs_table
+{
+ACPI_TABLE_HEADER_DEF/* ACPI common table header. */
+u32iv_info;
+u32reserved[2];
+struct ivrs_ivhd ivhd;
+} PACKED;
+
prefix with amd_iommu_ or amd_ then ?
This should be standard nomenclature already, even if IVRS is AMD
IOMMU-specific.
Yes but the specific structure is amd specific, isn't it?
#include acpi-dsdt.hex
static void
@@ -579,6 +609,59 @@ build_srat(void)
return srat;
}
+#define IVRS_SIGNATURE 0x53525649 // IVRS
+#define IVRS_MAX_DEVS 32
+static void *
+build_ivrs(void)
+{
+int iommu_bdf, iommu_cap;
+int bdf, max, i;
+struct ivrs_table *ivrs;
+struct ivrs_ivhd *ivhd;
+
+/* Note this currently works for a single IOMMU! */
Meant to be a FIXME?
How hard is it to fix? Just stick this in a loop?
I suspect a real BIOS would have these values hardcoded anyway,
according to the topology of the PCI bus and which IOMMUs sit where.
Which values exactly?
You
already mentioned the possibility of multiple IOMMU capabilities in the
same function/bus, in which case there's probably no easy way to guess
it from SeaBIOS.
It's easy enough to enumerate capabilities and pci devices, isn't it?
[snip]
+static void amd_iommu_init(u16 bdf, void *arg)
+{
+int cap;
+u32 base_addr;
+
+cap = pci_find_capability(bdf, PCI_CAP_ID_SEC);
+if (cap 0) {
+return;
+}
There actually can be multiple instances of this
capability according to spec.
Do we care?
Hm, perhaps we should at least assign a base address there, that's easy.
As for QEMU/KVM usage we probably don't need it.
I expect assigning multiple domains will be useful.
I'm guessing multiple devices is what systems have
in this case? If so I'm not really sure why is there need
for multiple iommu capabilities per device.
+
+if (amd_iommu_addr = BUILD_AMD_IOMMU_END) {
+return;
+}
+base_addr = amd_iommu_addr;
+amd_iommu_addr += 0x4000;
+
+pci_config_writel(bdf, cap + 0x0C, 0);
+pci_config_writel(bdf, cap + 0x08, 0);
+pci_config_writel(bdf, cap + 0x04, base_addr | 1);
+}
+
static const struct pci_device_id pci_class_tbl[] = {
/* STORAGE IDE */
PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_1,
@@ -279,6 +302,10 @@ static const struct pci_device_id pci_class_tbl[] = {
PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_BRIDGE_PCI,
pci_bios_init_device_bridge),
+/* AMD IOMMU */
Makes sense to limit to AMD vendor id?
I don't think so, I assume any PCI_CLASS_SYSTEM_IOMMU device would
implement the same specification, considering these ids have been
assigned by PCI-SIG.
This hasn't been the case in the past, e.g. with
PCI_CLASS_NETWORK_ETHERNET, so I see no reason to assume
it here.
+PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_SYSTEM_IOMMU,
+ amd_iommu_init),
+
/* default */
PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID, pci_bios_allocate_regions),
@@ -408,6 +435,8 @@ pci_setup(void)
pci_region_init(pci_bios_prefmem_region,
BUILD_PCIPREFMEM_START, BUILD_PCIPREFMEM_END - 1);
+amd_iommu_addr = BUILD_AMD_IOMMU_START;
+
pci_bios_init_bus();
int bdf, max;
--
1.7.3.4
Thanks for your review, I read your other comments and will resubmit
once I fix those issues.
Eduard
--
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: [SeaBIOS] IO APIC emulation failure with qemu-kvm
On 02/04/2011 03:58 PM, Jan Kiszka wrote: when i run my kernel image with qemu-kvm it gives emulation error failure trying to execute the code outside ROM or RAM at fec0(IO APIC base address) but the same code runs fine with qemu. can anyone please point me where might be the problem or how to find out this one? Please post the error message. Start with capturing the activity of you guest via ftrace, enabling all kvm:* events. You may also try to attach gdb to qemu and analyze the different code path in both versions (specifically if you have debugging symbols for your guest). The easy way to do that is trace-cmd (http://lwn.net/Articles/341902/): $ trace-cmd record -e kvm -b 2 ... ^C $ trace-cmd report -- error compiling committee.c: too many arguments to function -- 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
[Bug 28402] New: MacOSX guest has SMP problem without -kvm-irqchip option
https://bugzilla.kernel.org/show_bug.cgi?id=28402 Summary: MacOSX guest has SMP problem without -kvm-irqchip option Product: Virtualization Version: unspecified Kernel Version: 2.6.38-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm AssignedTo: virtualization_...@kernel-bugs.osdl.org ReportedBy: spamjunkea...@gmail.com Regression: No Created an attachment (id=46652) -- (https://bugzilla.kernel.org/attachment.cgi?id=46652) MacOSX guest cannot boot SMP without -kvm-irqchip Problem : On MacOSX SMP guest, got Error message and lock on boot( with -v option) There is no problem with single core and could boot without -kvm-irqchip. Failed to start CPU 01, rebooting... CPU halted. Screenshot attached. The command I use to launch the vm is: qemu-kvm -hda ./MacOSX.vdi -net nic,vlan=0,model=rtl8139 -net user,vlan=0,hostname=emu -boot c -smp 4 The problem appearing with -no-kvm-pit. The problem stops appearing with -no-kvm-irqchip. The problem stops appearing with -no-kvm switch. (offcourse) Software: Host:OpenSUSE 11.3 with Vanilla 2.6.38-rc3/AMD64, Guest: MacOSX 10.6.0 KVM: QEMU emulator version 0.14.50 (kvm-0.14.0.rc0-69.1) (From OpenSUSE repos) Hardware configuration: AMD Phenom II x4 2.6 Ghz. Biostar 790GX A2+ 4GB DDR2 PC800 RAM -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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
[Bug 28412] New: MacOSX guest has Ethernet card problem without -kvm-irqchip option
https://bugzilla.kernel.org/show_bug.cgi?id=28412 Summary: MacOSX guest has Ethernet card problem without -kvm-irqchip option Product: Virtualization Version: unspecified Kernel Version: 2.6.38-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm AssignedTo: virtualization_...@kernel-bugs.osdl.org ReportedBy: spamjunkea...@gmail.com Regression: No Problem : On MacOSX Ethernet connection has problems when KVM used. MacOSX guest cannot communicate without -kvm-irqchip option. Os recognizes Ethernet card properly but cannot communicate with host, cannot get IP (like 10.0.2.15 from qemu), etc. The command I use to launch the vm is: qemu-kvm -hda ./MacOSX.vdi The problem also appearing with -no-kvm-pit. The problem stops appearing with -no-kvm-irqchip and -no-kvm. Software: Host:OpenSUSE 11.3 with Vanilla 2.6.38-rc3/AMD64, Guest: MacOSX 10.6.0 KVM: QEMU emulator version 0.14.50 (kvm-0.14.0.rc0-69.1) (From OpenSUSE repos) Hardware configuration: AMD Phenom II x4 2.6 Ghz. Biostar 790GX A2+ 4GB DDR2 PC800 RAM -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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
buildbot failure in kvm on ppc64
The Buildbot has detected a new failure of ppc64 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/ppc64/builds/85 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
[regression] KVM: hangs and irq timeout booting HURD unless -no-kvm-irqchip passed
Hi kvm-ers,
When I boot the HURD with
kvm -m 768 -net nic,model=ne2k_pci -net user hurd-installed.qemu
it hangs and eventually produces two messages:
hd0: unexpected_intr: status=0x58 { DriveReady SeekComplete DataRequest
}
hd0: irq timeout: status=0x58 { DriveReady Seek Complete DataRequest }
More details below[1].
Adding -no-kvm-irqchip to the kvm command line fixes it --- no
more hangs or confusing messages (thanks, Guillem!).
Bisects (thanks to Michael for the idea) to
v2.6.37-rc1~142^2~39 (KVM: Check for pending events before
attempting injection, 2010-07-27).
Bisection log and kernel configuration available upon request (but
probably not too relevant --- the 2.6.37 distro kernel from Debian
exhibits the same problem). Reproducible with kvm/master (2d4b4d26,
2011-02-01).
CPU is a dual-core AMD Athlon II P360, family 16, model 6.
Any hints for tracking this down? For those wanting to follow along
at home, you can find a HURD cd to try at [2].
Thanks for kvm --- now that I have hardware that can handle it, it's
become a favorite toy. :)
Jonathan
[1] Background: http://bugs.debian.org/612105
Result:
1. Normal boot procedure. Eventually the following message from HURD
is on the console:
start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec
2. Hang. I hit ctrl+alt, info registers, and so on in the hope of
waking it up. Eventually...
3. A flood of repeated
kb_setleds1: unexpected state (1)
messages.
4. Another message and another hang:
hd0: unexpected_intr: status=0x58 { DriveReady SeekComplete DataRequest
}
hd0: irq timeout: status=0x58 { DriveReady Seek Complete DataRequest }
(the two messages overlap sometimes).
[2] http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
--
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
