[Qemu-devel] [PATCH] docs/specs/fw_cfg.txt: Add fw_cfg documentation
This initial version covers the generic portions of fw_cfg and the x86/x86-64 architecture specific portions of fw_cfg. Signed-off-by: Jordan Justen jljus...@gmail.com --- docs/specs/fw_cfg.txt | 168 + 1 files changed, 168 insertions(+), 0 deletions(-) create mode 100644 docs/specs/fw_cfg.txt diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt new file mode 100644 index 000..554ac48 --- /dev/null +++ b/docs/specs/fw_cfg.txt @@ -0,0 +1,168 @@ + += Hardware Interface = + +== Index Port == +* Two bytes in width (guest native endianness) +* Write only +* Can be an I/O port and/or Memory-Mapped I/O +* Location is platform dependent + +A write to this port sets the index of a firmware configuration item +which can subsequently be accessed at the data port. + +Setting the index port will cause the data offset to be set to zero. +The data offset impacts which data is accessed via the data port, and +is explained below. + +Bit15 of the index value indicates if the configuration setting is +architecture specific. If bit15 of the index is 0, then the item is +a generic configuration item. If bit15 of the index is 1, then the +item is specific to a particular architecture. (In other words, +generic configuration items are accessed when the index is between +0x-0x7fff, and architecture specific configuration items are +accessed when the index is between 0x8000-0x.) + +Bit14 of the index value indicates if the configuration setting is +being written. If bit14 of the index is 0, then the item is only +being read, and all write access to the data port will be completely +ignored. If bit14 of the index is 1, then the item's data can be +written to by writing to the data port. (In other words, +configuration write mode is enabled when the index is between +0x4000-0x7fff or 0xc000-0x.) + +== Data Port == +* One byte in width +* Read + Write +* Can be an I/O port and/or Memory-Mapped I/O +* Location is platform dependent + +The data port allows for access to an array of bytes for each firmware +configuration data item. This item is selected by a write to the +index port. + +Initially following a write to the index port, the data offset will +be set to zero. Each successful read or write to the data port will +cause the data offset to increment by one byte. There is only one +data offset value, and it will be incremented by accesses to any of +the I/O or MMIO data ports. A write access will not increment the +data offset if the selected index did not have bit14 set. + +Each firmware configuration item has a maximum length of data +associated with the item. After the data offset has passed the +end of this maximum data length, then any reads will return a data +value of 0x00, and all writes will be ignored. + +A read of the data port will return the current byte of the firmware +configuration item. + +A write of the data port will set the current byte of the firmware +configuration item. A write access will not impact the firmware +configuration data if the selected index did not have bit14 set. + +== x86, x86-64 Ports == + +I/O Index Port: 0x510 +I/O Data Port: 0x511 +MMIO Index Port: N/A +MMIO Data Port: N/A + += Firmware Configuration Items = + +== Ranges == + +There are up to 0x4000 generic firmware configuration items, and up to +0x4000 architecturally specific firmware configuration items. + +Index Port Range Range Usage + --- +0x - 0x3fff Generic Items (0x - 0x3fff) (Read-only) +0x4000 - 0x7fff Generic Items (0x - 0x3fff) (Read+Write) +0x8000 - 0xbfff Architecture Specific Items (0x - 0x3fff) (Read-only) +0xc000 - 0x Architecture Specific Items (0x - 0x3fff) (Read+Write) + +== Data Items Format == + +uint8_t : 8-bit unsigned integer +uint16_t: 16-bit unsigned integer +uint32_t: 32-bit unsigned integer +uint64_t: 64-bit unsigned integer +n bytes : byte array of length n +array : byte array of a format specific size +string : null byte terminated ascii string + +All integer data is accessed with the least significant byte first and +then proceeding to more significant bytes on subsequent accesses. + +== Generic Items == + +Index Data Type Data Meaning +- - +0x00 4 bytesSignature - 'Q', 'E', 'M', 'U' +0x01 uint32_t ID +0x02 16 bytes System UUID +0x03 uint64_t RAM Size +0x04 uint16_t 0 indicates graphics mode, otherwise non-graphics mode +0x05 uint16_t The number of SMP CPUs +0x06 uint16_t Machine ID +0x07 uint32_t Kernel Address +0x08 uint32_t Kernel Size +0x09 string Kernel command line +0x0a uint32_t Initrd Address +0x0b uint32_t Initrd Size +0x0c uint16_t Boot Device +0x0d array NUMA Data +0x0e uint16_t Boot Menu +0x0f uint16_t The maximum number of CPUs (hotpluggable) +0x10 uint32_t Kernel Entry +0x11 array Kernel Data +0x12 array Initrd Data +0x13
Re: [Qemu-devel] Re: [PATCH 00/14] lm32: Milkymist board support
On Thu, Mar 24, 2011 at 10:28:49AM +0100, Alexander Graf wrote: On 16.03.2011, at 18:08, Alexander Graf wrote: On 03/07/2011 11:32 PM, Michael Walle wrote: This is the second (and last) patchset of the LatticeMico32 support. It adds almost complete support for the opensource and openhardware Milkymist One board [1]. [1] http://www.milkymist.org/mmone.html From my side you get: Acked-by: Alexander Graf ag...@suse.de But it'd be great if the respective subsystem maintainers could also take a look at code affecting them. Ping? Enough time passed for people to comment now, no? I've applied this now, thanks Michael and Alex. Cheers
Re: [Qemu-devel] [PATCH 00/19] s390x emulation support
On 04.04.2011, at 00:43, Alexander Graf wrote: On 04.04.2011, at 00:37, Aurelien Jarno wrote: On Tue, Mar 29, 2011 at 03:29:27PM +0200, Alexander Graf wrote: We've had support for running s390x guests with KVM for a while now. This patch set also enables support for running s390x guests in system as well as linux-user mode in emulation! Within this scope, I again want to stress that this is _not_ supposed to replace Hercules - the s390 emulator - in any way. The only target supported by qemu is Linux. You can only run Linux applications with linux-user emulation and Linux guest OSs with the system emulation. All the device logic (and 24 bit mode) for running legacy stuff is missing. Use Hercules for those! I have successfully run the following guest OSs: - SUSE Linux Enterprise Server 11 SP1 - Debian Lenny Both of which work just fine on x86_64 and ppc hosts. Other hosts should also work. The only thing that did not work for me is network. Somehow networking only works with KVM enabled, so there is probably some bug involved still. Either way - rejoice! As with this patch set you can finally fulfill your mainframe desires on your local workstation. And - most importantly - finally test patches to virtio against s390! For images, I'm hoping for Aurelien to provide Debian images that run in qemu. Other distributions only provide S390x target support in their enterprise variants, keeping me from redistributing images :(. If you're trying to get things rolling yourself, make sure to use a recent kernel that has support for the virtio architecture and virtio console support - otherwise you won't see output. The linux user mode emulation part only support 64bit binaries, so running Debian binaries with that one is out of question for now. Use the system emulation mode if you really need to run Debian binaries. For the lazy ones: git://repo.or.cz/qemu/agraf.git s390-tcg-v2 v1 - v2: - fix broken s390-virtio-serial - fix broken s390 kvm target - always set 64bit flag for s390x binaries in elf loader - remove redundant EXECUTE_SVC - advance psw.addr in syscall execution path - remove FPReg definition - add descriptions to more cc_ops - add comment on time2tod - describe EXCP_EXT - use new clock syntax - use float_chs - use float compare built-ins - remove redundant EXECUTE_SVC - don't pass env into DisasContext - remove if 0'd code - truncate at 80 chars - enable disas debug by default (-d in_asm) - remove explicit psw.addr advancing on SVC Alexander Graf (14): Only build ivshmem when CONFIG_PCI CONFIG_KVM virtio: use generic name when possible s390x: fix KVM target s390x: fix s390-virtio-serial s390x: Enable s390x-softmmu target s390x: Dispatch interrupts to KVM or the real CPU s390x: Adjust GDB stub s390x: virtio machine storage keys s390x: Prepare cpu.h for emulation s390x: helper functions for system emulation s390x: Implement opcode helpers s390x: Adjust internal kvm code s390x: translate engine for s390x CPU s390x: build s390x by default Ulrich Hecht (5): s390x: Enable disassembler for s390x s390x: Enable nptl for s390x s390x: enable CPU_QuadU s390x: s390x-linux-user support linux-user: define a couple of syscalls for non-uid16 targets Makefile.target |8 +- blockdev.c |2 +- configure|3 + cpu-all.h|2 +- cpu-exec.c |8 + default-configs/s390x-linux-user.mak |1 + disas.c |6 + gdbstub.c|8 +- hw/s390-virtio-bus.c | 18 +- hw/s390-virtio-bus.h |4 +- hw/s390-virtio.c | 21 +- hw/virtio-pci.c |3 + linux-user/elfload.c | 19 + linux-user/main.c| 83 + linux-user/s390x/syscall.h | 25 + linux-user/s390x/syscall_nr.h| 349 +++ linux-user/s390x/target_signal.h | 26 + linux-user/s390x/termbits.h | 283 ++ linux-user/signal.c | 314 +++ linux-user/syscall.c | 143 +- linux-user/syscall_defs.h| 56 +- s390x.ld | 194 ++ scripts/qemu-binfmt-conf.sh |4 +- target-s390x/cpu.h | 770 +- target-s390x/exec.h | 20 + target-s390x/helper.c| 581 - target-s390x/helpers.h | 151 + target-s390x/kvm.c | 62 +- target-s390x/op_helper.c | 2880 +++- target-s390x/translate.c | 5116 +- vl.c |6 +- 31 files changed, 11005 insertions(+), 161 deletions(-) create mode 100644 default-configs/s390x-linux-user.mak create mode 100644
[Qemu-devel] A question about qemu 0.9.1
I am learning qemu 0.9.1，and there is a question.After I complied the
project,there are some codes in /i386-softmmu/op.h
case INDEX_op_movl_A0_EAX: {
extern void op_movl_A0_EAX();
memcpy(gen_code_ptr, (void *)((char *)op_movl_A0_EAX+0), 3);
gen_code_ptr += 3;
}
Where is this op_movl_A0_EAX() come from?I can't find it in the op.c or
even the whole project.But it does exist in the op.o.I check the file
Makefile.target
op.o: op.c
$(CC) $(OP_CFLAGS) $(CPPFLAGS) -c -o $@ $
op.o depends only on op.c,isn't it?Then where does this
op_movl_A0_EAX() come from?
Maybe I have made some mistakes.Correct me if I am wrong...
Please give me some help.I was blocked here for a long time.
Thank you very much!
--Terry
[Qemu-devel] [PATCH 0/4] target-arm: Make Neon helpers use correct FP status
This is a patchset which takes the approach discussed in the comments on my earlier patch to fix this bug. We compile *_helper.c with HELPER_CFLAGS, so targets don't need to put all their helper routines in op_helper.c. (This only changes behaviour for target-arm because that's the only target that has files matching that pattern.) Patches two and three are large but fairly mechanical changes to remove explicit CPUState* arguments in favour of just using global 'env' in the two files which can now access it. Finally, patch 4 is a two-liner to use the Neon FP status word... Peter Maydell (4): Makefile.target: Allow target helpers to be in any *_helper.c file target-arm: Use global env in neon_helper.c helpers target-arm: Use global env in iwmmxt_helper.c helpers target-arm: Make Neon helper routines use correct FP status Makefile.target|2 +- target-arm/helpers.h | 256 ++-- target-arm/iwmmxt_helper.c | 80 ++ target-arm/neon_helper.c | 147 - target-arm/translate.c | 248 --- 5 files changed, 349 insertions(+), 384 deletions(-)
[Qemu-devel] [PATCH 1/4] Makefile.target: Allow target helpers to be in any *_helper.c file
Build all files matching *_helper.c with HELPER_CFLAGS, not just op_helper.c. This allows you to put target helper functions which use the global 'env' variable in multiple source files. This only affects the ARM target as all the other targets currently only have op_helper.c. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- Makefile.target |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.target b/Makefile.target index 04e20dd..45acdba 100644 --- a/Makefile.target +++ b/Makefile.target @@ -94,7 +94,7 @@ tcg/tcg.o: cpu.h # HELPER_CFLAGS is used for all the code compiled with static register # variables -op_helper.o cpu-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) +%_helper.o cpu-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) # Note: this is a workaround. The real fix is to avoid compiling # cpu_signal_handler() in cpu-exec.c. -- 1.7.1
[Qemu-devel] [PATCH 4/4] target-arm: Make Neon helper routines use correct FP status
Make the Neon helper routines use the correct FP status from the CPUEnv rather than using a dummy static one. This means they will correctly handle denormals and NaNs and will set FPSCR exception bits properly. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- target-arm/neon_helper.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c index 315e693..c3ac96a 100644 --- a/target-arm/neon_helper.c +++ b/target-arm/neon_helper.c @@ -18,8 +18,7 @@ #define SET_QC() env-vfp.xregs[ARM_VFP_FPSCR] = CPSR_Q -static float_status neon_float_status; -#define NFS neon_float_status +#define NFS (env-vfp.standard_fp_status) #define NEON_TYPE1(name, type) \ typedef struct \ -- 1.7.1
[Qemu-devel] [PATCH 3/4] target-arm: Use global env in iwmmxt_helper.c helpers
Use the global 'env' variable in the helper functions in iwmmxt_helper.c. This means we don't need to pass env as an argument to them any more. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- target-arm/helpers.h | 122 +- target-arm/iwmmxt_helper.c | 80 target-arm/translate.c | 129 +--- 3 files changed, 156 insertions(+), 175 deletions(-) diff --git a/target-arm/helpers.h b/target-arm/helpers.h index 0705b9c..ae701e8 100644 --- a/target-arm/helpers.h +++ b/target-arm/helpers.h @@ -375,47 +375,47 @@ DEF_HELPER_2(iwmmxt_macsw, i64, i64, i64) DEF_HELPER_2(iwmmxt_macuw, i64, i64, i64) DEF_HELPER_1(iwmmxt_setpsr_nz, i32, i64) -#define DEF_IWMMXT_HELPER_SIZE_ENV(name) \ -DEF_HELPER_3(iwmmxt_##name##b, i64, env, i64, i64) \ -DEF_HELPER_3(iwmmxt_##name##w, i64, env, i64, i64) \ -DEF_HELPER_3(iwmmxt_##name##l, i64, env, i64, i64) \ - -DEF_IWMMXT_HELPER_SIZE_ENV(unpackl) -DEF_IWMMXT_HELPER_SIZE_ENV(unpackh) - -DEF_HELPER_2(iwmmxt_unpacklub, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackluw, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpacklul, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackhub, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackhuw, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackhul, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpacklsb, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpacklsw, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpacklsl, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackhsb, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackhsw, i64, env, i64) -DEF_HELPER_2(iwmmxt_unpackhsl, i64, env, i64) - -DEF_IWMMXT_HELPER_SIZE_ENV(cmpeq) -DEF_IWMMXT_HELPER_SIZE_ENV(cmpgtu) -DEF_IWMMXT_HELPER_SIZE_ENV(cmpgts) - -DEF_IWMMXT_HELPER_SIZE_ENV(mins) -DEF_IWMMXT_HELPER_SIZE_ENV(minu) -DEF_IWMMXT_HELPER_SIZE_ENV(maxs) -DEF_IWMMXT_HELPER_SIZE_ENV(maxu) - -DEF_IWMMXT_HELPER_SIZE_ENV(subn) -DEF_IWMMXT_HELPER_SIZE_ENV(addn) -DEF_IWMMXT_HELPER_SIZE_ENV(subu) -DEF_IWMMXT_HELPER_SIZE_ENV(addu) -DEF_IWMMXT_HELPER_SIZE_ENV(subs) -DEF_IWMMXT_HELPER_SIZE_ENV(adds) - -DEF_HELPER_3(iwmmxt_avgb0, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_avgb1, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_avgw0, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_avgw1, i64, env, i64, i64) +#define DEF_IWMMXT_HELPER_SIZE(name) \ +DEF_HELPER_2(iwmmxt_##name##b, i64, i64, i64) \ +DEF_HELPER_2(iwmmxt_##name##w, i64, i64, i64) \ +DEF_HELPER_2(iwmmxt_##name##l, i64, i64, i64) \ + +DEF_IWMMXT_HELPER_SIZE(unpackl) +DEF_IWMMXT_HELPER_SIZE(unpackh) + +DEF_HELPER_1(iwmmxt_unpacklub, i64, i64) +DEF_HELPER_1(iwmmxt_unpackluw, i64, i64) +DEF_HELPER_1(iwmmxt_unpacklul, i64, i64) +DEF_HELPER_1(iwmmxt_unpackhub, i64, i64) +DEF_HELPER_1(iwmmxt_unpackhuw, i64, i64) +DEF_HELPER_1(iwmmxt_unpackhul, i64, i64) +DEF_HELPER_1(iwmmxt_unpacklsb, i64, i64) +DEF_HELPER_1(iwmmxt_unpacklsw, i64, i64) +DEF_HELPER_1(iwmmxt_unpacklsl, i64, i64) +DEF_HELPER_1(iwmmxt_unpackhsb, i64, i64) +DEF_HELPER_1(iwmmxt_unpackhsw, i64, i64) +DEF_HELPER_1(iwmmxt_unpackhsl, i64, i64) + +DEF_IWMMXT_HELPER_SIZE(cmpeq) +DEF_IWMMXT_HELPER_SIZE(cmpgtu) +DEF_IWMMXT_HELPER_SIZE(cmpgts) + +DEF_IWMMXT_HELPER_SIZE(mins) +DEF_IWMMXT_HELPER_SIZE(minu) +DEF_IWMMXT_HELPER_SIZE(maxs) +DEF_IWMMXT_HELPER_SIZE(maxu) + +DEF_IWMMXT_HELPER_SIZE(subn) +DEF_IWMMXT_HELPER_SIZE(addn) +DEF_IWMMXT_HELPER_SIZE(subu) +DEF_IWMMXT_HELPER_SIZE(addu) +DEF_IWMMXT_HELPER_SIZE(subs) +DEF_IWMMXT_HELPER_SIZE(adds) + +DEF_HELPER_2(iwmmxt_avgb0, i64, i64, i64) +DEF_HELPER_2(iwmmxt_avgb1, i64, i64, i64) +DEF_HELPER_2(iwmmxt_avgw0, i64, i64, i64) +DEF_HELPER_2(iwmmxt_avgw1, i64, i64, i64) DEF_HELPER_2(iwmmxt_msadb, i64, i64, i64) @@ -434,26 +434,26 @@ DEF_HELPER_1(iwmmxt_msbb, i32, i64) DEF_HELPER_1(iwmmxt_msbw, i32, i64) DEF_HELPER_1(iwmmxt_msbl, i32, i64) -DEF_HELPER_3(iwmmxt_srlw, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_srll, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_srlq, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_sllw, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_slll, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_sllq, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_sraw, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_sral, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_sraq, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_rorw, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_rorl, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_rorq, i64, env, i64, i32) -DEF_HELPER_3(iwmmxt_shufh, i64, env, i64, i32) - -DEF_HELPER_3(iwmmxt_packuw, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_packul, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_packuq, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_packsw, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_packsl, i64, env, i64, i64) -DEF_HELPER_3(iwmmxt_packsq, i64, env, i64, i64) +DEF_HELPER_2(iwmmxt_srlw, i64, i64, i32) +DEF_HELPER_2(iwmmxt_srll, i64, i64, i32) +DEF_HELPER_2(iwmmxt_srlq, i64, i64, i32) +DEF_HELPER_2(iwmmxt_sllw, i64, i64, i32) +DEF_HELPER_2(iwmmxt_slll, i64, i64, i32) +DEF_HELPER_2(iwmmxt_sllq, i64, i64, i32) +DEF_HELPER_2(iwmmxt_sraw, i64, i64, i32)
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On Sun, Apr 03, 2011 at 07:06:17PM +0100, Stefan Hajnoczi wrote:
On Sun, Apr 3, 2011 at 2:12 PM, Blue Swirl blauwir...@gmail.com wrote:
On Sun, Apr 3, 2011 at 2:57 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Mar 29, 2011 at 8:04 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
Piggy-back on the guest CD-ROM polling to poll on the host. Open and
close the host CD-ROM file descriptor to ensure we read the new size and
not a stale size.
Two things are going on here:
1. If hald/udisks is not already polling CD-ROMs on the host then
re-opening the CD-ROM causes the host to read the new medium's size.
2. There is a bug in Linux which means the CD-ROM file descriptor must
be re-opened in order for lseek(2) to see the new size. The
inode size gets out of sync with the underlying device (which you can
confirm by checking that /sys/block/sr0/size and lseek(2) do not
match after media change). I have raised this with the
maintainers but we need a workaround for the foreseeable future.
Note that these changes are all in a #ifdef __linux__ section.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block/raw-posix.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 6b72470..8b5205c 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1238,10 +1238,28 @@ static int cdrom_is_inserted(BlockDriverState *bs)
BDRVRawState *s = bs-opaque;
int ret;
- ret = ioctl(s-fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
- if (ret == CDS_DISC_OK)
- return 1;
- return 0;
+ /*
+ * Close the file descriptor if no medium is present and open it to
poll
+ * again. This ensures the medium size is refreshed. If the file
+ * descriptor is kept open the size can become stale. This is
essentially
+ * replicating CD-ROM polling but is driven by the guest. As the
guest
+ * polls, we poll the host.
+ */
+
+ if (s-fd == -1) {
+ s-fd = qemu_open(bs-filename, s-open_flags, 0644);
+ if (s-fd 0) {
+ return 0;
+ }
+ }
+
+ ret = (ioctl(s-fd, CDROM_DRIVE_STATUS, CDSL_CURRENT) ==
CDS_DISC_OK);
+
+ if (!ret) {
+ close(s-fd);
+ s-fd = -1;
+ }
+ return ret;
}
static int cdrom_eject(BlockDriverState *bs, int eject_flag)
--
1.7.4.1
There is an issue with reopening host devices in QEMU when running
under libvirt. It appears that libvirt chowns image files (including
device nodes) so that the launched QEMU process can access them.
Unfortunately after media change on host devices udev will reset the
ownership of the device node. This causes open(2) to fail with EACCES
since the QEMU process does not have the right uid/gid/groups and
libvirt is unaware that the file's ownership has changed.
In order for media change to work with Linux host CD-ROM it is
necessary to reopen the file (otherwise the inode size will not
refresh, this is an issue with existing kernels).
How can libvirt's security model be made to support this case? In
theory udev could be temporarily configured with libvirt permissions
for the CD-ROM device while passed through to the guest, but is that
feasible?
How about something like this: Add an explicit reopen method to
BlockDriver. Make a special block device for passed file descriptors.
Pass descriptors in libvirt for CD-ROMs instead of the device paths.
The reopen method for file descriptors should notify libvirt about
need to pass a reopened descriptor and then block all accesses until a
new descriptor is available. This should also solve your earlier
problem.
I'm hoping libvirt's behavior can be made to just work rather than
adding new features to QEMU. But perhaps passing file descriptors is
useful for more than just reopening host devices. This would
basically be a privilege separation model where the QEMU process isn't
able to open files itself but can request libvirt to open them on its
behalf.
It is rather frickin' annoying the way udev resets the ownership
when the media merely changes. If it isn't possible to stop udev
doing this, then i think the only practical thing is to use ACLs
instead of user/group ownership. We wanted to switch to ACLs in
libvirt for other reasons already, but it isn't quite as simple
as it sounds[1] so we've not done it just yet.
Daniel
[1] Mostly due to handling upgrades from existing libvirtd while
VMs are running, and coping with filesystems which don't
support ACLs (or have them turned of by mount options)
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
[Qemu-devel] [PATCH 2/4] target-arm: Use global env in neon_helper.c helpers
Use the global 'env' variable in the helper functions in neon_helper.c. This means we don't need to pass env as an argument to them any more. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- target-arm/helpers.h | 134 +- target-arm/neon_helper.c | 144 ++--- target-arm/translate.c | 119 +- 3 files changed, 191 insertions(+), 206 deletions(-) diff --git a/target-arm/helpers.h b/target-arm/helpers.h index 9de10e3..0705b9c 100644 --- a/target-arm/helpers.h +++ b/target-arm/helpers.h @@ -154,22 +154,22 @@ DEF_HELPER_2(sar_cc, i32, i32, i32) DEF_HELPER_2(ror_cc, i32, i32, i32) /* neon_helper.c */ -DEF_HELPER_3(neon_qadd_u8, i32, env, i32, i32) -DEF_HELPER_3(neon_qadd_s8, i32, env, i32, i32) -DEF_HELPER_3(neon_qadd_u16, i32, env, i32, i32) -DEF_HELPER_3(neon_qadd_s16, i32, env, i32, i32) -DEF_HELPER_3(neon_qadd_u32, i32, env, i32, i32) -DEF_HELPER_3(neon_qadd_s32, i32, env, i32, i32) -DEF_HELPER_3(neon_qsub_u8, i32, env, i32, i32) -DEF_HELPER_3(neon_qsub_s8, i32, env, i32, i32) -DEF_HELPER_3(neon_qsub_u16, i32, env, i32, i32) -DEF_HELPER_3(neon_qsub_s16, i32, env, i32, i32) -DEF_HELPER_3(neon_qsub_u32, i32, env, i32, i32) -DEF_HELPER_3(neon_qsub_s32, i32, env, i32, i32) -DEF_HELPER_3(neon_qadd_u64, i64, env, i64, i64) -DEF_HELPER_3(neon_qadd_s64, i64, env, i64, i64) -DEF_HELPER_3(neon_qsub_u64, i64, env, i64, i64) -DEF_HELPER_3(neon_qsub_s64, i64, env, i64, i64) +DEF_HELPER_2(neon_qadd_u8, i32, i32, i32) +DEF_HELPER_2(neon_qadd_s8, i32, i32, i32) +DEF_HELPER_2(neon_qadd_u16, i32, i32, i32) +DEF_HELPER_2(neon_qadd_s16, i32, i32, i32) +DEF_HELPER_2(neon_qadd_u32, i32, i32, i32) +DEF_HELPER_2(neon_qadd_s32, i32, i32, i32) +DEF_HELPER_2(neon_qsub_u8, i32, i32, i32) +DEF_HELPER_2(neon_qsub_s8, i32, i32, i32) +DEF_HELPER_2(neon_qsub_u16, i32, i32, i32) +DEF_HELPER_2(neon_qsub_s16, i32, i32, i32) +DEF_HELPER_2(neon_qsub_u32, i32, i32, i32) +DEF_HELPER_2(neon_qsub_s32, i32, i32, i32) +DEF_HELPER_2(neon_qadd_u64, i64, i64, i64) +DEF_HELPER_2(neon_qadd_s64, i64, i64, i64) +DEF_HELPER_2(neon_qsub_u64, i64, i64, i64) +DEF_HELPER_2(neon_qsub_s64, i64, i64, i64) DEF_HELPER_2(neon_hadd_s8, i32, i32, i32) DEF_HELPER_2(neon_hadd_u8, i32, i32, i32) @@ -247,26 +247,26 @@ DEF_HELPER_2(neon_rshl_u32, i32, i32, i32) DEF_HELPER_2(neon_rshl_s32, i32, i32, i32) DEF_HELPER_2(neon_rshl_u64, i64, i64, i64) DEF_HELPER_2(neon_rshl_s64, i64, i64, i64) -DEF_HELPER_3(neon_qshl_u8, i32, env, i32, i32) -DEF_HELPER_3(neon_qshl_s8, i32, env, i32, i32) -DEF_HELPER_3(neon_qshl_u16, i32, env, i32, i32) -DEF_HELPER_3(neon_qshl_s16, i32, env, i32, i32) -DEF_HELPER_3(neon_qshl_u32, i32, env, i32, i32) -DEF_HELPER_3(neon_qshl_s32, i32, env, i32, i32) -DEF_HELPER_3(neon_qshl_u64, i64, env, i64, i64) -DEF_HELPER_3(neon_qshl_s64, i64, env, i64, i64) -DEF_HELPER_3(neon_qshlu_s8, i32, env, i32, i32); -DEF_HELPER_3(neon_qshlu_s16, i32, env, i32, i32); -DEF_HELPER_3(neon_qshlu_s32, i32, env, i32, i32); -DEF_HELPER_3(neon_qshlu_s64, i64, env, i64, i64); -DEF_HELPER_3(neon_qrshl_u8, i32, env, i32, i32) -DEF_HELPER_3(neon_qrshl_s8, i32, env, i32, i32) -DEF_HELPER_3(neon_qrshl_u16, i32, env, i32, i32) -DEF_HELPER_3(neon_qrshl_s16, i32, env, i32, i32) -DEF_HELPER_3(neon_qrshl_u32, i32, env, i32, i32) -DEF_HELPER_3(neon_qrshl_s32, i32, env, i32, i32) -DEF_HELPER_3(neon_qrshl_u64, i64, env, i64, i64) -DEF_HELPER_3(neon_qrshl_s64, i64, env, i64, i64) +DEF_HELPER_2(neon_qshl_u8, i32, i32, i32) +DEF_HELPER_2(neon_qshl_s8, i32, i32, i32) +DEF_HELPER_2(neon_qshl_u16, i32, i32, i32) +DEF_HELPER_2(neon_qshl_s16, i32, i32, i32) +DEF_HELPER_2(neon_qshl_u32, i32, i32, i32) +DEF_HELPER_2(neon_qshl_s32, i32, i32, i32) +DEF_HELPER_2(neon_qshl_u64, i64, i64, i64) +DEF_HELPER_2(neon_qshl_s64, i64, i64, i64) +DEF_HELPER_2(neon_qshlu_s8, i32, i32, i32); +DEF_HELPER_2(neon_qshlu_s16, i32, i32, i32); +DEF_HELPER_2(neon_qshlu_s32, i32, i32, i32); +DEF_HELPER_2(neon_qshlu_s64, i64, i64, i64); +DEF_HELPER_2(neon_qrshl_u8, i32, i32, i32) +DEF_HELPER_2(neon_qrshl_s8, i32, i32, i32) +DEF_HELPER_2(neon_qrshl_u16, i32, i32, i32) +DEF_HELPER_2(neon_qrshl_s16, i32, i32, i32) +DEF_HELPER_2(neon_qrshl_u32, i32, i32, i32) +DEF_HELPER_2(neon_qrshl_s32, i32, i32, i32) +DEF_HELPER_2(neon_qrshl_u64, i64, i64, i64) +DEF_HELPER_2(neon_qrshl_s64, i64, i64, i64) DEF_HELPER_2(neon_add_u8, i32, i32, i32) DEF_HELPER_2(neon_add_u16, i32, i32, i32) @@ -295,22 +295,22 @@ DEF_HELPER_1(neon_cls_s16, i32, i32) DEF_HELPER_1(neon_cls_s32, i32, i32) DEF_HELPER_1(neon_cnt_u8, i32, i32) -DEF_HELPER_3(neon_qdmulh_s16, i32, env, i32, i32) -DEF_HELPER_3(neon_qrdmulh_s16, i32, env, i32, i32) -DEF_HELPER_3(neon_qdmulh_s32, i32, env, i32, i32) -DEF_HELPER_3(neon_qrdmulh_s32, i32, env, i32, i32) +DEF_HELPER_2(neon_qdmulh_s16, i32, i32, i32) +DEF_HELPER_2(neon_qrdmulh_s16, i32, i32, i32) +DEF_HELPER_2(neon_qdmulh_s32, i32, i32, i32) +DEF_HELPER_2(neon_qrdmulh_s32, i32, i32,
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
From: Lai Jiangshan la...@cn.fujitsu.com
Date: Mon, 7 Mar 2011 17:05:15 +0800
Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
inject-nmi command injects an NMI on all CPUs of guest.
It is only supported for x86 guest currently, it will
returns Unsupported error for non-x86 guest.
---
hmp-commands.hx |2 +-
monitor.c | 18 +-
qmp-commands.hx | 29 +
3 files changed, 47 insertions(+), 2 deletions(-)
Does anyone have any feedback on this addition, or are all new
QMP patch proposals blocked pending Anthony's QAPI work ?
We'd like to support it in libvirt and thus want it to be
available in QMP, as well as HMP.
@@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
break;
}
}
+
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env-next_cpu)
+cpu_interrupt(env, CPU_INTERRUPT_NMI);
+
+return 0;
+}
+#else
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+qerror_report(QERR_UNSUPPORTED);
+return -1;
+}
#endif
Interesting that with HMP you need to specify a single CPU index, but
with QMP it is injecting to all CPUs at once. Is there any compelling
reason why we'd ever need the ability to only inject to a single CPU
from an app developer POV ?
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] A question about qemu 0.9.1
On Mon, 4 Apr 2011 08:10:55 pm y y wrote: op_movl_A0_EAX() come from? I think its a pre-processor generated thing. So to find it, I think you need to find the parts (like INDEX_op in one pre- processor command, and the rest in another place), and how it is pasted together. HTH. Brad
[Qemu-devel] [PATCH] cpu-all.h: Remove unnecessary target-specific ifdef for CPU_QuadU
CPU_QuadU isn't used on all targets, but there's no harm in defining the
typedef anyway. It only needs to be guarded by CONFIG_SOFTFLOAT, because
softfloat-native doesn't have a float128 type. This avoids the need for
every new target which uses CPU_QuadU to add itself to an #ifdef in
what ought to be target-agnostic code.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Noticed this one as a result of the s390 support patches; seems like
a minor but worthwhile cleanup to me...
cpu-all.h |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 4cc445f..dc0f2f0 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -138,11 +138,10 @@ typedef union {
uint64_t ll;
} CPU_DoubleU;
-#if defined(TARGET_SPARC) || defined(TARGET_S390X)
+#if defined(CONFIG_SOFTFLOAT)
typedef union {
float128 q;
-#if defined(HOST_WORDS_BIGENDIAN) \
-|| (defined(__arm__) !defined(__VFP_FP__) !defined(CONFIG_SOFTFLOAT))
+#if defined(HOST_WORDS_BIGENDIAN)
struct {
uint32_t upmost;
uint32_t upper;
--
1.7.1
Re: [Qemu-devel] A question about qemu 0.9.1
2011/4/4 y y fenglei999...@gmail.com: I am learning qemu 0.9.1 The obvious question here is why are you looking at 0.9.1?; it is now extremely old... In particular it predates the switch to TCG so anything you learn about the codegen process is likely to be irrelevant to newer versions. -- PMM
Re: [Qemu-devel] [PATCH 1/3] arm: basic support for ARMv4/ARMv4T emulation
On 2 April 2011 16:25, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: On 3/31/11, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: Yeah, it seems so :) Please commit the fixed patch. Do I need to send the fixed patchset? I think that would probably be best. -- PMM
Re: [Qemu-devel] [PATCH] Register only one qbus_reset_all_fn() for system bus
On 4/3/11, Isaku Yamahata yamah...@valinux.co.jp wrote: On Sat, Apr 02, 2011 at 06:47:37PM +0400, Dmitry Eremin-Solenikov wrote: On 4/2/11, Isaku Yamahata yamah...@valinux.co.jp wrote: Have you verified that all bus devices have been qdevified since this code has been added? I wouldn't bet it is the case. I think his analysis is valid. So how about the following patch. Could you please point me to an example of devices for which this check is required. Although I don't have any example, I bet to not change the reset order. If you check all the devices, it's good. The question is which devices to check as lots of devices are already converted to qdev. Is it correct that we should check only devices which register a child bus with parent device set, and the thing that we should check is the fact that the parent reset function also causes the bus reset? -- With best wishes Dmitry
[Qemu-devel] [regression] configure: add opengl detection
Hello, commit 20ff075bb3340c5278a0da38ad1f4d602565aa06 Author: Michael Walle mich...@walle.cc Date: Mon Mar 7 23:32:39 2011 +0100 configure: add opengl detection This patch introduce a new config option CONFIG_OPENGL. Signed-off-by: Michael Walle mich...@walle.cc Signed-off-by: Edgar E. Iglesias edgar.igles...@gmail.com introduces a segfault for me with following backtrace: Starting program: /home/ben/local/src/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1G -net none -drive file=/home/ben/diskImages/debian_squeeze_amd64.qcow2,snapshot=on -nographic [Thread debugging using libthread_db enabled] [New Thread 0x7fff9ee07700 (LWP 19445)] Program received signal SIGUSR2, User defined signal 2. 0x75624ff3 in select () from /lib/libc.so.6 (gdb) info stack #0 0x75624ff3 in select () from /lib/libc.so.6 #1 0x0042edfa in qemu_aio_wait () at aio.c:193 #2 0x0042dd65 in bdrv_read_em (bs=0x11277c0, sector_num=0, buf=0x7fffd9d0 \353c\220\020\216м, nb_sectors=1) at block.c:2660 #3 0x0042b790 in guess_disk_lchs (bs=0x11277c0, pcylinders=0x7fffdc2c, pheads=0x7fffdc28, psectors=0x7fffdc24) at block.c:1203 #4 0x0042b90f in bdrv_guess_geometry (bs=0x11277c0, pcyls=0x7fffdc7c, pheads=0x7fffdc78, psecs=0x7fffdc74) at block.c:1250 #5 0x005707c1 in ide_init_drive (s=0x1c936f0, bs=0x11277c0, version=0x0, serial=0x0) at /home/ben/local/src/qemu/hw/ide/core.c:2522 #6 0x00573762 in ide_drive_initfn (dev=0x15afb20) at /home/ben/local/src/qemu/hw/ide/qdev.c:137 #7 0x00480328 in qdev_init (dev=0xa) at /home/ben/local/src/qemu/hw/qdev.c:281 #8 0x0048039a in qdev_init_nofail (dev=0xa) at /home/ben/local/src/qemu/hw/qdev.c:372 #9 0x005739fc in ide_create_drive (bus=value optimized out, unit=0, drive=0x1127720) at /home/ben/local/src/qemu/hw/ide/qdev.c:104 #10 0x00574206 in pci_ide_create_devs (dev=0x1c93410, hd_table=value optimized out) at /home/ben/local/src/qemu/hw/ide/pci.c:438 #11 0x0057489b in pci_piix3_ide_init (bus=value optimized out, hd_table=0x7fffdda0, devfn=value optimized out) at /home/ben/local/src/qemu/hw/ide/piix.c:177 #12 0x005aaf84 in pc_init1 (ram_size=value optimized out, boot_device=value optimized out, kernel_filename=value optimized out, kernel_cmdline=value optimized out, initrd_filename=0x18 Address 0x18 out of bounds, cpu_model=value optimized out, pci_enabled=1, kvmclock_enabled=1) at /home/ben/local/src/qemu/hw/pc_piix.c:143 #13 0x005ab208 in pc_init_pci (ram_size=10, boot_device=0x7fffd890 , kernel_filename=0x7fffd810 , kernel_cmdline=0x Address 0x out of bounds, initrd_filename=0x0, cpu_model=0x4bf2 Address 0x4bf2 out of bounds) at /home/ben/local/src/qemu/hw/pc_piix.c:199 #14 0x00546d8b in main (argc=value optimized out, argv=0x7fffe1a8, envp=value optimized out) at /home/ben/local/src/qemu/vl.c:3057 I configured with `./configure --target-list=x86_64-softmmu` and had following output: Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin config directory /usr/local/etc Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/ben/local/src/qemu C compilergcc Host C compiler gcc CFLAGS-O2 -g QEMU_CFLAGS -Werror -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits LDFLAGS -Wl,--warn-common -m64 -g make make install install host CPU x86_64 host big endian no target list x86_64-softmmu tcg debug enabled no Mon debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no -Werror enabled yes SDL support yes curses supportyes curl support yes check support no mingw32 support no Audio drivers oss Extra audio cards ac97 es1370 sb16 hda Block whitelist Mixer emulation no VNC support yes VNC TLS support yes VNC SASL support no VNC JPEG support yes VNC PNG support yes VNC threadno xen support no brlapi supportno bluez supportno Documentation yes NPTL support yes GUEST_BASEyes PIE user targets no vde support no IO thread no Linux AIO support yes ATTR/XATTR support yes Install blobs yes KVM support yes fdt support no preadv supportyes fdatasync yes madvise yes posix_madvise yes uuid support yes vhost-net support no Trace
[Qemu-devel] [PATCH 3/3] Basic implementation of Sharp Zaurus SL-5500 collie PDA
Add very basic implementation of collie PDA emulation. The system lacks
LoCoMo and graphics/sound emulation. Linux kernel boots up to mounting
rootfs (theoretically it can be provided in pflash images).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
Makefile.target |1 +
hw/collie.c | 70 +++
2 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 hw/collie.c
diff --git a/Makefile.target b/Makefile.target
index cd03cec..47fba98 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -353,6 +353,7 @@ obj-arm-y += syborg_serial.o syborg_timer.o
syborg_pointer.o syborg_rtc.o
obj-arm-y += syborg_virtio.o
obj-arm-y += vexpress.o
obj-arm-y += strongarm.o
+obj-arm-y += collie.o
obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/collie.c b/hw/collie.c
new file mode 100644
index 000..965fd13
--- /dev/null
+++ b/hw/collie.c
@@ -0,0 +1,70 @@
+/*
+ * SA-1110-based Sharp Zaurus SL-5500 platform.
+ *
+ * Copyright (C) 2011 Dmitry Eremin-Solenikov
+ *
+ * This code is licensed under GNU GPL v2.
+ */
+#include hw.h
+#include sysbus.h
+#include boards.h
+#include devices.h
+#include strongarm.h
+#include arm-misc.h
+#include flash.h
+#include blockdev.h
+
+static struct arm_boot_info collie_binfo = {
+.loader_start = SA_SDCS0,
+.ram_size = 0x2000,
+};
+
+static void collie_init(ram_addr_t ram_size,
+const char *boot_device,
+const char *kernel_filename, const char *kernel_cmdline,
+const char *initrd_filename, const char *cpu_model)
+{
+StrongARMState *s;
+DriveInfo *dinfo;
+ram_addr_t phys_flash;
+
+if (!cpu_model) {
+cpu_model = sa1110;
+}
+
+s = sa1110_init(collie_binfo.ram_size, cpu_model);
+(void) s;
+
+phys_flash = qemu_ram_alloc(NULL, collie.fl1, 0x0200);
+dinfo = drive_get(IF_PFLASH, 0, 0);
+pflash_cfi01_register(SA_CS0, phys_flash,
+dinfo ? dinfo-bdrv : NULL, (64 * 1024),
+512, 4, 0x00, 0x00, 0x00, 0x00, 0);
+
+phys_flash = qemu_ram_alloc(NULL, collie.fl2, 0x0200);
+dinfo = drive_get(IF_PFLASH, 0, 1);
+pflash_cfi01_register(SA_CS1, phys_flash,
+dinfo ? dinfo-bdrv : NULL, (64 * 1024),
+512, 4, 0x00, 0x00, 0x00, 0x00, 0);
+
+sysbus_create_simple(scoop, 0x4080, NULL);
+
+collie_binfo.kernel_filename = kernel_filename;
+collie_binfo.kernel_cmdline = kernel_cmdline;
+collie_binfo.initrd_filename = initrd_filename;
+collie_binfo.board_id = 0x208;
+arm_load_kernel(s-env, collie_binfo);
+}
+
+static QEMUMachine collie_machine = {
+.name = collie,
+.desc = Collie PDA (SA-1110),
+.init = collie_init,
+};
+
+static void collie_machine_init(void)
+{
+qemu_register_machine(collie_machine);
+}
+
+machine_init(collie_machine_init)
--
1.7.4.1
[Qemu-devel] [PATCH 2/3] Implement basic part of SA-1110/SA-1100
Basic implementation of DEC/Intel SA-1100/SA-1110 chips emulation.
Implemented:
- IRQs
- GPIO
- PPC
- RTC
- UARTs (no IrDA/etc.)
- OST reused from pxa25x
Everything else is TODO (esp. PM/idle/sleep!) - see the todo in the
hw/strongarm.c
V2:
* removed all strongarm variants except latest
* dropped unused casts
* fixed PIC vmstate
* fixed new devices created with version_id = 1
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
Makefile.target |1 +
hw/strongarm.c | 1301 +++
hw/strongarm.h | 62 +++
target-arm/cpu.h|3 +
target-arm/helper.c |9 +
5 files changed, 1376 insertions(+), 0 deletions(-)
create mode 100644 hw/strongarm.c
create mode 100644 hw/strongarm.h
diff --git a/Makefile.target b/Makefile.target
index 2f76714..cd03cec 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -352,6 +352,7 @@ obj-arm-y += syborg.o syborg_fb.o syborg_interrupt.o
syborg_keyboard.o
obj-arm-y += syborg_serial.o syborg_timer.o syborg_pointer.o syborg_rtc.o
obj-arm-y += syborg_virtio.o
obj-arm-y += vexpress.o
+obj-arm-y += strongarm.o
obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/strongarm.c b/hw/strongarm.c
new file mode 100644
index 000..9f3df87
--- /dev/null
+++ b/hw/strongarm.c
@@ -0,0 +1,1301 @@
+/*
+ * StrongARM SA-1100/SA-1110 emulation
+ *
+ * Copyright (C) 2011 Dmitry Eremin-Solenikov
+ *
+ * Largely based on StrongARM emulation:
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski bal...@zabor.org
+ *
+ * UART code based on QEMU 16550A UART emulation
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2008 Citrix Systems, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ */
+#include sysbus.h
+#include strongarm.h
+#include qemu-error.h
+#include arm-misc.h
+#include sysemu.h
+
+/*
+ TODO
+ - Implement cp15, c14 ?
+ - Implement cp15, c15 !!! (idle used in L)
+ - Implement idle mode handling/DIM
+ - Implement sleep mode/Wake sources
+ - Implement reset control
+ - Implement memory control regs
+ - PCMCIA handling
+ - Maybe support MBGNT/MBREQ
+ - DMA channels
+ - GPCLK
+ - IrDA
+ - MCP
+ - Enhance UART with modem signals
+ */
+
+static struct {
+target_phys_addr_t io_base;
+int irq;
+} sa_serial[] = {
+{ 0x8001, SA_PIC_UART1 },
+{ 0x8003, SA_PIC_UART2 },
+{ 0x8005, SA_PIC_UART3 },
+{ 0, 0 }
+};
+
+/* Interrupt Controller */
+typedef struct {
+SysBusDevice busdev;
+qemu_irqirq;
+qemu_irqfiq;
+
+uint32_t pending;
+uint32_t enabled;
+uint32_t is_fiq;
+uint32_t int_idle;
+} StrongARMPICState;
+
+#define ICIP0x00
+#define ICMR0x04
+#define ICLR0x08
+#define ICFP0x10
+#define ICPR0x20
+#define ICCR0x0c
+
+#define SA_PIC_SRCS 32
+
+
+static void strongarm_pic_update(void *opaque)
+{
+StrongARMPICState *s = opaque;
+
+/* FIXME: reflect DIM */
+qemu_set_irq(s-fiq, s-pending s-enabled s-is_fiq);
+qemu_set_irq(s-irq, s-pending s-enabled ~s-is_fiq);
+}
+
+static void strongarm_pic_set_irq(void *opaque, int irq, int level)
+{
+StrongARMPICState *s = opaque;
+
+if (level) {
+s-pending |= 1 irq;
+} else {
+s-pending = ~(1 irq);
+}
+
+strongarm_pic_update(s);
+}
+
+static uint32_t strongarm_pic_mem_read(void *opaque, target_phys_addr_t offset)
+{
+StrongARMPICState *s = opaque;
+
+switch (offset) {
+case ICIP:
+return s-pending ~s-is_fiq s-enabled;
+case ICMR:
+return s-enabled;
+case ICLR:
+return s-is_fiq;
+case ICCR:
+return s-int_idle == 0;
+case ICFP:
+return s-pending s-is_fiq s-enabled;
+case ICPR:
+return s-pending;
+default:
+printf(%s: Bad register offset 0x TARGET_FMT_plx \n,
+__func__, offset);
+return 0;
+}
+}
+
+static void strongarm_pic_mem_write(void *opaque, target_phys_addr_t offset,
+uint32_t value)
+{
+StrongARMPICState *s = opaque;
+
+switch (offset) {
+case ICMR:
+s-enabled = value;
+break;
+case ICLR:
+s-is_fiq = value;
+break;
+case ICCR:
+s-int_idle = (value 1) ? 0 : ~0;
+break;
+default:
+printf(%s: Bad register offset 0x TARGET_FMT_plx \n,
+__func__, offset);
+break;
+}
+strongarm_pic_update(s);
+}
+
+static CPUReadMemoryFunc * const strongarm_pic_readfn[] = {
+strongarm_pic_mem_read,
+strongarm_pic_mem_read,
+strongarm_pic_mem_read,
+};
+
+static CPUWriteMemoryFunc * const strongarm_pic_writefn[] = {
+strongarm_pic_mem_write,
+strongarm_pic_mem_write,
+strongarm_pic_mem_write,
+};
+
+static int
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
[Note cc: Anthony]
Daniel P. Berrange berra...@redhat.com writes:
On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
From: Lai Jiangshan la...@cn.fujitsu.com
Date: Mon, 7 Mar 2011 17:05:15 +0800
Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
inject-nmi command injects an NMI on all CPUs of guest.
It is only supported for x86 guest currently, it will
returns Unsupported error for non-x86 guest.
---
hmp-commands.hx |2 +-
monitor.c | 18 +-
qmp-commands.hx | 29 +
3 files changed, 47 insertions(+), 2 deletions(-)
Does anyone have any feedback on this addition, or are all new
QMP patch proposals blocked pending Anthony's QAPI work ?
That would be bad. Anthony, what's holding this back?
We'd like to support it in libvirt and thus want it to be
available in QMP, as well as HMP.
@@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
break;
}
}
+
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env-next_cpu)
+cpu_interrupt(env, CPU_INTERRUPT_NMI);
+
+return 0;
+}
+#else
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+qerror_report(QERR_UNSUPPORTED);
+return -1;
+}
#endif
Interesting that with HMP you need to specify a single CPU index, but
with QMP it is injecting to all CPUs at once. Is there any compelling
reason why we'd ever need the ability to only inject to a single CPU
from an app developer POV ?
Quoting my own executive summary on this issue:
* Real hardware's NMI button injects all CPUs. This is the primary use
case.
* Lai said injecting a single CPU can be useful for debugging. Was
deemed acceptable as secondary use case.
Lai also pointed out that the human monitor's nmi command injects a
single CPU. That was dismissed as irrelevant for QMP.
* No other use cases have been presented.
[Qemu-devel] [PATCH 1/3] arm: basic support for ARMv4/ARMv4T emulation
Currently target-arm/ assumes at least ARMv5 core. Add support for
handling also ARMv4/ARMv4T. This changes the following instructions:
BX(v4T and later)
BKPT, BLX, CDP2, CLZ, LDC2, LDRD, MCRR, MCRR2, MRRC, MCRR, MRC2, MRRC,
MRRC2, PLD QADD, QDADD, QDSUB, QSUB, STRD, SMLAxy, SMLALxy, SMLAWxy,
SMULxy, SMULWxy, STC2 (v5 and later)
All instructions that are v5TE and later are also bound to just v5, as
that's how it was before.
This patch doesn _not_ include disabling of cp15 access and base-updated
data abort model (that will be required to emulate chips based on a
ARM7TDMI), because:
* no ARM7TDMI chips are currently emulated (or planned)
* those features aren't strictly necessary for my purposes (SA-1 core
emulation).
All v5 models are handled as they are v5T. Internally we still have a
check if the model is a v5(T) or v5TE, but as all emulated cores are
v5TE, those two cases are simply aliased (for now).
Patch is heavily based on patch by Filip Navara filip.nav...@gmail.com
which in turn is based on work by Ulrich Hecht u...@suse.de and Vincent
Sanders vi...@kyllikki.org.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
target-arm/cpu.h |4 ++-
target-arm/helper.c| 28 ++-
target-arm/translate.c | 59 +++
3 files changed, 79 insertions(+), 12 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 1ae7982..e247a7a 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -360,7 +360,9 @@ enum arm_features {
ARM_FEATURE_M, /* Microcontroller profile. */
ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */
ARM_FEATURE_THUMB2EE,
-ARM_FEATURE_V7MP/* v7 Multiprocessing Extensions */
+ARM_FEATURE_V7MP,/* v7 Multiprocessing Extensions */
+ARM_FEATURE_V4T,
+ARM_FEATURE_V5,
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 6788a4c..4c0b4a2 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -48,17 +48,23 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c0_cpuid = id;
switch (id) {
case ARM_CPUID_ARM926:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_VFP);
env-vfp.xregs[ARM_VFP_FPSID] = 0x41011090;
env-cp15.c0_cachetype = 0x1dd20d2;
env-cp15.c1_sys = 0x00090078;
break;
case ARM_CPUID_ARM946:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_MPU);
env-cp15.c0_cachetype = 0x0f004006;
env-cp15.c1_sys = 0x0078;
break;
case ARM_CPUID_ARM1026:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_VFP);
set_feature(env, ARM_FEATURE_AUXCR);
env-vfp.xregs[ARM_VFP_FPSID] = 0x410110a0;
@@ -67,6 +73,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
break;
case ARM_CPUID_ARM1136_R2:
case ARM_CPUID_ARM1136:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_VFP);
set_feature(env, ARM_FEATURE_AUXCR);
@@ -79,6 +87,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
env-cp15.c1_sys = 0x00050078;
break;
case ARM_CPUID_ARM11MPCORE:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_V6K);
set_feature(env, ARM_FEATURE_VFP);
@@ -91,6 +101,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
env-cp15.c0_cachetype = 0x1dd20d2;
break;
case ARM_CPUID_CORTEXA8:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_V6K);
set_feature(env, ARM_FEATURE_V7);
@@ -113,6 +125,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c1_sys = 0x00c50078;
break;
case ARM_CPUID_CORTEXA9:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_V6K);
set_feature(env, ARM_FEATURE_V7);
@@ -140,6 +154,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c1_sys = 0x00c50078;
break;
case ARM_CPUID_CORTEXM3:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_THUMB2);
set_feature(env, ARM_FEATURE_V7);
@@ -147,6 +163,8 @@ static void
Re: [Qemu-devel] [PATCH 3/3] Basic implementation of Sharp Zaurus SL-5500 collie PDA
On 4 April 2011 13:15, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: + s = sa1110_init(collie_binfo.ram_size, cpu_model); + (void) s; Is this (void) s needed now, or is it a leftover from before code to use s later in the function was added, maybe? -- PMM
Re: [Qemu-devel] [PATCH] Fix build error in usb-ccid code
On 4 April 2011 13:31, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: W/o this fix I'm getting the following error: cc1: warnings being treated as errors hw/usb-ccid.c: In function ‘ccid_card_card_error’: hw/usb-ccid.c:1202:5: error: format ‘%lX’ expects type ‘long unsigned int’, but argument 2 has type ‘uint64_t’ David Gibson posted a patch for that earlier this morning: http://patchwork.ozlabs.org/patch/89577/ -- PMM
Re: [Qemu-devel] [PATCH] Fix non-portable format string in usb-ccid.c
On Mon, Apr 04, 2011 at 02:48:08PM +1000, David Gibson wrote: At one point, usb-ccid.c attempts to use a %lX format specifier to print a uint64_t, which is only correct on some host platforms. This patch corrects the statement to use the stdint specified PRIX64 constant instead. Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- hw/usb-ccid.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied. diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c index 723b2e3..44156cc 100644 --- a/hw/usb-ccid.c +++ b/hw/usb-ccid.c @@ -1199,7 +1199,7 @@ void ccid_card_card_error(CCIDCardState *card, uint64_t error) s-bmCommandStatus = COMMAND_STATUS_FAILED; s-last_answer_error = error; -DPRINTF(s, 1, VSC_Error: %lX\n, s-last_answer_error); +DPRINTF(s, 1, VSC_Error: % PRIX64 \n, s-last_answer_error); /* TODO: these error's should be more verbose and propogated to the guest.*/ /* * We flush all pending answers on CardRemove message in ccid-card-passthru, -- 1.7.1 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 04/04/2011 01:59 PM, Daniel P. Berrange wrote: Interesting that with HMP you need to specify a single CPU index, but with QMP it is injecting to all CPUs at once. Is there any compelling reason why we'd ever need the ability to only inject to a single CPU from an app developer POV ? When a PC has an NMI button, it is (I presume) connected to all CPUs' LINT1 pin, which is often configured as an NMI input. So the all-cpu variant corresponds to real hardware, while the single-cpu variant doesn't. wrt the app developer POV, the only use I'm aware of is that you can configure Windows to dump core when the NMI button is pressed and thus debug driver problems. It's likely more reliable when sent to all cpus. -- error compiling committee.c: too many arguments to function
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On Mon, Apr 4, 2011 at 11:47 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Sun, Apr 03, 2011 at 07:06:17PM +0100, Stefan Hajnoczi wrote:
On Sun, Apr 3, 2011 at 2:12 PM, Blue Swirl blauwir...@gmail.com wrote:
On Sun, Apr 3, 2011 at 2:57 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Mar 29, 2011 at 8:04 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
Piggy-back on the guest CD-ROM polling to poll on the host. Open and
close the host CD-ROM file descriptor to ensure we read the new size and
not a stale size.
Two things are going on here:
1. If hald/udisks is not already polling CD-ROMs on the host then
re-opening the CD-ROM causes the host to read the new medium's size.
2. There is a bug in Linux which means the CD-ROM file descriptor must
be re-opened in order for lseek(2) to see the new size. The
inode size gets out of sync with the underlying device (which you can
confirm by checking that /sys/block/sr0/size and lseek(2) do not
match after media change). I have raised this with the
maintainers but we need a workaround for the foreseeable future.
Note that these changes are all in a #ifdef __linux__ section.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block/raw-posix.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 6b72470..8b5205c 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1238,10 +1238,28 @@ static int cdrom_is_inserted(BlockDriverState
*bs)
BDRVRawState *s = bs-opaque;
int ret;
- ret = ioctl(s-fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
- if (ret == CDS_DISC_OK)
- return 1;
- return 0;
+ /*
+ * Close the file descriptor if no medium is present and open it to
poll
+ * again. This ensures the medium size is refreshed. If the file
+ * descriptor is kept open the size can become stale. This is
essentially
+ * replicating CD-ROM polling but is driven by the guest. As the
guest
+ * polls, we poll the host.
+ */
+
+ if (s-fd == -1) {
+ s-fd = qemu_open(bs-filename, s-open_flags, 0644);
+ if (s-fd 0) {
+ return 0;
+ }
+ }
+
+ ret = (ioctl(s-fd, CDROM_DRIVE_STATUS, CDSL_CURRENT) ==
CDS_DISC_OK);
+
+ if (!ret) {
+ close(s-fd);
+ s-fd = -1;
+ }
+ return ret;
}
static int cdrom_eject(BlockDriverState *bs, int eject_flag)
--
1.7.4.1
There is an issue with reopening host devices in QEMU when running
under libvirt. It appears that libvirt chowns image files (including
device nodes) so that the launched QEMU process can access them.
Unfortunately after media change on host devices udev will reset the
ownership of the device node. This causes open(2) to fail with EACCES
since the QEMU process does not have the right uid/gid/groups and
libvirt is unaware that the file's ownership has changed.
In order for media change to work with Linux host CD-ROM it is
necessary to reopen the file (otherwise the inode size will not
refresh, this is an issue with existing kernels).
How can libvirt's security model be made to support this case? In
theory udev could be temporarily configured with libvirt permissions
for the CD-ROM device while passed through to the guest, but is that
feasible?
How about something like this: Add an explicit reopen method to
BlockDriver. Make a special block device for passed file descriptors.
Pass descriptors in libvirt for CD-ROMs instead of the device paths.
The reopen method for file descriptors should notify libvirt about
need to pass a reopened descriptor and then block all accesses until a
new descriptor is available. This should also solve your earlier
problem.
I'm hoping libvirt's behavior can be made to just work rather than
adding new features to QEMU. But perhaps passing file descriptors is
useful for more than just reopening host devices. This would
basically be a privilege separation model where the QEMU process isn't
able to open files itself but can request libvirt to open them on its
behalf.
It is rather frickin' annoying the way udev resets the ownership
when the media merely changes. If it isn't possible to stop udev
doing this, then i think the only practical thing is to use ACLs
instead of user/group ownership. We wanted to switch to ACLs in
libvirt for other reasons already, but it isn't quite as simple
as it sounds[1] so we've not done it just yet.
Daniel
[1] Mostly due to handling upgrades from existing libvirtd while
VMs are running, and coping with filesystems which don't
support ACLs (or have them turned of by mount options)
I haven't peeked at how udev does it but perhaps the ACLs will be lost
or reset across media change too?
Daniel, do you know someone from the
Re: [Qemu-devel] Help Debugging AIX boot on qemu-system-ppc (it reads bootfile.exe now)
Out of curiosity, what command line did you use for this? On Sat, 2011-04-02 at 20:09 -0700, Kenneth Salerno wrote: Hi, I have been using QEMU for a few years and periodically tested AIX V6.1 with qemu-system-ppc and read the various threads in the mailing list knowing not to expect it to work just yet. However, with OpenBIOS v1.0 I was surprised to find how far it gets now. Please see below and I would appreciate any advice on how to debug further: = OpenBIOS 1.0 [Jan 30 2011 08:46] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 2047M UUID: 17202d0a-45f8-4159-a8e1-78b866f50aa7 CPU type PowerPC,750 Welcome to OpenBIOS v1.0 built on Jan 30 2011 08:46 Trying cd:,\\:tbxi... Trying cd:,\ppc\bootinfo.txt... --- Welcome to AIX. boot image timestamp: 00:39 35/2D The current time and date: 23:00:50 04/02/2011 processor count: 1; memory size: 2047MB; kernel size: 2293829 boot device: cd:\ppc\chrp\bootfile.exe qemu info cpus * CPU #0: nip=0xfff0fcdc thread_id=2527 info registers NIP fff0fcec LR fff0fcc4 CTR fff11558 XER 2000 MSR 3032 HID0 HF 2000 idx 1 TB 1542797983 DECR 2752169338 GPR00 7fb9f0d0 7fcf7790 7fba29e4 GPR04 fffb403c 00044200 fff02464 00044200 GPR08 7fba29e4 000c 0820 GPR12 88ac fff305f5 fff30dac GPR16 fff2f14e 0400 fffb36c4 fffb3ec4 GPR20 30ec fff2ef4a fff2ef38 fff2eeb8 GPR24 fff2ef40 fffb3628 00044204 fff8 GPR28 0036 fffb fffb 7fb9f0d8 CR 4884 [ G L - - - - L G ] RES FPR00 FPR04 FPR08 FPR12 FPR16 FPR20 FPR24 FPR28 FPSCR SRR0 42c0 SRR1 3032 SDR1 7fd0 x/20i $pc-10 0xfff0fcd2: fnmadd. f31,f24,f4,f18 0xfff0fcd6: .long 0xfff84800 0xfff0fcda: .long 0x87d23 0xfff0fcde: bla 0xff788120 0xfff0fce2: .long 0x2f89 0xfff0fce6: .long 0x419e 0xfff0fcea: .long 0x148149 0xfff0fcee: .long 0x4817f 0xfff0fcf2: .long 0xfffc7f8a 0xfff0fcf6: rlmir0,r2,r8,6,14 0xfff0fcfa: fnmadd. f31,f4,f4,f18 0xfff0fcfe: .long 0xfff89003 0xfff0fd02: .long 0x3961 0xfff0fd06: .long 0x104801 0xfff0fd0a: ori r24,r11,37921 0xfff0fd0e: .long 0xffe07c08 0xfff0fd12: .long 0x2a6bfa1 0xfff0fd16: .long 0x147c7e 0xfff0fd1a: .long 0x1b799001 0xfff0fd1e: .long 0x247c9d last entry from out_asm: OUT: [size=256] 0x4157ae90: mov0x100(%r14),%ebp 0x4157ae97: mov0x4(%r14),%ebx 0x4157ae9b: lea-0x10(%rbx),%r12d 0x4157ae9f: mov%ebp,(%r14) 0x4157aea2: mov$0x20,%ebp 0x4157aea7: mov%ebp,0x260(%r14) 0x4157aeae: mov%r12d,%esi 0x4157aeb1: mov%r12d,%edi 0x4157aeb4: shr$0x7,%esi 0x4157aeb7: and$0xf003,%edi 0x4157aebd: and$0x1fe0,%esi 0x4157aec3: lea0x228c(%r14,%rsi,1),%rsi 0x4157aecb: cmp(%rsi),%edi 0x4157aecd: mov%r12d,%edi 0x4157aed0: jne0x4157aede 0x4157aed2: add0xc(%rsi),%rdi 0x4157aed6: mov%ebx,%esi 0x4157aed8: bswap %esi 0x4157aeda: mov%esi,(%rdi) 0x4157aedc: jmp0x4157aeea 0x4157aede: mov%ebx,%esi 0x4157aee0: mov$0x1,%edx 0x4157aee5: callq 0x57f0f5 0x4157aeea: lea0x14(%r12),%ebp 0x4157aeef: mov(%r14),%ebx 0x4157aef2: mov%r12d,0x4(%r14) 0x4157aef6: mov%ebp,%esi 0x4157aef8: mov%ebp,%edi 0x4157aefa: shr$0x7,%esi 0x4157aefd: and$0xf003,%edi 0x4157af03: and$0x1fe0,%esi 0x4157af09: lea0x228c(%r14,%rsi,1),%rsi 0x4157af11: cmp(%rsi),%edi 0x4157af13: mov%ebp,%edi 0x4157af15: jne0x4157af23 0x4157af17: add0xc(%rsi),%rdi 0x4157af1b: mov%ebx,%esi 0x4157af1d: bswap %esi 0x4157af1f: mov%esi,(%rdi) 0x4157af21: jmp0x4157af2f 0x4157af23: mov%ebx,%esi 0x4157af25: mov$0x1,%edx 0x4157af2a: callq 0x57f0f5 0x4157af2f: mov0xc(%r14),%ebp 0x4157af33: lea0x18(%rbp),%ebx 0x4157af36: mov%ebx,%esi 0x4157af38:
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Mon, 04 Apr 2011 14:19:58 +0200
Markus Armbruster arm...@redhat.com wrote:
[Note cc: Anthony]
Daniel P. Berrange berra...@redhat.com writes:
On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
From: Lai Jiangshan la...@cn.fujitsu.com
Date: Mon, 7 Mar 2011 17:05:15 +0800
Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
inject-nmi command injects an NMI on all CPUs of guest.
It is only supported for x86 guest currently, it will
returns Unsupported error for non-x86 guest.
---
hmp-commands.hx |2 +-
monitor.c | 18 +-
qmp-commands.hx | 29 +
3 files changed, 47 insertions(+), 2 deletions(-)
Does anyone have any feedback on this addition, or are all new
QMP patch proposals blocked pending Anthony's QAPI work ?
No, we agreed on merging stuff against current QMP.
That would be bad. Anthony, what's holding this back?
I remember Anthony asked for errors descriptions.
We'd like to support it in libvirt and thus want it to be
available in QMP, as well as HMP.
@@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
break;
}
}
+
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env-next_cpu)
+cpu_interrupt(env, CPU_INTERRUPT_NMI);
+
+return 0;
+}
+#else
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+qerror_report(QERR_UNSUPPORTED);
+return -1;
+}
#endif
Interesting that with HMP you need to specify a single CPU index, but
with QMP it is injecting to all CPUs at once. Is there any compelling
reason why we'd ever need the ability to only inject to a single CPU
from an app developer POV ?
Quoting my own executive summary on this issue:
* Real hardware's NMI button injects all CPUs. This is the primary use
case.
* Lai said injecting a single CPU can be useful for debugging. Was
deemed acceptable as secondary use case.
Lai also pointed out that the human monitor's nmi command injects a
single CPU. That was dismissed as irrelevant for QMP.
* No other use cases have been presented.
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 04/04/2011 07:54 AM, Avi Kivity wrote: On 04/04/2011 01:59 PM, Daniel P. Berrange wrote: Interesting that with HMP you need to specify a single CPU index, but with QMP it is injecting to all CPUs at once. Is there any compelling reason why we'd ever need the ability to only inject to a single CPU from an app developer POV ? When a PC has an NMI button, it is (I presume) connected to all CPUs' LINT1 pin, which is often configured as an NMI input. So the all-cpu variant corresponds to real hardware, while the single-cpu variant doesn't. wrt the app developer POV, the only use I'm aware of is that you can configure Windows to dump core when the NMI button is pressed and thus debug driver problems. It's likely more reliable when sent to all cpus. It either needs to be removed from HMP or added to QMP. HMP shouldn't have more features than QMP (even if those features are non-sensible). Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On 04/04/2011 07:19 AM, Markus Armbruster wrote: [Note cc: Anthony] Daniel P. Berrangeberra...@redhat.com writes: On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote: From: Lai Jiangshanla...@cn.fujitsu.com Date: Mon, 7 Mar 2011 17:05:15 +0800 Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command inject-nmi command injects an NMI on all CPUs of guest. It is only supported for x86 guest currently, it will returns Unsupported error for non-x86 guest. --- hmp-commands.hx |2 +- monitor.c | 18 +- qmp-commands.hx | 29 + 3 files changed, 47 insertions(+), 2 deletions(-) Does anyone have any feedback on this addition, or are all new QMP patch proposals blocked pending Anthony's QAPI work ? That would be bad. Anthony, what's holding this back? It doesn't pass checkpath.pl. But I'd also expect this to come through Luiz's QMP tree. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Fix build error in usb-ccid code
On 4/4/11, Peter Maydell peter.mayd...@linaro.org wrote: On 4 April 2011 13:31, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: W/o this fix I'm getting the following error: cc1: warnings being treated as errors hw/usb-ccid.c: In function ‘ccid_card_card_error’: hw/usb-ccid.c:1202:5: error: format ‘%lX’ expects type ‘long unsigned int’, but argument 2 has type ‘uint64_t’ David Gibson posted a patch for that earlier this morning: http://patchwork.ozlabs.org/patch/89577/ Sorry for the noise then. -- With best wishes Dmitry
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/2011 05:47 AM, Daniel P. Berrange wrote: I'm hoping libvirt's behavior can be made to just work rather than adding new features to QEMU. But perhaps passing file descriptors is useful for more than just reopening host devices. This would basically be a privilege separation model where the QEMU process isn't able to open files itself but can request libvirt to open them on its behalf. It is rather frickin' annoying the way udev resets the ownership when the media merely changes. If it isn't possible to stop udev doing this, then i think the only practical thing is to use ACLs instead of user/group ownership. We wanted to switch to ACLs in libvirt for other reasons already, but it isn't quite as simple as it sounds[1] so we've not done it just yet. Isn't the root of the problem that you're not running a guest in the expected security context? How much of a leap would it be to spawn a guest with the credentials of the user that created/defined it? Or better yet, to let the user be specified in the XML. Regards, Anthony Liguori Daniel [1] Mostly due to handling upgrades from existing libvirtd while VMs are running, and coping with filesystems which don't support ACLs (or have them turned of by mount options)
Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote: In order for media change to work with Linux host CD-ROM it is necessary to reopen the file (otherwise the inode size will not refresh, this is an issue with existing kernels). Maybe we should fix the bug in Linux (and backport as necessary)? I think cd-rom assignment is sufficiently obscure that we can require a fixed kernel instead of providing a workaround. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 3/3] Basic implementation of Sharp Zaurus SL-5500 collie PDA
On 4/4/11, Peter Maydell peter.mayd...@linaro.org wrote: On 4 April 2011 13:15, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: +s = sa1110_init(collie_binfo.ram_size, cpu_model); +(void) s; Is this (void) s needed now, or is it a leftover from before code to use s later in the function was added, maybe? ATM it's just a leftover (unnecessary now). -- With best wishes Dmitry
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
On Mon, 04 Apr 2011 08:09:29 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 04/04/2011 07:19 AM, Markus Armbruster wrote: [Note cc: Anthony] Daniel P. Berrangeberra...@redhat.com writes: On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote: From: Lai Jiangshanla...@cn.fujitsu.com Date: Mon, 7 Mar 2011 17:05:15 +0800 Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command inject-nmi command injects an NMI on all CPUs of guest. It is only supported for x86 guest currently, it will returns Unsupported error for non-x86 guest. --- hmp-commands.hx |2 +- monitor.c | 18 +- qmp-commands.hx | 29 + 3 files changed, 47 insertions(+), 2 deletions(-) Does anyone have any feedback on this addition, or are all new QMP patch proposals blocked pending Anthony's QAPI work ? That would be bad. Anthony, what's holding this back? It doesn't pass checkpath.pl. But I'd also expect this to come through Luiz's QMP tree. I had this ready in my tree some time ago, but you commented on that version asking for errors descriptions and other things, so I didn't push it. But we have to set expectations here. My tree will eventually die, specially wrt new interfaces where I expect you to jump in ASAP. First because you have to be sure a new interface conforms to QAPI, and second (and more importantly) because it's time to pass this on to someone else (preferably you).
[Qemu-devel] [PATCH 0/3] StrongARM/collie support
Please find the next iteration of the patches. Changes since previous release are: fix for VMStateDescription of strongarm_uart, fixed RTSR reg. offset and added emulation of strongarm SSP port. Also unused (void) s; statement was dropped from hw/collie.c
[Qemu-devel] [PATCH 1/3] arm: basic support for ARMv4/ARMv4T emulation
Currently target-arm/ assumes at least ARMv5 core. Add support for
handling also ARMv4/ARMv4T. This changes the following instructions:
BX(v4T and later)
BKPT, BLX, CDP2, CLZ, LDC2, LDRD, MCRR, MCRR2, MRRC, MCRR, MRC2, MRRC,
MRRC2, PLD QADD, QDADD, QDSUB, QSUB, STRD, SMLAxy, SMLALxy, SMLAWxy,
SMULxy, SMULWxy, STC2 (v5 and later)
All instructions that are v5TE and later are also bound to just v5, as
that's how it was before.
This patch doesn _not_ include disabling of cp15 access and base-updated
data abort model (that will be required to emulate chips based on a
ARM7TDMI), because:
* no ARM7TDMI chips are currently emulated (or planned)
* those features aren't strictly necessary for my purposes (SA-1 core
emulation).
All v5 models are handled as they are v5T. Internally we still have a
check if the model is a v5(T) or v5TE, but as all emulated cores are
v5TE, those two cases are simply aliased (for now).
Patch is heavily based on patch by Filip Navara filip.nav...@gmail.com
which in turn is based on work by Ulrich Hecht u...@suse.de and Vincent
Sanders vi...@kyllikki.org.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
target-arm/cpu.h |4 ++-
target-arm/helper.c| 29 ++-
target-arm/translate.c | 59 +++
3 files changed, 80 insertions(+), 12 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 1ae7982..e247a7a 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -360,7 +360,9 @@ enum arm_features {
ARM_FEATURE_M, /* Microcontroller profile. */
ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */
ARM_FEATURE_THUMB2EE,
-ARM_FEATURE_V7MP/* v7 Multiprocessing Extensions */
+ARM_FEATURE_V7MP,/* v7 Multiprocessing Extensions */
+ARM_FEATURE_V4T,
+ARM_FEATURE_V5,
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 6788a4c..ce9a9d8 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -48,17 +48,23 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c0_cpuid = id;
switch (id) {
case ARM_CPUID_ARM926:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_VFP);
env-vfp.xregs[ARM_VFP_FPSID] = 0x41011090;
env-cp15.c0_cachetype = 0x1dd20d2;
env-cp15.c1_sys = 0x00090078;
break;
case ARM_CPUID_ARM946:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_MPU);
env-cp15.c0_cachetype = 0x0f004006;
env-cp15.c1_sys = 0x0078;
break;
case ARM_CPUID_ARM1026:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_VFP);
set_feature(env, ARM_FEATURE_AUXCR);
env-vfp.xregs[ARM_VFP_FPSID] = 0x410110a0;
@@ -67,6 +73,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
break;
case ARM_CPUID_ARM1136_R2:
case ARM_CPUID_ARM1136:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_VFP);
set_feature(env, ARM_FEATURE_AUXCR);
@@ -79,6 +87,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
env-cp15.c1_sys = 0x00050078;
break;
case ARM_CPUID_ARM11MPCORE:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_V6K);
set_feature(env, ARM_FEATURE_VFP);
@@ -91,6 +101,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
env-cp15.c0_cachetype = 0x1dd20d2;
break;
case ARM_CPUID_CORTEXA8:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_V6K);
set_feature(env, ARM_FEATURE_V7);
@@ -113,6 +125,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c1_sys = 0x00c50078;
break;
case ARM_CPUID_CORTEXA9:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_V6K);
set_feature(env, ARM_FEATURE_V7);
@@ -140,6 +154,8 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c1_sys = 0x00c50078;
break;
case ARM_CPUID_CORTEXM3:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
set_feature(env, ARM_FEATURE_V6);
set_feature(env, ARM_FEATURE_THUMB2);
set_feature(env, ARM_FEATURE_V7);
@@ -147,6 +163,8 @@ static void
[Qemu-devel] [PATCH 2/3] Implement basic part of SA-1110/SA-1100
Basic implementation of DEC/Intel SA-1100/SA-1110 chips emulation.
Implemented:
- IRQs
- GPIO
- PPC
- RTC
- UARTs (no IrDA/etc.)
- OST reused from pxa25x
Everything else is TODO (esp. PM/idle/sleep!) - see the todo in the
hw/strongarm.c
V3:
* fix the name of UART VMSD
* fix RTSR reg offset
* add SSP support
V2:
* removed all strongarm variants except latest
* dropped unused casts
* fixed PIC vmstate
* fixed new devices created with version_id = 1
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
Makefile.target |1 +
hw/strongarm.c | 1539 +++
hw/strongarm.h | 64 +++
target-arm/cpu.h|3 +
target-arm/helper.c |9 +
5 files changed, 1616 insertions(+), 0 deletions(-)
create mode 100644 hw/strongarm.c
create mode 100644 hw/strongarm.h
diff --git a/Makefile.target b/Makefile.target
index 2f76714..cd03cec 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -352,6 +352,7 @@ obj-arm-y += syborg.o syborg_fb.o syborg_interrupt.o
syborg_keyboard.o
obj-arm-y += syborg_serial.o syborg_timer.o syborg_pointer.o syborg_rtc.o
obj-arm-y += syborg_virtio.o
obj-arm-y += vexpress.o
+obj-arm-y += strongarm.o
obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/strongarm.c b/hw/strongarm.c
new file mode 100644
index 000..90b9ad0
--- /dev/null
+++ b/hw/strongarm.c
@@ -0,0 +1,1539 @@
+/*
+ * StrongARM SA-1100/SA-1110 emulation
+ *
+ * Copyright (C) 2011 Dmitry Eremin-Solenikov
+ *
+ * Largely based on StrongARM emulation:
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski bal...@zabor.org
+ *
+ * UART code based on QEMU 16550A UART emulation
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2008 Citrix Systems, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ */
+#include sysbus.h
+#include strongarm.h
+#include qemu-error.h
+#include arm-misc.h
+#include sysemu.h
+#include ssi.h
+
+/*
+ TODO
+ - Implement cp15, c14 ?
+ - Implement cp15, c15 !!! (idle used in L)
+ - Implement idle mode handling/DIM
+ - Implement sleep mode/Wake sources
+ - Implement reset control
+ - Implement memory control regs
+ - PCMCIA handling
+ - Maybe support MBGNT/MBREQ
+ - DMA channels
+ - GPCLK
+ - IrDA
+ - MCP
+ - Enhance UART with modem signals
+ */
+
+static struct {
+target_phys_addr_t io_base;
+int irq;
+} sa_serial[] = {
+{ 0x8001, SA_PIC_UART1 },
+{ 0x8003, SA_PIC_UART2 },
+{ 0x8005, SA_PIC_UART3 },
+{ 0, 0 }
+};
+
+/* Interrupt Controller */
+typedef struct {
+SysBusDevice busdev;
+qemu_irqirq;
+qemu_irqfiq;
+
+uint32_t pending;
+uint32_t enabled;
+uint32_t is_fiq;
+uint32_t int_idle;
+} StrongARMPICState;
+
+#define ICIP0x00
+#define ICMR0x04
+#define ICLR0x08
+#define ICFP0x10
+#define ICPR0x20
+#define ICCR0x0c
+
+#define SA_PIC_SRCS 32
+
+
+static void strongarm_pic_update(void *opaque)
+{
+StrongARMPICState *s = opaque;
+
+/* FIXME: reflect DIM */
+qemu_set_irq(s-fiq, s-pending s-enabled s-is_fiq);
+qemu_set_irq(s-irq, s-pending s-enabled ~s-is_fiq);
+}
+
+static void strongarm_pic_set_irq(void *opaque, int irq, int level)
+{
+StrongARMPICState *s = opaque;
+
+if (level) {
+s-pending |= 1 irq;
+} else {
+s-pending = ~(1 irq);
+}
+
+strongarm_pic_update(s);
+}
+
+static uint32_t strongarm_pic_mem_read(void *opaque, target_phys_addr_t offset)
+{
+StrongARMPICState *s = opaque;
+
+switch (offset) {
+case ICIP:
+return s-pending ~s-is_fiq s-enabled;
+case ICMR:
+return s-enabled;
+case ICLR:
+return s-is_fiq;
+case ICCR:
+return s-int_idle == 0;
+case ICFP:
+return s-pending s-is_fiq s-enabled;
+case ICPR:
+return s-pending;
+default:
+printf(%s: Bad register offset 0x TARGET_FMT_plx \n,
+__func__, offset);
+return 0;
+}
+}
+
+static void strongarm_pic_mem_write(void *opaque, target_phys_addr_t offset,
+uint32_t value)
+{
+StrongARMPICState *s = opaque;
+
+switch (offset) {
+case ICMR:
+s-enabled = value;
+break;
+case ICLR:
+s-is_fiq = value;
+break;
+case ICCR:
+s-int_idle = (value 1) ? 0 : ~0;
+break;
+default:
+printf(%s: Bad register offset 0x TARGET_FMT_plx \n,
+__func__, offset);
+break;
+}
+strongarm_pic_update(s);
+}
+
+static CPUReadMemoryFunc * const strongarm_pic_readfn[] = {
+strongarm_pic_mem_read,
+strongarm_pic_mem_read,
+strongarm_pic_mem_read,
+};
+
+static CPUWriteMemoryFunc * const strongarm_pic_writefn[] = {
+strongarm_pic_mem_write,
+
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On Mon, Apr 04, 2011 at 08:02:26AM -0500, Anthony Liguori wrote: On 04/04/2011 05:47 AM, Daniel P. Berrange wrote: I'm hoping libvirt's behavior can be made to just work rather than adding new features to QEMU. But perhaps passing file descriptors is useful for more than just reopening host devices. This would basically be a privilege separation model where the QEMU process isn't able to open files itself but can request libvirt to open them on its behalf. It is rather frickin' annoying the way udev resets the ownership when the media merely changes. If it isn't possible to stop udev doing this, then i think the only practical thing is to use ACLs instead of user/group ownership. We wanted to switch to ACLs in libvirt for other reasons already, but it isn't quite as simple as it sounds[1] so we've not done it just yet. Isn't the root of the problem that you're not running a guest in the expected security context? That doesn't really have any impact. If a desktop user is logged in, udev may change the ownership to match that user, but if they aren't, then udev may reset it to root:disk. Either way, QEMU may loose permissions to the disk. How much of a leap would it be to spawn a guest with the credentials of the user that created/defined it? Or better yet, to let the user be specified in the XML. That's a completely independent RFE which won't fix this issue in the general case. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH 3/3] Basic implementation of Sharp Zaurus SL-5500 collie PDA
Add very basic implementation of collie PDA emulation. The system lacks
LoCoMo and graphics/sound emulation. Linux kernel boots up to mounting
rootfs (theoretically it can be provided in pflash images).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
Makefile.target |1 +
hw/collie.c | 69 +++
2 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 hw/collie.c
diff --git a/Makefile.target b/Makefile.target
index cd03cec..47fba98 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -353,6 +353,7 @@ obj-arm-y += syborg_serial.o syborg_timer.o
syborg_pointer.o syborg_rtc.o
obj-arm-y += syborg_virtio.o
obj-arm-y += vexpress.o
obj-arm-y += strongarm.o
+obj-arm-y += collie.o
obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/collie.c b/hw/collie.c
new file mode 100644
index 000..156404d
--- /dev/null
+++ b/hw/collie.c
@@ -0,0 +1,69 @@
+/*
+ * SA-1110-based Sharp Zaurus SL-5500 platform.
+ *
+ * Copyright (C) 2011 Dmitry Eremin-Solenikov
+ *
+ * This code is licensed under GNU GPL v2.
+ */
+#include hw.h
+#include sysbus.h
+#include boards.h
+#include devices.h
+#include strongarm.h
+#include arm-misc.h
+#include flash.h
+#include blockdev.h
+
+static struct arm_boot_info collie_binfo = {
+.loader_start = SA_SDCS0,
+.ram_size = 0x2000,
+};
+
+static void collie_init(ram_addr_t ram_size,
+const char *boot_device,
+const char *kernel_filename, const char *kernel_cmdline,
+const char *initrd_filename, const char *cpu_model)
+{
+StrongARMState *s;
+DriveInfo *dinfo;
+ram_addr_t phys_flash;
+
+if (!cpu_model) {
+cpu_model = sa1110;
+}
+
+s = sa1110_init(collie_binfo.ram_size, cpu_model);
+
+phys_flash = qemu_ram_alloc(NULL, collie.fl1, 0x0200);
+dinfo = drive_get(IF_PFLASH, 0, 0);
+pflash_cfi01_register(SA_CS0, phys_flash,
+dinfo ? dinfo-bdrv : NULL, (64 * 1024),
+512, 4, 0x00, 0x00, 0x00, 0x00, 0);
+
+phys_flash = qemu_ram_alloc(NULL, collie.fl2, 0x0200);
+dinfo = drive_get(IF_PFLASH, 0, 1);
+pflash_cfi01_register(SA_CS1, phys_flash,
+dinfo ? dinfo-bdrv : NULL, (64 * 1024),
+512, 4, 0x00, 0x00, 0x00, 0x00, 0);
+
+sysbus_create_simple(scoop, 0x4080, NULL);
+
+collie_binfo.kernel_filename = kernel_filename;
+collie_binfo.kernel_cmdline = kernel_cmdline;
+collie_binfo.initrd_filename = initrd_filename;
+collie_binfo.board_id = 0x208;
+arm_load_kernel(s-env, collie_binfo);
+}
+
+static QEMUMachine collie_machine = {
+.name = collie,
+.desc = Collie PDA (SA-1110),
+.init = collie_init,
+};
+
+static void collie_machine_init(void)
+{
+qemu_register_machine(collie_machine);
+}
+
+machine_init(collie_machine_init)
--
1.7.4.1
Re: [Qemu-devel] [PATCH] Register only one qbus_reset_all_fn() for system bus
On Mon, Apr 04, 2011 at 03:58:39PM +0400, Dmitry Eremin-Solenikov wrote: On 4/3/11, Isaku Yamahata yamah...@valinux.co.jp wrote: On Sat, Apr 02, 2011 at 06:47:37PM +0400, Dmitry Eremin-Solenikov wrote: On 4/2/11, Isaku Yamahata yamah...@valinux.co.jp wrote: Have you verified that all bus devices have been qdevified since this code has been added? I wouldn't bet it is the case. I think his analysis is valid. So how about the following patch. Could you please point me to an example of devices for which this check is required. Although I don't have any example, I bet to not change the reset order. If you check all the devices, it's good. The question is which devices to check as lots of devices are already converted to qdev. Is it correct that we should check only devices which register a child bus with parent device set, and the thing that we should check is the fact that the parent reset function also causes the bus reset? qbus whose parent is NULL, non-qdev devices and qdev devices which uses qemu_register_reset() instead of DeviceInfo::reset. -- yamahata
Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/2011 08:22 AM, Avi Kivity wrote: On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote: In order for media change to work with Linux host CD-ROM it is necessary to reopen the file (otherwise the inode size will not refresh, this is an issue with existing kernels). Maybe we should fix the bug in Linux (and backport as necessary)? I think cd-rom assignment is sufficiently obscure that we can require a fixed kernel instead of providing a workaround. Do reads fail after CD change? Or do they succeed and the size is just reported incorrectly? If it's the later, I'd agree that it needs fixing in the kernel. If it's the former, I'd say it's clearly a feature. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/2011 04:38 PM, Anthony Liguori wrote: On 04/04/2011 08:22 AM, Avi Kivity wrote: On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote: In order for media change to work with Linux host CD-ROM it is necessary to reopen the file (otherwise the inode size will not refresh, this is an issue with existing kernels). Maybe we should fix the bug in Linux (and backport as necessary)? I think cd-rom assignment is sufficiently obscure that we can require a fixed kernel instead of providing a workaround. Do reads fail after CD change? Or do they succeed and the size is just reported incorrectly? If it's the later, I'd agree that it needs fixing in the kernel. If it's the former, I'd say it's clearly a feature. Even if it's a documented or intentional feature, we can add an ioctl to refresh the device with up-to-date data. -- error compiling committee.c: too many arguments to function
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/2011 08:16 AM, Daniel P. Berrange wrote: That doesn't really have any impact. If a desktop user is logged in, udev may change the ownership to match that user, but if they aren't, then udev may reset it to root:disk. Either way, QEMU may loose permissions to the disk. Then if you create a guest without being in the 'disk' group, it'll fail. That's pretty expected AFAICT. But with libvirt today, when you launch a guest, your security context doesn't matter and there's no way you can control what context the guest gets. libvirt is essentially creating it's own authorization mechanism. Supporting ACLs goes much further down that path. How much of a leap would it be to spawn a guest with the credentials of the user that created/defined it? Or better yet, to let the user be specified in the XML. That's a completely independent RFE which won't fix this issue in the general case. I think it really does. Regards, Anthony Liguori Regards, Daniel
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On Mon, Apr 04, 2011 at 09:19:36AM -0500, Anthony Liguori wrote: On 04/04/2011 08:16 AM, Daniel P. Berrange wrote: That doesn't really have any impact. If a desktop user is logged in, udev may change the ownership to match that user, but if they aren't, then udev may reset it to root:disk. Either way, QEMU may loose permissions to the disk. Then if you create a guest without being in the 'disk' group, it'll fail. That's pretty expected AFAICT. We don't *ever* want to put QEMU in the 'disk' group because that gives it access to any disk on the system in general. But with libvirt today, when you launch a guest, your security context doesn't matter and there's no way you can control what context the guest gets. libvirt is essentially creating it's own authorization mechanism. Supporting ACLs goes much further down that path. How much of a leap would it be to spawn a guest with the credentials of the user that created/defined it? Or better yet, to let the user be specified in the XML. That's a completely independent RFE which won't fix this issue in the general case. I think it really does. Nope it doesn't. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
On 03/30/11 16:07, Peter Maydell wrote: On 30 March 2011 14:56, Anthony Liguori anth...@codemonkey.ws wrote: On 03/30/2011 08:22 AM, Peter Maydell wrote: Not really, typically they're just filled up in some particular order (main RAM in one place and expansion RAM elsewhere). Since the board init function is only passed a single ram_size parameter that's all you can do anyhow. FWIW, I don't think any static data is going to be perfect here. A lot of boards have strict requirements on ram_size based on plausible combinations of DIMMs. Arbitrary values up to ram_size is not good enough. ram_size ought to be viewed as a hint, not a mechanism to allow common code to completely validate the passed in ram size parameter. It's still up to the board to validate that the given ram size makes sense. Yes, I agree, so we shouldn't try to specify some complicated set of static data that still won't be good enough. I'm trying to make it easy for boards to avoid crashing horribly when the user passes a bad value; that's all. If you don't validate properly, is there really a point in introducing that value anyway? From what you write, it sounds like it can still fail for some limits of the memory valid if the config is wrong? It still seems to me it would be better to have the boards present a table of valid memory ranges so we can do a proper validation of the valud? Cheers, Jes
[Qemu-devel] [PATCH 06/15] s390x: Dispatch interrupts to KVM or the real CPU
The KVM interrupt injection path is non-generic for now. So we need to push
knowledge of how to inject a device interrupt using KVM into the actual device
code.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/s390-virtio-bus.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index 60e0135..35acf53 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -43,6 +43,8 @@
do { } while (0)
#endif
+#define VIRTIO_EXT_CODE 0x2603
+
struct BusInfo s390_virtio_bus_info = {
.name = s390-virtio,
.size = sizeof(VirtIOS390Bus),
@@ -304,9 +306,13 @@ static void virtio_s390_notify(void *opaque, uint16_t
vector)
{
VirtIOS390Device *dev = (VirtIOS390Device*)opaque;
uint64_t token = s390_virtio_device_vq_token(dev, vector);
+CPUState *env = s390_cpu_addr2state(0);
-/* XXX kvm dependency! */
-kvm_s390_virtio_irq(s390_cpu_addr2state(0), 0, token);
+if (kvm_enabled()) {
+kvm_s390_virtio_irq(env, 0, token);
+} else {
+cpu_inject_ext(env, VIRTIO_EXT_CODE, 0, token);
+}
}
static unsigned virtio_s390_get_features(void *opaque)
--
1.6.0.2
[Qemu-devel] [PATCH 07/15] s390x: Adjust GDB stub
We have successfully lazilized cc computation, so we need to manually trigger its calculation when gdb wants to fetch it. We also changed the variable name, so writing it writes into a different field now. Signed-off-by: Alexander Graf ag...@suse.de --- gdbstub.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/gdbstub.c b/gdbstub.c index 0838948..ae856f9 100644 --- a/gdbstub.c +++ b/gdbstub.c @@ -1436,7 +1436,11 @@ static int cpu_gdb_read_register(CPUState *env, uint8_t *mem_buf, int n) /* XXX */ break; case S390_PC_REGNUM: GET_REGL(env-psw.addr); break; -case S390_CC_REGNUM: GET_REG32(env-cc); break; +case S390_CC_REGNUM: +env-cc_op = calc_cc(env, env-cc_op, env-cc_src, env-cc_dst, + env-cc_vr); +GET_REG32(env-cc_op); +break; } return 0; @@ -1462,7 +1466,7 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t *mem_buf, int n) /* XXX */ break; case S390_PC_REGNUM: env-psw.addr = tmpl; break; -case S390_CC_REGNUM: env-cc = tmp32; r=4; break; +case S390_CC_REGNUM: env-cc_op = tmp32; r=4; break; } return r; -- 1.6.0.2
[Qemu-devel] [PATCH 01/15] s390x: fix virtio feature bitmap
The feature bitmap in the s390 virtio machine is little endian. To
address for that, we need to bswap the values after reading them out.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/s390-virtio-bus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index 58af164..60e0135 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -223,7 +223,7 @@ void s390_virtio_device_sync(VirtIOS390Device *dev)
cur_offs += num_vq * VIRTIO_VQCONFIG_LEN;
/* Sync feature bitmap */
-stl_phys(cur_offs, dev-host_features);
+stl_phys(cur_offs, bswap32(dev-host_features));
dev-feat_offs = cur_offs + dev-feat_len;
cur_offs += dev-feat_len * 2;
@@ -246,7 +246,7 @@ void s390_virtio_device_update_status(VirtIOS390Device *dev)
/* Update guest supported feature bitmap */
-features = ldl_phys(dev-feat_offs);
+features = bswap32(ldl_phys(dev-feat_offs));
if (vdev-set_features) {
vdev-set_features(vdev, features);
}
--
1.6.0.2
[Qemu-devel] [PATCH 05/15] s390x: Enable s390x-softmmu target
This patch adds some code paths for running s390x guest OSs without the
need for KVM.
Signed-off-by: Alexander Graf ag...@suse.de
---
cpu-exec.c |8
target-s390x/exec.h | 20
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 5cc9379..ebc8cba 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -343,6 +343,8 @@ int cpu_exec(CPUState *env1)
do_interrupt(env);
#elif defined(TARGET_M68K)
do_interrupt(0);
+#elif defined(TARGET_S390X)
+do_interrupt(env);
#endif
env-exception_index = -1;
#endif
@@ -551,6 +553,12 @@ int cpu_exec(CPUState *env1)
do_interrupt(1);
next_tb = 0;
}
+#elif defined(TARGET_S390X) !defined(CONFIG_USER_ONLY)
+if ((interrupt_request CPU_INTERRUPT_HARD)
+(env-psw.mask PSW_MASK_EXT)) {
+do_interrupt(env);
+next_tb = 0;
+}
#endif
/* Don't use the cached interupt_request value,
do_interrupt may have updated the EXITTB flag. */
diff --git a/target-s390x/exec.h b/target-s390x/exec.h
index f7893f3..6fe64a6 100644
--- a/target-s390x/exec.h
+++ b/target-s390x/exec.h
@@ -34,6 +34,26 @@ static inline int cpu_has_work(CPUState *env)
return env-interrupt_request CPU_INTERRUPT_HARD; // guess
}
+static inline void regs_to_env(void)
+{
+}
+
+static inline void env_to_regs(void)
+{
+}
+
+static inline int cpu_halted(CPUState *env)
+{
+if (!env-halted) {
+ return 0;
+}
+if (cpu_has_work(env)) {
+env-halted = 0;
+return 0;
+}
+return EXCP_HALTED;
+}
+
static inline void cpu_pc_from_tb(CPUState *env, TranslationBlock* tb)
{
env-psw.addr = tb-pc;
--
1.6.0.2
[Qemu-devel] [PATCH 02/15] s390x: set alignment for long to 8
The alignment for longs on s390x is 8. That's the only place where it differs from the default alignments found in configure already. The example alignment program from Laurent printed the following on a real s390x: alignof(short) 2 alignof(int) 4 alignof(long) 8 alignof(long long) 8 Signed-off-by: Alexander Graf ag...@suse.de --- configure |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure b/configure index faaed60..1e068e6 100755 --- a/configure +++ b/configure @@ -3182,6 +3182,7 @@ case $target_arch2 in s390x) target_nptl=yes target_phys_bits=64 +target_long_alignment=8 ;; *) echo Unsupported target CPU -- 1.6.0.2
[Qemu-devel] [PATCH 04/15] linux-user: define a couple of syscalls for non-uid16 targets
From: Ulrich Hecht u...@suse.de
Quite a number of syscalls are only defined on systems with USE_UID16
defined; this patch defines them on other systems as well.
Fixes a large number of uid/gid-related testcases on the s390x target
(and most likely on other targets as well)
Signed-off-by: Ulrich Hecht u...@suse.de
---
linux-user/syscall.c | 125 ++
1 files changed, 105 insertions(+), 20 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fabe815..0bce466 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -326,7 +326,7 @@ static int sys_fchmodat(int dirfd, const char *pathname,
mode_t mode)
return (fchmodat(dirfd, pathname, mode, 0));
}
#endif
-#if defined(TARGET_NR_fchownat) defined(USE_UID16)
+#if defined(TARGET_NR_fchownat)
static int sys_fchownat(int dirfd, const char *pathname, uid_t owner,
gid_t group, int flags)
{
@@ -435,7 +435,7 @@ _syscall3(int,sys_faccessat,int,dirfd,const char
*,pathname,int,mode)
#if defined(TARGET_NR_fchmodat) defined(__NR_fchmodat)
_syscall3(int,sys_fchmodat,int,dirfd,const char *,pathname, mode_t,mode)
#endif
-#if defined(TARGET_NR_fchownat) defined(__NR_fchownat) defined(USE_UID16)
+#if defined(TARGET_NR_fchownat) defined(__NR_fchownat)
_syscall5(int,sys_fchownat,int,dirfd,const char *,pathname,
uid_t,owner,gid_t,group,int,flags)
#endif
@@ -6817,18 +6817,35 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
case TARGET_NR_setfsgid:
ret = get_errno(setfsgid(arg1));
break;
+#else /* USE_UID16 */
+#if defined(TARGET_NR_fchownat) defined(__NR_fchownat)
+case TARGET_NR_fchownat:
+if (!(p = lock_user_string(arg2)))
+goto efault;
+ret = get_errno(sys_fchownat(arg1, p, arg3, arg4, arg5));
+unlock_user(p, arg2, 0);
+break;
+#endif
#endif /* USE_UID16 */
-#ifdef TARGET_NR_lchown32
+#if defined(TARGET_NR_lchown32) || !defined(USE_UID16)
+#if defined(TARGET_NR_lchown32)
case TARGET_NR_lchown32:
+#else
+case TARGET_NR_lchown:
+#endif
if (!(p = lock_user_string(arg1)))
goto efault;
ret = get_errno(lchown(p, arg2, arg3));
unlock_user(p, arg1, 0);
break;
#endif
-#ifdef TARGET_NR_getuid32
+#if defined(TARGET_NR_getuid32) || (defined(TARGET_NR_getuid)
!defined(USE_UID16))
+#if defined(TARGET_NR_getuid32)
case TARGET_NR_getuid32:
+#else
+case TARGET_NR_getuid:
+#endif
ret = get_errno(getuid());
break;
#endif
@@ -6973,33 +6990,57 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
break;
#endif
-#ifdef TARGET_NR_getgid32
+#if defined(TARGET_NR_getgid32) || (defined(TARGET_NR_getgid)
!defined(USE_UID16))
+#if defined(TARGET_NR_getgid32)
case TARGET_NR_getgid32:
+#else
+case TARGET_NR_getgid:
+#endif
ret = get_errno(getgid());
break;
#endif
-#ifdef TARGET_NR_geteuid32
+#if defined(TARGET_NR_geteuid32) || (defined(TARGET_NR_geteuid)
!defined(USE_UID16))
+#if defined(TARGET_NR_geteuid32)
case TARGET_NR_geteuid32:
+#else
+case TARGET_NR_geteuid:
+#endif
ret = get_errno(geteuid());
break;
#endif
-#ifdef TARGET_NR_getegid32
+#if defined(TARGET_NR_getegid32) || (defined(TARGET_NR_getegid)
!defined(USE_UID16))
+#if defined(TARGET_NR_getegid32)
case TARGET_NR_getegid32:
+#else
+case TARGET_NR_getegid:
+#endif
ret = get_errno(getegid());
break;
#endif
-#ifdef TARGET_NR_setreuid32
+#if defined(TARGET_NR_setreuid32) || !defined(USE_UID16)
+#if defined(TARGET_NR_setreuid32)
case TARGET_NR_setreuid32:
+#else
+case TARGET_NR_setreuid:
+#endif
ret = get_errno(setreuid(arg1, arg2));
break;
#endif
-#ifdef TARGET_NR_setregid32
+#if defined(TARGET_NR_setregid32) || !defined(USE_UID16)
+#if defined(TARGET_NR_setregid32)
case TARGET_NR_setregid32:
+#else
+case TARGET_NR_setregid:
+#endif
ret = get_errno(setregid(arg1, arg2));
break;
#endif
-#ifdef TARGET_NR_getgroups32
+#if defined(TARGET_NR_getgroups32) || !defined(USE_UID16)
+#if defined(TARGET_NR_getgroups32)
case TARGET_NR_getgroups32:
+#else
+case TARGET_NR_getgroups:
+#endif
{
int gidsetsize = arg1;
uint32_t *target_grouplist;
@@ -7023,8 +7064,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
}
break;
#endif
-#ifdef TARGET_NR_setgroups32
+#if defined(TARGET_NR_setgroups32) || !defined(USE_UID16)
+#if defined(TARGET_NR_setgroups32)
case TARGET_NR_setgroups32:
+#else
+case TARGET_NR_setgroups:
+#endif
{
int gidsetsize = arg1;
uint32_t *target_grouplist;
@@ -7044,18 +7089,30 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
}
break;
#endif
-#ifdef TARGET_NR_fchown32
+#if defined(TARGET_NR_fchown32) || !defined(USE_UID16)
+#if
[Qemu-devel] [PATCH 15/15] tcg: use ext op for deposit
With the s390x target we use the deposit instruction to store 32bit values
into 64bit registers without clobbering the upper 32 bits.
This specific operation can be optimized slightly by using the ext operation
instead of an explicit and in the deposit instruction. This patch adds that
special case to the generic deposit implementation.
Signed-off-by: Alexander Graf ag...@suse.de
---
tcg/tcg-op.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index 207a89f..88575e7 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -2124,7 +2124,11 @@ static inline void tcg_gen_deposit_i64(TCGv_i64 ret,
TCGv_i64 arg1,
uint64_t mask = (1ull len) - 1;
TCGv_i64 t1 = tcg_temp_new_i64 ();
- tcg_gen_andi_i64(t1, arg2, mask);
+ if (len == 32) {
+ tcg_gen_ext32u_i64(t1, arg2);
+ } else {
+ tcg_gen_andi_i64(t1, arg2, mask);
+ }
tcg_gen_shli_i64(t1, t1, ofs);
tcg_gen_andi_i64(ret, arg1, ~(mask ofs));
tcg_gen_or_i64(ret, ret, t1);
--
1.6.0.2
[Qemu-devel] [PATCH 00/15] s390x emulation support v3
We've had support for running s390x guests with KVM for a while now. This patch set also enables support for running s390x guests in system as well as linux-user mode in emulation! Within this scope, I again want to stress that this is _not_ supposed to replace Hercules - the s390 emulator - in any way. The only target supported by qemu is Linux. You can only run Linux applications with linux-user emulation and Linux guest OSs with the system emulation. All the device logic (and 24 bit mode) for running legacy stuff is missing. Use Hercules for those! I have successfully run the following guest OSs: - SUSE Linux Enterprise Server 11 SP1 - Debian Lenny Both of which work just fine on x86_64 and ppc hosts. Other hosts should also work. The only thing that did not work for me is network. Somehow networking only works with KVM enabled, so there is probably some bug involved still. Either way - rejoice! As with this patch set you can finally fulfill your mainframe desires on your local workstation. And - most importantly - finally test patches to virtio against s390! For images, I'm hoping for Aurelien to provide Debian images that run in qemu. Other distributions only provide S390x target support in their enterprise variants, keeping me from redistributing images :(. If you're trying to get things rolling yourself, make sure to use a recent kernel that has support for the virtio architecture and virtio console support - otherwise you won't see output. The linux user mode emulation part only support 64bit binaries, so running Debian binaries with that one is out of question for now. Use the system emulation mode if you really need to run Debian binaries. For the lazy ones: git://repo.or.cz/qemu/agraf.git s390-tcg-v3 v1 - v2: - fix broken s390-virtio-serial - fix broken s390 kvm target - always set 64bit flag for s390x binaries in elf loader - remove redundant EXECUTE_SVC - advance psw.addr in syscall execution path - remove FPReg definition - add descriptions to more cc_ops - add comment on time2tod - describe EXCP_EXT - use new clock syntax - use float_chs - use float compare built-ins - remove redundant EXECUTE_SVC - don't pass env into DisasContext - remove if 0'd code - truncate at 80 chars - enable disas debug by default (-d in_asm) - remove explicit psw.addr advancing on SVC v2 - v3: - use g2h instead of direct casts - remove old code stuffed into comments - reduce amount of tcg ops in LM and LMH to stay below limits - add patch: fix virtio feature bitmap - add patch: set alignment for long to 8 - add patch: use ext op for deposit Alexander Graf (13): s390x: fix virtio feature bitmap s390x: set alignment for long to 8 s390x: Enable s390x-softmmu target s390x: Dispatch interrupts to KVM or the real CPU s390x: Adjust GDB stub s390x: virtio machine storage keys s390x: Prepare cpu.h for emulation s390x: helper functions for system emulation s390x: Implement opcode helpers s390x: Adjust internal kvm code s390x: translate engine for s390x CPU s390x: build s390x by default tcg: use ext op for deposit Ulrich Hecht (2): s390x: s390x-linux-user support linux-user: define a couple of syscalls for non-uid16 targets configure|3 + cpu-exec.c |8 + default-configs/s390x-linux-user.mak |1 + gdbstub.c|8 +- hw/s390-virtio-bus.c | 14 +- hw/s390-virtio.c | 21 +- linux-user/elfload.c | 19 + linux-user/main.c| 83 + linux-user/s390x/syscall.h | 25 + linux-user/s390x/syscall_nr.h| 349 +++ linux-user/s390x/target_signal.h | 26 + linux-user/s390x/termbits.h | 283 ++ linux-user/signal.c | 314 +++ linux-user/syscall.c | 143 +- linux-user/syscall_defs.h| 56 +- s390x.ld | 194 ++ scripts/qemu-binfmt-conf.sh |4 +- target-s390x/cpu.h | 770 +- target-s390x/exec.h | 20 + target-s390x/helper.c| 581 - target-s390x/helpers.h | 151 + target-s390x/kvm.c | 60 +- target-s390x/op_helper.c | 2881 +++- target-s390x/translate.c | 5120 +- tcg/tcg-op.h |6 +- 25 files changed, 10988 insertions(+), 152 deletions(-) create mode 100644 default-configs/s390x-linux-user.mak create mode 100644 linux-user/s390x/syscall.h create mode 100644 linux-user/s390x/syscall_nr.h create mode 100644 linux-user/s390x/target_signal.h create mode 100644 linux-user/s390x/termbits.h create mode 100644 s390x.ld create mode 100644 target-s390x/helpers.h
[Qemu-devel] [PATCH 14/15] s390x: build s390x by default
This patch enables building of s390x-softmmu and s390x-linux-user targets by default. Signed-off-by: Alexander Graf ag...@suse.de --- configure|2 ++ default-configs/s390x-linux-user.mak |1 + 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 default-configs/s390x-linux-user.mak diff --git a/configure b/configure index 1e068e6..fcff1cc 100755 --- a/configure +++ b/configure @@ -1022,6 +1022,7 @@ sh4-softmmu \ sh4eb-softmmu \ sparc-softmmu \ sparc64-softmmu \ +s390x-softmmu \ fi # the following are Linux specific @@ -1046,6 +1047,7 @@ sh4eb-linux-user \ sparc-linux-user \ sparc64-linux-user \ sparc32plus-linux-user \ +s390x-linux-user \ fi # the following are Darwin specific diff --git a/default-configs/s390x-linux-user.mak b/default-configs/s390x-linux-user.mak new file mode 100644 index 000..a243c99 --- /dev/null +++ b/default-configs/s390x-linux-user.mak @@ -0,0 +1 @@ +# Default configuration for s390x-linux-user -- 1.6.0.2
Re: [Qemu-devel] [PATCH V1 3/8] Implementation of the TCG BIOS extensions
On 04/04/2011 12:14 AM, Kevin O'Connor wrote: Hi Stefan, I haven't had a chance to fully review, but I do have some comments. Thanks. I can post a v2 as a followup to your changes. On Wed, Mar 30, 2011 at 01:55:37PM -0400, Stefan Berger wrote: [...] - a utility function called mssleep is added. It waits for a number of milliseconds before it returns. I had tried to build a function like that based on calc_future_time() and check_timer(), but those didn't work once in an S3 resume. There is already msleep() for this. The inb(0x61) thing doesn't actually work anywhere but on bochs. If msleep() isn't working for you, try rerunning calibrate_tsc() after S3 resume. Using that one now. [...] +/* + * Implementation of the TCG BIOS extension according to the specification + * described in + * https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PCClientImplementationforBIOS_1-20_1-00.pdf + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. SeaBIOS is LGPLv3. Also, I'm not a big fan of these big copyright notices on the top of every file - is it necessary? I will change it to look like the other files. [...] +#if CONFIG_TCGBIOS I'd prefer to avoid ifdefs in the code. Everything should be setup to have the compiler/linker automatically drop anything unused. (So, a simple if (!CONFIG_TCGBIOS) return; should drop any function and all variables/functions only reachable from it.) Ok, I will adapt it to that. [...] +//#define DEBUG_TCGBIOS Same here. Can you use just set DEBUG_tcg to a value in config.h and replace all the dprintf(1, ...) with dprintf(DEBUG_tcg, ...)? Did that now. +static u8 +calc_checksum(const u8 *addr, u32 length) util.c:checksum() Using that one. +static struct rsdp_descriptor * +find_rsdp(u8 *start, unsigned int len) Should be unneeded - see how acpi.c:find_resume_vector() works. I was going to keep the function find_rsdp but change its implementation to the test you are doing in find_resume_vector() regarding rsdp signature. Stefan -Kevin
[Qemu-devel] [PATCH 08/15] s390x: virtio machine storage keys
For emulation (and migration) we need to know about the guest's storage keys.
These are separate from actual RAM contents, so we need to allocate them in
parallel to RAM.
While touching the file, this patch also adjusts the hypercall function
to a new syntax that aligns better with tcg emulated code.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/s390-virtio.c | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 850422f..be2c80c 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -82,13 +82,12 @@ CPUState *s390_cpu_addr2state(uint16_t cpu_addr)
return ipi_states[cpu_addr];
}
-int s390_virtio_hypercall(CPUState *env)
+int s390_virtio_hypercall(CPUState *env, uint64_t mem, uint64_t hypercall)
{
int r = 0, i;
-target_ulong mem = env-regs[2];
-dprintf(KVM hypercall: %ld\n, env-regs[1]);
-switch (env-regs[1]) {
+dprintf(KVM hypercall: %ld\n, hypercall);
+switch (hypercall) {
case KVM_S390_VIRTIO_NOTIFY:
if (mem ram_size) {
VirtIOS390Device *dev = s390_virtio_bus_find_vring(s390_bus,
@@ -128,8 +127,7 @@ int s390_virtio_hypercall(CPUState *env)
break;
}
-env-regs[2] = r;
-return 0;
+return r;
}
/* PC hardware initialisation */
@@ -145,14 +143,9 @@ static void s390_init(ram_addr_t ram_size,
ram_addr_t kernel_size = 0;
ram_addr_t initrd_offset;
ram_addr_t initrd_size = 0;
+uint8_t *storage_keys;
int i;
-/* XXX we only work on KVM for now */
-
-if (!kvm_enabled()) {
-fprintf(stderr, The S390 target only works with KVM enabled\n);
-exit(1);
-}
/* get a BUS */
s390_bus = s390_virtio_bus_init(ram_size);
@@ -161,6 +154,9 @@ static void s390_init(ram_addr_t ram_size,
ram_addr = qemu_ram_alloc(NULL, s390.ram, ram_size);
cpu_register_physical_memory(0, ram_size, ram_addr);
+/* allocate storage keys */
+storage_keys = qemu_mallocz(ram_size / TARGET_PAGE_SIZE);
+
/* init CPUs */
if (cpu_model == NULL) {
cpu_model = host;
@@ -178,6 +174,7 @@ static void s390_init(ram_addr_t ram_size,
ipi_states[i] = tmp_env;
tmp_env-halted = 1;
tmp_env-exception_index = EXCP_HLT;
+tmp_env-storage_keys = storage_keys;
}
env-halted = 0;
--
1.6.0.2
Re: [Qemu-devel] [PATCH V1 2/8] Provide ACPI SSDT table for TPM device + S3 resume support
On 04/04/2011 12:17 AM, Kevin O'Connor wrote: On Wed, Mar 30, 2011 at 01:55:36PM -0400, Stefan Berger wrote: This patch provides ACPI support for the TPM device. It probes for the TPM device and only if a TPM device is found then the TPM's SSDT and TCPA table are created. This patch also connects them to the RSDT. [...] // Space to reserve in high-memory for tables -#define CONFIG_MAX_HIGHTABLE (64*1024) +#if CONFIG_TCGBIOS +# define CONFIG_MAX_HIGHTABLE (96*1024) +#else +# define CONFIG_MAX_HIGHTABLE (64*1024) +#endif I'm a bit confused on patch ordering - it seems CONFIG_TCGBIOS is defined in patch 4 but used in patch 2. I had it in patch 2 since there I am allocating 64kb in the high memory... I'll move it to patch 4. Also, I'd prefer to avoid ifdefs - just up the size to 96 always, or do something like: #define CONFIG_MAX_HIGHTABLE ((64*1024) + CONFIG_TCGBIOS*(32*1024)) Done that. Stefan -Kevin
[Qemu-devel] [PATCH 03/15] s390x: s390x-linux-user support
From: Ulrich Hecht u...@suse.de
This patch adds support for running s390x binaries in the linux-user emulation
code.
Signed-off-by: Ulrich Hecht u...@suse.de
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- always set 64bit flag for s390x binaries in elf loader
- remove redundant EXECUTE_SVC
- advance psw.addr in syscall execution path
---
linux-user/elfload.c | 19 ++
linux-user/main.c| 83 +
linux-user/s390x/syscall.h | 25 +++
linux-user/s390x/syscall_nr.h| 349 ++
linux-user/s390x/target_signal.h | 26 +++
linux-user/s390x/termbits.h | 283 ++
linux-user/signal.c | 314 ++
linux-user/syscall.c | 18 ++-
linux-user/syscall_defs.h| 56 ++-
s390x.ld | 194 +
scripts/qemu-binfmt-conf.sh |4 +-
11 files changed, 1363 insertions(+), 8 deletions(-)
create mode 100644 linux-user/s390x/syscall.h
create mode 100644 linux-user/s390x/syscall_nr.h
create mode 100644 linux-user/s390x/target_signal.h
create mode 100644 linux-user/s390x/termbits.h
create mode 100644 s390x.ld
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index fe5410e..489f839 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -793,6 +793,25 @@ static inline void init_thread(struct target_pt_regs *regs,
#endif /* TARGET_ALPHA */
+#ifdef TARGET_S390X
+
+#define ELF_START_MMAP (0x200ULL)
+
+#define elf_check_arch(x) ( (x) == ELF_ARCH )
+
+#define ELF_CLASS ELFCLASS64
+#define ELF_DATA ELFDATA2MSB
+#define ELF_ARCH EM_S390
+
+static inline void init_thread(struct target_pt_regs *regs, struct image_info
*infop)
+{
+regs-psw.addr = infop-entry;
+regs-psw.mask = PSW_MASK_64 | PSW_MASK_32;
+regs-gprs[15] = infop-start_stack;
+}
+
+#endif /* TARGET_S390X */
+
#ifndef ELF_PLATFORM
#define ELF_PLATFORM (NULL)
#endif
diff --git a/linux-user/main.c b/linux-user/main.c
index e651bfd..362b8cb 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2624,6 +2624,80 @@ void cpu_loop (CPUState *env)
}
#endif /* TARGET_ALPHA */
+#ifdef TARGET_S390X
+void cpu_loop(CPUS390XState *env)
+{
+int trapnr;
+target_siginfo_t info;
+
+while (1) {
+trapnr = cpu_s390x_exec (env);
+
+switch (trapnr) {
+case EXCP_INTERRUPT:
+/* just indicate that signals should be handled asap */
+break;
+case EXCP_DEBUG:
+{
+int sig;
+
+sig = gdb_handlesig (env, TARGET_SIGTRAP);
+if (sig) {
+info.si_signo = sig;
+info.si_errno = 0;
+info.si_code = TARGET_TRAP_BRKPT;
+queue_signal(env, info.si_signo, info);
+}
+}
+break;
+case EXCP_SVC:
+{
+int n = env-int_svc_code;
+if (!n) {
+/* syscalls 255 */
+n = env-regs[1];
+}
+env-psw.addr += env-int_svc_ilc;
+env-regs[2] = do_syscall(env, n,
+ env-regs[2],
+ env-regs[3],
+ env-regs[4],
+ env-regs[5],
+ env-regs[6],
+ env-regs[7]);
+}
+break;
+case EXCP_ADDR:
+{
+info.si_signo = SIGSEGV;
+info.si_errno = 0;
+/* XXX: check env-error_code */
+info.si_code = TARGET_SEGV_MAPERR;
+info._sifields._sigfault._addr = env-__excp_addr;
+queue_signal(env, info.si_signo, info);
+}
+break;
+case EXCP_SPEC:
+{
+fprintf(stderr,specification exception insn 0x%08x%04x\n,
ldl(env-psw.addr), lduw(env-psw.addr + 4));
+info.si_signo = SIGILL;
+info.si_errno = 0;
+info.si_code = TARGET_ILL_ILLOPC;
+info._sifields._sigfault._addr = env-__excp_addr;
+queue_signal(env, info.si_signo, info);
+}
+break;
+default:
+printf (Unhandled trap: 0x%x\n, trapnr);
+cpu_dump_state(env, stderr, fprintf, 0);
+exit (1);
+}
+process_pending_signals (env);
+}
+}
+
+#endif /* TARGET_S390X */
+
static void version(void)
{
printf(qemu- TARGET_ARCH version QEMU_VERSION QEMU_PKGVERSION
@@ -3363,6 +3437,15 @@ int main(int argc, char **argv, char **envp)
env-regs[15] = regs-acr;
env-pc = regs-erp;
}
+#elif defined(TARGET_S390X)
+{
+int i;
+for (i = 0; i 16; i++) {
+
[Qemu-devel] [PATCH 09/15] s390x: Prepare cpu.h for emulation
We need to add some more logic to the CPU description to leverage emulation
of an s390x CPU. This patch adds all the required helpers, fields in CPUState
and constant definitions required for user and system emulation.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- remove FPReg definition
- remove EXCP_EXECUTE_SVC in non user-mode
- add descriptions to more cc_ops
- add comment on time2tod
- remove redundant EXECUTE_SVC
- describe EXCP_EXT
---
target-s390x/cpu.h | 770 +---
1 files changed, 726 insertions(+), 44 deletions(-)
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index e47c372..0d9c4f2 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -26,24 +26,35 @@
#define CPUState struct CPUS390XState
#include cpu-defs.h
+#define TARGET_PAGE_BITS 12
+
+#define TARGET_PHYS_ADDR_SPACE_BITS 64
+#define TARGET_VIRT_ADDR_SPACE_BITS 64
+
+#include cpu-all.h
#include softfloat.h
-#define NB_MMU_MODES 2
+#define NB_MMU_MODES 3
-typedef union FPReg {
-struct {
-#ifdef WORDS_BIGENDIAN
-float32 e;
-int32_t __pad;
-#else
-int32_t __pad;
-float32 e;
-#endif
-};
-float64 d;
-uint64_t i;
-} FPReg;
+#define MMU_MODE0_SUFFIX _primary
+#define MMU_MODE1_SUFFIX _secondary
+#define MMU_MODE2_SUFFIX _home
+
+#define MMU_USER_IDX 1
+
+#define MAX_EXT_QUEUE 16
+
+typedef struct PSW {
+uint64_t mask;
+uint64_t addr;
+} PSW;
+
+typedef struct ExtQueue {
+uint32_t code;
+uint32_t param;
+uint32_t param64;
+} ExtQueue;
typedef struct CPUS390XState {
uint64_t regs[16]; /* GP registers */
@@ -51,17 +62,41 @@ typedef struct CPUS390XState {
uint32_t aregs[16];/* access registers */
uint32_t fpc; /* floating-point control register */
-FPReg fregs[16]; /* FP registers */
+CPU_DoubleU fregs[16]; /* FP registers */
float_status fpu_status; /* passed to softfloat lib */
-struct {
-uint64_t mask;
-uint64_t addr;
-} psw;
+PSW psw;
-int cc; /* condition code (0-3) */
+uint32_t cc_op;
+uint64_t cc_src;
+uint64_t cc_dst;
+uint64_t cc_vr;
uint64_t __excp_addr;
+uint64_t psa;
+
+uint32_t int_pgm_code;
+uint32_t int_pgm_ilc;
+
+uint32_t int_svc_code;
+uint32_t int_svc_ilc;
+
+uint64_t cregs[16]; /* control registers */
+
+int pending_int;
+ExtQueue ext_queue[MAX_EXT_QUEUE];
+
+/* reset does memset(0) up to here */
+
+int ext_index;
+int cpu_num;
+uint8_t *storage_keys;
+
+uint64_t tod_offset;
+uint64_t tod_basetime;
+QEMUTimer *tod_timer;
+
+QEMUTimer *cpu_timer;
CPU_COMMON
} CPUS390XState;
@@ -69,24 +104,174 @@ typedef struct CPUS390XState {
#if defined(CONFIG_USER_ONLY)
static inline void cpu_clone_regs(CPUState *env, target_ulong newsp)
{
-if (newsp)
+if (newsp) {
env-regs[15] = newsp;
+}
env-regs[0] = 0;
}
#endif
-#define MMU_MODE0_SUFFIX _kernel
-#define MMU_MODE1_SUFFIX _user
-#define MMU_USER_IDX 1
+/* Interrupt Codes */
+/* Program Interrupts */
+#define PGM_OPERATION 0x0001
+#define PGM_PRIVILEGED 0x0002
+#define PGM_EXECUTE 0x0003
+#define PGM_PROTECTION 0x0004
+#define PGM_ADDRESSING 0x0005
+#define PGM_SPECIFICATION 0x0006
+#define PGM_DATA0x0007
+#define PGM_FIXPT_OVERFLOW 0x0008
+#define PGM_FIXPT_DIVIDE0x0009
+#define PGM_DEC_OVERFLOW0x000a
+#define PGM_DEC_DIVIDE 0x000b
+#define PGM_HFP_EXP_OVERFLOW0x000c
+#define PGM_HFP_EXP_UNDERFLOW 0x000d
+#define PGM_HFP_SIGNIFICANCE0x000e
+#define PGM_HFP_DIVIDE 0x000f
+#define PGM_SEGMENT_TRANS 0x0010
+#define PGM_PAGE_TRANS 0x0011
+#define PGM_TRANS_SPEC 0x0012
+#define PGM_SPECIAL_OP 0x0013
+#define PGM_OPERAND 0x0015
+#define PGM_TRACE_TABLE 0x0016
+#define PGM_SPACE_SWITCH0x001c
+#define PGM_HFP_SQRT0x001d
+#define PGM_PC_TRANS_SPEC 0x001f
+#define PGM_AFX_TRANS 0x0020
+#define PGM_ASX_TRANS 0x0021
+#define PGM_LX_TRANS0x0022
+#define PGM_EX_TRANS0x0023
+#define PGM_PRIM_AUTH 0x0024
+#define PGM_SEC_AUTH0x0025
+#define PGM_ALET_SPEC 0x0028
+#define PGM_ALEN_SPEC 0x0029
+#define PGM_ALE_SEQ 0x002a
+#define PGM_ASTE_VALID 0x002b
+#define PGM_ASTE_SEQ0x002c
+#define PGM_EXT_AUTH0x002d
+#define PGM_STACK_FULL 0x0030
+#define PGM_STACK_EMPTY 0x0031
+#define PGM_STACK_SPEC
Re: [Qemu-devel] [PATCH V1 5/8] Support for BIOS interrupt handler
On 04/04/2011 12:30 AM, Kevin O'Connor wrote:
On Wed, Mar 30, 2011 at 01:55:39PM -0400, Stefan Berger wrote:
This patch implements the TCG BIOS interrupt handler 1ah. It is for
example used by trusted grub.
[...]
+/***
+ Calculation of SHA1 in SW
+
+ See: http://www.itl.nist.gov/fipspubs/fip180-1.htm
+ RFC3174, Wikipedia's SHA1 alogrithm description
+ **/
Looks like tcgbios.c is awfully big - can we move the sha1 code to
it's own file (eg, sha1.c)?
Done.
[...]
+static inline u32 rol(u32 val, u16 rol)
Should move to util.h.
Done.
+static inline u64 bswap_64(u64 val)
Same.
Done.
[...]
+++ seabios/src/stacks.c
[...]
+#ifdef CONFIG_TCGBIOS
+void tcpa_interrupt_handler16(struct bregs *regs)
+{
+if (MODESEGMENT) {
I'm a bit confused here - MODESEGMENT will always be true. Also, this
code doesn't need to be in stacks.c - just invoke call32() directly
from handle_1abb().
Will adapt it to that.
Other code was checking the MODESEGMENT and so I thought I better do
that, too.
Also, as before, just do if (!CONFIG_TCGBIOS) return; instead of the
#ifdef.
Did that.
Stefan
-Kevin
[Qemu-devel] [PATCH 10/15] s390x: helper functions for system emulation
When running system emulation, we need to transverse through the MMU and
deliver interrupts according to the specification.
This patch implements those two pieces and in addition adjusts the CPU
initialization code to account for the new fields in CPUState.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- new clock syntax
---
target-s390x/helper.c | 581 -
1 files changed, 571 insertions(+), 10 deletions(-)
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 4a5297b..bae3adb 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -2,6 +2,7 @@
* S/390 helpers
*
* Copyright (c) 2009 Ulrich Hecht
+ * Copyright (c) 2011 Alexander Graf
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -25,27 +26,108 @@
#include exec-all.h
#include gdbstub.h
#include qemu-common.h
+#include qemu-timer.h
+#if !defined(CONFIG_USER_ONLY)
#include linux/kvm.h
#include kvm.h
+#endif
+
+//#define S390_PTE_PRINTF_HACK
+//#define DEBUG_S390
+//#define DEBUG_S390_PTE
+//#define DEBUG_S390_STDOUT
+
+#ifdef DEBUG_S390
+#ifdef DEBUG_S390_STDOUT
+#define dprintf(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); \
+ qemu_log(fmt, ##__VA_ARGS__); } while (0)
+#else
+#define dprintf(fmt, ...) \
+do { qemu_log(fmt, ## __VA_ARGS__); } while (0)
+#endif
+#else
+#define dprintf(fmt, ...) \
+do { } while (0)
+#endif
+
+#ifdef DEBUG_S390_PTE
+#define pte_dprintf dprintf
+#else
+#define pte_dprintf(fmt, ...) \
+do { } while (0)
+#endif
+
+#ifndef CONFIG_USER_ONLY
+static void s390x_tod_timer(void *opaque)
+{
+CPUState *env = opaque;
+
+env-pending_int |= INTERRUPT_TOD;
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+}
+
+static void s390x_cpu_timer(void *opaque)
+{
+CPUState *env = opaque;
+
+env-pending_int |= INTERRUPT_CPUTIMER;
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+}
+#endif
CPUS390XState *cpu_s390x_init(const char *cpu_model)
{
CPUS390XState *env;
+#if !defined (CONFIG_USER_ONLY)
+struct tm tm;
+#endif
static int inited = 0;
+static int cpu_num = 0;
env = qemu_mallocz(sizeof(CPUS390XState));
cpu_exec_init(env);
if (!inited) {
inited = 1;
+s390x_translate_init();
}
+#if !defined(CONFIG_USER_ONLY)
+qemu_get_timedate(tm, 0);
+env-tod_offset = TOD_UNIX_EPOCH +
+ (time2tod(mktimegm(tm)) * 10ULL);
+env-tod_basetime = 0;
+env-tod_timer = qemu_new_timer_ns(vm_clock, s390x_tod_timer, env);
+env-cpu_timer = qemu_new_timer_ns(vm_clock, s390x_cpu_timer, env);
+#endif
env-cpu_model_str = cpu_model;
+env-cpu_num = cpu_num++;
+env-ext_index = -1;
cpu_reset(env);
qemu_init_vcpu(env);
return env;
}
+#if defined(CONFIG_USER_ONLY)
+
+void do_interrupt (CPUState *env)
+{
+env-exception_index = -1;
+}
+
+int cpu_s390x_handle_mmu_fault (CPUState *env, target_ulong address, int rw,
+ int mmu_idx, int is_softmmu)
+{
+/* fprintf(stderr,%s: address 0x%lx rw %d mmu_idx %d is_softmmu %d\n,
+__FUNCTION__, address, rw, mmu_idx, is_softmmu); */
+env-exception_index = EXCP_ADDR;
+env-__excp_addr = address; /* FIXME: find out how this works on a real
machine */
+return 1;
+}
+
+#endif /* CONFIG_USER_ONLY */
+
void cpu_reset(CPUS390XState *env)
{
if (qemu_loglevel_mask(CPU_LOG_RESET)) {
@@ -53,32 +135,511 @@ void cpu_reset(CPUS390XState *env)
log_cpu_state(env, 0);
}
-memset(env, 0, offsetof(CPUS390XState, breakpoints));
+memset(env, 0, offsetof(CPUS390XState, cpu_num));
/* FIXME: reset vector? */
tlb_flush(env, 1);
}
-target_phys_addr_t cpu_get_phys_page_debug(CPUState *env, target_ulong addr)
+#ifndef CONFIG_USER_ONLY
+
+/* Ensure to exit the TB after this call! */
+static void trigger_pgm_exception(CPUState *env, uint32_t code, uint32_t ilc)
+{
+env-exception_index = EXCP_PGM;
+env-int_pgm_code = code;
+env-int_pgm_ilc = ilc;
+}
+
+static int trans_bits(CPUState *env, uint64_t mode)
+{
+int bits = 0;
+
+switch (mode) {
+case PSW_ASC_PRIMARY:
+bits = 1;
+break;
+case PSW_ASC_SECONDARY:
+bits = 2;
+break;
+case PSW_ASC_HOME:
+bits = 3;
+break;
+default:
+cpu_abort(env, unknown asc mode\n);
+break;
+}
+
+return bits;
+}
+
+static void trigger_prot_fault(CPUState *env, target_ulong vaddr, uint64_t
mode)
+{
+int ilc = ILC_LATER_INC_2;
+int bits = trans_bits(env, mode) | 4;
+
+dprintf(%s: vaddr=%016 PRIx64 bits=%d\n, __FUNCTION__, vaddr, bits);
+#ifdef S390_PTE_PRINTF_HACK
+fprintf(stderr, %s: vaddr=%016 PRIx64 bits=%d\n, __FUNCTION__, vaddr,
bits);
+#endif
+
+stq_phys(env-psa + offsetof(LowCore, trans_exc_code), vaddr | bits);
+trigger_pgm_exception(env,
[Qemu-devel] Re: [PATCH] spapr_vscsi: Set uninitialized variable
On 04/03/2011 06:21 PM, Stefan Weil wrote:
cppcheck reports this error:
hw/spapr_vscsi.c:274: error: Uninitialized variable: rc
If llen == 0, rc was indeed used without being initialized.
Signed-off-by: Stefan Weilw...@mail.berlios.de
---
hw/spapr_vscsi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/spapr_vscsi.c b/hw/spapr_vscsi.c
index e142dae..9928334 100644
--- a/hw/spapr_vscsi.c
+++ b/hw/spapr_vscsi.c
@@ -255,7 +255,7 @@ static int vscsi_srp_direct_data(VSCSIState *s, vscsi_req
*req,
{
struct srp_direct_buf *md = req-cur_desc;
uint32_t llen;
-int rc;
+int rc = 0;
David, is this correct? Or would rc be -1 when !llen?
Alex
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/2011 09:26 AM, Daniel P. Berrange wrote: On Mon, Apr 04, 2011 at 09:19:36AM -0500, Anthony Liguori wrote: On 04/04/2011 08:16 AM, Daniel P. Berrange wrote: That doesn't really have any impact. If a desktop user is logged in, udev may change the ownership to match that user, but if they aren't, then udev may reset it to root:disk. Either way, QEMU may loose permissions to the disk. Then if you create a guest without being in the 'disk' group, it'll fail. That's pretty expected AFAICT. We don't *ever* want to put QEMU in the 'disk' group because that gives it access to any disk on the system in general. If that's what the user wants to do, what's the problem with doing it? Setting the global user/group is not enough because just because you have one VM that you want in disk doesn't mean you want all of them in disk. And to be clear, if you could do this today, there wouldn't be a problem here in terms of QEMU just reopening the file. Regards, Anthony Liguori Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
On 04/04/11 16:42, Peter Maydell wrote: On 4 April 2011 15:29, Jes Sorensen jes.soren...@redhat.com wrote: Yes, I agree, so we shouldn't try to specify some complicated set of static data that still won't be good enough. I'm trying to make it easy for boards to avoid crashing horribly when the user passes a bad value; that's all. If you don't validate properly, is there really a point in introducing that value anyway? From what you write, it sounds like it can still fail for some limits of the memory valid if the config is wrong? For the boards I care about (the ARM ones), the only validation requirement is that we don't allow the user to specify so much ram that we overlap physical RAM with I/O space. So ram_size is good enough. For the sun4m boards we can assume that the only validation they need is a ram_size check, because that's all they do at the moment and nobody's complaining that I know of. I understand that what you are proposing seems to work well enough for your problem at hand. What I am saying is that adding a mechanism like that, can cause problems for adding a more generic mechanism that handles more advanced boards in the future. I much prefer a generic solution than a simple hack. It still seems to me it would be better to have the boards present a table of valid memory ranges so we can do a proper validation of the valud? If you have a concrete example of multiple boards which we currently model and which require this level of flexibility to avoid odd misbehaviour trying to run a guest, then please point them out and I'll look at expanding the patch to cover their requirements. If this is just a theoretical issue, then I think we should only add the extra generic framework code if and when we turn out to need it. As I pointed out before, this is not a theoretical problem, most numa systems have this issue, including many x86 boxes. I can see the problem also existing with mips boards like the sb1250 ones I worked on many years ago. Having an a table of valid ram locations for a board, will also give you a framework to validate against if you want to be able to specify chunks of memory at different areas of a board. This could be useful for testing behavior that is like it would be if you have a system where installing different DIMMs would split the RAM up differently. Jes
[Qemu-devel] [PATCH 00/10] pci: pci_register_bar_simple
Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially. This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right. Avi Kivity (10): pci: add pci_register_bar_simple() API rtl8139: convert to pci_register_bar_simple() cirrus-vga: convert to pci_register_bar_simple() eepro100: convert to pci_register_bar_simple() ich/ahci: convert to pci_register_bar_simple() hda-intel: convert to pci_register_bar_simple() hda-intel: convert to pci_register_bar_simple() (partial) pcnet-pci: convert to pci_register_bar_simple() usb-ohci: convert to pci_register_bar_simple() wdt_i6300esb: convert to pci_register_bar_simple() hw/cirrus_vga.c | 13 ++--- hw/eepro100.c | 43 +-- hw/ide/ahci.c |9 - hw/ide/ahci.h |3 --- hw/ide/ich.c |3 +-- hw/intel-hda.c| 11 +-- hw/lsi53c895a.c | 12 +--- hw/pci.c | 17 + hw/pci.h |3 +++ hw/pcnet-pci.c| 16 +--- hw/rtl8139.c | 11 +-- hw/usb-ohci.c | 10 +- hw/wdt_i6300esb.c | 42 +++--- 13 files changed, 56 insertions(+), 137 deletions(-)
[Qemu-devel] [PATCH 09/10] usb-ohci: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/usb-ohci.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index d2b14f7..73d47b8 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1713,13 +1713,6 @@ typedef struct {
OHCIState state;
} OHCIPCIState;
-static void ohci_mapfunc(PCIDevice *pci_dev, int i,
-pcibus_t addr, pcibus_t size, int type)
-{
-OHCIPCIState *ohci = DO_UPCAST(OHCIPCIState, pci_dev, pci_dev);
-cpu_register_physical_memory(addr, size, ohci-state.mem);
-}
-
static int usb_ohci_initfn_pci(struct PCIDevice *dev)
{
OHCIPCIState *ohci = DO_UPCAST(OHCIPCIState, pci_dev, dev);
@@ -1737,8 +1730,7 @@ static int usb_ohci_initfn_pci(struct PCIDevice *dev)
ohci-state.irq = ohci-pci_dev.irq[0];
/* TODO: avoid cast below by using dev */
-pci_register_bar(ohci-pci_dev, 0, 256,
- PCI_BASE_ADDRESS_SPACE_MEMORY, ohci_mapfunc);
+pci_register_bar_simple(ohci-pci_dev, 0, 256, 0, ohci-state.mem);
return 0;
}
--
1.7.1
[Qemu-devel] [PATCH 05/10] ich/ahci: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/ide/ahci.c |9 -
hw/ide/ahci.h |3 ---
hw/ide/ich.c |3 +--
3 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 98bdf70..c6e0c77 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -1129,15 +1129,6 @@ void ahci_uninit(AHCIState *s)
qemu_free(s-dev);
}
-void ahci_pci_map(PCIDevice *pci_dev, int region_num,
-pcibus_t addr, pcibus_t size, int type)
-{
-struct AHCIPCIState *d = (struct AHCIPCIState *)pci_dev;
-AHCIState *s = d-ahci;
-
-cpu_register_physical_memory(addr, size, s-mem);
-}
-
void ahci_reset(void *opaque)
{
struct AHCIPCIState *d = opaque;
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index a4560c4..dc86951 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -325,9 +325,6 @@ typedef struct NCQFrame {
void ahci_init(AHCIState *s, DeviceState *qdev, int ports);
void ahci_uninit(AHCIState *s);
-void ahci_pci_map(PCIDevice *pci_dev, int region_num,
-pcibus_t addr, pcibus_t size, int type);
-
void ahci_reset(void *opaque);
#endif /* HW_IDE_AHCI_H */
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index f242d7a..eb00f03 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -95,8 +95,7 @@ static int pci_ich9_ahci_init(PCIDevice *dev)
qemu_register_reset(ahci_reset, d);
/* XXX BAR size should be 1k, but that breaks, so bump it to 4k for now */
-pci_register_bar(d-card, 5, 0x1000, PCI_BASE_ADDRESS_SPACE_MEMORY,
- ahci_pci_map);
+pci_register_bar_simple(d-card, 5, 0x1000, 0, d-ahci.mem);
msi_init(dev, 0x50, 1, true, false);
--
1.7.1
[Qemu-devel] [PATCH 03/10] cirrus-vga: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/cirrus_vga.c | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 2724f7b..ff78335 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3076,15 +3076,6 @@ static void cirrus_pci_lfb_map(PCIDevice *d, int
region_num,
vga_dirty_log_start(s-vga);
}
-static void cirrus_pci_mmio_map(PCIDevice *d, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-CirrusVGAState *s = DO_UPCAST(PCICirrusVGAState, dev, d)-cirrus_vga;
-
-cpu_register_physical_memory(addr, CIRRUS_PNPMMIO_SIZE,
-s-cirrus_mmio_io_addr);
-}
-
static void pci_cirrus_write_config(PCIDevice *d,
uint32_t address, uint32_t val, int len)
{
@@ -3123,8 +3114,8 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
pci_register_bar(d-dev, 0, 0x200,
PCI_BASE_ADDRESS_MEM_PREFETCH, cirrus_pci_lfb_map);
if (device_id == CIRRUS_ID_CLGD5446) {
- pci_register_bar(d-dev, 1, CIRRUS_PNPMMIO_SIZE,
- PCI_BASE_ADDRESS_SPACE_MEMORY, cirrus_pci_mmio_map);
+ pci_register_bar_simple(d-dev, 1, CIRRUS_PNPMMIO_SIZE, 0,
+ s-cirrus_mmio_io_addr);
}
return 0;
}
--
1.7.1
[Qemu-devel] [PATCH 04/10] eepro100: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/eepro100.c | 43 +--
1 files changed, 13 insertions(+), 30 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index edf48f6..f2505e4 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -228,7 +228,7 @@ typedef struct {
uint8_t scb_stat; /* SCB stat/ack byte */
uint8_t int_stat; /* PCI interrupt status */
/* region must not be saved by nic_save. */
-uint32_t region[3]; /* PCI region addresses */
+uint32_t region1; /* PCI region 1 address */
uint16_t mdimem[32];
eeprom_t *eeprom;
uint32_t device;/* device variant */
@@ -1488,19 +1488,19 @@ static uint32_t ioport_read1(void *opaque, uint32_t
addr)
#if 0
logout(addr=%s\n, regname(addr));
#endif
-return eepro100_read1(s, addr - s-region[1]);
+return eepro100_read1(s, addr - s-region1);
}
static uint32_t ioport_read2(void *opaque, uint32_t addr)
{
EEPRO100State *s = opaque;
-return eepro100_read2(s, addr - s-region[1]);
+return eepro100_read2(s, addr - s-region1);
}
static uint32_t ioport_read4(void *opaque, uint32_t addr)
{
EEPRO100State *s = opaque;
-return eepro100_read4(s, addr - s-region[1]);
+return eepro100_read4(s, addr - s-region1);
}
static void ioport_write1(void *opaque, uint32_t addr, uint32_t val)
@@ -1509,19 +1509,19 @@ static void ioport_write1(void *opaque, uint32_t addr,
uint32_t val)
#if 0
logout(addr=%s val=0x%02x\n, regname(addr), val);
#endif
-eepro100_write1(s, addr - s-region[1], val);
+eepro100_write1(s, addr - s-region1, val);
}
static void ioport_write2(void *opaque, uint32_t addr, uint32_t val)
{
EEPRO100State *s = opaque;
-eepro100_write2(s, addr - s-region[1], val);
+eepro100_write2(s, addr - s-region1, val);
}
static void ioport_write4(void *opaque, uint32_t addr, uint32_t val)
{
EEPRO100State *s = opaque;
-eepro100_write4(s, addr - s-region[1], val);
+eepro100_write4(s, addr - s-region1, val);
}
/***/
@@ -1544,7 +1544,7 @@ static void pci_map(PCIDevice * pci_dev, int region_num,
register_ioport_write(addr, size, 4, ioport_write4, s);
register_ioport_read(addr, size, 4, ioport_read4, s);
-s-region[region_num] = addr;
+s-region1 = addr;
}
/*
@@ -1619,22 +1619,6 @@ static CPUReadMemoryFunc * const pci_mmio_read[] = {
pci_mmio_readl
};
-static void pci_mmio_map(PCIDevice * pci_dev, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
-
-TRACE(OTHER, logout(region %d, addr=0x%08FMT_PCIBUS,
- size=0x%08FMT_PCIBUS, type=%d\n,
- region_num, addr, size, type));
-
-assert(region_num == 0 || region_num == 2);
-
-/* Map control / status registers and flash. */
-cpu_register_physical_memory(addr, size, s-mmio_index);
-s-region[region_num] = addr;
-}
-
static int nic_can_receive(VLANClientState *nc)
{
EEPRO100State *s = DO_UPCAST(NICState, nc, nc)-opaque;
@@ -1882,17 +1866,16 @@ static int e100_nic_init(PCIDevice *pci_dev)
cpu_register_io_memory(pci_mmio_read, pci_mmio_write, s,
DEVICE_NATIVE_ENDIAN);
-pci_register_bar(s-dev, 0, PCI_MEM_SIZE,
- PCI_BASE_ADDRESS_SPACE_MEMORY |
- PCI_BASE_ADDRESS_MEM_PREFETCH, pci_mmio_map);
+pci_register_bar_simple(s-dev, 0, PCI_MEM_SIZE,
+PCI_BASE_ADDRESS_MEM_PREFETCH, s-mmio_index);
+
pci_register_bar(s-dev, 1, PCI_IO_SIZE, PCI_BASE_ADDRESS_SPACE_IO,
pci_map);
-pci_register_bar(s-dev, 2, PCI_FLASH_SIZE, PCI_BASE_ADDRESS_SPACE_MEMORY,
- pci_mmio_map);
+pci_register_bar_simple(s-dev, 2, PCI_FLASH_SIZE, 0, s-mmio_index);
qemu_macaddr_default_if_unset(s-conf.macaddr);
logout(macaddr: %s\n, nic_dump(s-conf.macaddr.a[0], 6));
-assert(s-region[1] == 0);
+assert(s-region1 == 0);
nic_reset(s);
--
1.7.1
[Qemu-devel] [PATCH 08/10] pcnet-pci: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/pcnet-pci.c | 16 +---
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c
index 339a401..4ac3e32 100644
--- a/hw/pcnet-pci.c
+++ b/hw/pcnet-pci.c
@@ -214,19 +214,6 @@ static CPUReadMemoryFunc * const pcnet_mmio_read[] = {
pcnet_mmio_readl
};
-static void pcnet_mmio_map(PCIDevice *pci_dev, int region_num,
-pcibus_t addr, pcibus_t size, int type)
-{
-PCIPCNetState *d = DO_UPCAST(PCIPCNetState, pci_dev, pci_dev);
-
-#ifdef PCNET_DEBUG_IO
-printf(pcnet_mmio_map addr=0x%08FMT_PCIBUS 0x%08FMT_PCIBUS\n,
- addr, size);
-#endif
-
-cpu_register_physical_memory(addr, PCNET_PNPMMIO_SIZE,
d-state.mmio_index);
-}
-
static void pci_physical_memory_write(void *dma_opaque, target_phys_addr_t
addr,
uint8_t *buf, int len, int do_bswap)
{
@@ -300,8 +287,7 @@ static int pci_pcnet_init(PCIDevice *pci_dev)
pci_register_bar(pci_dev, 0, PCNET_IOPORT_SIZE,
PCI_BASE_ADDRESS_SPACE_IO, pcnet_ioport_map);
-pci_register_bar(pci_dev, 1, PCNET_PNPMMIO_SIZE,
- PCI_BASE_ADDRESS_SPACE_MEMORY, pcnet_mmio_map);
+pci_register_bar_simple(pci_dev, 1, PCNET_PNPMMIO_SIZE, 0, s-mmio_index);
s-irq = pci_dev-irq[0];
s-phys_mem_read = pci_physical_memory_read;
--
1.7.1
[Qemu-devel] [PATCH 01/10] pci: add pci_register_bar_simple() API
This is similar to pci_register_bar(), but automatically registers a single
memory region spanning the entire BAR.
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/pci.c | 17 +
hw/pci.h |3 +++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 6b577e1..65ae196 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -859,6 +859,7 @@ void pci_register_bar(PCIDevice *pci_dev, int region_num,
r-filtered_size = size;
r-type = type;
r-map_func = map_func;
+r-ram_addr = IO_MEM_UNASSIGNED;
wmask = ~(size - 1);
addr = pci_bar(pci_dev, region_num);
@@ -877,6 +878,22 @@ void pci_register_bar(PCIDevice *pci_dev, int region_num,
}
}
+static void pci_simple_bar_mapfunc(PCIDevice *pci_dev, int region_num,
+ pcibus_t addr, pcibus_t size, int type)
+{
+cpu_register_physical_memory(addr, size,
+ pci_dev-io_regions[region_num].ram_addr);
+}
+
+void pci_register_bar_simple(PCIDevice *pci_dev, int region_num,
+ pcibus_t size, uint8_t attr, ram_addr_t ram_addr)
+{
+pci_register_bar(pci_dev, region_num, size,
+ PCI_BASE_ADDRESS_SPACE_MEMORY | attr,
+ pci_simple_bar_mapfunc);
+pci_dev-io_regions[region_num].ram_addr = ram_addr;
+}
+
static void pci_bridge_filter(PCIDevice *d, pcibus_t *addr, pcibus_t *size,
uint8_t type)
{
diff --git a/hw/pci.h b/hw/pci.h
index 52ee8c9..3230764 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -92,6 +92,7 @@ typedef struct PCIIORegion {
pcibus_t filtered_size;
uint8_t type;
PCIMapIORegionFunc *map_func;
+ram_addr_t ram_addr;
} PCIIORegion;
#define PCI_ROM_SLOT 6
@@ -200,6 +201,8 @@ PCIDevice *pci_register_device(PCIBus *bus, const char
*name,
void pci_register_bar(PCIDevice *pci_dev, int region_num,
pcibus_t size, uint8_t type,
PCIMapIORegionFunc *map_func);
+void pci_register_bar_simple(PCIDevice *pci_dev, int region_num,
+ pcibus_t size, uint8_t attr, ram_addr_t ram_addr);
int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
uint8_t offset, uint8_t size);
--
1.7.1
[Qemu-devel] [PATCH 02/10] rtl8139: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/rtl8139.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index d545933..822038d 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3341,14 +3341,6 @@ static const VMStateDescription vmstate_rtl8139 = {
/***/
/* PCI RTL8139 definitions */
-static void rtl8139_mmio_map(PCIDevice *pci_dev, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-RTL8139State *s = DO_UPCAST(RTL8139State, dev, pci_dev);
-
-cpu_register_physical_memory(addr + 0, 0x100, s-rtl8139_mmio_io_addr);
-}
-
static void rtl8139_ioport_map(PCIDevice *pci_dev, int region_num,
pcibus_t addr, pcibus_t size, int type)
{
@@ -3444,8 +3436,7 @@ static int pci_rtl8139_init(PCIDevice *dev)
pci_register_bar(s-dev, 0, 0x100,
PCI_BASE_ADDRESS_SPACE_IO, rtl8139_ioport_map);
-pci_register_bar(s-dev, 1, 0x100,
- PCI_BASE_ADDRESS_SPACE_MEMORY, rtl8139_mmio_map);
+pci_register_bar_simple(s-dev, 1, 0x100, 0, s-rtl8139_mmio_io_addr);
qemu_macaddr_default_if_unset(s-conf.macaddr);
--
1.7.1
[Qemu-devel] [PATCH 06/10] hda-intel: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/intel-hda.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/hw/intel-hda.c b/hw/intel-hda.c
index b0b1d12..7f83745 100644
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -1109,14 +1109,6 @@ static CPUWriteMemoryFunc * const
intel_hda_mmio_write[3] = {
intel_hda_mmio_writel,
};
-static void intel_hda_map(PCIDevice *pci, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-IntelHDAState *d = DO_UPCAST(IntelHDAState, pci, pci);
-
-cpu_register_physical_memory(addr, 0x4000, d-mmio_addr);
-}
-
/* - */
static void intel_hda_reset(DeviceState *dev)
@@ -1158,8 +1150,7 @@ static int intel_hda_init(PCIDevice *pci)
d-mmio_addr = cpu_register_io_memory(intel_hda_mmio_read,
intel_hda_mmio_write, d,
DEVICE_NATIVE_ENDIAN);
-pci_register_bar(d-pci, 0, 0x4000, PCI_BASE_ADDRESS_SPACE_MEMORY,
- intel_hda_map);
+pci_register_bar_simple(d-pci, 0, 0x4000, 0, d-mmio_addr);
if (d-msi) {
msi_init(d-pci, 0x50, 1, true, false);
}
--
1.7.1
[Qemu-devel] [PATCH 10/10] wdt_i6300esb: convert to pci_register_bar_simple()
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/wdt_i6300esb.c | 42 +++---
1 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/hw/wdt_i6300esb.c b/hw/wdt_i6300esb.c
index 4a7fba7..0791721 100644
--- a/hw/wdt_i6300esb.c
+++ b/hw/wdt_i6300esb.c
@@ -355,31 +355,6 @@ static void i6300esb_mem_writel(void *vp,
target_phys_addr_t addr, uint32_t val)
}
}
-static void i6300esb_map(PCIDevice *dev, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-static CPUReadMemoryFunc * const mem_read[3] = {
-i6300esb_mem_readb,
-i6300esb_mem_readw,
-i6300esb_mem_readl,
-};
-static CPUWriteMemoryFunc * const mem_write[3] = {
-i6300esb_mem_writeb,
-i6300esb_mem_writew,
-i6300esb_mem_writel,
-};
-I6300State *d = DO_UPCAST(I6300State, dev, dev);
-int io_mem;
-
-i6300esb_debug(addr = %FMT_PCIBUS, size = %FMT_PCIBUS, type = %d\n,
- addr, size, type);
-
-io_mem = cpu_register_io_memory(mem_read, mem_write, d,
-DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory (addr, 0x10, io_mem);
-/* qemu_register_coalesced_mmio (addr, 0x10); ? */
-}
-
static const VMStateDescription vmstate_i6300esb = {
.name = i6300esb_wdt,
.version_id = sizeof(I6300State),
@@ -407,6 +382,17 @@ static int i6300esb_init(PCIDevice *dev)
{
I6300State *d = DO_UPCAST(I6300State, dev, dev);
uint8_t *pci_conf;
+int io_mem;
+static CPUReadMemoryFunc * const mem_read[3] = {
+i6300esb_mem_readb,
+i6300esb_mem_readw,
+i6300esb_mem_readl,
+};
+static CPUWriteMemoryFunc * const mem_write[3] = {
+i6300esb_mem_writeb,
+i6300esb_mem_writew,
+i6300esb_mem_writel,
+};
i6300esb_debug(I6300State = %p\n, d);
@@ -418,8 +404,10 @@ static int i6300esb_init(PCIDevice *dev)
pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_INTEL_ESB_9);
pci_config_set_class(pci_conf, PCI_CLASS_SYSTEM_OTHER);
-pci_register_bar(d-dev, 0, 0x10,
-PCI_BASE_ADDRESS_SPACE_MEMORY, i6300esb_map);
+io_mem = cpu_register_io_memory(mem_read, mem_write, d,
+DEVICE_NATIVE_ENDIAN);
+pci_register_bar_simple(d-dev, 0, 0x10, 0, io_mem);
+/* qemu_register_coalesced_mmio (addr, 0x10); ? */
return 0;
}
--
1.7.1
[Qemu-devel] Re: [PATCH] cpu-all.h: Remove unnecessary target-specific ifdef for CPU_QuadU
On 4 April 2011 15:47, Alexander Graf ag...@suse.de wrote: On 04/04/2011 01:09 PM, Peter Maydell wrote: CPU_QuadU isn't used on all targets, but there's no harm in defining the typedef anyway. It only needs to be guarded by CONFIG_SOFTFLOAT, because softfloat-native doesn't have a float128 type. This avoids the need for every new target which uses CPU_QuadU to add itself to an #ifdef in what ought to be target-agnostic code. Signed-off-by: Peter Maydellpeter.mayd...@linaro.org I don't really know my way around FP, but from here it looks good :). Not sure about the arm part, but I trust Peter on that one ;). The __arm__ part of the ifdef was a voodoo-copy from the CPU_DoubleU typedef, where it actually does matter if you're building a softfloat-native target on an ARM host which uses the ancient FPA floating point ABI (as the comment says, although ARM is generally little-endian doubles are stored in memory in big-endian order under FPA; the more modern VFP has them little-endian). This ifdef condition was meaningless for CPU_QuadU (because FPA didn't have a 128 bit native float type for the type to try to be compatible with) and could never have kicked in anyhow because we wouldn't have compiled unless CONFIG_SOFTFLOAT was defined. -- PMM
[Qemu-devel] [PATCH 07/10] hda-intel: convert to pci_register_bar_simple() (partial)
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/lsi53c895a.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index e4b51a8..be4df58 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -2094,15 +2094,6 @@ static void lsi_ram_mapfunc(PCIDevice *pci_dev, int
region_num,
cpu_register_physical_memory(addr + 0, 0x2000, s-ram_io_addr);
}
-static void lsi_mmio_mapfunc(PCIDevice *pci_dev, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-LSIState *s = DO_UPCAST(LSIState, dev, pci_dev);
-
-DPRINTF(Mapping registers at %08FMT_PCIBUS\n, addr);
-cpu_register_physical_memory(addr + 0, 0x400, s-mmio_io_addr);
-}
-
static void lsi_scsi_reset(DeviceState *dev)
{
LSIState *s = DO_UPCAST(LSIState, dev.qdev, dev);
@@ -2245,8 +2236,7 @@ static int lsi_scsi_init(PCIDevice *dev)
pci_register_bar(s-dev, 0, 256,
PCI_BASE_ADDRESS_SPACE_IO, lsi_io_mapfunc);
-pci_register_bar(s-dev, 1, 0x400,
- PCI_BASE_ADDRESS_SPACE_MEMORY, lsi_mmio_mapfunc);
+pci_register_bar_simple(s-dev, 1, 0x400, 0, s-mmio_io_addr);
pci_register_bar(s-dev, 2, 0x2000,
PCI_BASE_ADDRESS_SPACE_MEMORY, lsi_ram_mapfunc);
QTAILQ_INIT(s-queue);
--
1.7.1
Re: [Qemu-devel] [PATCH] docs/specs/fw_cfg.txt: Add fw_cfg documentation
On Mon, Apr 4, 2011 at 9:46 AM, Jordan Justen jljus...@gmail.com wrote: This initial version covers the generic portions of fw_cfg and the x86/x86-64 architecture specific portions of fw_cfg. Signed-off-by: Jordan Justen jljus...@gmail.com --- docs/specs/fw_cfg.txt | 168 + 1 files changed, 168 insertions(+), 0 deletions(-) create mode 100644 docs/specs/fw_cfg.txt diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt new file mode 100644 index 000..554ac48 --- /dev/null +++ b/docs/specs/fw_cfg.txt @@ -0,0 +1,168 @@ + += Hardware Interface = + +== Index Port == +* Two bytes in width (guest native endianness) +* Write only +* Can be an I/O port and/or Memory-Mapped I/O +* Location is platform dependent + +A write to this port sets the index of a firmware configuration item +which can subsequently be accessed at the data port. + +Setting the index port will cause the data offset to be set to zero. +The data offset impacts which data is accessed via the data port, and +is explained below. + +Bit15 of the index value indicates if the configuration setting is +architecture specific. If bit15 of the index is 0, then the item is +a generic configuration item. If bit15 of the index is 1, then the +item is specific to a particular architecture. (In other words, +generic configuration items are accessed when the index is between +0x-0x7fff, and architecture specific configuration items are +accessed when the index is between 0x8000-0x.) + +Bit14 of the index value indicates if the configuration setting is +being written. If bit14 of the index is 0, then the item is only +being read, and all write access to the data port will be completely +ignored. If bit14 of the index is 1, then the item's data can be +written to by writing to the data port. (In other words, +configuration write mode is enabled when the index is between +0x4000-0x7fff or 0xc000-0x.) + +== Data Port == +* One byte in width +* Read + Write +* Can be an I/O port and/or Memory-Mapped I/O +* Location is platform dependent + +The data port allows for access to an array of bytes for each firmware +configuration data item. This item is selected by a write to the +index port. + +Initially following a write to the index port, the data offset will +be set to zero. Each successful read or write to the data port will +cause the data offset to increment by one byte. There is only one +data offset value, and it will be incremented by accesses to any of +the I/O or MMIO data ports. A write access will not increment the +data offset if the selected index did not have bit14 set. + +Each firmware configuration item has a maximum length of data +associated with the item. After the data offset has passed the +end of this maximum data length, then any reads will return a data +value of 0x00, and all writes will be ignored. + +A read of the data port will return the current byte of the firmware +configuration item. + +A write of the data port will set the current byte of the firmware +configuration item. A write access will not impact the firmware +configuration data if the selected index did not have bit14 set. + +== x86, x86-64 Ports == + +I/O Index Port: 0x510 +I/O Data Port: 0x511 +MMIO Index Port: N/A +MMIO Data Port: N/A This also applies to sun4u. PPC uses MMIO 0xf51[01] and sun4m 0xd051[01]. Other architectures don't use the device. + += Firmware Configuration Items = + +== Ranges == + +There are up to 0x4000 generic firmware configuration items, and up to +0x4000 architecturally specific firmware configuration items. + +Index Port Range Range Usage + --- +0x - 0x3fff Generic Items (0x - 0x3fff) (Read-only) +0x4000 - 0x7fff Generic Items (0x - 0x3fff) (Read+Write) +0x8000 - 0xbfff Architecture Specific Items (0x - 0x3fff) (Read-only) +0xc000 - 0x Architecture Specific Items (0x - 0x3fff) (Read+Write) + +== Data Items Format == + +uint8_t : 8-bit unsigned integer +uint16_t: 16-bit unsigned integer +uint32_t: 32-bit unsigned integer +uint64_t: 64-bit unsigned integer +n bytes : byte array of length n +array : byte array of a format specific size +string : null byte terminated ascii string + +All integer data is accessed with the least significant byte first and +then proceeding to more significant bytes on subsequent accesses. Due to properties of little endian data and because QEMU supplies zeros for out of range access, any integers are automatically zero extended. It is possible for BIOS to read 64 bit integers even when QEMU supplies 32 bit data (but vice versa will not work). So I wouldn't emphasize the data sizes. + +== Generic Items == + +Index Data Type Data Meaning +- - +0x00 4 bytes Signature - 'Q', 'E', 'M', 'U' +0x01 uint32_t ID This is
[Qemu-devel] Re: [PATCH 00/10] pci: pci_register_bar_simple
On 04/04/2011 06:59 PM, Michael S. Tsirkin wrote: On Mon, Apr 04, 2011 at 06:27:57PM +0300, Avi Kivity wrote: Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially. This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right. This will save some code, so Acked-by: Michael S. Tsirkinm...@redhat.com I really hope the rest of devices will follow. Do you see more devices which can be converted to this API? AFAICT, the others will need something more complicated. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [PATCH 00/10] pci: pci_register_bar_simple
On 04/04/2011 10:59 AM, Michael S. Tsirkin wrote: On Mon, Apr 04, 2011 at 06:27:57PM +0300, Avi Kivity wrote: Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially. This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right. This will save some code, so Acked-by: Michael S. Tsirkinm...@redhat.com I really hope the rest of devices will follow. How complete is this? From a couple of quick greps, it looks like this covers most everything that it can. Acked-by: Anthony Liguori aligu...@us.ibm.com Regards, Anthony Liguori Avi Kivity (10): pci: add pci_register_bar_simple() API rtl8139: convert to pci_register_bar_simple() cirrus-vga: convert to pci_register_bar_simple() eepro100: convert to pci_register_bar_simple() ich/ahci: convert to pci_register_bar_simple() hda-intel: convert to pci_register_bar_simple() hda-intel: convert to pci_register_bar_simple() (partial) pcnet-pci: convert to pci_register_bar_simple() usb-ohci: convert to pci_register_bar_simple() wdt_i6300esb: convert to pci_register_bar_simple() hw/cirrus_vga.c | 13 ++--- hw/eepro100.c | 43 +-- hw/ide/ahci.c |9 - hw/ide/ahci.h |3 --- hw/ide/ich.c |3 +-- hw/intel-hda.c| 11 +-- hw/lsi53c895a.c | 12 +--- hw/pci.c | 17 + hw/pci.h |3 +++ hw/pcnet-pci.c| 16 +--- hw/rtl8139.c | 11 +-- hw/usb-ohci.c | 10 +- hw/wdt_i6300esb.c | 42 +++--- 13 files changed, 56 insertions(+), 137 deletions(-)
Re: [Qemu-devel] Re: [PATCH 00/10] pci: pci_register_bar_simple
On 04/04/2011 07:22 PM, Anthony Liguori wrote: On 04/04/2011 10:59 AM, Michael S. Tsirkin wrote: On Mon, Apr 04, 2011 at 06:27:57PM +0300, Avi Kivity wrote: Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially. This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right. This will save some code, so Acked-by: Michael S. Tsirkinm...@redhat.com I really hope the rest of devices will follow. How complete is this? I converted all devices which were easy to convert. There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API). The rest likely need to stick with the callback-based API. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH V1 6/8] Add measurement code to the BIOS
On 04/04/2011 12:57 AM, Kevin O'Connor wrote:
On Wed, Mar 30, 2011 at 01:55:40PM -0400, Stefan Berger wrote:
This patch adds invocactions of functions that measure various parts of the
code and data through various parts of the BIOS code. It follows TCG
specifications on what needs to be measured. It also adds the implementation
of the called functions.
[...]
void VISIBLE32FLAT
startBoot(void)
{
+tcpa_calling_int19h();
+tcpa_add_event_separators();
Why add two functions here, instead of just one function that does
both actions?
I kept them separate since they're two different 'events', which would
allow to put another call in between, if another event was to be
measured - currently there is none. I'll combine the calls.
[...]
// Initialize tpm (after acpi tables were written)
tcpa_acpi_init();
tcpa_startup();
+tcpa_measure_post((void *)0xE, (void *)0xF);
+tcpa_smbios_measure();
Same here. Also, I'm not sure I understand why you're measuring
0xE-0xF - if the intent is to measure the code, then it's a
bit more complicated as the init code has already been relocated by
this point.
Basically, I wanted to start the measuring as early as possible, ideally
measuring layers or functions sequentially, which turns out to be quite
'tricky'. So this was the brute force compromise. I'll drop it and will
start with the smbios measurement for now.
[...]
+tcpa_option_rom(FLATPTR_TO_SEG(rom), len);
You're better off just defining tcpa_option_rom() to take a regular
pointer.
Done.
[...]
+/* specs: 8.2.3 step 5 and 8.2.5.6, measure El Torito boot catalog */
+/* measure 2048 bytes (one sector) */
+tcpa_add_bootdevice(1, 0);
+tcpa_ipl(IPL_EL_TORITO_2, GET_SEG(SS), (u32)buffer, 2048);
Same here for tcpa_ipl(). GET_SEG() always returns 0 in 32bit mode
and this code is only run in 32bit mode.
Done.
[...]
+static struct smbios_entry_point *
+find_smbios_entry_point(void)
+{
The smbios table is built in smbios.c:smbios_entry_point_init() -
instead of scanning for the table, just record where the table is in a
global variable.
Done.
[...]
+u32
+tcpa_smbios_measure(void)
+{
+u32 rc;
+struct pcctes pcctes = {
+.eventid = 1, /* 10.4.2.3.1 */
+.eventdatasize = SHA1_BUFSIZE,
+};
+struct smbios_entry_point *sep = find_smbios_entry_point();
+
+if (!has_working_tpm())
+return 0;
BTW - SeaBIOS uses C99, so it's fine to move if (!has_working_tpm())
above the variable declarations.
I am moving all these checks above the var decls.
Stefan
-Kevin
[Qemu-devel] Re: [PATCH 00/10] pci: pci_register_bar_simple
On Mon, Apr 04, 2011 at 06:27:57PM +0300, Avi Kivity wrote: Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially. This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right. This will save some code, so Acked-by: Michael S. Tsirkin m...@redhat.com I really hope the rest of devices will follow. Avi Kivity (10): pci: add pci_register_bar_simple() API rtl8139: convert to pci_register_bar_simple() cirrus-vga: convert to pci_register_bar_simple() eepro100: convert to pci_register_bar_simple() ich/ahci: convert to pci_register_bar_simple() hda-intel: convert to pci_register_bar_simple() hda-intel: convert to pci_register_bar_simple() (partial) pcnet-pci: convert to pci_register_bar_simple() usb-ohci: convert to pci_register_bar_simple() wdt_i6300esb: convert to pci_register_bar_simple() hw/cirrus_vga.c | 13 ++--- hw/eepro100.c | 43 +-- hw/ide/ahci.c |9 - hw/ide/ahci.h |3 --- hw/ide/ich.c |3 +-- hw/intel-hda.c| 11 +-- hw/lsi53c895a.c | 12 +--- hw/pci.c | 17 + hw/pci.h |3 +++ hw/pcnet-pci.c| 16 +--- hw/rtl8139.c | 11 +-- hw/usb-ohci.c | 10 +- hw/wdt_i6300esb.c | 42 +++--- 13 files changed, 56 insertions(+), 137 deletions(-)
Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On Mon, Apr 4, 2011 at 5:43 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 04/04/2011 09:26 AM, Daniel P. Berrange wrote: On Mon, Apr 04, 2011 at 09:19:36AM -0500, Anthony Liguori wrote: On 04/04/2011 08:16 AM, Daniel P. Berrange wrote: That doesn't really have any impact. If a desktop user is logged in, udev may change the ownership to match that user, but if they aren't, then udev may reset it to root:disk. Either way, QEMU may loose permissions to the disk. Then if you create a guest without being in the 'disk' group, it'll fail. That's pretty expected AFAICT. We don't *ever* want to put QEMU in the 'disk' group because that gives it access to any disk on the system in general. If that's what the user wants to do, what's the problem with doing it? Setting the global user/group is not enough because just because you have one VM that you want in disk doesn't mean you want all of them in disk. Privilege separated QEMU sounds so interesting that I'd go for that direction. There could be helper processes which retain privileges and communicate with the main unprivileged QEMU with only file descriptors. The helpers could even execute setgid disk group re-opener for the CD-ROM case, or ask libvirt to do the reopen. For unprivileged QEMU part it wouldn't matter, all it sees are the descriptors.
Re: [Qemu-devel] [PATCH] ide: consolidate drive_get(IF_IDE)
Am 03.04.2011 13:32, schrieb Isaku Yamahata: factor out ide initialization to call drive_get(IF_IDE) Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
On 4 April 2011 15:29, Jes Sorensen jes.soren...@redhat.com wrote: On 03/30/11 16:07, Peter Maydell wrote: On 30 March 2011 14:56, Anthony Liguori anth...@codemonkey.ws wrote: On 03/30/2011 08:22 AM, Peter Maydell wrote: Not really, typically they're just filled up in some particular order (main RAM in one place and expansion RAM elsewhere). Since the board init function is only passed a single ram_size parameter that's all you can do anyhow. FWIW, I don't think any static data is going to be perfect here. A lot of boards have strict requirements on ram_size based on plausible combinations of DIMMs. Arbitrary values up to ram_size is not good enough. ram_size ought to be viewed as a hint, not a mechanism to allow common code to completely validate the passed in ram size parameter. It's still up to the board to validate that the given ram size makes sense. Yes, I agree, so we shouldn't try to specify some complicated set of static data that still won't be good enough. I'm trying to make it easy for boards to avoid crashing horribly when the user passes a bad value; that's all. If you don't validate properly, is there really a point in introducing that value anyway? From what you write, it sounds like it can still fail for some limits of the memory valid if the config is wrong? For the boards I care about (the ARM ones), the only validation requirement is that we don't allow the user to specify so much ram that we overlap physical RAM with I/O space. So ram_size is good enough. For the sun4m boards we can assume that the only validation they need is a ram_size check, because that's all they do at the moment and nobody's complaining that I know of. As far as I know Anthony is suggesting that some boards might in theory have stricter memory size requirements. I agree that this is a possibility, but if you have a rare board which has an idiosyncratic requirement then the correct way to handle that is to add extra checks in the board init functions. I don't see a huge queue of people with patches to add complex checks to board init functions that would indicate that we need a generic mechanism for handling this. What we do have is simple ram_size limit checks (in sun4m and we need them for the arm devboards) -- which is a demonstrated need that justifies the common code framework. It still seems to me it would be better to have the boards present a table of valid memory ranges so we can do a proper validation of the valud? If you have a concrete example of multiple boards which we currently model and which require this level of flexibility to avoid odd misbehaviour trying to run a guest, then please point them out and I'll look at expanding the patch to cover their requirements. If this is just a theoretical issue, then I think we should only add the extra generic framework code if and when we turn out to need it. -- PMM
Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen jes.soren...@redhat.com wrote: On 04/04/11 16:42, Peter Maydell wrote: On 4 April 2011 15:29, Jes Sorensen jes.soren...@redhat.com wrote: Yes, I agree, so we shouldn't try to specify some complicated set of static data that still won't be good enough. I'm trying to make it easy for boards to avoid crashing horribly when the user passes a bad value; that's all. If you don't validate properly, is there really a point in introducing that value anyway? From what you write, it sounds like it can still fail for some limits of the memory valid if the config is wrong? For the boards I care about (the ARM ones), the only validation requirement is that we don't allow the user to specify so much ram that we overlap physical RAM with I/O space. So ram_size is good enough. For the sun4m boards we can assume that the only validation they need is a ram_size check, because that's all they do at the moment and nobody's complaining that I know of. I understand that what you are proposing seems to work well enough for your problem at hand. What I am saying is that adding a mechanism like that, can cause problems for adding a more generic mechanism that handles more advanced boards in the future. I much prefer a generic solution than a simple hack. We could have -device RAM,base=xxx,size=yyy,id=DIMM1 -numa nodeid=zzz,memory=DIMM1 for fine tuned control. But asking users to list and bind the DIMMs needed just to have some amount of RAM is a bit too much. So we also need a simple case (-m) and a simple check for the max memory. It's still possible for the board to do additional checks and even use heuristics to invent the DIMMs. It still seems to me it would be better to have the boards present a table of valid memory ranges so we can do a proper validation of the valud? If you have a concrete example of multiple boards which we currently model and which require this level of flexibility to avoid odd misbehaviour trying to run a guest, then please point them out and I'll look at expanding the patch to cover their requirements. If this is just a theoretical issue, then I think we should only add the extra generic framework code if and when we turn out to need it. As I pointed out before, this is not a theoretical problem, most numa systems have this issue, including many x86 boxes. I can see the problem also existing with mips boards like the sb1250 ones I worked on many years ago. Having an a table of valid ram locations for a board, will also give you a framework to validate against if you want to be able to specify chunks of memory at different areas of a board. This could be useful for testing behavior that is like it would be if you have a system where installing different DIMMs would split the RAM up differently. Maybe we could remove some of memory logic in pc.c with this approach. By the way, fw_cfg only uses one number for the memory size. This should be changed. Alternatively the BIOSes could do a more realistic RAM probe, but that would be wasteful.
[Qemu-devel] Re: [PATCH] cpu-all.h: Remove unnecessary target-specific ifdef for CPU_QuadU
On 04/04/2011 01:09 PM, Peter Maydell wrote: CPU_QuadU isn't used on all targets, but there's no harm in defining the typedef anyway. It only needs to be guarded by CONFIG_SOFTFLOAT, because softfloat-native doesn't have a float128 type. This avoids the need for every new target which uses CPU_QuadU to add itself to an #ifdef in what ought to be target-agnostic code. Signed-off-by: Peter Maydellpeter.mayd...@linaro.org I don't really know my way around FP, but from here it looks good :). Not sure about the arm part, but I trust Peter on that one ;). Alex
Re: [Qemu-devel] Re: [PATCH 00/10] pci: pci_register_bar_simple
On Mon, Apr 4, 2011 at 7:35 PM, Avi Kivity a...@redhat.com wrote: On 04/04/2011 07:22 PM, Anthony Liguori wrote: On 04/04/2011 10:59 AM, Michael S. Tsirkin wrote: On Mon, Apr 04, 2011 at 06:27:57PM +0300, Avi Kivity wrote: Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially. This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right. This will save some code, so Acked-by: Michael S. Tsirkinm...@redhat.com I really hope the rest of devices will follow. How complete is this? I converted all devices which were easy to convert. There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API). The rest likely need to stick with the callback-based API. In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled. But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.
Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/2011 06:09 PM, Stefan Hajnoczi wrote: On Mon, Apr 4, 2011 at 2:49 PM, Avi Kivitya...@redhat.com wrote: On 04/04/2011 04:38 PM, Anthony Liguori wrote: On 04/04/2011 08:22 AM, Avi Kivity wrote: On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote: In order for media change to work with Linux host CD-ROM it is necessary to reopen the file (otherwise the inode size will not refresh, this is an issue with existing kernels). Maybe we should fix the bug in Linux (and backport as necessary)? I think cd-rom assignment is sufficiently obscure that we can require a fixed kernel instead of providing a workaround. Do reads fail after CD change? Or do they succeed and the size is just reported incorrectly? If it's the later, I'd agree that it needs fixing in the kernel. If it's the former, I'd say it's clearly a feature. Even if it's a documented or intentional feature, we can add an ioctl to refresh the device with up-to-date data. It's possible to fix this in the kernel. I just haven't written the patch yet. The inode size needs to be updated when the new medium is detected. I haven't tested but I suspect reads within the size of the previous medium will succeed. But if the new medium is larger then reads beyond the old medium size will fail. The size reported by lseek(fd, 0, SEEK_END) is outdated. I believe a kernel fix is best in that case, leaving qemu alone. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On Mon, Apr 4, 2011 at 2:49 PM, Avi Kivity a...@redhat.com wrote: On 04/04/2011 04:38 PM, Anthony Liguori wrote: On 04/04/2011 08:22 AM, Avi Kivity wrote: On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote: In order for media change to work with Linux host CD-ROM it is necessary to reopen the file (otherwise the inode size will not refresh, this is an issue with existing kernels). Maybe we should fix the bug in Linux (and backport as necessary)? I think cd-rom assignment is sufficiently obscure that we can require a fixed kernel instead of providing a workaround. Do reads fail after CD change? Or do they succeed and the size is just reported incorrectly? If it's the later, I'd agree that it needs fixing in the kernel. If it's the former, I'd say it's clearly a feature. Even if it's a documented or intentional feature, we can add an ioctl to refresh the device with up-to-date data. It's possible to fix this in the kernel. I just haven't written the patch yet. The inode size needs to be updated when the new medium is detected. I haven't tested but I suspect reads within the size of the previous medium will succeed. But if the new medium is larger then reads beyond the old medium size will fail. The size reported by lseek(fd, 0, SEEK_END) is outdated. Stefan
Re: [Qemu-devel] [PATCH 4/5] sparc64: fix mmu context at trap levels above zero
On Sat, May 22, 2010 at 12:52 PM, Igor V. Kovalenko
igor.v.kovale...@gmail.com wrote:
--- a/target-sparc/helper.c
+++ b/target-sparc/helper.c
@@ -572,6 +572,23 @@ static int get_physical_address(CPUState *env,
target_phys_addr_t *physical,
/* ??? We treat everything as a small page, then explicitly flush
everything when an entry is evicted. */
*page_size = TARGET_PAGE_SIZE;
+
+#if defined (DEBUG_MMU)
+ /* safety net to catch wrong softmmu index use from dynamic code */
What does wrong softmmu index mean? Is it an error or an indication
that something is not implemented?
I'm hitting this net with the following message:
get_physical_address DATA tl=1 mmu_idx=2 primary context=0 secondary
context=0 address=fffb5f40
+ if (env-tl 0 mmu_idx != MMU_NUCLEUS_IDX) {
+ DPRINTF_MMU(get_physical_address %s tl=%d mmu_idx=%d
+ primary context=% PRIx64
+ secondary context=% PRIx64
+ address=% PRIx64
+ \n,
+ (rw == 2 ? CODE : DATA),
+ env-tl, mmu_idx,
+ env-dmmu.mmu_primary_context,
+ env-dmmu.mmu_secondary_context,
+ address);
+ }
+#endif
Artyom
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
On 4 April 2011 15:53, Jes Sorensen jes.soren...@redhat.com wrote: I understand that what you are proposing seems to work well enough for your problem at hand. What I am saying is that adding a mechanism like that, can cause problems for adding a more generic mechanism that handles more advanced boards in the future. I much prefer a generic solution than a simple hack. I don't think it's a hack. I think it's a reasonably clean solution to the set of cases we've actually encountered in practice, and I think trying to design something more generalised without actually having a use case to tie it to is just going to produce something complicated which doesn't turn out to actually be what a hypothetical advanced board will actually need. I think we're much better off with code that does what we need it to do now, and designing and implementing the complicated generic framework only when we actually need it. If you have a concrete example of multiple boards which we currently model and which require this level of flexibility to avoid odd misbehaviour trying to run a guest, then please point them out and I'll look at expanding the patch to cover their requirements. If this is just a theoretical issue, then I think we should only add the extra generic framework code if and when we turn out to need it. As I pointed out before, this is not a theoretical problem, most numa systems have this issue, including many x86 boxes. I can see the problem also existing with mips boards like the sb1250 ones I worked on many years ago. OK, so presumably you can provide a qemu command line and an image which demonstrates the problem... Having an a table of valid ram locations for a board ...I'm not sure this is even meaningful for boards where you can remap the RAM to different physical addresses at runtime (versatile express ought to do this although we don't currently model that bit). -- PMM
[Qemu-devel] [PATCH 12/15] s390x: Adjust internal kvm code
We're now finally emulating an s390x CPU, so we can move quite some logic
from the kvm code out into generic CPU code.
This patch does this and adjusts the interfaces according to what the code
around now expects to be able to call.
Signed-off-by: Alexander Graf ag...@suse.de
---
target-s390x/kvm.c | 60 ---
1 files changed, 14 insertions(+), 46 deletions(-)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index ae7dc56..f464367 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -49,13 +49,6 @@
#define DIAG_KVM_HYPERCALL 0x500
#define DIAG_KVM_BREAKPOINT 0x501
-#define SCP_LENGTH 0x00
-#define SCP_FUNCTION_CODE 0x02
-#define SCP_CONTROL_MASK0x03
-#define SCP_RESPONSE_CODE 0x06
-#define SCP_MEM_CODE0x08
-#define SCP_INCREMENT 0x0a
-
#define ICPT_INSTRUCTION0x04
#define ICPT_WAITPSW0x1c
#define ICPT_SOFT_INTERCEPT 0x24
@@ -182,8 +175,8 @@ int kvm_arch_process_async_events(CPUState *env)
return 0;
}
-static void kvm_s390_interrupt_internal(CPUState *env, int type, uint32_t parm,
-uint64_t parm64, int vm)
+void kvm_s390_interrupt_internal(CPUState *env, int type, uint32_t parm,
+ uint64_t parm64, int vm)
{
struct kvm_s390_interrupt kvmint;
int r;
@@ -218,7 +211,7 @@ void kvm_s390_virtio_irq(CPUState *env, int config_change,
uint64_t token)
token, 1);
}
-static void kvm_s390_interrupt(CPUState *env, int type, uint32_t code)
+void kvm_s390_interrupt(CPUState *env, int type, uint32_t code)
{
kvm_s390_interrupt_internal(env, type, code, 0, 0);
}
@@ -228,16 +221,16 @@ static void enter_pgmcheck(CPUState *env, uint16_t code)
kvm_s390_interrupt(env, KVM_S390_PROGRAM_INT, code);
}
-static void setcc(CPUState *env, uint64_t cc)
+static inline void setcc(CPUState *env, uint64_t cc)
{
-env-kvm_run-psw_mask = ~(3ul 44);
+env-kvm_run-psw_mask = ~(3ull 44);
env-kvm_run-psw_mask |= (cc 3) 44;
env-psw.mask = ~(3ul 44);
env-psw.mask |= (cc 3) 44;
}
-static int sclp_service_call(CPUState *env, struct kvm_run *run, uint16_t
ipbh0)
+static int kvm_sclp_service_call(CPUState *env, struct kvm_run *run, uint16_t
ipbh0)
{
uint32_t sccb;
uint64_t code;
@@ -247,35 +240,11 @@ static int sclp_service_call(CPUState *env, struct
kvm_run *run, uint16_t ipbh0)
sccb = env-regs[ipbh0 0xf];
code = env-regs[(ipbh0 0xf0) 4];
-dprintf(sclp(0x%x, 0x%lx)\n, sccb, code);
-
-if (sccb ~0x7ff8ul) {
-fprintf(stderr, KVM: invalid sccb address 0x%x\n, sccb);
-r = -1;
-goto out;
-}
-
-switch(code) {
-case SCLP_CMDW_READ_SCP_INFO:
-case SCLP_CMDW_READ_SCP_INFO_FORCED:
-stw_phys(sccb + SCP_MEM_CODE, ram_size 20);
-stb_phys(sccb + SCP_INCREMENT, 1);
-stw_phys(sccb + SCP_RESPONSE_CODE, 0x10);
-setcc(env, 0);
-
-kvm_s390_interrupt_internal(env, KVM_S390_INT_SERVICE,
-sccb ~3, 0, 1);
-break;
-default:
-dprintf(KVM: invalid sclp call 0x%x / 0x%lx\n, sccb, code);
-r = -1;
-break;
-}
-
-out:
-if (r 0) {
+r = sclp_service_call(env, sccb, code);
+if (r) {
setcc(env, 3);
}
+
return 0;
}
@@ -287,7 +256,7 @@ static int handle_priv(CPUState *env, struct kvm_run *run,
uint8_t ipa1)
dprintf(KVM: PRIV: %d\n, ipa1);
switch (ipa1) {
case PRIV_SCLP_CALL:
-r = sclp_service_call(env, run, ipbh0);
+r = kvm_sclp_service_call(env, run, ipbh0);
break;
default:
dprintf(KVM: unknown PRIV: 0x%x\n, ipa1);
@@ -300,12 +269,10 @@ static int handle_priv(CPUState *env, struct kvm_run
*run, uint8_t ipa1)
static int handle_hypercall(CPUState *env, struct kvm_run *run)
{
-int r;
-
cpu_synchronize_state(env);
-r = s390_virtio_hypercall(env);
+env-regs[2] = s390_virtio_hypercall(env, env-regs[2], env-regs[1]);
-return r;
+return 0;
}
static int handle_diag(CPUState *env, struct kvm_run *run, int ipb_code)
@@ -450,7 +417,8 @@ static int handle_intercept(CPUState *env)
int icpt_code = run-s390_sieic.icptcode;
int r = 0;
-dprintf(intercept: 0x%x (at 0x%lx)\n, icpt_code, env-kvm_run-psw_addr);
+dprintf(intercept: 0x%x (at 0x%lx)\n, icpt_code,
+(long)env-kvm_run-psw_addr);
switch (icpt_code) {
case ICPT_INSTRUCTION:
r = handle_instruction(env, run);
--
1.6.0.2
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello Stefan, 2011/4/3 Stefan Hajnoczi stefa...@gmail.com On Sat, Apr 2, 2011 at 8:03 PM, Lyu Mitnick mitnick@gmail.com wrote: Hello Stefan, I have take a look at block.c. But I am a little confused about the meaning of synchronous/asynchronous i/o. I know the two concept in a operating system. However I am not sure whether it is analogous in virtual machine. You may want to read up on the QEMU threading model: http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-and.html (Over)simplifying a bit, only one host thread can be executing QEMU code at any given time because QEMU is not thread-safe internally. If the VM issues a disk read and QEMU uses a read(2) system call to service it, then QEMU and the VM is blocked until the read(2) system call completes. Therefore it is better to use asynchronous I/O in QEMU and resume the VM. Once the read operation completes a callback in QEMU is invoked and we can signal completion back to the VM. Also, in terms of the storage controller interfaces that QEMU emulates (IDE, SCSI, virtio-blk) disk operations are queued or handed to the hardware. The guest operating system expects to continue executing while the disk operation is in progress. On completion the storage controller raises an interrupt and the operating system will complete the I/O. Again, this is an asynchronous (request/response) model rather than a synchronous operation from the guest operating system perspective. Look at hw/virtio-blk.c:virtio_blk_handle_output() for an example of how disk emulation works in QEMU. For qemu-img it is more natural to use synchronous I/O because it is just a sequential C program, not an event-driven program like QEMU. Stefan I am writing my proposal now. I met a problem about describing Adding Fixed hard disk image and Differencing hard disk image support into VHD format. This is a format with three sub-format . Is exist another format containing sub-format and I can take a look?? Thanks Mitnick
Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
On 04/04/11 07:38, Anthony Liguori wrote: On 04/04/2011 08:22 AM, Avi Kivity wrote: On 04/03/2011 02:57 PM, Stefan Hajnoczi wrote: In order for media change to work with Linux host CD-ROM it is necessary to reopen the file (otherwise the inode size will not refresh, this is an issue with existing kernels). Maybe we should fix the bug in Linux (and backport as necessary)? I think cd-rom assignment is sufficiently obscure that we can require a fixed kernel instead of providing a workaround. Do reads fail after CD change? Or do they succeed and the size is just reported incorrectly? If it's the later, I'd agree that it needs fixing in the kernel. If it's the former, I'd say it's clearly a feature. In January 2010 I was seeing old data -- data from the prior CD -- in the guest after the media change. David
[Qemu-devel] Re: [regression] configure: add opengl detection
Hi Benjamin, Let me know if you need more info. what happens if you configure with ./configure --target-list=x86_64-softmmu --disable-opengl -- Michael
Re: [Qemu-devel] [PATCH] lan9118: Ignore write to MAC_VLAN1 register
On Tue, Mar 29, 2011 at 10:41:12PM +0900, Atsushi Nemoto wrote: Since kernel 2.6.38, smsc911x driver writes to VLAN1 registger. Signed-off-by: Atsushi Nemoto an...@mba.ocn.ne.jp --- hw/lan9118.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/lan9118.c b/hw/lan9118.c index af6949f..62aead3 100644 --- a/hw/lan9118.c +++ b/hw/lan9118.c @@ -785,6 +785,8 @@ static void do_mac_write(lan9118_state *s, int reg, uint32_t val) case MAC_FLOW: s-mac_flow = val 0x; break; +case MAC_VLAN1: +break; /* just ignore */ default: hw_error(lan9118: Unimplemented MAC register write: %d = 0x%x\n, s-mac_cmd 0xf, val); Is it really safe ignoring write to this register? If yes, it's probably a good idea to explain why in a comment. In any case, if supporting this register is easy to do, it would be the best option. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH 0/4] target-arm: Make Neon helpers use correct FP status
On Mon, Apr 04, 2011 at 11:46:31AM +0100, Peter Maydell wrote: This is a patchset which takes the approach discussed in the comments on my earlier patch to fix this bug. We compile *_helper.c with HELPER_CFLAGS, so targets don't need to put all their helper routines in op_helper.c. (This only changes behaviour for target-arm because that's the only target that has files matching that pattern.) Patches two and three are large but fairly mechanical changes to remove explicit CPUState* arguments in favour of just using global 'env' in the two files which can now access it. Finally, patch 4 is a two-liner to use the Neon FP status word... Peter Maydell (4): Makefile.target: Allow target helpers to be in any *_helper.c file target-arm: Use global env in neon_helper.c helpers target-arm: Use global env in iwmmxt_helper.c helpers target-arm: Make Neon helper routines use correct FP status Makefile.target|2 +- target-arm/helpers.h | 256 ++-- target-arm/iwmmxt_helper.c | 80 ++ target-arm/neon_helper.c | 147 - target-arm/translate.c | 248 --- 5 files changed, 349 insertions(+), 384 deletions(-) Thanks, all applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 4/5] sparc64: fix mmu context at trap levels above zero
On Mon, Apr 4, 2011 at 8:25 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sat, May 22, 2010 at 12:52 PM, Igor V. Kovalenko igor.v.kovale...@gmail.com wrote: --- a/target-sparc/helper.c +++ b/target-sparc/helper.c @@ -572,6 +572,23 @@ static int get_physical_address(CPUState *env, target_phys_addr_t *physical, /* ??? We treat everything as a small page, then explicitly flush everything when an entry is evicted. */ *page_size = TARGET_PAGE_SIZE; + +#if defined (DEBUG_MMU) + /* safety net to catch wrong softmmu index use from dynamic code */ What does wrong softmmu index mean? Is it an error or an indication that something is not implemented? I'm hitting this net with the following message: The warning is not correct for CPUs without hypervisor mode. On T1/T2, the default access mode when TL 1 is hypervisor or nucleus mode. Even then, the hypervisor could perform some accesses with kernel or user ASIs.
