Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 04/17/2011 08:31 PM, Alexander Graf wrote: On 17.04.2011, at 20:26, Richard Henderson wrote: On 04/17/2011 11:23 AM, Alexander Graf wrote: We try to keep a reference in pc-bios/README on where it comes from and Anthony usually wants you to also add git submodule magic for easy cloning :). The README is easy. I don't know what a git submodule is. Pointers are very welcome... Pointers are easy: http://patchwork.ozlabs.org/patch/90696/ I personally have no clue about them though - better to pester Anthony for details :). All that is done just with git submodule add git://repo.or.cz/qemu-palcode.git roms/qemu-palcode Paolo
Re: [Qemu-devel] Para-virtualized ram-based filesystem?
On 04/18/2011 06:28 AM, Ritchie, Stuart wrote: On 4/17/11 5:43 AM, "Avi Kivity" wrote: >On 04/16/2011 02:58 AM, Ritchie, Stuart wrote: >> > >> >You can do this with ivshmem today. You give it a path to a shared >> >memory file, and then there's a path in sysfs that you can mmap() in >> >userspace in the guest. >> >> Please correct me if I am wrong, but with ivshmem you must to manage >>your >> world within a single, fixed size region. I appreciate the simplicity >>of >> mapping the whole region all in one go, but our requirements are a bit >> different. Even if you could pass multiple -device ivshmem instances, >> it's still a fixed environment. Right? >> > >You could place a read-only filesystem (say iso9660) in the region and >mount it; it will then appear as a complete filesystem. We've thought about formatting the region as a ramdisk, but the block layer shields mmap() from the storage, thus requiring a data copy into the page-cache. The great thing about ramfs/tmpfs is the data is used in-place; we'd lose that when going with a ramdisk or other real filesystem. s390 uses a trick to achieve this (XIP). Look at fs/ext2/xip.c. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] [Bug 764252] [NEW] wishlist: kirkwood support
Public bug reported: This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/764252 Title: wishlist: kirkwood support Status in QEMU: New Bug description: This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices.
Re: [Qemu-devel] Para-virtualized ram-based filesystem?
On 4/16/11 1:52 AM, "Stefan Hajnoczi" wrote: >On Sat, Apr 16, 2011 at 1:27 AM, Brad Hards wrote: >> On Saturday 16 April 2011 09:58:32 Ritchie, Stuart wrote: >>> How does that sound? >> As a general user: Confusing. >> >> Is there a concrete example (specific applications, specific >>performance issues, >> specific requirements) that you can share? > >I'm also wondering why you want this. The reason why we want this is the same reason why anyone would want mmap() and tmpfs/ramfs in the first place: zero-copy, in-place access to your data. > >Does it matter if the files get pushed out to swap on the host? We don't run in a swapping environment. But someone who does and accepts the performance hit, then I don't see why it would matter. Ramfs does not kick pages out of the page-cache. But tmpfs does -- the host should make this transparent, as it does now. > >It's tempting to take advantage of running virtualized but then things >like migration get in the way. Have you actually tried out network >file systems and determined they won't work for some reason? > >Stefan For performance reasons it's very important for our system that the data be as close to the app as possible. We can't afford to push data through an I/O channel. What I'm really suggesting here is a way for guest applications to mmap() host memory. Combine that with a virt-aware robust mutex and you've probably got the most flexible, performant, inter-guest sharing/communication mechanism possible. (Semaphores through a socket? On the same system? You gotta be kidding. :-) Cheers, --Stuart The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs
Re: [Qemu-devel] Para-virtualized ram-based filesystem?
On 4/17/11 5:43 AM, "Avi Kivity" wrote: >On 04/16/2011 02:58 AM, Ritchie, Stuart wrote: >> > >> >You can do this with ivshmem today. You give it a path to a shared >> >memory file, and then there's a path in sysfs that you can mmap() in >> >userspace in the guest. >> >> Please correct me if I am wrong, but with ivshmem you must to manage >>your >> world within a single, fixed size region. I appreciate the simplicity >>of >> mapping the whole region all in one go, but our requirements are a bit >> different. Even if you could pass multiple -device ivshmem instances, >> it's still a fixed environment. Right? >> > >You could place a read-only filesystem (say iso9660) in the region and >mount it; it will then appear as a complete filesystem. We've thought about formatting the region as a ramdisk, but the block layer shields mmap() from the storage, thus requiring a data copy into the page-cache. The great thing about ramfs/tmpfs is the data is used in-place; we'd lose that when going with a ramdisk or other real filesystem. --Stuart The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs
Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_load
On Sun, Apr 17, 2011 at 10:34:47PM +0100, Peter Maydell wrote: > On 17 April 2011 22:07, Stefan Weil wrote: > > Am 17.04.2011 20:27, schrieb Aurelien Jarno: > >> > >> On Thu, Apr 14, 2011 at 08:50:00PM +0200, Stefan Weil wrote: > >>> > >>> Am 13.04.2011 23:05, schrieb Peter Maydell: > > On 13 April 2011 21:38, Stefan Weil wrote: > > > > gen_pc_load was introduced in commit > > d2856f1ad4c259e5766847c49acbb4e390731bd4. > > The only reason for parameter searched_pc was > > a debug statement in target-i386/translate.c. > > > > Remove searched_pc from the debug statement > > and from the parameter list of gen_pc_load. > > No issues with the meat of the patch, but if we're going to > change all the callers and implementations of this anyway, > is there any appetite for giving it a more appropriate name? > It doesn't generate any code, it affects more than just the > pc, and it doesn't do a load... > > restore_state_to_opc() ? set_env_for_opc() ? > > -- PMM > >>> > >>> > >>> What about cpu_restore_pc()? That's not always the whole truth, > >>> but it's always the main action done in function n.n. which currently > >>> is called gen_pc_load. > >>> > >>> Or cpu_restore_helper()? Helper is very generic - it always fits. > >>> > >>> Aurelien, please feel free to choose a name which suits bests. > >>> I don't mind if you simply patch my patch, create a new one > >>> or tell me which name should go into a new version of the patch > >>> so I can send it. > >>> > >> > >> As Peter said, the function is doing more than simply restoring the > >> pc. I am fine with the name he proposed, I think restore_state_to_opc() > >> is a bit better. > > > > Ok, so I'll send a new patch which also replaces gen_pc_load > > by restore_state_to_op. > > That's _to_opc, not _to_op : I was trying to be consistent with > the naming of the gen_opc_* arrays. > Oops, sorry, just a cut & paste mistake. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_load
On 17 April 2011 22:07, Stefan Weil wrote: > Am 17.04.2011 20:27, schrieb Aurelien Jarno: >> >> On Thu, Apr 14, 2011 at 08:50:00PM +0200, Stefan Weil wrote: >>> >>> Am 13.04.2011 23:05, schrieb Peter Maydell: On 13 April 2011 21:38, Stefan Weil wrote: > > gen_pc_load was introduced in commit > d2856f1ad4c259e5766847c49acbb4e390731bd4. > The only reason for parameter searched_pc was > a debug statement in target-i386/translate.c. > > Remove searched_pc from the debug statement > and from the parameter list of gen_pc_load. No issues with the meat of the patch, but if we're going to change all the callers and implementations of this anyway, is there any appetite for giving it a more appropriate name? It doesn't generate any code, it affects more than just the pc, and it doesn't do a load... restore_state_to_opc() ? set_env_for_opc() ? -- PMM >>> >>> >>> What about cpu_restore_pc()? That's not always the whole truth, >>> but it's always the main action done in function n.n. which currently >>> is called gen_pc_load. >>> >>> Or cpu_restore_helper()? Helper is very generic - it always fits. >>> >>> Aurelien, please feel free to choose a name which suits bests. >>> I don't mind if you simply patch my patch, create a new one >>> or tell me which name should go into a new version of the patch >>> so I can send it. >>> >> >> As Peter said, the function is doing more than simply restoring the >> pc. I am fine with the name he proposed, I think restore_state_to_opc() >> is a bit better. > > Ok, so I'll send a new patch which also replaces gen_pc_load > by restore_state_to_op. That's _to_opc, not _to_op : I was trying to be consistent with the naming of the gen_opc_* arrays. -- PMM
Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_load
Am 17.04.2011 20:27, schrieb Aurelien Jarno: On Thu, Apr 14, 2011 at 08:50:00PM +0200, Stefan Weil wrote: Am 13.04.2011 23:05, schrieb Peter Maydell: On 13 April 2011 21:38, Stefan Weil wrote: gen_pc_load was introduced in commit d2856f1ad4c259e5766847c49acbb4e390731bd4. The only reason for parameter searched_pc was a debug statement in target-i386/translate.c. Remove searched_pc from the debug statement and from the parameter list of gen_pc_load. No issues with the meat of the patch, but if we're going to change all the callers and implementations of this anyway, is there any appetite for giving it a more appropriate name? It doesn't generate any code, it affects more than just the pc, and it doesn't do a load... restore_state_to_opc() ? set_env_for_opc() ? -- PMM What about cpu_restore_pc()? That's not always the whole truth, but it's always the main action done in function n.n. which currently is called gen_pc_load. Or cpu_restore_helper()? Helper is very generic - it always fits. Aurelien, please feel free to choose a name which suits bests. I don't mind if you simply patch my patch, create a new one or tell me which name should go into a new version of the patch so I can send it. As Peter said, the function is doing more than simply restoring the pc. I am fine with the name he proposed, I think restore_state_to_opc() is a bit better. Ok, so I'll send a new patch which also replaces gen_pc_load by restore_state_to_op. The new function name is longer than the old one, but it was possible to remove one more function parameter, therefore line lengths don't increase. avoid over
[Qemu-devel] [PULL] Migration of misc devices
The following changes since commit a0102082de4026833afbd2525e8a6320d1f92885: usb: fix spelling errors in usb-linux.c (2011-04-16 12:24:28 +0100) are available in the git repository at: git://repo.or.cz/qemu/quintela.git vmstate-misc-devices-v2 Juan Quintela (45): vmstate: port adb_kbd vmstate: port adb_mouse vmstate: port ads7846 vmstate: port m48t59 vmstate: port mipsnet vmstate: port arm sp804 vmstate: port arm_timer vmstate: port sysborg_timer vmstate: port pmtimer vmstate: port syborg_rtc vmstate: port pxa2xx_keypad vmstate: port pl011 vmstate: port armv7m nvic vmstate: port stellaris i2c vmstate: port stellaris ssi bus vmstate: port stellaris sys vmstate: port pl022 ssp vmstate: port heathrow_pic vmstate: port cuda vmstate: port stellaris gptm vmstate: port pxa2xx_i2s vmstate: port pxa2xx_cm vmstate: port pxa2xx_mm vmstate: port pxa2xx_pm vmstate: port ppce500_pci vmstate: port ppc4xx_pci vmstate: port syborg_pointer vmstate: port stellaris_adc vmstate: port syborg_serial vmstate: port syborg_keyboard vmstate: port stellaris gamepad vmstate: stellaris use unused for placeholder entries pxa2xx_lcd: name anonymous struct pxa2xx_lcd: up field is used as a bool and migrated as an uint8_t vmstate: port pxa2xx_lcd max111x: input field is only used as uint8_t vmstate: port max111x nand: pin values are uint8_t vmstate: port nand mac_nvram: size is a size, no need to be a target dependent type vmstate: port mac_nvram piix4: create PIIX4State vmstate: port piix4 mac_dbdma: create DBDMAState instead of passing one array around vmstate: port mac_dbdma hw/adb.c | 83 +- hw/ads7846.c | 41 +++ hw/arm_timer.c | 66 --- hw/armv7m_nvic.c | 39 ++ hw/cuda.c| 116 +++--- hw/flash.h |4 +- hw/heathrow_pic.c| 62 -- hw/hw.h | 17 ++- hw/m48t59.c | 36 ++ hw/mac_dbdma.c | 83 +++-- hw/mac_nvram.c | 32 ++--- hw/max111x.c | 51 +++- hw/mipsnet.c | 53 +++-- hw/nand.c| 79 +++-- hw/piix4.c | 44 hw/pl011.c | 76 hw/pl022.c | 84 ++ hw/ppc4xx_pci.c | 80 ++--- hw/ppce500_pci.c | 87 ++ hw/ptimer.c | 59 +++--- hw/pxa2xx.c | 158 + hw/pxa2xx_keypad.c | 53 +++-- hw/pxa2xx_lcd.c | 138 +- hw/stellaris.c | 323 +- hw/stellaris_input.c | 50 hw/syborg_keyboard.c | 57 +++-- hw/syborg_pointer.c | 73 +--- hw/syborg_rtc.c | 34 ++ hw/syborg_serial.c | 60 +++--- hw/syborg_timer.c| 46 +++- qemu-timer.h |2 - 31 files changed, 854 insertions(+), 1332 deletions(-)
Re: [Qemu-devel] [PATCH 1/3] slirp: Implement TFTP Blocksize option
On Sun, Apr 17, 2011 at 7:16 PM, Hervé Poussineau wrote: > Hi, > > Yes, I've tried booting with PXELINUX and gPXE, and I didn't see any > problem. Great. Thanks for confirming. Stefan
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 17.04.2011, at 20:26, Richard Henderson wrote: > On 04/17/2011 11:23 AM, Alexander Graf wrote: >> We try to keep a reference in pc-bios/README on where it comes from >> and Anthony usually wants you to also add git submodule magic for >> easy cloning :). > > The README is easy. I don't know what a git submodule is. > Pointers are very welcome... Pointers are easy: http://patchwork.ozlabs.org/patch/90696/ I personally have no clue about them though - better to pester Anthony for details :). Alex
Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_load
On Thu, Apr 14, 2011 at 08:50:00PM +0200, Stefan Weil wrote: > Am 13.04.2011 23:05, schrieb Peter Maydell: > >On 13 April 2011 21:38, Stefan Weil wrote: > >>gen_pc_load was introduced in commit > >>d2856f1ad4c259e5766847c49acbb4e390731bd4. > >>The only reason for parameter searched_pc was > >>a debug statement in target-i386/translate.c. > >> > >>Remove searched_pc from the debug statement > >>and from the parameter list of gen_pc_load. > > > >No issues with the meat of the patch, but if we're going to > >change all the callers and implementations of this anyway, > >is there any appetite for giving it a more appropriate name? > >It doesn't generate any code, it affects more than just the > >pc, and it doesn't do a load... > > > >restore_state_to_opc() ? set_env_for_opc() ? > > > >-- PMM > > > What about cpu_restore_pc()? That's not always the whole truth, > but it's always the main action done in function n.n. which currently > is called gen_pc_load. > > Or cpu_restore_helper()? Helper is very generic - it always fits. > > Aurelien, please feel free to choose a name which suits bests. > I don't mind if you simply patch my patch, create a new one > or tell me which name should go into a new version of the patch > so I can send it. > As Peter said, the function is doing more than simply restoring the pc. I am fine with the name he proposed, I think restore_state_to_opc() is a bit better. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 04/17/2011 11:23 AM, Alexander Graf wrote: > We try to keep a reference in pc-bios/README on where it comes from > and Anthony usually wants you to also add git submodule magic for > easy cloning :). The README is easy. I don't know what a git submodule is. Pointers are very welcome... r~
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 17.04.2011, at 19:11, Richard Henderson wrote: > On 04/17/2011 10:03 AM, Peter Maydell wrote: >> On 17 April 2011 17:14, Richard Henderson wrote: >>> Delete the old partial support for alpha-softmmu, which kind-of tried >>> to emulate real HW and its PALcode. Instead, use a custom HW interface >>> for a custom PALcode. Wire up as much of the device emulation as is >>> available. >> >>> pc-bios/palcode-sx164 | Bin 0 -> 107781 bytes >> >> My personal opinion is that if we have the binary blob in qemu git >> we should also have its corresponding source code. >> > > How does this differ from e.g. SeaBios? > > And while I might agree that this ought to be in-tree, this isn't > true for any of the other blobs we currently have in-tree. We > don't really have any configury for cross-compilation of the bios bits. We try to keep a reference in pc-bios/README on where it comes from and Anthony usually wants you to also add git submodule magic for easy cloning :). Alex
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 17.04.2011, at 19:12, Richard Henderson wrote: > On 04/17/2011 09:42 AM, Alexander Graf wrote: >> Mind to split it up? I'm having a hard time reading such huge patches O_o. >> Awesome work, btw :). > > What sort of split would you like to see? > > I thought about it, but there's not too many splits that actually > compile individually. Yeah, I was in a similar dilemma. I'm pretty sure you can at least split linux-user, device emulation and cpu emulation patches :). Usually, I just try to split things by file and see if it's easy enough to get back to bisectability using a script I got from Avi a while back: #!/bin/bash -e for commit in $(git rev-list --reverse "$@"); do echo "Commit $commit" git checkout "$commit" make -j done Alex
Re: [Qemu-devel] [PATCH 1/3] slirp: Implement TFTP Blocksize option
Hi, Yes, I've tried booting with PXELINUX and gPXE, and I didn't see any problem. Hervé Stefan Hajnoczi a écrit : On Mon, Apr 11, 2011 at 07:10:52PM +, Herve Poussineau wrote: From: Herv? Poussineau This option is described in RFC 1783. As this is only an optional field, we may ignore it in some situations and handle it in some others. Here, if client requests a block size bigger than the block size we emit (512 bytes), accept the option with a value of 512 Signed-off-by: Herv? Poussineau --- slirp/tftp.c | 40 1 files changed, 32 insertions(+), 8 deletions(-) Have you tested PXELINUX and gPXE? Stefan
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 04/17/2011 09:42 AM, Alexander Graf wrote: > Mind to split it up? I'm having a hard time reading such huge patches O_o. > Awesome work, btw :). What sort of split would you like to see? I thought about it, but there's not too many splits that actually compile individually. r~
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 04/17/2011 10:03 AM, Peter Maydell wrote: > On 17 April 2011 17:14, Richard Henderson wrote: >> Delete the old partial support for alpha-softmmu, which kind-of tried >> to emulate real HW and its PALcode. Instead, use a custom HW interface >> for a custom PALcode. Wire up as much of the device emulation as is >> available. > >> pc-bios/palcode-sx164 | Bin 0 -> 107781 bytes > > My personal opinion is that if we have the binary blob in qemu git > we should also have its corresponding source code. > How does this differ from e.g. SeaBios? And while I might agree that this ought to be in-tree, this isn't true for any of the other blobs we currently have in-tree. We don't really have any configury for cross-compilation of the bios bits. r~
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 17 April 2011 17:14, Richard Henderson wrote: > Delete the old partial support for alpha-softmmu, which kind-of tried > to emulate real HW and its PALcode. Instead, use a custom HW interface > for a custom PALcode. Wire up as much of the device emulation as is > available. > pc-bios/palcode-sx164 | Bin 0 -> 107781 bytes My personal opinion is that if we have the binary blob in qemu git we should also have its corresponding source code. (plus it should be in the same commit that adds it to configure's list of files, because configure doesn't do the right thing for missing binary blobs) -- PMM
Re: [Qemu-devel] [PATCH 5/5] target-alpha: Emulate Alpha SX164.
On 17.04.2011, at 18:14, Richard Henderson wrote: > Delete the old partial support for alpha-softmmu, which kind-of tried > to emulate real HW and its PALcode. Instead, use a custom HW interface > for a custom PALcode. Wire up as much of the device emulation as is > available. Mind to split it up? I'm having a hard time reading such huge patches O_o. Awesome work, btw :). Alex
[Qemu-devel] [PATCH 4/5] target-alpha: Prepare for Alpha BIOS images.
Signed-off-by: Richard Henderson --- Makefile |3 ++- configure |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index fa93be5..a3ac9c7 100644 --- a/Makefile +++ b/Makefile @@ -184,7 +184,8 @@ pxe-rtl8139.bin pxe-virtio.bin \ bamboo.dtb petalogix-s3adsp1800.dtb petalogix-ml605.dtb \ multiboot.bin linuxboot.bin \ s390-zipl.rom \ -spapr-rtas.bin slof.bin +spapr-rtas.bin slof.bin \ +palcode-sx164 else BLOBS= endif diff --git a/configure b/configure index da2da04..4a93972 100755 --- a/configure +++ b/configure @@ -3454,7 +3454,7 @@ FILES="Makefile tests/Makefile" FILES="$FILES tests/cris/Makefile tests/cris/.gdbinit" FILES="$FILES pc-bios/optionrom/Makefile pc-bios/keymaps" FILES="$FILES roms/seabios/Makefile roms/vgabios/Makefile" -for bios_file in $source_path/pc-bios/*.bin $source_path/pc-bios/*.dtb $source_path/pc-bios/openbios-*; do +for bios_file in $source_path/pc-bios/*.bin $source_path/pc-bios/*.dtb $source_path/pc-bios/openbios-* $source_path/pc-bios/palcode-*; do FILES="$FILES pc-bios/`basename $bios_file`" done mkdir -p $DIRS -- 1.7.4.2
[Qemu-devel] [PATCH 0/5] Alpha system emulation
This is good enough to begin booting the Linux kernel. We do not get all the way to userspace yet; I've found two kernel bugs so far leading to immediate crashes, I suspect there are more that have crept in. At the moment we seem to get into the cpu_idle loop without managing to schedule the first kernel_thread. Posted to begin getting comments. Source to the QEMU PALcode can be found at http://repo.or.cz/w/qemu-palcode.git Several patches for the kernel to recover from recent breakage at http://repo.or.cz/w/linux-2.6/rth.git axp-qemu r~ Richard Henderson (5): Export the unassigned_mem read/write functions. target-alpha: Disassemble EV6 PALcode instructions. pci: Export pci_to_cpu_addr. target-alpha: Prepare for Alpha BIOS images. target-alpha: Emulate Alpha SX164. Makefile |3 +- Makefile.target |4 +- alpha-dis.c |4 - configure |3 +- cpu-common.h |7 + cpu-exec.c| 16 +- default-configs/alpha-softmmu.mak |9 + dis-asm.h |3 + disas.c |2 +- exec.c| 12 +- hw/alpha_palcode.c| 1048 hw/alpha_pci.c| 327 hw/alpha_pyxis.c | 1057 + hw/alpha_sx164.c | 195 +++ hw/alpha_sys.h| 41 ++ hw/pci.c |3 +- hw/pci.h |1 + linux-user/main.c | 39 +- pc-bios/palcode-sx164 | Bin 0 -> 107781 bytes target-alpha/cpu.h| 337 +--- target-alpha/exec.h |7 +- target-alpha/helper.c | 630 ++ target-alpha/helper.h | 34 +- target-alpha/machine.c| 84 +++ target-alpha/op_helper.c | 249 -- target-alpha/translate.c | 422 +--- 26 files changed, 2543 insertions(+), 1994 deletions(-) create mode 100644 default-configs/alpha-softmmu.mak delete mode 100644 hw/alpha_palcode.c create mode 100644 hw/alpha_pci.c create mode 100644 hw/alpha_pyxis.c create mode 100644 hw/alpha_sx164.c create mode 100644 hw/alpha_sys.h create mode 100644 pc-bios/palcode-sx164 create mode 100644 target-alpha/machine.c -- 1.7.4.2
[Qemu-devel] [PATCH 3/5] pci: Export pci_to_cpu_addr.
This is, more or less, the read accessor to pci_bus_set_mem_base
as a write accessor. It will be needed for implementing sparse
memory spaces for Alpha.
Signed-off-by: Richard Henderson
---
hw/pci.c |3 +--
hw/pci.h |1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 6b577e1..8c7f52a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -793,8 +793,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char
*name,
return pci_dev;
}
-static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus,
- target_phys_addr_t addr)
+target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, target_phys_addr_t addr)
{
return addr + bus->mem_base;
}
diff --git a/hw/pci.h b/hw/pci.h
index 52ee8c9..cb0f738 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -242,6 +242,7 @@ void pci_device_reset(PCIDevice *dev);
void pci_bus_reset(PCIBus *bus);
void pci_bus_set_mem_base(PCIBus *bus, target_phys_addr_t base);
+target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, target_phys_addr_t addr);
PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
const char *default_devaddr);
--
1.7.4.2
[Qemu-devel] [PATCH 2/5] target-alpha: Disassemble EV6 PALcode instructions.
The QEMU emulation PALcode will use EV6 PALcode insns regardless
of the "real" cpu instruction set being emulated.
Signed-off-by: Richard Henderson
---
alpha-dis.c |4
dis-asm.h |3 +++
disas.c |2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/alpha-dis.c b/alpha-dis.c
index 8a2411e..ae331b3 100644
--- a/alpha-dis.c
+++ b/alpha-dis.c
@@ -238,10 +238,6 @@ extern const unsigned alpha_num_operands;
#define AXP_REG_SP 30
#define AXP_REG_ZERO 31
-#define bfd_mach_alpha_ev4 0x10
-#define bfd_mach_alpha_ev5 0x20
-#define bfd_mach_alpha_ev6 0x30
-
enum bfd_reloc_code_real {
BFD_RELOC_23_PCREL_S2,
BFD_RELOC_ALPHA_HINT
diff --git a/dis-asm.h b/dis-asm.h
index 296537a..5b07d7f 100644
--- a/dis-asm.h
+++ b/dis-asm.h
@@ -184,6 +184,9 @@ enum bfd_architecture
#define bfd_mach_sh50x50
bfd_arch_alpha, /* Dec Alpha */
#define bfd_mach_alpha 1
+#define bfd_mach_alpha_ev4 0x10
+#define bfd_mach_alpha_ev5 0x20
+#define bfd_mach_alpha_ev6 0x30
bfd_arch_arm,/* Advanced Risc Machines ARM */
#define bfd_mach_arm_unknown 0
#define bfd_mach_arm_2 1
diff --git a/disas.c b/disas.c
index 223606c..d208c52 100644
--- a/disas.c
+++ b/disas.c
@@ -205,7 +205,7 @@ void target_disas(FILE *out, target_ulong code,
target_ulong size, int flags)
disasm_info.mach = bfd_mach_sh4;
print_insn = print_insn_sh;
#elif defined(TARGET_ALPHA)
-disasm_info.mach = bfd_mach_alpha;
+disasm_info.mach = bfd_mach_alpha_ev6;
print_insn = print_insn_alpha;
#elif defined(TARGET_CRIS)
if (flags != 32) {
--
1.7.4.2
[Qemu-devel] [PATCH 1/5] Export the unassigned_mem read/write functions.
Signed-off-by: Richard Henderson
---
cpu-common.h |7 +++
exec.c | 12 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index 96c02ae..e17020b 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -45,6 +45,13 @@ static inline void
cpu_register_physical_memory(target_phys_addr_t start_addr,
cpu_register_physical_memory_offset(start_addr, size, phys_offset, 0);
}
+extern CPUReadMemoryFunc unassigned_mem_readb;
+extern CPUReadMemoryFunc unassigned_mem_readw;
+extern CPUReadMemoryFunc unassigned_mem_readl;
+extern CPUWriteMemoryFunc unassigned_mem_writeb;
+extern CPUWriteMemoryFunc unassigned_mem_writew;
+extern CPUWriteMemoryFunc unassigned_mem_writel;
+
ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
ram_addr_t size, void *host);
diff --git a/exec.c b/exec.c
index b1ee52a..994d51b 100644
--- a/exec.c
+++ b/exec.c
@@ -3090,7 +3090,7 @@ ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr)
return ram_addr;
}
-static uint32_t unassigned_mem_readb(void *opaque, target_phys_addr_t addr)
+uint32_t unassigned_mem_readb(void *opaque, target_phys_addr_t addr)
{
#ifdef DEBUG_UNASSIGNED
printf("Unassigned mem read " TARGET_FMT_plx "\n", addr);
@@ -3101,7 +3101,7 @@ static uint32_t unassigned_mem_readb(void *opaque,
target_phys_addr_t addr)
return 0;
}
-static uint32_t unassigned_mem_readw(void *opaque, target_phys_addr_t addr)
+uint32_t unassigned_mem_readw(void *opaque, target_phys_addr_t addr)
{
#ifdef DEBUG_UNASSIGNED
printf("Unassigned mem read " TARGET_FMT_plx "\n", addr);
@@ -3112,7 +3112,7 @@ static uint32_t unassigned_mem_readw(void *opaque,
target_phys_addr_t addr)
return 0;
}
-static uint32_t unassigned_mem_readl(void *opaque, target_phys_addr_t addr)
+uint32_t unassigned_mem_readl(void *opaque, target_phys_addr_t addr)
{
#ifdef DEBUG_UNASSIGNED
printf("Unassigned mem read " TARGET_FMT_plx "\n", addr);
@@ -3123,7 +3123,7 @@ static uint32_t unassigned_mem_readl(void *opaque,
target_phys_addr_t addr)
return 0;
}
-static void unassigned_mem_writeb(void *opaque, target_phys_addr_t addr,
uint32_t val)
+void unassigned_mem_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)
{
#ifdef DEBUG_UNASSIGNED
printf("Unassigned mem write " TARGET_FMT_plx " = 0x%x\n", addr, val);
@@ -3133,7 +3133,7 @@ static void unassigned_mem_writeb(void *opaque,
target_phys_addr_t addr, uint32_
#endif
}
-static void unassigned_mem_writew(void *opaque, target_phys_addr_t addr,
uint32_t val)
+void unassigned_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val)
{
#ifdef DEBUG_UNASSIGNED
printf("Unassigned mem write " TARGET_FMT_plx " = 0x%x\n", addr, val);
@@ -3143,7 +3143,7 @@ static void unassigned_mem_writew(void *opaque,
target_phys_addr_t addr, uint32_
#endif
}
-static void unassigned_mem_writel(void *opaque, target_phys_addr_t addr,
uint32_t val)
+void unassigned_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t val)
{
#ifdef DEBUG_UNASSIGNED
printf("Unassigned mem write " TARGET_FMT_plx " = 0x%x\n", addr, val);
--
1.7.4.2
Re: [Qemu-devel] [PATCH 24/26] acpi, acpi_piix: factor out GPE logic
On 04/17/2011 04:50 PM, Isaku Yamahata wrote:
On Sun, Apr 17, 2011 at 04:17:51PM +0300, Avi Kivity wrote:
> On 03/16/2011 11:29 AM, Isaku Yamahata wrote:
>> factor out ACPI GPE logic. Later it will be used by ICH9 ACPI.
>>
>
> I think this patch is causing qemu-kvm failures on migration:
> (gdb) bt
> #0 0x0049aff4 in qemu_put_be16s (f=0x1a74490, pv=0x2c02580,
> size=2) at hw/hw.h:108
> #1 put_uint16 (f=0x1a74490, pv=0x2c02580, size=2) at savevm.c:855
> #2 0x0049c3e4 in vmstate_save_state (f=0x1a74490,
> vmsd=0x6f0b00, opaque=0x1842ef0) at savevm.c:1436
> #3 0x0049c3b6 in vmstate_save_state (f=0x1a74490,
> vmsd=0x6f0aa0, opaque=0x1842b90) at savevm.c:1434
> #4 0x0049c6f1 in vmstate_save (mon=,
> f=0x1a74490) at savevm.c:1459
> #5 qemu_savevm_state_complete (mon=, f=0x1a74490)
> at savevm.c:1600
> #6 0x0049455a in migrate_fd_put_ready (opaque=0x1847890) at
> migration.c:383
> #7 0x004ce2eb in qemu_run_timers (clock=)
> at qemu-timer.c:505
> #8 0x004ce806 in qemu_run_all_timers () at qemu-timer.c:619
> #9 0x00419463 in main_loop_wait (nonblocking= out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1339
> #10 0x00433927 in kvm_main_loop () at
> /build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1590
> #11 0x0041a3a6 in main_loop (argc=,
> argv=, envp=)
> at /build/home/tlv/akivity/qemu-kvm/vl.c:1369
> #12 main (argc=, argv=,
> envp=) at /build/home/tlv/akivity/qemu-kvm/vl.c:3257
>
> The vmstate being migrated is "gpe".
>
>
>
>>
>> +#define VMSTATE_GPE_ARRAY(_field, _state)\
>> + { \
>> + .name = (stringify(_field)), \
>> + .version_id = 0,\
>> + .num= GPE_LEN, \
>> + .info =&vmstate_info_uint16, \
>> + .size = sizeof(uint16_t), \
>> + .flags = VMS_ARRAY | VMS_POINTER, \
>> + .offset = vmstate_offset_pointer(_state, _field, uint8_t), \
>> + }
>> +
>>static const VMStateDescription vmstate_gpe = {
>>.name = "gpe",
>>.version_id = 1,
>>.minimum_version_id = 1,
>>.minimum_version_id_old = 1,
>>.fields = (VMStateField []) {
>> -VMSTATE_UINT16(sts, struct gpe_regs),
>> -VMSTATE_UINT16(en, struct gpe_regs),
>> +VMSTATE_GPE_ARRAY(sts, ACPIGPE),
>> +VMSTATE_GPE_ARRAY(en, ACPIGPE),
>>VMSTATE_END_OF_LIST()
>>}
>>};
>
> I'm no vmstate expert, but this does look odd. Why both VMS_ARRAY and
> VMS_POINTER? aren't we trying to save/restore a simple 16-bit value? Or
> at least we did before this patch.
That's right. the difference is, the new member type became uint8_t*.
Does the following help?
Unforunately not. The core is very similar though:
#0 0x0049aff4 in qemu_put_be16s (f=0x2427490, pv=0x1ae7580,
size=2) at hw/hw.h:108
#1 put_uint16 (f=0x2427490, pv=0x1ae7580, size=2) at savevm.c:855
#2 0x0049c3e4 in vmstate_save_state (f=0x2427490,
vmsd=0x6f0b00, opaque=0x21f5ef0) at savevm.c:1436
#3 0x0049c3b6 in vmstate_save_state (f=0x2427490,
vmsd=0x6f0aa0, opaque=0x21f5b90) at savevm.c:1434
#4 0x0049c6f1 in vmstate_save (mon=,
f=0x2427490) at savevm.c:1459
#5 qemu_savevm_state_complete (mon=, f=0x2427490)
at savevm.c:1600
#6 0x0049455a in migrate_fd_put_ready (opaque=0x21fa8c0) at
migration.c:383
#7 0x004ce2eb in qemu_run_timers (clock=)
at qemu-timer.c:505
#8 0x004ce806 in qemu_run_all_timers () at qemu-timer.c:619
#9 0x00419463 in main_loop_wait (nonblocking=out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1339
#10 0x00433927 in kvm_main_loop () at
/build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1590
#11 0x0041a3a6 in main_loop (argc=,
argv=, envp=)
at /build/home/tlv/akivity/qemu-kvm/vl.c:1369
#12 main (argc=, argv=,
envp=) at /build/home/tlv/akivity/qemu-kvm/vl.c:3257
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] 2.6.32.x guest dies when trying to run tcpdump
OK, just wanted to let You know I were testing it quite a lot, and I'm not able to reproduce this with 2.6.38.3-rc1. So the bug must have been fixed. I'll bisect it to find proper fix so it can be posted to stable... n. On Sat, Apr 02, 2011 at 09:42:26PM +0200, Nikola Ciprich wrote: > Hello Stefan! > > > It looks like your guests are SMP. How many vcpus are you running? > > How many physical cpus does /proc/cpuinfo list on the host? > one of guests is SMP (8cpus), one is UP, host has 2x4 cores. > > > > Is the host overloaded when this occurs? > nope > > > > > Are there any clues in host dmesg? > nothing :( > I guess I shall try 2.6.38 or maybe latest git to check if the problem > is still present... > > > > > Stefan > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > - > Ing. Nikola CIPRICH > LinuxBox.cz, s.r.o. > 28. rijna 168, 709 01 Ostrava > > tel.: +420 596 603 142 > fax:+420 596 621 273 > mobil: +420 777 093 799 > > www.linuxbox.cz > > mobil servis: +420 737 238 656 > email servis: ser...@linuxbox.cz > - > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz -
Re: [Qemu-devel] [PATCH 24/26] acpi, acpi_piix: factor out GPE logic
On Sun, Apr 17, 2011 at 04:17:51PM +0300, Avi Kivity wrote:
> On 03/16/2011 11:29 AM, Isaku Yamahata wrote:
>> factor out ACPI GPE logic. Later it will be used by ICH9 ACPI.
>>
>
> I think this patch is causing qemu-kvm failures on migration:
> (gdb) bt
> #0 0x0049aff4 in qemu_put_be16s (f=0x1a74490, pv=0x2c02580,
> size=2) at hw/hw.h:108
> #1 put_uint16 (f=0x1a74490, pv=0x2c02580, size=2) at savevm.c:855
> #2 0x0049c3e4 in vmstate_save_state (f=0x1a74490,
> vmsd=0x6f0b00, opaque=0x1842ef0) at savevm.c:1436
> #3 0x0049c3b6 in vmstate_save_state (f=0x1a74490,
> vmsd=0x6f0aa0, opaque=0x1842b90) at savevm.c:1434
> #4 0x0049c6f1 in vmstate_save (mon=,
> f=0x1a74490) at savevm.c:1459
> #5 qemu_savevm_state_complete (mon=, f=0x1a74490)
> at savevm.c:1600
> #6 0x0049455a in migrate_fd_put_ready (opaque=0x1847890) at
> migration.c:383
> #7 0x004ce2eb in qemu_run_timers (clock=)
> at qemu-timer.c:505
> #8 0x004ce806 in qemu_run_all_timers () at qemu-timer.c:619
> #9 0x00419463 in main_loop_wait (nonblocking= out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1339
> #10 0x00433927 in kvm_main_loop () at
> /build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1590
> #11 0x0041a3a6 in main_loop (argc=,
> argv=, envp=)
> at /build/home/tlv/akivity/qemu-kvm/vl.c:1369
> #12 main (argc=, argv=,
> envp=) at /build/home/tlv/akivity/qemu-kvm/vl.c:3257
>
> The vmstate being migrated is "gpe".
>
>
>
>>
>> +#define VMSTATE_GPE_ARRAY(_field, _state)\
>> + { \
>> + .name = (stringify(_field)), \
>> + .version_id = 0,\
>> + .num= GPE_LEN, \
>> + .info =&vmstate_info_uint16, \
>> + .size = sizeof(uint16_t), \
>> + .flags = VMS_ARRAY | VMS_POINTER, \
>> + .offset = vmstate_offset_pointer(_state, _field, uint8_t), \
>> + }
>> +
>> static const VMStateDescription vmstate_gpe = {
>> .name = "gpe",
>> .version_id = 1,
>> .minimum_version_id = 1,
>> .minimum_version_id_old = 1,
>> .fields = (VMStateField []) {
>> -VMSTATE_UINT16(sts, struct gpe_regs),
>> -VMSTATE_UINT16(en, struct gpe_regs),
>> +VMSTATE_GPE_ARRAY(sts, ACPIGPE),
>> +VMSTATE_GPE_ARRAY(en, ACPIGPE),
>> VMSTATE_END_OF_LIST()
>> }
>> };
>
> I'm no vmstate expert, but this does look odd. Why both VMS_ARRAY and
> VMS_POINTER? aren't we trying to save/restore a simple 16-bit value? Or
> at least we did before this patch.
That's right. the difference is, the new member type became uint8_t*.
Does the following help?
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 96f5222..3a8fece 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -214,10 +214,9 @@ static int vmstate_acpi_post_load(void *opaque, int
version_id)
{ \
.name = (stringify(_field)), \
.version_id = 0,\
- .num= GPE_LEN, \
.info = &vmstate_info_uint16, \
.size = sizeof(uint16_t), \
- .flags = VMS_ARRAY | VMS_POINTER, \
+ .flags = VMS_SINGLE | VMS_POINTER, \
.offset = vmstate_offset_pointer(_state, _field, uint8_t), \
}
--
yamahata
Re: [Qemu-devel] [PATCH 24/26] acpi, acpi_piix: factor out GPE logic
On 03/16/2011 11:29 AM, Isaku Yamahata wrote:
factor out ACPI GPE logic. Later it will be used by ICH9 ACPI.
I think this patch is causing qemu-kvm failures on migration:
(gdb) bt
#0 0x0049aff4 in qemu_put_be16s (f=0x1a74490, pv=0x2c02580,
size=2) at hw/hw.h:108
#1 put_uint16 (f=0x1a74490, pv=0x2c02580, size=2) at savevm.c:855
#2 0x0049c3e4 in vmstate_save_state (f=0x1a74490,
vmsd=0x6f0b00, opaque=0x1842ef0) at savevm.c:1436
#3 0x0049c3b6 in vmstate_save_state (f=0x1a74490,
vmsd=0x6f0aa0, opaque=0x1842b90) at savevm.c:1434
#4 0x0049c6f1 in vmstate_save (mon=,
f=0x1a74490) at savevm.c:1459
#5 qemu_savevm_state_complete (mon=, f=0x1a74490)
at savevm.c:1600
#6 0x0049455a in migrate_fd_put_ready (opaque=0x1847890) at
migration.c:383
#7 0x004ce2eb in qemu_run_timers (clock=)
at qemu-timer.c:505
#8 0x004ce806 in qemu_run_all_timers () at qemu-timer.c:619
#9 0x00419463 in main_loop_wait (nonblocking=out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1339
#10 0x00433927 in kvm_main_loop () at
/build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1590
#11 0x0041a3a6 in main_loop (argc=,
argv=, envp=)
at /build/home/tlv/akivity/qemu-kvm/vl.c:1369
#12 main (argc=, argv=,
envp=) at /build/home/tlv/akivity/qemu-kvm/vl.c:3257
The vmstate being migrated is "gpe".
+#define VMSTATE_GPE_ARRAY(_field, _state)\
+ { \
+ .name = (stringify(_field)), \
+ .version_id = 0,\
+ .num= GPE_LEN, \
+ .info =&vmstate_info_uint16, \
+ .size = sizeof(uint16_t), \
+ .flags = VMS_ARRAY | VMS_POINTER, \
+ .offset = vmstate_offset_pointer(_state, _field, uint8_t), \
+ }
+
static const VMStateDescription vmstate_gpe = {
.name = "gpe",
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField []) {
-VMSTATE_UINT16(sts, struct gpe_regs),
-VMSTATE_UINT16(en, struct gpe_regs),
+VMSTATE_GPE_ARRAY(sts, ACPIGPE),
+VMSTATE_GPE_ARRAY(en, ACPIGPE),
VMSTATE_END_OF_LIST()
}
};
I'm no vmstate expert, but this does look odd. Why both VMS_ARRAY and
VMS_POINTER? aren't we trying to save/restore a simple 16-bit value? Or
at least we did before this patch.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Para-virtualized ram-based filesystem?
On 04/16/2011 02:58 AM, Ritchie, Stuart wrote: > >You can do this with ivshmem today. You give it a path to a shared >memory file, and then there's a path in sysfs that you can mmap() in >userspace in the guest. Please correct me if I am wrong, but with ivshmem you must to manage your world within a single, fixed size region. I appreciate the simplicity of mapping the whole region all in one go, but our requirements are a bit different. Even if you could pass multiple -device ivshmem instances, it's still a fixed environment. Right? You could place a read-only filesystem (say iso9660) in the region and mount it; it will then appear as a complete filesystem. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 1/3] slirp: Implement TFTP Blocksize option
On 04/11/2011 10:10 PM, Herve Poussineau wrote: From: Herv� Poussineau Note: your charset is UTF-8 but this is Latin-1 (I think). Please use consistent charsets. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] Slirp reverse UDP firewall
On 04/14/2011 11:04 PM, Daisuke Nojiri wrote: Hi, Avi, Complex and complete firewalling is probably out of my focus for now. I'm trying to introduce a simple reverse firewall functionality which filters outgoing patckets based on only destination address and port. Since Qemu doesn't have any reverse firewall currently, I believe this is a good addition and start. IMO this is the wrong direction. Integrating libpcap should be simple (a call to pcap_offline_filter()) and immediately satisfy all current and future firewalling needs. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 2/6] kvm: add kvmclock to its second bit
On 2011-04-17 00:10, Marcelo Tosatti wrote:
> From: Glauber Costa
>
> We have two bits that can represent kvmclock in cpuid.
> They signal the guest which msr set to use. When we tweak flags
> involving this value - specially when we use "-", we have to act on both.
>
> Besides adding it to the kvm features list, we also have to "break" the
> assumption represented by the break in lookup_feature.
>
> Signed-off-by: Glauber Costa
> Signed-off-by: Avi Kivity
> ---
> target-i386/cpuid.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
> index 814d13e..5e48d35 100644
> --- a/target-i386/cpuid.c
> +++ b/target-i386/cpuid.c
> @@ -73,7 +73,7 @@ static const char *ext3_feature_name[] = {
> };
>
> static const char *kvm_feature_name[] = {
> -"kvmclock", "kvm_nopiodelay", "kvm_mmu", NULL, "kvm_asyncpf", NULL,
> NULL, NULL,
> +"kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf",
> NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> @@ -193,7 +193,6 @@ static int lookup_feature(uint32_t *pval, const char *s,
> const char *e,
> for (mask = 1, ppc = featureset; mask; mask <<= 1, ++ppc)
> if (*ppc && !altcmp(s, e, *ppc)) {
> *pval |= mask;
> -break;
> }
> return (mask ? 1 : 0);
> }
This is required on top to fix the issues Anthony was seeing:
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 5e48d35..b7e20e8 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -189,12 +189,14 @@ static int lookup_feature(uint32_t *pval, const char *s,
const char *e,
{
uint32_t mask;
const char **ppc;
+int found = 0;
for (mask = 1, ppc = featureset; mask; mask <<= 1, ++ppc)
if (*ppc && !altcmp(s, e, *ppc)) {
*pval |= mask;
+found = 1;
}
-return (mask ? 1 : 0);
+return found;
}
static void add_flagname_to_bitmaps(const char *flagname, uint32_t *features,
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] how to debug bochs sbios on qemu?
hi, I am currently using an old version of qemu which is still using bios from bochs project. And I am wondering how to capture the output of those BX_INFO and BX_DEBUG macros? Thanks, CJ
[Qemu-devel] how to debug bochs sbios?
hi, I am currently using an old version of qemu which is still using bios from bochs project. And I am wondering how to capture the output of those BX_INFO and BX_DEBUG macros? Thanks, CJ
[Qemu-devel] [PATCH] kvm: ppc: warn user on PAGE_SIZE mismatch
On PPC, the default PAGE_SIZE is 64kb. Unfortunately, the hardware
alignments don't match here: There are RAM and MMIO regions within
a single page when it's 64kb in size.
So the only way out for now is to tell the user that he should use 4k
PAGE_SIZE.
This patch gives the user a hint on that, telling him that failing to
register a prefix slot is most likely to be caused by mismatching PAGE_SIZE.
This way it's also more future-proof, as bigger PAGE_SIZE can easily be
supported by other machines then, as long as they stick to 64kb granularities.
Signed-off-by: Alexander Graf
---
kvm-all.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 1d7e8ea..ff30858 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -577,6 +577,11 @@ static void kvm_set_phys_mem(target_phys_addr_t
start_addr, ram_addr_t size,
if (err) {
fprintf(stderr, "%s: error registering prefix slot: %s\n",
__func__, strerror(-err));
+#ifdef TARGET_PPC
+fprintf(stderr, "%s: This is probably because your kernel's " \
+"PAGE_SIZE is too big. Please try to use 4k " \
+"PAGE_SIZE!\n", __func__);
+#endif
abort();
}
}
--
1.6.0.2
[Qemu-devel] [PATCH] kvm: ppc: detect old headers
When compiling Qemu with older kernel headers, the PVR setting
mechanism isn't available yet. Unfortunately, back then I didn't add
a capability we could check against, so all we can do is add a configure
test to see if we support PVR setting. For BookE, we don't care yet.
While at it, also memset the sregs to zero, so we have sane state in
case we add fields later.
This fixes compilation errors with KVM enabled on older kernel headers
(like 2.6.32).
Signed-off-by: Alexander Graf
---
configure| 18 ++
target-ppc/kvm.c | 24 +---
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index da2da04..7b90e1e 100755
--- a/configure
+++ b/configure
@@ -1772,6 +1772,21 @@ recent kvm-kmod from
http://sourceforge.net/projects/kvm.";
fi
##
+# test for ppc kvm pvr setting
+
+if test "$kvm" = "yes" && test "$cpu" = "ppc" -o "$cpu" = "ppc64"; then
+cat > $TMPC <
+int main(void) { struct kvm_sregs s; s.pvr = 0; return 0; }
+EOF
+if compile_prog "$kvm_cflags" "" ; then
+kvm_ppc_pvr=yes
+else
+kvm_ppc_pvr=no
+fi
+fi
+
+##
# test for vhost net
if test "$vhost_net" != "no"; then
@@ -3241,6 +3256,9 @@ case "$target_arch2" in
if test $vhost_net = "yes" ; then
echo "CONFIG_VHOST_NET=y" >> $config_target_mak
fi
+ if test $kvm_ppc_pvr = "yes" ; then
+echo "CONFIG_KVM_PPC_PVR=y" >> $config_target_mak
+ fi
fi
esac
if test "$target_bigendian" = "yes" ; then
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2cfb24b..93d91df 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -80,10 +80,28 @@ int kvm_arch_init(KVMState *s)
int kvm_arch_init_vcpu(CPUState *cenv)
{
int ret = 0;
-struct kvm_sregs sregs;
-sregs.pvr = cenv->spr[SPR_PVR];
-ret = kvm_vcpu_ioctl(cenv, KVM_SET_SREGS, &sregs);
+if ((cenv->mmu_model == POWERPC_MMU_BOOKE) ||
+(cenv->mmu_model == POWERPC_MMU_BOOKE_FSL)) {
+/* What we're really trying to say is "if we're on BookE, we use
+ the native PVR for now". This is the only sane way to check
+ it though, so we potentially confuse users that they can run
+ BookE guests on BookS. Let's hope nobody dares enough :) */
+} else {
+#ifdef CONFIG_KVM_PPC_PVR
+struct kvm_sregs sregs;
+
+memset(&sregs, 0, sizeof(sregs));
+sregs.pvr = cenv->spr[SPR_PVR];
+ret = kvm_vcpu_ioctl(cenv, KVM_SET_SREGS, &sregs);
+#else
+ret = -ENOSYS;
+#endif
+
+if (ret) {
+fprintf(stderr, "kvm error: missing PVR setting capability\n");
+}
+}
idle_timer = qemu_new_timer_ns(vm_clock, kvm_kick_env, cenv);
--
1.6.0.2
[Qemu-devel] Question about vpc 004 testcase of qemu-iotests
Hello all, I use qemu-iotests to test vpc part of master tree. An error occurred when I type ./check -vpc. Error message is as follows: 004 4s ... - output mismatch (see 004.out.bad) --- 004.out 2011-04-10 15:43:21.819400771 +0800 +++ 004.out.bad 2011-04-17 10:45:00.642745274 +0800 @@ -9,7 +9,8 @@ write failed: Input/output error write at image boundary -write failed: Input/output error +wrote 4096/4096 bytes at offset 134217728 +4 KiB, 1 ops; 0. sec (28.678 KiB/sec and 7.1694 ops/sec) write past image boundary write failed: Input/output error @@ -28,7 +29,8 @@ read failed: Input/output error read at image boundary -read failed: Input/output error +read 4096/4096 bytes at offset 134217728 +4 KiB, 1 ops; 0. sec (62.004 MiB/sec and 15873.0159 ops/sec) read past image boundary read failed: Input/output error I am wondering whether it is a bug of block/vpc.c?? Thanks Mitnick
