Re: [Qemu-devel] KVM/QEMU: Support executing from flash device
On Sat, Mar 03, 2012 at 10:56:02PM -0800, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. Do you want to execute code from a flash while it traps on read/exec? KVM emulator can't do that. 3. qemu should be able to then restore the region to the initial state. Here is my plan: 1. Add KVM_CAP_REGION_WRITE_TRAP 2. Add kvm_memory_region::flags KVM_MEMSLOT_TRAP_WRITES 3. Update page table creation to trap on writes when KVM_MEMSLOT_TRAP_WRITES is set Is this plan heading in the right direction? Regarding emulating ROM (as you mentioned above): I think that it can trap to qemu and QEMU can ignore it. This would be a performance hit, but I don't think it is expected that lots of writes to a ROM will occur. Do you agree? -Jordan -- Gleb.
Re: [Qemu-devel] BlockDriverState stack and BlockListeners
Il 04/03/2012 06:14, Ori Mamluk ha scritto: I prefer not to do it as NBD server, mainly because NBD by definition requires a port per volume and I think it will pose a management overhead. NBD supports multiple volumes on the same server, just not the implementation in QEMU. Also you could use a different negotiation but still the same request format, which would let you share some code. Paolo
[Qemu-devel] [PATCH] make: remove generated objects from target dirs
I ended up with qmp-commands.h in target directories, which makes build fail as it is found before the main header. make clean fixes it, but it might get triggered again when we make some header target-independent next. It's easy to just make sure all such leftovers are removed, so let's do this. Signed-off-by: Michael S. Tsirkin m...@redhat.com diff --git a/Makefile b/Makefile index e66e885..958a414 100644 --- a/Makefile +++ b/Makefile @@ -89,6 +89,7 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) subdir-%: $(GENERATED_HEADERS) + $(call quiet-command,rm -f $(foreach header, $(GENERATED_HEADERS), $*/$(header)),) $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V=$(V) TARGET_DIR=$*/ all,) ifneq ($(wildcard config-host.mak),)
Re: [Qemu-devel] SPARC64: unable to boot OpenBIOS from git master
On Sat, Mar 03, 2012 at 03:09:16PM +, Blue Swirl wrote: On Mon, Feb 27, 2012 at 06:36, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote: Hi all, I've been experimenting with SPARC64 under QEMU, and with current git master I am unable to boot OpenBIOS at all with the following error: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19d84 NPC = 0xffd19d88 Stopping execution Using git bisect indicates that the problem lies with the following commit: commit d5f27e88699f14c802d66c01de70e5ea37b7153a Author: Michael S. Tsirkin m...@redhat.com Date: Tue Feb 21 15:57:58 2012 +0200 pci: set memory type for memory behind the bridge As we make upper bits in IO and prefetcheable memory registers writeable, we should declare support for 64 bit prefetcheable memory and 32 bit io in the bridge. This changes the default for apb, dec, but I'm guessing they got the defaults wrong by accident. Alternatively, we could let bridges declare lack of 64 bit support and make the upper bits read-only zero. With this applied, we can drop these bits from express code. Reported-by: Gerd Hoffmann kra...@redhat.com Signed-off-by: Michael S. Tsirkin m...@redhat.com Could someone familiar with apb,dec ack this please? Signed-off-by: Anthony Liguori aligu...@us.ibm.com Does anyone have an idea as to whether this is something that needs to be fixed in QEMU or OpenBIOS? No idea. Michael, should the commit be reverted? It's easy to confirm the bug, just run qemu-system-sparc64 without any arguments. Bug: black screen, no bug: yellow screen with OpenBIOS boot text. In fact, it's pretty annoying to see that even this very minimal amount of testing effort has not been spent by a critical subsystem maintainer. My bad, I just sent out a fix. Many thanks, Mark.
[Qemu-devel] [PATCH] pci: fix bridge IO/BASE
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? --- hw/pci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/pci.c b/hw/pci.c index fee27fc..6d08cef 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) memset(d-wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); /* Supported memory and i/o types */ -d-config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; -d-config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; +d-config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; +d-config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; pci_word_test_and_set_mask(d-config + PCI_PREF_MEMORY_BASE, PCI_PREF_RANGE_TYPE_64); pci_word_test_and_set_mask(d-config + PCI_PREF_MEMORY_LIMIT, -- 1.7.9.111.gf3fb0
Re: [Qemu-devel] [PULL] kvm updates
On 03/02/2012 01:45 AM, Andreas Färber wrote: Am 01.03.2012 13:47, schrieb Avi Kivity: Avi Kivity (1): pc-bios: update kvmvapic.bin Gleb Natapov (1): kvm: Synchronize cpu state in kvm_arch_stop_on_emulation_error() Jan Kiszka (10): kvm: Set cpu_single_env only once Remove useless casts from cpu iterators Process pending work while waiting for initial kick-off in TCG mode Allow to use pause_all_vcpus from VCPU context target-i386: Add infrastructure for reporting TPR MMIO accesses kvmvapic: Add option ROM kvmvapic: Introduce TPR access optimization for Windows guests kvmvapic: Simplify mp/up_set_tpr optionsrom: Reserve space for checksum kvmvapic: Use optionrom helpers What about my kvmclock kvm_enabled() fix? Should I rather submit that as part of my qom-cpu queue? It depends on it. I am still catching up with my queue post vacation. Somehow it seems to be getting longer instead of shorter. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 108e:a000 id Bus 0, device 1, function 0: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 1. subordinate bus 1. IO range [0x, 0x0fff] memory range [0x, 0x000f] prefetchable memory range [0x, 0x000f] id Bus 0, device 1, function 1: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 2. subordinate bus 2. IO range [0x, 0x0fff] memory range [0x, 0x000f] prefetchable memory range [0x, 0x000f] id Bus 0, device 2, function 0: VGA controller: PCI device 1234: BAR0: 32 bit prefetchable memory at 0x0080 [0x00ff]. BAR6: 32 bit memory at 0x0100 [0x0100]. id Bus 0, device 3, function 0: Bridge: PCI device 108e:1000 BAR0: 32 bit memory at 0x0200 [0x02ff]. BAR1: 32 bit memory at 0x0300 [0x037f]. id Bus 0, device 4, function 0: Ethernet controller: PCI device 10ec:8029 IRQ 0. BAR0: I/O at 0x [0x00fe]. BAR6: 32 bit memory at 0x0380 [0x0380]. id Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id (qemu) info mtree memory -7ffe (prio 0, RW): system -07ff (prio 0, RW): sun4u.ram 01fe-01fe (prio 0, RW): apb-config 01fe0100-01fe01ff (prio 0, RW): apb-pci-config 01fe0200-01fe0200 (prio 0, RW): apb-pci-ioport 01ff-01ff (prio 0, RW): pci-mmio 01ff-01ff000f (prio 1, RW): alias pci_bridge_mem @pci_bridge_pci -000f 01ff-01ff000f (prio 1, RW): alias pci_bridge_pref_mem @pci_bridge_pci -000f 01ff-01ff000f (prio 1, RW): alias pci_bridge_mem @pci_bridge_pci -000f 01ff-01ff000f (prio 1, RW): alias pci_bridge_pref_mem @pci_bridge_pci -000f 01ff000a-01ff000a (prio 2, RW): alias vga.chain4 @vga.vram - 01ff000a-01ff000b (prio 1, RW): vga-lowmem 01ff0080-01ff00ff (prio 1, RW): vga.vram 01ff0100-01ff0100 (prio 1, RW): vga.rom 01ff0200-01ff02ff (prio 1, RW): isa-mmio 01ff0300-01ff037f (prio 1, RW): isa-mmio 01ff0380-01ff0380 (prio 1, RW): ne2000.rom 01fff000-01fff03f (prio 0, R-): sun4u.prom pci_bridge_pci -7ffe (prio 0, RW): pci_bridge_pci pci_bridge_pci -7ffe (prio 0, RW): pci_bridge_pci vga.vram 0080-00ff (prio 1, RW): vga.vram I/O - (prio 0, RW): io -0fff (prio 1, RW): alias pci_bridge_io @pci_bridge_io -0fff -0fff (prio 1, RW): alias pci_bridge_io @pci_bridge_io -0fff 0060-0060 (prio 0, RW): i8042-data 0064-0064 (prio 0, RW): i8042-cmd 0074-0077 (prio 0, RW): m48t59 01ce-01ce (prio 0, RW): alias vbe @vbe 01ce-01ce
Re: [Qemu-devel] KVM/QEMU: Support executing from flash device
On 03/04/2012 10:12 AM, Gleb Natapov wrote: On Sat, Mar 03, 2012 at 10:56:02PM -0800, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. Do you want to execute code from a flash while it traps on read/exec? KVM emulator can't do that. No, he wants read/exec to go to RAM, and writes to be handled as mmio. This should work. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] KVM/QEMU: Support executing from flash device
On Sun, Mar 04, 2012 at 12:36:20PM +0200, Avi Kivity wrote: On 03/04/2012 10:12 AM, Gleb Natapov wrote: On Sat, Mar 03, 2012 at 10:56:02PM -0800, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. Do you want to execute code from a flash while it traps on read/exec? KVM emulator can't do that. No, he wants read/exec to go to RAM, and writes to be handled as mmio. This should work. That's mode 1 from above and will obviously work. I am asking about mode 2 from above. -- Gleb.
Re: [Qemu-devel] KVM/QEMU: Support executing from flash device
On 03/04/2012 08:56 AM, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. 3. qemu should be able to then restore the region to the initial state. Here is my plan: 1. Add KVM_CAP_REGION_WRITE_TRAP 2. Add kvm_memory_region::flags KVM_MEMSLOT_TRAP_WRITES 3. Update page table creation to trap on writes when KVM_MEMSLOT_TRAP_WRITES is set Is this plan heading in the right direction? Sure. I'd name things differently, call this type of slot readonly instead of write trapping (that is, say what works in kvm (reads) instead of what doesn't (writes). Note you need to update kvm_userspace_memory_region, not kvm_memory_region, which has been deprecated since 2.6.24 or so. Regarding emulating ROM (as you mentioned above): I think that it can trap to qemu and QEMU can ignore it. This would be a performance hit, but I don't think it is expected that lots of writes to a ROM will occur. Do you agree? I do, I don't foresee any problems in this area. Only potential issue is vapic writing to a ROM region, but Jan's recent work adds a hackaround for that (vapic_map_rom_writable()). -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] KVM/QEMU: Support executing from flash device
On 03/04/2012 12:38 PM, Gleb Natapov wrote: On Sun, Mar 04, 2012 at 12:36:20PM +0200, Avi Kivity wrote: On 03/04/2012 10:12 AM, Gleb Natapov wrote: On Sat, Mar 03, 2012 at 10:56:02PM -0800, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. Do you want to execute code from a flash while it traps on read/exec? KVM emulator can't do that. No, he wants read/exec to go to RAM, and writes to be handled as mmio. This should work. That's mode 1 from above and will obviously work. I am asking about mode 2 from above. Mode 2 is pure mmio. You're right that kvm won't run code from that. Jordan, what's the use for mode 2? Is it just used during programming? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v1 0/5] Microblaze machine models and bootloader refactoring
From: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com Overhauled the microblaze bootloader process. Factored out the common boot code between petalogix_ml605 and petalogix_s3adsp1800 machine models into a dedicated microblaze bootloader (Patch 1). It now organised in much the same way as its handled in arm machine models (arm_boot.c) where the machine model calls load_kernel() after machine initialisation. Did some general cleanup of s2adsp1800, moved some cpu reset behaviour out of the machine model initialisation (patch 2) and #defined some magic numbers (patch 3). Hooked up Peter Maydells -dtb argument to the bootloader for dtb loading (patches 4+5). Peter A. G. Crosthwaite (5): microblaze: factored out common boot code petalogix_s2adsp1800: moved rst logic to rst fn petalogix_s2adsp1800: macro'd magic numbers qemu-options.hx: allow -dtb argument for all archs microblaze_boot: enabled -dtb argument Makefile.target |1 + hw/microblaze_boot.c | 177 + hw/microblaze_boot.h | 10 +++ hw/petalogix_ml605_mmu.c | 144 +++-- hw/petalogix_s3adsp1800_mmu.c | 147 +- qemu-options.hx |2 +- 6 files changed, 221 insertions(+), 260 deletions(-) create mode 100644 hw/microblaze_boot.c create mode 100644 hw/microblaze_boot.h -- 1.7.5.4
[Qemu-devel] [PATCH v1 1/5] microblaze: factored out common boot code
From: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
factored out the copy-pasted common boot code from the two microblaze platforms
into a dedicated microblaze bootloader (microblaze_boot.o).
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
Makefile.target |1 +
hw/microblaze_boot.c | 183 +
hw/microblaze_boot.h | 10 ++
hw/petalogix_ml605_mmu.c | 144 +++-
hw/petalogix_s3adsp1800_mmu.c | 127 +---
5 files changed, 211 insertions(+), 254 deletions(-)
create mode 100644 hw/microblaze_boot.c
create mode 100644 hw/microblaze_boot.h
diff --git a/Makefile.target b/Makefile.target
index 343eb78..f853883 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -307,6 +307,7 @@ obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o
mips_fulong2e.o
obj-microblaze-y = petalogix_s3adsp1800_mmu.o
obj-microblaze-y += petalogix_ml605_mmu.o
+obj-microblaze-y += microblaze_boot.o
obj-microblaze-y += microblaze_pic_cpu.o
obj-microblaze-y += xilinx_intc.o
diff --git a/hw/microblaze_boot.c b/hw/microblaze_boot.c
new file mode 100644
index 000..37fce50
--- /dev/null
+++ b/hw/microblaze_boot.c
@@ -0,0 +1,183 @@
+/*
+ * Microblaze kernel loader
+ *
+ * Copyright (c) 2012 Peter Crosthwaite peter.crosthwa...@petalogix.com
+ * Copyright (c) 2012 PetaLogix
+ * Copyright (c) 2009 Edgar E. Iglesias.
+ *
+ * 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 qemu-option.h
+#include qemu-config.h
+#include qemu-common.h
+#include device_tree.h
+#include loader.h
+#include elf.h
+
+#include microblaze_boot.h
+
+static struct
+{
+void (*machine_cpu_reset)(CPUState *);
+uint32_t bootstrap_pc;
+uint32_t cmdline;
+uint32_t fdt;
+} boot_info;
+
+static void main_cpu_reset(void *opaque)
+{
+CPUState *env = opaque;
+
+cpu_reset(env);
+env-regs[5] = boot_info.cmdline;
+env-regs[7] = boot_info.fdt;
+env-sregs[SR_PC] = boot_info.bootstrap_pc;
+if (boot_info.machine_cpu_reset) {
+boot_info.machine_cpu_reset(env);
+}
+}
+
+static int microblaze_load_dtb(target_phys_addr_t addr,
+ uint32_t ramsize,
+ const char *kernel_cmdline,
+ const char *dtb_filename)
+{
+char *path;
+int fdt_size;
+#ifdef CONFIG_FDT
+void *fdt;
+int r;
+
+/* Try the local mb.dtb override. */
+fdt = load_device_tree(mb.dtb, fdt_size);
+if (!fdt) {
+path = qemu_find_file(QEMU_FILE_TYPE_BIOS, dtb_filename);
+if (path) {
+fdt = load_device_tree(path, fdt_size);
+g_free(path);
+}
+if (!fdt) {
+return 0;
+}
+}
+
+if (kernel_cmdline) {
+r = qemu_devtree_setprop_string(fdt, /chosen, bootargs,
+kernel_cmdline);
+if (r 0) {
+fprintf(stderr, couldn't set /chosen/bootargs\n);
+}
+}
+
+cpu_physical_memory_write(addr, (void *)fdt, fdt_size);
+#else
+/* We lack libfdt so we cannot manipulate the fdt. Just pass on the blob
+ to the kernel. */
+fdt_size = load_image_targphys(mb.dtb, addr, 0x1);
+if (fdt_size 0) {
+path = qemu_find_file(QEMU_FILE_TYPE_BIOS, BINARY_DEVICE_TREE_FILE);
+if (path) {
+fdt_size = load_image_targphys(path, addr, 0x1);
+g_free(path);
+}
+}
+
+if (kernel_cmdline) {
+fprintf(stderr,
+Warning: missing libfdt, cannot pass cmdline to kernel!\n);
+}
+#endif
+return fdt_size;
+}
+
+static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
+{
+return addr - 0x3000LL;
+}
+
+void microblaze_load_kernel(CPUState *env, target_phys_addr_t ddr_base,
+
[Qemu-devel] [PATCH v1 2/5] petalogix_s2adsp1800: moved rst logic to rst fn
From: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
This belongs in the machine specific reset function
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
hw/petalogix_s3adsp1800_mmu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 7c6e9b8..99c3590 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -42,6 +42,12 @@
#define BINARY_DEVICE_TREE_FILE petalogix-s3adsp1800.dtb
+static void machine_cpu_reset(CPUState *env)
+{
+/* FIXME: move to machine specfic cpu reset */
+env-pvr.regs[10] = 0x0c00; /* spartan 3a dsp family. */
+}
+
static void
petalogix_s3adsp1800_init(ram_addr_t ram_size,
const char *boot_device,
@@ -53,6 +59,7 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
CPUState *env;
DriveInfo *dinfo;
int i;
+/* FIXME: remove harcoded magic numbers */
target_phys_addr_t ddr_base = 0x9000;
MemoryRegion *phys_lmb_bram = g_new(MemoryRegion, 1);
MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
@@ -65,9 +72,6 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
}
env = cpu_init(cpu_model);
-/* FIXME: move to machine specfic cpu reset */
-env-pvr.regs[10] = 0x0c00; /* spartan 3a dsp family. */
-
/* Attach emulated BRAM through the LMB. */
memory_region_init_ram(phys_lmb_bram,
petalogix_s3adsp1800.lmb_bram, LMB_BRAM_SIZE);
@@ -97,7 +101,7 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
xilinx_ethlite_create(nd_table[0], 0x8100, irq[1], 0, 0);
microblaze_load_kernel(env, ddr_base, ram_size,
-BINARY_DEVICE_TREE_FILE, NULL);
+BINARY_DEVICE_TREE_FILE, machine_cpu_reset);
}
static QEMUMachine petalogix_s3adsp1800_machine = {
--
1.7.5.4
[Qemu-devel] [PATCH v1 3/5] petalogix_s2adsp1800: macro'd magic numbers
From: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
defined macros for the addresses of the peripherals in machine model
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
hw/petalogix_s3adsp1800_mmu.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 99c3590..2cb0b1f 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -42,6 +42,13 @@
#define BINARY_DEVICE_TREE_FILE petalogix-s3adsp1800.dtb
+#define MEMORY_BASEADDR 0x9000
+#define FLASH_BASEADDR 0xa000
+#define INTC_BASEADDR 0x8180
+#define TIMER_BASEADDR 0x83c0
+#define UARTLITE_BASEADDR 0x8400
+#define ETHLITE_BASEADDR 0x8100
+
static void machine_cpu_reset(CPUState *env)
{
/* FIXME: move to machine specfic cpu reset */
@@ -59,8 +66,7 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
CPUState *env;
DriveInfo *dinfo;
int i;
-/* FIXME: remove harcoded magic numbers */
-target_phys_addr_t ddr_base = 0x9000;
+target_phys_addr_t ddr_base = MEMORY_BASEADDR;
MemoryRegion *phys_lmb_bram = g_new(MemoryRegion, 1);
MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
qemu_irq irq[32], *cpu_irq;
@@ -83,22 +89,22 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
memory_region_add_subregion(sysmem, ddr_base, phys_ram);
dinfo = drive_get(IF_PFLASH, 0, 0);
-pflash_cfi01_register(0xa000,
+pflash_cfi01_register(FLASH_BASEADDR,
NULL, petalogix_s3adsp1800.flash, FLASH_SIZE,
dinfo ? dinfo-bdrv : NULL, (64 * 1024),
FLASH_SIZE 16,
1, 0x89, 0x18, 0x, 0x0, 1);
cpu_irq = microblaze_pic_init_cpu(env);
-dev = xilinx_intc_create(0x8180, cpu_irq[0], 2);
+dev = xilinx_intc_create(INTC_BASEADDR, cpu_irq[0], 2);
for (i = 0; i 32; i++) {
irq[i] = qdev_get_gpio_in(dev, i);
}
-sysbus_create_simple(xilinx,uartlite, 0x8400, irq[3]);
+sysbus_create_simple(xilinx,uartlite, UARTLITE_BASEADDR, irq[3]);
/* 2 timers at irq 2 @ 62 Mhz. */
-xilinx_timer_create(0x83c0, irq[0], 2, 62 * 100);
-xilinx_ethlite_create(nd_table[0], 0x8100, irq[1], 0, 0);
+xilinx_timer_create(TIMER_BASEADDR, irq[0], 2, 62 * 100);
+xilinx_ethlite_create(nd_table[0], ETHLITE_BASEADDR, irq[1], 0, 0);
microblaze_load_kernel(env, ddr_base, ram_size,
BINARY_DEVICE_TREE_FILE, machine_cpu_reset);
--
1.7.5.4
[Qemu-devel] [PATCH v1 4/5] qemu-options.hx: allow -dtb argument for all archs
From: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
qemu-options.hx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index e38799c..daefce3 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2038,7 +2038,7 @@ first module.
ETEXI
DEF(dtb, HAS_ARG, QEMU_OPTION_dtb, \
--dtbfileuse 'file' as device tree image\n, QEMU_ARCH_ARM)
+-dtbfileuse 'file' as device tree image\n, QEMU_ARCH_ALL)
STEXI
@item -dtb @var{file}
@findex -dtb
--
1.7.5.4
[Qemu-devel] [PATCH v1 5/5] microblaze_boot: enabled -dtb argument
From: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
Use the -dtb argument for passing is a custom dtb rather than the old
hardcoded mb.dtb
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
hw/microblaze_boot.c | 34 ++
1 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/hw/microblaze_boot.c b/hw/microblaze_boot.c
index 37fce50..b2f96df 100644
--- a/hw/microblaze_boot.c
+++ b/hw/microblaze_boot.c
@@ -59,23 +59,16 @@ static int microblaze_load_dtb(target_phys_addr_t addr,
const char *kernel_cmdline,
const char *dtb_filename)
{
-char *path;
int fdt_size;
#ifdef CONFIG_FDT
-void *fdt;
+void *fdt = NULL;
int r;
-/* Try the local mb.dtb override. */
-fdt = load_device_tree(mb.dtb, fdt_size);
+if (dtb_filename) {
+fdt = load_device_tree(dtb_filename, fdt_size);
+}
if (!fdt) {
-path = qemu_find_file(QEMU_FILE_TYPE_BIOS, dtb_filename);
-if (path) {
-fdt = load_device_tree(path, fdt_size);
-g_free(path);
-}
-if (!fdt) {
-return 0;
-}
+return 0;
}
if (kernel_cmdline) {
@@ -90,15 +83,9 @@ static int microblaze_load_dtb(target_phys_addr_t addr,
#else
/* We lack libfdt so we cannot manipulate the fdt. Just pass on the blob
to the kernel. */
-fdt_size = load_image_targphys(mb.dtb, addr, 0x1);
-if (fdt_size 0) {
-path = qemu_find_file(QEMU_FILE_TYPE_BIOS, BINARY_DEVICE_TREE_FILE);
-if (path) {
-fdt_size = load_image_targphys(path, addr, 0x1);
-g_free(path);
-}
+if (dtb_filename) {
+fdt_size = load_image_targphys(dtb_filename, addr, 0x1);
}
-
if (kernel_cmdline) {
fprintf(stderr,
Warning: missing libfdt, cannot pass cmdline to kernel!\n);
@@ -123,8 +110,15 @@ void microblaze_load_kernel(CPUState *env,
target_phys_addr_t ddr_base,
machine_opts = qemu_opts_find(qemu_find_opts(machine), 0);
if (machine_opts) {
+const char *dtb_arg;
kernel_filename = qemu_opt_get(machine_opts, kernel);
kernel_cmdline = qemu_opt_get(machine_opts, append);
+dtb_arg = qemu_opt_get(machine_opts, dtb);
+if (dtb_arg) { /* Preference a -dtb argument */
+dtb_filename = dtb_arg;
+} else { /* default to pcbios dtb as passed by machine_init */
+dtb_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, dtb_filename);
+}
}
boot_info.machine_cpu_reset = machine_cpu_reset;
--
1.7.5.4
[Qemu-devel] [PATCH] usb-ehci: drop unused isoch_pause variable
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/usb-ehci.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index df742f7..f4d53ff 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -419,7 +419,6 @@ struct EHCIState {
USBPacket ipacket;
QEMUSGList isgl;
-int isoch_pause;
uint64_t last_run_ns;
};
@@ -907,7 +906,6 @@ static void ehci_reset(void *opaque)
s-astate = EST_INACTIVE;
s-pstate = EST_INACTIVE;
-s-isoch_pause = -1;
s-attach_poll_counter = 0;
for(i = 0; i NB_PORTS; i++) {
@@ -2150,9 +2148,7 @@ static void ehci_frame_timer(void *opaque)
for (i = 0; i frames; i++) {
if ( !(ehci-usbsts USBSTS_HALT)) {
-if (ehci-isoch_pause = 0) {
-ehci-frindex += 8;
-}
+ehci-frindex += 8;
if (ehci-frindex 0x1fff) {
ehci-frindex = 0;
--
1.7.7.6
Re: [Qemu-devel] [PULL] Patch queue
Thanks, pulled. On Tue, Feb 28, 2012 at 21:47, Stefan Weil s...@weilnetz.de wrote: Hi, please pull these patches from January. Thanks, Stefan Weil The following changes since commit b55c952aea6de024bf1a06357b49367fba045443: Merge remote-tracking branch 'aneesh/for-upstream' into staging (2012-02-27 11:19:27 -0600) are available in the git repository at: git://qemu.weilnetz.de/qemu.git upstream for you to fetch changes up to c0fd260e9da7e6e60ea6bf1b0198a804f147073f: Move definition of HOST_LONG_BITS to qemu-common.h (2012-02-28 22:33:43 +0100) Stefan Weil (15): Remove macro HOST_LONG_SIZE target-alpha: Clean includes target-arm: Clean includes target-cris: Clean includes target-i386: Clean includes target-lm32: Clean includes target-m68k: Clean includes target-microblaze: Clean includes target-mips: Clean includes target-ppc: Clean includes target-s390x: Clean includes target-sh4: Clean includes target-unicore32: Clean includes target-xtensa: Clean includes Move definition of HOST_LONG_BITS to qemu-common.h configure | 12 cpu-defs.h | 2 -- qemu-common.h | 9 + target-alpha/cpu.h | 1 + target-alpha/translate.c | 5 - target-arm/helper.c | 5 - target-cris/cpu.h | 3 +++ target-cris/helper.c | 4 target-cris/mmu.c | 5 - target-cris/translate.c | 7 --- target-i386/helper.c | 6 -- target-i386/op_helper.c | 1 - target-lm32/cpu.h | 1 + target-lm32/helper.c | 5 - target-lm32/translate.c | 8 target-m68k/cpu.h | 1 + target-m68k/helper.c | 5 - target-m68k/translate.c | 6 -- target-microblaze/cpu.h | 3 +++ target-microblaze/helper.c | 5 - target-microblaze/mmu.c | 4 target-microblaze/translate.c | 8 target-mips/translate.c | 7 --- target-ppc/helper.c | 6 -- target-ppc/translate.c | 6 -- target-s390x/cpu.h | 3 +++ target-s390x/helper.c | 5 - target-s390x/translate.c | 5 - target-sh4/translate.c | 6 -- target-unicore32/cpu.h | 2 ++ target-unicore32/helper.c | 4 target-xtensa/core-dc232b.c | 1 - target-xtensa/core-fsf.c | 1 - target-xtensa/helper.c | 1 - thunk.h | 4 ++-- 35 files changed, 25 insertions(+), 132 deletions(-)
Re: [Qemu-devel] [PATCH 0/6] w64: Improve compilation with MinGW-w64
Thanks, applied all. On Fri, Mar 2, 2012 at 22:30, Stefan Weil s...@weilnetz.de wrote: These patches are a step towards full 64 bit support for w64. The patches 4 and 5 are optional. Please apply this series. Thanks, Stefan Weil [PATCH 1/6] w64: Fix size of ram_addr_t [PATCH 2/6] tcg: Rearrange definitions and include statements [PATCH 3/6] w64: Fix data type of parameters for flush_icache_range [PATCH 4/6] w64: Change data type of parameters for [PATCH 5/6] cache-utils: Change data type of parameters for [PATCH 6/6] w64: fix type casts when calling flush_icache_range
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. The host kernel exposes the dirty bit map with a bit per -host- kernel PAGE_SIZE (which is what getpagesize() gets you in qemu). My patch makes thus makes things work when the host uses 64K page sizes. In all cases, the guest page size is irrelevant, this is purely a problem between the host kernel and qemu. Cheers, Ben.
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On 03/04/2012 01:53 PM, Benjamin Herrenschmidt wrote: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. The host kernel exposes the dirty bit map with a bit per -host- kernel PAGE_SIZE (which is what getpagesize() gets you in qemu). My patch makes thus makes things work when the host uses 64K page sizes. In all cases, the guest page size is irrelevant, this is purely a problem between the host kernel and qemu. Right (and I actually knew all this stuff before :( ). -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v8 1/4] cadence_uart: initial version of device model
On Fri, Mar 2, 2012 at 12:09 AM, Peter Maydell peter.mayd...@linaro.org wrote:
On 28 February 2012 07:40, Peter A. G. Crosthwaite
peter.crosthwa...@petalogix.com wrote:
Implemented cadence UART serial controller
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
Signed-off-by: John Linn john.l...@xilinx.com
Acked-by: Edgar E. Iglesias edgar.igles...@gmail.com
---
changed from v7:
removed fflush() from DBPRINTF
changed from v6:
removed automatic interrupt clearing
removed mask_and_right_justify
removed redundant stop_break logic
made tx and rx function interfaces consistent
renamed qemu_debug() - DB_PRINT (all)
changed from v4:
fixed FSF addess
changed device_init - type_init
changes from v1:
converted register file to array
added vmsd state save/load support
removed read side effects from CISR register
Makefile.target | 1 +
hw/cadence_uart.c | 535
+
2 files changed, 536 insertions(+), 0 deletions(-)
create mode 100644 hw/cadence_uart.c
diff --git a/Makefile.target b/Makefile.target
index 68a5641..2021926 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -344,6 +344,7 @@ endif
obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o
pl190.o
obj-arm-y += versatile_pci.o
+obj-arm-y += cadence_uart.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
diff --git a/hw/cadence_uart.c b/hw/cadence_uart.c
new file mode 100644
index 000..646f0e6
--- /dev/null
+++ b/hw/cadence_uart.c
@@ -0,0 +1,535 @@
+/*
+ * Device model for Cadence UART
+ *
+ * Copyright (c) 2010 Xilinx Inc.
+ * Copyright (c) 2012 Peter A.G. Crosthwaite
(peter.crosthwa...@petalogix.com)
+ * Copyright (c) 2012 PetaLogix Pty Ltd.
+ * Written by Haibing Ma
+ * M.Habib
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include qemu-char.h
+#include qemu-timer.h
+
+#ifdef CADENCE_UART_ERR_DEBUG
+#define DB_PRINT(...) do { \
+ fprintf(stderr, : %s: , __func__); \
+ fprintf(stderr, ## __VA_ARGS__); \
+ } while (0);
+#else
+ #define DB_PRINT(...)
+#endif
+
+#define UART_INTR_RTRIG 0x0001
+#define UART_INTR_REMPTY 0x0002
+#define UART_INTR_RFUL 0x0004
+#define UART_INTR_TEMPTY 0x0008
+#define UART_INTR_TFUL 0x0010
+#define UART_INTR_ROVR 0x0020
+#define UART_INTR_FRAME 0x0040
+#define UART_INTR_PARE 0x0080
+#define UART_INTR_TIMEOUT 0x0100
+#define UART_INTR_DMSI 0x0200
+#define UART_INTR_TTRIG 0x0400
+#define UART_INTR_TNFUL 0x0800
+#define UART_INTR_TOVR 0x1000
+
+#define UART_CSR_RTRIG 0x0001
+#define UART_CSR_REMPTY 0x0002
+#define UART_CSR_RFUL 0x0004
+#define UART_CSR_TEMPTY 0x0008
+#define UART_CSR_TFUL 0x0010
+#define UART_CSR_ROVR 0x0020
+#define UART_CSR_FRAME 0x0040
+#define UART_CSR_PARE 0x0080
+#define UART_CSR_TIMEOUT 0x0100
+#define UART_CSR_DMSI 0x0200
+#define UART_CSR_RACTIVE 0x0400
+#define UART_CSR_TACTIVE 0x0800
+#define UART_CSR_FDELT 0x1000
+#define UART_CSR_TTRIG 0x2000
+#define UART_CSR_TNFUL 0x4000
+
+#define UART_CR_RXRST 0x0001
+#define UART_CR_TXRST 0x0002
+#define UART_CR_RX_EN 0x0004
+#define UART_CR_RX_DIS 0x0008
+#define UART_CR_TX_EN 0x0010
+#define UART_CR_TX_DIS 0x0020
+#define UART_CR_RST_TO 0x0040
+#define UART_CR_STARTBRK 0x0080
+#define UART_CR_STOPBRK 0x0100
+
+#define UART_MR_CLKS 0x0001
+#define UART_MR_CHRL 0x0006
+#define UART_MR_CHRL_SH 1
+#define UART_MR_PAR 0x0038
+#define UART_MR_PAR_SH 3
+#define UART_MR_NBSTOP 0x00C0
+#define UART_MR_NBSTOP_SH 6
+#define UART_MR_CHMODE 0x0300
+#define UART_MR_CHMODE_SH 8
+#define UART_MR_UCLKEN 0x0400
+#define UART_MR_IRMODE 0x0800
+
+#define UART_DATA_BITS_6 (0x3 UART_MR_CHRL_SH)
+#define UART_DATA_BITS_7 (0x2 UART_MR_CHRL_SH)
+#define UART_PARITY_ODD (0x1 UART_MR_PAR_SH)
+#define UART_PARITY_EVEN (0x0 UART_MR_PAR_SH)
+#define UART_STOP_BITS_1
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4==at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4==by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4==by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4==at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4==by 0x225F56: malloc_and_trace (vl.c:2156) ==4==by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4==by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4==by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4==by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4==by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4==at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4==by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4==by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4==at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4==by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4==by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4==at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4==by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4==by 0x9AD9A19: ??? ==4== Is the above a problem? This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 108e:a000 id Bus 0, device 1, function 0: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 1. subordinate bus 1. IO range [0x, 0x0fff] memory range [0x, 0x000f] prefetchable memory range [0x, 0x000f] id Bus 0, device 1, function 1: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 2. subordinate bus 2. IO range [0x, 0x0fff] memory range [0x, 0x000f] prefetchable memory range [0x, 0x000f] id Bus 0, device 2, function 0: VGA controller: PCI device 1234: BAR0: 32 bit prefetchable memory at 0x0080 [0x00ff]. BAR6: 32 bit memory at 0x0100 [0x0100]. id Bus 0, device 3, function 0: Bridge: PCI device 108e:1000 BAR0: 32 bit memory at 0x0200 [0x02ff]. BAR1: 32 bit memory at 0x0300 [0x037f]. id Bus 0, device 4, function 0: Ethernet controller: PCI device 10ec:8029 IRQ 0. BAR0: I/O at 0x [0x00fe]. BAR6: 32 bit memory at 0x0380 [0x0380]. id
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On 03/04/2012 12:27 PM, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
So here's a theory: the issue is that both device IO
and bridge IO have the same priority.
Bridge is initialized with IO at 0 to 4K
and so we have two devices at the same priority.
And flipping a type bit affects this, by chance?
I tried the following and it seems to help.
But the real fix IMO is to either disable the bridge ranges
at reset, in hardware, or have the BIOS do this.
Avi, could you pls comment on my analysis?
diff --git a/hw/pci.c b/hw/pci.c
index 6d08cef..286383a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d)
r-addr = new_addr;
if (r-addr != PCI_BAR_UNMAPPED) {
memory_region_add_subregion_overlap(r-address_space,
-r-addr, r-memory, 1);
+r-addr, r-memory, 2);
}
}
}
[Qemu-devel] questions about pci
Hi all: I read pci code in qemu about i440fx, pci.c and so on. I think if guest os whose mainboard is based on x86, it will use IO instructions to access PCI configuration space.If not use passthrough, qemu should emulate these operations.I find a function called kvm_handle_io who will emulate ioport write/read, I have traced this function, but I haven't found it has any relationship with pci read/write configuration space functions like i440fx_write_config and piix3_write_config.So how does it emulate pci configuration space access when not use passthrough? thanks Wanpeng Li LTC China, IBM
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 02:33:02PM +0200, Michael S. Tsirkin wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
So here's a theory: the issue is that both device IO
and bridge IO have the same priority.
Bridge is initialized with IO at 0 to 4K
and so we have two devices at the same priority.
And flipping a type bit affects this, by chance?
I tried the following and it seems to help.
But the real fix IMO is to either disable the bridge ranges
at reset, in hardware, or have the BIOS do this.
Avi, could you pls comment on my analysis?
diff --git a/hw/pci.c b/hw/pci.c
index 6d08cef..286383a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d)
r-addr = new_addr;
if (r-addr != PCI_BAR_UNMAPPED) {
memory_region_add_subregion_overlap(r-address_space,
-r-addr, r-memory, 1);
+r-addr, r-memory, 2);
}
}
}
Grr. Scap the above, the patch does nothing, I didn't test it right.
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On 03/04/2012 02:33 PM, Michael S. Tsirkin wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
So here's a theory: the issue is that both device IO
and bridge IO have the same priority.
Bridge is initialized with IO at 0 to 4K
and so we have two devices at the same priority.
And flipping a type bit affects this, by chance?
What device shares its BAR with the bridge I/O window?
I tried the following and it seems to help.
But the real fix IMO is to either disable the bridge ranges
at reset, in hardware, or have the BIOS do this.
Avi, could you pls comment on my analysis?
diff --git a/hw/pci.c b/hw/pci.c
index 6d08cef..286383a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d)
r-addr = new_addr;
if (r-addr != PCI_BAR_UNMAPPED) {
memory_region_add_subregion_overlap(r-address_space,
-r-addr, r-memory, 1);
+r-addr, r-memory, 2);
}
}
}
Who says a BAR has higher priority than a bridge?
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It looks like Sparc does not reset registers at CPU reset. Nice catch. This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 108e:a000 id Bus 0, device 1, function 0: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 1. subordinate bus 1. IO range [0x, 0x0fff] memory range [0x, 0x000f] prefetchable memory range [0x, 0x000f] id Bus 0, device 1, function 1: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 2. subordinate bus 2. IO range [0x, 0x0fff] memory range [0x, 0x000f] prefetchable memory range [0x, 0x000f] id Bus 0, device 2, function 0: VGA controller: PCI device 1234: BAR0: 32 bit prefetchable memory at 0x0080 [0x00ff]. BAR6: 32 bit memory at 0x0100 [0x0100]. id Bus 0, device 3, function 0: Bridge: PCI device 108e:1000 BAR0: 32 bit memory at 0x0200 [0x02ff]. BAR1: 32 bit memory at 0x0300 [0x037f]. id Bus 0, device
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 12:28, Avi Kivity a...@redhat.com wrote: On 03/04/2012 12:27 PM, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so? No, this is after failure. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On 03/04/2012 02:38 PM, Blue Swirl wrote: This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so? No, this is after failure. I don't see why the guest expects the BARs to work then. -- error compiling committee.c: too many arguments to function
[Qemu-devel] restart a coroutine?
Since all block (bdrv) layer is now implemented using coroutines, I thought I'd give it a try. But immediately hit a question to which I don't know a good answer. Suppose we've some networking block device (like NBD) and want to be able to support reconnection - this is actually very useful feature, in order to be able to reboot/restart the NBD server without a need to restart all the clients. For this to work, we should have an ability to reconnect to the server and re-issue all requests which were waiting for reply. Traditionally, in asyncronous event-loop-based scheme, this is implemented as a queue of requests linked to the block driver state structure, and in case of reconnection we just walk over all requests and requeue these. But if the block driver is implemented as a set of coroutines (like nbd currently does), I see no sane/safe way to restart the requests. Setjmp/longjmp can be uses with extra care there, but with these it is extremly fragile. Any hints on how to do that? Thanks, /mjt
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 12:33, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
So here's a theory: the issue is that both device IO
and bridge IO have the same priority.
Bridge is initialized with IO at 0 to 4K
and so we have two devices at the same priority.
And flipping a type bit affects this, by chance?
I tried the following and it seems to help.
But the real fix IMO is to either disable the bridge ranges
at reset, in hardware, or have the BIOS do this.
I'd suppose bridge ranges should be disabled at reset. BIOS should
probably also program the bridge ranges so that only devices behind
the bridge are visible, or if no devices exist, disable the bridge
completely. It's possible that all of these could be buggy and the
original commit could be correct.
Avi, could you pls comment on my analysis?
diff --git a/hw/pci.c b/hw/pci.c
index 6d08cef..286383a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d)
r-addr = new_addr;
if (r-addr != PCI_BAR_UNMAPPED) {
memory_region_add_subregion_overlap(r-address_space,
- r-addr, r-memory, 1);
+ r-addr, r-memory, 2);
}
}
}
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 12:41, Avi Kivity a...@redhat.com wrote: On 03/04/2012 02:38 PM, Blue Swirl wrote: This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so? No, this is after failure. I don't see why the guest expects the BARs to work then. OpenBIOS could initialize them before this commit, now it obviously can't (or initializes the bridges incorrectly). Maybe also the devices should be moved behind the bridges, that's where they really should be. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v8 2/4] cadence_ttc: initial version of device model
On Fri, Mar 2, 2012 at 12:58 AM, Peter Maydell peter.mayd...@linaro.org wrote:
On 28 February 2012 07:40, Peter A. G. Crosthwaite
peter.crosthwa...@petalogix.com wrote:
Implemented cadence Triple Timer Counter (TCC)
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
Signed-off-by: John Linn john.l...@xilinx.com
Acked-by: Edgar E. Iglesias edgar.igles...@gmail.com
---
changed from v7:
removed fflush() from DBPRINTF
changed from v6:
renamed cadence_ttc_state - CadenceTTCState
renamed qemu_debug() - DB_PRINT (all)
added reset function
changed from v4:
fixed FSF addess
changed device_init - type_init
changed from v3:
Fixed race condition where timer could miss match events on wrap around
changed from v2:
changed ptimer to QEMUTimer (Fixed skew/drift issue in timer delays)
changes from v1:
refactored event driven code
marked vmsd as unmigratable
Makefile.target | 1 +
hw/cadence_ttc.c | 448
++
2 files changed, 449 insertions(+), 0 deletions(-)
create mode 100644 hw/cadence_ttc.c
diff --git a/Makefile.target b/Makefile.target
index 2021926..c09deda 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -345,6 +345,7 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o
arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o
pl190.o
obj-arm-y += versatile_pci.o
obj-arm-y += cadence_uart.o
+obj-arm-y += cadence_ttc.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
diff --git a/hw/cadence_ttc.c b/hw/cadence_ttc.c
new file mode 100644
index 000..08b6c9c
--- /dev/null
+++ b/hw/cadence_ttc.c
@@ -0,0 +1,448 @@
+/*
+ * Xilinx Zynq cadence TTC model
+ *
+ * Copyright (c) 2011 Xilinx Inc.
+ * Copyright (c) 2012 Peter A.G. Crosthwaite
(peter.crosthwa...@petalogix.com)
+ * Copyright (c) 2012 PetaLogix Pty Ltd.
+ * Written By Haibing Ma
+ * M. Habib
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include qemu-timer.h
+
+#ifdef CADENCE_TTC_ERR_DEBUG
+#define DB_PRINT(...) do { \
+ fprintf(stderr, : %s: , __func__); \
+ fprintf(stderr, ## __VA_ARGS__); \
+ } while (0);
+#else
+ #define DB_PRINT(...)
+#endif
+
+#define COUNTER_INTR_IV 0x0001
+#define COUNTER_INTR_M1 0x0002
+#define COUNTER_INTR_M2 0x0004
+#define COUNTER_INTR_M3 0x0008
+#define COUNTER_INTR_OV 0x0010
+#define COUNTER_INTR_EV 0x0020
+
+#define COUNTER_CTRL_DIS 0x0001
+#define COUNTER_CTRL_INT 0x0002
+#define COUNTER_CTRL_DEC 0x0004
+#define COUNTER_CTRL_MATCH 0x0008
+#define COUNTER_CTRL_RST 0x0010
+
+#define CLOCK_CTRL_PS_EN 0x0001
+#define CLOCK_CTRL_PS_V 0x001e
+
+typedef struct {
+ QEMUTimer *timer;
+ int freq;
+
+ uint32_t reg_clock;
+ uint32_t reg_count;
+ uint32_t reg_value;
+ uint16_t reg_interval;
+ uint16_t reg_match[3];
+ uint32_t reg_intr;
+ uint32_t reg_intr_en;
+ uint32_t reg_event_ctrl;
+ uint32_t reg_event;
+
+ uint64_t cpu_time;
+ unsigned int cpu_time_valid;
+
+ qemu_irq irq;
+} CadenceTimerState;
+
+typedef struct {
+ SysBusDevice busdev;
+ MemoryRegion iomem;
+ CadenceTimerState * timer[3];
+} CadenceTTCState;
+
+static void cadence_timer_update(CadenceTimerState *s)
+{
+ qemu_set_irq(s-irq, !!(s-reg_intr s-reg_intr_en));
+}
+
+static CadenceTimerState *cadence_timer_from_addr(void *opaque,
+ target_phys_addr_t offset)
+{
+ unsigned int index;
+ CadenceTTCState *s = (CadenceTTCState *)opaque;
+
+ index = (offset 2) % 3;
+
+ return s-timer[index];
+}
+
+static uint64_t cadence_timer_get_ns(CadenceTimerState *s, uint64_t
timer_steps)
+{
+ /* timer_steps has max value of 0x1. double check it
+ * (or overflow can happen below) */
+ assert(timer_steps = 1ULL 32);
+
+ uint64_t r = timer_steps * 10ULL;
+ if (s-reg_clock CLOCK_CTRL_PS_EN) {
+ r = 16 - (((s-reg_clock CLOCK_CTRL_PS_V) 1) + 1);
+ } else {
+ r = 16;
+ }
+ r /= (uint64_t)s-freq;
+ return r;
+}
+
+static uint64_t cadence_timer_get_steps(CadenceTimerState *s, uint64_t ns)
+{
+ uint64_t to_divide = 10ULL;
+
+ uint64_t r = ns;
+ /* for very large intervals ( 8s) do some division
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 12:46:23PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:41, Avi Kivity a...@redhat.com wrote: On 03/04/2012 02:38 PM, Blue Swirl wrote: This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so? No, this is after failure. I don't see why the guest expects the BARs to work then. OpenBIOS could initialize them before this commit, now it obviously can't (or initializes the bridges incorrectly). I traced all config reads and writes to the bridge and there's no difference I can see between before and after this commit. I think there's some other bug, tweaking this specific bit just happens to trigger it. Maybe also the devices should be moved behind the bridges, that's where they really should be. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 02:41:33PM +0200, Avi Kivity wrote: On 03/04/2012 02:38 PM, Blue Swirl wrote: This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0x [0x0006]. BAR1: I/O at 0x [0x0002]. BAR2: I/O at 0x [0x0006]. BAR3: I/O at 0x [0x0002]. BAR4: I/O at 0x [0x000e]. id The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so? No, this is after failure. I don't see why the guest expects the BARs to work then. I don't belive it does - it probably got hang before initializing BARs. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs
On 4 March 2012 09:10, Michael S. Tsirkin m...@redhat.com wrote: I ended up with qmp-commands.h in target directories, which makes build fail as it is found before the main header. make clean fixes it, but it might get triggered again when we make some header target-independent next. It's easy to just make sure all such leftovers are removed, so let's do this. Signed-off-by: Michael S. Tsirkin m...@redhat.com diff --git a/Makefile b/Makefile index e66e885..958a414 100644 --- a/Makefile +++ b/Makefile @@ -89,6 +89,7 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) subdir-%: $(GENERATED_HEADERS) + $(call quiet-command,rm -f $(foreach header, $(GENERATED_HEADERS), $*/$(header)),) $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V=$(V) TARGET_DIR=$*/ all,) In general we don't have workarounds for something moved directory and this broke builds not from clean (source file moved from hw/ to . being one that's bitten me before), so why does just this one deserve to get an rm here rather than just asking the user to run 'make clean / distclean' ? -- PMM
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
The weird thing is the range type does not seem to be accessed
at all. So I guessed there's some memory corruption here.
Running valgrind shows this:
--4-- WARNING: unhandled syscall: 340
--4-- You may be able to write your own handler.
--4-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4-- Nevertheless we consider this a bug. Please report
--4-- it at http://valgrind.org/support/bug_reports.html.
==4== Invalid read of size 4
==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350)
==4== by 0x2F7A84: sun4uv_init (sun4u.c:779)
==4== by 0x13D716: main (vl.c:3397)
==4== Address 0x156c7d30 is 0 bytes after a block of size 64
alloc'd
==4== at 0x557DD69: malloc (vg_replace_malloc.c:236)
==4== by 0x225F56: malloc_and_trace (vl.c:2156)
==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47)
==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778)
==4== by 0x13D716: main (vl.c:3397)
==4==
apb: here
==4== Warning: client switching stacks? SP change: 0xfec42cbc --
0x16894008
==4== to suppress, use: --max-stackframe=398791500 or
greater
==4== Warning: client switching stacks? SP change: 0x16893fa0 --
0xfec42cc0
==4== to suppress, use: --max-stackframe=398791392 or
greater
==4== Warning: client switching stacks? SP change: 0xfec42fe0 --
0x16893fd0
==4== to suppress, use: --max-stackframe=398790640 or
greater
==4== further instances of this message will not be shown.
QEMU 1.0.50 monitor - type 'help' for more information
(qemu) ==4== Thread 2:
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8351: compute_all_sub (cc_helper.c:37)
==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
Is the above a problem?
It looks like Sparc does not reset registers at CPU reset. Nice catch.
Invalid read and address after block are also worrying.
irqs are allocated with
#define MAX_PILS 16
irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS);
then passed to apb:
pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, pci_bus2,
pci_bus3);
which does:
PCIBus *pci_apb_init(target_phys_addr_t special_base,
target_phys_addr_t mem_base,
qemu_irq *pic, PCIBus **bus2, PCIBus **bus3)
and
for (i = 0; i 32; i++) {
sysbus_connect_irq(s, i, pic[i]);
}
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device 108e:a000
id
Bus 0, device 1, function 0:
PCI bridge: PCI device 108e:5000
BUS 0.
secondary bus 1.
subordinate bus 1.
IO range [0x, 0x0fff]
memory range [0x, 0x000f]
prefetchable memory range [0x,
Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs
On Sun, Mar 04, 2012 at 01:25:59PM +, Peter Maydell wrote: On 4 March 2012 09:10, Michael S. Tsirkin m...@redhat.com wrote: I ended up with qmp-commands.h in target directories, which makes build fail as it is found before the main header. make clean fixes it, but it might get triggered again when we make some header target-independent next. It's easy to just make sure all such leftovers are removed, so let's do this. Signed-off-by: Michael S. Tsirkin m...@redhat.com diff --git a/Makefile b/Makefile index e66e885..958a414 100644 --- a/Makefile +++ b/Makefile @@ -89,6 +89,7 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) subdir-%: $(GENERATED_HEADERS) + $(call quiet-command,rm -f $(foreach header, $(GENERATED_HEADERS), $*/$(header)),) $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V=$(V) TARGET_DIR=$*/ all,) In general we don't have workarounds for something moved directory and this broke builds not from clean Why don't we? It's cheaper than always doing make clean after pull. (source file moved from hw/ to . being one that's bitten me before), Why would that bite anyone? AFAIK files under source control are handled fine. It's the generated ones that are a problem. so why does just this one deserve to get an rm here rather than just asking the user to run 'make clean / distclean' ? -- PMM
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 13:22, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 02:41:33PM +0200, Avi Kivity wrote:
On 03/04/2012 02:38 PM, Blue Swirl wrote:
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
(qemu) info pci
Bus 0, device 5, function 0:
IDE controller: PCI device 1095:0646
IRQ 1.
BAR0: I/O at 0x [0x0006].
BAR1: I/O at 0x [0x0002].
BAR2: I/O at 0x [0x0006].
BAR3: I/O at 0x [0x0002].
BAR4: I/O at 0x [0x000e].
id
The BARs are not initialized, so they aren't accessible.
But perhaps the dump was not taken at the point of failure, can you
provide a relevant dump if so?
No, this is after failure.
I don't see why the guest expects the BARs to work then.
I don't belive it does - it probably got hang before
initializing BARs.
This is later, the crash happens when IDE driver is accessing CMD646
registers after the PCI device is configured.
I changed OpenBIOS to disable any bridges with no devices, but that
didn't help. It looks like this is not related to bridges, I disabled
the secondary bridges with this patch and still there is the crash.
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..ed9dc68 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -256,11 +256,13 @@ static const MemoryRegionOps pci_ioport_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
+#if 0
/* The APB host has an IRQ line for each IRQ line of each slot. */
static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num)
{
return ((pci_dev-devfn 0x18) 1) + irq_num;
}
+#endif
static int pci_pbm_map_irq(PCIDevice *pci_dev, int irq_num)
{
@@ -322,8 +324,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
SysBusDevice *s;
APBState *d;
unsigned int i;
+#if 0
PCIDevice *pci_dev;
PCIBridge *br;
+#endif
/* Ultrasparc PBM main bus */
dev = qdev_create(NULL, pbm);
@@ -352,6 +356,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
pci_create_simple(d-bus, 0, pbm-pci);
+#if 0
/* APB secondary busses */
pci_dev = pci_create_multifunction(d-bus, PCI_DEVFN(1, 0), true,
pbm-bridge);
@@ -368,7 +373,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
pci_apb_map_irq);
qdev_init_nofail(pci_dev-qdev);
*bus3 = pci_bridge_get_sec_bus(br);
-
+#endif
return d-bus;
}
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It looks like Sparc does not reset registers at CPU reset. Nice catch. The following is likely also needed, maybe the define should be shared with apb. diff --git a/hw/sun4u.c b/hw/sun4u.c index 423108f..19a135a 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -81,7 +81,7 @@ #define FW_CFG_SPARC64_HEIGHT (FW_CFG_ARCH_LOCAL + 0x01) #define FW_CFG_SPARC64_DEPTH (FW_CFG_ARCH_LOCAL + 0x02) -#define MAX_PILS 16 +#define MAX_PILS 32 #define TICK_MAX 0x7fffULL
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is
0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
The weird thing is the range type does not seem to be accessed
at all. So I guessed there's some memory corruption here.
Running valgrind shows this:
--4-- WARNING: unhandled syscall: 340
--4-- You may be able to write your own handler.
--4-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4-- Nevertheless we consider this a bug. Please report
--4-- it at http://valgrind.org/support/bug_reports.html.
==4== Invalid read of size 4
==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350)
==4== by 0x2F7A84: sun4uv_init (sun4u.c:779)
==4== by 0x13D716: main (vl.c:3397)
==4== Address 0x156c7d30 is 0 bytes after a block of size 64
alloc'd
==4== at 0x557DD69: malloc (vg_replace_malloc.c:236)
==4== by 0x225F56: malloc_and_trace (vl.c:2156)
==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47)
==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778)
==4== by 0x13D716: main (vl.c:3397)
==4==
apb: here
==4== Warning: client switching stacks? SP change: 0xfec42cbc --
0x16894008
==4== to suppress, use: --max-stackframe=398791500 or
greater
==4== Warning: client switching stacks? SP change: 0x16893fa0 --
0xfec42cc0
==4== to suppress, use: --max-stackframe=398791392 or
greater
==4== Warning: client switching stacks? SP change: 0xfec42fe0 --
0x16893fd0
==4== to suppress, use: --max-stackframe=398790640 or
greater
==4== further instances of this message will not be shown.
QEMU 1.0.50 monitor - type 'help' for more information
(qemu) ==4== Thread 2:
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8351: compute_all_sub (cc_helper.c:37)
==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
Is the above a problem?
It looks like Sparc does not reset registers at CPU reset. Nice catch.
Invalid read and address after block are also worrying.
irqs are allocated with
#define MAX_PILS 16
irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS);
then passed to apb:
pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, pci_bus2,
pci_bus3);
which does:
PCIBus *pci_apb_init(target_phys_addr_t special_base,
target_phys_addr_t mem_base,
qemu_irq *pic, PCIBus **bus2, PCIBus **bus3)
and
for (i = 0; i 32; i++) {
sysbus_connect_irq(s, i, pic[i]);
}
Awful. But using 32 for MAX_PILS does not help either.
I get this with a modified OpenBIOS and no secondary bridges:
OpenBIOS for Sparc64
Initializing PCI host bridge...
pci_host_set_reg reg 01FE 0200
=== CHANGED === package path old=/pci new=/pci@1fe,0
0:0.0 - 108e:a000 - host bridge found - /pci@1fe,0 -
pci_host_set_reg reg 01FE 0200
Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs
On 4 March 2012 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:25:59PM +, Peter Maydell wrote: In general we don't have workarounds for something moved directory and this broke builds not from clean Why don't we? It's cheaper than always doing make clean after pull. That's an argument for a general solution to the problem, not a one-off bandaid fix for the bit that happened to bite you. (source file moved from hw/ to . being one that's bitten me before), Why would that bite anyone? AFAIK files under source control are handled fine. It's the generated ones that are a problem. I forget the exact failure mode but I think the problem is that the old arm-softmmu/foo.d file is still lying around and claims that foo.o depends on the no-longer-present hw/foo.c. (If we didn't squash the directory structure, so that it was arm-softmmu/hw/foo.d and arm-softmmu/hw/foo.o, this problem wouldn't happen.) -- PMM
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 01:33:42PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 13:22, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 02:41:33PM +0200, Avi Kivity wrote:
On 03/04/2012 02:38 PM, Blue Swirl wrote:
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
(qemu) info pci
Bus 0, device 5, function 0:
IDE controller: PCI device 1095:0646
IRQ 1.
BAR0: I/O at 0x [0x0006].
BAR1: I/O at 0x [0x0002].
BAR2: I/O at 0x [0x0006].
BAR3: I/O at 0x [0x0002].
BAR4: I/O at 0x [0x000e].
id
The BARs are not initialized, so they aren't accessible.
But perhaps the dump was not taken at the point of failure, can you
provide a relevant dump if so?
No, this is after failure.
I don't see why the guest expects the BARs to work then.
I don't belive it does - it probably got hang before
initializing BARs.
This is later, the crash happens when IDE driver is accessing CMD646
registers after the PCI device is configured.
I changed OpenBIOS to disable any bridges with no devices, but that
didn't help. It looks like this is not related to bridges, I disabled
the secondary bridges with this patch and still there is the crash.
It seems to have to do with the host bridge.
It's unusual to have host bridge present itself
as a pci to pci bridge but there it is.
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..ed9dc68 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -256,11 +256,13 @@ static const MemoryRegionOps pci_ioport_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
+#if 0
/* The APB host has an IRQ line for each IRQ line of each slot. */
static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num)
{
return ((pci_dev-devfn 0x18) 1) + irq_num;
}
+#endif
static int pci_pbm_map_irq(PCIDevice *pci_dev, int irq_num)
{
@@ -322,8 +324,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
SysBusDevice *s;
APBState *d;
unsigned int i;
+#if 0
PCIDevice *pci_dev;
PCIBridge *br;
+#endif
/* Ultrasparc PBM main bus */
dev = qdev_create(NULL, pbm);
@@ -352,6 +356,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
pci_create_simple(d-bus, 0, pbm-pci);
+#if 0
/* APB secondary busses */
pci_dev = pci_create_multifunction(d-bus, PCI_DEVFN(1, 0), true,
pbm-bridge);
@@ -368,7 +373,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
pci_apb_map_irq);
qdev_init_nofail(pci_dev-qdev);
*bus3 = pci_bridge_get_sec_bus(br);
-
+#endif
return d-bus;
}
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs
On Sun, Mar 04, 2012 at 01:44:26PM +, Peter Maydell wrote: On 4 March 2012 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:25:59PM +, Peter Maydell wrote: In general we don't have workarounds for something moved directory and this broke builds not from clean Why don't we? It's cheaper than always doing make clean after pull. That's an argument for a general solution to the problem, not a one-off bandaid fix for the bit that happened to bite you. What I did is generic: I remove all generated headers. If you see more problems, let me know. (source file moved from hw/ to . being one that's bitten me before), Why would that bite anyone? AFAIK files under source control are handled fine. It's the generated ones that are a problem. I forget the exact failure mode but I think the problem is that the old arm-softmmu/foo.d file is still lying around and claims that foo.o depends on the no-longer-present hw/foo.c. (If we didn't squash the directory structure, so that it was arm-softmmu/hw/foo.d and arm-softmmu/hw/foo.o, this problem wouldn't happen.) -- PMM Aha. A stale .d file, I see. Note that it's siginificantly different from my problem. I would think if .c is newer than .o we should just ignore .d, alternatively make the dependencies in .d somehow weaker than the implicit dependencies so they don't fail the build. I'll see whether I can come up with a solution. -- MST
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com
wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is
0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
The weird thing is the range type does not seem to be accessed
at all. So I guessed there's some memory corruption here.
Running valgrind shows this:
--4-- WARNING: unhandled syscall: 340
--4-- You may be able to write your own handler.
--4-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4-- Nevertheless we consider this a bug. Please report
--4-- it at http://valgrind.org/support/bug_reports.html.
==4== Invalid read of size 4
==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350)
==4== by 0x2F7A84: sun4uv_init (sun4u.c:779)
==4== by 0x13D716: main (vl.c:3397)
==4== Address 0x156c7d30 is 0 bytes after a block of size 64
alloc'd
==4== at 0x557DD69: malloc (vg_replace_malloc.c:236)
==4== by 0x225F56: malloc_and_trace (vl.c:2156)
==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47)
==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778)
==4== by 0x13D716: main (vl.c:3397)
==4==
apb: here
==4== Warning: client switching stacks? SP change: 0xfec42cbc --
0x16894008
==4== to suppress, use: --max-stackframe=398791500 or
greater
==4== Warning: client switching stacks? SP change: 0x16893fa0 --
0xfec42cc0
==4== to suppress, use: --max-stackframe=398791392 or
greater
==4== Warning: client switching stacks? SP change: 0xfec42fe0 --
0x16893fd0
==4== to suppress, use: --max-stackframe=398790640 or
greater
==4== further instances of this message will not be shown.
QEMU 1.0.50 monitor - type 'help' for more information
(qemu) ==4== Thread 2:
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8351: compute_all_sub (cc_helper.c:37)
==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
Is the above a problem?
It looks like Sparc does not reset registers at CPU reset. Nice catch.
Invalid read and address after block are also worrying.
irqs are allocated with
#define MAX_PILS 16
irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS);
then passed to apb:
pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, pci_bus2,
pci_bus3);
which does:
PCIBus *pci_apb_init(target_phys_addr_t special_base,
target_phys_addr_t mem_base,
qemu_irq *pic, PCIBus **bus2, PCIBus **bus3)
and
for (i = 0; i 32; i++) {
sysbus_connect_irq(s, i, pic[i]);
}
Awful. But using 32 for MAX_PILS does not help either.
Could you please clarify what is the SABRE device?
Is it, in fact, a bridge device? Or not?
--
MST
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 14:08, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 01:33:42PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 13:22, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 02:41:33PM +0200, Avi Kivity wrote:
On 03/04/2012 02:38 PM, Blue Swirl wrote:
This unassigned memory exception is triggered because CMD646 IDE I/O
registers are not accessible:
(qemu) info pci
Bus 0, device 5, function 0:
IDE controller: PCI device 1095:0646
IRQ 1.
BAR0: I/O at 0x [0x0006].
BAR1: I/O at 0x [0x0002].
BAR2: I/O at 0x [0x0006].
BAR3: I/O at 0x [0x0002].
BAR4: I/O at 0x [0x000e].
id
The BARs are not initialized, so they aren't accessible.
But perhaps the dump was not taken at the point of failure, can you
provide a relevant dump if so?
No, this is after failure.
I don't see why the guest expects the BARs to work then.
I don't belive it does - it probably got hang before
initializing BARs.
This is later, the crash happens when IDE driver is accessing CMD646
registers after the PCI device is configured.
I changed OpenBIOS to disable any bridges with no devices, but that
didn't help. It looks like this is not related to bridges, I disabled
the secondary bridges with this patch and still there is the crash.
It seems to have to do with the host bridge.
It's unusual to have host bridge present itself
as a pci to pci bridge but there it is.
It looks like the I/O base calculations in OpenBIOS are confused by
host bridge, after that all BARs are wrong. OpenBIOS also thinks that
the host bridge is a device and attempts to configure six BARs instead
of two.
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..ed9dc68 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -256,11 +256,13 @@ static const MemoryRegionOps pci_ioport_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
+#if 0
/* The APB host has an IRQ line for each IRQ line of each slot. */
static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num)
{
return ((pci_dev-devfn 0x18) 1) + irq_num;
}
+#endif
static int pci_pbm_map_irq(PCIDevice *pci_dev, int irq_num)
{
@@ -322,8 +324,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
SysBusDevice *s;
APBState *d;
unsigned int i;
+#if 0
PCIDevice *pci_dev;
PCIBridge *br;
+#endif
/* Ultrasparc PBM main bus */
dev = qdev_create(NULL, pbm);
@@ -352,6 +356,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
pci_create_simple(d-bus, 0, pbm-pci);
+#if 0
/* APB secondary busses */
pci_dev = pci_create_multifunction(d-bus, PCI_DEVFN(1, 0), true,
pbm-bridge);
@@ -368,7 +373,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
pci_apb_map_irq);
qdev_init_nofail(pci_dev-qdev);
*bus3 = pci_bridge_get_sec_bus(br);
-
+#endif
return d-bus;
}
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com
wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is
0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
The weird thing is the range type does not seem to be accessed
at all. So I guessed there's some memory corruption here.
Running valgrind shows this:
--4-- WARNING: unhandled syscall: 340
--4-- You may be able to write your own handler.
--4-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4-- Nevertheless we consider this a bug. Please report
--4-- it at http://valgrind.org/support/bug_reports.html.
==4== Invalid read of size 4
==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350)
==4== by 0x2F7A84: sun4uv_init (sun4u.c:779)
==4== by 0x13D716: main (vl.c:3397)
==4== Address 0x156c7d30 is 0 bytes after a block of size 64
alloc'd
==4== at 0x557DD69: malloc (vg_replace_malloc.c:236)
==4== by 0x225F56: malloc_and_trace (vl.c:2156)
==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47)
==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778)
==4== by 0x13D716: main (vl.c:3397)
==4==
apb: here
==4== Warning: client switching stacks? SP change: 0xfec42cbc --
0x16894008
==4== to suppress, use: --max-stackframe=398791500 or
greater
==4== Warning: client switching stacks? SP change: 0x16893fa0 --
0xfec42cc0
==4== to suppress, use: --max-stackframe=398791392 or
greater
==4== Warning: client switching stacks? SP change: 0xfec42fe0 --
0x16893fd0
==4== to suppress, use: --max-stackframe=398790640 or
greater
==4== further instances of this message will not be shown.
QEMU 1.0.50 monitor - type 'help' for more information
(qemu) ==4== Thread 2:
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8351: compute_all_sub (cc_helper.c:37)
==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
Is the above a problem?
It looks like Sparc does not reset registers at CPU reset. Nice catch.
Invalid read and address after block are also worrying.
irqs are allocated with
#define MAX_PILS 16
irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS);
then passed to apb:
pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, pci_bus2,
pci_bus3);
which does:
PCIBus *pci_apb_init(target_phys_addr_t special_base,
target_phys_addr_t mem_base,
qemu_irq *pic, PCIBus **bus2, PCIBus **bus3)
and
for (i = 0; i 32; i++) {
sysbus_connect_irq(s, i, pic[i]);
}
Awful. But using 32 for MAX_PILS does not help either.
Could you please clarify what is the SABRE device?
Is it, in fact, a bridge device? Or
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com
wrote:
On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com
wrote:
commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced
a regression: we do not make IO base/limit upper 16
bit registers writeable, so we should report a 16 bit
IO range type, not a 32 bit one.
Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32
is 0x1.
In particular, this broke sparc64.
Note: this just reverts to behaviour prior to the patch.
Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
registers writeable should, and seems to, work just as well, but
as no system seems to actually be interested in 32 bit IO,
let's not make unnecessary changes.
Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Mark, can you confirm that this fixes the bug for you?
No, running
qemu-system-sparc64 -serial stdio
still shows black screen and the following on console:
OpenBIOS for Sparc64
Unhandled Exception 0x0032
PC = 0xffd19e18 NPC = 0xffd19e1c
Stopping execution
The weird thing is the range type does not seem to be accessed
at all. So I guessed there's some memory corruption here.
Running valgrind shows this:
--4-- WARNING: unhandled syscall: 340
--4-- You may be able to write your own handler.
--4-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4-- Nevertheless we consider this a bug. Please report
--4-- it at http://valgrind.org/support/bug_reports.html.
==4== Invalid read of size 4
==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350)
==4== by 0x2F7A84: sun4uv_init (sun4u.c:779)
==4== by 0x13D716: main (vl.c:3397)
==4== Address 0x156c7d30 is 0 bytes after a block of size 64
alloc'd
==4== at 0x557DD69: malloc (vg_replace_malloc.c:236)
==4== by 0x225F56: malloc_and_trace (vl.c:2156)
==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8)
==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47)
==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778)
==4== by 0x13D716: main (vl.c:3397)
==4==
apb: here
==4== Warning: client switching stacks? SP change: 0xfec42cbc --
0x16894008
==4== to suppress, use: --max-stackframe=398791500 or
greater
==4== Warning: client switching stacks? SP change: 0x16893fa0 --
0xfec42cc0
==4== to suppress, use: --max-stackframe=398791392 or
greater
==4== Warning: client switching stacks? SP change: 0xfec42fe0 --
0x16893fd0
==4== to suppress, use: --max-stackframe=398790640 or
greater
==4== further instances of this message will not be
shown.
QEMU 1.0.50 monitor - type 'help' for more information
(qemu) ==4== Thread 2:
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8351: compute_all_sub (cc_helper.c:37)
==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
==4== Conditional jump or move depends on uninitialised value(s)
==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295)
==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473)
==4== by 0x9AD9A19: ???
==4==
Is the above a problem?
It looks like Sparc does not reset registers at CPU reset. Nice catch.
Invalid read and address after block are also worrying.
irqs are allocated with
#define MAX_PILS 16
irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS);
then passed to apb:
pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, pci_bus2,
pci_bus3);
which does:
PCIBus *pci_apb_init(target_phys_addr_t special_base,
target_phys_addr_t mem_base,
qemu_irq *pic, PCIBus **bus2, PCIBus **bus3)
and
for (i = 0; i 32; i++) {
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: Yes, it's the host bridge, also known as PBM. It's documented in UltraSPARC IIi User's Manual and there it says that the device is found in the configuration space. So it seems I can make things work if I disable is_bridge and make some bits in BAR4 writeable: pci_set_long(d-wmask + 0x20, 0x); I don't yet know why, and the manual says there should be no BARs. The secondary bridges are Simbas and should be called APBs. -- MST
Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs
Am 04.03.2012 10:10, schrieb Michael S. Tsirkin: I ended up with qmp-commands.h in target directories, which makes build fail as it is found before the main header. make clean fixes it, but it might get triggered again when we make some header target-independent next. It's easy to just make sure all such leftovers are removed, so let's do this. Signed-off-by: Michael S. Tsirkin m...@redhat.com diff --git a/Makefile b/Makefile index e66e885..958a414 100644 --- a/Makefile +++ b/Makefile @@ -89,6 +89,7 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) subdir-%: $(GENERATED_HEADERS) + $(call quiet-command,rm -f $(foreach header, $(GENERATED_HEADERS), $*/$(header)),) Nack. While this happens to fix an issue you encountered this is just plain wrong and dangerous. It takes a list of currently generated headers in the main directory and deletes them in all target folders on every compile; it's not forbidden to have a header of the same name in both directories, whether generated or not. I am all for making make clean do what it claims though. The real solution to this problem would be to make sure by careful review not to move files around in such a conflicting way (rename them instead) rather than posting a note to please run make clean or make distclean (which is fine if you have to do it once, bothersome for multiple repos, and unhelpful for bisecting). Andreas $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V=$(V) TARGET_DIR=$*/ all,) ifneq ($(wildcard config-host.mak),) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] restart a coroutine?
On 03/04/2012 02:41 PM, Michael Tokarev wrote: Since all block (bdrv) layer is now implemented using coroutines, I thought I'd give it a try. But immediately hit a question to which I don't know a good answer. Suppose we've some networking block device (like NBD) and want to be able to support reconnection - this is actually very useful feature, in order to be able to reboot/restart the NBD server without a need to restart all the clients. For this to work, we should have an ability to reconnect to the server and re-issue all requests which were waiting for reply. Traditionally, in asyncronous event-loop-based scheme, this is implemented as a queue of requests linked to the block driver state structure, and in case of reconnection we just walk over all requests and requeue these. But if the block driver is implemented as a set of coroutines (like nbd currently does), I see no sane/safe way to restart the requests. Setjmp/longjmp can be uses with extra care there, but with these it is extremly fragile. Any hints on how to do that? From the block layer's point of view, the requests should still be pending. For example, if a read request sees a dropped connection, it adds itself to a list of coroutines waiting for a reconnect, wakes up a connection manager coroutine (or thread), and sleeps. The connection manager periodically tries to connect, and if it succeeds, it wakes up the coroutines waiting for a reconnection. It's important to implement request cancellation correctly here, or we can end up with a device that cannot be unplugged or a guest that cannot be shutdown. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 02:26:13PM +, Blue Swirl wrote:
It seems to have to do with the host bridge.
It's unusual to have host bridge present itself
as a pci to pci bridge but there it is.
It looks like the I/O base calculations in OpenBIOS are confused
Where's the source for that, BTW? Have build instructions?
by
host bridge, after that all BARs are wrong. OpenBIOS also thinks that
the host bridge is a device and attempts to configure six BARs instead
of two.
According to the spec it is a device, so should be ok?
If I just make BAR4 writeable we get past the
bios screen at least.
Maybe openbios gets confused if a device has no BARs?
Do things work for you with the patch below?
All it does is make BAR4 writeable, accesses go nowhere.
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..fae841f 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d)
pci_set_word(d-config + PCI_STATUS,
PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
PCI_STATUS_DEVSEL_MEDIUM);
+pci_set_long(d-wmask + 0x20, 0xfff0);
return 0;
}
@@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass,
void *data)
k-vendor_id = PCI_VENDOR_ID_SUN;
k-device_id = PCI_DEVICE_ID_SUN_SABRE;
k-class_id = PCI_CLASS_BRIDGE_HOST;
-k-is_bridge = 1;
}
static TypeInfo pbm_pci_host_info = {
--
MST
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? For the record, I am hoping to get rid of some of those cpu.h defines in a later stage of QOM'ification. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs
On Sun, Mar 04, 2012 at 05:03:14PM +0100, Andreas Färber wrote: Am 04.03.2012 10:10, schrieb Michael S. Tsirkin: I ended up with qmp-commands.h in target directories, which makes build fail as it is found before the main header. make clean fixes it, but it might get triggered again when we make some header target-independent next. It's easy to just make sure all such leftovers are removed, so let's do this. Signed-off-by: Michael S. Tsirkin m...@redhat.com diff --git a/Makefile b/Makefile index e66e885..958a414 100644 --- a/Makefile +++ b/Makefile @@ -89,6 +89,7 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) subdir-%: $(GENERATED_HEADERS) + $(call quiet-command,rm -f $(foreach header, $(GENERATED_HEADERS), $*/$(header)),) Nack. While this happens to fix an issue you encountered this is just plain wrong and dangerous. It takes a list of currently generated headers in the main directory and deletes them in all target folders on every compile; it's not forbidden to have a header of the same name in both directories, whether generated or not. Yes it is Forbidden. With a big F. And the reason is that it will break the build in a very confusing way. So if you do this silly thing, you pay the price, and this is way better than everyone who tries to build the tree pays the price. I am all for making make clean do what it claims though. The real solution to this problem would be to make sure by careful review not to move files around in such a conflicting way (rename them instead) Too late for current tree. There are many such conflicts. rather than posting a note to please run make clean or make distclean (which is fine if you have to do it once, bothersome for multiple repos, and unhelpful for bisecting). Andreas This means that a file name that was generated somewhere in the hierarchy at any point in the past can never be generated again anywhere else. That's impractical. $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V=$(V) TARGET_DIR=$*/ all,) ifneq ($(wildcard config-host.mak),) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] seabios: acpi: Add _STA for PCI hotplug slots
On Fri, Feb 24, 2012 at 04:21:17PM -0700, Alex Williamson wrote: When a Status method is provided on a slot, the OSPM evaluates _STA in response to the device check notify on the slot. This allows some degree of a handshake between the platform and the OSPM that the hotplug has been acknowledged. In order to implement _STA, we need to know which slots have devices. A slot with device returns 0x0F, a slot without a device returns Zero. We get this information from Qemu using the 0xae08 I/O port register. This was previously the read-side of the register written to commit a device eject and always returned 0 on read. It now returns a bitmap of present slots, so we know that reading 0 means we have and old Qemu and dynamically modify our SSDT to rename the _STA methods. This is necessary to allow backwards compatibility. The _STA method also writes the slot identifier to I/O port register 0xae00 as an acknowledgment of the hotplug request. Thanks. The patch looks fine to me. However, since I'm not all that familiar with the details of the qemu/kvm support for this, I'd like to see an Ack from one of the qemu or kvm maintainers. -Kevin
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It looks like Sparc does not reset registers at CPU reset. Nice catch. Invalid read and address after block are also worrying. irqs are allocated with #define MAX_PILS 16 irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); then passed to apb: pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, pci_bus2, pci_bus3); which does: PCIBus *pci_apb_init(target_phys_addr_t special_base, target_phys_addr_t mem_base,
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 05:07:34PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It looks like Sparc does not reset registers at CPU reset. Nice catch. Invalid read and address after block are also worrying. irqs are allocated with #define MAX_PILS 16 irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); then passed to apb: pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq,
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 16:42, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 02:26:13PM +, Blue Swirl wrote:
It seems to have to do with the host bridge.
It's unusual to have host bridge present itself
as a pci to pci bridge but there it is.
It looks like the I/O base calculations in OpenBIOS are confused
Where's the source for that, BTW? Have build instructions?
Under roms/openbios or www.openbios.org. You need xsltproc.
../config/scripts/switch-arch sparc64
make build-verbose
qemu-system-sparc64 -bios obj-sparc64/openbios-builtin.elf.nostrip
by
host bridge, after that all BARs are wrong. OpenBIOS also thinks that
the host bridge is a device and attempts to configure six BARs instead
of two.
According to the spec it is a device, so should be ok?
If I just make BAR4 writeable we get past the
bios screen at least.
Maybe openbios gets confused if a device has no BARs?
Do things work for you with the patch below?
All it does is make BAR4 writeable, accesses go nowhere.
Looking at serial console, there is no crash, but VGA still does not work.
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..fae841f 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d)
pci_set_word(d-config + PCI_STATUS,
PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
PCI_STATUS_DEVSEL_MEDIUM);
+ pci_set_long(d-wmask + 0x20, 0xfff0);
return 0;
}
@@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass,
void *data)
k-vendor_id = PCI_VENDOR_ID_SUN;
k-device_id = PCI_DEVICE_ID_SUN_SABRE;
k-class_id = PCI_CLASS_BRIDGE_HOST;
- k-is_bridge = 1;
}
static TypeInfo pbm_pci_host_info = {
--
MST
[Qemu-devel] PPC: VGA broken in git master
Hi all, I've just done a git pull to update my local repository, and it now appears that the VGA device is broken in QEMU - rather than displaying the OpenBIOS banner in my VNC client, the framebuffer remains constantly black. A git bisect shows that the problem is caused by the following commit: de58ac72b6a062d1a61478284c0c0f8a0428613e is the first bad commit commit de58ac72b6a062d1a61478284c0c0f8a0428613e Author: Avi Kivity a...@redhat.com Date: Sun Jan 8 19:46:17 2012 +0200 ioport: change portio_list not to use memory_region_set_offset() memory_region_set_offset() will be going away soon, so don't use it. Use an alias instead. Signed-off-by: Avi Kivity a...@redhat.com Reviewed-by: Richard Henderson r...@twiddle.net Avi/Richard - please would it be possible for you to review this commit and come up with a suitable fix? Many thanks, Mark.
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On 04/03/12 17:49, Blue Swirl wrote: According to the spec it is a device, so should be ok? If I just make BAR4 writeable we get past the bios screen at least. Maybe openbios gets confused if a device has no BARs? Do things work for you with the patch below? All it does is make BAR4 writeable, accesses go nowhere. Looking at serial console, there is no crash, but VGA still does not work. Note that I've just emailed the list about a VGA regression I've found on PPC caused by one of Avi's commits - perhaps Michael's fix does work, but you're being bitten by the same bug? ATB, Mark.
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On 04.03.2012, at 17:46, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Assert for what? Linux page size of 64k is something perfectly normal on ppc. The hardware can always do at least 4k maps however. Alex For the record, I am hoping to get rid of some of those cpu.h defines in a later stage of QOM'ification. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] seabios: acpi: Add _STA for PCI hotplug slots
On Fri, Feb 24, 2012 at 04:21:17PM -0700, Alex Williamson wrote:
When a Status method is provided on a slot, the OSPM evaluates
_STA in response to the device check notify on the slot. This
allows some degree of a handshake between the platform and the
OSPM that the hotplug has been acknowledged.
In order to implement _STA, we need to know which slots have
devices. A slot with device returns 0x0F, a slot without a
device returns Zero. We get this information from Qemu using
the 0xae08 I/O port register. This was previously the read-side
of the register written to commit a device eject and always
returned 0 on read. It now returns a bitmap of present slots,
so we know that reading 0 means we have and old Qemu and
dynamically modify our SSDT to rename the _STA methods. This
is necessary to allow backwards compatibility.
Interesting. Isn't the UP register sufficient for _STA?
Assuming we want to implement _STA - for which
the only motivation seems the handshake hack below.
The _STA method also writes the slot identifier to I/O port
register 0xae00 as an acknowledgment of the hotplug request.
This part looks a bit like a hack.
_STA is not intended as an acknowledgement - it's a query for state.
ACPI spec 5.0 requires that _STA is called before _INI,
but ACPI 1.0b doesn't. Did you try some 1.0 OSPMs (e.g. XP)
to see what they do?
I also think I see how this can cause a race, see below.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Your description of the qemu patches made me think
that all you really want is detect an OS without
OSPM. If that is the case, I would suggest adding
an _INI method at top level as a simpler and more robust
procedure.
Otherwise, how about implementing _PS0
(and probably _PS3) to manage slot power?
Maybe this what you are really after, and it
seems like a better interface than 'acknowledge'
which does not seem to make sense for real hardware.
---
src/acpi-dsdt.dsl | 36 ++-
src/acpi-dsdt.hex | 124 ++
src/acpi.c | 27 ++
src/ssdt-pcihp.dsl |3
src/ssdt-pcihp.hex | 658
5 files changed, 686 insertions(+), 162 deletions(-)
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 7082b65..6b87086 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -119,17 +119,15 @@ DefinitionBlock (
prt_slot3(0x001f),
})
-OperationRegion(PCST, SystemIO, 0xae00, 0x08)
+OperationRegion(PCST, SystemIO, 0xae00, 0x0c)
Field (PCST, DWordAcc, NoLock, WriteAsZeros)
{
-PCIU, 32,
-PCID, 32,
-}
-
-OperationRegion(SEJ, SystemIO, 0xae08, 0x04)
-Field (SEJ, DWordAcc, NoLock, WriteAsZeros)
-{
-B0EJ, 32,
+// PCI Up/ACK
+PUPA, 32,
+// PCI Down
+PDWN, 32,
+// PCI Present/Eject
+PPEJ, 32,
Note on the comment: this only affects bus0 not all of PCI.
}
Name (_CRS, ResourceTemplate ()
@@ -462,10 +460,20 @@ DefinitionBlock (
/* Methods called by hotplug devices */
Method (PCEJ, 1, NotSerialized) {
// _EJ0 method - eject callback
-Store(ShiftLeft(1, Arg0), B0EJ)
+Store(ShiftLeft(1, Arg0), PPEJ)
Return (0x0)
}
+Method (PSTA, 1, NotSerialized) {
+Store(ShiftLeft(1, Arg0), PUPA)
So this looks wrong to me.
Specifically _STA is also called at the end after _EJ0.
If the device is ejected then insterted, you
get a window where _STA is called and hardware
will think insertion was acknowledged, while in fact
ejection was acknowledged.
I also think a request for the OS to rescan the bus
will trigger _STA calls. Same race can get triggered.
+Store(PPEJ, Local0)
+If (And(Local0, ShiftLeft(1, Arg0))) {
+Return(0x0F)
+} Else {
+Return(Zero)
+}
+}
+
/* Hotplug notification method supplied by SSDT */
External (\_SB.PCI0.PCNT, MethodObj)
@@ -473,12 +481,16 @@ DefinitionBlock (
Method(PCNF, 0) {
// Local0 = iterator
Store (Zero, Local0)
+// Local1 = slots marked up
+Store (PUPA, Local1)
+// Local2 = slots marked down
+Store (PDWN, Local2)
While (LLess(Local0, 31)) {
Increment(Local0)
-If (And(PCIU, ShiftLeft(1, Local0))) {
+If (And(Local1, ShiftLeft(1, Local0))) {
PCNT(Local0, 1)
}
-If (And(PCID, ShiftLeft(1, Local0))) {
+If (And(Local2, ShiftLeft(1, Local0))) {
PCNT(Local0, 3)
}
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 05:49:04PM +, Blue Swirl wrote:
On Sun, Mar 4, 2012 at 16:42, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 04, 2012 at 02:26:13PM +, Blue Swirl wrote:
It seems to have to do with the host bridge.
It's unusual to have host bridge present itself
as a pci to pci bridge but there it is.
It looks like the I/O base calculations in OpenBIOS are confused
Where's the source for that, BTW? Have build instructions?
Under roms/openbios or www.openbios.org. You need xsltproc.
../config/scripts/switch-arch sparc64
make build-verbose
qemu-system-sparc64 -bios obj-sparc64/openbios-builtin.elf.nostrip
I don't see anything obviously wrong in there, but
the behaviour does seem to indicate some firmware bug ...
I don't have the right toolchain - care debugging?
by
host bridge, after that all BARs are wrong. OpenBIOS also thinks that
the host bridge is a device and attempts to configure six BARs instead
of two.
According to the spec it is a device, so should be ok?
If I just make BAR4 writeable we get past the
bios screen at least.
Maybe openbios gets confused if a device has no BARs?
Do things work for you with the patch below?
All it does is make BAR4 writeable, accesses go nowhere.
Looking at serial console, there is no crash, but VGA still does not work.
What do info pci/ifo mtree show now?
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..fae841f 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d)
pci_set_word(d-config + PCI_STATUS,
PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
PCI_STATUS_DEVSEL_MEDIUM);
+ pci_set_long(d-wmask + 0x20, 0xfff0);
return 0;
}
@@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass,
void *data)
k-vendor_id = PCI_VENDOR_ID_SUN;
k-device_id = PCI_DEVICE_ID_SUN_SABRE;
k-class_id = PCI_CLASS_BRIDGE_HOST;
- k-is_bridge = 1;
}
static TypeInfo pbm_pci_host_info = {
--
MST
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 06:11:20PM +, Mark Cave-Ayland wrote: On 04/03/12 17:49, Blue Swirl wrote: According to the spec it is a device, so should be ok? If I just make BAR4 writeable we get past the bios screen at least. Maybe openbios gets confused if a device has no BARs? Do things work for you with the patch below? All it does is make BAR4 writeable, accesses go nowhere. Looking at serial console, there is no crash, but VGA still does not work. Note that I've just emailed the list about a VGA regression I've found on PPC caused by one of Avi's commits - perhaps Michael's fix does work, but you're being bitten by the same bug? ATB, Mark. It's not a fix as such - just a hack to see what makes bios crash. -- MST
Re: [Qemu-devel] [Seabios] [PATCH 0/6] 64bit PCI BARs allocations (take 2)
On Thu, Mar 01, 2012 at 06:50:43PM +1300, Alexey Korolev wrote: Hi, This patch series enables 64bit BAR support in seabios. It has a bit different approach for resources accounting, We did this because we wanted: a) Provide 64bit bar support for PCI BARs and bridges with 64bit memory window. b) Allow migration to 64bit bit ranges if we did not fit into 32bit range c) Keep implementation simple. Hrmm. By my count, this would be the third rewrite of the PCI bar initialization in the last 14 months. [...] The patch series includes 6 patches. In the 1st patch we introduce new structures. Patch 1 does not look like it will compile independently. There is no point in breaking up patches if each part doesn't compile. In the 2nd patch we introduce support functions for basic hlist operations, plus modify service functions to support 64bits address ranges. Note: I've seen similar hlist operations in post memory manager and stack location operations, it makes sense to move them to a header file. In the 3rd patch a new function to fill pci_region structures with entries, and discover topology is added. In the 4th patch we define address range for pci_region structure, migrate entries to 64bits address range if necessary, and program PCI BAR addresses and bridge regions. In the 6th patch we clear old code. Given the churn in this area, I don't want to commit patches that do wholesale code replacement. I'd prefer to see each patch independently add some functionality and perform its related cleanup. Also, since Gerd has some patches pending in this area, we should figure out which direction makes sense. Can you explain on how this 64bit support is different from the support proposed by Gerd? Thanks, -Kevin
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 06:11:20PM +, Mark Cave-Ayland wrote: On 04/03/12 17:49, Blue Swirl wrote: According to the spec it is a device, so should be ok? If I just make BAR4 writeable we get past the bios screen at least. Maybe openbios gets confused if a device has no BARs? Do things work for you with the patch below? All it does is make BAR4 writeable, accesses go nowhere. Looking at serial console, there is no crash, but VGA still does not work. Note that I've just emailed the list about a VGA regression I've found on PPC caused by one of Avi's commits - perhaps Michael's fix does work, but you're being bitten by the same bug? ATB, Mark. Can you pls try applying my patch on top of old tree where VGA did work, and see what happens? -- MST
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 05:07:34PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It looks like Sparc does not reset registers at CPU reset. Nice catch. Invalid read and address after block are also worrying. irqs are allocated with #define MAX_PILS 16 irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); then passed to apb:
Re: [Qemu-devel] restart a coroutine?
On 04.03.2012 20:08, Avi Kivity wrote:
On 03/04/2012 02:41 PM, Michael Tokarev wrote:
Since all block (bdrv) layer is now implemented using
coroutines, I thought I'd give it a try. But immediately
hit a question to which I don't know a good answer.
Suppose we've some networking block device (like NBD) and
want to be able to support reconnection - this is actually
very useful feature, in order to be able to reboot/restart
the NBD server without a need to restart all the clients.
For this to work, we should have an ability to reconnect
to the server and re-issue all requests which were waiting
for reply.
Traditionally, in asyncronous event-loop-based scheme, this
is implemented as a queue of requests linked to the block
driver state structure, and in case of reconnection we just
walk over all requests and requeue these.
But if the block driver is implemented as a set of coroutines
(like nbd currently does), I see no sane/safe way to restart
the requests. Setjmp/longjmp can be uses with extra care
there, but with these it is extremly fragile.
Any hints on how to do that?
From the block layer's point of view, the requests should still be
pending. For example, if a read request sees a dropped connection, it
adds itself to a list of coroutines waiting for a reconnect, wakes up a
connection manager coroutine (or thread), and sleeps. The connection
manager periodically tries to connect, and if it succeeds, it wakes up
the coroutines waiting for a reconnection.
This is all fine, except of one thing: restarting (resending) of
the requests which has been sent to the remote and for which we
were waiting for reply already.
For these requests, they should be resent using new socket, when
the connection manager wakes corresponding coroutine up. That's
where my question comes.
The request handling coroutine looks like regular function
(pseudocode):
offset = 0;
while(offset sendsize) {
ret = send(sock, senddata+offset, sendsize-offset);
if (EAGAIN) { coroutine_yeld(); continue; }
if (ret 0) return -EIO;
offset += ret;
}
offset = 0;
while(offset recvsize) {
ret = recv(sock, recvdata+offset, recvsize-offset);
if (EAGAIN) { coroutine_yeld(); continue; }
if (ret 0) return -EIO;
offset += ret;
}
return status(recvdata);
This function will need to have a ton of goto begin in all places
where it calls yeld() -- in order to actually start _sending_ the
request to the new sock after a reconnect. It is all good when it
is in one function, but if the code is split into several functions,
it becomes very clumsy, to a point where regular asyncronous state
machine bay be more appropriate. It also requires to open-code all
helper functions (like qiov handlers).
So I was asking if it can be done using a setjmp/longjmp maybe, to
simplify it all somehow.
It's important to implement request cancellation correctly here, or we
can end up with a device that cannot be unplugged or a guest that cannot
be shutdown.
Is there some mechanism to cancel bdrv_co_{read,write}v()? I see a
way to cancel bdrv_aio_{read,write}v(), but even these are now
implemented as coroutines...
Thanks!
/mjt
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 07:51:02PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 05:07:34PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It looks like Sparc does not reset registers at CPU reset. Nice catch.
[Qemu-devel] XP install cores with SCSI LSI 53C895A disks
Hello, Clean XP install cores with SCSI LSI 53C89A disk when copying files. Reproduceable. Driver used is sym_hi. Details are below. Tried also old versions 1.0, 0.15.1, cores too. Any ideas? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ Image created with: qemu-img create -f qcow2 XP-TEST.qcow2 10G Command line: Version: git b5ed4b6f6f0d31e0d8210f4b444ba67bfa5d6de2 /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive file=VM-XP-TEST/XP-TEST.qcow2,media=disk,if=scsi,bus=0,unit=0 -cdrom ISO/XP.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -option-rom BIOS/V4.19/8xx_64.rom -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 #0 0x7f66a29e5117 in malloc_consolidate.part.3 () from /lib64/libc.so.6 #1 0x7f66a29e5e99 in _int_free () from /lib64/libc.so.6 #2 0x7f66a64a1444 in scsi_req_unref (req=0x7f66a9791f70) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272 #3 scsi_req_unref (req=0x7f66a9791f70) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268 #4 0x7f66a64a2445 in scsi_device_purge_requests (sdev=0x7f66a9616160, sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421 #5 0x7f66a64a2d27 in scsi_disk_reset (dev=0x7f66a9616160) at /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498 #6 0x7f66a643dd60 in lsi_reg_writeb (s=0x7f66a95fa140, offset=optimized out, val=optimized out)at /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684 #7 0x7f66a65187a0 in access_with_adjusted_size (addr=1, value=0x7f669f3ecbb0, size=1, access_size_min=optimized out,access_size_max=optimized out, access=0x7f66a65186c0 memory_region_write_accessor, opaque=0x7f66a95fa5a8)at /root/download/qemu/git/qemu-kvm/memory.c:304 #8 0x7f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f66a95fa5a8) at /root/download/qemu/git/qemu-kvm/memory.c:982 #9 io_mem_write (io_index=optimized out, addr=1, val=optimized out, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564 #10 0x7f66a65187a0 in access_with_adjusted_size (addr=1, value=0x7f669f3ecc60, size=1, access_size_min=optimized out,access_size_max=optimized out, access=0x7f66a65186c0 memory_region_write_accessor, opaque=0x7f669801bae0)at /root/download/qemu/git/qemu-kvm/memory.c:304 #11 0x7f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f669801bae0) at /root/download/qemu/git/qemu-kvm/memory.c:982 #12 io_mem_write (io_index=optimized out, addr=1, val=optimized out, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564 #13 0x7f66a64efe58 in cpu_physical_memory_rw (addr=4273938433, buf=0x7f66a6319028 Address 0x7f66a6319028 out of bounds, len=1, is_write=1)at /root/download/qemu/git/qemu-kvm/exec.c:3594 #14 0x7f66a650d195 in kvm_cpu_exec (env=0x7f66a8d52900) at /root/download/qemu/git/qemu-kvm/kvm-all.c:1192 #15 0x7f66a64e3201 in qemu_kvm_cpu_thread_fn (arg=0x7f66a8d52900) at /root/download/qemu/git/qemu-kvm/cpus.c:732 #16 0x7f66a47bbd90 in start_thread () from /lib64/libpthread.so.0 #17 0x7f66a2a57f5d in clone () from /lib64/libc.so.6 (gdb) back #0 0x7f66efb81285 in raise () from /lib64/libc.so.6 #1 0x7f66efb82b9b in abort () from /lib64/libc.so.6 #2 0x7f66efbc2a7e in __libc_message () from /lib64/libc.so.6 #3 0x7f66efbc8da6 in malloc_printerr () from /lib64/libc.so.6 #4 0x7f66efbc9279 in malloc_consolidate.part.3 () from /lib64/libc.so.6 #5 0x7f66efbc9e99 in _int_free () from /lib64/libc.so.6 #6 0x7f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272 #7 scsi_req_unref (req=0x7f66f6db1bc0) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268 #8 0x7f66f3686445 in scsi_device_purge_requests (sdev=0x7f66f6b8e160, sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421 #9 0x7f66f3686d27 in scsi_disk_reset (dev=0x7f66f6b8e160) at /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498 #10 0x7f66f3621d60 in lsi_reg_writeb (s=0x7f66f6b72140, offset=optimized out, val=optimized out)at /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684 #11 0x7f66f36fc7a0 in access_with_adjusted_size (addr=1, value=0x7f66ec5d0bb0, size=1, access_size_min=optimized out,access_size_max=optimized out, access=0x7f66f36fc6c0 memory_region_write_accessor, opaque=0x7f66f6b725a8)at /root/download/qemu/git/qemu-kvm/memory.c:304 #12 0x7f66f37011a0 in
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
Am 04.03.2012 19:46, schrieb Alexander Graf: On 04.03.2012, at 17:46, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Assert for what? Linux page size of 64k is something perfectly normal on ppc. The hardware can always do at least 4k maps however. g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On 04.03.2012, at 21:21, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 19:46, schrieb Alexander Graf: On 04.03.2012, at 17:46, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Assert for what? Linux page size of 64k is something perfectly normal on ppc. The hardware can always do at least 4k maps however. g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. What I'm trying to tell you is that it's the default case on book3s ppc! ;) Alex
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
Am 04.03.2012 21:25, schrieb Alexander Graf: On 04.03.2012, at 21:21, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 19:46, schrieb Alexander Graf: On 04.03.2012, at 17:46, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Assert for what? Linux page size of 64k is something perfectly normal on ppc. The hardware can always do at least 4k maps however. g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. What I'm trying to tell you is that it's the default case on book3s ppc! ;) Exactly, which is why I'm saying just ignore the weird embedded case. :) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH v4 1/3] kvmclock: Always register type
Currently, the kvmclock type is only registered when kvm_enabled().
This breaks when moving type registration to before command line
parsing (so that QOM types can be used for CPU and machine).
Since the QOM classes are lazy-initialized anyway and kvmclock_create()
has another kvm_enabled() check, simply drop the KVM check in
kvmclock_register_types().
kvm-i8259, kvm-apic and kvm-ioapic do not suffer from such a check.
Signed-off-by: Andreas Färber afaer...@suse.de
Reviewed-by: Jan Kiszka jan.kis...@siemens.com
Cc: Marcelo Tosatti mtosa...@redhat.com
---
hw/kvm/clock.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
index 2157340..446bd62 100644
--- a/hw/kvm/clock.c
+++ b/hw/kvm/clock.c
@@ -121,9 +121,7 @@ void kvmclock_create(void)
static void kvmclock_register_types(void)
{
-if (kvm_enabled()) {
type_register_static(kvmclock_info);
-}
}
type_init(kvmclock_register_types)
--
1.7.7
[Qemu-devel] [PATCH v4 2/3] qom: Register QOM infrastructure early
The constructors for QOM TYPE_INTERFACE were executed rather late in
vl.c's main(). Call them very early so that QOM can safely be used for
machines and CPUs.
Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori anth...@codemonkey.ws
---
vl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 97ab2b9..3fb9182 100644
--- a/vl.c
+++ b/vl.c
@@ -2299,6 +2299,8 @@ int main(int argc, char **argv, char **envp)
#endif
}
+module_call_init(MODULE_INIT_QOM);
+
runstate_init();
init_clocks();
@@ -3460,8 +3462,6 @@ int main(int argc, char **argv, char **envp)
if (foreach_device_config(DEV_DEBUGCON, debugcon_parse) 0)
exit(1);
-module_call_init(MODULE_INIT_QOM);
-
/* must be after qdev registration but before machine init */
if (vga_model) {
select_vgahw(vga_model);
--
1.7.7
[Qemu-devel] [PATCH v4 3/3] qom: Add QOM support to user emulators
Link the Object base class and the module infrastructure for class registration. Introduce $(universal-obj-y) for objects that are more common than $(common-obj-y), so that those only get built once. Call QOM module init for type registration. Signed-off-by: Andreas Färber afaer...@suse.de Cc: Anthony Liguori anth...@codemonkey.ws --- Makefile |6 +++--- Makefile.objs | 23 ++- Makefile.target|4 Makefile.user |1 + bsd-user/main.c|2 ++ darwin-user/main.c |3 +++ linux-user/main.c |2 ++ qemu-user.c| 37 + 8 files changed, 70 insertions(+), 8 deletions(-) create mode 100644 qemu-user.c diff --git a/Makefile b/Makefile index 49c775b..cc24fea 100644 --- a/Makefile +++ b/Makefile @@ -97,12 +97,12 @@ ifneq ($(wildcard config-host.mak),) include $(SRC_PATH)/Makefile.objs endif -$(common-obj-y): $(GENERATED_HEADERS) +$(universal-obj-y) $(common-obj-y): $(GENERATED_HEADERS) subdir-libcacard: $(oslib-obj-y) $(trace-obj-y) qemu-timer-common.o -$(filter %-softmmu,$(SUBDIR_RULES)): $(trace-obj-y) $(common-obj-y) subdir-libdis +$(filter %-softmmu,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) $(common-obj-y) subdir-libdis -$(filter %-user,$(SUBDIR_RULES)): $(GENERATED_HEADERS) $(trace-obj-y) subdir-libdis-user subdir-libuser +$(filter %-user,$(SUBDIR_RULES)): $(GENERATED_HEADERS) $(universal-obj-y) $(trace-obj-y) subdir-libdis-user subdir-libuser ROMSUBDIR_RULES=$(patsubst %,romsubdir-%, $(ROMS)) romsubdir-%: diff --git a/Makefile.objs b/Makefile.objs index 808de6a..f912fbb 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -1,9 +1,22 @@ ### +# Target-independent parts used in system and user emulation +universal-obj-y = + +### # QObject qobject-obj-y = qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o qobject-obj-y += qjson.o json-lexer.o json-streamer.o json-parser.o qobject-obj-y += qerror.o error.o qemu-error.o +universal-obj-y += $(qobject-obj-y) + +### +# QOM +include $(SRC_PATH)/qom/Makefile +qom-obj-y = $(addprefix qom/, $(qom-y)) + +universal-obj-y += $(qom-obj-y) + ### # oslib-obj-y is code depending on the OS (win32 vs posix) oslib-obj-y = osdep.o @@ -76,7 +89,6 @@ fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) common-obj-y = $(block-obj-y) blockdev.o common-obj-y += $(net-obj-y) -common-obj-y += $(qobject-obj-y) common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) common-obj-y += readline.o console.o cursor.o common-obj-y += $(oslib-obj-y) @@ -124,9 +136,6 @@ common-obj-$(CONFIG_WIN32) += version.o common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o ui/spice-display.o spice-qemu-char.o -include $(SRC_PATH)/qom/Makefile -common-obj-y += $(addprefix qom/, $(qom-y)) - audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o audio-obj-$(CONFIG_SDL) += sdlaudio.o audio-obj-$(CONFIG_OSS) += ossaudio.o @@ -182,6 +191,8 @@ user-obj-y = user-obj-y += envlist.o path.o user-obj-y += tcg-runtime.o host-utils.o user-obj-y += cutils.o cache-utils.o +user-obj-y += module.o +user-obj-y += qemu-user.o user-obj-y += $(trace-obj-y) ## @@ -418,9 +429,11 @@ qapi-nested-y += qmp-output-visitor.o qmp-registry.o qmp-dispatch.o qapi-nested-y += string-input-visitor.o string-output-visitor.o qapi-obj-y = $(addprefix qapi/, $(qapi-nested-y)) -common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o $(qapi-obj-y) +common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o common-obj-y += qmp.o hmp.o +universal-obj-y += $(qapi-obj-y) + ## # guest agent diff --git a/Makefile.target b/Makefile.target index 343eb78..ac4ebfe 100644 --- a/Makefile.target +++ b/Makefile.target @@ -136,6 +136,7 @@ obj-m68k-y += m68k-sim.o m68k-semi.o $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS) +obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) obj-y += $(addprefix ../libdis-user/, $(libdis-y)) obj-y += $(libobj-y) @@ -163,6 +164,7 @@ obj-i386-y += ioport-user.o $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS) +obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) obj-y += $(addprefix ../libdis-user/, $(libdis-y)) obj-y += $(libobj-y) @@ -185,6 +187,7 @@ obj-i386-y += ioport-user.o $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS) +obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) obj-y += $(addprefix ../libdis-user/, $(libdis-y)) obj-y +=
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 20:02, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 07:51:02PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 05:07:34PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4== Is the above a problem? It
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On 04.03.2012, at 21:31, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 21:25, schrieb Alexander Graf: On 04.03.2012, at 21:21, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 19:46, schrieb Alexander Graf: On 04.03.2012, at 17:46, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Assert for what? Linux page size of 64k is something perfectly normal on ppc. The hardware can always do at least 4k maps however. g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. What I'm trying to tell you is that it's the default case on book3s ppc! ;) Exactly, which is why I'm saying just ignore the weird embedded case. :) Ugh. Sorry, apparently I can't read :). So you're saying 'break for ppcemb'. Hrm. Not sure that'd be all that great for 440, since there host pagesize is still 4k, but T_P_S is 1k. Alex Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH v4 0/3] Prepare QOM support for machines and CPU
Hello Anthony, This series prepares for QOM'ification of CPUs and machines by rearranging constructor calls and Makefile dependency rules. I've separated it out due to complaints about patch series length for conversion of all targets. Patch 1 is a RESEND that avoids an abort after patch 2. Patch 2 rearranges module init for QOM in the system emulators, so that objects can really be used beyond devices. Patch 3 adds QOM support to the user emulators. As required by Anthony, they are now only built once. Available at: http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-user.v4 Regards, Andreas Cc: Anthony Liguori anth...@codemonkey.ws Cc: Avi Kivity a...@redhat.com v3 - v4: * Fix kvmclock abort due to too early kvm_enabled() check. * Introduce $(universal-obj-y) to build some objects only once. * Fix GPLv2 license link. v2 - v3: * Rebased against qom-upstream.14 branch (and that against master). * Build common dependencies for user emulators in libuser/. * New dependencies needed after moving properties into object.c. * Add a qemu-user.c with stubs needed for successful linking. v1 - v2: * Don't introduce extra early_init(), just relocate former MODULE_INIT_DEVICE. * Provide new type_init() macro to be used instead of device_init(). Andreas Färber (3): kvmclock: Always register type qom: Register QOM infrastructure early qom: Add QOM support to user emulators Makefile |6 +++--- Makefile.objs | 23 ++- Makefile.target|4 Makefile.user |1 + bsd-user/main.c|2 ++ darwin-user/main.c |3 +++ hw/kvm/clock.c |2 -- linux-user/main.c |2 ++ qemu-user.c| 37 + vl.c |4 ++-- 10 files changed, 72 insertions(+), 12 deletions(-) create mode 100644 qemu-user.c -- 1.7.7
Re: [Qemu-devel] KVM/QEMU: Support executing from flash device
On Sun, Mar 4, 2012 at 02:46, Avi Kivity a...@redhat.com wrote: On 03/04/2012 12:38 PM, Gleb Natapov wrote: On Sun, Mar 04, 2012 at 12:36:20PM +0200, Avi Kivity wrote: On 03/04/2012 10:12 AM, Gleb Natapov wrote: On Sat, Mar 03, 2012 at 10:56:02PM -0800, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. Do you want to execute code from a flash while it traps on read/exec? KVM emulator can't do that. No, he wants read/exec to go to RAM, and writes to be handled as mmio. This should work. That's mode 1 from above and will obviously work. I am asking about mode 2 from above. Mode 2 is pure mmio. You're right that kvm won't run code from that. Jordan, what's the use for mode 2? Is it just used during programming? Yes. It is the programming state for the flash, and no execution would occur from the region while it is in that state. At least for the flash that I'm interested in supporting (qemu:hw/pflash_cfi01.c), it would not be possible to execute from the flash in this mode because the entire region will no longer read-back the flash contents. -Jordan
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On Sun, 2012-03-04 at 17:46 +0100, Andreas Färber wrote: Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Well, my patch should work anyway, as long as getpagesize() returns a higher power of two. The case that wouldn't work (but also doesn't exist) is getpagesize() TARGET_PAGE_SIZE. For the record, I am hoping to get rid of some of those cpu.h defines in a later stage of QOM'ification. Cheers, Ben.
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On Sun, 2012-03-04 at 21:59 +0100, Alexander Graf wrote: g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. What I'm trying to tell you is that it's the default case on book3s ppc! ;) Exactly, which is why I'm saying just ignore the weird embedded case. :) Ugh. Sorry, apparently I can't read :). So you're saying 'break for ppcemb'. Hrm. Not sure that'd be all that great for 440, since there host pagesize is still 4k, but T_P_S is 1k. No, Alex, you are reading Andreas assert backward :-) What he suggests is break if TARGET_PAGE_SIZE getpagesize() which currently cannot happen. Even embedded 1k TARGET_PAGE_SIZE is fine. It's getpagesize() 1k that wouldn't be but it also never happens. Cheers, Ben.
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
Am 04.03.2012 21:59, schrieb Alexander Graf: On 04.03.2012, at 21:31, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 21:25, schrieb Alexander Graf: On 04.03.2012, at 21:21, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 19:46, schrieb Alexander Graf: On 04.03.2012, at 17:46, Andreas Färber afaer...@suse.de wrote: Am 04.03.2012 12:53, schrieb Benjamin Herrenschmidt: On Sun, 2012-03-04 at 12:49 +0200, Avi Kivity wrote: On 02/28/2012 11:48 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-02-28 at 14:32 +0200, Avi Kivity wrote: What if TARGET_PAGE_SIZE getpagesize()? Or is that impossible? We have yet to encounter such a case. It's not currently possible on power (some old embedded chips could do 1K and 2K page sizes in the TLB iirc but we never supported that in Linux and it's being phased out in HW). I suggest that gets dealt with when/if it needs to, which means probably never :-) Doesn't ppc support both 4k and 64k pages? Suppose you run a 4k guest on a 64k host? Maybe I'm misremembering or misunderstanding something. TARGET_PAGE_SIZE in qemu is always 4k for powerpc, it's a compile time #define. Except for ppcemb-softmmu (1k), which is irrelevant for KVM AFAIU. Maybe just add an assert and be done with it? Assert for what? Linux page size of 64k is something perfectly normal on ppc. The hardware can always do at least 4k maps however. g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. What I'm trying to tell you is that it's the default case on book3s ppc! ;) Exactly, which is why I'm saying just ignore the weird embedded case. :) [...] So you're saying 'break for ppcemb'. Hrm. Not sure that'd be all that great for 440, since there host pagesize is still 4k, but T_P_S is 1k. Err, 1k = 4k would still be supported. The way I see it, the only cases breaking would be ppc with host page size 4k, and ppcemb with host page size 1k (which I'm not aware of). Is it realistic to expect virtualizing a Mac or pSeries to work on a 1k/2k bamboo? TCG would be unaffected AFAICT. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On 04.03.2012, at 22:19, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sun, 2012-03-04 at 21:59 +0100, Alexander Graf wrote: g_assert(TARGET_PAGE_SIZE = getpagesize()) Just declare the above case as unsupported and abort if we encounter it. What I'm trying to tell you is that it's the default case on book3s ppc! ;) Exactly, which is why I'm saying just ignore the weird embedded case. :) Ugh. Sorry, apparently I can't read :). So you're saying 'break for ppcemb'. Hrm. Not sure that'd be all that great for 440, since there host pagesize is still 4k, but T_P_S is 1k. No, Alex, you are reading Andreas assert backward :-) What he suggests is break if TARGET_PAGE_SIZE getpagesize() which currently cannot happen. Even embedded 1k TARGET_PAGE_SIZE is fine. It's getpagesize() 1k that wouldn't be but it also never happens. O_o. Ok, that would obviously work. We never get hostpagesize 4k and T_P_S is always 1k/4k, never bigger. Alex Cheers, Ben.
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 4, 2012 at 21:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 08:32:26PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 20:02, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 07:51:02PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 05:07:34PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 02:35:28PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 01:38:38PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 12:37:57PM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Mar 04, 2012 at 10:27:24AM +, Blue Swirl wrote: On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin m...@redhat.com wrote: commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced a regression: we do not make IO base/limit upper 16 bit registers writeable, so we should report a 16 bit IO range type, not a 32 bit one. Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. In particular, this broke sparc64. Note: this just reverts to behaviour prior to the patch. Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 registers writeable should, and seems to, work just as well, but as no system seems to actually be interested in 32 bit IO, let's not make unnecessary changes. Reported-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Signed-off-by: Michael S. Tsirkin m...@redhat.com Mark, can you confirm that this fixes the bug for you? No, running qemu-system-sparc64 -serial stdio still shows black screen and the following on console: OpenBIOS for Sparc64 Unhandled Exception 0x0032 PC = 0xffd19e18 NPC = 0xffd19e1c Stopping execution The weird thing is the range type does not seem to be accessed at all. So I guessed there's some memory corruption here. Running valgrind shows this: --4-- WARNING: unhandled syscall: 340 --4-- You may be able to write your own handler. --4-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --4-- Nevertheless we consider this a bug. Please report --4-- it at http://valgrind.org/support/bug_reports.html. ==4== Invalid read of size 4 ==4== at 0x2A68C0: pci_apb_init (apb_pci.c:350) ==4== by 0x2F7A84: sun4uv_init (sun4u.c:779) ==4== by 0x13D716: main (vl.c:3397) ==4== Address 0x156c7d30 is 0 bytes after a block of size 64 alloc'd ==4== at 0x557DD69: malloc (vg_replace_malloc.c:236) ==4== by 0x225F56: malloc_and_trace (vl.c:2156) ==4== by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) ==4== by 0x19C50C: qemu_allocate_irqs (irq.c:47) ==4== by 0x2F7A4C: sun4uv_init (sun4u.c:778) ==4== by 0x13D716: main (vl.c:3397) ==4== apb: here ==4== Warning: client switching stacks? SP change: 0xfec42cbc -- 0x16894008 ==4== to suppress, use: --max-stackframe=398791500 or greater ==4== Warning: client switching stacks? SP change: 0x16893fa0 -- 0xfec42cc0 ==4== to suppress, use: --max-stackframe=398791392 or greater ==4== Warning: client switching stacks? SP change: 0xfec42fe0 -- 0x16893fd0 ==4== to suppress, use: --max-stackframe=398790640 or greater ==4== further instances of this message will not be shown. QEMU 1.0.50 monitor - type 'help' for more information (qemu) ==4== Thread 2: ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A8351: compute_all_sub (cc_helper.c:37) ==4== by 0x2A8782: helper_compute_psr (cc_helper.c:470) ==4== by 0x9AD9A19: ??? ==4== ==4== Conditional jump or move depends on uninitialised value(s) ==4== at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) ==4== by 0x2A8795: helper_compute_psr (cc_helper.c:473) ==4== by 0x9AD9A19: ??? ==4==
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On 04/03/12 19:51, Blue Swirl wrote:
I now know the root cause of the problem. OpenBIOS programs the BARs
somewhat correctly just by accident. The initial io_base and mem_base
for BARs are not correct, but because the host bridge BARs (and also 6
of which 4 are not even BARs!) are programmed first, the bases
happened to settle to values that happen to work. The commit revealed
the problem since the settling didn't happen. The mask changes just
let the host bridge setup continue to do the magic.
By just changing OpenBIOS (see attached patch), I can get the devices
to work (assuming that VGA is a separate problem). There's no need to
change QEMU.
Hi Blue/Michael,
Thanks for debugging this. I can confirm that building OpenBIOS SVN
trunk with Blue's patch and testing against QEMU git master with the
attached patch (to temporarily back out
2b50aa1f14d8e0a40f905ad0c022443c15646914 and
de58ac72b6a062d1a61478284c0c0f8a0428613e which breaks VGA on
PPC/SPARC64) appears to fix the problem for me.
Thanks a lot to both of you for taking the time to track this down :)
ATB,
Mark.
diff --git a/ioport.c b/ioport.c
index 8a474d3..36fa3a4 100644
--- a/ioport.c
+++ b/ioport.c
@@ -328,7 +328,6 @@ void portio_list_init(PortioList *piolist,
piolist-ports = callbacks;
piolist-nr = 0;
piolist-regions = g_new0(MemoryRegion *, n);
-piolist-aliases = g_new0(MemoryRegion *, n);
piolist-address_space = NULL;
piolist-opaque = opaque;
piolist-name = name;
@@ -337,7 +336,6 @@ void portio_list_init(PortioList *piolist,
void portio_list_destroy(PortioList *piolist)
{
g_free(piolist-regions);
-g_free(piolist-aliases);
}
static void portio_list_add_1(PortioList *piolist,
@@ -347,7 +345,7 @@ static void portio_list_add_1(PortioList *piolist,
{
MemoryRegionPortio *pio;
MemoryRegionOps *ops;
-MemoryRegion *region, *alias;
+MemoryRegion *region;
unsigned i;
/* Copy the sub-list and null-terminate it. */
@@ -364,20 +362,12 @@ static void portio_list_add_1(PortioList *piolist,
ops-old_portio = pio;
region = g_new(MemoryRegion, 1);
-alias = g_new(MemoryRegion, 1);
-/*
- * Use an alias so that the callback is called with an absolute address,
- * rather than an offset relative to to start + off_low.
- */
memory_region_init_io(region, ops, piolist-opaque, piolist-name,
- UINT64_MAX);
-memory_region_init_alias(alias, piolist-name,
- region, start + off_low, off_high - off_low);
+ off_high - off_low);
+memory_region_set_offset(region, start + off_low);
memory_region_add_subregion(piolist-address_space,
-start + off_low, alias);
-piolist-regions[piolist-nr] = region;
-piolist-aliases[piolist-nr] = alias;
-++piolist-nr;
+start + off_low, region);
+piolist-regions[piolist-nr++] = region;
}
void portio_list_add(PortioList *piolist,
@@ -419,19 +409,15 @@ void portio_list_add(PortioList *piolist,
void portio_list_del(PortioList *piolist)
{
-MemoryRegion *mr, *alias;
+MemoryRegion *mr;
unsigned i;
for (i = 0; i piolist-nr; ++i) {
mr = piolist-regions[i];
-alias = piolist-aliases[i];
-memory_region_del_subregion(piolist-address_space, alias);
-memory_region_destroy(alias);
+memory_region_del_subregion(piolist-address_space, mr);
memory_region_destroy(mr);
g_free((MemoryRegionOps *)mr-ops);
g_free(mr);
-g_free(alias);
piolist-regions[i] = NULL;
-piolist-aliases[i] = NULL;
}
}
diff --git a/ioport.h b/ioport.h
index ab29c89..ae3e9da 100644
--- a/ioport.h
+++ b/ioport.h
@@ -60,7 +60,6 @@ typedef struct PortioList {
struct MemoryRegion *address_space;
unsigned nr;
struct MemoryRegion **regions;
-struct MemoryRegion **aliases;
void *opaque;
const char *name;
} PortioList;
diff --git a/memory.c b/memory.c
index 6565e2e..926201a 100644
--- a/memory.c
+++ b/memory.c
@@ -389,17 +389,17 @@ static void memory_region_iorange_read(IORange *iorange,
*data = ((uint64_t)1 (width * 8)) - 1;
if (mrp) {
-*data = mrp-read(mr-opaque, offset);
+*data = mrp-read(mr-opaque, offset + mr-offset);
} else if (width == 2) {
mrp = find_portio(mr, offset, 1, false);
assert(mrp);
-*data = mrp-read(mr-opaque, offset) |
-(mrp-read(mr-opaque, offset + 1) 8);
+*data = mrp-read(mr-opaque, offset + mr-offset) |
+(mrp-read(mr-opaque, offset + mr-offset + 1) 8);
}
return;
}
*data = 0;
-access_with_adjusted_size(offset, data, width,
+access_with_adjusted_size(offset + mr-offset, data, width,
mr-ops-impl.min_access_size,
Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
On Sun, Mar 04, 2012 at 09:54:02PM +, Blue Swirl wrote: 19.3.1.10 tells that the header type is 0, as you noted too. Still, the register layout matches bridge spec instead, for example there are bus number registers in place of BAR 2. Sorry I don't see this in 19.3.1 Where are these registers documented? In my spec all registers from 0x10 on are greyed out which it says above means 'not implemented'? My spec also says 'Base Address' for 0x10 - 0x27. I see bus number and subordinate bus number registers at 0x40 and 0x41, this is outside the configuration header. The spec also says they are unused. Oh, I somehow read that they were in bridge locations 0x18 and 0x19. Perhaps the is_bridge property should be removed after OpenBIOS no longer wants to write to the registers. So we are in agreement then? The device seems to (more or less) go by the spec, but openbios gets confused, apparently by the absence of BARs. Can you try debugging openbios to see what is wrong? -- MST
Re: [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu
On Fri, Mar 02, 2012 at 07:02:21AM -0500, Stefan Berger wrote: On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote: On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote: On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote: On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote: On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote: When the backend delivers the response it checks whether the interface is used in interrupt mode and raises the interrupt. IMO it's the frontend that should send interrupts. Yes it kind of works for isa anyway, but e.g. pci needs to update configuration etc. The code that causes the interrupt to be raised is in the frontend. The function doing that is invoked via callback from the backend. This should be ok? Absolutely. The backend enters the frontend code with a callback. In this function also a signal is sent that may wake up the main thread that, upon suspend, may be waiting for the last command to be processed and be sleeping on a condition variable. I now added a function to the backend interface that is invoked by the frontend to notify the backend of a TPM request. The backend code can then either notify a thread (passthrough and libtpms driver) or create a response right away and invoke that callback to the front-end to deliver the response (null driver). How frontend and backend handle notifications is isolated to the frontend and backend with some backends (libtpms, passthough) sharing the code for how the notification is done. Stefan Right. And all the locking/threading can then be internal to the backend. Do you really want to replace code like this in the frontend: qemu_mutex_lock(s-state_lock) [...] qemu_mutex_unlock(s-state_lock) with s-be_driver-ops-state_lock(s-be_driver) [...] s-be_driver-ops-state_unlock(s-be_driver)) where the backend starts protecting frontend data structures ? It's ugly I hope you can do something saner: ops-send_command() with command encapsulating the relevant info. At the moment there are two backends that need threading: the libtpms and passthrough backends. Both will require locking of datastructures that belong to the frontend. Only the null driver doesn't need a thread and the main thread can call into the backend, create the response and call via callback into the frontend to deliver the repsonse. If structures are protected via mutxes then only the NULL driver (which we don't want anyway) may end up grabbing mutexes that really aren't necessary while the two other backends need them. I don't see the mitextes as problematic. The frontend at least protects its data structures for the callbacks and other API calls it offers and they simply are thread-safe. Stefan Worst case, you can take a qemu mutex. Is tpm very performance-sensitive to make contention on that lock a problem? Having instrumented the code with qemu_mutex_trylock() and a counter for failed attempts with subsequent qemu_mutex_lock() practically shows no lock contention at all for either polling or IRQ mode being used by the Linux driver. IRQ mode: 4 failed lock attempts out of 1726208 locks - 0.00% polling mode: 2 failed lock attempts out of 1545216 locks - 0.00% I used the libtpms based backend with and ran IMA and a test suite in the VM. Stefan so maybe you can just do qemu_mutex_lock_iothread similar to what kvm does. -- MST
Re: [Qemu-devel] [PATCH] seabios: acpi: Add _STA for PCI hotplug slots
On Sun, 2012-03-04 at 20:53 +0200, Michael S. Tsirkin wrote:
On Fri, Feb 24, 2012 at 04:21:17PM -0700, Alex Williamson wrote:
When a Status method is provided on a slot, the OSPM evaluates
_STA in response to the device check notify on the slot. This
allows some degree of a handshake between the platform and the
OSPM that the hotplug has been acknowledged.
In order to implement _STA, we need to know which slots have
devices. A slot with device returns 0x0F, a slot without a
device returns Zero. We get this information from Qemu using
the 0xae08 I/O port register. This was previously the read-side
of the register written to commit a device eject and always
returned 0 on read. It now returns a bitmap of present slots,
so we know that reading 0 means we have and old Qemu and
dynamically modify our SSDT to rename the _STA methods. This
is necessary to allow backwards compatibility.
Interesting. Isn't the UP register sufficient for _STA?
No, UP only reports the current slot being added, so we'd only be able
to report a present value for that slot and not static or previously
added slots.
Assuming we want to implement _STA - for which
the only motivation seems the handshake hack below.
The _STA method also writes the slot identifier to I/O port
register 0xae00 as an acknowledgment of the hotplug request.
This part looks a bit like a hack.
_STA is not intended as an acknowledgement - it's a query for state.
ACPI spec 5.0 requires that _STA is called before _INI,
but ACPI 1.0b doesn't. Did you try some 1.0 OSPMs (e.g. XP)
to see what they do?
I did test with XP. Section 6.3 of ACPI spec 1.0b references the _STA
method during hotplug. I also found this reference for Windows ACPI
procedure for hotplug/unplug:
http://www.microsoft.com/china/whdc/system/pnppwr/hotadd/hotplugpci.mspx#EYH
I agree, _STA is not intended as an acknowledgment, but that doesn't
mean we can't use it as one. The OSPM can call _STA at any point in
time, however calling it after we've done a notify for device check is
about the best indication we can get that the OSPM is processing it. It
doesn't hurt anything if _STA is called spuriously.
I also think I see how this can cause a race, see below.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Your description of the qemu patches made me think
that all you really want is detect an OS without
OSPM. If that is the case, I would suggest adding
an _INI method at top level as a simpler and more robust
procedure.
No, having OSPM is a prerequisite, but does not imply supporting
hotplug.
Otherwise, how about implementing _PS0
(and probably _PS3) to manage slot power?
Maybe this what you are really after, and it
seems like a better interface than 'acknowledge'
which does not seem to make sense for real hardware.
I tried this, _PS0/3 also requires _STA. Implementing both caused
interrupts to stop working on Linux guests. Note that _PS0/3 is even
less closely associated with device removal in 1.0b than _STA even
though the MSFT document references it.
---
src/acpi-dsdt.dsl | 36 ++-
src/acpi-dsdt.hex | 124 ++
src/acpi.c | 27 ++
src/ssdt-pcihp.dsl |3
src/ssdt-pcihp.hex | 658
5 files changed, 686 insertions(+), 162 deletions(-)
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 7082b65..6b87086 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -119,17 +119,15 @@ DefinitionBlock (
prt_slot3(0x001f),
})
-OperationRegion(PCST, SystemIO, 0xae00, 0x08)
+OperationRegion(PCST, SystemIO, 0xae00, 0x0c)
Field (PCST, DWordAcc, NoLock, WriteAsZeros)
{
-PCIU, 32,
-PCID, 32,
-}
-
-OperationRegion(SEJ, SystemIO, 0xae08, 0x04)
-Field (SEJ, DWordAcc, NoLock, WriteAsZeros)
-{
-B0EJ, 32,
+// PCI Up/ACK
+PUPA, 32,
+// PCI Down
+PDWN, 32,
+// PCI Present/Eject
+PPEJ, 32,
Note on the comment: this only affects bus0 not all of PCI.
As has always been the case.
}
Name (_CRS, ResourceTemplate ()
@@ -462,10 +460,20 @@ DefinitionBlock (
/* Methods called by hotplug devices */
Method (PCEJ, 1, NotSerialized) {
// _EJ0 method - eject callback
-Store(ShiftLeft(1, Arg0), B0EJ)
+Store(ShiftLeft(1, Arg0), PPEJ)
Return (0x0)
}
+Method (PSTA, 1, NotSerialized) {
+Store(ShiftLeft(1, Arg0), PUPA)
So this looks wrong to me.
Specifically _STA is also called at the end after _EJ0.
If the device is ejected then insterted, you
get a window where
[Qemu-devel] [PATCH 1/6] rtl8139: limit transmission buffer size in c+ mode
The tx buffer would be re-allocated for tx descriptor with big size
and without LS bit set, this would make guest driver could easily let
qemu to allocate unlimited.
In linux host, a glib failure were easy to be triggered:
GLib-ERROR **: gmem.c:176: failed to allocate 18446744071562067968 bytes
This patch fix this by adding a limit. As the spec didn't tell the maximum size
of buffer allowed, stick it to current CP_TX_BUFFER_SIZE (65536).
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/rtl8139.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 05b8e1e..d9e742c 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -2063,11 +2063,10 @@ static int rtl8139_cplus_transmit_one(RTL8139State *s)
while (s-cplus_txbuffer s-cplus_txbuffer_offset + txsize =
s-cplus_txbuffer_len)
{
-s-cplus_txbuffer_len += CP_TX_BUFFER_SIZE;
-s-cplus_txbuffer = g_realloc(s-cplus_txbuffer,
s-cplus_txbuffer_len);
-
-DPRINTF(+++ C+ mode transmission buffer space changed to %d\n,
-s-cplus_txbuffer_len);
+/* The spec didn't tell the maximum size, stick to CP_TX_BUFFER_SIZE */
+txsize = s-cplus_txbuffer_len - s-cplus_txbuffer_offset;
+DPRINTF(+++ C+ mode transmission buffer overrun, truncated descriptor
+length to %d\n, txsize);
}
if (!s-cplus_txbuffer)
[Qemu-devel] [PATCH 2/6] rtl8139: remove unused marco
Signed-off-by: Jason Wang jasow...@redhat.com --- hw/rtl8139.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/hw/rtl8139.c b/hw/rtl8139.c index d9e742c..ca613ae 100644 --- a/hw/rtl8139.c +++ b/hw/rtl8139.c @@ -65,9 +65,6 @@ #define PCI_FREQUENCY 3300L -/* debug RTL8139 card C+ mode only */ -//#define DEBUG_RTL8139CP 1 - #define SET_MASKED(input, mask, curr) \ ( ( (input) ~(mask) ) | ( (curr) (mask) ) )
[Qemu-devel] [PATCH 4/6] net: move compute_mcast_idx() to net.h
Reduce duplicated codes.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/eepro100.c | 25 -
hw/ne2000.c| 24
hw/opencores_eth.c | 25 -
hw/rtl8139.c | 24
net.c | 23 +++
net.h |3 +++
6 files changed, 26 insertions(+), 98 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index e3ba719..02e6f7e 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -322,33 +322,8 @@ static const uint16_t eepro100_mdi_mask[] = {
0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x,
};
-#define POLYNOMIAL 0x04c11db6
-
static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s);
-/* From FreeBSD */
-/* XXX: optimize */
-static unsigned compute_mcast_idx(const uint8_t * ep)
-{
-uint32_t crc;
-int carry, i, j;
-uint8_t b;
-
-crc = 0x;
-for (i = 0; i 6; i++) {
-b = *ep++;
-for (j = 0; j 8; j++) {
-carry = ((crc 0x8000L) ? 1 : 0) ^ (b 0x01);
-crc = 1;
-b = 1;
-if (carry) {
-crc = ((crc ^ POLYNOMIAL) | carry);
-}
-}
-}
-return (crc BITS(7, 2)) 2;
-}
-
/* Read a 16 bit control/status (CSR) register. */
static uint16_t e100_read_reg2(EEPRO100State *s, E100RegisterOffset addr)
{
diff --git a/hw/ne2000.c b/hw/ne2000.c
index 71452e1..d02e60c 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -150,30 +150,6 @@ static void ne2000_update_irq(NE2000State *s)
qemu_set_irq(s-irq, (isr != 0));
}
-#define POLYNOMIAL 0x04c11db6
-
-/* From FreeBSD */
-/* XXX: optimize */
-static int compute_mcast_idx(const uint8_t *ep)
-{
-uint32_t crc;
-int carry, i, j;
-uint8_t b;
-
-crc = 0x;
-for (i = 0; i 6; i++) {
-b = *ep++;
-for (j = 0; j 8; j++) {
-carry = ((crc 0x8000L) ? 1 : 0) ^ (b 0x01);
-crc = 1;
-b = 1;
-if (carry)
-crc = ((crc ^ POLYNOMIAL) | carry);
-}
-}
-return (crc 26);
-}
-
static int ne2000_buffer_full(NE2000State *s)
{
int avail, index, boundary;
diff --git a/hw/opencores_eth.c b/hw/opencores_eth.c
index 9b036cb..06ef712 100644
--- a/hw/opencores_eth.c
+++ b/hw/opencores_eth.c
@@ -351,31 +351,6 @@ static int open_eth_can_receive(VLANClientState *nc)
(rx_desc(s)-len_flags RXD_E);
}
-#define POLYNOMIAL 0x04c11db6
-
-/* From FreeBSD */
-/* XXX: optimize */
-static unsigned compute_mcast_idx(const uint8_t *ep)
-{
-uint32_t crc;
-int carry, i, j;
-uint8_t b;
-
-crc = 0x;
-for (i = 0; i 6; i++) {
-b = *ep++;
-for (j = 0; j 8; j++) {
-carry = ((crc 0x8000L) ? 1 : 0) ^ (b 0x01);
-crc = 1;
-b = 1;
-if (carry) {
-crc = ((crc ^ POLYNOMIAL) | carry);
-}
-}
-}
-return crc 26;
-}
-
static ssize_t open_eth_receive(VLANClientState *nc,
const uint8_t *buf, size_t size)
{
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index a946e79..509a53e 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -708,30 +708,6 @@ static void rtl8139_update_irq(RTL8139State *s)
qemu_set_irq(s-dev.irq[0], (isr != 0));
}
-#define POLYNOMIAL 0x04c11db6
-
-/* From FreeBSD */
-/* XXX: optimize */
-static int compute_mcast_idx(const uint8_t *ep)
-{
-uint32_t crc;
-int carry, i, j;
-uint8_t b;
-
-crc = 0x;
-for (i = 0; i 6; i++) {
-b = *ep++;
-for (j = 0; j 8; j++) {
-carry = ((crc 0x8000L) ? 1 : 0) ^ (b 0x01);
-crc = 1;
-b = 1;
-if (carry)
-crc = ((crc ^ POLYNOMIAL) | carry);
-}
-}
-return (crc 26);
-}
-
static int rtl8139_RxWrap(RTL8139State *s)
{
/* wrapping enabled; assume 1.5k more buffer space if size 65536 */
diff --git a/net.c b/net.c
index c34474f..1922d8a 100644
--- a/net.c
+++ b/net.c
@@ -1475,3 +1475,26 @@ int net_client_parse(QemuOptsList *opts_list, const char
*optarg)
default_net = 0;
return 0;
}
+
+/* From FreeBSD */
+/* XXX: optimize */
+unsigned compute_mcast_idx(const uint8_t *ep)
+{
+uint32_t crc;
+int carry, i, j;
+uint8_t b;
+
+crc = 0x;
+for (i = 0; i 6; i++) {
+b = *ep++;
+for (j = 0; j 8; j++) {
+carry = ((crc 0x8000L) ? 1 : 0) ^ (b 0x01);
+crc = 1;
+b = 1;
+if (carry) {
+crc = ((crc ^ POLYNOMIAL) | carry);
+}
+}
+}
+return crc 26;
+}
diff --git a/net.h b/net.h
index 75a8c15..64993b4 100644
--- a/net.h
+++ b/net.h
@@ -182,6 +182,9 @@ void qdev_set_nic_properties(DeviceState *dev, NICInfo *nd);
int net_handle_fd_param(Monitor *mon, const char *param);
+#define POLYNOMIAL 0x04c11db6
+unsigned
[Qemu-devel] [PATCH 3/6] rtl8139: support byte read to TxStatus registers
Some drivers (such as win7) use byte read for TxStatus registers, so we need to
support this to let guest driver behave correctly.
For writing, only double-word access is allowed by spec.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/rtl8139.c | 33 +
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index ca613ae..a946e79 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -2495,11 +2495,30 @@ static void rtl8139_TxStatus_write(RTL8139State *s,
uint32_t txRegOffset, uint32
rtl8139_transmit(s);
}
-static uint32_t rtl8139_TxStatus_read(RTL8139State *s, uint32_t txRegOffset)
+static uint32_t rtl8139_TxStatus_read(RTL8139State *s, uint8_t addr, int size)
{
-uint32_t ret = s-TxStatus[txRegOffset/4];
+uint32_t reg = (addr - TxStatus0) / 4;
+uint32_t offset = addr 0x3;
+uint32_t ret = 0;
+
+if (addr (size - 1)) {
+DPRINTF(not implemented read for TxStatus addr=0x%x size=0x%x\n,
addr,
+size);
+return ret;
+}
-DPRINTF(TxStatus read offset=0x%x val=0x%08x\n, txRegOffset, ret);
+switch (size) {
+case 1: /* fall through */
+case 2: /* fall through */
+case 4:
+ret = (s-TxStatus[reg] offset * 8) ((1 (size * 8)) - 1);
+DPRINTF(TxStatus[%d] read addr=0x%x size=0x%x val=0x%08x\n, reg,
addr,
+size, ret);
+break;
+default:
+DPRINTF(unsupported size 0x%x of TxStatus reading\n, size);
+break;
+}
return ret;
}
@@ -2970,6 +2989,9 @@ static uint32_t rtl8139_io_readb(void *opaque, uint8_t
addr)
case MAR0 ... MAR0+7:
ret = s-mult[addr - MAR0];
break;
+case TxStatus0 ... TxStatus0+4*4-1:
+ret = rtl8139_TxStatus_read(s, addr, 1);
+break;
case ChipCmd:
ret = rtl8139_ChipCmd_read(s);
break;
@@ -3033,6 +3055,9 @@ static uint32_t rtl8139_io_readw(void *opaque, uint8_t
addr)
switch (addr)
{
+case TxAddr0 ... TxAddr0+4*4-1:
+ret = rtl8139_TxStatus_read(s, addr, 2);
+break;
case IntrMask:
ret = rtl8139_IntrMask_read(s);
break;
@@ -3123,7 +3148,7 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t
addr)
break;
case TxStatus0 ... TxStatus0+4*4-1:
-ret = rtl8139_TxStatus_read(s, addr-TxStatus0);
+ret = rtl8139_TxStatus_read(s, addr, 4);
break;
case TxAddr0 ... TxAddr0+4*4-1:
[Qemu-devel] [PATCH 5/6] rtl8139: correctly check the opmode
According to the spec, only when opmode is Config. Register Write
Enable could driver write to CONFIG0,1,3,4 and bits 13,12,8 of BMCR.
Currently, we allow modifying to those registers also when 8139 is in
Auto-load mode and 93C46 (93C56) Programming mode. This patch
fixes this.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/rtl8139.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 509a53e..2e3da0b 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -332,8 +332,10 @@ enum CSCRBits {
};
enum Cfg9346Bits {
-Cfg9346_Lock = 0x00,
-Cfg9346_Unlock = 0xC0,
+Cfg9346_Normal = 0x00,
+Cfg9346_Autoload = 0x40,
+Cfg9346_Programming = 0x80,
+Cfg9346_ConfigWrite = 0xC0,
};
typedef enum {
@@ -1451,7 +1453,7 @@ static uint32_t rtl8139_IntrMitigate_read(RTL8139State *s)
static int rtl8139_config_writable(RTL8139State *s)
{
-if (s-Cfg9346 Cfg9346_Unlock)
+if ((s-Cfg9346 Chip9346_op_mask) == Cfg9346_ConfigWrite)
{
return 1;
}
[Qemu-devel] [PATCH 6/6] rtl8139: do the network/host communication only in normal operating mode
According the spec, the card works in network/host communication mode only when
both EEM1 and EEM0 are unset in 93C46 Command Register (normal op
mode). So this patch check these bits before trying to receive packets.
As some guest driver (such as linux, see cp_init_hw() in 8139cp.c)
allocate rx ring after the recevier were enabled, this would cause our
emulation codes tries to dma into guest memory when the rx descriptor
is not properly configured. This patch fixes this.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/rtl8139.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 2e3da0b..97a4b77 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -791,6 +791,9 @@ static int rtl8139_can_receive(VLANClientState *nc)
return 1;
if (!rtl8139_receiver_enabled(s))
return 1;
+/* network/host communication happens only in normal mode */
+if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal)
+ return 0;
if (rtl8139_cp_receiver_enabled(s)) {
/* ??? Flow control not implemented in c+ mode.
@@ -833,6 +836,12 @@ static ssize_t rtl8139_do_receive(VLANClientState *nc,
const uint8_t *buf, size_
return -1;
}
+/* check whether we are in normal mode */
+if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal) {
+DPRINTF(not in normal op mode\n);
+return -1;
+}
+
/* XXX: check this */
if (s-RxConfig AcceptAllPhys) {
/* promiscuous: receive all */
[Qemu-devel] [PATCH v9 0/4] Zynq-7000 EPP platform model
This is a suite of Device models and a machine model for the Xilinx Zynq-7000 Extensible Processing Platform: http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm This is an ARM based platform featuring embedded SoC peripherals. This patch series includes a minimal set of device models and a a machine model capable of emulating zynq platforms booting linux. This first 3 patches in this series are device models for IP provided by cadence for the Zynq platform. The final patch is the initial revision of the zynq machine model. Most of this work was originally authored by Xilinx, as indicated by (c) notices in added files. Tree is available from: git://developer.petalogix.com/private/peterc/qemu.git branch: zynq-initial.9 --- changed from v8: reworked uart interrupt behaviour (1/4) implemented vmsd (2/4) (3/4) (4/4) various typographical errors in comments (1/4) (2/4) changed from v7: removed fflush() from DBPRINTF (all) address P. Maydell comments re v6 (3/4) (4/4) fixed timer mod on wrap around logic (r.e. P Brook comments) (2/4) changed from v6: addressed P. Maydell comments re v5 (1/4) (2/4) renamed qemu_debug() - DB_PRINT (all) changed from v5: removed usages of arm_boot_info-bootsmp_priv_base (4/4) changed from v4: fixed FSF addess (1/4) (2/4) (4/4) changed device_init - type_init (all) changed from v3: fixed timer race condition issue (2/4) changed from v2: fixed timer prescision issue (2/4) fixed compile warnings in zynq_arm_sysctl (4/4) changes from v1: formatting and style fixes updated for QOM removed former patch 3 (cadence WDT device model) - not required removed former patch 5 (dtb argument) - this is currently under discussion in other patch series' removed former patch 6 (initrd parameterisation) - not required for minimal boot Peter A. G. Crosthwaite (4): cadence_uart: initial version of device model cadence_ttc: initial version of device model cadence_gem: initial version of device model xilinx_zynq: machine model initial version MAINTAINERS |7 + Makefile.target |4 + hw/cadence_gem.c | 1233 + hw/cadence_ttc.c | 489 + hw/cadence_uart.c | 513 ++ hw/xilinx_zynq.c | 157 +++ hw/zynq_slcr.c| 535 +++ 7 files changed, 2938 insertions(+), 0 deletions(-) create mode 100644 hw/cadence_gem.c create mode 100644 hw/cadence_ttc.c create mode 100644 hw/cadence_uart.c create mode 100644 hw/xilinx_zynq.c create mode 100644 hw/zynq_slcr.c -- 1.7.3.2
