[Qemu-devel] Re: [PATCH 0/8] vlan cleanup
Miguel Di Ciurcio Filho wrote: This series removes the vlan stuff without mercy. I've tried to make the steps as small as possible, but the last one is huge. I did some basic tests and networking is still working, so reviews are welcome :-D Sorry, this is a bit too rude. This not only removes the vlan model, something one may talk about, but also the innocent socket back-ends and the useful pcap dump support. Socket back-ends allow quick and easy unprivileged inter-VM network setups. Nothing for production systems, but useful for testing purposes on boxes where taps are not allowed or unhandy to configure. The dump client helps to debug user mode guest networks, namely slirp which you did not remove. If that should become the only use case for vlans with more than 2 nodes, we could think about making it a special feature of backend devices. I'm open for cleanups here, but they do require a bit mercy - and should also mention the reason. Jan A next step would be to rename VLANClientState and other structures to more proper names. Regards, Miguel --- Miguel Di Ciurcio Filho (8): vlan cleanup: update documentation vlan cleanup: update options vlan cleanup: do not depend on socket and dump vlan cleanup: do not build socket and dump vlan cleanup: remove socket.h and socket.c vlan cleanup: remove dump.h and dump.c vlan cleanup: remove legacy monitor commands vlan cleanup: remove usage of VLANState Makefile.objs|2 - hw/qdev-properties.c | 39 hw/qdev.c|2 - hw/qdev.h|5 - hw/xen_devconfig.c |8 +- hw/xen_nic.c |1 - net.c| 425 +++-- net.h| 12 - net/dump.c | 159 -- net/dump.h | 33 --- net/slirp.c | 54 ++ net/slirp.h |3 +- net/socket.c | 573 -- net/socket.h | 33 --- net/tap.c|9 +- net/tap.h|2 +- net/vde.c|8 +- net/vde.h|2 +- qemu-common.h|1 - qemu-doc.texi| 24 +-- qemu-monitor.hx | 36 +--- qemu-options.hx | 120 ++- 22 files changed, 89 insertions(+), 1462 deletions(-) delete mode 100644 net/dump.c delete mode 100644 net/dump.h delete mode 100644 net/socket.c delete mode 100644 net/socket.h signature.asc Description: OpenPGP digital signature
[Qemu-devel] [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
New links: http://dl3.ideco-software.ru/IdecoICS/IdecoICS_343_102.iso http://dl1.ideco-software.ru/IdecoICS/IdecoICS_343_102.iso http://dl2.ideco-software.ru/IdecoICS/IdecoICS_343_102.iso For some reason the fall of KVM are much rarer, though earlier it fell each time. I noticed that more often than not, it crashes when KVM is in the background, and I say, sitting in the browser. It seems, that it is true race-condition. $ ./kvm --version QEMU emulator version 0.12.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard Also, I have checked - cache=writeback does not work not in ide, nor in scsi. I mean that write cache does not work, and writing work as writethrough. In old version of KVM (qemu-kvm-0.12.3) there is no such bug. -- KVM segmentation fault, using SCSI+writeback and linux 2.4 guest https://bugs.launchpad.net/bugs/595438 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Confirmed Bug description: I Use Ubuntu 32 bit 10.04 with standard KVM. I have Intel E7600 @ 3.06GHz processor with VMX In this system I Run: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait -monitor chardev:monitor -boot d -drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback -net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus .iso image contain custom distro of 2.4-linux kernel based system. During install process (when .tar.gz actively unpacked), kvm dead with segmentation fault. And ONLY when I choose scsi virtual disk and writeback simultaneously. But, writeback+ide, writethrough+scsi works OK. I use qcow2. It seems, that qcow does not have such problems. Virtual machine get down at random time during file copy. It seems, when qcow2 file size need to be expanded.
[Qemu-devel] Re: KVM Call agenda for July 13th
On 07/12/2010 05:57 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. kvm testsuite -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] Re: [PATCH RFC] e1000: fix access 4 bytes beyond buffer end
On Mon, Jul 12, 2010 at 06:00:20PM -0500, Anthony Liguori wrote:
On 07/12/2010 05:42 PM, Michael S. Tsirkin wrote:
On Mon, Jul 12, 2010 at 04:07:21PM -0500, Anthony Liguori wrote:
On 07/12/2010 12:48 PM, Michael S. Tsirkin wrote:
We do range check for size, and get size as buffer,
but copy size + 4 bytes (4 is for FCS).
Let's copy size bytes but put size + 4 in length.
Signed-off-by: Michael S. Tsirkinm...@redhat.com
I think I'd feel slightly better if we zero'd out the FCS before
writing it to the guest. It is potentially a data leak.
Regards,
Anthony Liguori
I am guessing there's no chance guest actually looks
at this data, otherwise it won't match and we'd get errors, right?
That's my assumption too. Although I believe there are some known
issues with e1000 and certain versions of Windows and the Microsoft
built-in driver. Maybe this is why those drivers don't work and the
Intel drivers do?
At least one known issue with Windows drivers to me is that they
sometimes (on resume from S4 at least) enable interrupts before setup
irq routing, so if interrupt is generated in the wrong time it hangs the
guest. I guess it works on real HW for them because line speed
negotiation takes non-zero time.
Regards,
Anthony Liguori
---
Anthony, Alex, please review.
hw/e1000.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/e1000.c b/hw/e1000.c
index 0da65f9..70aba11 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -649,7 +649,6 @@ e1000_receive(VLANClientState *nc, const uint8_t *buf,
size_t size)
}
rdh_start = s-mac_reg[RDH];
-size += 4; // for the header
do {
if (s-mac_reg[RDH] == s-mac_reg[RDT] s-check_rxov) {
set_ics(s, 0, E1000_ICS_RXO);
@@ -663,7 +662,7 @@ e1000_receive(VLANClientState *nc, const uint8_t *buf,
size_t size)
if (desc.buffer_addr) {
cpu_physical_memory_write(le64_to_cpu(desc.buffer_addr),
(void *)(buf + vlan_offset), size);
-desc.length = cpu_to_le16(size);
+desc.length = cpu_to_le16(size + 4 /* for FCS */);
desc.status |= E1000_RXD_STAT_EOP|E1000_RXD_STAT_IXSM;
} else // as per intel docs; skip descriptors with null buf addr
DBGOUT(RX, Null RX descriptor!!\n);
--
Gleb.
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
Avi Kivity a écrit : On 07/12/2010 05:57 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.12.n+1 I won't be at the KVM call, but I can work on that in the next days. Basically the stable tree already contains a lot of fixes and we can do a call for patches for this release. One week should be enough, so that we can have the release at the end of next week (a few technical days are needed in addition). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] how to add one pcie device to qemu
Thanks, Yamahata sam, then, could you give me so some advice about how to add one pcie device to it? I studied the source code, but still have no idea, I'm thinking that add one pcie device through pci_bridge_qdev_register() and device_init(), just like downstream and upstream, is it available? thanks. On Tue, Jul 6, 2010 at 11:22 AM, Isaku Yamahata yamah...@valinux.co.jpwrote: I'm using debian lenny. $ gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Tue, Jul 06, 2010 at 10:23:45AM +0800, Lisa Lei wrote: On Wed, Jun 30, 2010 at 9:48 PM, Isaku Yamahata yamah...@valinux.co.jp wrote: On Wed, Jun 30, 2010 at 04:10:02PM +0800, Lisa Lei wrote: Hi, I'm finding the solution of how to add one pcie device which emulated by systemc to qemu, such as net card. I noticed that you've been working on Q35 support for qemu, and the status of pcie port emulator is working on April, can it be used now? thanks. The public repo for q35 support is avaiable as follows. http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02066.html I'm now trying to merge those patches to qemu upstream, but not finished yet. thanks, Thanks for your reply, I have got the sourcecode now, but compile failed, can you tell me the gcc version, and qemu version based on? my gcc version is 3.4.6. thanks. -- yamahata -- yamahata
[Qemu-devel] Hantera obetalda fakturor
Om du har problem med att läsa detta e-postmeddelande, klicka här (http://www.anp.se/newsletter/787687/444059437941455D4B7142445C43) för en webb-version. Vårt nyhetsbrev skickas automatiskt till våra kunder och intressenter. Vill du inte ha detta nyhetsbrev framöver, klicka här för att avprenumerera (http://www.anp.se/oa/787687/444059437941455D4B7142445C43). Nyhetsbrev 32/2010Detta nyhetsbrev är skickat till: qemu-devel@nongnu.org (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.sefrom=172191075prefix=dm) (http://www.anp.se/taf/787687/444059437941455D4B7142445C43) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_newsletters.aspfrom=172191075prefix=dm) (http://www.anp.se/newsletter.asp?sqid=787687sid=444059437941455D4B7142445C43print=true) Hantera obetalda fakturor Många företag skulle kunna få betalt betydligt fortare genom att agera med snabbhet och ihärdighet. Inledningsvis skickas normalt betalningspåminnelser. Om skulden ändå inte betalas in finns det möjlighet att förmå kunden att betala genom inkassoåtgärder, vilka går utmärkt att vidta på egen hand. Hos oss finner du dokument som kan hjälpa dig på vägen. Med DokuMeras Företagspaket (http://www.dokumera.se/visa-kategorier.asp?id=1321) får du tillgång till fler än 1300 avtal, checklistor, policys, expertsvar och mycket annat som underlättar och juridiskt säkerställer arbetet i ditt företag. Veckans dokument Påminnelse nr 1 (http://www.dokumera.se/betalningspaminnelse_nr_1_460_dd.html) Påminnelse nr 2 (http://www.dokumera.se/betalningspaminnelse_nr_2_463_dd.html) Dröjsmålsränteberäkning (http://www.dokumera.se/drojsmalsranteberakning_referensrantebaserad_1190_dd.html) Fler mallar (http://www.dokumera.se/krav_2887_dc.html) Sommartider DokuMeras nyhetsbrev tar nu sommar- uppehåll. Kontoret har dock öppet som vanligt hela sommaren. Ha en riktigt trevlig sommar, så ses vi igen i augusti! (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/foretagspaketet_1321_dc.htmlfrom=172191075prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_ppdviewer.aspfrom=172191075prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/styckvisa_dokumentmallar_1330_dc.htmlfrom=172191075prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_contactusmessage.aspfrom=172191075prefix=dm) För en kostnadsfri exklusiv presentation av hur DokuMera kan spara tiotusentals kronor åt just mitt företag. Givetvis är du varmt välkommen att ringa oss på 08-664 04 50. Innehållet i nyhetsbrev ska inte tolkas som ett åtagande från DokuMeras sida. Informationen sänds ut i befintligt skick, utan garantier och digitala signaturer.
[Qemu-devel] Re: [OpenBIOS] [commit] r791 - in trunk/openbios-devel: fs/grubfs include/fs packages
On Tue, Jun 08, 2010 at 10:59:09PM +0200, repository service wrote: Author: mcayland Date: Tue Jun 8 22:59:08 2010 New Revision: 791 URL: http://tracker.coreboot.org/trac/openbios/changeset/791 Log: As documented on the mailing lists, change the interposition order of the disk packages from: cdrom - deblocker - disk-label - (misc-files | sun-parts | pc-parts | mac-parts) to: cdrom - deblocker - disk-label - (sun-parts | pc-parts | mac-parts) - misc-files This makes the overall code much simpler, since instead of passing get-info structures between the different layers to work out the current device offset, each package can simply maintain its own offsets and bubble them back up to the parent. There are also many, many bugfixes present is patch, some of which are given below: - Add debugging in /packages/misc-files, augment debugging in all other disk packages - Fix alignment issue in /packages/pc-parts so it works correctly on strictly align archs, e.g. SPARC64 - Fix parsing of [id,][filename] arguments to load (in preparation for next patch set) - Fix byte-swapping issues in /packages/mac-parts (in theory it should now work regardless of endian) Unfortunately this commit has broken PowerPC boot using the Quik bootloader. CD-ROM boot is not affected. This can easily be reproduced using the image from: http://people.debian.org/~aurel32/qemu/powerpc/debian_lenny_powerpc_small.qcow2 I have tried with the latest available revision, and the problem is still there. Does anyone has an idea of the problem before I start debugging it? [CCed: qemu-devel@nongnu.org as this version is now used in QEMU] -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On 07/13/2010 09:57 AM, Aurelien Jarno wrote: Avi Kivity a écrit : On 07/12/2010 05:57 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.12.n+1 I won't be at the KVM call, but I can work on that in the next days. Basically the stable tree already contains a lot of fixes and we can do a call for patches for this release. One week should be enough, so that we can have the release at the end of next week (a few technical days are needed in addition). Thanks. I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). -- error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm
** Tags added: armel -- qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm https://bugs.launchpad.net/bugs/604872 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: New Bug description: Binary package hint: qemu-kvm As I'm now implementing the support for creating a rootstock rootfs without requiring root, I need to run the deboostrap' second stage inside a VM, to correctly install the packages into the rootfs. qemu-system-arm fails right after debootstrap finish the second stage, giving a segmentation fault. Command: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot -nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 -append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 init=/bin/installer' Uncompressing Linux. done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-21-versatile (bui...@cushaw) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 2.6.32-21.32-versatile 2.6.32.11+drm33.2) ... I: Base system installed successfully. I: Starting basic services in VM Segmentation fault (core dumped) [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc ip cf6ba8fc sp 7fffd0e68680 error 14 Image: * rootfs: http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 1d063ac8a65c798bb004cd1c4c7970c5) * kernel: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86). Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4 Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 Uname: Linux 2.6.35-6-generic x86_64 Architecture: amd64 Date: Mon Jul 12 18:55:35 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 2764CTO PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: qemu-kvm dmi.bios.date: 04/19/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 7UET86WW (3.16 ) dmi.board.name: 2764CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2764CTO dmi.product.version: ThinkPad T400 dmi.sys.vendor: LENOVO
[Qemu-devel] [PATCH 2/2][Tracing] Add trace-file command to open/close/flush trace file
This patch adds the trace-file command:
trace-file [on|off|flush]
Open, close, or flush the trace file. If no argument is given,
the status of the trace file is displayed.
The trace file is turned on by default but is only written out when the
trace buffer becomes full. The flush operation can be used to force
write out at any time.
Turning off the trace file does not change the state of trace events;
tracing will continue to the trace buffer. When the trace file is off,
use info trace to display the contents of the trace buffer in memory.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
monitor.c | 17 +
qemu-monitor.hx | 14 ++
simpletrace.c | 45 +
tracetool |3 +++
4 files changed, 75 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 090e13c..1e35a6b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -540,6 +540,23 @@ static void do_change_trace_event_state(Monitor *mon,
const QDict *qdict)
bool new_state = qdict_get_bool(qdict, option);
change_trace_event_state(tp_name, new_state);
}
+
+static void do_trace_file(Monitor *mon, const QDict *qdict)
+{
+const char *op = qdict_get_try_str(qdict, op);
+
+if (!op) {
+st_print_trace_file_status((FILE *)mon, monitor_fprintf);
+} else if (!strcmp(op, on)) {
+st_set_trace_file_enabled(true);
+} else if (!strcmp(op, off)) {
+st_set_trace_file_enabled(false);
+} else if (!strcmp(op, flush)) {
+st_flush_trace_buffer();
+} else {
+monitor_printf(mon, unexpected argument \%s\\n, op);
+}
+}
#endif
static void user_monitor_complete(void *opaque, QObject *ret_data)
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index c5ba3d2..25887bd 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -273,6 +273,20 @@ STEXI
@findex trace-event
changes status of a trace event
ETEXI
+
+{
+.name = trace-file,
+.args_type = op:s?,
+.params = op [on|off|flush],
+.help = open, close, or flush trace file,
+.mhandler.cmd = do_trace_file,
+},
+
+STEXI
+...@item trace-file on|off|flush
+...@findex trace-file
+Open, close, or flush the trace file. If no argument is given, the status of
the trace file is displayed.
+ETEXI
#endif
{
diff --git a/simpletrace.c b/simpletrace.c
index 29fd6a9..71110b3 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -20,6 +20,13 @@ enum {
static TraceRecord trace_buf[TRACE_BUF_LEN];
static unsigned int trace_idx;
static FILE *trace_fp;
+static bool trace_file_enabled = true;
+
+void st_print_trace_file_status(FILE *stream, int (*stream_printf)(FILE
*stream, const char *fmt, ...))
+{
+stream_printf(stream, Trace file \ CONFIG_TRACE_FILE \ %s.\n,
+ getpid(), trace_file_enabled ? on : off);
+}
static bool open_trace_file(void)
{
@@ -34,22 +41,52 @@ static bool open_trace_file(void)
return trace_fp != NULL;
}
-static void flush_trace_buffer(void)
+static void flush_trace_file(void)
{
+/* If the trace file is not open yet, open it now */
if (!trace_fp) {
-if (open_trace_file()) {
-atexit(flush_trace_buffer);
+if (!open_trace_file()) {
+/* Avoid repeatedly trying to open file on failure */
+trace_file_enabled = false;
+return;
}
+atexit(st_flush_trace_buffer);
}
+
if (trace_fp) {
size_t unused; /* for when fwrite(3) is declared warn_unused_result */
unused = fwrite(trace_buf, trace_idx * sizeof(trace_buf[0]), 1,
trace_fp);
}
+}
+
+void st_flush_trace_buffer(void)
+{
+if (trace_file_enabled) {
+flush_trace_file();
+}
/* Discard written trace records */
trace_idx = 0;
}
+void st_set_trace_file_enabled(bool enable)
+{
+if (enable == trace_file_enabled) {
+return; /* no change */
+}
+
+/* Flush/discard trace buffer */
+st_flush_trace_buffer();
+
+/* To disable, close trace file */
+if (!enable) {
+fclose(trace_fp);
+trace_fp = NULL;
+}
+
+trace_file_enabled = enable;
+}
+
static void trace(TraceEventID event, unsigned long x1,
unsigned long x2, unsigned long x3,
unsigned long x4, unsigned long x5)
@@ -76,7 +113,7 @@ static void trace(TraceEventID event, unsigned long x1,
rec-x5 = x5;
if (++trace_idx == TRACE_BUF_LEN) {
-flush_trace_buffer();
+st_flush_trace_buffer();
}
}
diff --git a/tracetool b/tracetool
index 8d8f27c..999ef7e 100755
--- a/tracetool
+++ b/tracetool
@@ -141,6 +141,9 @@ void trace4(TraceEventID event, unsigned long x1, unsigned
long x2, unsigned lon
void trace5(TraceEventID event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4, unsigned long x5);
void st_print_trace(FILE *stream, int (*stream_printf)(FILE *stream, const
[Qemu-devel] [PATCH 1/2][Tracing] Specify trace file name
From: Prerna Saxena pre...@linux.vnet.ibm.com
Allow users to specify a file for trace-outputs at configuration.
Also, allow trace files to be annotated by pid so each qemu instance has
unique traces.
The trace file name can be passed as a config option:
--trace-file=/path/to/file
(Default : /tmp/trace )
At runtime, the pid of the qemu process is appended to the filename so
that mutiple qemu instances do not have overlapping logs.
Eg : /tmp/trace-1234 for qemu launched with pid 1234.
I have yet to test this on windows. getpid() is used at many places
in code(including vnc.c), so I'm hoping this would be okay too.
Edited-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
Prerna, I have modified this patch that you wrote and together with patch 2/2
it provides control over the trace file. The changes include:
* Set trace_file earlier in ./configure so $trace_file-pid displays
correctly.
* Introduce open_trace_file() helper function to handle file naming.
configure | 13 +
simpletrace.c | 16 ++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 02bf602..fe1b027 100755
--- a/configure
+++ b/configure
@@ -313,6 +313,7 @@ check_utests=no
user_pie=no
zero_malloc=
trace_backend=nop
+trace_file=/tmp/trace
# OS specific
if check_define __linux__ ; then
@@ -470,6 +471,7 @@ if test $mingw32 = yes ; then
bindir=\${prefix}
sysconfdir=\${prefix}
confsuffix=
+ trace_file=trace
fi
# find source path
@@ -517,6 +519,8 @@ for opt do
;;
--trace-backend=*) trace_backend=$optarg
;;
+ --trace-file=*) trace_file=$optarg
+ ;;
--enable-gprof) gprof=yes
;;
--static)
@@ -876,6 +880,9 @@ echo --disable-docs disable documentation
build
echo --disable-vhost-net disable vhost-net acceleration support
echo --enable-vhost-net enable vhost-net acceleration support
echo --trace-backend=BTrace backend nop simple ust
+echo --trace-file=NAMEFull PATH,NAME of file to store traces
+echoDefault:/tmp/trace-pid
+echoDefault:trace-pid on Windows
echo
echo NOTE: The object files are built at the place where configure is
launched
exit 1
@@ -2132,6 +2139,7 @@ echo fdatasync $fdatasync
echo uuid support $uuid
echo vhost-net support $vhost_net
echo Trace backend $trace_backend
+echo Trace output file $trace_file-pid
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
@@ -2387,6 +2395,11 @@ fi
if test $trace_backend = ust; then
LIBS=-lust $LIBS
fi
+# Set the appropriate trace file.
+if test $trace_backend = simple; then
+ trace_file=\$trace_file-%u\
+fi
+echo CONFIG_TRACE_FILE=$trace_file $config_host_mak
echo TOOLS=$tools $config_host_mak
echo ROMS=$roms $config_host_mak
echo MAKE=$make $config_host_mak
diff --git a/simpletrace.c b/simpletrace.c
index ed20d36..29fd6a9 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -21,11 +21,23 @@ static TraceRecord trace_buf[TRACE_BUF_LEN];
static unsigned int trace_idx;
static FILE *trace_fp;
+static bool open_trace_file(void)
+{
+char *filename;
+
+if (asprintf(filename, CONFIG_TRACE_FILE, getpid()) 0) {
+return false;
+}
+
+trace_fp = fopen(filename, w);
+free(filename);
+return trace_fp != NULL;
+}
+
static void flush_trace_buffer(void)
{
if (!trace_fp) {
-trace_fp = fopen(/tmp/trace.log, w);
-if (trace_fp) {
+if (open_trace_file()) {
atexit(flush_trace_buffer);
}
}
--
1.7.1
Re: [Qemu-devel] Re: [OpenBIOS] [commit] r791 - in trunk/openbios-devel: fs/grubfs include/fs packages
Aurelien Jarno wrote: Unfortunately this commit has broken PowerPC boot using the Quik bootloader. CD-ROM boot is not affected. This can easily be reproduced using the image from: http://people.debian.org/~aurel32/qemu/powerpc/debian_lenny_powerpc_small.qcow2 I have tried with the latest available revision, and the problem is still there. Does anyone has an idea of the problem before I start debugging it? [CCed: qemu-devel@nongnu.org as this version is now used in QEMU] Ah okay, that'll be part of my recent tidy-up work - let me take a quick look. Thanks for the test image as that will really help :) ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: [Qemu-devel] how to add one pcie device to qemu
Hi Lisa. If your target device isn't pcie port switch device, pci_bridge_xxx() aren't what you want. Just create pci device with PCIDeviceInfo::is_express = 1. Then its configuration space size is 4K. The rest part is same as conventional pci. Helper functions in pcie.c can be used, but not mandatory. thanks, On Tue, Jul 13, 2010 at 03:01:48PM +0800, Lisa Lei wrote: Thanks, Yamahata sam, then, could you give me so some advice about how to add one pcie device to it? I studied the source code, but still have no idea, I'm thinking that add one pcie device through pci_bridge_qdev_register() and device_init(), just like downstream and upstream, is it available? thanks. On Tue, Jul 6, 2010 at 11:22 AM, Isaku Yamahata yamah...@valinux.co.jp wrote: I'm using debian lenny. $ gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Tue, Jul 06, 2010 at 10:23:45AM +0800, Lisa Lei wrote: On Wed, Jun 30, 2010 at 9:48 PM, Isaku Yamahata yamah...@valinux.co.jp wrote: On Wed, Jun 30, 2010 at 04:10:02PM +0800, Lisa Lei wrote: Hi, I'm finding the solution of how to add one pcie device which emulated by systemc to qemu, such as net card. I noticed that you've been working on Q35 support for qemu, and the status of pcie port emulator is working on April, can it be used now? thanks. The public repo for q35 support is avaiable as follows. http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02066.html I'm now trying to merge those patches to qemu upstream, but not finished yet. thanks, Thanks for your reply, I have got the sourcecode now, but compile failed, can you tell me the gcc version, and qemu version based on? my gcc version is 3.4.6. thanks. -- yamahata -- yamahata -- yamahata
Re: [Qemu-devel] Re: BTRFS: Unbelievably slow with kvm/qemu
Am 12.07.2010 15:43, schrieb Josef Bacik: On Mon, Jul 12, 2010 at 03:34:44PM +0200, Giangiacomo Mariotti wrote: On Mon, Jul 12, 2010 at 9:09 AM, Michael Tokarev m...@tls.msk.ru wrote: This looks quite similar to a problem with ext4 and O_SYNC which I reported earlier but no one cared to answer (or read?) - there: http://permalink.gmane.org/gmane.linux.file-systems/42758 (sent to qemu-devel and linux-fsdevel lists - Cc'd too). You can try a few other options, esp. cache=none and re-writing some guest files to verify. /mjt Either way, changing to cache=none I suspect wouldn't tell me much, because if it's as slow as before, it's still unusable and if instead it's even slower, well it'd be even more unusable, so I wouldn't be able to tell the difference. What I can say for certain is that with the exact same virtual hd file, same options, same system, but on an ext3 fs there's no problem at all, on a Btrfs is not just slower, it takes ages. O_DIRECT support was just introduced recently, please try on the latest kernel with the normal settings (which IIRC uses O_DIRECT), that should make things suck alot less. IIUC, he uses the default cache option of qemu, which is cache=writethrough and maps to O_DSYNC without O_DIRECT. O_DIRECT would only be used for cache=none. Kevin
[Qemu-devel] Re: [SeaBIOS] [PATCH 2/7] seabios: shadow: make device finding more generic.
On Mon, Jul 12, 2010 at 08:59:14PM -0400, Kevin O'Connor wrote: On Mon, Jul 12, 2010 at 08:47:47PM +0900, Isaku Yamahata wrote: pam register offset is north bridge specific. So determine the offset based on found north bridge. Is it really just the offset that is north bridge specific? I thought the entire process was very north bridge specific. If so, I don't think it makes sense to pass back the pam0 register - instead the north bridge specific code should do the necessary work (using helper functions if possible). I have the same concern with part 3 and 4 of this series. I440fx and Q35 (all Intel chipset?) are similar in registers which seabios programs, so I choice to abstract it at register offset level. I don't expect that other vendor's chipset support is wanted. If you want more high level abstract, I'll respin the patch set. -- yamahata
[Qemu-devel] fix for stable: audio/alsa: Handle SND_PCM_STATE_SETUP in alsa_poll_handler
Any reason why this isn't in stable-0.12? I got bitten by it on Debian,
using their qemu-kvm package from squeeze.
Bjørn
commit d9812b033a17c82f9e933757c1c3ef364e3ba62d
Author: malc av1...@comtv.ru
Date: Sun Feb 28 18:34:21 2010 +0300
audio/alsa: Handle SND_PCM_STATE_SETUP in alsa_poll_handler
Signed-off-by: malc av1...@comtv.ru
diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 6a9b87a..88344ff 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -213,6 +213,10 @@ static void alsa_poll_handler (void *opaque)
state = snd_pcm_state (hlp-handle);
switch (state) {
+case SND_PCM_STATE_SETUP:
+alsa_recover (hlp-handle);
+break;
+
case SND_PCM_STATE_XRUN:
alsa_recover (hlp-handle);
break;
[Qemu-devel] [PATCH 1/2] [virtio-9p] Cleanup legacy 'dotu' variable.
Hi,
This patch cleans up the legacy 'dotu' variable which is always set to
1 by default, since qemu doesnt support legacy 9p clients.
Signed-off-by: Arun R Bharadwaj a...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 26 +++
hw/virtio-9p-debug.h |1
hw/virtio-9p.c | 119 +++
3 files changed, 63 insertions(+), 83 deletions(-)
Index: qemu/hw/virtio-9p-debug.h
===
--- qemu.orig/hw/virtio-9p-debug.h
+++ qemu/hw/virtio-9p-debug.h
@@ -1,7 +1,6 @@
#ifndef _QEMU_VIRTIO_9P_DEBUG_H
#define _QEMU_VIRTIO_9P_DEBUG_H
-extern int dotu;
void pprint_pdu(V9fsPDU *pdu);
#endif
Index: qemu/hw/virtio-9p-debug.c
===
--- qemu.orig/hw/virtio-9p-debug.c
+++ qemu/hw/virtio-9p-debug.c
@@ -169,12 +169,10 @@ static void pprint_stat(V9fsPDU *pdu, in
pprint_str(pdu, rx, offsetp, , uid);
pprint_str(pdu, rx, offsetp, , gid);
pprint_str(pdu, rx, offsetp, , muid);
-if (dotu) {
-pprint_str(pdu, rx, offsetp, , extension);
-pprint_int32(pdu, rx, offsetp, , uid);
-pprint_int32(pdu, rx, offsetp, , gid);
-pprint_int32(pdu, rx, offsetp, , muid);
-}
+pprint_str(pdu, rx, offsetp, , extension);
+pprint_int32(pdu, rx, offsetp, , uid);
+pprint_int32(pdu, rx, offsetp, , gid);
+pprint_int32(pdu, rx, offsetp, , muid);
fprintf(llogfile, });
}
@@ -343,9 +341,7 @@ void pprint_pdu(V9fsPDU *pdu)
pprint_int32(pdu, 0, offset, afid);
pprint_str(pdu, 0, offset, , uname);
pprint_str(pdu, 0, offset, , aname);
-if (dotu) {
-pprint_int32(pdu, 0, offset, , n_uname);
-}
+pprint_int32(pdu, 0, offset, , n_uname);
break;
case P9_RAUTH:
fprintf(llogfile, RAUTH: ();
@@ -357,9 +353,7 @@ void pprint_pdu(V9fsPDU *pdu)
pprint_int32(pdu, 0, offset, , afid);
pprint_str(pdu, 0, offset, , uname);
pprint_str(pdu, 0, offset, , aname);
-if (dotu) {
-pprint_int32(pdu, 0, offset, , n_uname);
-}
+pprint_int32(pdu, 0, offset, , n_uname);
break;
case P9_RATTACH:
fprintf(llogfile, RATTACH: ();
@@ -371,9 +365,7 @@ void pprint_pdu(V9fsPDU *pdu)
case P9_RERROR:
fprintf(llogfile, RERROR: ();
pprint_str(pdu, 1, offset, ename);
-if (dotu) {
-pprint_int32(pdu, 1, offset, , ecode);
-}
+pprint_int32(pdu, 1, offset, , ecode);
break;
case P9_TFLUSH:
fprintf(llogfile, TFLUSH: ();
@@ -408,9 +400,7 @@ void pprint_pdu(V9fsPDU *pdu)
pprint_str(pdu, 0, offset, , name);
pprint_int32(pdu, 0, offset, , perm);
pprint_int8(pdu, 0, offset, , mode);
-if (dotu) {
-pprint_str(pdu, 0, offset, , extension);
-}
+pprint_str(pdu, 0, offset, , extension);
break;
case P9_RCREATE:
fprintf(llogfile, RCREATE: ();
Index: qemu/hw/virtio-9p.c
===
--- qemu.orig/hw/virtio-9p.c
+++ qemu/hw/virtio-9p.c
@@ -18,7 +18,6 @@
#include fsdev/qemu-fsdev.h
#include virtio-9p-debug.h
-int dotu = 1;
int debug_9p_pdu;
enum {
@@ -753,9 +752,7 @@ static void complete_pdu(V9fsState *s, V
len = 7;
len += pdu_marshal(pdu, len, s, str);
-if (dotu) {
-len += pdu_marshal(pdu, len, d, err);
-}
+len += pdu_marshal(pdu, len, d, err);
id = P9_RERROR;
}
@@ -785,22 +782,20 @@ static mode_t v9mode_to_mode(uint32_t mo
ret |= S_IFDIR;
}
-if (dotu) {
-if (mode P9_STAT_MODE_SYMLINK) {
-ret |= S_IFLNK;
-}
-if (mode P9_STAT_MODE_SOCKET) {
-ret |= S_IFSOCK;
-}
-if (mode P9_STAT_MODE_NAMED_PIPE) {
-ret |= S_IFIFO;
-}
-if (mode P9_STAT_MODE_DEVICE) {
-if (extension extension-data[0] == 'c') {
-ret |= S_IFCHR;
-} else {
-ret |= S_IFBLK;
-}
+if (mode P9_STAT_MODE_SYMLINK) {
+ret |= S_IFLNK;
+}
+if (mode P9_STAT_MODE_SOCKET) {
+ret |= S_IFSOCK;
+}
+if (mode P9_STAT_MODE_NAMED_PIPE) {
+ret |= S_IFIFO;
+}
+if (mode P9_STAT_MODE_DEVICE) {
+if (extension extension-data[0] == 'c') {
+ret |= S_IFCHR;
+} else {
+ret |= S_IFBLK;
}
}
@@ -863,34 +858,32 @@ static uint32_t stat_to_v9mode(const str
mode |= P9_STAT_MODE_DIR;
}
-if (dotu) {
-if (S_ISLNK(stbuf-st_mode)) {
-mode |= P9_STAT_MODE_SYMLINK;
-}
+if (S_ISLNK(stbuf-st_mode)) {
+mode |= P9_STAT_MODE_SYMLINK;
+}
-if (S_ISSOCK(stbuf-st_mode)) {
-mode |= P9_STAT_MODE_SOCKET;
-}
+if
[Qemu-devel] [PATCH 2/2] [virtio-9p] Implement TLERROR/RLERROR.
* Arun R Bharadwaj a...@linux.vnet.ibm.com [2010-07-13 16:24:41]:
This patch implements TLERROR/RLERROR in the qemu 9P server.
Signed-off-by: Arun R Bharadwaj a...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 19 +--
hw/virtio-9p.h |2 ++
2 files changed, 15 insertions(+), 6 deletions(-)
Index: qemu/hw/virtio-9p.h
===
--- qemu.orig/hw/virtio-9p.h
+++ qemu/hw/virtio-9p.h
@@ -13,6 +13,8 @@
#define VIRTIO_9P_MOUNT_TAG 0
enum {
+P9_TLERROR = 6,
+P9_RLERROR,
P9_TVERSION = 100,
P9_RVERSION,
P9_TAUTH = 102,
Index: qemu/hw/virtio-9p.c
===
--- qemu.orig/hw/virtio-9p.c
+++ qemu/hw/virtio-9p.c
@@ -744,17 +744,24 @@ static void complete_pdu(V9fsState *s, V
int8_t id = pdu-id + 1; /* Response */
if (len 0) {
-V9fsString str;
int err = -len;
+len = 7;
-str.data = strerror(err);
-str.size = strlen(str.data);
+if (s-proto_version != V9FS_PROTO_2000L) {
+V9fsString str;
+
+str.data = strerror(err);
+str.size = strlen(str.data);
+
+len += pdu_marshal(pdu, len, s, str);
+id = P9_RERROR;
+}
-len = 7;
-len += pdu_marshal(pdu, len, s, str);
len += pdu_marshal(pdu, len, d, err);
-id = P9_RERROR;
+if (s-proto_version == V9FS_PROTO_2000L) {
+id = P9_RLERROR;
+}
}
/* fill out the header */
Re: [Qemu-devel] Re: [PATCH RFC] e1000: fix access 4 bytes beyond buffer end
On Tue, Jul 13, 2010 at 09:35:49AM +0300, Gleb Natapov wrote:
On Mon, Jul 12, 2010 at 06:00:20PM -0500, Anthony Liguori wrote:
On 07/12/2010 05:42 PM, Michael S. Tsirkin wrote:
On Mon, Jul 12, 2010 at 04:07:21PM -0500, Anthony Liguori wrote:
On 07/12/2010 12:48 PM, Michael S. Tsirkin wrote:
We do range check for size, and get size as buffer,
but copy size + 4 bytes (4 is for FCS).
Let's copy size bytes but put size + 4 in length.
Signed-off-by: Michael S. Tsirkinm...@redhat.com
I think I'd feel slightly better if we zero'd out the FCS before
writing it to the guest. It is potentially a data leak.
Regards,
Anthony Liguori
I am guessing there's no chance guest actually looks
at this data, otherwise it won't match and we'd get errors, right?
That's my assumption too. Although I believe there are some known
issues with e1000 and certain versions of Windows and the Microsoft
built-in driver. Maybe this is why those drivers don't work and the
Intel drivers do?
At least one known issue with Windows drivers to me is that they
sometimes (on resume from S4 at least) enable interrupts before setup
irq routing, so if interrupt is generated in the wrong time it hangs the
guest. I guess it works on real HW for them because line speed
negotiation takes non-zero time.
I guess we could work around this. Is there a bz?
Regards,
Anthony Liguori
---
Anthony, Alex, please review.
hw/e1000.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/e1000.c b/hw/e1000.c
index 0da65f9..70aba11 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -649,7 +649,6 @@ e1000_receive(VLANClientState *nc, const uint8_t
*buf, size_t size)
}
rdh_start = s-mac_reg[RDH];
-size += 4; // for the header
do {
if (s-mac_reg[RDH] == s-mac_reg[RDT] s-check_rxov) {
set_ics(s, 0, E1000_ICS_RXO);
@@ -663,7 +662,7 @@ e1000_receive(VLANClientState *nc, const uint8_t
*buf, size_t size)
if (desc.buffer_addr) {
cpu_physical_memory_write(le64_to_cpu(desc.buffer_addr),
(void *)(buf + vlan_offset),
size);
-desc.length = cpu_to_le16(size);
+desc.length = cpu_to_le16(size + 4 /* for FCS */);
desc.status |= E1000_RXD_STAT_EOP|E1000_RXD_STAT_IXSM;
} else // as per intel docs; skip descriptors with null buf
addr
DBGOUT(RX, Null RX descriptor!!\n);
--
Gleb.
Re: [Qemu-devel] Re: [PATCH RFC] e1000: fix access 4 bytes beyond buffer end
On Tue, Jul 13, 2010 at 02:11:10PM +0300, Michael S. Tsirkin wrote: On Tue, Jul 13, 2010 at 09:35:49AM +0300, Gleb Natapov wrote: On Mon, Jul 12, 2010 at 06:00:20PM -0500, Anthony Liguori wrote: On 07/12/2010 05:42 PM, Michael S. Tsirkin wrote: On Mon, Jul 12, 2010 at 04:07:21PM -0500, Anthony Liguori wrote: On 07/12/2010 12:48 PM, Michael S. Tsirkin wrote: We do range check for size, and get size as buffer, but copy size + 4 bytes (4 is for FCS). Let's copy size bytes but put size + 4 in length. Signed-off-by: Michael S. Tsirkinm...@redhat.com I think I'd feel slightly better if we zero'd out the FCS before writing it to the guest. It is potentially a data leak. Regards, Anthony Liguori I am guessing there's no chance guest actually looks at this data, otherwise it won't match and we'd get errors, right? That's my assumption too. Although I believe there are some known issues with e1000 and certain versions of Windows and the Microsoft built-in driver. Maybe this is why those drivers don't work and the Intel drivers do? At least one known issue with Windows drivers to me is that they sometimes (on resume from S4 at least) enable interrupts before setup irq routing, so if interrupt is generated in the wrong time it hangs the guest. I guess it works on real HW for them because line speed negotiation takes non-zero time. I guess we could work around this. Is there a bz? BZ where? We do not support e1000 with Windows guests. -- Gleb.
[Qemu-devel] [Tracing][PATCH] Allow bulk enabling of trace events at compile time.
[PATCH] For 'simple' trace backend, allow bulk enabling/disabling of trace
events at compile time.
Trace events that are preceded by 'disable' keyword are compiled in, but
turned off by default. These can individually be turned on using the monitor.
All other trace events are enabled by default.
TODO :
This could be enhanced when the trace-event namespace is partitioned into a
group and an ID within that group. In such a case, marking a group as enabled
would automatically enable all trace-events listed under it.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
trace-events |3 +++
tracetool| 36
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/trace-events b/trace-events
index a533414..cb5ef00 100644
--- a/trace-events
+++ b/trace-events
@@ -17,6 +17,9 @@
# Example: qemu_malloc(size_t size) size %zu
#
# The disable keyword will build without the trace event.
+# In case of 'simple' trace backend, it will allow the trace event to be
+# compiled, but this would be turned off by default. It can be toggled on via
+# the monitor.
#
# The name must be a valid as a C function name.
#
diff --git a/tracetool b/tracetool
index b7a0499..98d23fb 100755
--- a/tracetool
+++ b/tracetool
@@ -73,6 +73,20 @@ get_fmt()
echo $fmt
}
+# Get the state of a trace event
+get_state()
+{
+local str disable state
+str=$(get_name $1)
+disable=${str##disable }
+if [ $disable = $str ] ; then
+state=1
+else
+state=0
+fi
+echo $state
+}
+
linetoh_begin_nop()
{
return
@@ -155,12 +169,16 @@ cast_args_to_ulong()
linetoh_simple()
{
-local name args argc ulong_args
+local name args argc ulong_args state
name=$(get_name $1)
args=$(get_args $1)
argc=$(get_argc $1)
ulong_args=$(cast_args_to_ulong $1)
+state=$(get_state $1)
+if [ $state = 0 ]; then
+name=${name##disable }
+fi
cat EOF
static inline void trace_$name($args) {
trace$argc($simple_event_num, $ulong_args);
@@ -191,10 +209,14 @@ EOF
linetoc_simple()
{
-local name
+local name state
name=$(get_name $1)
+state=$(get_state $1)
+if [ $state = 0 ] ; then
+name=${name##disable }
+fi
cat EOF
-{.tp_name = $name, .state=0},
+{.tp_name = $name, .state=$state},
EOF
simple_event_num=$((simple_event_num + 1))
}
@@ -305,7 +327,13 @@ convert()
disable=${str%%disable *}
echo
if test -z $disable; then
-lineto$1_nop ${str##disable }
+# Pass the disabled state as an arg to lineto$1_simple().
+# For all other cases, call lineto$1_nop()
+if [ $backend = simple ]; then
+$process_line $str
+else
+lineto$1_nop ${str##disable }
+fi
else
$process_line $str
fi
--
1.6.2.5
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[Qemu-devel] [PATCH] scsi: Dequeue requests before invoking completion callback
The request completion callback of the LSI controller may start the next
request that can use the same tag as the completed one. As the latter is
still enqueued at that point, scsi_send_command will complain about the
tag reuse and cancel the completed request. That will cause a double
free later on when the completion path cleans up as well.
Fix this by dequeuing the request before invoking the callback.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
This should fix bug 595438.
hw/scsi-bus.c | 12 +++-
hw/scsi.h |1 +
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index d69c74c..b860a09 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -142,6 +142,7 @@ SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d,
uint32_t tag, uint32_t l
req-tag = tag;
req-lun = lun;
req-status = -1;
+req-enqueued = true;
QTAILQ_INSERT_TAIL(d-requests, req, next);
return req;
}
@@ -158,9 +159,17 @@ SCSIRequest *scsi_req_find(SCSIDevice *d, uint32_t tag)
return NULL;
}
+static void scsi_req_dequeue(SCSIRequest *req)
+{
+if (req-enqueued) {
+QTAILQ_REMOVE(req-dev-requests, req, next);
+req-enqueued = false;
+}
+}
+
void scsi_req_free(SCSIRequest *req)
{
-QTAILQ_REMOVE(req-dev-requests, req, next);
+scsi_req_dequeue(req);
qemu_free(req);
}
@@ -512,6 +521,7 @@ void scsi_req_print(SCSIRequest *req)
void scsi_req_complete(SCSIRequest *req)
{
assert(req-status != -1);
+scsi_req_dequeue(req);
req-bus-complete(req-bus, SCSI_REASON_DONE,
req-tag,
req-status);
diff --git a/hw/scsi.h b/hw/scsi.h
index 4fbf1d5..cb06d6d 100644
--- a/hw/scsi.h
+++ b/hw/scsi.h
@@ -43,6 +43,7 @@ typedef struct SCSIRequest {
enum SCSIXferMode mode;
} cmd;
BlockDriverAIOCB *aiocb;
+bool enqueued;
QTAILQ_ENTRY(SCSIRequest) next;
} SCSIRequest;
--
1.7.1
[Qemu-devel] Re: [PATCH 0/8] vlan cleanup
On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka jan.kis...@web.de wrote: Miguel Di Ciurcio Filho wrote: This series removes the vlan stuff without mercy. I've tried to make the steps as small as possible, but the last one is huge. I did some basic tests and networking is still working, so reviews are welcome :-D Sorry, this is a bit too rude. This not only removes the vlan model, something one may talk about, but also the innocent socket back-ends and the useful pcap dump support. Socket back-ends allow quick and easy unprivileged inter-VM network setups. Nothing for production systems, but useful for testing purposes on boxes where taps are not allowed or unhandy to configure. I agree that it might be handy sometimes, but one could use VDE for that too. Runs on user-space and can be tunneled over SSH or netcat [1]. Another option would be to make the socket backend properly work as a netdev, so one could directly connect guest NICs on different hosts, but on a 1:1 relationship. The dump client helps to debug user mode guest networks, namely slirp which you did not remove. If that should become the only use case for vlans with more than 2 nodes, we could think about making it a special feature of backend devices. socket and dump are only used when the vlan backends are concerned, so they don't have any useful meaning outside of that. How about add dump hooks on backends? I don't think network backends need to be stackable like block devices, thought. I'm open for cleanups here, but they do require a bit mercy - and should also mention the reason. Well, basically there is a lot of if (vlan) else if (peer). While discussing the query-netdev QMP command, no one has shown any love about the vlan stuff at all, quite the contrary and it was kept out of the protocol. Regards, Miguel [1] http://wiki.virtualsquare.org/index.php/VDE#vde_plug
[Qemu-devel] Re: [PATCH 2/2] [virtio-9p] Implement TLERROR/RLERROR.
* Arun R Bharadwaj a...@linux.vnet.ibm.com [2010-07-13 16:26:30]: * Arun R Bharadwaj a...@linux.vnet.ibm.com [2010-07-13 16:24:41]: This patch implements TLERROR/RLERROR in the qemu 9P server. Here is the link to client implementation of the same http://sourceforge.net/mailarchive/message.php?msg_name=20100713110049.GC11854%40linux.vnet.ibm.com -arun
[Qemu-devel] Re: [PATCH 0/8] vlan cleanup
Miguel Di Ciurcio Filho wrote: On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka jan.kis...@web.de wrote: Miguel Di Ciurcio Filho wrote: This series removes the vlan stuff without mercy. I've tried to make the steps as small as possible, but the last one is huge. I did some basic tests and networking is still working, so reviews are welcome :-D Sorry, this is a bit too rude. This not only removes the vlan model, something one may talk about, but also the innocent socket back-ends and the useful pcap dump support. Socket back-ends allow quick and easy unprivileged inter-VM network setups. Nothing for production systems, but useful for testing purposes on boxes where taps are not allowed or unhandy to configure. I agree that it might be handy sometimes, but one could use VDE for that too. Runs on user-space and can be tunneled over SSH or netcat [1]. Yes, I know. But it requires yet another process as hop. In contrast, peer-to-peer sockets used to be as fast as taps in certain setup (now taps became faster again). Another option would be to make the socket backend properly work as a netdev, so one could directly connect guest NICs on different hosts, but on a 1:1 relationship. What is required for this conversion? And are VDE and Slirp already fully converted? The dump client helps to debug user mode guest networks, namely slirp which you did not remove. If that should become the only use case for vlans with more than 2 nodes, we could think about making it a special feature of backend devices. socket and dump are only used when the vlan backends are concerned, so they don't have any useful meaning outside of that. That's still the default network configuration unless you configure something specific (management tools do, of course). How about add dump hooks on backends? I don't think network backends need to be stackable like block devices, thought. That's what I suggested. Definitely an option to migrate the dump feature. I'm open for cleanups here, but they do require a bit mercy - and should also mention the reason. Well, basically there is a lot of if (vlan) else if (peer). While discussing the query-netdev QMP command, no one has shown any love about the vlan stuff at all, quite the contrary and it was kept out of the protocol. As I said: Removing the vlan abstraction is one thing, removing backends is another. I would suggest to start with preparatory work (enable all backends for netdev, port dump, make netdev default), then remove the vlan infrastructure. Jan Regards, Miguel [1] http://wiki.virtualsquare.org/index.php/VDE#vde_plug -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] QMP argument parser does not verify json type
Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes:
Hi there,
I've run QEMU like this:
$ qemu -qmp tcp:localhost:3000,server,nowait -netdev
type=tap,id=ndev1,vhost=on
Then I run these commands over QMP:
works:
{execute: device_add, arguments: {driver: virtio-net-pci,
csum: off, id: nic1, netdev: ndev1}}
works:
{execute: device_add, arguments: {driver: virtio-net-pci,
csum: false, id: nic1, netdev: ndev1}}
works, no error reported, csum stays on:
{execute: device_add, arguments: {driver: virtio-net-pci,
csum: [ ], id: nic1, netdev: ndev1}}
works:
{execute: device_add, arguments: {driver: virtio-net-pci,
id: nic1, netdev: ndev1, vectors: 10}}
works:
{execute: device_add, arguments: {driver: virtio-net-pci,
id: nic1, netdev: ndev1, vectors: 10}}
When specifying query-qdm I've faced this problem of internal QEMU
types against json types. The mapped types need to be verified
accordingly, IMHO.
First we query for supported devices and get:
{
name:virtio-net-pci,
creatable:true,
bus:PCI,
properties:[
{
name:vectors,
type: { qdev: uint32, qmp: integer }
},
...
]
}
And then this should result in an error:
{execute: device_add, arguments: {driver: virtio-net-pci,
id: nic1, netdev: ndev1, vectors: 10}}
Yes.
This is where command line (QemuOpts), human monitor (args_type) and QMP
(QDict) meet. Or rather collide. It's a mess. I can explain the gory
details, if anyone's interested.
Re: [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for query-qdm
[cc: kraxel] I didn't get around to review v1. Sorry. Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes: Changelog from v1 - - renamed props to properties - updated the examples - reworded the explanations of name and description - split type into a json-object, adding qmp and qdev - list all possible values for bus - list all possible values for qdev on type - list all possible values for qmp on type --- qemu-monitor.hx | 88 +++ 1 files changed, 88 insertions(+), 0 deletions(-) diff --git a/qemu-monitor.hx b/qemu-monitor.hx index 2af3de6..0055d0a 100644 --- a/qemu-monitor.hx +++ b/qemu-monitor.hx @@ -2490,6 +2490,94 @@ STEXI show device tree @item info qdm show qdev device model list +ETEXI +SQMP +query-qdm +- + +Describe the capabilities of all devices registered with qdev. + +The returned output is a json-array, each element is a json-object describing +a single device type. + +Each json-object contains the following: + +- name: name of the device (json-string) +- bus: the name of the bus type for the device (json-string) +- Possible values: PCI, SCSI, I2C, ISA, SSI, USB, virtio-serial-bus, System Missing: IDE (hw/ide/qdev.c) and s390-virtio (hw/s390-virtio-bus.c). +- alias: an alias by which the device is also known (json-string, optional) +- description: description of the device (json-string, optional) +- creatable: whether this device can be created on command line (json-boolean) on the command line is misleading; it applies to monitor (human QMP) as well. by the user? +- properties: a list where each element is an json-object that describes a + property of the device. Each json-object contains the following: + - name: the name of the property (json-string) + - type: a json-object that contains the following: +- qdev: the internal name of the type of the property (json-string) +- Possible values: uint8, uint16, uint32, uint64, int32, macaddr, + drive, chr, string, netdev, bit, taddr +- qmp: the json equivalent type of the internal type (json-string) +- Possible values: integer, string, boolean Fairly close to JSON Schema, but there are differences. Do we need qdev? Is exposing it wise? Smells a bit too much of internal detail for comfort... Could we use type just like JSON Schema? Drop qdev or move it out of type, then make type what its member qmp is now. Note: qdev property documentation overlaps with QMP command self-documentation, because qdev properties are also arguments of command device_add. We may wish to revisit this when we do self-documentation. [...] Note: query-qdm isn't just a straight port of info qdm to QMP. It additionally documents properties. It's like info qdm + device_add D,? for all D. I'm fine with that.
Re: [Qemu-devel] [PATCH 2/2] [virtio-9p] Implement TLERROR/RLERROR.
On Tuesday 13 July 2010 04:26 PM, Arun R Bharadwaj wrote:
* Arun R Bharadwaja...@linux.vnet.ibm.com [2010-07-13 16:24:41]:
This patch implements TLERROR/RLERROR in the qemu 9P server.
Signed-off-by: Arun R Bharadwaja...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 19 +--
hw/virtio-9p.h |2 ++
2 files changed, 15 insertions(+), 6 deletions(-)
Index: qemu/hw/virtio-9p.h
===
--- qemu.orig/hw/virtio-9p.h
+++ qemu/hw/virtio-9p.h
@@ -13,6 +13,8 @@
#define VIRTIO_9P_MOUNT_TAG 0
enum {
+P9_TLERROR = 6,
+P9_RLERROR,
P9_TVERSION = 100,
P9_RVERSION,
P9_TAUTH = 102,
Index: qemu/hw/virtio-9p.c
===
--- qemu.orig/hw/virtio-9p.c
+++ qemu/hw/virtio-9p.c
@@ -744,17 +744,24 @@ static void complete_pdu(V9fsState *s, V
int8_t id = pdu-id + 1; /* Response */
if (len 0) {
-V9fsString str;
int err = -len;
+len = 7;
-str.data = strerror(err);
-str.size = strlen(str.data);
+if (s-proto_version != V9FS_PROTO_2000L) {
+V9fsString str;
+
+str.data = strerror(err);
+str.size = strlen(str.data);
+
+len += pdu_marshal(pdu, len, s,str);
+id = P9_RERROR;
+}
-len = 7;
-len += pdu_marshal(pdu, len, s,str);
len += pdu_marshal(pdu, len, d, err);
-id = P9_RERROR;
+if (s-proto_version == V9FS_PROTO_2000L) {
+id = P9_RLERROR;
+}
}
I guess this can go in the else part of the above if loop
ie
if (s-proto_version != V9FS_PROTO_2000L) {
id = P9_RERROR;
} else {
id = P9_RLERROR;
}
-aneesh
Re: [Qemu-devel] [PATCH 2/2] [virtio-9p] Implement TLERROR/RLERROR.
* Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com [2010-07-13 18:41:18]:
On Tuesday 13 July 2010 04:26 PM, Arun R Bharadwaj wrote:
* Arun R Bharadwaja...@linux.vnet.ibm.com [2010-07-13 16:24:41]:
This patch implements TLERROR/RLERROR in the qemu 9P server.
Signed-off-by: Arun R Bharadwaja...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 19 +--
hw/virtio-9p.h |2 ++
2 files changed, 15 insertions(+), 6 deletions(-)
Index: qemu/hw/virtio-9p.h
===
--- qemu.orig/hw/virtio-9p.h
+++ qemu/hw/virtio-9p.h
@@ -13,6 +13,8 @@
#define VIRTIO_9P_MOUNT_TAG 0
enum {
+P9_TLERROR = 6,
+P9_RLERROR,
P9_TVERSION = 100,
P9_RVERSION,
P9_TAUTH = 102,
Index: qemu/hw/virtio-9p.c
===
--- qemu.orig/hw/virtio-9p.c
+++ qemu/hw/virtio-9p.c
@@ -744,17 +744,24 @@ static void complete_pdu(V9fsState *s, V
int8_t id = pdu-id + 1; /* Response */
if (len 0) {
-V9fsString str;
int err = -len;
+len = 7;
-str.data = strerror(err);
-str.size = strlen(str.data);
+if (s-proto_version != V9FS_PROTO_2000L) {
+V9fsString str;
+
+str.data = strerror(err);
+str.size = strlen(str.data);
+
+len += pdu_marshal(pdu, len, s,str);
+id = P9_RERROR;
+}
-len = 7;
-len += pdu_marshal(pdu, len, s,str);
len += pdu_marshal(pdu, len, d, err);
-id = P9_RERROR;
+if (s-proto_version == V9FS_PROTO_2000L) {
+id = P9_RLERROR;
+}
}
I guess this can go in the else part of the above if loop
ie
if (s-proto_version != V9FS_PROTO_2000L) {
id = P9_RERROR;
} else {
id = P9_RLERROR;
}
Sure. That works fine.
-aneesh
Re: [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for query-qdm
On Tue, Jul 13, 2010 at 8:49 AM, Markus Armbruster arm...@redhat.com wrote: +- bus: the name of the bus type for the device (json-string) + - Possible values: PCI, SCSI, I2C, ISA, SSI, USB, virtio-serial-bus, System Missing: IDE (hw/ide/qdev.c) and s390-virtio (hw/s390-virtio-bus.c). Ack. +- alias: an alias by which the device is also known (json-string, optional) +- description: description of the device (json-string, optional) +- creatable: whether this device can be created on command line (json-boolean) on the command line is misleading; it applies to monitor (human QMP) as well. by the user? Ack. +- properties: a list where each element is an json-object that describes a + property of the device. Each json-object contains the following: + - name: the name of the property (json-string) + - type: a json-object that contains the following: + - qdev: the internal name of the type of the property (json-string) + - Possible values: uint8, uint16, uint32, uint64, int32, macaddr, + drive, chr, string, netdev, bit, taddr + - qmp: the json equivalent type of the internal type (json-string) + - Possible values: integer, string, boolean Fairly close to JSON Schema, but there are differences. Do we need qdev? Is exposing it wise? Smells a bit too much of internal detail for comfort... Could we use type just like JSON Schema? Drop qdev or move it out of type, then make type what its member qmp is now. I think it is better not to expose too much the internals to. My initial concern and Daniel's too was to make clear what is the meaning of the property. Like, give me a proper formated MAC address or an id of a properly created netdev. But I think we could drop the qdev properties stuff and return the proper error in case of parsing problems. Regards, Miguel
Re: [Qemu-devel] QMP argument parser does not verify json type
On Tue, Jul 13, 2010 at 10:03 AM, Markus Armbruster arm...@redhat.com wrote:
And then this should result in an error:
{execute: device_add, arguments: {driver: virtio-net-pci,
id: nic1, netdev: ndev1, vectors: 10}}
Yes.
This is where command line (QemuOpts), human monitor (args_type) and QMP
(QDict) meet. Or rather collide. It's a mess. I can explain the gory
details, if anyone's interested.
I am :-D
I seriously tried to wrap my mind around this stuff, but as you said,
it is a mess.
Regards,
Miguel
Re: [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for query-qdm
On Tue, 13 Jul 2010 13:49:46 +0200 Markus Armbruster arm...@redhat.com wrote: [cc: kraxel] I didn't get around to review v1. Sorry. Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes: Changelog from v1 - - renamed props to properties - updated the examples - reworded the explanations of name and description - split type into a json-object, adding qmp and qdev - list all possible values for bus - list all possible values for qdev on type - list all possible values for qmp on type --- qemu-monitor.hx | 88 +++ 1 files changed, 88 insertions(+), 0 deletions(-) diff --git a/qemu-monitor.hx b/qemu-monitor.hx index 2af3de6..0055d0a 100644 --- a/qemu-monitor.hx +++ b/qemu-monitor.hx @@ -2490,6 +2490,94 @@ STEXI show device tree @item info qdm show qdev device model list +ETEXI +SQMP +query-qdm +- + +Describe the capabilities of all devices registered with qdev. + +The returned output is a json-array, each element is a json-object describing +a single device type. + +Each json-object contains the following: + +- name: name of the device (json-string) +- bus: the name of the bus type for the device (json-string) +- Possible values: PCI, SCSI, I2C, ISA, SSI, USB, virtio-serial-bus, System Missing: IDE (hw/ide/qdev.c) and s390-virtio (hw/s390-virtio-bus.c). What about System, is it ok to expose it? +- alias: an alias by which the device is also known (json-string, optional) +- description: description of the device (json-string, optional) +- creatable: whether this device can be created on command line (json-boolean) on the command line is misleading; it applies to monitor (human QMP) as well. by the user? When is a device not creatable? +- properties: a list where each element is an json-object that describes a + property of the device. Each json-object contains the following: + - name: the name of the property (json-string) + - type: a json-object that contains the following: +- qdev: the internal name of the type of the property (json-string) +- Possible values: uint8, uint16, uint32, uint64, int32, macaddr, + drive, chr, string, netdev, bit, taddr Didn't see this before, but we should not use too short names like chr and taddr. +- qmp: the json equivalent type of the internal type (json-string) +- Possible values: integer, string, boolean Fairly close to JSON Schema, but there are differences. Do we need qdev? Is exposing it wise? Smells a bit too much of internal detail for comfort... Agreed, although this was a suggestion from me. Could we use type just like JSON Schema? Drop qdev or move it out of type, then make type what its member qmp is now. The most important point here is to try to figure out how clients are going to use this. Actually, the fact that libvirt doesn't actually need this makes me wonder if we should have it in the first place, at the same time listing the property name w/o saying what type it accepts doesn't seem to be that useful either. Let's look at all possibilities: 1. Drop qmp key and rename qdev to type (ie. use the qdev type only) This was the original proposal. I don't like it because its values are quite low-level and have no meaning in json. If this is needed, then I think it needs a complement specifying the json type for it. 2. Drop qdev key and rename qmp to type (ie. use the json type only) This is what makes sense when self-documenting the protocol, however, given the original proposal, I wonder if this is going to be enough. That is, say a property takes a MAC address. By using the json type we will just say string, how is the client going to know that it's actually a MAC address in a string format? 3. Use both qdev and qmp keys Then clients can have a matrix of qdev and qmp types, then when query-qdm says a property takes qdev=macaddr and qmp=string, clients can automatically build the command's argument. Now, I'm wondering if the int types make sense... Note: qdev property documentation overlaps with QMP command self-documentation, because qdev properties are also arguments of command device_add. We may wish to revisit this when we do self-documentation. Hm, maybe this is also true for other commands Daniel has converted..
Re: [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for query-qdm
On Tue, 13 Jul 2010 10:30:24 -0300 Miguel Di Ciurcio Filho miguel.fi...@gmail.com wrote: [...] On Tue, Jul 13, 2010 at 8:49 AM, Markus Armbruster arm...@redhat.com wrote: +- properties: a list where each element is an json-object that describes a + property of the device. Each json-object contains the following: + - name: the name of the property (json-string) + - type: a json-object that contains the following: + - qdev: the internal name of the type of the property (json-string) + - Possible values: uint8, uint16, uint32, uint64, int32, macaddr, + drive, chr, string, netdev, bit, taddr + - qmp: the json equivalent type of the internal type (json-string) + - Possible values: integer, string, boolean Fairly close to JSON Schema, but there are differences. Do we need qdev? Is exposing it wise? Smells a bit too much of internal detail for comfort... Could we use type just like JSON Schema? Drop qdev or move it out of type, then make type what its member qmp is now. I think it is better not to expose too much the internals to. My initial concern and Daniel's too was to make clear what is the meaning of the property. Like, give me a proper formated MAC address or an id of a properly created netdev. But I think we could drop the qdev properties stuff and return the proper error in case of parsing problems. Then client writers will have to know how to encode the property ahead of time, which makes self-documenting useless.
[Qemu-devel] Re: KVM Call agenda for July 13th
On 07/12/2010 11:38 PM, Avi Kivity wrote: On 07/13/2010 01:08 AM, Anthony Liguori wrote: On 07/12/2010 05:07 PM, Anthony Liguori wrote: On 07/12/2010 04:57 PM, Chris Wright wrote: * Juan Quintela (quint...@redhat.com) wrote: Please send in any agenda items you are interested in covering. 0.13 ;-) - vCPU limits; how much testing has anyone done of 64-way guests? - Finding a way to enable virtio by default; any clever ideas? Both of these are really in the category of, getting good performance out of KVM when running it as a casual user (like via virt-manager). Casual users starting 64-way guests? A 4-socket octal core is 32 physical cores or 64 threads. That's not a super high end system today and it's going to approach mid-range in the not too distant future. Regards, Anthony Liguori
[Qemu-devel] Re: [Tracing][PATCH] Allow bulk enabling of trace events at compile time.
On Tue, Jul 13, 2010 at 05:04:16PM +0530, Prerna Saxena wrote:
[PATCH] For 'simple' trace backend, allow bulk enabling/disabling of trace
events at compile time.
Trace events that are preceded by 'disable' keyword are compiled in, but
turned off by default. These can individually be turned on using the monitor.
All other trace events are enabled by default.
TODO :
This could be enhanced when the trace-event namespace is partitioned into a
group and an ID within that group. In such a case, marking a group as enabled
would automatically enable all trace-events listed under it.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
Applied, thanks!
Stefan
trace-events |3 +++
tracetool| 36
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/trace-events b/trace-events
index a533414..cb5ef00 100644
--- a/trace-events
+++ b/trace-events
@@ -17,6 +17,9 @@
# Example: qemu_malloc(size_t size) size %zu
#
# The disable keyword will build without the trace event.
+# In case of 'simple' trace backend, it will allow the trace event to be
+# compiled, but this would be turned off by default. It can be toggled on
via
+# the monitor.
#
# The name must be a valid as a C function name.
#
diff --git a/tracetool b/tracetool
index b7a0499..98d23fb 100755
--- a/tracetool
+++ b/tracetool
@@ -73,6 +73,20 @@ get_fmt()
echo $fmt
}
+# Get the state of a trace event
+get_state()
+{
+local str disable state
+str=$(get_name $1)
+disable=${str##disable }
+if [ $disable = $str ] ; then
+state=1
+else
+state=0
+fi
+echo $state
+}
+
linetoh_begin_nop()
{
return
@@ -155,12 +169,16 @@ cast_args_to_ulong()
linetoh_simple()
{
-local name args argc ulong_args
+local name args argc ulong_args state
name=$(get_name $1)
args=$(get_args $1)
argc=$(get_argc $1)
ulong_args=$(cast_args_to_ulong $1)
+state=$(get_state $1)
+if [ $state = 0 ]; then
+name=${name##disable }
+fi
cat EOF
static inline void trace_$name($args) {
trace$argc($simple_event_num, $ulong_args);
@@ -191,10 +209,14 @@ EOF
linetoc_simple()
{
-local name
+local name state
name=$(get_name $1)
+state=$(get_state $1)
+if [ $state = 0 ] ; then
+name=${name##disable }
+fi
cat EOF
-{.tp_name = $name, .state=0},
+{.tp_name = $name, .state=$state},
EOF
simple_event_num=$((simple_event_num + 1))
}
@@ -305,7 +327,13 @@ convert()
disable=${str%%disable *}
echo
if test -z $disable; then
-lineto$1_nop ${str##disable }
+# Pass the disabled state as an arg to lineto$1_simple().
+# For all other cases, call lineto$1_nop()
+if [ $backend = simple ]; then
+$process_line $str
+else
+lineto$1_nop ${str##disable }
+fi
else
$process_line $str
fi
--
1.6.2.5
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On Tue, 13 Jul 2010 10:40:40 +0300 Avi Kivity a...@redhat.com wrote: On 07/13/2010 09:57 AM, Aurelien Jarno wrote: Avi Kivity a écrit : On 07/12/2010 05:57 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.12.n+1 I won't be at the KVM call, but I can work on that in the next days. Basically the stable tree already contains a lot of fixes and we can do a call for patches for this release. One week should be enough, so that we can have the release at the end of next week (a few technical days are needed in addition). Thanks. I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). I remember someone has stepped in to take that work, but I don't exactly remember who.
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On 07/13/2010 05:08 PM, Luiz Capitulino wrote: I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). I remember someone has stepped in to take that work, but I don't exactly remember who. He doesn't either, presumably. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 544527] Re: usbfs is bugged with 2.6.32.9 and =2.6.33 (breaks VMWare, Qemu, sane scanners, ...)
This bugfix is incomplete. Isochronous transfers are still broken, when
running 32-bit software on a 64-bit kernel. Function
processcompl_compat() in devio.c needs a similar fix to the fix that was
applied to processcompl(). Looking at processcompl_compat() I see:
if (as-userbuffer urb-actual_length)
if (copy_to_user(as-userbuffer, urb-transfer_buffer,
urb-actual_length))
return -EFAULT;
correct code would be something like
if (as-userbuffer urb-actual_length) {
if (urb-number_of_packets 0) /* Isochronous */
i = urb-transfer_buffer_length;
else/* Non-Isoc */
i = urb-actual_length;
if (copy_to_user(as-userbuffer, urb-transfer_buffer, i))
goto err_out;
}
(note the difference between urb-actual_length and
urb-transfer_buffer_length).
With kernel 2.6.32-23-generic x86_64 on Ubuntu 10.04, using proprietary
USB-hardware hooked up to the USB bus (with software compiled for
32-bit), I can directly observe how isochronous transfers retrieved via
ioctl(.. USBDEVFS_REAPURB ..) are too short, i.e. the kernel does not
write the end of the data packet to the supplied buffer. Booting on the
2.6.31 kernel still present from before I upgraded from Ubuntu 9.10, the
same software runs flawlessly.
As a workaround I'll use the older kernel for now (also I could compile
for 64-bit, actually...).
cheers,
David
--
usbfs is bugged with 2.6.32.9 and =2.6.33 (breaks VMWare, Qemu, sane
scanners, ...)
https://bugs.launchpad.net/bugs/544527
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Fix Committed
Status in SANE-backends - Backends for SANE: Fix Committed
Status in Tv Time: Fix Committed
Status in Virtualbox: Fix Committed
Status in “linux” package in Ubuntu: Fix Committed
Bug description:
Binary package hint: tvtime
There's a problem with isochronous and usbfs, suse tried to improve usbfs but
it end up that it broke usbfs.
For isochronous the entire packet needs to be copied and not only a part of it.
http://lkml.org/lkml/2010/2/26/490 (Report)
http://lkml.org/lkml/2010/2/27/226 (Bugfix)
please merge this bugfix asap.
ProblemType: Bug
Architecture: amd64
Date: Mon Mar 22 21:09:00 2010
DistroRelease: Ubuntu 10.04
LiveMediaBuild: Ubuntu 10.04 Lucid Lynx - Alpha amd64 (20100322)
Package: tvtime 1.0.2-5ubuntu2
ProcEnviron:
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: tvtime
Uname: Linux 2.6.32-16-generic x86_64
[Qemu-devel] [PULL 0/5] Block patches
These are some more fixes that should go into 0.13. The following changes since commit f077caa99c21847152e706e77b378cb0ec2f: Merge remote branch 'mst/for_anthony' into staging (2010-07-13 08:56:27 -0500) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Markus Armbruster (3): virtio-pci: Check for virtio_blk_init() failure virtio-blk: Fix virtio-blk-s390 to require drive ide scsi virtio-blk: Reject empty drives unless media is removable Shahar Havivi (1): Block migration fail, ignore error from bdrv_getlength Stefan Weil (1): qemu-img: Fix copy+paste bug in documentation block-migration.c |2 +- hw/ide/core.c |4 hw/scsi-disk.c|5 + hw/virtio-blk.c | 10 ++ hw/virtio-pci.c |5 ++--- qemu-img-cmds.hx |2 +- 6 files changed, 23 insertions(+), 5 deletions(-)
[Qemu-devel] [PATCH 1/5] qemu-img: Fix copy+paste bug in documentation
From: Stefan Weil w...@mail.berlios.de
Replace rebase by resize in documentation of resize command.
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Cc: Kevin Wolf kw...@redhat.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-img-cmds.hx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index c4cf3e7..6d3e5f8 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -54,6 +54,6 @@ ETEXI
DEF(resize, img_resize,
resize filename [+ | -]size)
STEXI
-...@item rebase @var{filename} [+ | -...@var{size}
+...@item resize @var{filename} [+ | -...@var{size}
@end table
ETEXI
--
1.7.1.1
[Qemu-devel] [PATCH 3/5] virtio-pci: Check for virtio_blk_init() failure
From: Markus Armbruster arm...@redhat.com
It can't actually fail now, but the next commit will change that.
s390_virtio_blk_init() already checks for failure, but
virtio_blk_init_pci() doesn't. Fix that.
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/virtio-pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index c728fff..5583166 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -551,6 +551,9 @@ static int virtio_blk_init_pci(PCIDevice *pci_dev)
return -1;
}
vdev = virtio_blk_init(pci_dev-qdev, proxy-block);
+if (!vdev) {
+return -1;
+}
vdev-nvectors = proxy-nvectors;
virtio_init_pci(proxy, vdev,
PCI_VENDOR_ID_REDHAT_QUMRANET,
--
1.7.1.1
[Qemu-devel] [PATCH 4/5] virtio-blk: Fix virtio-blk-s390 to require drive
From: Markus Armbruster arm...@redhat.com
Move the check from virtio_blk_init_pci(), where it protects only
virtio-blk-pci, to virtio_blk_init(). Without that, virtio-blk-s390
initializes without a drive. I figure that can lead to null pointer
dereferences.
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/virtio-blk.c |6 ++
hw/virtio-pci.c |4
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 8747634..99e9dd2 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -12,6 +12,7 @@
*/
#include qemu-common.h
+#include qemu-error.h
#include virtio-blk.h
#ifdef __linux__
# include scsi/sg.h
@@ -490,6 +491,11 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf
*conf)
static int virtio_blk_id;
DriveInfo *dinfo;
+if (!conf-bs) {
+error_report(virtio-blk-pci: drive property not set);
+return NULL;
+}
+
s = (VirtIOBlock *)virtio_common_init(virtio-blk, VIRTIO_ID_BLOCK,
sizeof(struct virtio_blk_config),
sizeof(VirtIOBlock));
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 5583166..31a711e 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -546,10 +546,6 @@ static int virtio_blk_init_pci(PCIDevice *pci_dev)
proxy-class_code != PCI_CLASS_STORAGE_OTHER)
proxy-class_code = PCI_CLASS_STORAGE_SCSI;
-if (!proxy-block.bs) {
-error_report(virtio-blk-pci: drive property not set);
-return -1;
-}
vdev = virtio_blk_init(pci_dev-qdev, proxy-block);
if (!vdev) {
return -1;
--
1.7.1.1
[Qemu-devel] [PATCH 2/5] Block migration fail, ignore error from bdrv_getlength
From: Shahar Havivi shah...@redhat.com
When there is no block driver associate with BlockDriverState bdrv_getlength
returns -ENOMEDIUM that cause block migration to fail
Signed-off-by: Shahar Havivi shah...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block-migration.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 7db6f02..a77106e 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -238,7 +238,7 @@ static void init_blk_migration_it(void *opaque,
BlockDriverState *bs)
if (!bdrv_is_read_only(bs)) {
sectors = bdrv_getlength(bs) BDRV_SECTOR_BITS;
-if (sectors == 0) {
+if (sectors = 0) {
return;
}
--
1.7.1.1
[Qemu-devel] Sparc32: reserve addresses for unimplemented devices on SS-20
Use empty_slot to reserve addresses for several unimplemented devices so they
won't fault.
- BPP (parallel port), DBRI (audio), SX (pixel processor), and vsimms
(framebuffer)
OBP for SS-20 either assumes these devices exist or probes without expecting
faults.
Signed-off-by: Bob Breuer breu...@mc.net
---
hw/sun4m.c | 53 +++--
1 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 208c8a8..e7a4cf6 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -89,6 +89,7 @@
#define MAX_CPUS 16
#define MAX_PILS 16
+#define MAX_VSIMMS 4
#define ESCC_CLOCK 4915200
@@ -98,6 +99,10 @@ struct sun4m_hwdef {
target_phys_addr_t serial_base, fd_base;
target_phys_addr_t afx_base, idreg_base, dma_base, esp_base, le_base;
target_phys_addr_t tcx_base, cs_base, apc_base, aux1_base, aux2_base;
+target_phys_addr_t bpp_base, dbri_base, sx_base;
+struct {
+target_phys_addr_t reg_base, vram_base;
+} vsimm[MAX_VSIMMS];
target_phys_addr_t ecc_base;
uint32_t ecc_version;
uint8_t nvram_machine_id;
@@ -810,6 +815,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
ram_addr_t RAM_size,
unsigned long kernel_size;
DriveInfo *fd[MAX_FD];
void *fw_cfg;
+unsigned int num_vsimms;
/* init CPUs */
if (!cpu_model)
@@ -872,8 +878,22 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
ram_addr_t RAM_size,
fprintf(stderr, qemu: Unsupported depth: %d\n, graphic_depth);
exit (1);
}
-tcx_init(hwdef-tcx_base, 0x0010, graphic_width, graphic_height,
- graphic_depth);
+num_vsimms = 0;
+if (num_vsimms == 0) {
+tcx_init(hwdef-tcx_base, 0x0010, graphic_width, graphic_height,
+ graphic_depth);
+}
+
+for (i = num_vsimms; i MAX_VSIMMS; i++) {
+/* vsimm registers probed by OBP */
+if (hwdef-vsimm[i].reg_base) {
+empty_slot_init(hwdef-vsimm[i].reg_base, 0x2000);
+}
+}
+
+if (hwdef-sx_base) {
+empty_slot_init(hwdef-sx_base, 0x2000);
+}
lance_init(nd_table[0], hwdef-le_base, ledma, ledma_irq);
@@ -920,6 +940,19 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
ram_addr_t RAM_size,
slavio_irq[5]);
}
+if (hwdef-dbri_base) {
+/* ISDN chip with attached CS4215 audio codec */
+/* prom space */
+empty_slot_init(hwdef-dbri_base+0x1000, 0x30);
+/* reg space */
+empty_slot_init(hwdef-dbri_base+0x1, 0x100);
+}
+
+if (hwdef-bpp_base) {
+/* parallel port */
+empty_slot_init(hwdef-bpp_base, 0x20);
+}
+
kernel_size = sun4m_load_kernel(kernel_filename, initrd_filename,
RAM_size);
@@ -1063,9 +1096,25 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.dma_base = 0xef040ULL,
.esp_base = 0xef080ULL,
.le_base = 0xef0c0ULL,
+.bpp_base = 0xef480ULL,
.apc_base = 0xefa00ULL, // XXX should not exist
.aux1_base= 0xff180ULL,
.aux2_base= 0xff1a01000ULL,
+.dbri_base= 0xee000ULL,
+.sx_base = 0xf8000ULL,
+.vsimm= {
+{
+.reg_base = 0x9c00ULL,
+.vram_base = 0xfc00ULL
+}, {
+.reg_base = 0x9000ULL,
+.vram_base = 0xf000ULL
+}, {
+.reg_base = 0x9400ULL
+}, {
+.reg_base = 0x9800ULL
+}
+},
.ecc_base = 0xfULL,
.ecc_version = 0x2000, // version 0, implementation 2
.nvram_machine_id = 0x72,
--
1.6.2.2.1669.g7eaf8
[Qemu-devel] [PATCH 5/5] ide scsi virtio-blk: Reject empty drives unless media is removable
From: Markus Armbruster arm...@redhat.com
Disks without media make no sense. For SCSI, a Linux guest kernel
complains during boot. I didn't try other combinations.
scsi-generic doesn't need the additional check, because it already
requires bdrv_is_sg(), which fails without media.
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/ide/core.c |4
hw/scsi-disk.c |5 +
hw/virtio-blk.c |4
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index af52c2c..e20f2e7 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2630,6 +2630,10 @@ int ide_init_drive(IDEState *s, BlockDriverState *bs,
s-drive_kind = IDE_CD;
bdrv_set_change_cb(bs, cdrom_change_cb, s);
} else {
+if (!bdrv_is_inserted(s-bs)) {
+error_report(Device needs media, but drive is empty);
+return -1;
+}
if (bdrv_is_read_only(bs)) {
error_report(Can't use a read-only drive);
return -1;
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index c30709c..f43f2d0 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1059,6 +1059,11 @@ static int scsi_disk_initfn(SCSIDevice *dev)
s-bs = s-qdev.conf.bs;
is_cd = bdrv_get_type_hint(s-bs) == BDRV_TYPE_CDROM;
+if (!is_cd !bdrv_is_inserted(s-bs)) {
+error_report(Device needs media, but drive is empty);
+return -1;
+}
+
if (bdrv_get_on_error(s-bs, 1) != BLOCK_ERR_REPORT) {
error_report(Device doesn't support drive option rerror);
return -1;
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 99e9dd2..f50069d 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -495,6 +495,10 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf
*conf)
error_report(virtio-blk-pci: drive property not set);
return NULL;
}
+if (!bdrv_is_inserted(conf-bs)) {
+error_report(Device needs media, but drive is empty);
+return NULL;
+}
s = (VirtIOBlock *)virtio_common_init(virtio-blk, VIRTIO_ID_BLOCK,
sizeof(struct virtio_blk_config),
--
1.7.1.1
[Qemu-devel] Re: [Bug 544527] Re: usbfs is bugged with 2.6.32.9 and =2.6.33 (breaks VMWare, Qemu, sane scanners, ...)
On Tue, Jul 13, 2010 at 5:14 PM, David Kühling
544...@bugs.launchpad.net wrote:
This bugfix is incomplete. Isochronous transfers are still broken, when
running 32-bit software on a 64-bit kernel. Function
processcompl_compat() in devio.c needs a similar fix to the fix that was
applied to processcompl(). Looking at processcompl_compat() I see:
if (as-userbuffer urb-actual_length)
if (copy_to_user(as-userbuffer, urb-transfer_buffer,
urb-actual_length))
return -EFAULT;
correct code would be something like
if (as-userbuffer urb-actual_length) {
if (urb-number_of_packets 0) /* Isochronous */
i = urb-transfer_buffer_length;
else /* Non-Isoc */
i = urb-actual_length;
if (copy_to_user(as-userbuffer, urb-transfer_buffer, i))
goto err_out;
}
(note the difference between urb-actual_length and
urb-transfer_buffer_length).
With kernel 2.6.32-23-generic x86_64 on Ubuntu 10.04, using proprietary
USB-hardware hooked up to the USB bus (with software compiled for
32-bit), I can directly observe how isochronous transfers retrieved via
ioctl(.. USBDEVFS_REAPURB ..) are too short, i.e. the kernel does not
write the end of the data packet to the supplied buffer. Booting on the
2.6.31 kernel still present from before I upgraded from Ubuntu 9.10, the
same software runs flawlessly.
As a workaround I'll use the older kernel for now (also I could compile
for 64-bit, actually...).
yes you're right, since we distribute 64 and 32bit drivers it doesn't
really affect us.
before applying any change you can submit some patches to us and we
can test them if needed.
Things should definitely not go upstream untested anymore as it used
to happen in the past with various kernel releases. (isochronous is
bugged with 2.6.26/27/28 (memory leak) and 32/33 (copying wrong memory
area). Luckily our hardware supports switching from ISO to BULK in
order to work around those issues - but bulk transfers have a bad
performance in userspace
Markus
cheers,
David
--
usbfs is bugged with 2.6.32.9 and =2.6.33 (breaks VMWare, Qemu, sane
scanners, ...)
https://bugs.launchpad.net/bugs/544527
You received this bug notification because you are a direct subscriber
of the bug.
--
usbfs is bugged with 2.6.32.9 and =2.6.33 (breaks VMWare, Qemu, sane
scanners, ...)
https://bugs.launchpad.net/bugs/544527
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Fix Committed
Status in SANE-backends - Backends for SANE: Fix Committed
Status in Tv Time: Fix Committed
Status in Virtualbox: Fix Committed
Status in “linux” package in Ubuntu: Fix Committed
Bug description:
Binary package hint: tvtime
There's a problem with isochronous and usbfs, suse tried to improve usbfs but
it end up that it broke usbfs.
For isochronous the entire packet needs to be copied and not only a part of it.
http://lkml.org/lkml/2010/2/26/490 (Report)
http://lkml.org/lkml/2010/2/27/226 (Bugfix)
please merge this bugfix asap.
ProblemType: Bug
Architecture: amd64
Date: Mon Mar 22 21:09:00 2010
DistroRelease: Ubuntu 10.04
LiveMediaBuild: Ubuntu 10.04 Lucid Lynx - Alpha amd64 (20100322)
Package: tvtime 1.0.2-5ubuntu2
ProcEnviron:
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: tvtime
Uname: Linux 2.6.32-16-generic x86_64
Re: [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for query-qdm
Luiz Capitulino lcapitul...@redhat.com writes: On Tue, 13 Jul 2010 13:49:46 +0200 Markus Armbruster arm...@redhat.com wrote: [cc: kraxel] I didn't get around to review v1. Sorry. Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes: Changelog from v1 - - renamed props to properties - updated the examples - reworded the explanations of name and description - split type into a json-object, adding qmp and qdev - list all possible values for bus - list all possible values for qdev on type - list all possible values for qmp on type --- qemu-monitor.hx | 88 +++ 1 files changed, 88 insertions(+), 0 deletions(-) diff --git a/qemu-monitor.hx b/qemu-monitor.hx index 2af3de6..0055d0a 100644 --- a/qemu-monitor.hx +++ b/qemu-monitor.hx @@ -2490,6 +2490,94 @@ STEXI show device tree @item info qdm show qdev device model list +ETEXI +SQMP +query-qdm +- + +Describe the capabilities of all devices registered with qdev. + +The returned output is a json-array, each element is a json-object describing +a single device type. + +Each json-object contains the following: + +- name: name of the device (json-string) +- bus: the name of the bus type for the device (json-string) +- Possible values: PCI, SCSI, I2C, ISA, SSI, USB, virtio-serial-bus, System Missing: IDE (hw/ide/qdev.c) and s390-virtio (hw/s390-virtio-bus.c). What about System, is it ok to expose it? What makes it special? +- alias: an alias by which the device is also known (json-string, optional) +- description: description of the device (json-string, optional) +- creatable: whether this device can be created on command line (json-boolean) on the command line is misleading; it applies to monitor (human QMP) as well. by the user? When is a device not creatable? Stuff like i440FX: if your board comes with it, you already got it, if not, you can't have it. +- properties: a list where each element is an json-object that describes a + property of the device. Each json-object contains the following: + - name: the name of the property (json-string) + - type: a json-object that contains the following: +- qdev: the internal name of the type of the property (json-string) +- Possible values: uint8, uint16, uint32, uint64, int32, macaddr, + drive, chr, string, netdev, bit, taddr Didn't see this before, but we should not use too short names like chr and taddr. +- qmp: the json equivalent type of the internal type (json-string) +- Possible values: integer, string, boolean Fairly close to JSON Schema, but there are differences. Do we need qdev? Is exposing it wise? Smells a bit too much of internal detail for comfort... Agreed, although this was a suggestion from me. Could we use type just like JSON Schema? Drop qdev or move it out of type, then make type what its member qmp is now. The most important point here is to try to figure out how clients are going to use this. Actually, the fact that libvirt doesn't actually need this makes me wonder if we should have it in the first place, at the same time listing the property name w/o saying what type it accepts doesn't seem to be that useful either. Adding stuff we need when we need it is easier and less painfull than taking out stuff when we realize we shouldn't have added it :) Let's look at all possibilities: 1. Drop qmp key and rename qdev to type (ie. use the qdev type only) This was the original proposal. I don't like it because its values are quite low-level and have no meaning in json. If this is needed, then I think it needs a complement specifying the json type for it. 2. Drop qdev key and rename qmp to type (ie. use the json type only) Let's start with this, and add more information as needed. This is what makes sense when self-documenting the protocol, however, given the original proposal, I wonder if this is going to be enough. That is, say a property takes a MAC address. By using the json type we will just say string, how is the client going to know that it's actually a MAC address in a string format? I think the primary use for self-documentation is to let clients figure out whether something they know how to use is actually there. For that use, we don't need to describe how MAC addresses look like. Perhaps other uses could use such information. For instance, a hypothetical graphical front end to the QEMU monitor could let the user configure arbitrary properties without understanding them. For what it's worth, JSON schema has separate optional properties like format, enum, minimum, maximum, and more. enum seems particularly useful. 3. Use both qdev and qmp keys Then clients can have a matrix of qdev and qmp types, then when
Re: [Qemu-devel] cg14
Another preview of the cg14 framebuffer. Activate by selecting SS-20 machine and setting width 1024, i.e. -M SS-20 -g 1152x900. Note that NetBSD assumes 1152x900, while OBP also supports 1024x768, 1280x1024, and 1600x1280. New since last time: - All video memory accesses implemented X under linux now works (uses RGB instead of XRGB space) - Hooked into qdev Todo: - fix NetBSD display - add draw_line templates to handle other than 32-bit RGB host displays - use VGA_DIRTY tracking - What's the equivalent of stb_p that also sets the dirty bits? - inform OpenBIOS of cg14 framebuffer - Can we pass nvalias screen /obio/cgfourteen to the firmware? Bob --- Makefile.target |1 + hw/cg14.c | 850 +++ hw/sun4m.c | 22 ++ 3 files changed, 873 insertions(+), 0 deletions(-) create mode 100644 hw/cg14.c diff --git a/Makefile.target b/Makefile.target index 3ef4666..54a2ae4 100644 --- a/Makefile.target +++ b/Makefile.target @@ -255,6 +255,7 @@ else obj-sparc-y = sun4m.o lance.o tcx.o sun4m_iommu.o slavio_intctl.o obj-sparc-y += slavio_timer.o slavio_misc.o sparc32_dma.o obj-sparc-y += cs4231.o eccmemctl.o sbi.o sun4c_intctl.o +obj-sparc-y += cg14.o endif obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o diff --git a/hw/cg14.c b/hw/cg14.c new file mode 100644 index 000..533dc04 --- /dev/null +++ b/hw/cg14.c @@ -0,0 +1,850 @@ +/* + * QEMU CG14 Frame buffer + * + * Copyright (c) 2010 Bob Breuer breu...@mc.net + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include console.h +#include sysbus.h +#include qdev-addr.h + +//#define DEBUG_CG14 +//#define DEBUG_DAC +//#define DEBUG_CONFIG + +/* + * Sun CG14 framebuffer (without SX) + * CG14 = vsimm framebuffer (video ram and dac) + * SX = pixel processor (acceleration) built into chipset + * + * Documentation: not publicly documented by Sun + * linux driver: drivers/video/cg14.c + * NetBSD/OpenBSD: src/sys/arch/sparc/dev/cgfourteen* + * + * Takes up one memory slot: + * A[28:26] = slot number (4 to 7) + * regs: size 0x1 @ 0x09c00 (0x8000 + slot * 64M) + * vmem: size upto 16MB @ 0x0fc00 (0xE000 + slot * 64M) + * + * SS-20 OBP only supports slots 7 (onboard output) and 4 (AVB output) + * + * memory map: + * reg+0x = control registers + * reg+0x1000 = cursor registers + * reg+0x2000 = dac registers (ADV7152) + * reg+0x3000 = xlut + * reg+0x4000 = clut1 + * reg+0x5000 = clut2 + * reg+0x6000 = clut3 (if implemented) + * reg+0xf000 = autoinc + * + * mem+0x000 = XBGR (01234567) + * mem+0x100 = BGR (.123.567) writes to X are blocked, reads are ok + * mem+0x200 = X16 (0246) + * mem+0x280 = C16 (1357) + * mem+0x300 = X32 (04) + * mem+0x340 = B32 (15) + * mem+0x380 = G32 (26) + * mem+0x3c0 = R32 (37) + */ + +#define CG14_REG_SIZE 0x1 +#define CG14_VMEM_SLOTSIZE(6420) + +#define CG14_MONID_1024x768 0 +#define CG14_MONID_1600x1280 1 +#define CG14_MONID_1280x1024 2 +#define CG14_MONID_1152x900 7 + +#define CG14_MONID_DEFAULTCG14_MONID_1024x768 + + +#define CG14_MCR_INTENABLE 0x80 +#define CG14_MCR_VIDENABLE 0x40 +#define CG14_MCR_PIXMODE_MASK 0x30 +#define CG14_MCR_PIXMODE_8 0x00 +#define CG14_MCR_PIXMODE_160x20 /* 8+8 (X16,C16) */ +#define CG14_MCR_PIXMODE_320x30 /* XBGR */ + + +#ifdef DEBUG_CG14 +#define DPRINTF(fmt, ...) \ +printf(CG14: fmt , ## __VA_ARGS__) +#else +#define DPRINTF(fmt, ...) +#endif + +#ifdef DEBUG_DAC +#define DPRINTF_DAC(fmt, ...) \ +printf(CG14 dac: fmt , ## __VA_ARGS__) +#else +#define DPRINTF_DAC(fmt, ...) +#endif + +#ifdef DEBUG_CONFIG +#define DPRINTF_CONFIG(fmt, ...)\ +printf(CG14: fmt , ## __VA_ARGS__) +#else +#define DPRINTF_CONFIG(fmt, ...) +#endif + +#define
Re: [Qemu-devel] [PULL 0/5] Block patches
On Tuesday, July 13, 2010 10:54:21 am Kevin Wolf wrote: These are some more fixes that should go into 0.13. Any of these 0.12-stable material? The following changes since commit f077caa99c21847152e706e77b378cb0ec2f: Merge remote branch 'mst/for_anthony' into staging (2010-07-13 08:56:27 -0500) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Markus Armbruster (3): virtio-pci: Check for virtio_blk_init() failure virtio-blk: Fix virtio-blk-s390 to require drive ide scsi virtio-blk: Reject empty drives unless media is removable Shahar Havivi (1): Block migration fail, ignore error from bdrv_getlength Stefan Weil (1): qemu-img: Fix copy+paste bug in documentation block-migration.c |2 +- hw/ide/core.c |4 hw/scsi-disk.c|5 + hw/virtio-blk.c | 10 ++ hw/virtio-pci.c |5 ++--- qemu-img-cmds.hx |2 +- 6 files changed, 23 insertions(+), 5 deletions(-)
Re: [Qemu-devel] Re: [OpenBIOS] [commit] r791 - in trunk/openbios-devel: fs/grubfs include/fs packages
Aurelien Jarno wrote: Unfortunately this commit has broken PowerPC boot using the Quik bootloader. CD-ROM boot is not affected. This can easily be reproduced using the image from: http://people.debian.org/~aurel32/qemu/powerpc/debian_lenny_powerpc_small.qcow2 I have tried with the latest available revision, and the problem is still there. Does anyone has an idea of the problem before I start debugging it? [CCed: qemu-devel@nongnu.org as this version is now used in QEMU] Thanks for the report - this should now be fixed as of OpenBIOS r821. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: [Qemu-devel] [PULL 0/5] Block patches
Am 13.07.2010 18:43, schrieb Brian Jackson: On Tuesday, July 13, 2010 10:54:21 am Kevin Wolf wrote: These are some more fixes that should go into 0.13. Any of these 0.12-stable material? I'll try to have a closer look tomorrow. Probably not these, but I think there are some more patches in git master which could go into 0.12-stable. Kevin
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On 07/13/2010 02:40 AM, Avi Kivity wrote: On 07/13/2010 09:57 AM, Aurelien Jarno wrote: Avi Kivity a écrit : On 07/12/2010 05:57 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.12.n+1 I won't be at the KVM call, but I can work on that in the next days. Basically the stable tree already contains a lot of fixes and we can do a call for patches for this release. One week should be enough, so that we can have the release at the end of next week (a few technical days are needed in addition). Thanks. I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). Would you like to see more frequent stable releases or more frequent master releases? The later is a bit easier since it doesn't involve maintaining and testing two code bases. Regards, Anthony Liguori
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On 07/13/2010 07:57 PM, Anthony Liguori wrote: I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). Would you like to see more frequent stable releases or more frequent master releases? Yes. But in this context I'm interested in stable releases. We have bugs reported, fixed, and the fix applied, yet the fixes are unreachable to users. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On Tuesday, July 13, 2010 12:01:22 pm Avi Kivity wrote: On 07/13/2010 07:57 PM, Anthony Liguori wrote: I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). Would you like to see more frequent stable releases or more frequent master releases? Yes. But in this context I'm interested in stable releases. We have bugs reported, fixed, and the fix applied, yet the fixes are unreachable to users. Especially so since qemu-kvm 0.12-stable hasn't been merged with qemu basically since 0.12.4 came out. I was trying to help one of the Gentoo maintainers find post 0.12.4 patches the other day and had to point them to the upstream qemu stable tree.
[Qemu-devel] [PATCH] set proper migration status on -write error (v4)
If -write fails, declare migration status as MIG_STATE_ERROR.
Also, in buffered_file.c, -close the object in case of an
error.
Fixes migrate -d exec:dd of=file, where dd fails to open file.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/buffered_file.c b/buffered_file.c
index 54dc6c2..be147d6 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -222,8 +222,10 @@ static void buffered_rate_tick(void *opaque)
{
QEMUFileBuffered *s = opaque;
-if (s-has_error)
+if (s-has_error) {
+buffered_close(s);
return;
+}
qemu_mod_timer(s-timer, qemu_get_clock(rt_clock) + 100);
diff --git a/migration.c b/migration.c
index b49964c..f8e6325 100644
--- a/migration.c
+++ b/migration.c
@@ -316,8 +316,14 @@ ssize_t migrate_fd_put_buffer(void *opaque, const void
*data, size_t size)
if (ret == -1)
ret = -(s-get_error(s));
-if (ret == -EAGAIN)
+if (ret == -EAGAIN) {
qemu_set_fd_handler2(s-fd, NULL, NULL, migrate_fd_put_notify, s);
+} else if (ret 0) {
+if (s-mon) {
+monitor_resume(s);
+}
+s-state = MIG_STATE_ERROR;
+}
return ret;
}
[Qemu-devel] [STABLE] Call for patches
Hi all, A few people requested a new stable release. The current stable branch already contains quite a few patches, that have been cherry-picked at the same time they have been committed to HEAD, but some important patches are probably missing. If you would like to see some more patches, please submit them with the [STABLE] tag by Tuesday 20th 12:00 UTC. Then I'll try to release QEMU 0.12.5 by the end of next week. Thanks in advance. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Re: [OpenBIOS] [commit] r791 - in trunk/openbios-devel: fs/grubfs include/fs packages
On Tue, Jul 13, 2010 at 05:45:14PM +0100, Mark Cave-Ayland wrote: Aurelien Jarno wrote: Unfortunately this commit has broken PowerPC boot using the Quik bootloader. CD-ROM boot is not affected. This can easily be reproduced using the image from: http://people.debian.org/~aurel32/qemu/powerpc/debian_lenny_powerpc_small.qcow2 I have tried with the latest available revision, and the problem is still there. Does anyone has an idea of the problem before I start debugging it? [CCed: qemu-devel@nongnu.org as this version is now used in QEMU] Thanks for the report - this should now be fixed as of OpenBIOS r821. That was fast ;-) Thanks for the fix, I'll commit this new version to QEMU. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH v2 00/18] [PATCH v2 00/18] VNC Updates for 0.13
On Wednesday 07 July 2010 13:57:48 Corentin Chary wrote: This set contains all my patchs related to tight and threaded vnc server. Since v1: * Add a fix for jpeg and png with non-24bpp displays * Better default values for vnc options in ./configure * Fixed Tight PNG to use its own encoding number (-260) * Cleaned tight send_sub_rect() [ snip ] Can anybody comment on the likelihood of this being committed in 0.13? I'd like to evaluate some particular use cases with these VNC changes, however if it is not likely to be in 0.13 I will, unfortunately, have to bump my evaluations to a lower priority. Thanks, -Rick
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On 07/13/2010 08:19 PM, Brian Jackson wrote: Yes. But in this context I'm interested in stable releases. We have bugs reported, fixed, and the fix applied, yet the fixes are unreachable to users. Especially so since qemu-kvm 0.12-stable hasn't been merged with qemu basically since 0.12.4 came out. I was trying to help one of the Gentoo maintainers find post 0.12.4 patches the other day and had to point them to the upstream qemu stable tree. An email should suffice to get things merged. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] Automatic generation of code-generator components
Dear QEMU developers -- I have had some email conversation with a few active developers, and with their encouragement, want to open it up for the whole list to comment. For several years my research group at UMass has been developing generic code-generator generator (CGG) technology. Historic CGGs have always been tied to a particular code-generation framework, that is, to a particular intermediate representation (IR) and compiler. Our tool, called GIST (for Generator of Instruction Selectors Tool), is designed to work from any reasonable IR and to connect to any reasonable framework. More technical details below, but what we are hoping for is to be able to say that if we make this industrial-strength with some funding from the National Science Foundation, the QEMU community will be interested in using it. No commitment -- just that you think it *might* be a good idea if we can make it go. We would use QEMU as one of our demo environments. Ok, more details. We have an architecture description language called CISL (CoGenT Instruction Set Language; CoGenT is our overall project's name). It is somewhat like C or Java in appearance. You define the various memories and registers, and the instructions. To generate an instruction selector from input ISA A (generally a compiler IR, but not necessarily) to output ISA B (generally, but not always, a hardware architecture), you start with descriptions of A and B in CISL -- some of which may already be around. You also write what we call a *mapping* from A to B, which simply indicates where on B each memory/register of A should go. The tool then finds instruction selector patterns, at least one for each instruction of the A machine. For any given retargetable *framework* (compiler, interpreter, emulator), we write one *adapter*, that knows how to take GIST patterns in their internal form and write them out in the way that the framework needs them. Here's an example. Suppose we are going from A = QEMU IR to B = MIPS, that is, the same as the TCG back end for an emulator running on the MIPS processor. We have written a CISL description for the QEMU IR (yes, already), and suppose we have one for the MIPS, sufficient for code generation anyway. [Side note: Compilers do not generally use every instruction of their target, e.g., not the privileged mode ones, etc. Also, in the presence of register allocation, they generally target a slightly virtualized machine -- one with a huge number of registers, which register allocation then resolves to real registers and occasional spilled locations.] The mapping would talk about how to find QEMU memory on the MIPS (perhaps a dedicated base register), etc., and would also capture the conventions for calling helper routines, and so on. The adapter for QEMU TCG back ends would generate something like a C switch statement with one case for each QEMU IR instruction. Each case might have some additional case analysis. This is because (as you see in QEMU), a given IR instruction can have special cases depending on values of constants, whether something is in a register, etc. GIST will have found different patterns for each of these, and with each one there would be a *constraint*, indicating when it applies. For example, patterns for adding a constant value on the MIPS would likely have a special case for constants that fit in 16 bits, since then you can use one immediate instruction. Likewise, the constant 0 is a special case since it can just be a move. In addition to constraints, patterns have costs, which one can develop for any given target, but would typically be based on number of instructions, number of instruction bytes, number of memory references, etc. Thus the case analysis for a given instruction would check for the lowest cost patterns first, and would conclude with the most general pattern (but which may be the most expensive). The adapter would also need to generate the information needed by the QEMU TCG register allocator. Now, here are some things of additional interest: - While QEMU IR - emulation host code-generation is maybe the most obvious case, we can also handle the front end emulation target - QEMU IR generation. This probably requires a slightly different description of machine A than when A is the emulation host -- after all, we must handle *all* instructions, including privileged ones, etc. But it is possible to make the descriptions modular in such a way that instructions used in both cases are not repeated. - I noticed that someone is looking at interpretation rather than compilation. We have seen that we can generate functional simulators (very close to emulators) from CISL descriptions. Thus, it would be possible to generate a simulator for any of the machines of interest. What QEMU provides is a framework with all the memory and device modeling, etc. - An approach like this might make it easier to maintain a range of different models of the same
Re: [Qemu-devel] Re: [PATCH] ceph/rbd block driver for qemu-kvm (v3)
On Sat, Jun 19, 2010 at 8:48 AM, Christian Brunner c...@muc.de wrote: Are you going to send a final version which includes Simone's patch or should I apply them as two patches and just accept that rbd is broken after the first one? Or were there any other problems that need to be solved first? I'll send a final version, when I've tested everything. There is another problem with very large i/o requests. I suspect that this can be triggered only with qemu-io and not in kvm, but I'll try to get a proper solution it anyway. Have you made any progress with this issue? Just note that there were a few changes we introduced recently (a format change that allows renaming of rbd images, and some snapshots support), so everything will needed to be reposted once we figure out the aio issue. Thanks, Yehuda
Re: [Qemu-devel] [PULL] pci, virtio fixes
On 07/11/2010 03:55 PM, Michael S. Tsirkin wrote: A couple of pci fixes in vmware are untested, but look very minor to me and no one objected yet - let's merge and handle the fallout if any. The following changes since commit 1ddda5cd364d2f82201830ca69675e17c60ded8e: Pulled. Thanks. Regards, Anthony Liguori AppleSMC device emulation (2010-07-11 20:33:10 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony Isaku Yamahata (3): pci: fix pci_device_reset pci hotplug: make pci_device_hot_remove() static pci hotplug: make pci hotplug return value to caller Michael S. Tsirkin (5): pcnet: address TODOs rtl8139: address TODOs vmware_vga: fix reset value for command register virtio-net: correct packet length math pci: fix bridge update hw/pci-hotplug.c |2 +- hw/pci.c | 34 +- hw/pcnet.c | 16 ++-- hw/rtl8139.c |3 --- hw/virtio-net.c | 41 - hw/vmware_vga.c |3 --- sysemu.h |1 - 7 files changed, 56 insertions(+), 44 deletions(-)
Re: [Qemu-devel] [PULL] pci, virtio fixes
On 07/11/2010 03:55 PM, Michael S. Tsirkin wrote: A couple of pci fixes in vmware are untested, but look very minor to me and no one objected yet - let's merge and handle the fallout if any. The following changes since commit 1ddda5cd364d2f82201830ca69675e17c60ded8e: AppleSMC device emulation (2010-07-11 20:33:10 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony Isaku Yamahata (3): pci: fix pci_device_reset pci hotplug: make pci_device_hot_remove() static pci hotplug: make pci hotplug return value to caller Michael S. Tsirkin (5): pcnet: address TODOs rtl8139: address TODOs vmware_vga: fix reset value for command register I think I neglected to respond but I did actually test this patch for you. All you need is a F13 live cd. Just boot it with -vmware vga. The driver is built in. Regards, Anthony Liguori virtio-net: correct packet length math pci: fix bridge update hw/pci-hotplug.c |2 +- hw/pci.c | 34 +- hw/pcnet.c | 16 ++-- hw/rtl8139.c |3 --- hw/virtio-net.c | 41 - hw/vmware_vga.c |3 --- sysemu.h |1 - 7 files changed, 56 insertions(+), 44 deletions(-)
[Qemu-devel] Re: [PATCH 0/8] vlan cleanup
On 07/13/2010 07:48 AM, Jan Kiszka wrote: Miguel Di Ciurcio Filho wrote: On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszkajan.kis...@web.de wrote: Miguel Di Ciurcio Filho wrote: This series removes the vlan stuff without mercy. I've tried to make the steps as small as possible, but the last one is huge. I did some basic tests and networking is still working, so reviews are welcome :-D Sorry, this is a bit too rude. This not only removes the vlan model, something one may talk about, but also the innocent socket back-ends and the useful pcap dump support. Socket back-ends allow quick and easy unprivileged inter-VM network setups. Nothing for production systems, but useful for testing purposes on boxes where taps are not allowed or unhandy to configure. I agree that it might be handy sometimes, but one could use VDE for that too. Runs on user-space and can be tunneled over SSH or netcat [1]. Yes, I know. But it requires yet another process as hop. In contrast, peer-to-peer sockets used to be as fast as taps in certain setup (now taps became faster again). Dump is critical to maintain. sockets is not terribly useful without vlan. Honestly, I have a hard time agreeing that it's terribly useful to begin with. I don't buy an argument about ease-of-use because how to properly configure the sockets backend is not at all obvious. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH 0/8] vlan cleanup
Anthony Liguori wrote: On 07/13/2010 07:48 AM, Jan Kiszka wrote: Miguel Di Ciurcio Filho wrote: On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszkajan.kis...@web.de wrote: Miguel Di Ciurcio Filho wrote: This series removes the vlan stuff without mercy. I've tried to make the steps as small as possible, but the last one is huge. I did some basic tests and networking is still working, so reviews are welcome :-D Sorry, this is a bit too rude. This not only removes the vlan model, something one may talk about, but also the innocent socket back-ends and the useful pcap dump support. Socket back-ends allow quick and easy unprivileged inter-VM network setups. Nothing for production systems, but useful for testing purposes on boxes where taps are not allowed or unhandy to configure. I agree that it might be handy sometimes, but one could use VDE for that too. Runs on user-space and can be tunneled over SSH or netcat [1]. Yes, I know. But it requires yet another process as hop. In contrast, peer-to-peer sockets used to be as fast as taps in certain setup (now taps became faster again). Dump is critical to maintain. sockets is not terribly useful without vlan. Honestly, I have a hard time agreeing that it's terribly useful to begin with. I don't buy an argument about ease-of-use because how to properly configure the sockets backend is not at all obvious. Old style: -net socket,listen=:12345 plus -net socket,connect=127.0.0.1:12345 and you have linked two VMs. New style would be less handy (unless we map -net on -netdev once vlans are gone), but still following the same pattern. I bet there is only a minor bit missing to get -netdev socket working, given that slirp apparently works. If I had time, I would look into this. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH 0/8] vlan cleanup
On 07/13/2010 02:08 PM, Jan Kiszka wrote: Anthony Liguori wrote: On 07/13/2010 07:48 AM, Jan Kiszka wrote: Miguel Di Ciurcio Filho wrote: On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszkajan.kis...@web.de wrote: Miguel Di Ciurcio Filho wrote: This series removes the vlan stuff without mercy. I've tried to make the steps as small as possible, but the last one is huge. I did some basic tests and networking is still working, so reviews are welcome :-D Sorry, this is a bit too rude. This not only removes the vlan model, something one may talk about, but also the innocent socket back-ends and the useful pcap dump support. Socket back-ends allow quick and easy unprivileged inter-VM network setups. Nothing for production systems, but useful for testing purposes on boxes where taps are not allowed or unhandy to configure. I agree that it might be handy sometimes, but one could use VDE for that too. Runs on user-space and can be tunneled over SSH or netcat [1]. Yes, I know. But it requires yet another process as hop. In contrast, peer-to-peer sockets used to be as fast as taps in certain setup (now taps became faster again). Dump is critical to maintain. sockets is not terribly useful without vlan. Honestly, I have a hard time agreeing that it's terribly useful to begin with. I don't buy an argument about ease-of-use because how to properly configure the sockets backend is not at all obvious. Old style: -net socket,listen=:12345 plus -net socket,connect=127.0.0.1:12345 and you have linked two VMs. New style would be less handy (unless we map -net on -netdev once vlans are gone), but still following the same pattern. For peer-to-peer. But -net socket + vlan also supports multiple point. And in this example, you're forwarding TCP over TCP which is pretty awful from a perf perspective. Last time I did a quick sniff test with -net socket, it was amazingly slow (like 10s of KB/s). I bet there is only a minor bit missing to get -netdev socket working, given that slirp apparently works. If I had time, I would look into this. I'm sure you could, but the result is a tremendously crippled version of -net socket which leads me to wonder if it's still even worth supporting. Regards, Anthony Liguori Jan
Re: [Qemu-devel] Re: [PATCH] ceph/rbd block driver for qemu-kvm (v3)
On Tue, Jul 13, 2010 at 11:27:03AM -0700, Yehuda Sadeh Weinraub wrote:
There is another problem with very large i/o requests. I suspect that
this can be triggered only
with qemu-io and not in kvm, but I'll try to get a proper solution it
anyway.
Have you made any progress with this issue? Just note that there were
a few changes we introduced recently (a format change that allows
renaming of rbd images, and some snapshots support), so everything
will needed to be reposted once we figure out the aio issue.
Attached is a patch where I'm trying to solve the issue
with pthreads locking. It works well with qemu-io, but I'm
not sure if there are interferences with other threads in
qemu/kvm (I didn't have time to test this, yet).
Another thing I'm not sure about is the fact, that these
large I/O requests only happen with qemu-io. I've never seen
this happen inside a virtual machine. So do we really have
to fix this, as it is only a warning message (laggy).
Regards,
Christian
From fcef3d897e0357b252a189ed59e43bfd5c24d229 Mon Sep 17 00:00:00 2001
From: Christian Brunner c...@muc.de
Date: Tue, 22 Jun 2010 21:51:09 +0200
Subject: [PATCH 27/27] add queueing delay based on queuesize
---
block/rbd.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/block/rbd.c b/block/rbd.c
index 10daf20..c6693d7 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -24,7 +24,7 @@
#include rados/librados.h
#include signal.h
-
+#include pthread.h
int eventfd(unsigned int initval, int flags);
@@ -50,6 +50,7 @@ int eventfd(unsigned int initval, int flags);
*/
#define OBJ_MAX_SIZE (1UL OBJ_DEFAULT_OBJ_ORDER)
+#define MAX_QUEUE_SIZE 33554432 // 32MB
typedef struct RBDAIOCB {
BlockDriverAIOCB common;
@@ -79,6 +80,9 @@ typedef struct BDRVRBDState {
uint64_t size;
uint64_t objsize;
int qemu_aio_count;
+uint64_t queuesize;
+pthread_mutex_t *queue_mutex;
+pthread_cond_t *queue_threshold;
} BDRVRBDState;
typedef struct rbd_obj_header_ondisk RbdHeader1;
@@ -334,6 +338,12 @@ static int rbd_open(BlockDriverState *bs, const char
*filename, int flags)
le64_to_cpus((uint64_t *) header-image_size);
s-size = header-image_size;
s-objsize = 1 header-options.order;
+s-queuesize = 0;
+
+s-queue_mutex = qemu_malloc(sizeof(pthread_mutex_t));
+pthread_mutex_init(s-queue_mutex, NULL);
+s-queue_threshold = qemu_malloc(sizeof(pthread_cond_t));
+pthread_cond_init (s-queue_threshold, NULL);
s-efd = eventfd(0, 0);
if (s-efd 0) {
@@ -356,6 +366,11 @@ static void rbd_close(BlockDriverState *bs)
{
BDRVRBDState *s = bs-opaque;
+pthread_cond_destroy(s-queue_threshold);
+qemu_free(s-queue_threshold);
+pthread_mutex_destroy(s-queue_mutex);
+qemu_free(s-queue_mutex);
+
rados_close_pool(s-pool);
rados_deinitialize();
}
@@ -443,6 +458,12 @@ static void rbd_finish_aiocb(rados_completion_t c, RADOSCB
*rcb)
int i;
acb-aiocnt--;
+acb-s-queuesize -= rcb-segsize;
+if (acb-s-queuesize+rcb-segsize MAX_QUEUE_SIZE acb-s-queuesize
= MAX_QUEUE_SIZE) {
+pthread_mutex_lock(acb-s-queue_mutex);
+pthread_cond_signal(acb-s-queue_threshold);
+pthread_mutex_unlock(acb-s-queue_mutex);
+}
r = rados_aio_get_return_value(c);
rados_aio_release(c);
if (acb-write) {
@@ -560,6 +581,14 @@ static BlockDriverAIOCB
*rbd_aio_rw_vector(BlockDriverState *bs,
rcb-segsize = segsize;
rcb-buf = buf;
+while (s-queuesize MAX_QUEUE_SIZE) {
+pthread_mutex_lock(s-queue_mutex);
+pthread_cond_wait(s-queue_threshold, s-queue_mutex);
+pthread_mutex_unlock(s-queue_mutex);
+}
+
+s-queuesize += segsize;
+
if (write) {
rados_aio_create_completion(rcb, NULL,
(rados_callback_t) rbd_finish_aiocb,
--
1.7.0.4
Re: [Qemu-devel] Re: [PATCH] ceph/rbd block driver for qemu-kvm (v3)
On Tue, Jul 13, 2010 at 12:23 PM, Christian Brunner c...@muc.de wrote: On Tue, Jul 13, 2010 at 11:27:03AM -0700, Yehuda Sadeh Weinraub wrote: There is another problem with very large i/o requests. I suspect that this can be triggered only with qemu-io and not in kvm, but I'll try to get a proper solution it anyway. Have you made any progress with this issue? Just note that there were a few changes we introduced recently (a format change that allows renaming of rbd images, and some snapshots support), so everything will needed to be reposted once we figure out the aio issue. Attached is a patch where I'm trying to solve the issue with pthreads locking. It works well with qemu-io, but I'm not sure if there are interferences with other threads in qemu/kvm (I didn't have time to test this, yet). Another thing I'm not sure about is the fact, that these large I/O requests only happen with qemu-io. I've never seen this happen inside a virtual machine. So do we really have to fix this, as it is only a warning message (laggy). We can have it configurable, and by default not use it. We don't need to feed the osds with more data that they can digest anyway, since that will only increase our memory usage -- whether it's just a warning or a real error. So a bounded approach that doesn't hurt performance makes sense. I'll merge this one into our tree so that it could get some broader testing, however, I think the qemu code requires using the qemu_cond wrappers instead of directly using the pthread_cond_*(). Thanks, Yehuda
Re: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
On Tue, Jun 29, 2010 at 9:29 PM, Isaku Yamahata yamah...@valinux.co.jp wrote:
On Tue, Jun 29, 2010 at 11:48:13AM -0600, Cam Macdonell wrote:
On Tue, Jun 29, 2010 at 12:50 AM, Avi Kivity a...@redhat.com wrote:
On 06/28/2010 11:38 PM, Cam Macdonell wrote:
Is this really the address the guest programmed, or is qemu
misinterpreting
it?
Well, what's the answer?
You're going to have to give me a hint on how to determine that.
lspci in the guest shows the following
Memory at c200 (64-bit, non-prefetchable) [size=1024M]
does that demonstrate a guest generated address?
That's the result of a round trip: the guest programmed the address and
then
read it back. ?It could have been screwed up in the first place, or perhaps
qemu screwed it up.
Add a printf() to the config space handlers in qemu (likely in your own
code) on writes and reads, and show the relevant writes (and reads) for
this
BAR.
That's the theory of deductive debugging; however browsing the code shows
the guest is at fault:
? ? ? ?for (i = 0; i PCI_NUM_REGIONS; i++) {
? ? ? ? ? ?int ofs;
? ? ? ? ? ?if (i == PCI_ROM_SLOT)
? ? ? ? ? ? ? ?ofs = PCI_ROM_ADDRESS;
? ? ? ? ? ?else
? ? ? ? ? ? ? ?ofs = PCI_BASE_ADDRESS_0 + i * 4;
? ? ? ? ? ?u32 old = pci_config_readl(bdf, ofs);
? ? ? ? ? ?u32 mask;
? ? ? ? ? ?if (i == PCI_ROM_SLOT) {
? ? ? ? ? ? ? ?mask = PCI_ROM_ADDRESS_MASK;
? ? ? ? ? ? ? ?pci_config_writel(bdf, ofs, mask);
? ? ? ? ? ?} else {
? ? ? ? ? ? ? ?if (old PCI_BASE_ADDRESS_SPACE_IO)
? ? ? ? ? ? ? ? ? ?mask = PCI_BASE_ADDRESS_IO_MASK;
? ? ? ? ? ? ? ?else
? ? ? ? ? ? ? ? ? ?mask = PCI_BASE_ADDRESS_MEM_MASK;
? ? ? ? ? ? ? ?pci_config_writel(bdf, ofs, ~0);
? ? ? ? ? ?}
? ? ? ? ? ?u32 val = pci_config_readl(bdf, ofs);
? ? ? ? ? ?pci_config_writel(bdf, ofs, old);
? ? ? ? ? ?if (val != 0) {
? ? ? ? ? ? ? ?u32 size = (~(val mask)) + 1;
? ? ? ? ? ? ? ?if (val PCI_BASE_ADDRESS_SPACE_IO)
? ? ? ? ? ? ? ? ? ?paddr = pci_bios_io_addr;
? ? ? ? ? ? ? ?else
? ? ? ? ? ? ? ? ? ?paddr = pci_bios_mem_addr;
? ? ? ? ? ? ? ?*paddr = ALIGN(*paddr, size);
? ? ? ? ? ? ? ?pci_set_io_region_addr(bdf, i, *paddr);
? ? ? ? ? ? ? ?*paddr += size;
? ? ? ? ? ?}
? ? ? ?}
? ? ? ?break;
? ?}
Seabios completely ignore the 64-bitness of the BAR. ?Looks like it also
thinks the second half of the BAR is an I/O region instead of memory (hence
the c200, that's part of the pci portio region.
I've sent the patches to address it. But they haven't been merged yet.
seabios doesn't map BARs beyond 4GB.
If bar is mapped beyond 4GB, guest BIOS does it.
Have those patches been merged yet?
To see how seabios works, it would help to increase CONFIG_DEBUG_LEVEL
in config.h of seabios
Where does the output from seabios end up? Inside dmesg?
Do post those reads and writes, I think there's more than one thing wrong
here.
Here it is, I added the debug statements to pci_read_config and
pci_default_write_config.
here are the reads and writes to offsets 0x18 and 0x1c where a 64-bit
BAR2 config would be configured
It seems that 0x1c is accessed as BAR3.
The write value in the log is always 0.
Some comment in the log.
pci_read_config: (val) 0x4 - 0x18 (addr)
pci_write_config: (val) 0x0 - 0x18 (addr)
pci_read_config: (val) 0xc004 - 0x18 (addr)
pci_write_config: (val) 0x0 - 0x18 (addr)
pci_read_config: (val) 0x4 - 0x18 (addr)
pci_write_config: (val) 0x0 - 0x18 (addr)
pci_read_config: (val) 0x0 - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
pci_read_config: (val) 0x - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
pci_read_config: (val) 0x0 - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
pci_read_config: (val) 0x4 - 0x18 (addr)
pci_write_config: (val) 0x0 - 0x18 (addr)
pci_read_config: (val) 0xc004 - 0x18 (addr)
pci_write_config: (val) 0x0 - 0x18 (addr)
pci_read_config: (val) 0xc040 - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
pci_read_config: (val) 0x - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
the complete read/write profile is below along with debug statements
from the map functions for the BARs (prefixed with IVSHMEM)
pci_read_config: (val) 0x1af4 - 0x0 (addr)
pci_read_config: (val) 0x0 - 0xe (addr)
pci_read_config: (val) 0x1af4 - 0x0 (addr)
pci_read_config: (val) 0x1110 - 0x2 (addr)
pci_read_config: (val) 0x0 - 0xe (addr)
pci_read_config: (val) 0x1af4 - 0x0 (addr)
pci_read_config: (val) 0x0 - 0xe (addr)
pci_read_config: (val) 0x500 - 0xa (addr)
pci_read_config: (val) 0x1af4 - 0x0 (addr)
pci_read_config: (val) 0x1110 - 0x2 (addr)
pci_read_config: (val) 0x0 - 0x10 (addr)
pci_write_config: (val) 0x0 - 0x10 (addr)
pci_read_config: (val) 0xff00 - 0x10 (addr)
pci_write_config: (val) 0x0 - 0x10 (addr)
pci_read_config: (val) 0x0 - 0x10 (addr)
pci_write_config: (val) 0x0 - 0x10 (addr)
pci_read_config: (val) 0x0 -
Re: [Qemu-devel] cg14
2010/7/13 Bob Breuer breu...@mc.net: Another preview of the cg14 framebuffer. Activate by selecting SS-20 machine and setting width 1024, i.e. -M SS-20 -g 1152x900. Note that NetBSD assumes 1152x900, while OBP also supports 1024x768, 1280x1024, and 1600x1280. New since last time: - All video memory accesses implemented X under linux now works (uses RGB instead of XRGB space) - Hooked into qdev Great job! Todo: - fix NetBSD display - add draw_line templates to handle other than 32-bit RGB host displays - use VGA_DIRTY tracking - What's the equivalent of stb_p that also sets the dirty bits? afaics stb_phys does set the dirty bits. The ones which don't are st?_phys_notdirty . - inform OpenBIOS of cg14 framebuffer - Can we pass nvalias screen /obio/cgfourteen to the firmware? Do we have to? Why not just probe for the VSIMM? Bob --- Makefile.target | 1 + hw/cg14.c | 850 +++ hw/sun4m.c | 22 ++ 3 files changed, 873 insertions(+), 0 deletions(-) create mode 100644 hw/cg14.c diff --git a/Makefile.target b/Makefile.target index 3ef4666..54a2ae4 100644 --- a/Makefile.target +++ b/Makefile.target @@ -255,6 +255,7 @@ else obj-sparc-y = sun4m.o lance.o tcx.o sun4m_iommu.o slavio_intctl.o obj-sparc-y += slavio_timer.o slavio_misc.o sparc32_dma.o obj-sparc-y += cs4231.o eccmemctl.o sbi.o sun4c_intctl.o +obj-sparc-y += cg14.o endif obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o diff --git a/hw/cg14.c b/hw/cg14.c new file mode 100644 index 000..533dc04 --- /dev/null +++ b/hw/cg14.c @@ -0,0 +1,850 @@ +/* + * QEMU CG14 Frame buffer + * + * Copyright (c) 2010 Bob Breuer breu...@mc.net + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include console.h +#include sysbus.h +#include qdev-addr.h + +//#define DEBUG_CG14 +//#define DEBUG_DAC +//#define DEBUG_CONFIG + +/* + * Sun CG14 framebuffer (without SX) + * CG14 = vsimm framebuffer (video ram and dac) + * SX = pixel processor (acceleration) built into chipset + * + * Documentation: not publicly documented by Sun + * linux driver: drivers/video/cg14.c + * NetBSD/OpenBSD: src/sys/arch/sparc/dev/cgfourteen* + * + * Takes up one memory slot: + * A[28:26] = slot number (4 to 7) + * regs: size 0x1 @ 0x09c00 (0x8000 + slot * 64M) + * vmem: size upto 16MB @ 0x0fc00 (0xE000 + slot * 64M) + * + * SS-20 OBP only supports slots 7 (onboard output) and 4 (AVB output) + * + * memory map: + * reg+0x = control registers + * reg+0x1000 = cursor registers + * reg+0x2000 = dac registers (ADV7152) + * reg+0x3000 = xlut + * reg+0x4000 = clut1 + * reg+0x5000 = clut2 + * reg+0x6000 = clut3 (if implemented) + * reg+0xf000 = autoinc + * + * mem+0x000 = XBGR (01234567) + * mem+0x100 = BGR (.123.567) writes to X are blocked, reads are ok + * mem+0x200 = X16 (0246) + * mem+0x280 = C16 (1357) + * mem+0x300 = X32 (04) + * mem+0x340 = B32 (15) + * mem+0x380 = G32 (26) + * mem+0x3c0 = R32 (37) + */ + +#define CG14_REG_SIZE 0x1 +#define CG14_VMEM_SLOTSIZE (6420) + +#define CG14_MONID_1024x768 0 +#define CG14_MONID_1600x1280 1 +#define CG14_MONID_1280x1024 2 +#define CG14_MONID_1152x900 7 + +#define CG14_MONID_DEFAULT CG14_MONID_1024x768 + + +#define CG14_MCR_INTENABLE 0x80 +#define CG14_MCR_VIDENABLE 0x40 +#define CG14_MCR_PIXMODE_MASK 0x30 +#define CG14_MCR_PIXMODE_8 0x00 +#define CG14_MCR_PIXMODE_16 0x20 /* 8+8 (X16,C16) */ +#define CG14_MCR_PIXMODE_32 0x30 /* XBGR */ + + +#ifdef DEBUG_CG14 +#define DPRINTF(fmt, ...) \ + printf(CG14: fmt , ## __VA_ARGS__) +#else +#define DPRINTF(fmt, ...) +#endif + +#ifdef DEBUG_DAC +#define DPRINTF_DAC(fmt,
Re: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote: Seabios completely ignore the 64-bitness of the BAR. ?Looks like it also thinks the second half of the BAR is an I/O region instead of memory (hence the c200, that's part of the pci portio region. I've sent the patches to address it. But they haven't been merged yet. seabios doesn't map BARs beyond 4GB. If bar is mapped beyond 4GB, guest BIOS does it. Have those patches been merged yet? They have been merged into seabios upstream now. qemu seabios fork hasn't pulled for a while, though. To see how seabios works, it would help to increase CONFIG_DEBUG_LEVEL in config.h of seabios Where does the output from seabios end up? Inside dmesg? It outputs them to the serial console which qemu emulates. seabios is out of kernel control, so dmesg doesn't show it. pci_read_config: (val) 0x0 - 0x1c (addr) pci_write_config: (val) 0x0 - 0x1c (addr) pci_read_config: (val) 0x - 0x1c (addr) pci_write_config: (val) 0x0 - 0x1c (addr) pci_read_config: (val) 0x0 - 0x1c (addr) pci_write_config: (val) 0x0 - 0x1c (addr) seabios BAR3. Not sure how it is mapped from this message. Isn't the BAR3 from the fact that a 64-bit BAR would use both BAR2 and BAR3 to store all 64-bits? Yes. Seabios misbehaves. 64bit bar is(was) a missing feature. -- yamahata
[Qemu-devel] Re: [PATCH] set proper migration status on -write error (v4)
On Tue, 13 Jul 2010 14:30:22 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
If -write fails, declare migration status as MIG_STATE_ERROR.
Also, in buffered_file.c, -close the object in case of an
error.
Fixes migrate -d exec:dd of=file, where dd fails to open file.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/buffered_file.c b/buffered_file.c
index 54dc6c2..be147d6 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -222,8 +222,10 @@ static void buffered_rate_tick(void *opaque)
{
QEMUFileBuffered *s = opaque;
-if (s-has_error)
+if (s-has_error) {
+buffered_close(s);
return;
+}
qemu_mod_timer(s-timer, qemu_get_clock(rt_clock) + 100);
diff --git a/migration.c b/migration.c
index b49964c..f8e6325 100644
--- a/migration.c
+++ b/migration.c
@@ -316,8 +316,14 @@ ssize_t migrate_fd_put_buffer(void *opaque, const void
*data, size_t size)
if (ret == -1)
ret = -(s-get_error(s));
-if (ret == -EAGAIN)
+if (ret == -EAGAIN) {
qemu_set_fd_handler2(s-fd, NULL, NULL, migrate_fd_put_notify, s);
+} else if (ret 0) {
+if (s-mon) {
+monitor_resume(s);
s/monitor_resume(s)/monitor_resume(s-mon)
+}
+s-state = MIG_STATE_ERROR;
+}
return ret;
}
Re: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
On Tue, Jul 13, 2010 at 2:41 PM, Isaku Yamahata yamah...@valinux.co.jp wrote: On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote: Seabios completely ignore the 64-bitness of the BAR. ?Looks like it also thinks the second half of the BAR is an I/O region instead of memory (hence the c200, that's part of the pci portio region. I've sent the patches to address it. But they haven't been merged yet. seabios doesn't map BARs beyond 4GB. If bar is mapped beyond 4GB, guest BIOS does it. Have those patches been merged yet? They have been merged into seabios upstream now. qemu seabios fork hasn't pulled for a while, though. To see how seabios works, it would help to increase CONFIG_DEBUG_LEVEL in config.h of seabios Where does the output from seabios end up? Inside dmesg? It outputs them to the serial console which qemu emulates. seabios is out of kernel control, so dmesg doesn't show it. pci_read_config: (val) 0x0 - 0x1c (addr) pci_write_config: (val) 0x0 - 0x1c (addr) pci_read_config: (val) 0x - 0x1c (addr) pci_write_config: (val) 0x0 - 0x1c (addr) pci_read_config: (val) 0x0 - 0x1c (addr) pci_write_config: (val) 0x0 - 0x1c (addr) seabios BAR3. Not sure how it is mapped from this message. Isn't the BAR3 from the fact that a 64-bit BAR would use both BAR2 and BAR3 to store all 64-bits? Yes. Seabios misbehaves. 64bit bar is(was) a missing feature. -- yamahata With the latest seabios git passed via -bios, I no longer see the 48-bit address, but instead a 32-bit address and then . This guest has 1gb of RAM so the address isn't be mapped beyond 4g. IVSHMEM: guest pci addr = e000, guest h/w addr = 1090912256, size = 2000 IVSHMEM: guest pci addr = , guest h/w addr = 1090912256, size = 2000 However, booting fails when I use a 64-bit BAR. Booting is fine with a 32-bit BAR. HPET: 1 timers in total, 0 timers will be used for per-cpu timer divide error: [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.35-rc1 #280 /Bochs RIP: 0010:[812a801b] [812a801b] hpet_alloc+0x12c/0x35b RSP: 0018:88003e61fd80 EFLAGS: 00010246 RAX: 00038d7ea4c68000 RBX: 88003e6efd80 RCX: RDX: RSI: RDI: 817b8520 RBP: 88003e61fdc0 R08: 80d0 R09: c900 R10: 88003f9ac600 R11: R12: 88003e61fdd0 R13: c900 R14: R15: 817a00a9 FS: () GS:88000200() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 01a42000 CR4: 06f0DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 1, threadinfo 88003e61e000, task 88003e62) Stack: 88003f43ab90 88003f43ab90 81ca3174 81b1d596 0 0100 0100 0 88003e61fe80 8102945d fed0 c900 Call Trace: [81b1d596] ? hpet_late_init+0x0/0xea [8102945d] hpet_reserve_platform_timers+0x10b/0x115 [81b1d596] ? hpet_late_init+0x0/0xea [81b1d601] hpet_late_init+0x6b/0xea [81b1d596] ? hpet_late_init+0x0/0xea [81002069] do_one_initcall+0x5e/0x159 [81b0b71e] kernel_init+0x18e/0x21c [8100aa24] kernel_thread_helper+0x4/0x10 [81b0b590] ? kernel_init+0x0/0x21c [8100aa20] ? kernel_thread_helper+0x0/0x10 Code: 89 1d 8a 92 b3 00 48 c1 ea 21 8b 73 34 49 c7 c7 a9 00 7a 81 48 8d 04 02 4c 89 f2 48 c7 c7 20 85 7b 81 48 c1 ea 20 48 89 d1 31 d2 48 f7 f1 83 7b 30 01 48 c7 c1 cd fa 7c 81 49 0f 46 cf 48 89 43 RIP [812a801b] hpet_alloc+0x12c/0x35b RSP 88003e61fd80 ---[ end trace a7919e7f17c0a725 ]--- Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: swapper Tainted: G D 2.6.35-rc1 #280 Call Trace: [8145b870] panic+0x8b/0x10b [81056a93] ? exit_ptrace+0x38/0x121 [8104f9e8] do_exit+0x7a/0x722 [8104c3bd] ? spin_unlock_irqrestore+0xe/0x10 [8104cfd8] ? kmsg_dump+0x12b/0x145 [8145eaa9] oops_end+0xbf/0xc7 [8100d299] die+0x5a/0x63 [8145e4b3] do_trap+0x121/0x130 [8100b560] do_divide_error+0x96/0x9f [812a801b] ? hpet_alloc+0x12c/0x35b [8100a83b] divide_error+0x1b/0x20 [812a801b] ? hpet_alloc+0x12c/0x35b [81b1d596] ? hpet_late_init+0x0/0xea [8102945d] hpet_reserve_platform_timers+0x10b/0x115 [81b1d596] ? hpet_late_init+0x0/0xea [81b1d601] hpet_late_init+0x6b/0xea [81b1d596] ? hpet_late_init+0x0/0xea [81002069] do_one_initcall+0x5e/0x159 [81b0b71e] kernel_init+0x18e/0x21c [8100aa24] kernel_thread_helper+0x4/0x10
[Qemu-devel] [PATCH] set proper migration status on -write error (v5)
If -write fails, declare migration status as MIG_STATE_ERROR.
Also, in buffered_file.c, -close the object in case of an
error.
Fixes migrate -d exec:dd of=file, where dd fails to open file.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/buffered_file.c b/buffered_file.c
index 54dc6c2..be147d6 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -222,8 +222,10 @@ static void buffered_rate_tick(void *opaque)
{
QEMUFileBuffered *s = opaque;
-if (s-has_error)
+if (s-has_error) {
+buffered_close(s);
return;
+}
qemu_mod_timer(s-timer, qemu_get_clock(rt_clock) + 100);
diff --git a/migration.c b/migration.c
index b49964c..f8e6325 100644
--- a/migration.c
+++ b/migration.c
@@ -316,8 +316,14 @@ ssize_t migrate_fd_put_buffer(void *opaque, const void
*data, size_t size)
if (ret == -1)
ret = -(s-get_error(s));
-if (ret == -EAGAIN)
+if (ret == -EAGAIN) {
qemu_set_fd_handler2(s-fd, NULL, NULL, migrate_fd_put_notify, s);
+} else if (ret 0) {
+if (s-mon) {
+monitor_resume(s-mon);
+}
+s-state = MIG_STATE_ERROR;
+}
return ret;
}
Re: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
On Tue, Jul 13, 2010 at 04:48:19PM -0600, Cam Macdonell wrote:
On Tue, Jul 13, 2010 at 2:41 PM, Isaku Yamahata yamah...@valinux.co.jp
wrote:
On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote:
Seabios completely ignore the 64-bitness of the BAR. ?Looks like it
also
thinks the second half of the BAR is an I/O region instead of memory
(hence
the c200, that's part of the pci portio region.
I've sent the patches to address it. But they haven't been merged yet.
seabios doesn't map BARs beyond 4GB.
If bar is mapped beyond 4GB, guest BIOS does it.
Have those patches been merged yet?
They have been merged into seabios upstream now.
qemu seabios fork hasn't pulled for a while, though.
To see how seabios works, it would help to increase CONFIG_DEBUG_LEVEL
in config.h of seabios
Where does the output from seabios end up? ?Inside dmesg?
It outputs them to the serial console which qemu emulates.
seabios is out of kernel control, so dmesg doesn't show it.
pci_read_config: (val) 0x0 - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
pci_read_config: (val) 0x - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
pci_read_config: (val) 0x0 - 0x1c (addr)
pci_write_config: (val) 0x0 - 0x1c (addr)
seabios BAR3. Not sure how it is mapped from this
message.
Isn't the BAR3 from the fact that a 64-bit BAR would use both BAR2 and
BAR3 to store all 64-bits?
Yes. Seabios misbehaves. 64bit bar is(was) a missing feature.
--
yamahata
With the latest seabios git passed via -bios, I no longer see the
48-bit address, but instead a 32-bit address and then
. This guest has 1gb of RAM so the address isn't be
mapped beyond 4g.
Can I see the debug log like before?
(hopefully seabios with CONFIG_DEBUG_LEVEL enabled.)
Do you know who sets the BAR to ?
If it's seabios, does the following patch help?
diff --git a/src/pciinit.c b/src/pciinit.c
index b110531..ce07709 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -117,11 +117,7 @@ static int pci_bios_allocate_region(u16 bdf, int
region_num)
int is_64bit = !(val PCI_BASE_ADDRESS_SPACE_IO)
(val PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64;
if (is_64bit) {
-if (size 0) {
-pci_config_writel(bdf, ofs + 4, 0);
-} else {
-pci_config_writel(bdf, ofs + 4, ~0);
-}
+pci_config_writel(bdf, ofs + 4, 0);
}
return is_64bit;
}
IVSHMEM: guest pci addr = e000, guest h/w addr = 1090912256, size =
2000
IVSHMEM: guest pci addr = , guest h/w addr =
1090912256, size = 2000
However, booting fails when I use a 64-bit BAR. Booting is fine with
a 32-bit BAR.
HPET: 1 timers in total, 0 timers will be used for per-cpu timer
divide error: [#1] SMP last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.35-rc1 #280 /Bochs
RIP: 0010:[812a801b] [812a801b] hpet_alloc+0x12c/0x35b
RSP: 0018:88003e61fd80 EFLAGS: 00010246
RAX: 00038d7ea4c68000 RBX: 88003e6efd80 RCX:
RDX: RSI: RDI: 817b8520
RBP: 88003e61fdc0 R08: 80d0 R09: c900
R10: 88003f9ac600 R11: R12: 88003e61fdd0
R13: c900 R14: R15: 817a00a9
FS: () GS:88000200() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: CR3: 01a42000 CR4: 06f0DR0:
DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 88003e61e000, task 88003e62)
Stack:
88003f43ab90 88003f43ab90 81ca3174 81b1d596
0 0100 0100
0 88003e61fe80 8102945d fed0 c900
Call Trace:
[81b1d596] ? hpet_late_init+0x0/0xea
[8102945d] hpet_reserve_platform_timers+0x10b/0x115
[81b1d596] ? hpet_late_init+0x0/0xea
[81b1d601] hpet_late_init+0x6b/0xea
[81b1d596] ? hpet_late_init+0x0/0xea
[81002069] do_one_initcall+0x5e/0x159
[81b0b71e] kernel_init+0x18e/0x21c
[8100aa24] kernel_thread_helper+0x4/0x10
[81b0b590] ? kernel_init+0x0/0x21c
[8100aa20] ? kernel_thread_helper+0x0/0x10
Code: 89 1d 8a 92 b3 00 48 c1 ea 21 8b 73 34 49 c7 c7 a9 00 7a 81 48
8d 04 02 4c 89 f2 48 c7 c7 20 85 7b 81 48 c1 ea 20 48 89 d1 31 d2 48
f7 f1 83 7b 30 01 48
c7 c1 cd fa 7c 81 49 0f 46 cf 48 89 43
RIP [812a801b] hpet_alloc+0x12c/0x35b
RSP 88003e61fd80
---[ end trace a7919e7f17c0a725 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper
[Qemu-devel] [RFC PATCH 0/7] AMD IOMMU emulation patchset
Hi everybody, This is my work on the AMD IOMMU emulation project. I've put this, along with the SeaBIOS patches (which you need to test), in my Git repos here: http://repo.or.cz/w/qemu-kvm/amd-iommu.git http://repo.or.cz/w/seabios/amd-iommu.git While it works for Linux guests (didn't try anything else), it's not yet complete. But the ported devices work, and so may others that either don't do DMA (VGA for example) or they're not on a PCI bus. Passing devices from a guest to a nested guest also works. It seems no modifications were needed for that (well, except getting a host kernel on which nested SVM works right ;), and I'd recommend 2.6.34.1), but I only tested with the rtl8139. Will test soon with a doubly nested guest to cover that scenario as well, along with testing other emulated hw. I'd like your opinions on this. Perhaps you could test it and report if you find any issues. Some things aren't done/complete yet: - fixing the theoretical AIO issue, but it's not a priority right now - actually testing that access checking works (should inject faults) - implementing skipped translation levels - a translation cache might be a good idea - implementing features not used by Linux (e.g. interrupt remapping) That being said, any feedback is welcome. Thanks, Eduard P.S.: I'd also like to thank Paul Brook for his help on figuring out some aspects of the IOMMU layer. Eduard - Gabriel Munteanu (7): Generic IOMMU layer AMD IOMMU emulation pci: call IOMMU hooks ide: IOMMU support rtl8139: IOMMU support eepro100: IOMMU support ac97: IOMMU support Makefile.target |3 + configure | 11 + hw/ac97.c | 20 ++- hw/amd_iommu.c | 621 +++ hw/eepro100.c | 141 + hw/ide/core.c | 46 +++-- hw/iommu.c | 82 hw/iommu.h | 260 +++ hw/pc.c |4 + hw/pc.h |3 + hw/pci.c| 21 ++ hw/pci_ids.h|2 + hw/pci_regs.h |1 + hw/qdev.h |6 + hw/rtl8139.c| 98 ++ 15 files changed, 1225 insertions(+), 94 deletions(-) create mode 100644 hw/amd_iommu.c create mode 100644 hw/iommu.c create mode 100644 hw/iommu.h
[Qemu-devel] [RFC PATCH 7/7] ac97: IOMMU support
Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/ac97.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/hw/ac97.c b/hw/ac97.c
index 4319bc8..0e30d80 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -15,6 +15,7 @@
*/
#include hw.h
+#include iommu.h
#include audiodev.h
#include audio/audio.h
#include pci.h
@@ -221,9 +222,13 @@ static void cold_reset (AC97LinkState * s)
static void fetch_bd (AC97LinkState *s, AC97BusMasterRegs *r)
{
+struct iommu *iommu;
+DeviceState *dev;
uint8_t b[8];
-cpu_physical_memory_read (r-bdbar + r-civ * 8, b, 8);
+iommu = iommu_get(s-dev.qdev, dev);
+
+iommu_read (iommu, dev, r-bdbar + r-civ * 8, b, 8);
r-bd_valid = 1;
r-bd.addr = le32_to_cpu (*(uint32_t *) b[0]) ~3;
r-bd.ctl_len = le32_to_cpu (*(uint32_t *) b[4]);
@@ -962,6 +967,9 @@ static int write_audio (AC97LinkState *s, AC97BusMasterRegs
*r,
uint32_t temp = r-picb 1;
uint32_t written = 0;
int to_copy = 0;
+struct iommu *iommu;
+DeviceState *dev;
+
temp = audio_MIN (temp, max);
if (!temp) {
@@ -969,10 +977,12 @@ static int write_audio (AC97LinkState *s,
AC97BusMasterRegs *r,
return 0;
}
+iommu = iommu_get(s-dev.qdev, dev);
+
while (temp) {
int copied;
to_copy = audio_MIN (temp, sizeof (tmpbuf));
-cpu_physical_memory_read (addr, tmpbuf, to_copy);
+iommu_read (iommu, dev, addr, tmpbuf, to_copy);
copied = AUD_write (s-voice_po, tmpbuf, to_copy);
dolog (write_audio max=%x to_copy=%x copied=%x\n,
max, to_copy, copied);
@@ -1040,6 +1050,10 @@ static int read_audio (AC97LinkState *s,
AC97BusMasterRegs *r,
uint32_t nread = 0;
int to_copy = 0;
SWVoiceIn *voice = (r - s-bm_regs) == MC_INDEX ? s-voice_mc :
s-voice_pi;
+struct iommu *iommu;
+DeviceState *dev;
+
+iommu = iommu_get(s-dev.qdev, dev);
temp = audio_MIN (temp, max);
@@ -1056,7 +1070,7 @@ static int read_audio (AC97LinkState *s,
AC97BusMasterRegs *r,
*stop = 1;
break;
}
-cpu_physical_memory_write (addr, tmpbuf, acquired);
+iommu_write (iommu, dev, addr, tmpbuf, acquired);
temp -= acquired;
addr += acquired;
nread += acquired;
--
1.7.1
[Qemu-devel] [RFC PATCH 4/7] ide: IOMMU support
Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/ide/core.c | 46 +++---
1 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 0b3b7c2..7f8f7df 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -26,6 +26,7 @@
#include hw/pc.h
#include hw/pci.h
#include hw/scsi.h
+#include hw/iommu.h
#include qemu-timer.h
#include sysemu.h
#include dma.h
@@ -433,7 +434,12 @@ static int dma_buf_prepare(BMDMAState *bm, int is_write)
uint32_t addr;
uint32_t size;
} prd;
-int l, len;
+int l, len, err, io_len;
+struct iommu *iommu;
+DeviceState *dev;
+target_phys_addr_t io_addr;
+
+iommu = iommu_get(s-bus-qbus.parent, dev);
qemu_sglist_init(s-sg, s-nsector / (IDE_PAGE_SIZE / 512) + 1);
s-io_buffer_size = 0;
@@ -443,7 +449,7 @@ static int dma_buf_prepare(BMDMAState *bm, int is_write)
if (bm-cur_prd_last ||
(bm-cur_addr - bm-addr) = IDE_PAGE_SIZE)
return s-io_buffer_size != 0;
-cpu_physical_memory_read(bm-cur_addr, (uint8_t *)prd, 8);
+err = iommu_read(iommu, dev, bm-cur_addr, (uint8_t *)prd, 8);
bm-cur_addr += 8;
prd.addr = le32_to_cpu(prd.addr);
prd.size = le32_to_cpu(prd.size);
@@ -455,11 +461,22 @@ static int dma_buf_prepare(BMDMAState *bm, int is_write)
bm-cur_prd_last = (prd.size 0x8000);
}
l = bm-cur_prd_len;
-if (l 0) {
-qemu_sglist_add(s-sg, bm-cur_prd_addr, l);
-bm-cur_prd_addr += l;
-bm-cur_prd_len -= l;
-s-io_buffer_size += l;
+while (l 0) {
+/*
+ * In case translation / access checking fails no
+ * transfer happens but we pretend it went through.
+ */
+err = iommu_translate(iommu, dev, bm-cur_prd_addr,
+ io_addr, io_len, !is_write);
+if (!err) {
+if (io_len l)
+io_len = l;
+qemu_sglist_add(s-sg, io_addr, io_len);
+}
+bm-cur_prd_addr += io_len;
+bm-cur_prd_len -= io_len;
+s-io_buffer_size += io_len;
+l -= io_len;
}
}
return 1;
@@ -516,6 +533,10 @@ static int dma_buf_rw(BMDMAState *bm, int is_write)
uint32_t size;
} prd;
int l, len;
+struct iommu *iommu;
+DeviceState *dev;
+
+iommu = iommu_get(s-bus-qbus.parent, dev);
for(;;) {
l = s-io_buffer_size - s-io_buffer_index;
@@ -526,7 +547,7 @@ static int dma_buf_rw(BMDMAState *bm, int is_write)
if (bm-cur_prd_last ||
(bm-cur_addr - bm-addr) = IDE_PAGE_SIZE)
return 0;
-cpu_physical_memory_read(bm-cur_addr, (uint8_t *)prd, 8);
+iommu_read(iommu, dev, bm-cur_addr, (uint8_t *)prd, 8);
bm-cur_addr += 8;
prd.addr = le32_to_cpu(prd.addr);
prd.size = le32_to_cpu(prd.size);
@@ -540,13 +561,8 @@ static int dma_buf_rw(BMDMAState *bm, int is_write)
if (l bm-cur_prd_len)
l = bm-cur_prd_len;
if (l 0) {
-if (is_write) {
-cpu_physical_memory_write(bm-cur_prd_addr,
- s-io_buffer + s-io_buffer_index,
l);
-} else {
-cpu_physical_memory_read(bm-cur_prd_addr,
- s-io_buffer + s-io_buffer_index,
l);
-}
+iommu_rw(iommu, dev, bm-cur_prd_addr,
+ s-io_buffer + s-io_buffer_index, l, is_write);
bm-cur_prd_addr += l;
bm-cur_prd_len -= l;
s-io_buffer_index += l;
--
1.7.1
[Qemu-devel] [RFC PATCH 1/7] Generic IOMMU layer
This provides an API for abstracting IOMMU functions. Hardware emulation
code can use it to request address translation and access checking. In
the absence of an emulated IOMMU, no translation/checking happens and
I/O goes through as before.
IOMMU emulation code must provide implementation-specific hooks for this
layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
Makefile.target |1 +
hw/iommu.c | 82 +
hw/iommu.h | 260 +++
hw/qdev.h |6 ++
4 files changed, 349 insertions(+), 0 deletions(-)
create mode 100644 hw/iommu.c
create mode 100644 hw/iommu.h
diff --git a/Makefile.target b/Makefile.target
index 70a9c1b..3f895ae 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -183,6 +183,7 @@ obj-$(CONFIG_VIRTFS) += virtio-9p.o
obj-y += rwhandler.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_NO_KVM) += kvm-stub.o
+obj-$(CONFIG_IOMMU) += iommu.o
# MSI-X depends on kvm for interrupt injection,
# so moved it from Makefile.objs to Makefile.target for now
diff --git a/hw/iommu.c b/hw/iommu.c
new file mode 100644
index 000..511756b
--- /dev/null
+++ b/hw/iommu.c
@@ -0,0 +1,82 @@
+/*
+ * Generic IOMMU layer
+ *
+ * Copyright (c) 2010 Eduard - Gabriel Munteanu
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include errno.h
+
+#include iommu.h
+
+struct iommu *iommu_get(DeviceState *dev, DeviceState **real_dev)
+{
+BusState *bus;
+
+while (dev) {
+bus = dev-parent_bus;
+if (!bus)
+goto out;
+
+if (bus-iommu) {
+*real_dev = dev;
+return bus-iommu;
+}
+
+dev = bus-parent;
+}
+
+out:
+*real_dev = NULL;
+return NULL;
+}
+
+int __iommu_rw(struct iommu *iommu,
+ DeviceState *dev,
+ target_phys_addr_t addr,
+ uint8_t *buf,
+ int len,
+ int is_write)
+{
+int plen, err;
+target_phys_addr_t paddr;
+unsigned perms;
+
+if (!is_write)
+perms = IOMMU_PERM_READ;
+else
+perms = IOMMU_PERM_WRITE;
+
+do {
+err = iommu-translate(iommu, dev, addr, paddr, plen, perms);
+if (err)
+return err;
+if (plen len)
+plen = len;
+
+cpu_physical_memory_rw(paddr, buf, plen, is_write);
+
+len -= plen;
+addr += plen;
+buf += plen;
+} while (len);
+
+return 0;
+}
diff --git a/hw/iommu.h b/hw/iommu.h
new file mode 100644
index 000..01996a6
--- /dev/null
+++ b/hw/iommu.h
@@ -0,0 +1,260 @@
+#ifndef QEMU_IOMMU_H
+#define QEMU_IOMMU_H
+
+#include pci.h
+#include targphys.h
+#include qdev.h
+
+/* Don't use directly. */
+struct iommu {
+void *opaque;
+
+void (*register_device)(struct iommu *iommu,
+DeviceState *dev);
+int (*translate)(struct iommu *iommu,
+ DeviceState *dev,
+ target_phys_addr_t addr,
+ target_phys_addr_t *paddr,
+ int *len,
+ unsigned perms);
+int (*start_transaction)(struct iommu *iommu,
+ DeviceState *dev);
+void (*end_transaction)(struct iommu *iommu,
+DeviceState *dev);
+};
+
+#define IOMMU_PERM_READ (1 0)
+#define IOMMU_PERM_WRITE (1 1)
+
+#define IOMMU_PERM_RW (IOMMU_PERM_READ | IOMMU_PERM_WRITE)
+
+static inline int iommu_nop_translate(struct iommu *iommu,
+ DeviceState *dev,
+ target_phys_addr_t addr,
+ target_phys_addr_t *paddr,
+ int *len,
+ unsigned perms)
+{
+*paddr = addr;
+*len = INT_MAX;
+
+return 0;
+}
+
+static inline int iommu_nop_rw(struct iommu *iommu,
[Qemu-devel] [RFC PATCH 3/7] pci: call IOMMU hooks
Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/pci.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 6871728..9c5d706 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -22,6 +22,7 @@
* THE SOFTWARE.
*/
#include hw.h
+#include iommu.h
#include pci.h
#include monitor.h
#include net.h
@@ -733,12 +734,25 @@ static void do_pci_unregister_device(PCIDevice *pci_dev)
pci_config_free(pci_dev);
}
+#ifdef CONFIG_IOMMU
+static inline int pci_iommu_register_device(PCIBus *bus, PCIDevice *dev)
+{
+return iommu_register_device(bus-qbus.iommu, dev-qdev);
+}
+#else
+static inline int pci_iommu_register_device(PCIBus *bus, PCIDevice *dev)
+{
+return 0;
+}
+#endif
+
PCIDevice *pci_register_device(PCIBus *bus, const char *name,
int instance_size, int devfn,
PCIConfigReadFunc *config_read,
PCIConfigWriteFunc *config_write)
{
PCIDevice *pci_dev;
+int err;
pci_dev = qemu_mallocz(instance_size);
pci_dev = do_pci_register_device(pci_dev, bus, name, devfn,
@@ -747,6 +761,13 @@ PCIDevice *pci_register_device(PCIBus *bus, const char
*name,
if (pci_dev == NULL) {
hw_error(PCI: can't register device\n);
}
+
+err = pci_iommu_register_device(bus, pci_dev);
+if (err) {
+hw_error(PCI: can't register device with IOMMU\n);
+return NULL;
+}
+
return pci_dev;
}
--
1.7.1
[Qemu-devel] [RFC PATCH 2/7] AMD IOMMU emulation
This introduces emulation for the AMD IOMMU, described in AMD I/O Virtualization Technology (IOMMU) Specification. Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro --- Makefile.target |2 + configure | 11 + hw/amd_iommu.c | 621 +++ hw/pc.c |4 + hw/pc.h |3 + hw/pci_ids.h|2 + hw/pci_regs.h |1 + 7 files changed, 644 insertions(+), 0 deletions(-) create mode 100644 hw/amd_iommu.c diff --git a/Makefile.target b/Makefile.target index 3f895ae..eb164ba 100644 --- a/Makefile.target +++ b/Makefile.target @@ -220,6 +220,8 @@ obj-i386-y += pcspk.o i8254.o obj-i386-$(CONFIG_KVM_PIT) += i8254-kvm.o obj-i386-$(CONFIG_KVM_DEVICE_ASSIGNMENT) += device-assignment.o +obj-i386-$(CONFIG_AMD_IOMMU) += amd_iommu.o + # Hardware support obj-ia64-y += ide.o pckbd.o vga.o $(SOUND_HW) dma.o $(AUDIODRV) obj-ia64-y += fdc.o mc146818rtc.o serial.o i8259.o ipf.o diff --git a/configure b/configure index af50607..a0730b7 100755 --- a/configure +++ b/configure @@ -317,6 +317,7 @@ io_thread=no mixemu=no kvm_cap_pit= kvm_cap_device_assignment= +amd_iommu=no kerneldir= aix=no blobs=yes @@ -629,6 +630,8 @@ for opt do ;; --enable-kvm-device-assignment) kvm_cap_device_assignment=yes ;; + --enable-amd-iommu-emul) amd_iommu=yes + ;; --enable-profiler) profiler=yes ;; --enable-cocoa) @@ -871,6 +874,8 @@ echo --disable-kvm-pitdisable KVM pit support echo --enable-kvm-pit enable KVM pit support echo --disable-kvm-device-assignment disable KVM device assignment support echo --enable-kvm-device-assignment enable KVM device assignment support +echo --disable-amd-iommu-emul disable AMD IOMMU emulation +echo --enable-amd-iommu-emul enable AMD IOMMU emulation echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets @@ -2251,6 +2256,7 @@ echo Install blobs $blobs echo KVM support $kvm echo KVM PIT support $kvm_cap_pit echo KVM device assig. $kvm_cap_device_assignment +echo AMD IOMMU emul. $amd_iommu echo fdt support $fdt echo preadv support$preadv echo fdatasync $fdatasync @@ -2645,6 +2651,11 @@ case $target_arch2 in x86_64) TARGET_BASE_ARCH=i386 target_phys_bits=64 +if test $amd_iommu = yes; then + echo CONFIG_AMD_IOMMU=y $config_target_mak + echo CONFIG_IOMMU=y $config_target_mak + echo CONFIG_IOMMU=y $config_host_mak +fi ;; ia64) target_phys_bits=64 diff --git a/hw/amd_iommu.c b/hw/amd_iommu.c new file mode 100644 index 000..e72f0c0 --- /dev/null +++ b/hw/amd_iommu.c @@ -0,0 +1,621 @@ +/* + * AMD IOMMU emulation + * + * Copyright (c) 2010 Eduard - Gabriel Munteanu + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include pc.h +#include hw.h +#include pci.h +#include iommu.h + +/* Capability registers */ +#define CAPAB_HEADER0x00 +#define CAPAB_REV_TYPE0x02 +#define CAPAB_FLAGS 0x03 +#define CAPAB_BAR_LOW 0x04 +#define CAPAB_BAR_HIGH 0x08 +#define CAPAB_RANGE 0x0C +#define CAPAB_MISC 0x10 + +#define CAPAB_SIZE 0x14 + +/* Capability header data */ +#define CAPAB_FLAG_IOTLBSUP (1 0) +#define CAPAB_FLAG_HTTUNNEL (1 1) +#define CAPAB_FLAG_NPCACHE (1 2) +#define CAPAB_INIT_REV (1 3) +#define CAPAB_INIT_TYPE 3 +#define CAPAB_INIT_REV_TYPE (CAPAB_REV | CAPAB_TYPE) +#define CAPAB_INIT_FLAGS(CAPAB_FLAG_NPCACHE | CAPAB_FLAG_HTTUNNEL) +#define CAPAB_INIT_MISC (64 15) | (48 8) +#define CAPAB_BAR_MASK ~((1UL 14) - 1) + +/* MMIO registers */ +#define MMIO_DEVICE_TABLE 0x +#define MMIO_COMMAND_BASE 0x0008 +#define MMIO_EVENT_BASE 0x0010
[Qemu-devel] [RFC PATCH 6/7] eepro100: IOMMU support
Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/eepro100.c | 141 +
1 files changed, 101 insertions(+), 40 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 97afa2c..74e1d15 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -43,6 +43,7 @@
#include stddef.h /* offsetof */
#include hw.h
+#include iommu.h
#include pci.h
#include net.h
#include eeprom93xx.h
@@ -306,10 +307,13 @@ static const uint16_t eepro100_mdi_mask[] = {
};
/* XXX: optimize */
-static void stl_le_phys(target_phys_addr_t addr, uint32_t val)
+static void stl_le_phys(struct iommu *iommu,
+DeviceState *dev,
+target_phys_addr_t addr,
+uint32_t val)
{
val = cpu_to_le32(val);
-cpu_physical_memory_write(addr, (const uint8_t *)val, sizeof(val));
+iommu_write(iommu, dev, addr, (const uint8_t *)val, sizeof(val));
}
#define POLYNOMIAL 0x04c11db6
@@ -687,17 +691,25 @@ static void set_ru_state(EEPRO100State * s, ru_state_t
state)
static void dump_statistics(EEPRO100State * s)
{
+struct iommu *iommu;
+DeviceState *dev;
+int err;
+
+iommu = iommu_get(s-dev.qdev, dev);
+
/* Dump statistical data. Most data is never changed by the emulation
* and always 0, so we first just copy the whole block and then those
* values which really matter.
* Number of data should check configuration!!!
*/
-cpu_physical_memory_write(s-statsaddr,
- (uint8_t *) s-statistics, s-stats_size);
-stl_le_phys(s-statsaddr + 0, s-statistics.tx_good_frames);
-stl_le_phys(s-statsaddr + 36, s-statistics.rx_good_frames);
-stl_le_phys(s-statsaddr + 48, s-statistics.rx_resource_errors);
-stl_le_phys(s-statsaddr + 60, s-statistics.rx_short_frame_errors);
+err = iommu_write(iommu, dev, s-statsaddr,
+ (uint8_t *) s-statistics, s-stats_size);
+stl_le_phys(iommu, dev, s-statsaddr + 0, s-statistics.tx_good_frames);
+stl_le_phys(iommu, dev, s-statsaddr + 36, s-statistics.rx_good_frames);
+stl_le_phys(iommu, dev,
+s-statsaddr + 48, s-statistics.rx_resource_errors);
+stl_le_phys(iommu, dev,
+s-statsaddr + 60, s-statistics.rx_short_frame_errors);
#if 0
stw_le_phys(s-statsaddr + 76, s-statistics.xmt_tco_frames);
stw_le_phys(s-statsaddr + 78, s-statistics.rcv_tco_frames);
@@ -707,7 +719,13 @@ static void dump_statistics(EEPRO100State * s)
static void read_cb(EEPRO100State *s)
{
-cpu_physical_memory_read(s-cb_address, (uint8_t *) s-tx, sizeof(s-tx));
+struct iommu *iommu;
+DeviceState *dev;
+int err;
+
+iommu = iommu_get(s-dev.qdev, dev);
+
+err = iommu_read(iommu, dev, s-cb_address, (uint8_t *) s-tx,
sizeof(s-tx));
s-tx.status = le16_to_cpu(s-tx.status);
s-tx.command = le16_to_cpu(s-tx.command);
s-tx.link = le32_to_cpu(s-tx.link);
@@ -723,6 +741,12 @@ static void tx_command(EEPRO100State *s)
uint8_t buf[2600];
uint16_t size = 0;
uint32_t tbd_address = s-cb_address + 0x10;
+struct iommu *iommu;
+DeviceState *dev;
+int err;
+
+iommu = iommu_get(s-dev.qdev, dev);
+
TRACE(RXTX, logout
(transmit, TBD array address 0x%08x, TCB byte count 0x%04x, TBD count
%u\n,
tbd_array, tcb_bytes, s-tx.tbd_count));
@@ -737,18 +761,18 @@ static void tx_command(EEPRO100State *s)
}
assert(tcb_bytes = sizeof(buf));
while (size tcb_bytes) {
-uint32_t tx_buffer_address = ldl_phys(tbd_address);
-uint16_t tx_buffer_size = lduw_phys(tbd_address + 4);
+uint32_t tx_buffer_address = iommu_ldl(iommu, dev, tbd_address);
+uint16_t tx_buffer_size = iommu_lduw(iommu, dev, tbd_address + 4);
#if 0
-uint16_t tx_buffer_el = lduw_phys(tbd_address + 6);
+uint16_t tx_buffer_el = iommu_lduw(tbd_address + 6);
#endif
tbd_address += 8;
TRACE(RXTX, logout
(TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n,
tx_buffer_address, tx_buffer_size));
tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
-cpu_physical_memory_read(tx_buffer_address, buf[size],
- tx_buffer_size);
+err = iommu_read(iommu, dev,
+ tx_buffer_address, buf[size], tx_buffer_size);
size += tx_buffer_size;
}
if (tbd_array == 0x) {
@@ -759,16 +783,18 @@ static void tx_command(EEPRO100State *s)
if (s-has_extended_tcb_support !(s-configuration[6] BIT(4))) {
/* Extended Flexible TCB. */
for (; tbd_count 2; tbd_count++) {
-uint32_t tx_buffer_address = ldl_phys(tbd_address);
-uint16_t tx_buffer_size = lduw_phys(tbd_address + 4);
-uint16_t
