Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek ler...@redhat.com wrote: This was how I interpreted our discussion with Jordan: L: Shouldn't qemu OVMF agree on GPE0? J: Why? Anyway, OVMF should be correct, because all ACPI registers are in one tight bunch, starting from 0x400. L: None of those two characteristics (1: 0x400, 2: one tight bunch) are required by the spec. For proof, see what SeaBIOS does: 1: it doesn't use 0x400 as base, 2: GPE0 is not even above the base. This code was written to the PIIX4 datasheet. According to the datasheet, if you change PMBA, it changes the GPE blk too. It sounds like QEMU does not emulate this, and hardcodes the GPE blk. Yes. QEMU does not really implement PIIX4 though. It implements PIIX3 + PM from PIIX4 (but with a functionality that is not present in original spec like pci/cpu hotplug) + other differences that firmware had to take into account. For instance event if QEMU will implement PMBA, OVMF would not be able to configure it to the value 0x400 since QEMU hardcodes another PV device there. Regarding a solution, such as communicating the address in fw_cfg, that could work. OVMF has plans to add fw_cfg support. Can it check that it runs over QEMU and use QEMU's values? No need for new fw_cfg. Anyway, back to my original question: currently OVMF and qemu disagree wrt. GPE0. Which one should I try to modify so that they agree? It does seem like qemu could be changed, does it? It would require a simultaneous fix of qemu seabios. But, if qemu could be changed, could it be made to match the PIIX4 datasheet? We try not to change QEMU in non backwards compatible way. We can implement PMBA and start using address there if FW writes into it, but, as I noted before, OVMF will have to be changed anyways since 0x400 address is already occupied and pci/cpu/memory hotplug/unplug functionality uses additional IO space not documented by PIIX4 spec. It would be better for OVMF to treat QEMU like separate platform, that behave almost, but not exactly like, real HW. -- Gleb.
Re: [Qemu-devel] [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP
Hello Jason, On Sat, Apr 28, 2012 at 6:43 AM, Jason Baron jba...@redhat.com wrote: On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote: Jason, On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron jba...@redhat.com wrote: Hi, The motivation for this change was that I was looking at a way for a qemu-kvm process, to exclude the guest memory from its core dump, which can be quite large. There are already a number of filter flags in /proc/pid/coredump_filter, however, these allow one to specify 'types' of kernel memory, not specific address ranges (which is needed in this case). Since there are no more vma flags available, the first patch eliminates the need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to mark vdso and vsyscall pages. However, it is simple enough to check if a vma covers a vdso or vsyscall page without the need for this flag. The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags: 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to work the same as before unless 'MADV_DONTDUMP' is set on the region. The qemu code which implements this features is at: http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch In my testing the qemu core dump shrunk from 383MB - 13MB with this patch. I also believe that the 'MADV_DONTDUMP' flag might be useful for security sensitive apps, which might want to select which areas are dumped. Since we have MADV_DODUMP MADV_DONTDUMP MADV_NODUMP heading for userspace in 3.4, would you be willing to write patches for the madvise(2) man page to describe these flags? See http://www.kernel.org/doc/man-pages/download.html for details on accessing man-pages Git. Cheers, Michael PS Please also CC linux-api@ when making API/ABI changes. Ok, here's a stab at manpage patch, let me know if I should send it as a separate patch. Thanks. -Jason diff --git a/man2/madvise.2 b/man2/madvise.2 index 36f988a..472c23a 100644 --- a/man2/madvise.2 +++ b/man2/madvise.2 @@ -247,6 +247,22 @@ Ensures that memory in the address range specified by and .IR length will not be collapsed into huge pages. +.TP +.BR MADV_DONTDUMP (since Linux 3.4) +Explicitly exclude from a core dump those pages in the range specified by +.I addr +and +.IR length . +Applications may have large areas of memory which are known not to be useful in +diagnosing a core dump. This specification takes precedence over the bit mask that +is set via the +.I /proc/PID/coredump_filter +file (see +.BR core (5)). +.TP +.BR MADV_DODUMP (since Linux 3.4) +Undo the effect of an earlier +.BR MADV_DONTDUMP. .SH RETURN VALUE On success .BR madvise () @@ -356,4 +372,5 @@ from the system call, as it should). .BR mmap (2), .BR mprotect (2), .BR msync (2), -.BR munmap (2) +.BR munmap (2), +.BR core (5) Thanks! I tweaked this patch a little and applied the version below. Cheers, Michael --- a/man2/madvise.2 +++ b/man2/madvise.2 @@ -247,6 +247,24 @@ Ensures that memory in the address range specified by and .IR length will not be collapsed into huge pages. +.TP +.BR MADV_DONTDUMP (since Linux 3.4) +Exclude from a core dump those pages in the range specified by +.I addr +and +.IR length . +This is useful in applications that have large areas of memory +that are known not to be useful in a core dump. +The effect of +.BR MADV_DONTDUMP +takes precedence over the bit mask that is set via the +.I /proc/PID/coredump_filter +file (see +.BR core (5)). +.TP +.BR MADV_DODUMP (since Linux 3.4) +Undo the effect of an earlier +.BR MADV_DONTDUMP . .SH RETURN VALUE On success .BR madvise () @@ -356,4 +374,5 @@ from the system call, as it should). .BR mmap (2), .BR mprotect (2), .BR msync (2), -.BR munmap (2) +.BR munmap (2), +.BR core (5) -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/
[Qemu-devel] [PATCH 1/2] qcow2: remove a line of unnecessary code
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
block/qcow2-cluster.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index a747a88..b048821 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -538,7 +538,6 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
if (l2_offset) {
qcow2_free_clusters(bs, l2_offset, s-l2_size * sizeof(uint64_t));
}
-l2_offset = s-l1_table[l1_index] L1E_OFFSET_MASK;
}
/* find the cluster offset for the given disk offset */
--
1.7.6
[Qemu-devel] [PATCH 2/2] qcow2: fix the byte endian convertion
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
block/qcow2-refcount.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 812c93c..443c021 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -367,7 +367,7 @@ static int alloc_refcount_block(BlockDriverState *bs,
}
for(i = 0; i table_size; i++) {
-cpu_to_be64s(new_table[i]);
+be64_to_cpus(new_table[i]);
}
/* Hook up the new refcount table in the qcow2 header */
--
1.7.6
Re: [Qemu-devel] [PATCH qemu 4/6] vl.c: change 'defconfig' variable to bool
On Tue, Apr 24, 2012 at 20:32, Eduardo Habkost ehabk...@redhat.com wrote:
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
vl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 1e5e593..a4f4676 100644
--- a/vl.c
+++ b/vl.c
@@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
#ifdef CONFIG_VNC
int show_vnc_port = 0;
#endif
- int defconfig = 1;
+ int defconfig = true;
The type is still 'int', is that intentional?
const char *log_mask = NULL;
const char *log_file = NULL;
GMemVTable mem_trace = {
@@ -2346,7 +2346,7 @@ int main(int argc, char **argv, char **envp)
popt = lookup_opt(argc, argv, optarg, optind);
switch (popt-index) {
case QEMU_OPTION_nodefconfig:
- defconfig=0;
+ defconfig = false;
break;
}
}
--
1.7.3.2
Re: [Qemu-devel] [RFC 00/14] MAINTAINERS cleanups - please read
On Thu, Apr 26, 2012 at 13:43, Andreas Färber afaer...@suse.de wrote: Am 17.04.2012 22:45, schrieb Blue Swirl: On Mon, Apr 16, 2012 at 21:47, Anthony Liguori anth...@codemonkey.ws wrote: On 04/16/2012 04:24 PM, Peter Maydell wrote: On 16 April 2012 18:42, Anthony Liguorianth...@codemonkey.ws wrote: On 04/16/2012 12:17 PM, Peter Maydell wrote: Here's my stab at it: Maintained: Someone actually looks after it. The maintainer will have a git subtree for this area and patches are expected to go through it. Bug reports will generally be investigated. * For something to be marked Maintained, there must be a person on M: and there must be a git tree for the subsystem. Do you mean there must be a git tree or there must be a git tree listed under T: for this area ? We have I think several subsystems where things do come in via pullreq for a submaintainer tree but that tree isn't officially public except in as much as the branch name for the pullreq is always the same... I'd like to record T: as part of a way to validate pull requests. I get slightly nervous about pull requests because it's an easy way to sneak code into the tree if you're malicious. Wouldn't signed PULL requests help? They need a very recent git though. Signed PULL requests can authenticate the person sending the PULL but not authorize what areas the contents of the PULL is allowed to touch. Yes, but was that the problem Anthony had with PULLs? For a person with malicious intentions, a pull would not necessarily be the tool of choice, since it could lead to banning and investigations after discovery. I thought Anthony was talking about MITM (or kernel.org style breach) scenarios, there signed PULLs and/or signed commits could help. Any definition of key - files (just like email - files) is going to be surrounded by grey zones and exceptions to the rule, so I guess verifying each PULL's diff stat and good judgment are the only weapons against malicious PULLs, given that PULLs have become quite popular these days and are no longer limited to recurring block, pci, ppc, etc. How is a PULL any different from email, can you do something in a PULL which is not possible with email? I think signed PULLs and commits would give higher level of integrity and non-repudiation than unsigned email. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] slirp: Untangle TCPOLEN_* from TCPOPT_*
On Fri, Apr 27, 2012 at 22:29, Andreas Färber afaer...@suse.de wrote:
From: Andreas Färber andreas.faer...@web.de
Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up
conflicts with system headers) enclosed TCPOLEN_MAXSEG with an #ifdef
TCPOPT_EOL. This broke the build on illumos, which has TCPOPT_*
but not TCPOLEN_*.
Move them to their own #ifdef TCPOLEN_MAXSEG section to remedy this.
This is just a band aid for the general problem, please introduce
QEMU_ or SLIRP_ prefix so we that avoid system headers and the
#ifdeffery.
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
slirp/tcp.h | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/slirp/tcp.h b/slirp/tcp.h
index 8299603..2e2b403 100644
--- a/slirp/tcp.h
+++ b/slirp/tcp.h
@@ -79,20 +79,23 @@ struct tcphdr {
#define TCPOPT_EOL 0
#define TCPOPT_NOP 1
#define TCPOPT_MAXSEG 2
-#define TCPOLEN_MAXSEG 4
#define TCPOPT_WINDOW 3
-#define TCPOLEN_WINDOW 3
#define TCPOPT_SACK_PERMITTED 4 /* Experimental */
-#define TCPOLEN_SACK_PERMITTED 2
#define TCPOPT_SACK 5 /* Experimental */
#define TCPOPT_TIMESTAMP 8
-#define TCPOLEN_TIMESTAMP 10
-#define TCPOLEN_TSTAMP_APPA (TCPOLEN_TIMESTAMP+2) /* appendix A */
#define TCPOPT_TSTAMP_HDR \
(TCPOPT_NOP24|TCPOPT_NOP16|TCPOPT_TIMESTAMP8|TCPOLEN_TIMESTAMP)
#endif
+#ifndef TCPOLEN_MAXSEG
+#define TCPOLEN_MAXSEG 4
+#define TCPOLEN_WINDOW 3
+#define TCPOLEN_SACK_PERMITTED 2
+#define TCPOLEN_TIMESTAMP 10
+#define TCPOLEN_TSTAMP_APPA (TCPOLEN_TIMESTAMP+2) /* appendix A */
+#endif
+
/*
* Default maximum segment size for TCP.
* With an IP MSS of 576, this is 536,
--
1.7.7
[Qemu-devel] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1
Public bug reported: Hello! I have: virtio_ioport_write: unexpected address 0x13 value 0x1 on config: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed to find romfile pxe-virtio.bin with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 qemu 0.12.3+noroms-0ubuntu9.18 ** Affects: qemu Importance: Undecided Status: New ** Tags: bug kvm virtio -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/990364 Title: virtio_ioport_write: unexpected address 0x13 value 0x1 Status in QEMU: New Bug description: Hello! I have: virtio_ioport_write: unexpected address 0x13 value 0x1 on config: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed to find romfile pxe-virtio.bin with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 qemu 0.12.3+noroms-0ubuntu9.18 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions
[Qemu-devel] [Bug 990364] Re: virtio_ioport_write: unexpected address 0x13 value 0x1
I forgot: guest os is Windows XP Pro SP3 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/990364 Title: virtio_ioport_write: unexpected address 0x13 value 0x1 Status in QEMU: New Bug description: Hello! I have: virtio_ioport_write: unexpected address 0x13 value 0x1 on config: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed to find romfile pxe-virtio.bin with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 qemu 0.12.3+noroms-0ubuntu9.18 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions
[Qemu-devel] [Bug 990364] Re: virtio_ioport_write: unexpected address 0x13 value 0x1
** Attachment added: Mini042412-01.dmp https://bugs.launchpad.net/bugs/990364/+attachment/3111605/+files/Mini042412-01.dmp -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/990364 Title: virtio_ioport_write: unexpected address 0x13 value 0x1 Status in QEMU: New Bug description: Hello! I have: virtio_ioport_write: unexpected address 0x13 value 0x1 on config: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed to find romfile pxe-virtio.bin with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 qemu 0.12.3+noroms-0ubuntu9.18 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions
[Qemu-devel] [Bug 990364] Re: virtio_ioport_write: unexpected address 0x13 value 0x1
** Attachment added: dmesg https://bugs.launchpad.net/qemu/+bug/990364/+attachment/3111622/+files/dmesg -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/990364 Title: virtio_ioport_write: unexpected address 0x13 value 0x1 Status in QEMU: New Bug description: Hello! I have: virtio_ioport_write: unexpected address 0x13 value 0x1 on config: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed to find romfile pxe-virtio.bin with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 qemu 0.12.3+noroms-0ubuntu9.18 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions
Re: [Qemu-devel] [PATCH] slirp: Untangle TCPOLEN_* from TCPOPT_*
Am 28.04.2012 10:18, schrieb Blue Swirl: On Fri, Apr 27, 2012 at 22:29, Andreas Färber afaer...@suse.de wrote: From: Andreas Färber andreas.faer...@web.de Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up conflicts with system headers) enclosed TCPOLEN_MAXSEG with an #ifdef TCPOPT_EOL. This broke the build on illumos, which has TCPOPT_* but not TCPOLEN_*. Move them to their own #ifdef TCPOLEN_MAXSEG section to remedy this. This is just a band aid for the general problem, please introduce QEMU_ or SLIRP_ prefix so we that avoid system headers and the #ifdeffery. This is a fix for a build regression introduced by Paolo. Do you seriously expect me to rewrite the whole of SLIRP on the eve of 1.1 Hard Freeze? A much easier solution would be to revert Paolo's commit. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] slirp: Untangle TCPOLEN_* from TCPOPT_*
On Sat, Apr 28, 2012 at 11:11, Andreas Färber afaer...@suse.de wrote: Am 28.04.2012 10:18, schrieb Blue Swirl: On Fri, Apr 27, 2012 at 22:29, Andreas Färber afaer...@suse.de wrote: From: Andreas Färber andreas.faer...@web.de Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up conflicts with system headers) enclosed TCPOLEN_MAXSEG with an #ifdef TCPOPT_EOL. This broke the build on illumos, which has TCPOPT_* but not TCPOLEN_*. Move them to their own #ifdef TCPOLEN_MAXSEG section to remedy this. This is just a band aid for the general problem, please introduce QEMU_ or SLIRP_ prefix so we that avoid system headers and the #ifdeffery. This is a fix for a build regression introduced by Paolo. Do you seriously expect me to rewrite the whole of SLIRP on the eve of 1.1 Hard Freeze? It would be The Right Fix and for most part, easily reviewable mechanical conversion. But it could be done later and only apply it to 1.1 if there are still problems with other OS headers. A much easier solution would be to revert Paolo's commit. But that would leave Illumos broken. I'd rather apply this one. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 0/5] qemu-timer: Clean code
On Mon, Apr 23, 2012 at 20:39, Stefan Weil s...@weilnetz.de wrote: Am 23.04.2012 22:13, schrieb Anthony Liguori: On 04/20/2012 05:03 AM, Stefan Weil wrote: These patches remove timer code which is no longer needed and try to improve the remaining code. [PATCH 1/5] qemu-timer: Remove redundant include statements [PATCH 2/5] qemu-timer: Remove unused function qemu_alarm_pending [PATCH 3/5] qemu-timer: Use bool, false, true for boolean values [PATCH 4/5] qemu-timer: Remove function alarm_has_dynticks [PATCH 5/5] qemu-timer: Optimize data structures If you're goign to rev a patch, please resubmit the full series. Otherwise it's a pain in the ass to apply because the patches have to be reordered by hand. It's not so bad if it's the last patch in a series but when it's in the middle, it sucks. Regards, Anthony Liguori The patches 4 and 5 don't depend on each other, so they can be reordered. Then patch 4 (v2) would be the last patch. To avoid further pain, it's now possible to pull this series. Thanks, pulled. Regards, Stefan Weil The following changes since commit 092dfc7714ad7983aeb0cada5d5983e9fde8d84c: Merge remote-tracking branch 'origin/master' into staging (2012-04-23 15:02:53 -0500) are available in the git repository at: git://qemu.weilnetz.de/qemu.git timer for you to fetch changes up to 475d53efedeaf3444e78088939afd376e8843d09: qemu-timer: Optimize data structures (2012-04-23 22:37:12 +0200) Stefan Weil (5): qemu-timer: Remove redundant include statements qemu-timer: Remove unused function qemu_alarm_pending qemu-timer: Use bool, false, true for boolean values qemu-timer: Remove function alarm_has_dynticks qemu-timer: Optimize data structures qemu-timer.c | 94 ++--- qemu-timer.h | 13 ++-- 2 files changed, 33 insertions(+), 74 deletions(-)
Re: [Qemu-devel] [PULL 0/3] target-arm queue
On Fri, Apr 27, 2012 at 11:59, Peter Maydell peter.mayd...@linaro.org wrote: Hi; this is a small target-arm pullreq intended to go in before the hardfreeze. It's got the final part of the QOM subclassing work from Andreas plus a minor bugfix to a corner case in the BE8 handling. Please pull. Thanks, pulled. thanks -- PMM The following changes since commit be5ea8ed4481f0ffa4ea0f7ba13e465701536001: Revert configure: Virtfs doesn't require libcap. (2012-04-26 13:14:58 -0500) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git target-arm.for-upstream Andreas Färber (1): target-arm: Change cpu_arm_init() return type to ARMCPU Peter Maydell (2): target-arm: Move A9 config_base_address reset value to ARMCPU target-arm: Make SETEND respect bswap_code (BE8) setting hw/highbank.c | 15 ++- target-arm/cpu-qom.h | 2 +- target-arm/cpu.c | 6 ++ target-arm/cpu.h | 7 --- target-arm/helper.c | 4 ++-- target-arm/translate.c | 8 6 files changed, 19 insertions(+), 23 deletions(-)
Re: [Qemu-devel] [RFC 00/14] MAINTAINERS cleanups - please read
Am 28.04.2012 10:14, schrieb Blue Swirl: On Thu, Apr 26, 2012 at 13:43, Andreas Färber afaer...@suse.de wrote: Am 17.04.2012 22:45, schrieb Blue Swirl: On Mon, Apr 16, 2012 at 21:47, Anthony Liguori anth...@codemonkey.ws wrote: On 04/16/2012 04:24 PM, Peter Maydell wrote: On 16 April 2012 18:42, Anthony Liguorianth...@codemonkey.ws wrote: * For something to be marked Maintained, there must be a person on M: and there must be a git tree for the subsystem. Do you mean there must be a git tree or there must be a git tree listed under T: for this area ? We have I think several subsystems where things do come in via pullreq for a submaintainer tree but that tree isn't officially public except in as much as the branch name for the pullreq is always the same... I'd like to record T: as part of a way to validate pull requests. I get slightly nervous about pull requests because it's an easy way to sneak code into the tree if you're malicious. Wouldn't signed PULL requests help? They need a very recent git though. Signed PULL requests can authenticate the person sending the PULL but not authorize what areas the contents of the PULL is allowed to touch. Yes, but was that the problem Anthony had with PULLs? For a person with malicious intentions, a pull would not necessarily be the tool of choice, since it could lead to banning and investigations after discovery. I thought Anthony was talking about MITM (or kernel.org style breach) scenarios, Didn't read that into his words. To me it sounded like he wanted for his mailbox scripts to be able to automatically decide whether to accept a PULL (which he receives by unsigned email) or not, based on the tree documented in MAINTAINERS. On IRC however Anthony turned towards trusting persons not trees. That would easily be supportable by signed PULLs I guess, by whitelisting public keys. Any definition of key - files (just like email - files) is going to be surrounded by grey zones and exceptions to the rule, so I guess verifying each PULL's diff stat and good judgment are the only weapons against malicious PULLs, given that PULLs have become quite popular these days and are no longer limited to recurring block, pci, ppc, etc. How is a PULL any different from email, can you do something in a PULL which is not possible with email? I think signed PULLs and commits would give higher level of integrity and non-repudiation than unsigned email. A PULL is a standardized form of unsigned email. It contains a From:, an upstream commit hash, a branch/tag name and usually a diffstat and list of commits. So it's more than just a personal mail naming a branch. The diffstat can easily be verified by fetching from the branch and recalculating it from the commit hash in the message. This could then be checked against the file patterns in MAINTAINERS. But like I said, there's exceptions - my upcoming Cocoa PULL will include changes to configure and block/*, both not file patterns of the Cocoa subsystem, but semantically related and coordinated by mail/IRC. Therefore my saying, validating PULLs against MAINTAINERS sections is not going to work; validating PULLs for interim projects (like QOM'ifications) not documented in MAINTAINERS are not going to work, nor is if no one replies to it after X days send me a PULL. Thus we can try to whitelist where to PULL from, but we cannot blacklist PULLs not whitelisted, they'll still need to be reviewed individually with some common sense. What would be neat btw is if incoming PULLs could automatically be checked by our build bots (we can dream). Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v2 0/4] softfloat: Fix build on Darwin (uint16)
On Wed, Apr 25, 2012 at 22:15, Andreas Färber andreas.faer...@web.de wrote:
Hello,
Since shortly before 1.0 the build on Mac OS X host is broken due to a type
conflict for uint16 between SoftFloat and system headers. The conflict stems
from SoftFloat using int for uint16 (i.e., 32 bits) whereas Apple wants 16
bits,
and no correct workaround was found in time.
Since these integer types also potentially conflict with those of BeOS/Haiku
and kept creeping into others parts of code accidentally, we concluded that
the
SoftFloat [u]intX types were doing more bad than good and should be replaced.
Options considered were renaming them to unique qemu_[u]intX or reusing POSIX
[u]int_leastX_t, [u]int_fastX_t or [u]intX_t.
Renaming raised the question of why the types were defined as they are today.
If they are intended to be performance-tuned then [u]int_fastX_t would allow
to leave that responsibility to the OS.
[u]int_leastX_t matches the described semantics of [u]intX but was discarded
in favor of [u]int_fastX_t.
That leaves a choice between [u]intX_t and [u]int_fastX_t.
Having already introduced the use of [u]intX_t in an earlier series (bitsX),
using [u]intX_t for these formerly separate types would make it hard to
move from that to another type in case of problems.
However, introducing [u]int_fast32_t might turn 32-bit types into 64-bit
types,
unexpected by code that may be misusing these types (missing masks/casts).
This series therefore strips down my RFC series to only replace uint16, where
Mac OS X users are seeing problems, and for symmetry int16. Peter and me
consider this limited change safe for 1.1 since a) sizeof(uint16) != 2 already
and b) uint16 is signed, without bug reports all those years.
(i) uint16: signed int - unsigned short / int / long / long long depending
on host
(ii) int16: signed int - signed short / int / long / long long depending
on host
That would fix the reported build problem and leave the door open to sed the
types to something more performant or smaller at a later point in time.
As before, constructive feedback and in particular...
* tests on the various platforms,
* benchmark results that show performance improving (or not significantly
degrading), as well as
* test suites beyond ARM guests to make sure we introduce no regressions
...for the remaining types from the previous RFC series (especially [u]int32)
are much more appreciated than reposting old hacky workarounds, which I will
continue to nack.
Thanks, applied all.
Regards,
Andreas
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Bernhard Walle bernh...@bwalle.de
v1 - v2:
* Change comment moved from target-mips to reflect further types being added.
(suggested by Peter)
* Drop all non-essential patches that need further testing/benchmarking.
Andreas Färber (4):
softfloat: Fix mixups of int and int16
target-mips: Move definition of uint_fast{8,16}_t to osdep.h
softfloat: Replace uint16 type with uint_fast16_t
softfloat: Replace int16 type with int_fast16_t
fpu/softfloat-macros.h | 18
fpu/softfloat.c | 122
fpu/softfloat.h | 13 ++---
osdep.h | 7 +++
target-mips/cpu.h | 7 ---
5 files changed, 82 insertions(+), 85 deletions(-)
--
1.7.7
Re: [Qemu-devel] [PATCH] configure: Don't build bsd-user on Mac OS X by default
On Thu, Apr 26, 2012 at 09:57, Andreas Färber andreas.faer...@web.de wrote:
Fixes the build when combined with the drop of darwin-user.
Enthusiasts can still try building it using --enable-bsd-user.
Signed-off-by: Andreas Färber andreas.faer...@web.de
Cc: Bernhard Walle bernh...@bwalle.de
Thanks, applied.
---
configure | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index dd09f1a..e1bdc10 100755
--- a/configure
+++ b/configure
@@ -498,8 +498,8 @@ esac
if [ $bsd = yes ] ; then
if [ $darwin != yes ] ; then
usb=bsd
+ bsd_user=yes
fi
- bsd_user=yes
fi
: ${make=${MAKE-make}}
--
1.7.5.3
Re: [Qemu-devel] [PATCH] main-loop: Fix build for w32 and w64
On Fri, Apr 27, 2012 at 15:02, Stefan Weil s...@weilnetz.de wrote:
This patch fixes a build regression with MinGW which was introduced by
commit 7c7db75576bd5a31508208f153c5aada64b2c8df.
The 3rd argument of g_main_context_query must point to a gint value.
Using a pointer to an uint32_t value is wrong.
The timeout argument of function os_host_main_loop_wait was never
used for w32 / w64.
Signed-off-by: Stefan Weil s...@weilnetz.de
Thanks, applied.
---
main-loop.c | 7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 0457bf2..24cf540 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -410,6 +410,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
int ret, i;
PollingEntry *pe;
WaitObjects *w = wait_objects;
+ gint poll_timeout;
static struct timeval tv0;
/* XXX: need to suppress polling by better using win32 events */
@@ -424,12 +425,12 @@ static int os_host_main_loop_wait(uint32_t timeout)
if (nfds = 0) {
ret = select(nfds + 1, rfds, wfds, xfds, tv0);
if (ret != 0) {
- timeout = 0;
+ /* TODO. */
}
}
g_main_context_prepare(context, max_priority);
- n_poll_fds = g_main_context_query(context, max_priority, timeout,
+ n_poll_fds = g_main_context_query(context, max_priority, poll_timeout,
poll_fds, ARRAY_SIZE(poll_fds));
g_assert(n_poll_fds = ARRAY_SIZE(poll_fds));
@@ -439,7 +440,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
}
qemu_mutex_unlock_iothread();
- ret = g_poll(poll_fds, n_poll_fds + w-num, timeout);
+ ret = g_poll(poll_fds, n_poll_fds + w-num, poll_timeout);
qemu_mutex_lock_iothread();
if (ret 0) {
for (i = 0; i w-num; i++) {
--
1.7.9
Re: [Qemu-devel] [PATCH 2/4] cputlb: move TLB handling to a separate file
On Sun, Apr 22, 2012 at 15:35, Blue Swirl blauwir...@gmail.com wrote:
Move TLB handling and softmmu code load helpers to cputlb.c,
compile only for softmmu targets.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
Makefile.target | 2 +-
cputlb.c | 362
cputlb.h | 63 +
exec-all.h | 12 +-
exec.c | 380
+--
5 files changed, 443 insertions(+), 376 deletions(-)
create mode 100644 cputlb.c
create mode 100644 cputlb.h
diff --git a/Makefile.target b/Makefile.target
index b6a9330..77cd0a1 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -225,7 +225,7 @@ obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-$(CONFIG_VGA) += vga.o
-obj-y += memory.o savevm.o
+obj-y += memory.o savevm.o cputlb.o
LIBS+=-lz
obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/cputlb.c b/cputlb.c
new file mode 100644
index 000..b7d8f07
--- /dev/null
+++ b/cputlb.c
@@ -0,0 +1,362 @@
+/*
+ * Common CPU TLB handling
+ *
+ * Copyright (c) 2003 Fabrice Bellard
+ *
+ * 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.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+#include config.h
+#include cpu.h
+#include exec-all.h
+#include memory.h
+
+#include cputlb.h
+
+#define WANT_EXEC_OBSOLETE
+#include exec-obsolete.h
+
+//#define DEBUG_TLB
+//#define DEBUG_TLB_CHECK
+
+/* statistics */
+int tlb_flush_count;
+
+static const CPUTLBEntry s_cputlb_empty_entry = {
+ .addr_read = -1,
+ .addr_write = -1,
+ .addr_code = -1,
+ .addend = -1,
+};
+
+/* NOTE:
+ * If flush_global is true (the usual case), flush all tlb entries.
+ * If flush_global is false, flush (at least) all tlb entries not
+ * marked global.
+ *
+ * Since QEMU doesn't currently implement a global/not-global flag
+ * for tlb entries, at the moment tlb_flush() will also flush all
+ * tlb entries in the flush_global == false case. This is OK because
+ * CPU architectures generally permit an implementation to drop
+ * entries from the TLB at any time, so flushing more entries than
+ * required is only an efficiency issue, not a correctness issue.
+ */
+void tlb_flush(CPUArchState *env, int flush_global)
+{
+ int i;
+
+#if defined(DEBUG_TLB)
+ printf(tlb_flush:\n);
+#endif
+ /* must reset current TB so that interrupts cannot modify the
+ links while we are modifying them */
+ env-current_tb = NULL;
+
+ for (i = 0; i CPU_TLB_SIZE; i++) {
+ int mmu_idx;
+
+ for (mmu_idx = 0; mmu_idx NB_MMU_MODES; mmu_idx++) {
+ env-tlb_table[mmu_idx][i] = s_cputlb_empty_entry;
+ }
+ }
+
+ memset(env-tb_jmp_cache, 0, TB_JMP_CACHE_SIZE * sizeof (void *));
+
+ env-tlb_flush_addr = -1;
+ env-tlb_flush_mask = 0;
+ tlb_flush_count++;
+}
+
+static inline void tlb_flush_entry(CPUTLBEntry *tlb_entry, target_ulong addr)
+{
+ if (addr == (tlb_entry-addr_read
+ (TARGET_PAGE_MASK | TLB_INVALID_MASK)) ||
+ addr == (tlb_entry-addr_write
+ (TARGET_PAGE_MASK | TLB_INVALID_MASK)) ||
+ addr == (tlb_entry-addr_code
+ (TARGET_PAGE_MASK | TLB_INVALID_MASK))) {
+ *tlb_entry = s_cputlb_empty_entry;
+ }
+}
+
+void tlb_flush_page(CPUArchState *env, target_ulong addr)
+{
+ int i;
+ int mmu_idx;
+
+#if defined(DEBUG_TLB)
+ printf(tlb_flush_page: TARGET_FMT_lx \n, addr);
+#endif
+ /* Check if we need to flush due to large pages. */
+ if ((addr env-tlb_flush_mask) == env-tlb_flush_addr) {
+#if defined(DEBUG_TLB)
+ printf(tlb_flush_page: forced full flush (
+ TARGET_FMT_lx / TARGET_FMT_lx )\n,
+ env-tlb_flush_addr, env-tlb_flush_mask);
+#endif
+ tlb_flush(env, 1);
+ return;
+ }
+ /* must reset current TB so that interrupts cannot modify the
+ links while we are modifying them */
+ env-current_tb = NULL;
+
+ addr = TARGET_PAGE_MASK;
+ i = (addr TARGET_PAGE_BITS) (CPU_TLB_SIZE - 1);
+ for (mmu_idx = 0; mmu_idx NB_MMU_MODES; mmu_idx++) {
+ tlb_flush_entry(env-tlb_table[mmu_idx][i], addr);
+ }
+
+
Re: [Qemu-devel] [RFC 00/14] MAINTAINERS cleanups - please read
On Sat, Apr 28, 2012 at 11:42, Andreas Färber afaer...@suse.de wrote: Am 28.04.2012 10:14, schrieb Blue Swirl: On Thu, Apr 26, 2012 at 13:43, Andreas Färber afaer...@suse.de wrote: Am 17.04.2012 22:45, schrieb Blue Swirl: On Mon, Apr 16, 2012 at 21:47, Anthony Liguori anth...@codemonkey.ws wrote: On 04/16/2012 04:24 PM, Peter Maydell wrote: On 16 April 2012 18:42, Anthony Liguorianth...@codemonkey.ws wrote: * For something to be marked Maintained, there must be a person on M: and there must be a git tree for the subsystem. Do you mean there must be a git tree or there must be a git tree listed under T: for this area ? We have I think several subsystems where things do come in via pullreq for a submaintainer tree but that tree isn't officially public except in as much as the branch name for the pullreq is always the same... I'd like to record T: as part of a way to validate pull requests. I get slightly nervous about pull requests because it's an easy way to sneak code into the tree if you're malicious. Wouldn't signed PULL requests help? They need a very recent git though. Signed PULL requests can authenticate the person sending the PULL but not authorize what areas the contents of the PULL is allowed to touch. Yes, but was that the problem Anthony had with PULLs? For a person with malicious intentions, a pull would not necessarily be the tool of choice, since it could lead to banning and investigations after discovery. I thought Anthony was talking about MITM (or kernel.org style breach) scenarios, Didn't read that into his words. To me it sounded like he wanted for his mailbox scripts to be able to automatically decide whether to accept a PULL (which he receives by unsigned email) or not, based on the tree documented in MAINTAINERS. On IRC however Anthony turned towards trusting persons not trees. That would easily be supportable by signed PULLs I guess, by whitelisting public keys. Any definition of key - files (just like email - files) is going to be surrounded by grey zones and exceptions to the rule, so I guess verifying each PULL's diff stat and good judgment are the only weapons against malicious PULLs, given that PULLs have become quite popular these days and are no longer limited to recurring block, pci, ppc, etc. How is a PULL any different from email, can you do something in a PULL which is not possible with email? I think signed PULLs and commits would give higher level of integrity and non-repudiation than unsigned email. A PULL is a standardized form of unsigned email. It contains a From:, an upstream commit hash, a branch/tag name and usually a diffstat and list of commits. So it's more than just a personal mail naming a branch. The diffstat can easily be verified by fetching from the branch and recalculating it from the commit hash in the message. This could then be checked against the file patterns in MAINTAINERS. But like I said, there's exceptions - my upcoming Cocoa PULL will include changes to configure and block/*, both not file patterns of the Cocoa subsystem, but semantically related and coordinated by mail/IRC. Therefore my saying, validating PULLs against MAINTAINERS sections is not going to work; validating PULLs for interim projects (like QOM'ifications) not documented in MAINTAINERS are not going to work, nor is if no one replies to it after X days send me a PULL. Thus we can try to whitelist where to PULL from, but we cannot blacklist PULLs not whitelisted, they'll still need to be reviewed individually with some common sense. There's also plenty of code which is not covered by MAINTAINERS, also qemu-trivial could touch anything. What would be neat btw is if incoming PULLs could automatically be checked by our build bots (we can dream). We could also dream of having bots to run checkpatch.pl on incoming patches, or buildbots that use clang analyzer or cppcheck instead of GCC, or run tests and check test coverage with gcov. We could also use Gerrit for patch review. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 0/3] Fix some memory leaks
Valgrind reports lots of memory leaks. Three of them which occur very often are fixed here. [PATCH 1/3] qdev: Fix memory leak in function set_pci_devfn [PATCH 2/3] qom: Fix memory leak in function container_get [PATCH 3/3] hw/pc_sysfw: Fix memory leak Regards, Stefan Weil
[Qemu-devel] [PATCH 3/3] hw/pc_sysfw: Fix memory leak
Valgrind reported this memory leak which occured a few times.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/pc_sysfw.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/pc_sysfw.c b/hw/pc_sysfw.c
index fafdf9b..f0d7c21 100644
--- a/hw/pc_sysfw.c
+++ b/hw/pc_sysfw.c
@@ -85,6 +85,9 @@ static void pc_fw_add_pflash_drv(void)
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
opts = drive_add(IF_PFLASH, -1, filename, readonly=on);
+
+g_free(filename);
+
if (opts == NULL) {
return;
}
--
1.7.9
[Qemu-devel] [PATCH 1/3] qdev: Fix memory leak in function set_pci_devfn
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/qdev-properties.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 98dd06a..c212303 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -834,6 +834,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void
*opaque,
visit_type_str(v, str, name, local_err);
if (local_err) {
+g_free(local_err);
return set_int32(obj, v, opaque, name, errp);
}
--
1.7.9
[Qemu-devel] [PATCH 2/3] qom: Fix memory leak in function container_get
Valgrind reported this memory leak which occured very often. Test scenario: qemu-system-i386 (no arguments), only BIOS started, terminate with monitor command (quit). Signed-off-by: Stefan Weil s...@weilnetz.de --- qom/container.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/qom/container.c b/qom/container.c index c9940ab..4ca8b5c 100644 --- a/qom/container.c +++ b/qom/container.c @@ -43,6 +43,8 @@ Object *container_get(Object *root, const char *path) } } +g_strfreev(parts); + return obj; } -- 1.7.9
Re: [Qemu-devel] [PATCH 1/3] qdev: Fix memory leak in function set_pci_devfn
Am 28.04.2012 14:20, schrieb Stefan Weil:
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/qdev-properties.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 98dd06a..c212303 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -834,6 +834,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void
*opaque,
visit_type_str(v, str, name, local_err);
if (local_err) {
+g_free(local_err);
Please use error_free() instead.
Andreas
return set_int32(obj, v, opaque, name, errp);
}
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH] qdev: Fix memory leak in function set_pci_devfn
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
v2:
Use error_free instead of g_free (hint from Andreas Färber, thanks).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/qdev-properties.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 98dd06a..c5545dc 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -834,6 +834,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void
*opaque,
visit_type_str(v, str, name, local_err);
if (local_err) {
+error_free(local_err);
return set_int32(obj, v, opaque, name, errp);
}
--
1.7.9
Re: [Qemu-devel] [PATCH 2/4] cputlb: move TLB handling to a separate file
Am 28.04.2012 13:48, schrieb Blue Swirl:
On Sun, Apr 22, 2012 at 15:35, Blue Swirl blauwir...@gmail.com wrote:
diff --git a/cputlb.c b/cputlb.c
new file mode 100644
index 000..b7d8f07
--- /dev/null
+++ b/cputlb.c
[...]
+void tlb_reset_dirty_range(CPUTLBEntry *tlb_entry, uintptr_t start,
+ uintptr_t length)
This...
+{
+uintptr_t addr;
+
+if (tlb_is_dirty_ram(tlb_entry)) {
+addr = (tlb_entry-addr_write TARGET_PAGE_MASK) +
tlb_entry-addend;
+if ((addr - start) length) {
+tlb_entry-addr_write |= TLB_NOTDIRTY;
+}
+}
+}
[...]
diff --git a/cputlb.h b/cputlb.h
new file mode 100644
index 000..d16c22e
--- /dev/null
+++ b/cputlb.h
[...]
+void tlb_reset_dirty_range(CPUTLBEntry *tlb_entry, unsigned long start,
+ unsigned long length);
... doesn't match this prototype, so build would fail on win32.
Maybe this is 1.2 material anyway.
Personally I'd like to have those big code movements sorted out earlier
than later (including any outstanding AREG0 refactorings) due to my
CPUArchState - CPUState consolidation work.
So if you and Richard are happy with the code changes except for this
mismatch then I can check both mingw cross builds if you name a branch.
But I'd also be fine with a semiofficial next branch for 1.2.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 1/3] qdev: Fix memory leak in function set_pci_devfn
Am 28.04.2012 14:24, schrieb Andreas Färber:
Am 28.04.2012 14:20, schrieb Stefan Weil:
Valgrind reported this memory leak which occured very often.
Test scenario:
qemu-system-i386 (no arguments), only BIOS started, terminate with
monitor command (quit).
Signed-off-by: Stefan Weils...@weilnetz.de
---
hw/qdev-properties.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 98dd06a..c212303 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -834,6 +834,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void
*opaque,
visit_type_str(v,str, name,local_err);
if (local_err) {
+g_free(local_err);
Please use error_free() instead.
Andreas
Thanks, I have sent a new patch.
Anthony or Blue, the patches in this series are independent,
so it's possible to skip patch 1/3.
Regards,
Stefan W.
Re: [Qemu-devel] [PATCH] qdev: Fix memory leak in function set_pci_devfn
Am 28.04.2012 14:32, schrieb Stefan Weil: Valgrind reported this memory leak which occured very often. Test scenario: qemu-system-i386 (no arguments), only BIOS started, terminate with monitor command (quit). v2: Use error_free instead of g_free (hint from Andreas Färber, thanks). Signed-off-by: Stefan Weil s...@weilnetz.de Acked-by: Andreas Färber afaer...@suse.de /-F -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 2/3] qom: Fix memory leak in function container_get
Am 28.04.2012 14:20, schrieb Stefan Weil: Valgrind reported this memory leak which occured very often. Test scenario: qemu-system-i386 (no arguments), only BIOS started, terminate with monitor command (quit). Signed-off-by: Stefan Weil s...@weilnetz.de Reviewed-by: Andreas Färber afaer...@suse.de /-F -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 3/3] hw/pc_sysfw: Fix memory leak
Am 28.04.2012 14:20, schrieb Stefan Weil: Valgrind reported this memory leak which occured a few times. Test scenario: qemu-system-i386 (no arguments), only BIOS started, terminate with monitor command (quit). Signed-off-by: Stefan Weil s...@weilnetz.de Reviewed-by: Andreas Färber afaer...@suse.de /-F -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 0/1] Fix /dev/sg causing the guest to kernel panic
List, Please find a patch to fix scsi_cmd_xfer_mode() so that qemu will use the correct transfer direction for SCSI-GENERIC devices for the opcodes UNMAP WRITE_SAME_16 ATA_PASSTHROUGH Without this patch, any recent linux guest kernels (3.x) will panic if qemu are presenting a scsi-generic device to the guest. regards ronnie sahlberg
[Qemu-devel] [PATCH] SCSI-GENERIC: Specify the xfer direction for UNMAP/WRITESAME16/ATAPASSTHROUGH command
scsi_cmd_xfer_mode() is used to specify the xfer direction for SCSI commands that come in from the guest. If the direction is set incorrectly this will eventually cause QEMU to kernel-panic the guest. Add UNMAP/WRITESAME16/ATAPASSTHROUGH as commands that send data to the device. Without this change, recent kernels will send both UNMAP as well as ATAPASSTHROUGH commands to any /dev/sg* device, which due to the incorrect xfer direction very quickly causes the guest kernel to crash. Example causing a crash without the patch applied: ./x86_64-softmmu/qemu-system-x86_64 -m 1024 -enable-kvm -cdrom linuxmint-12-gnome-dvd-64bit.iso -drive file=/dev/sg4,if=scsi,bus=0,unit=6 Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- hw/scsi-bus.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c index dbdb99c..bca2be8 100644 --- a/hw/scsi-bus.c +++ b/hw/scsi-bus.c @@ -920,6 +920,8 @@ static void scsi_cmd_xfer_mode(SCSICommand *cmd) case UPDATE_BLOCK: case WRITE_LONG_10: case WRITE_SAME_10: +case WRITE_SAME_16: +case UNMAP: case SEARCH_HIGH_12: case SEARCH_EQUAL_12: case SEARCH_LOW_12: @@ -929,6 +931,7 @@ static void scsi_cmd_xfer_mode(SCSICommand *cmd) case SEND_DVD_STRUCTURE: case PERSISTENT_RESERVE_OUT: case MAINTENANCE_OUT: +case ATA_PASSTHROUGH: cmd-mode = SCSI_XFER_TO_DEV; break; default: -- 1.7.3.1
Re: [Qemu-devel] [PATCH V3 12/13] hw/sd.c: introduce SD card device-id property
Il 27/04/2012 18:52, Igor Mitsyanko ha scritto: The other block device models use a property drive for connecting to a block backend, usually via DEFINE_BLOCK_PROPERTIES(). Why is it necessary for sd.c to be different? SD card is not an instance of TYPE_DEVICE, we cant set a pointer to BlockDriverState as a property of TYPE_SD_CARD object. I think in the future we will just have TYPE_SD_CARD/childTYPE_BLOCK_DRIVER_STATE or TYPE_SD_CARD/linkTYPE_BLOCK_DRIVER_STATE, but now device_id property seems like a nice solution. I agree---however, calling it drive for consistency is nicer. Paolo
Re: [Qemu-devel] [PATCH V3 13/13] hw/sd.c: introduce eject property for SD card objects
Il 27/04/2012 17:50, Igor Mitsyanko ha scritto:
Boolean property eject could be used to query if virtual media is inserted
into
SD card object, or to deattach BlockDriverState from SD card object.
All this is already available in the BlockDriverState object; the eject
monitor command does bdrv_close and calls the change_media_cb on the
attached device. The SD card should just attach callbacks to the BDS.
Paolo
Signed-off-by: Igor Mitsyanko i.mitsya...@samsung.com
---
hw/sd.c | 60 +++-
1 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index d067ffb..de57000 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -508,6 +508,19 @@ static void sd_init_card(SDState *sd, BlockDriverState
*bdrv, Error **errp)
}
}
+static void sd_deinit_card(SDState *sd)
+{
+bdrv_close(sd-bdrv);
+sd-enable = false;
+bdrv_detach_dev(sd-bdrv, sd);
+sd_reset(sd, NULL);
+
+if (sd-buf) {
+qemu_vfree(sd-buf);
+sd-buf = NULL;
+}
+}
+
static void sd_set_callbacks(SDState *sd, qemu_irq readonly, qemu_irq insert)
{
sd-readonly_cb = readonly;
@@ -1828,15 +1841,7 @@ static void sd_devid_set(Object *obj, const char
*value, Error **errp)
return;
}
-bdrv_close(sd-bdrv);
-sd-enable = false;
-bdrv_detach_dev(sd-bdrv, sd);
-if (sd-buf) {
-qemu_vfree(sd-buf);
-sd-buf = NULL;
-}
-sd_reset(sd, NULL);
-
+sd_deinit_card(sd);
sd_init_card(sd, bdrv, errp);
if (error_is_set(errp)) {
vmstate_unregister(NULL, sd_vmstate, sd);
@@ -1850,6 +1855,41 @@ static void sd_devid_set(Object *obj, const char
*value, Error **errp)
}
}
+static void sd_is_ejected(Object *obj, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+SDState *sd = SD_CARD(obj);
+bool ejected = sd-bdrv bdrv_is_inserted(sd-bdrv) ? false : true;
+
+visit_type_bool(v, ejected, name, errp);
+}
+
+static void sd_eject(Object *obj, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+SDState *sd = SD_CARD(obj);
+bool eject;
+
+visit_type_bool(v, eject, name, errp);
+if (error_is_set(errp)) {
+return;
+}
+
+if (eject) {
+if (!sd-bdrv) {
+return;
+}
+
+if (bdrv_in_use(sd-bdrv)) {
+error_set(errp, QERR_DEVICE_IN_USE,
bdrv_get_device_name(sd-bdrv));
+return;
+}
+
+vmstate_unregister(NULL, sd_vmstate, sd);
+sd_deinit_card(sd);
+}
+}
+
static void sd_initfn(Object *obj)
{
SDState *sd = SD_CARD(obj);
@@ -1859,6 +1899,8 @@ static void sd_initfn(Object *obj)
NULL, NULL, NULL);
object_property_add_str(OBJECT(sd), device-id, sd_devid_get,
sd_devid_set,
NULL);
+object_property_add(obj, eject, boolean, sd_is_ejected, sd_eject,
+NULL, NULL, NULL);
}
static const TypeInfo sd_type_info = {
Re: [Qemu-devel] [PATCH] SCSI-GENERIC: Specify the xfer direction for UNMAP/WRITESAME16/ATAPASSTHROUGH command
Il 28/04/2012 15:49, Ronnie Sahlberg ha scritto: scsi_cmd_xfer_mode() is used to specify the xfer direction for SCSI commands that come in from the guest. If the direction is set incorrectly this will eventually cause QEMU to kernel-panic the guest. Add UNMAP/WRITESAME16/ATAPASSTHROUGH as commands that send data to the device. Without this change, recent kernels will send both UNMAP as well as ATAPASSTHROUGH commands to any /dev/sg* device, which due to the incorrect xfer direction very quickly causes the guest kernel to crash. Example causing a crash without the patch applied: ./x86_64-softmmu/qemu-system-x86_64 -m 1024 -enable-kvm -cdrom linuxmint-12-gnome-dvd-64bit.iso -drive file=/dev/sg4,if=scsi,bus=0,unit=6 Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- hw/scsi-bus.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c index dbdb99c..bca2be8 100644 --- a/hw/scsi-bus.c +++ b/hw/scsi-bus.c @@ -920,6 +920,8 @@ static void scsi_cmd_xfer_mode(SCSICommand *cmd) case UPDATE_BLOCK: case WRITE_LONG_10: case WRITE_SAME_10: +case WRITE_SAME_16: +case UNMAP: case SEARCH_HIGH_12: case SEARCH_EQUAL_12: case SEARCH_LOW_12: @@ -929,6 +931,7 @@ static void scsi_cmd_xfer_mode(SCSICommand *cmd) case SEND_DVD_STRUCTURE: case PERSISTENT_RESERVE_OUT: case MAINTENANCE_OUT: +case ATA_PASSTHROUGH: cmd-mode = SCSI_XFER_TO_DEV; break; default: Applied to scsi-next, thanks! Paolo
Re: [Qemu-devel] [PATCH] main-loop: Fix build for w32 and w64
Il 27/04/2012 17:02, Stefan Weil ha scritto:
diff --git a/main-loop.c b/main-loop.c
index 0457bf2..24cf540 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -410,6 +410,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
int ret, i;
PollingEntry *pe;
WaitObjects *w = wait_objects;
+gint poll_timeout;
static struct timeval tv0;
/* XXX: need to suppress polling by better using win32 events */
@@ -424,12 +425,12 @@ static int os_host_main_loop_wait(uint32_t timeout)
if (nfds = 0) {
ret = select(nfds + 1, rfds, wfds, xfds, tv0);
if (ret != 0) {
-timeout = 0;
+/* TODO. */
Please leave timeout = 0 here and...
}
}
g_main_context_prepare(context, max_priority);
-n_poll_fds = g_main_context_query(context, max_priority, timeout,
+n_poll_fds = g_main_context_query(context, max_priority, poll_timeout,
poll_fds, ARRAY_SIZE(poll_fds));
g_assert(n_poll_fds = ARRAY_SIZE(poll_fds));
@@ -439,7 +440,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
}
qemu_mutex_unlock_iothread();
-ret = g_poll(poll_fds, n_poll_fds + w-num, timeout);
... here do:
if (poll_timeout == INFINITE || timeout poll_timeout) {
poll_timeout = timeout;
}
+ret = g_poll(poll_fds, n_poll_fds + w-num, poll_timeout);
qemu_mutex_lock_iothread();
if (ret 0) {
for (i = 0; i w-num; i++) {
Thanks for fixing the breakage.
Paolo
Re: [Qemu-devel] scsi-testsuite for virtio-scsi
Il 28/04/2012 03:45, Zhi Yong Wu ha scritto: It's based on qemu-iotests, so the structure is familiar but uses sg3-utils to send SCSI commands instead of qemu-io. I think that those tests should be ran in guest, qemu-iotests has been merged into QEMU upstream, and those tests in it are mainly executed in host. Then will these scsi tests be maintained out of qemu-iotests? Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos. Paolo
Re: [Qemu-devel] scsi-testsuite for virtio-scsi
On Sat, Apr 28, 2012 at 10:34 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 28/04/2012 03:45, Zhi Yong Wu ha scritto: It's based on qemu-iotests, so the structure is familiar but uses sg3-utils to send SCSI commands instead of qemu-io. I think that those tests should be ran in guest, qemu-iotests has been merged into QEMU upstream, and those tests in it are mainly executed in host. Then will these scsi tests be maintained out of qemu-iotests? Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos. qemu-test means qemu-iotest? jeos is Just Enough Operating System? QEMU has plan to add it? or you means that it refers to one guest. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] main-loop: Fix build for w32 and w64
Am 28.04.2012 16:34, schrieb Paolo Bonzini:
Il 27/04/2012 17:02, Stefan Weil ha scritto:
diff --git a/main-loop.c b/main-loop.c
index 0457bf2..24cf540 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -410,6 +410,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
int ret, i;
PollingEntry *pe;
WaitObjects *w = wait_objects;
+ gint poll_timeout;
static struct timeval tv0;
/* XXX: need to suppress polling by better using win32 events */
@@ -424,12 +425,12 @@ static int os_host_main_loop_wait(uint32_t timeout)
if (nfds = 0) {
ret = select(nfds + 1, rfds, wfds, xfds, tv0);
if (ret != 0) {
- timeout = 0;
+ /* TODO. */
Please leave timeout = 0 here and...
}
}
g_main_context_prepare(context, max_priority);
- n_poll_fds = g_main_context_query(context, max_priority, timeout,
+ n_poll_fds = g_main_context_query(context, max_priority, poll_timeout,
poll_fds, ARRAY_SIZE(poll_fds));
g_assert(n_poll_fds = ARRAY_SIZE(poll_fds));
@@ -439,7 +440,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
}
qemu_mutex_unlock_iothread();
- ret = g_poll(poll_fds, n_poll_fds + w-num, timeout);
... here do:
if (poll_timeout == INFINITE || timeout poll_timeout) {
poll_timeout = timeout;
}
With poll_timeout of type gint = int and INFINITE = 0x,
poll_timeout == INFINITE would never be true. What about
if (poll_timeout 0 || timeout poll_timeout) {
According to the glib documentation, a negative value indicates
an infinite timeout.
+ ret = g_poll(poll_fds, n_poll_fds + w-num, poll_timeout);
qemu_mutex_lock_iothread();
if (ret 0) {
for (i = 0; i w-num; i++) {
Thanks for fixing the breakage.
Paolo
Thanks for your review.
Stefan
[Qemu-devel] [PATCH 0/1] Add libiscsi as possible target for SCSI-GENERIC
List, Paolo, Please find a patch that plugs libiscsi as a possible target for SCSI-GENERIC, allowing a guest passthrough access to talk to the remote iscsi devices directly. When specifying a -drive that uses iscsi:// as well as setting if=scsi this passes all SCSI commands straight to iscsi and the remote target just like for /dev/sg* devices. Example: ./x86_64-softmmu/qemu-system-x86_64 -m 1024 -enable-kvm -cdrom /linuxmint-12-gnome-dvd-64bit.iso -device lsi -drive file=iscsi://10.1.1.125/iqn.ronnie.test/1,if=scsi,bus=0,unit=6 regards ronnie sahlberg
[Qemu-devel] [PATCH 1/2] SCSI: Add SCSI passthrough via scsi-generic to libiscsi
Update scsi-generic to allow passthrough of SG_IO scsi commands
to iscsi devices too in addition to the real scsi-generic devices.
Implement both bdrv_ioctl() and bdrv_aio_ioctl() in the iscsi backend,
emulate the SG_IO ioctl and pass the SCSI commands across to the
iscsi target.
This allows end-to-end passthrough of SCSI all the way from the guest,
to qemu, via scsi-generic, then libiscsi all the way to the iscsi target.
To activate this you need to specify interface type as scsi when
creating the device.
Example:
-drive file=iscsi://10.1.1.125/iqn.ronnie.test/1,if=scsi,bus=0,unit=5
Note, you can currently not boot a qemu guest from a 'if=scsi' device.
Note,
This only works when the host is linux, since the emulation relies on
definitions of SG_IO from the scsi-generic implementation in the
linux kernel.
It should be fairly easy to re-implement some structures similar enough
for non-linux hosts to do the same style of passthrough via a fake
scsi generic layer and libiscsi if need be.
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block.c | 18 --
block.h |1 +
block/iscsi.c | 191 -
block_int.h |1 +
hw/scsi-bus.c |7 ++-
hw/scsi-disk.c|4 +
hw/scsi-generic.c |4 +-
7 files changed, 216 insertions(+), 10 deletions(-)
diff --git a/block.c b/block.c
index c0c90f0..6b22d10 100644
--- a/block.c
+++ b/block.c
@@ -458,10 +458,11 @@ static int find_image_format(const char *filename,
BlockDriver **pdrv)
return ret;
}
-/* Return the raw BlockDriver * to scsi-generic devices or empty drives */
-if (bs-sg || !bdrv_is_inserted(bs)) {
+/* Return the raw BlockDriver * to scsi-generic devices,
+ iscsi devices or empty drives */
+if (bs-sg || bs-iscsi || !bdrv_is_inserted(bs)) {
bdrv_delete(bs);
-drv = bdrv_find_format(raw);
+drv = bdrv_find_format(bs-iscsi ? iscsi : raw);
if (!drv) {
ret = -ENOENT;
}
@@ -501,9 +502,10 @@ static int refresh_total_sectors(BlockDriverState *bs,
int64_t hint)
{
BlockDriver *drv = bs-drv;
-/* Do not attempt drv-bdrv_getlength() on scsi-generic devices */
-if (bs-sg)
+/* Do not attempt drv-bdrv_getlength() on scsi-generic/iscsi devices */
+if (bs-sg || bs-iscsi) {
return 0;
+}
/* query actual device if possible, otherwise just trust the hint */
if (drv-bdrv_getlength) {
@@ -578,6 +580,7 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
bs-encrypted = 0;
bs-valid_key = 0;
bs-sg = 0;
+bs-iscsi = 0;
bs-open_flags = flags;
bs-growable = 0;
bs-buffer_alignment = 512;
@@ -2260,6 +2263,11 @@ int bdrv_is_sg(BlockDriverState *bs)
return bs-sg;
}
+int bdrv_is_iscsi(BlockDriverState *bs)
+{
+return bs-iscsi;
+}
+
int bdrv_enable_write_cache(BlockDriverState *bs)
{
return bs-enable_write_cache;
diff --git a/block.h b/block.h
index f163e54..3d6309d 100644
--- a/block.h
+++ b/block.h
@@ -279,6 +279,7 @@ void bdrv_set_on_error(BlockDriverState *bs,
BlockErrorAction on_read_error,
BlockErrorAction bdrv_get_on_error(BlockDriverState *bs, int is_read);
int bdrv_is_read_only(BlockDriverState *bs);
int bdrv_is_sg(BlockDriverState *bs);
+int bdrv_is_iscsi(BlockDriverState *bs);
int bdrv_enable_write_cache(BlockDriverState *bs);
int bdrv_is_inserted(BlockDriverState *bs);
int bdrv_media_changed(BlockDriverState *bs);
diff --git a/block/iscsi.c b/block/iscsi.c
index eb49093..c7b4a29 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -33,10 +33,15 @@
#include iscsi/iscsi.h
#include iscsi/scsi-lowlevel.h
+#ifdef __linux__
+#include scsi/sg.h
+#include hw/scsi-defs.h
+#endif
typedef struct IscsiLun {
struct iscsi_context *iscsi;
int lun;
+enum scsi_inquiry_peripheral_device_type type;
int block_size;
unsigned long num_blocks;
} IscsiLun;
@@ -52,6 +57,9 @@ typedef struct IscsiAIOCB {
int canceled;
size_t read_size;
size_t read_offset;
+#ifdef __linux__
+sg_io_hdr_t *ioh;
+#endif
} IscsiAIOCB;
struct IscsiTask {
@@ -442,6 +450,140 @@ iscsi_aio_discard(BlockDriverState *bs,
return acb-common;
}
+#ifdef __linux__
+static void
+iscsi_aio_ioctl_cb(struct iscsi_context *iscsi, int status,
+ void *command_data, void *opaque)
+{
+IscsiAIOCB *acb = opaque;
+
+if (acb-canceled != 0) {
+qemu_aio_release(acb);
+scsi_free_scsi_task(acb-task);
+acb-task = NULL;
+return;
+}
+
+acb-status = 0;
+if (status 0) {
+error_report(Failed to ioctl(SG_IO) to iSCSI lun. %s,
+ iscsi_get_error(iscsi));
+acb-status = -EIO;
+}
+
+acb-ioh-driver_status = 0;
+acb-ioh-host_status = 0;
+acb-ioh-resid = 0;
+
+#define SG_ERR_DRIVER_SENSE0x08
+
+if (status == SCSI_STATUS_CHECK_CONDITION
[Qemu-devel] [PATCH] arm-semi: Rename SYS_XXX macros to TARGET_SYS_XXX (fixes compiler warning)
SYS_OPEN is already defined in stdio.h of MinGW-w64,
therefore the compiler complains when building for w64.
Adding the prefix TARGET_ avoids that macro redefinition.
xtensa-semi.c also uses the same prefix (but mixed case macros
TARGET_SYS_xxx instead of TARGET_SYS_XXX).
Signed-off-by: Stefan Weil s...@weilnetz.de
---
arm-semi.c | 86 ++--
1 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/arm-semi.c b/arm-semi.c
index 8debd19..88ca9bb 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -37,26 +37,26 @@
#include hw/arm-misc.h
#endif
-#define SYS_OPEN0x01
-#define SYS_CLOSE 0x02
-#define SYS_WRITEC 0x03
-#define SYS_WRITE0 0x04
-#define SYS_WRITE 0x05
-#define SYS_READ0x06
-#define SYS_READC 0x07
-#define SYS_ISTTY 0x09
-#define SYS_SEEK0x0a
-#define SYS_FLEN0x0c
-#define SYS_TMPNAM 0x0d
-#define SYS_REMOVE 0x0e
-#define SYS_RENAME 0x0f
-#define SYS_CLOCK 0x10
-#define SYS_TIME0x11
-#define SYS_SYSTEM 0x12
-#define SYS_ERRNO 0x13
-#define SYS_GET_CMDLINE 0x15
-#define SYS_HEAPINFO0x16
-#define SYS_EXIT0x18
+#define TARGET_SYS_OPEN0x01
+#define TARGET_SYS_CLOSE 0x02
+#define TARGET_SYS_WRITEC 0x03
+#define TARGET_SYS_WRITE0 0x04
+#define TARGET_SYS_WRITE 0x05
+#define TARGET_SYS_READ0x06
+#define TARGET_SYS_READC 0x07
+#define TARGET_SYS_ISTTY 0x09
+#define TARGET_SYS_SEEK0x0a
+#define TARGET_SYS_FLEN0x0c
+#define TARGET_SYS_TMPNAM 0x0d
+#define TARGET_SYS_REMOVE 0x0e
+#define TARGET_SYS_RENAME 0x0f
+#define TARGET_SYS_CLOCK 0x10
+#define TARGET_SYS_TIME0x11
+#define TARGET_SYS_SYSTEM 0x12
+#define TARGET_SYS_ERRNO 0x13
+#define TARGET_SYS_GET_CMDLINE 0x15
+#define TARGET_SYS_HEAPINFO0x16
+#define TARGET_SYS_EXIT0x18
#ifndef O_BINARY
#define O_BINARY 0
@@ -138,11 +138,11 @@ static void arm_semi_cb(CPUARMState *env, target_ulong
ret, target_ulong err)
} else {
/* Fixup syscalls that use nonstardard return conventions. */
switch (env-regs[0]) {
-case SYS_WRITE:
-case SYS_READ:
+case TARGET_SYS_WRITE:
+case TARGET_SYS_READ:
env-regs[0] = arm_semi_syscall_len - ret;
break;
-case SYS_SEEK:
+case TARGET_SYS_SEEK:
env-regs[0] = 0;
break;
default:
@@ -190,7 +190,7 @@ uint32_t do_arm_semihosting(CPUARMState *env)
nr = env-regs[0];
args = env-regs[1];
switch (nr) {
-case SYS_OPEN:
+case TARGET_SYS_OPEN:
if (!(s = lock_user_string(ARG(0
/* FIXME - should this error code be -TARGET_EFAULT ? */
return (uint32_t)-1;
@@ -211,14 +211,14 @@ uint32_t do_arm_semihosting(CPUARMState *env)
}
unlock_user(s, ARG(0), 0);
return ret;
-case SYS_CLOSE:
+case TARGET_SYS_CLOSE:
if (use_gdb_syscalls()) {
gdb_do_syscall(arm_semi_cb, close,%x, ARG(0));
return env-regs[0];
} else {
return set_swi_errno(ts, close(ARG(0)));
}
-case SYS_WRITEC:
+case TARGET_SYS_WRITEC:
{
char c;
@@ -233,7 +233,7 @@ uint32_t do_arm_semihosting(CPUARMState *env)
return write(STDERR_FILENO, c, 1);
}
}
-case SYS_WRITE0:
+case TARGET_SYS_WRITE0:
if (!(s = lock_user_string(args)))
/* FIXME - should this error code be -TARGET_EFAULT ? */
return (uint32_t)-1;
@@ -246,7 +246,7 @@ uint32_t do_arm_semihosting(CPUARMState *env)
}
unlock_user(s, args, 0);
return ret;
-case SYS_WRITE:
+case TARGET_SYS_WRITE:
len = ARG(2);
if (use_gdb_syscalls()) {
arm_semi_syscall_len = len;
@@ -262,7 +262,7 @@ uint32_t do_arm_semihosting(CPUARMState *env)
return -1;
return len - ret;
}
-case SYS_READ:
+case TARGET_SYS_READ:
len = ARG(2);
if (use_gdb_syscalls()) {
arm_semi_syscall_len = len;
@@ -280,17 +280,17 @@ uint32_t do_arm_semihosting(CPUARMState *env)
return -1;
return len - ret;
}
-case SYS_READC:
+case TARGET_SYS_READC:
/* XXX: Read from debug cosole. Not implemented. */
return 0;
-case SYS_ISTTY:
+case TARGET_SYS_ISTTY:
if (use_gdb_syscalls()) {
gdb_do_syscall(arm_semi_cb, isatty,%x, ARG(0));
return env-regs[0];
} else {
return isatty(ARG(0));
}
-case SYS_SEEK:
+case TARGET_SYS_SEEK:
if (use_gdb_syscalls()) {
gdb_do_syscall(arm_semi_cb, lseek,%x,%x,0, ARG(0), ARG(1));
return env-regs[0];
@@ -300,7 +300,7 @@ uint32_t do_arm_semihosting(CPUARMState *env)
Re: [Qemu-devel] [PATCH] arm-semi: Rename SYS_XXX macros to TARGET_SYS_XXX (fixes compiler warning)
On 28 April 2012 16:07, Stefan Weil s...@weilnetz.de wrote: SYS_OPEN is already defined in stdio.h of MinGW-w64, therefore the compiler complains when building for w64. Adding the prefix TARGET_ avoids that macro redefinition. xtensa-semi.c also uses the same prefix (but mixed case macros TARGET_SYS_xxx instead of TARGET_SYS_XXX). Signed-off-by: Stefan Weil s...@weilnetz.de Acked-by: Peter Maydell peter.mayd...@linaro.org -- PMM
[Qemu-devel] [Bug 988125] Re: Generated smb.conf needs to declare state directory
qemu-devel mail: http://article.gmane.org/gmane.comp.emulators.qemu/148378 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/988125 Title: Generated smb.conf needs to declare state directory Status in QEMU: New Bug description: The smb.conf generated by the userspace networking does not include a state directory directive. Samba therefore falls back to the default value. Since the user generally does not have write access to this path, smbd immediately crashes. I have attached a patch that adds the missing option. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/988125/+subscriptions
[Qemu-devel] [Bug 988128] Re: smbd crashes when called with smb ports = 0
Sent a patch to qemu-devel, http://article.gmane.org/gmane.comp.emulators.qemu/148378 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/988128 Title: smbd crashes when called with smb ports = 0 Status in QEMU: New Bug description: The smb.conf generated by qemu-kvm contains a smb ports = 0 directive. This causes at least version 3.6.4 of Samba to crash with [0] vostro:/tmp/qemu-smb.6836-0# smbd -i -s smb.conf Unable to setup corepath for smbd: Operation not permitted smbd version 3.6.4 started. Copyright Andrew Tridgell and the Samba Team 1992-2011 open_sockets_smbd: No sockets available to bind to. === Abnormal server exit: open_sockets_smbd() failed === BACKTRACE: 6 stack frames: #0 smbd(log_stack_trace+0x1a) [0x7fe50c14f8ba] #1 smbd(+0x6a0743) [0x7fe50c3bd743] #2 smbd(+0x6a0a41) [0x7fe50c3bda41] #3 smbd(main+0xa52) [0x7fe50be26d42] #4 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fe508ac0ead] #5 smbd(+0x10a6b9) [0x7fe50be276b9] Changing smb ports to a non-privilileged port works around the issue. I'd like to help fix this, but I am not sure what qemu-kvm's intention is here. Zero is not a valid port, and the smb.conf manpage does not describe any special meaning of zero here. I found that previous versions of samba apparently did not bind to any port if zero was specified - but in that case, how is qemu communicating with samba? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/988128/+subscriptions
[Qemu-devel] [Bug 988125] Re: Generated smb.conf needs to declare state directory
Wrong link, sorry. This is the right one: http://article.gmane.org/gmane.comp.emulators.qemu/148286/ -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/988125 Title: Generated smb.conf needs to declare state directory Status in QEMU: New Bug description: The smb.conf generated by the userspace networking does not include a state directory directive. Samba therefore falls back to the default value. Since the user generally does not have write access to this path, smbd immediately crashes. I have attached a patch that adds the missing option. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/988125/+subscriptions
[Qemu-devel] [PATCH] ppce500_spin: Replace assert by hw_error (fixes compiler warning)
The default case in function spin_read should never be reached, therefore the old code used assert(0) to abort QEMU. This does not work when QEMU is compiled with macro NDEBUG defined. In this case (and also when the compiler does not know that assert never returns), there is a compiler warning because of the missing return value. Using hw_error allows an improved error message and aborts always. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/ppce500_spin.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c index 960b7b0..57dc995 100644 --- a/hw/ppce500_spin.c +++ b/hw/ppce500_spin.c @@ -178,7 +178,7 @@ static uint64_t spin_read(void *opaque, target_phys_addr_t addr, unsigned len) case 4: return ldl_p(spin_p); default: -assert(0); +hw_error(ppce500: unexpected spin_read with len = %u, len); } } -- 1.7.9
Re: [Qemu-devel] scsi-testsuite for virtio-scsi
Il 28/04/2012 16:53, Zhi Yong Wu ha scritto: Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos. qemu-test means qemu-iotest? jeos is Just Enough Operating System? http://git.qemu.org/ has both qemu-test and qemu-jeos. Paolo
Re: [Qemu-devel] [PATCH v5 0/7] add fixed-width visitors and serialization tests/fixes
Il 27/04/2012 22:21, Michael Roth ha scritto: Some of these were being carried as part of Paolo's realize series due to some conflicts, but that looks to be targetted for 1.2 now, and there's a QMP visitor bug and a small issue with String visitor that were caught by the test infrastructure introduced here and fixed as part of this series, so I'd like to get this in for 1.1 Agreed. Paolo
Re: [Qemu-devel] [PATCH] arm-semi: Rename SYS_XXX macros to TARGET_SYS_XXX (fixes compiler warning)
On 28 April 2012 16:38, Peter Maydell peter.mayd...@linaro.org wrote: On 28 April 2012 16:07, Stefan Weil s...@weilnetz.de wrote: SYS_OPEN is already defined in stdio.h of MinGW-w64, therefore the compiler complains when building for w64. Adding the prefix TARGET_ avoids that macro redefinition. xtensa-semi.c also uses the same prefix (but mixed case macros TARGET_SYS_xxx instead of TARGET_SYS_XXX). Signed-off-by: Stefan Weil s...@weilnetz.de Acked-by: Peter Maydell peter.mayd...@linaro.org (by which I mean no objections, not I have taken it into any tree of mine; if you want this in before freeze you should get Blue to commit it I guess.) -- PMM
Re: [Qemu-devel] [PATCH] ppce500_spin: Replace assert by hw_error (fixes compiler warning)
Am 28.04.2012 17:52, schrieb Stefan Weil: The default case in function spin_read should never be reached, therefore the old code used assert(0) to abort QEMU. This does not work when QEMU is compiled with macro NDEBUG defined. In this case (and also when the compiler does not know that assert never returns), there is a compiler warning because of the missing return value. Using hw_error allows an improved error message and aborts always. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/ppce500_spin.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c index 960b7b0..57dc995 100644 --- a/hw/ppce500_spin.c +++ b/hw/ppce500_spin.c @@ -178,7 +178,7 @@ static uint64_t spin_read(void *opaque, target_phys_addr_t addr, unsigned len) case 4: return ldl_p(spin_p); default: -assert(0); +hw_error(ppce500: unexpected spin_read with len = %u, len); Thanks. Bonus points for using __func__. :) Andreas } } -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 4/7] qapi: String visitor, use %f represenation for floats
Am 27.04.2012 22:21, schrieb Michael Roth: Currently string-output-visitor formats floats as %g, which is nice in that trailing 0's are automatically truncated, but otherwise this causes some issues: - it 6 uses significant figures instead of 6 decimal places, which it uses 6 significant means something like 155777.5 (which even has an exact floating point representation) will be rounded to 155778 when converted to a string. - output will be presented in scientific notation when the normalized form requires a 10^x multiplier. Not a huge deal, but arguably less readable for command-line arguments. - due to using sig figs instead of hard-defined decimal places, it six figs? fails a lot of the test-visitor-serialization unit tests for floats. Instead, let's just use %f, which is what the QJSON and the QMP visitors use. Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com /-F -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] scsi-testsuite for virtio-scsi
On Sat, Apr 28, 2012 at 11:52 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 28/04/2012 16:53, Zhi Yong Wu ha scritto: Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos. qemu-test means qemu-iotest? jeos is Just Enough Operating System? http://git.qemu.org/ has both qemu-test and qemu-jeos. OK. qemu-test isn't qemu-iotest and it is some tests based on qtester. I got what qemu-jeos mean. thanks. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH 0/4] tracetool: Python 2.4 compatibility fixes
Am 27.04.2012 16:23, schrieb Stefan Hajnoczi: The new Python tracetool implementation works great but does not run on older Python installations. This series takes us back to the happy days of Python 2.4, which was released in 2004. As a result tracetool should now work again on Mac OS X v10.5.8, OpenIndiana oi_151a, Solaris 10 U9, and Red Hat Enterprise Linux 5. Works fine on OSX v10.5.8 and v10.6.8 and on oi_151a3 but still fails on sol10u9 using python2.4 (2.4.6). Same error as before - does it maybe need some additional module installation or something? I'll try setting up sol10u10 to check there. Andreas Thanks for everyone's help testing on these platforms. Stefan Hajnoczi (4): tracetool: use Python 2.4-compatible exception handling syntax tracetool: use Python 2.4-compatible __import__() arguments tracetool: avoid str.rpartition() Python 2.5 function configure: check for supported Python 2.x versions configure |7 --- scripts/tracetool.py |4 ++-- scripts/tracetool/__init__.py | 19 +++ 3 files changed, 17 insertions(+), 13 deletions(-)
Re: [Qemu-devel] [PATCH v2 0/6] prep: some fixes and Super I/O emulation
Patch 1 has been applied to prep-up branch by Andreas Patch 5 has been applied to master by malc Ping. Hervé Hervé Poussineau a écrit : Hi, Patches 1 to 3 implement the pc87312 Super I/O chip. This patch has been tested on PReP emulation and on IBM 40p (not yet committed). Missing part is dynamic reconfiguration of devices (serial, parallel, floppy, IDE). However, it is not strictly needed as initial configuration can be changed with a property. Patch 4 completes the qdev-ification of Raven PCI host, where INTA register was mistakenly left in PReP machine. Patches 5 and 6 fix PC speaker in PReP machine, which had never worked. This patchset is based on Andreas prep-up branch. Changes v1 - v2: - removed patches already committed to prep-up branch - removed patch which changes the default CPU of prep machine - changed patches 2/3 according to remarks of Paolo and Andreas - added patches 4 to 6 Hervé Poussineau (6): isa: add isa_bus_from_device() method prep: add pc87312 Super I/O emulation prep: use pc87312 Super I/O chip instead of collection of random ISA devices prep: move int-ack register from PReP to Raven PCI emulation pcspk: initialize PC speaker if compiled in prep: initialize pc speaker Makefile.objs |1 + arch_init.c |2 +- default-configs/ppc-softmmu.mak |2 + hw/isa.h|5 + hw/pc87312.c| 405 +++ hw/ppc_prep.c | 78 +--- hw/prep_pci.c | 14 ++ trace-events|8 + 8 files changed, 446 insertions(+), 69 deletions(-) create mode 100644 hw/pc87312.c
Re: [Qemu-devel] [PATCH v2 0/6] prep: some fixes and Super I/O emulation
Am 28.04.2012 20:11, schrieb Hervé Poussineau: Patch 1 has been applied to prep-up branch by Andreas Patch 5 has been applied to master by malc Ping. v2 series is on my radar for the 1.1 PULL, but I still wasn't happy with the pc87312 patch, so I'd prefer to defer that to 1.2. Andreas Hervé Poussineau a écrit : Hi, Patches 1 to 3 implement the pc87312 Super I/O chip. This patch has been tested on PReP emulation and on IBM 40p (not yet committed). Missing part is dynamic reconfiguration of devices (serial, parallel, floppy, IDE). However, it is not strictly needed as initial configuration can be changed with a property. Patch 4 completes the qdev-ification of Raven PCI host, where INTA register was mistakenly left in PReP machine. Patches 5 and 6 fix PC speaker in PReP machine, which had never worked. This patchset is based on Andreas prep-up branch. Changes v1 - v2: - removed patches already committed to prep-up branch - removed patch which changes the default CPU of prep machine - changed patches 2/3 according to remarks of Paolo and Andreas - added patches 4 to 6 Hervé Poussineau (6): isa: add isa_bus_from_device() method prep: add pc87312 Super I/O emulation prep: use pc87312 Super I/O chip instead of collection of random ISA devices prep: move int-ack register from PReP to Raven PCI emulation pcspk: initialize PC speaker if compiled in prep: initialize pc speaker Makefile.objs |1 + arch_init.c |2 +- default-configs/ppc-softmmu.mak |2 + hw/isa.h|5 + hw/pc87312.c| 405 +++ hw/ppc_prep.c | 78 +--- hw/prep_pci.c | 14 ++ trace-events|8 + 8 files changed, 446 insertions(+), 69 deletions(-) create mode 100644 hw/pc87312.c
Re: [Qemu-devel] [PATCH v2 4/6] prep: move int-ack register from PReP to Raven PCI emulation
Am 14.04.2012 22:48, schrieb Hervé Poussineau:
Register is one byte-wide (as per specification), so there is no need to
specify endianness.
The region was 4 bytes before, now it's 1. What happens when a 4-byte
read is attempted at that address? Do we need to specify the valid
widths for the MemoryRegion? Or is such a read constructed from this
region and (assuming) the return value of an unassigned read?
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 8b29da9..43847f5 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -25,10 +25,12 @@
#include hw.h
#include pci.h
#include pci_host.h
+#include pc.h
Is that for pic_read_irq()?
Andreas
#include exec-memory.h
typedef struct PRePPCIState {
PCIHostState host_state;
+MemoryRegion intack;
qemu_irq irq[4];
} PREPPCIState;
@@ -67,6 +69,16 @@ static const MemoryRegionOps PPC_PCIIO_ops = {
.endianness = DEVICE_LITTLE_ENDIAN,
};
+static uint64_t ppc_intack_read(void *opaque, target_phys_addr_t addr,
+unsigned int size)
+{
+return pic_read_irq(isa_pic);
+}
+
+static const MemoryRegionOps PPC_intack_ops = {
+.read = ppc_intack_read,
+};
+
static int prep_map_irq(PCIDevice *pci_dev, int irq_num)
{
return (irq_num + (pci_dev-devfn 3)) 1;
@@ -110,6 +122,8 @@ static int raven_pcihost_init(SysBusDevice *dev)
memory_region_init_io(h-mmcfg, PPC_PCIIO_ops, s, pciio, 0x0040);
memory_region_add_subregion(address_space_mem, 0x8080, h-mmcfg);
+memory_region_init_io(s-intack, PPC_intack_ops, s, pci-intack, 1);
+memory_region_add_subregion(address_space_mem, 0xbff0, s-intack);
pci_create_simple(bus, 0, raven);
return 0;
[Qemu-devel] [PATCH] vga: Don't switch to 1 x 1 character text screen
Initially, vga_get_text_resolution returns a text resolution of 1 x 1
(vga register values are 0).
This is visible during MIPS Malta boot with SDL. It also occurs with the
i386 or x86_64 system emulation when it runs in single step mode:
QEMU changes the size of the SDL window to the smallest possible value
which is supported by the window manager. As this is not the calculated
size, QEMU switches to scaled mode. When the BIOS or the VGA driver sets
the normal text resolution, the window stays small and displays
microscopic characters.
Ignoring text resolutions of 1 x 1 or less avoids these problems.
A similar workaround already exists for too large resolutions.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/vga.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index f80860c..5824f85 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1327,6 +1327,10 @@ static void vga_draw_text(VGACommonState *s, int
full_update)
line_offset = s-line_offset;
vga_get_text_resolution(s, width, height, cw, cheight);
+if ((height * width) = 1) {
+/* better than nothing: exit if transient size is too small */
+return;
+}
if ((height * width) CH_ATTR_SIZE) {
/* better than nothing: exit if transient size is too big */
return;
--
1.7.9
Re: [Qemu-devel] [PATCH v2 6/6] prep: initialize pc speaker
Am 14.04.2012 22:51, schrieb Hervé Poussineau: Speaker init has been added in 506b7ddf889312659b36c667f7ae17bc9e909418, but audio subsystem init was missing. Signed-off-by: Hervé Poussineau hpous...@reactos.org Thanks, applied to prep-up: http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep-up Andreas
Re: [Qemu-devel] [PATCH v2 4/6] prep: move int-ack register from PReP to Raven PCI emulation
Andreas Färber a écrit : Am 14.04.2012 22:48, schrieb Hervé Poussineau: Register is one byte-wide (as per specification), so there is no need to specify endianness. The region was 4 bytes before, now it's 1. What happens when a 4-byte read is attempted at that address? Do we need to specify the valid widths for the MemoryRegion? Or is such a read constructed from this region and (assuming) the return value of an unassigned read? At first, Linux and IBM 40p firmware only attempt a 1-byte read to this address. In the case a 4-byte read is attempted to address 0xbff0, memory region layer will still call ppc_intack_read() function with size=4. However, by changing region size from 4 to 1, you prevent direct reads of 0xbff1..0xbff3, which I think is not a big loss (and is closer to specification). diff --git a/hw/prep_pci.c b/hw/prep_pci.c index 8b29da9..43847f5 100644 --- a/hw/prep_pci.c +++ b/hw/prep_pci.c @@ -25,10 +25,12 @@ #include hw.h #include pci.h #include pci_host.h +#include pc.h Is that for pic_read_irq()? Yes. All i8259-related functions are declared in pc.h Hervé
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Sat, Apr 28, 2012 at 00:08, Gleb Natapov g...@redhat.com wrote: On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: But, if qemu could be changed, could it be made to match the PIIX4 datasheet? We try not to change QEMU in non backwards compatible way. We can implement PMBA and start using address there if FW writes into it, but, as I noted before, OVMF will have to be changed anyways since 0x400 address is already occupied and pci/cpu/memory hotplug/unplug functionality uses additional IO space not documented by PIIX4 spec. The pci/cpu/memory hotplug/unplug functionality is also using hard coded addresses in the 0x400 range? And, 0xb000 would be the recommended PM base address? It would be better for OVMF to treat QEMU like separate platform, that behave almost, but not exactly like, real HW. Yes, it does seem like that will be required here. -Jordan
