Re: [Qemu-devel] CFP: 1st International QEMU Users Forum
On 11/26/10 15:21, Anthony Liguori wrote: > On 11/26/2010 08:15 AM, Jes Sorensen wrote: >> I would be all in favor of this! Do you want to attach it to another >> conference or totally standalone? >> > > Attaching is easier logistically but I don't know how much that helps if > it's a full 3 days instead of just a single day. Might be worth poking > the LF folks for some advice. > > But the key point is breadth, it should not be a "KVM Forum" but rather > an Open Virtualization conference with topics as high level as cloud > software automation and as low level as asynchronous page faults :-) Well that is definitely worth looking at, question is what continent would be preferred to have it on? I'll have a chat with LF to see what the options are. Cheers, Jes
Re: [Qemu-devel] CFP: 1st International QEMU Users Forum
Nathan Froyd a écrit : > On Sun, Nov 28, 2010 at 09:20:25AM +0100, Frédéric Pétrot wrote: >>IMHO someone from code sourcery would be great, as they (Paul Brooks in >> the >>older versions, it seems that Nathan is now taking over) are contributing >>most of the ARM emulation stuff. > > Well, Paul still knows way more than I do. I also have not done very > much of the ARM stuff; my focus has been on the MIPS and PowerPC side of > things. I think Peter has posted more in the way of ARM patches in the > last two weeks than we have done for the last year or so. :) (FWIW, I do > plan to add Reviewed-by tags to those this week.) > >>We may also have both talks organized one after the other covering both >>topics, but then Wolfgang and I have to see how to fit into the time and >>financial envelops (we can only pay the entrance fee for one people). >>This is now a choice to be made by the qemu-devel people. >>Please try to converge fast, so that we are in time for the DATE booklet. > > I'm sorry, what are the "both talks" you refer to above? Are you > proposing an additional talk alongside your (Frédéric's) existing talk? > -Nathan > No! I am very happy that you take over the introduction of the emulation. Indeed I was thinking that Alexander could be willing to introduce i.e. device emulation (he'll tell us). Can you send a title of yours ? Or shall we keep the same one, as it will be along these lines ? Frédéric -- +-+ | Frédéric Pétrot, Pr. ENSIMAG-TIMA/SLS frederic.pet...@imag.fr | | Phone : +33 4 76 57 48 70 Fluctuat nec mergitur | | Mobile: +33 6 74 57 99 65 Ad augusta per angusta | | Fax : +33 4 76 57 49 81 Eppur si muove | +-+ -- +-+ | Frédéric Pétrot, Pr. ENSIMAG-TIMA/SLS frederic.pet...@imag.fr | | Phone : +33 4 76 57 48 70 Fluctuat nec mergitur | | Mobile: +33 6 74 57 99 65 Ad augusta per angusta | | Fax : +33 4 76 57 49 81 Eppur si muove | +-+
Re: [Qemu-devel] CFP: 1st International QEMU Users Forum
On Sun, Nov 28, 2010 at 09:20:25AM +0100, Frédéric Pétrot wrote: >IMHO someone from code sourcery would be great, as they (Paul Brooks in the >older versions, it seems that Nathan is now taking over) are contributing >most of the ARM emulation stuff. Well, Paul still knows way more than I do. I also have not done very much of the ARM stuff; my focus has been on the MIPS and PowerPC side of things. I think Peter has posted more in the way of ARM patches in the last two weeks than we have done for the last year or so. :) (FWIW, I do plan to add Reviewed-by tags to those this week.) >We may also have both talks organized one after the other covering both >topics, but then Wolfgang and I have to see how to fit into the time and >financial envelops (we can only pay the entrance fee for one people). >This is now a choice to be made by the qemu-devel people. >Please try to converge fast, so that we are in time for the DATE booklet. I'm sorry, what are the "both talks" you refer to above? Are you proposing an additional talk alongside your (Frédéric's) existing talk? -Nathan
Re: neon acceleration via mmx/sse (was: Re: [Qemu-devel] CFP: 1st International QEMU Users Forum)
Peter Maydell a écrit : > 2010/11/28 Frédéric Pétrot : >> PS: We have indeed ourselves worked on the acceleration of the neon support >>(neon on mmx/sse instead of helpers) > > Slight tangent, but: How well did you find that worked? > Were you trying to retain bit-for-bit accuracy in the results? > > -- PMM > Ok, we worked on the integer neon only, as in integrated devices, we prefer fixed point for energy efficiency reasons (no plug, no fan, specialized applications). It works quite well, on synthetic benchmarks (loops with a growing number of simd instructions) we have a good speedup (4 to 6x) compared to the helper approach. Amdahl's law may well reduce this to almost nothing for most applications, but for video decoding and the like, it may have a value. We (do our best to) have an exact translation, and we checked against the arm of a beagleboard for the behavior. Incidentally, we have an interactive paper at DATE this year on this very topic. Don't hesitate to drop me a mail if you want to have a look at it. Frédéric Pétrot -- +-+ | Frédéric Pétrot, Pr. ENSIMAG-TIMA/SLS frederic.pet...@imag.fr | | Phone : +33 4 76 57 48 70 Fluctuat nec mergitur | | Mobile: +33 6 74 57 99 65 Ad augusta per angusta | | Fax : +33 4 76 57 49 81 Eppur si muove | +-+ -- +-+ | Frédéric Pétrot, Pr. ENSIMAG-TIMA/SLS frederic.pet...@imag.fr | | Phone : +33 4 76 57 48 70 Fluctuat nec mergitur | | Mobile: +33 6 74 57 99 65 Ad augusta per angusta | | Fax : +33 4 76 57 49 81 Eppur si muove | +-+
[Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 08:11:45PM +0100, Peter Stuge wrote: > Peter Stuge wrote: > > Specifying boot device using PCI BDF is a great example of using > > common structured data. That BDF exists both in machine and firmware > > data models. > > Gleb Natapov wrote: > > Bus numbers are assigned by a guest. Qemu knows nothing about them, > > so it specify device path by topology. > > Quite. By BDF I of course mean topology. ;) > Ah, then we are in violent agreement :) > The BDF itself is not much better than a BBS concept, since only the > firmware knows the details. > Yeap. > But the topology is common, even if bus number differs between > machine and firmware. > Correct. > How is the topology structured? I'm not sure that firmware can use a > "slot" number. Device number on the bus works, is that what you mean? > To specify device path to PCI card using topology one needs to specify slot.fn of all pci-to-pci buses from pci host controller to pci device in question. -- Gleb.
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 09:09:48PM +0200, Michael S. Tsirkin wrote: > On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote: > > On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote: > > > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote: > > > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > > > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > > > > > >>Anthony, Blue > > > > > > > >> > > > > > > > >>No comments on this patch series for almost a week. Can it be > > > > > > > >>applied? > > > > > > > > > > > > > > > >Does that mean everyone's happy or have folks not gotten around > > > > > > > >to > > > > > > > >review it? > > > > > > > > > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > > > > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to > > > > > > > get > > > > > > > it right. > > > > > > > > > > > > > > But I notice the there is no documentation - surely some is > > > > > > > needed? > > > > > > > > > > > > > > > > > > > The patch creates Openfirmware device path from qdev > > > > > > hierarchy. Each element of a device path depends on type of a bus > > > > > > the device resides on. You can find various bus bindings here: > > > > > > http://playground.sun.com/1275/bindings/ and main spec is here > > > > > > > > > > sun.com links have a tendency to disappear nowdays :) > > > > > Is this the official location? Aren't bindings part of some standard? > > > > I think this is official location. > > > > > > > > > > It also worries me that PCI Express bindings are in a 'proposal' form > > > > > from August 2004. The PCI bindings are from 1994. They are likely to > > > > > miss > > > > > some recent technology advancements :) > > > > > > > > > > > > > > > Further, while this last document which is only 28 page in length, is > > > > > not readable by itself: one must first digest the openfirmware spec. > > > > > However ... > > > > > > > > > > > http://forthworks.com/standards/of1275.pdf. > > > > > > > > > > That's 266 pages of a specification. I am guessing that most of it is > > > > > irrelevant for the task in question? Can we have a small text > > > > > document > > > > > including just the path format, please? > > > > > > > > > So basically you are complaining that reading specs is difficult. It > > > > is. That's > > > > life. > > > > > > Well, the specific format used is undocumented. Patch borrowed bits from > > > various specs, but it's undocumented which bits, and from which specs. > > > > > See above for documentation. Download everything. Read. > > > > > I do realize you had to go over all of these specs and do the difficult > > > work > > > to come up with the format, but please write documentation > > > for the rest of us. > > > > > Pleas read spec. You can even find that I interpreted spec incorrectly > > and point where the bug is. > > Seems a waste of time. As long as qemu and BIOS agree, it does > not matter what does the spec say. > So what. I don't get this "summarize spec for me here" request. > > That is the reason spec exists. I do not > > ask you to provide me with documentation for each and every thing you do > > in pci layer although it will be much simpler to read your executive > > summery then go and read complicated spec. The same hold true for any > > other piece of code that implement spec. > > > > -- > > Gleb. > > PCI is a hardware spec that guest drivers rely on for functionality. If > we implement it incorrectly, guests break. We also implement a large > part of the spec, quite unlike this case. The spec is also > organazed in the way that maps to our code. So if you > have msix.c, you look up msix in table of content and > you got it. And, we are adding pointers to spec chapters as we go on. > > With next patch to pci summarize pci spec for me please. It is to big and complex for me to understand in 3 minutes I have to look at it. -- Gleb.
[Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 08:00:29PM +0100, Peter Stuge wrote: > Gleb Natapov wrote: > > There is no way for qemu to know about BCVs or BEVs > > This is very much the key point. > > In order to have command line control over the boot process, the > machine and the firmware must agree on things. > > I see two options: > > 1. QEMU works very very hard to provide a machine that will result in > a particular BBS program flow in firmware, in the end resulting in > the desired device being used for booting - as long as QEMU and the > firmware happen to have the same understanding of the BBS. > Since qemu knows nothing about BCVs and BEVs it can't implement 1 since it can't know what BBS flow will look like in Seabios. > 2. QEMU passes boot instructions to the firmware based on immediate, > common, structured data. What is this "immediate, common, structured data"? This is the crux of the problem really. > > The first option seems disgusting to me, because it has many > drawbacks and no benefits. > > The second option requires inventing something that goes beyond the > established BIOS standards, maybe a reason for it to see fierce > resistance, but it is the only thing that makes sense. > > Specifying boot device using PCI BDF is a great example of using > common structured data. That BDF exists both in machine and firmware > data models. The scope of BBS is limited to the firmware, so it is > not really practical for creating consistency in a dynamic machine. > B from BDF does not exists in machine data model. -- Gleb.
[Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
Peter Stuge wrote: > Specifying boot device using PCI BDF is a great example of using > common structured data. That BDF exists both in machine and firmware > data models. Gleb Natapov wrote: > Bus numbers are assigned by a guest. Qemu knows nothing about them, > so it specify device path by topology. Quite. By BDF I of course mean topology. ;) The BDF itself is not much better than a BBS concept, since only the firmware knows the details. But the topology is common, even if bus number differs between machine and firmware. How is the topology structured? I'm not sure that firmware can use a "slot" number. Device number on the bus works, is that what you mean? //Peter
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote: > On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote: > > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote: > > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > > > > >>Anthony, Blue > > > > > > >> > > > > > > >>No comments on this patch series for almost a week. Can it be > > > > > > >>applied? > > > > > > > > > > > > > >Does that mean everyone's happy or have folks not gotten around to > > > > > > >review it? > > > > > > > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > > > > > it right. > > > > > > > > > > > > But I notice the there is no documentation - surely some is needed? > > > > > > > > > > > > > > > > The patch creates Openfirmware device path from qdev > > > > > hierarchy. Each element of a device path depends on type of a bus > > > > > the device resides on. You can find various bus bindings here: > > > > > http://playground.sun.com/1275/bindings/ and main spec is here > > > > > > > > sun.com links have a tendency to disappear nowdays :) > > > > Is this the official location? Aren't bindings part of some standard? > > > I think this is official location. > > > > > > > > It also worries me that PCI Express bindings are in a 'proposal' form > > > > from August 2004. The PCI bindings are from 1994. They are likely to > > > > miss > > > > some recent technology advancements :) > > > > > > > > > > > > Further, while this last document which is only 28 page in length, is > > > > not readable by itself: one must first digest the openfirmware spec. > > > > However ... > > > > > > > > > http://forthworks.com/standards/of1275.pdf. > > > > > > > > That's 266 pages of a specification. I am guessing that most of it is > > > > irrelevant for the task in question? Can we have a small text document > > > > including just the path format, please? > > > > > > > So basically you are complaining that reading specs is difficult. It is. > > > That's > > > life. > > > > Well, the specific format used is undocumented. Patch borrowed bits from > > various specs, but it's undocumented which bits, and from which specs. > > > See above for documentation. Download everything. Read. > > > I do realize you had to go over all of these specs and do the difficult work > > to come up with the format, but please write documentation > > for the rest of us. > > > Pleas read spec. You can even find that I interpreted spec incorrectly > and point where the bug is. Seems a waste of time. As long as qemu and BIOS agree, it does not matter what does the spec say. > That is the reason spec exists. I do not > ask you to provide me with documentation for each and every thing you do > in pci layer although it will be much simpler to read your executive > summery then go and read complicated spec. The same hold true for any > other piece of code that implement spec. > > -- > Gleb. PCI is a hardware spec that guest drivers rely on for functionality. If we implement it incorrectly, guests break. We also implement a large part of the spec, quite unlike this case. The spec is also organazed in the way that maps to our code. So if you have msix.c, you look up msix in table of content and you got it. And, we are adding pointers to spec chapters as we go on. -- MST
[Qemu-devel] [PATCH] Add basic read, write and create support for AMD SimNow HDD images.
$subj.
Someone asked about this format, wanting to try Haiku in SimNow, so I wrote
this.
I got a report of successfully booting a converted image in SimNow.
It doesn't yet support automatically growing the file, so we just preallocate
on create.
François.
From b0602bc2b02dcd7b15f0f9a143f850defd767509 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?=
Date: Sun, 28 Nov 2010 20:01:03 +0100
Subject: [PATCH] Add basic read, write and create support for AMD SimNow HDD
images.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: François Revol
---
Makefile.objs |2 +-
block/hdd.c | 354 +
2 files changed, 355 insertions(+), 1 deletions(-)
create mode 100644 block/hdd.c
diff --git a/Makefile.objs b/Makefile.objs
index 23b17ce..20e346d 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -20,7 +20,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o
vvfat.o
block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
-block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
+block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o hdd.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
block-nested-$(CONFIG_POSIX) += raw-posix.o
block-nested-$(CONFIG_CURL) += curl.o
diff --git a/block/hdd.c b/block/hdd.c
new file mode 100644
index 000..aed609e
--- /dev/null
+++ b/block/hdd.c
@@ -0,0 +1,354 @@
+/*
+ * Block driver for the AMD SimNow HDD disk image
+ *
+ * Copyright (c) 2010 François Revol
+ *
+ * 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.
+ *
+ * Reference:
+ * http://developer.amd.com/Assets/SimNowUsersManual4.6.2.pdf page 181
+ *
+ * "the hard-disk image file contains a 512-byte header before the raw data.
+ * This 512-byte header is identical to the information provided by the drive
+ * in response to the ATA command "IDENTIFY". Following the 512-byte header
+ * is the data for each sector from the device."
+ */
+
+#include "qemu-common.h"
+#include "block_int.h"
+#include "module.h"
+
+/* Command line option for static images. */
+#define BLOCK_OPT_STATIC "static"
+
+#define SECTOR_SIZE 512
+#define DATA_START 1
+#define MAX_MULT_SECTORS 1
+
+typedef struct BDRVHddState {
+uint8_t identify_data[SECTOR_SIZE];
+} BDRVHddState;
+
+
+static void padstr(char *str, const char *src, int len)
+{
+int i, v;
+for(i = 0; i < len; i++) {
+if (*src)
+v = *src++;
+else
+v = ' ';
+str[i^1] = v;
+}
+}
+
+static void put_le16(uint16_t *p, unsigned int v)
+{
+*p = cpu_to_le16(v);
+}
+
+static int isvalid_ide_chr(char c)
+{
+/* XXX: other chars also maybe? */
+return (isalnum(c) || c == ' ' || c == '.');
+}
+
+static int hdd_probe(const uint8_t *buf, int buf_size, const char *filename)
+{
+int name_len;
+uint16_t *p = (uint16_t *)buf;
+int64_t nb_sectors;
+uint32_t nb_sectors_clipped;
+int result = 0;
+int i;
+
+if (buf_size < SECTOR_SIZE) {
+/* Header too small, no VDI. */
+return 0;
+}
+
+/* best effort sanity check */
+/* TODO: check more (CHS size...) */
+
+/* serial number */
+for (i = 10 * 2; i < 10 * 2 + 20; i++) {
+if (!isvalid_ide_chr(buf[i])) {
+return 0;
+}
+}
+result += 20;
+
+/* firmware version */
+for (i = 23 * 2; i < 23 * 2 + 8; i++) {
+if (!isvalid_ide_chr(buf[i])) {
+return 0;
+}
+}
+result += 8;
+
+/* model */
+for (i = 27 * 2; i < 27 * 2 + 40; i++) {
+if (!isvalid_ide_chr(buf[i])) {
+return 0;
+}
+}
+result += 40;
+
+nb_sectors = le16_to_cpu(p[100]);
+nb_sectors |= (uint64_t)le16_to_cpu(p[101]) << 16;
+nb_sectors |= (uint64_t)le16_to_cpu(p[102]) << 32;
[Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
Gleb Natapov wrote: > There is no way for qemu to know about BCVs or BEVs This is very much the key point. In order to have command line control over the boot process, the machine and the firmware must agree on things. I see two options: 1. QEMU works very very hard to provide a machine that will result in a particular BBS program flow in firmware, in the end resulting in the desired device being used for booting - as long as QEMU and the firmware happen to have the same understanding of the BBS. 2. QEMU passes boot instructions to the firmware based on immediate, common, structured data. The first option seems disgusting to me, because it has many drawbacks and no benefits. The second option requires inventing something that goes beyond the established BIOS standards, maybe a reason for it to see fierce resistance, but it is the only thing that makes sense. Specifying boot device using PCI BDF is a great example of using common structured data. That BDF exists both in machine and firmware data models. The scope of BBS is limited to the firmware, so it is not really practical for creating consistency in a dynamic machine. //Peter
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote: > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote: > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > > > >>Anthony, Blue > > > > > >> > > > > > >>No comments on this patch series for almost a week. Can it be > > > > > >>applied? > > > > > > > > > > > >Does that mean everyone's happy or have folks not gotten around to > > > > > >review it? > > > > > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > > > > it right. > > > > > > > > > > But I notice the there is no documentation - surely some is needed? > > > > > > > > > > > > > The patch creates Openfirmware device path from qdev > > > > hierarchy. Each element of a device path depends on type of a bus > > > > the device resides on. You can find various bus bindings here: > > > > http://playground.sun.com/1275/bindings/ and main spec is here > > > > > > sun.com links have a tendency to disappear nowdays :) > > > Is this the official location? Aren't bindings part of some standard? > > I think this is official location. > > > > > > It also worries me that PCI Express bindings are in a 'proposal' form > > > from August 2004. The PCI bindings are from 1994. They are likely to miss > > > some recent technology advancements :) > > > > > > > > > Further, while this last document which is only 28 page in length, is > > > not readable by itself: one must first digest the openfirmware spec. > > > However ... > > > > > > > http://forthworks.com/standards/of1275.pdf. > > > > > > That's 266 pages of a specification. I am guessing that most of it is > > > irrelevant for the task in question? Can we have a small text document > > > including just the path format, please? > > > > > So basically you are complaining that reading specs is difficult. It is. > > That's > > life. > > Well, the specific format used is undocumented. Patch borrowed bits from > various specs, but it's undocumented which bits, and from which specs. > See above for documentation. Download everything. Read. > I do realize you had to go over all of these specs and do the difficult work > to come up with the format, but please write documentation > for the rest of us. > Pleas read spec. You can even find that I interpreted spec incorrectly and point where the bug is. That is the reason spec exists. I do not ask you to provide me with documentation for each and every thing you do in pci layer although it will be much simpler to read your executive summery then go and read complicated spec. The same hold true for any other piece of code that implement spec. -- Gleb.
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote: > On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote: > > On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote: > > > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote: > > > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can > > > > natively boot from has optionrom. What Seabios will do in such situation > > > > and how qemu can know it? Besides qemu support tries to be firmware > > > > agnostic. > > > > > > In such a situation, under my proposal, users wouldn't be able to > > > specify a default boot from their scsi drive until after qemu was also > > > upgraded to know seabios could boot native scsi. (Or, they'd only be > > > able to do it by adding in a command-line option.) > > > > > If scsi card has optionrom with only one bcv then Seabios can determine > > its boot order from device path, so why not provide user with this > > option today? > > It's unclear to me how SeaBIOS is supposed to do that. > Suppose we have "/p...@i0cf8/s...@3/d...@0,0" with boot index 5 in boot devices list and suppose pci device in slot 3 function 0 has optionrom. When Seabios load the option rom from device to memory it looks for string that matches "/p...@i0cf8/@3.*" if the string is found option rom gets boot index from it. In our case "/p...@i0cf8/s...@3/d...@0,0" will match and optionrom will get boot index 5. In practice Seabios will know that device is SCSI by reading device class so it will be able to construct string "/p...@i0cf8/s...@3" and use simple strstr to find matching device path. > >Besides qemu may be used to emulates sparc with openbios and > > this combination may be able to boot from scsi device. Qemu is not just > > x86 emulator running Seabios. If there is problem with scsi boot we let > > management know, so it will not create unbootable configuration. Today it > > is impossible to boot guest from scsi in qemu btw. > > Qemu can send in "/p...@i0cf8/s...@3/d...@0,0" - it's just unclear what > seabios is supposed to do with it. (If "ignore it" is the answer, > that's fine with me.) > See above. But for some device paths "ignore it" is acceptable answer (is Seabios can't boot from it and device doesn't have optionrom). > > > If qemu sends in "/p...@i0cf8/s...@3/d...@0,0" or > > > "/p...@i0cf8/ether...@4/ethernet-...@0" it will expect seabios to boot > > > from the appropriate device. In both cases, seabios would need to run > > > a rom in order to fulfill that request. Trying to figure out which > > > rom is quite painful. That's why I'd prefer to see qemu instead pass > > > in something like "/p...@i0cf8/r...@3/b...@0" or "/p...@i0cf8/r...@4/bev". > > > That is, if the machine needs to boot via a rom I'd prefer qemu state > > > that explicitly. > > It is painful in Seabios it is impossible in qemu at all. There is no > > way for qemu to know about BCVs or BEVs in optionroms especially > > considering that they are created at runtime like you say bellow. > > It's not impossible - qemu could code up rules for when to request a > rom boot and when to request a native boot. That may seem ugly, but > (as near as I can tell) it's basically what you've asked seabios to > do. If nothing else, qemu has the option to let the user pass in an > explicit request via the command-line. I still do not see why such rule is needed. Why information this patch set provides is not enough? > > > > BTW, in the situation where seabios has native device support (eg, > > > ATA), I don't have any concerns. (The names are a bit verbose, but > > > that's not really an issue.) > > This + network booting are the may use case really. And I do not see > > what problem we have with BEV devices. "/p...@i0cf8/r...@4/bev" is not > > much different from "/p...@i0cf8/ether...@4/ethernet-...@0" since there > > can be only one bev per pci device. It is easy for Seabios to see that > > to boot from pci device in slot 4 func 0 it has to execute BEV. > > I'm still stuck on how seabios is supposed to know it's an ethernet > card. Sure, seabios could hardcode translations from classid to > strings, but that seems fragile. What happens when the user wants to > boot from myranet, or fiberchannel, or whatnot? This is not fragile since class to name translation is defined by the spec. But even that is not required if Seabios will be a little bit smarter and will implement fuzzy matching. i.e do not match "/p...@i0cf8/ether...@4/ethernet-...@0" exactly but match "/p...@i0cf8/@4.*" instead. > > Maybe we can compromise here - if the user selects booting from a > device, and qemu sees there is a rom for that device, then qemu can > specify two boot options: > > /p...@i0cf8/ether...@4/ethernet-...@0 > /p...@i0cf8/r...@4 > This patch series implement device paths as defined by Openfirmware spec. /p...@i0cf8/r...@4 sould be out of spec. But I do not see why Seabios can't build later from the former. Also
Re: [Qemu-devel] [Bug 668799] Re: qemu-arm segfaults executing msgmerge (gettext)
On 11/28/2010 11:37 AM, Brian Harring wrote: > Additional note... it *looks* like the deadlock potential is there > already in 0.13, it's just heavily exacerbated by this patch- out of > about 600 builds I've seen 2 lockup in the same fashion (rate was far > higher with the patch on this ticket). > > Maybe I am a bit late, I had now also run my testsuites for OBS on this particular patch. I can confirm that it forces the deadlock *now to a reproducable state*. I had used a current git master from Fri as the base to cross check the "its already on 0.13" claim. Martin Martin Mohring OBS Maintainer
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote: > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > > >>Anthony, Blue > > > > >> > > > > >>No comments on this patch series for almost a week. Can it be applied? > > > > > > > > > >Does that mean everyone's happy or have folks not gotten around to > > > > >review it? > > > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > > > it right. > > > > > > > > But I notice the there is no documentation - surely some is needed? > > > > > > > > > > The patch creates Openfirmware device path from qdev > > > hierarchy. Each element of a device path depends on type of a bus > > > the device resides on. You can find various bus bindings here: > > > http://playground.sun.com/1275/bindings/ and main spec is here > > > > sun.com links have a tendency to disappear nowdays :) > > Is this the official location? Aren't bindings part of some standard? > I think this is official location. > > > > It also worries me that PCI Express bindings are in a 'proposal' form > > from August 2004. The PCI bindings are from 1994. They are likely to miss > > some recent technology advancements :) > > > > > > Further, while this last document which is only 28 page in length, is > > not readable by itself: one must first digest the openfirmware spec. > > However ... > > > > > http://forthworks.com/standards/of1275.pdf. > > > > That's 266 pages of a specification. I am guessing that most of it is > > irrelevant for the task in question? Can we have a small text document > > including just the path format, please? > > > So basically you are complaining that reading specs is difficult. It is. > That's > life. Well, the specific format used is undocumented. Patch borrowed bits from various specs, but it's undocumented which bits, and from which specs. I do realize you had to go over all of these specs and do the difficult work to come up with the format, but please write documentation for the rest of us. > -- > Gleb.
[Qemu-devel] [Bug 501177] Re: qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts
Works with 0.13.0 (Debian 0.13.0+dfsg-2). Probably 63a54736f31f9e11da6fb52319bba26e7d24f571 was the fix ** Changed in: qemu Status: New => Fix Released -- qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts https://bugs.launchpad.net/bugs/501177 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Released Bug description: I tried to boot a kernel with enabled kgdb and kgdb self checks with qemu emulating i386. It works with amd64, but crashes with i386. Tests were done with 19e65b47f60c68d7e8c96aa0a36223c5a0d3422b and qemu 0.11.1-1 on Debian sid. Backtrace of i386-softmmu/qemu (19e65b47f60c68d7e8c96aa0a36223c5a0d3422b) [ 15.398435] kgdbts:RUN singlestep [900/1000] [ 15.683097] kgdbts:RUN hw breakpoint test Program received signal SIGSEGV, Segmentation fault. raise_interrupt (intno=1, is_int=0, error_code=0, next_eip_addend=0) at /home/sven/tmp/qemu/target-i386/op_helper.c:1335 1335env->exception_index = intno; (gdb) bt #0 raise_interrupt (intno=1, is_int=0, error_code=0, next_eip_addend=0) at /home/sven/tmp/qemu/target-i386/op_helper.c:1335 #1 0x08182347 in raise_exception (exception_index=1) at /home/sven/tmp/qemu/target-i386/op_helper.c:1351 #2 0x08191e9a in breakpoint_handler (env=0x8467fa8) at /home/sven/tmp/qemu/target-i386/helper.c:1530 #3 0x08125e84 in cpu_handle_debug_exception (env1=0x8467fa8) at /home/sven/tmp/qemu/cpu-exec.c:209 #4 cpu_x86_exec (env1=0x8467fa8) at /home/sven/tmp/qemu/cpu-exec.c:274 #5 0x08052680 in qemu_cpu_exec (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4021 #6 tcg_cpu_exec (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4052 #7 main_loop (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4167 #8 main (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:6124 It was run with `/home/sven/tmp/qemu/i386-softmmu/qemu -m 1024 -kernel linux-2.6.32.qemu -drive file=root.cow3,if=virtio -net nic,macaddr=02:ca:ff:ee:ba:43,model=virtio,vlan=3 -net tap,ifname=tap3,vlan=3,script=no -nographic`
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote: > > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote: > > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can > > > natively boot from has optionrom. What Seabios will do in such situation > > > and how qemu can know it? Besides qemu support tries to be firmware > > > agnostic. > > > > In such a situation, under my proposal, users wouldn't be able to > > specify a default boot from their scsi drive until after qemu was also > > upgraded to know seabios could boot native scsi. (Or, they'd only be > > able to do it by adding in a command-line option.) > > > If scsi card has optionrom with only one bcv then Seabios can determine > its boot order from device path, so why not provide user with this > option today? It's unclear to me how SeaBIOS is supposed to do that. >Besides qemu may be used to emulates sparc with openbios and > this combination may be able to boot from scsi device. Qemu is not just > x86 emulator running Seabios. If there is problem with scsi boot we let > management know, so it will not create unbootable configuration. Today it > is impossible to boot guest from scsi in qemu btw. Qemu can send in "/p...@i0cf8/s...@3/d...@0,0" - it's just unclear what seabios is supposed to do with it. (If "ignore it" is the answer, that's fine with me.) > > If qemu sends in "/p...@i0cf8/s...@3/d...@0,0" or > > "/p...@i0cf8/ether...@4/ethernet-...@0" it will expect seabios to boot > > from the appropriate device. In both cases, seabios would need to run > > a rom in order to fulfill that request. Trying to figure out which > > rom is quite painful. That's why I'd prefer to see qemu instead pass > > in something like "/p...@i0cf8/r...@3/b...@0" or "/p...@i0cf8/r...@4/bev". > > That is, if the machine needs to boot via a rom I'd prefer qemu state > > that explicitly. > It is painful in Seabios it is impossible in qemu at all. There is no > way for qemu to know about BCVs or BEVs in optionroms especially > considering that they are created at runtime like you say bellow. It's not impossible - qemu could code up rules for when to request a rom boot and when to request a native boot. That may seem ugly, but (as near as I can tell) it's basically what you've asked seabios to do. If nothing else, qemu has the option to let the user pass in an explicit request via the command-line. > > BTW, in the situation where seabios has native device support (eg, > > ATA), I don't have any concerns. (The names are a bit verbose, but > > that's not really an issue.) > This + network booting are the may use case really. And I do not see > what problem we have with BEV devices. "/p...@i0cf8/r...@4/bev" is not > much different from "/p...@i0cf8/ether...@4/ethernet-...@0" since there > can be only one bev per pci device. It is easy for Seabios to see that > to boot from pci device in slot 4 func 0 it has to execute BEV. I'm still stuck on how seabios is supposed to know it's an ethernet card. Sure, seabios could hardcode translations from classid to strings, but that seems fragile. What happens when the user wants to boot from myranet, or fiberchannel, or whatnot? Maybe we can compromise here - if the user selects booting from a device, and qemu sees there is a rom for that device, then qemu can specify two boot options: /p...@i0cf8/ether...@4/ethernet-...@0 /p...@i0cf8/r...@4 SeaBIOS will ignore the first entry, and act on the second entry. If at some later point seabios knows how to natively boot from the device (eg, scsi), then it will use the first entry and ignore the second. BTW, how are PCI locations specified in these paths? They should have a (bus, dev, fn) - your examples only seem to show dev. How are the other parts specified? -Kevin
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 01:22:42PM +, Blue Swirl wrote: > On Sun, Nov 28, 2010 at 1:19 PM, Gleb Natapov wrote: > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > >> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > >> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > >> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > >> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > >> > > >>Anthony, Blue > >> > > >> > >> > > >>No comments on this patch series for almost a week. Can it be > >> > > >>applied? > >> > > > > >> > > >Does that mean everyone's happy or have folks not gotten around to > >> > > >review it? > >> > > > > >> > > >IOW, last call if you have objections :-) > >> > > > > >> > > > >> > > I haven't reviewed this - I trust the author and maintainers to get > >> > > it right. > >> > > > >> > > But I notice the there is no documentation - surely some is needed? > >> > > > >> > > >> > The patch creates Openfirmware device path from qdev > >> > hierarchy. Each element of a device path depends on type of a bus > >> > the device resides on. You can find various bus bindings here: > >> > http://playground.sun.com/1275/bindings/ and main spec is here > >> > >> sun.com links have a tendency to disappear nowdays :) > >> Is this the official location? Aren't bindings part of some standard? > > I think this is official location. > > I'd suppose some of them are IEEE standards, available for a fee. I don't think so: The IEEE-1275 Open Firmware standard was not reaffirmed by the OFWG and has been officially withdrawn by IEEE. Unfortunately, this means it is unavailable from the IEEE. -- MST
[Qemu-devel] Re: [Bug 501177] Re: qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts
Am 28.11.2010 13:48, Sven Eckelmann wrote: > My fault. it is still their... did my test wrong > > ** Changed in: qemu >Status: Fix Released => New > Fixed in stable-0.13 and master by 63a54736f31f9e11da6fb52319bba26e7d24f571. I guess stable-0.12 is now pure distro business. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH] xen: Restrict build to x86 targets
From: Jan Kiszka Xen target bits in qemu are intended for x86. Let the build system reflect this and avoid useless building/linking for other targets. Signed-off-by: Jan Kiszka --- Makefile.objs |4 ++-- Makefile.target |4 ++-- configure |4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 13ba26f..eabb032 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -148,8 +148,8 @@ slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y)) # xen backend driver support -common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o -common-obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o +common-obj-$(CONFIG_XEN_HOST) += xen_backend.o xen_devconfig.o +common-obj-$(CONFIG_XEN_HOST) += xen_console.o xenfb.o xen_disk.o xen_nic.o ## # libuser diff --git a/Makefile.target b/Makefile.target index 5784844..0863d5c 100644 --- a/Makefile.target +++ b/Makefile.target @@ -203,8 +203,8 @@ QEMU_CFLAGS += $(VNC_SASL_CFLAGS) QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) -# xen backend driver support -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o +# xen target support +obj-$(CONFIG_XEN_TARGET) += xen_machine_pv.o xen_domainbuild.o # USB layer obj-$(CONFIG_USB_OHCI) += usb-ohci.o diff --git a/configure b/configure index 2917874..3dd252a 100755 --- a/configure +++ b/configure @@ -2565,7 +2565,7 @@ if test "$bluez" = "yes" ; then echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak fi if test "$xen" = "yes" ; then - echo "CONFIG_XEN=y" >> $config_host_mak + echo "CONFIG_XEN_HOST=y" >> $config_host_mak fi if test "$io_thread" = "yes" ; then echo "CONFIG_IOTHREAD=y" >> $config_host_mak @@ -2903,7 +2903,7 @@ echo "TARGET_ABI_DIR=$TARGET_ABI_DIR" >> $config_target_mak case "$target_arch2" in i386|x86_64) if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then - echo "CONFIG_XEN=y" >> $config_target_mak + echo "CONFIG_XEN_TARGET=y" >> $config_target_mak fi esac case "$target_arch2" in -- 1.7.1
[Qemu-devel] [PATCH 5/6] ccid: add ccid-card-emulated device (v2)
changes from v1:
remove stale comments, use only c-style comments
bugfix, forgot to set recv_len
change reader name to 'Virtual Reader'
Signed-off-by: Alon Levy
---
Makefile.objs |2 +-
hw/ccid-card-emulated.c | 501 +++
2 files changed, 502 insertions(+), 1 deletions(-)
create mode 100644 hw/ccid-card-emulated.c
diff --git a/Makefile.objs b/Makefile.objs
index 82691c0..a494ee0 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -183,7 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
ccid-card-emulated.o
# PPC devices
hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/hw/ccid-card-emulated.c b/hw/ccid-card-emulated.c
new file mode 100644
index 000..b85df31
--- /dev/null
+++ b/hw/ccid-card-emulated.c
@@ -0,0 +1,501 @@
+/*
+ * CCID Card Device. Emulated card.
+ *
+ * It can be used to provide access to the local hardware in a non exclusive
+ * way, or it can use certificates. It requires the usb-ccid bus.
+ *
+ * Usage 1: standard, mirror hardware reader+card:
+ * qemu .. -usb -device usb-ccid -device ccid-card-emulated
+ *
+ * Usage 2: use certificates, no hardware required
+ * one time: create the certificates:
+ * for i in 1 2 3; do certutil -d /etc/pki/nssdb -x -t "CT,CT,CT" -S -s
"CN=user$i" -n user$i; done
+ * qemu .. -usb -device usb-ccid -device
ccid-card-emulated,cert1=user1,cert2=user2,cert3=user3
+ *
+ * If you use a non default db for the certificates you can specify it using
the db parameter.
+ *
+ *
+ * Copyright (c) 2010 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the LGPL.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "qemu-char.h"
+#include "monitor.h"
+#include "hw/ccid.h"
+
+#define DPRINTF(card, lvl, fmt, ...) \
+do { if (lvl <= card->debug) { printf("ccid-card-emul: %s: " fmt , __func__,
## __VA_ARGS__); } } while (0)
+
+#define EMULATED_DEV_NAME "ccid-card-emulated"
+
+#define BACKEND_NSS_EMULATED "nss-emulated" /* the default */
+#define BACKEND_CERTIFICATES "certificates"
+
+typedef struct EmulatedState EmulatedState;
+
+enum {
+EMUL_READER_INSERT = 0,
+EMUL_READER_REMOVE,
+EMUL_CARD_INSERT,
+EMUL_CARD_REMOVE,
+EMUL_GUEST_APDU,
+EMUL_RESPONSE_APDU,
+EMUL_ERROR,
+};
+
+static const char* emul_event_to_string(uint32_t emul_event)
+{
+switch (emul_event) {
+case EMUL_READER_INSERT: return "EMUL_READER_INSERT";
+case EMUL_READER_REMOVE: return "EMUL_READER_REMOVE";
+case EMUL_CARD_INSERT: return "EMUL_CARD_INSERT";
+case EMUL_CARD_REMOVE: return "EMUL_CARD_REMOVE";
+case EMUL_GUEST_APDU: return "EMUL_GUEST_APDU";
+case EMUL_RESPONSE_APDU: return "EMUL_RESPONSE_APDU";
+case EMUL_ERROR: return "EMUL_ERROR";
+default:
+break;
+}
+return "UNKNOWN";
+}
+
+typedef struct EmulEvent {
+QSIMPLEQ_ENTRY(EmulEvent) entry;
+union {
+struct {
+uint32_t type;
+} gen;
+struct {
+uint32_t type;
+uint64_t code;
+} error;
+struct {
+uint32_t type;
+uint32_t len;
+uint8_t data[];
+} data;
+} p;
+} EmulEvent;
+
+#define MAX_ATR_SIZE 40
+struct EmulatedState {
+CCIDCardState base;
+uint8_t debug;
+char*backend;
+char*cert1;
+char*cert2;
+char*cert3;
+char*db;
+uint8_t atr[MAX_ATR_SIZE];
+uint8_t atr_length;
+QSIMPLEQ_HEAD(event_list, EmulEvent) event_list;
+pthread_mutex_t event_list_mutex;
+VReader *reader;
+QSIMPLEQ_HEAD(guest_apdu_list, EmulEvent) guest_apdu_list;
+pthread_mutex_t vreader_mutex; /* and guest_apdu_list mutex */
+pthread_mutex_t handle_apdu_mutex;
+pthread_cond_t handle_apdu_cond;
+int pipe[2];
+int quit_apdu_thread;
+pthread_mutex_t apdu_thread_quit_mutex;
+pthread_cond_t apdu_thread_quit_cond;
+};
+
+static void emulated_apdu_from_guest(CCIDCardState *base, const uint8_t *apdu,
uint32_t len)
+{
+EmulatedState *card = DO_UPCAST(EmulatedState, base, base);
+EmulEvent *event = (EmulEvent*)malloc(sizeof(EmulEvent) + len);
+
+assert(event);
+event->p.data.type = EMUL_GUEST_APDU;
+event->p.data.len = len;
+memcpy(event->p.data.data, apdu, len);
+pthread_mutex_lock(&card->vreader_mutex);
+QSIMPLEQ_INSERT_TAIL(&card->guest_apdu_list, event, entry);
+pthread_mutex_unlock(&card->vreader_mutex);
+pthread_cond_signal(&card->handle_apdu_cond);
+}
+
+static const uint8_t* emulated_get_atr(CCIDCardState *base, uint32_t *len)
+{
+EmulatedState *card = DO_UPCAST(EmulatedState, base, base);
+
+*len = card->atr_length;
+return card-
[Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard
Signed-off-by: Alon Levy --- Makefile|6 -- Makefile.objs |5 + Makefile.target |2 ++ configure | 24 libcaccard/Makefile | 18 ++ 5 files changed, 53 insertions(+), 2 deletions(-) create mode 100644 libcaccard/Makefile diff --git a/Makefile b/Makefile index 4e120a2..e673bf1 100644 --- a/Makefile +++ b/Makefile @@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o $(CHECK_PROG_DEPS) check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o $(CHECK_PROG_DEPS) +QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard + clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h @@ -183,7 +185,7 @@ clean: rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp rm -f trace-dtrace.h trace-dtrace.h-timestamp $(MAKE) -C tests clean - for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis libdis-user; do \ + for d in $(ALL_SUBDIRS) $(QEMULIBS); do \ if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ rm -f $$d/qemu-options.def; \ done @@ -194,7 +196,7 @@ distclean: clean rm -f roms/seabios/config.mak roms/vgabios/config.mak rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf qemu-doc.pg qemu-doc.toc qemu-doc.tp qemu-doc.vr rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr - for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis libdis-user; do \ + for d in $(TARGET_DIRS) $(QEMULIBS); do \ rm -rf $$d || exit 1 ; \ done diff --git a/Makefile.objs b/Makefile.objs index 2059e89..82691c0 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o endif endif +## +# smartcard + +libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o vcard_emul_nss.o vcard_emul_type.o card_7816.o + vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) diff --git a/Makefile.target b/Makefile.target index 2800f47..7dd6932 100644 --- a/Makefile.target +++ b/Makefile.target @@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) endif # CONFIG_SOFTMMU +obj-y += $(addprefix $(SRC_PATH)/libcaccard/, $(libcaccard-$(CONFIG_SMARTCARD))) + obj-y += $(addprefix ../, $(trace-obj-y)) obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o diff --git a/configure b/configure index fb9eac2..4b55904 100755 --- a/configure +++ b/configure @@ -2130,6 +2130,25 @@ EOF fi fi +# check for libcaccard for smartcard support +if test "$smartcard" != "no" ; then + smartcard_cflags="-I\$(SRC_PATH)/libcaccard" + smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard" + libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null) + libcaccard_cflags=$($pkgconfig --cflags nss) + # TODO - what's the minimal nss version we support? + if $pkgconfig --atleast-version=3.12.8 nss; then +smartcard="yes" +QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags" +LIBS="$libcaccard_libs $LIBS" + else +if test "smartcard" = "yes" ; then + feature_not_found "smartcard" +fi +smartcard="no" + fi +fi + ## ## @@ -2956,6 +2975,11 @@ fi if test "$target_darwin_user" = "yes" ; then echo "CONFIG_DARWIN_USER=y" >> $config_target_mak fi +if test "$smartcard" = "yes" ; then + echo "subdir-$target: subdir-libcaccard" >> $config_host_mak + echo "libcaccard_libs=$libcaccard_libs" >> $config_host_mak + echo "libcaccard_cflags=$libcaccard_cflags" >> $config_host_mak +fi list="" if test ! -z "$gdb_xml_files" ; then for x in $gdb_xml_files; do diff --git a/libcaccard/Makefile b/libcaccard/Makefile new file mode 100644 index 000..a339af1 --- /dev/null +++ b/libcaccard/Makefile @@ -0,0 +1,18 @@ +include ../Makefile.objs +include ../config-host.mak +include ../config-all-devices.mak +include $(SRC_PATH)/rules.mak + +CFLAGS+=-fPIC + +libcaccard.so: $(libcaccard-y) + gcc -shared $(libcaccard_libs) -o $@ $^ + +vscclient: $(libcaccard-y) vscclient.o + gcc $(libcaccard_libs) -o $@ $^ + +all: libcaccard.so vscclient + +clean: + rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ libcaccard.so + -- 1.7.3.2
[Qemu-devel] [PATCH 6/6] ccid: add docs
Signed-off-by: Alon Levy --- docs/ccid.txt | 125 + docs/libcaccard.txt | 482 +++ 2 files changed, 607 insertions(+), 0 deletions(-) create mode 100644 docs/ccid.txt create mode 100644 docs/libcaccard.txt diff --git a/docs/ccid.txt b/docs/ccid.txt new file mode 100644 index 000..3af4f92 --- /dev/null +++ b/docs/ccid.txt @@ -0,0 +1,125 @@ +Qemu CCID Device Documentation. + +Contents +1. USB CCID device +2. Building +3. Using ccid-card-emulated with hardware +4. Using ccid-card-emulated with certificates +5. Using ccid-card-passthru with client side hardware +6. Using ccid-card-passthru with client side certificates +7. Passthrough protocol scenario +8. libcaccard + +1. USB CCID device + +The USB CCID device is a USB device implementing the CCID specification, which +lets one connect smart card readers that implement the same spec. For more +information see the specification: + + Universal Serial Bus + Device Class: Smart Card + CCID + Specification for + Integrated Circuit(s) Cards Interface Devices + Revision 1.1 + April 22rd, 2005 + +Smartcard are used for authentication, single sign on, decryption in +public/private schemes and digital signatures. A smartcard reader on the client +cannot be used on a guest with simple usb passthrough since it will then not be +available on the client, possibly locking the computer when it is "removed". On +the other hand this device can let you use the smartcard on both the client and +the guest machine. It is also possible to have a completely virtual smart card +reader and smart card (i.e. not backed by a physical device) using this device. + +2. Building + +The cryptographic functions and access to the physical card is done via NSS. + +Installing NSS: + +In redhat/fedora: +yum install nss-devel +In ubuntu/debian: +apt-get install libnss3-dev +(not tested on ubuntu) + +Configuring and building: +./configure --enable-smartcard && make + +3. Using ccid-card-emulated with hardware + +Assuming you have a working smartcard on the host with the current +user, using NSS, qemu acts as another NSS client using ccid-card-emulated: + +qemu -usb -device usb-ccid -device ccid-card-emualated + +4. Using ccid-card-emulated with certificates + +You must create the certificates. This is a one time process. We use NSS +certificates: + +certutil -d /etc/pki/nssdb -x -t "CT,CT,CT" -S -s "CN=cert1" -n cert1 + +Note: you must have exactly three certificates. + +Assuming the current user can access the certificates (use certutil -L to +verify), you can use the emulated card type with the certificates backend: + +qemu -usb -device usb-ccid -device ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3 + +5. Using ccid-card-passthru with client side hardware + +on the host specify the ccid-card-passthru device with a suitable chardev: + +qemu -chardev socket,server,host=0.0.0.0,port=2001,id=ccid,nowait -usb -device usb-ccid -device ccid-card-passthru,chardev=ccid + +on the client run vscclient, built when you built the libcaccard library: +libcaccard/vscclient 2001 + +6. Using ccid-card-passthru with client side certificates + +Run qemu as per #5, and run vscclient as follows: +(Note: vscclient command line interface is in a state of change) + +libcaccard/vscclient -e "db=\"/etc/pki/nssdb\" use_hw=no soft=(,Test,CAC,,cert1,cert2,cert3)" 2001 + +7. Passthrough protocol scenario + +This is a typical interchange of messages when using the passthru card device. +usb-ccid is a usb device. It defaults to an unattached usb device on startup. +usb-ccid expects a chardev and expects the protocol defined in +cac_card/vscard_common.h to be passed over that. + +A typical interchange is: + +client event | vscclient |passthru| usb-ccid | guest event +-- + | VSC_Init|| | + | VSC_ReaderAdd || attach| + | || | sees new usb device. +card inserted | || | + | VSC_ATR || | + | || | guest operation, APDU transfer via CCID + | | VSC_APDU | | + | VSC_APDU|| | +client<->physical | || | +card APDU exchange| || | +[APDU<->APDU repeats several times] +card removed | |
[Qemu-devel] [PATCH 1/6] usb-ccid: add CCID bus
A CCID device is a smart card reader. It is a USB device, defined at [1].
This patch introduces the usb-ccid device that is a ccid bus. Next patches will
introduce two card types to use it, a passthru card and an emulated card.
[1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.
Signed-off-by: Alon Levy
---
Makefile.objs |1 +
configure | 12 +
hw/ccid.h | 34 ++
hw/usb-ccid.c | 1345 +
4 files changed, 1392 insertions(+), 0 deletions(-)
create mode 100644 hw/ccid.h
create mode 100644 hw/usb-ccid.c
diff --git a/Makefile.objs b/Makefile.objs
index 23b17ce..713131f 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -183,6 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
hw-obj-$(CONFIG_DMA) += dma.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
# PPC devices
hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/configure b/configure
index 2917874..fb9eac2 100755
--- a/configure
+++ b/configure
@@ -332,6 +332,7 @@ zero_malloc=""
trace_backend="nop"
trace_file="trace"
spice=""
+smartcard="no"
# OS specific
if check_define __linux__ ; then
@@ -739,6 +740,10 @@ for opt do
;;
--enable-vhost-net) vhost_net="yes"
;;
+ --disable-smartcard) smartcard="no"
+ ;;
+ --enable-smartcard) smartcard="yes"
+ ;;
--*dir)
;;
*) echo "ERROR: unknown option $opt"; show_help="yes"
@@ -934,6 +939,8 @@ echo " --trace-file=NAMEFull PATH,NAME of file to
store traces"
echo " Default:trace-"
echo " --disable-spice disable spice"
echo " --enable-spice enable spice"
+echo " --disable-smartcard disable smartcard support"
+echo " --enable-smartcard enable smartcard support"
echo ""
echo "NOTE: The object files are built at the place where configure is
launched"
exit 1
@@ -2354,6 +2361,7 @@ echo "vhost-net support $vhost_net"
echo "Trace backend $trace_backend"
echo "Trace output file $trace_file-"
echo "spice support $spice"
+echo "smartcard support $smartcard"
if test $sdl_too_old = "yes"; then
echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -2617,6 +2625,10 @@ if test "$spice" = "yes" ; then
echo "CONFIG_SPICE=y" >> $config_host_mak
fi
+if test "$smartcard" = "yes" ; then
+ echo "CONFIG_SMARTCARD=y" >> $config_host_mak
+fi
+
# XXX: suppress that
if [ "$bsd" = "yes" ] ; then
echo "CONFIG_BSD=y" >> $config_host_mak
diff --git a/hw/ccid.h b/hw/ccid.h
new file mode 100644
index 000..a38f971
--- /dev/null
+++ b/hw/ccid.h
@@ -0,0 +1,34 @@
+#ifndef __CCID_H__
+#define __CCID_H__
+
+#include "qdev.h"
+
+typedef struct CCIDCardState CCIDCardState;
+typedef struct CCIDCardInfo CCIDCardInfo;
+
+struct CCIDCardState {
+DeviceState qdev;
+};
+
+struct CCIDCardInfo {
+DeviceInfo qdev;
+void (*print)(Monitor *mon, CCIDCardState *card, int indent);
+const uint8_t *(*get_atr)(CCIDCardState *card, uint32_t *len);
+void (*apdu_from_guest)(CCIDCardState *card, const uint8_t *apdu, uint32_t
len);
+int (*exitfn)(CCIDCardState *card);
+int (*initfn)(CCIDCardState *card);
+};
+
+void ccid_card_send_apdu_to_guest(CCIDCardState *card, uint8_t* apdu, uint32_t
len);
+void ccid_card_card_removed(CCIDCardState *card);
+void ccid_card_card_inserted(CCIDCardState *card);
+void ccid_card_card_error(CCIDCardState *card, uint64_t error);
+void ccid_card_qdev_register(CCIDCardInfo *card);
+
+/* support guest visible insertion/removal of ccid devices based on actual
+ * devices connected/removed. Called by card implementation (passthru, local)
*/
+int ccid_card_ccid_attach(CCIDCardState *card);
+void ccid_card_ccid_detach(CCIDCardState *card);
+
+#endif // __CCID_H__
+
diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
new file mode 100644
index 000..a0a32e8
--- /dev/null
+++ b/hw/usb-ccid.c
@@ -0,0 +1,1345 @@
+/*
+ * CCID Device emulation
+ *
+ * Based on usb-serial.c:
+ * Copyright (c) 2006 CodeSourcery.
+ * Copyright (c) 2008 Samuel Thibault
+ * Written by Paul Brook, reused for FTDI by Samuel Thibault,
+ * Reused for CCID by Alon Levy.
+ * Contributed to by Robert Relyea
+ * Copyright (c) 2010 Red Hat.
+ *
+ * This code is licenced under the LGPL.
+ */
+
+/* References:
+ *
+ * CCID Specification Revision 1.1 April 22nd 2005
+ * "Universal Serial Bus, Device Class: Smart Card"
+ * Specification for Integrated Circuit(s) Cards Interface Devices
+ *
+ * KNOWN BUGS
+ * 1. remove/insert can sometimes result in removed state instead of inserted.
+ * This is a result of the following:
+ * symptom: dmesg shows ERMOTEIO (-121), pcscd shows -99. This happens
+ * when we send a too short packet, seen in uhci-usb.c, resulting from
+ * a urb requesting SPD and us returning a smaller packet.
+ * Not sure which messages trigger this.
+ *
+ */
+
+#include "qemu-common.h"
+#include "qemu-error.h"
+#include "usb.h"
[Qemu-devel] [PATCH 2/6] ccid: add passthru card device
Signed-off-by: Alon Levy
---
Makefile.objs |2 +-
hw/ccid-card-passthru.c| 277
libcaccard/vscard_common.h | 130 +
3 files changed, 408 insertions(+), 1 deletions(-)
create mode 100644 hw/ccid-card-passthru.c
create mode 100644 libcaccard/vscard_common.h
diff --git a/Makefile.objs b/Makefile.objs
index 713131f..2059e89 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -183,7 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
# PPC devices
hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/hw/ccid-card-passthru.c b/hw/ccid-card-passthru.c
new file mode 100644
index 000..d4c6ab3
--- /dev/null
+++ b/hw/ccid-card-passthru.c
@@ -0,0 +1,277 @@
+/*
+ * CCID Card Device emulation
+ *
+ * Copyright (c) 2010 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the LGPL.
+ */
+
+#include "qemu-char.h"
+#include "monitor.h"
+#include "hw/ccid.h"
+#include "libcaccard/vscard_common.h"
+
+#define DPRINTF(card, lvl, fmt, ...) \
+do { if (lvl <= card->debug) { printf("ccid-card: " fmt , ## __VA_ARGS__); } }
while (0)
+
+/* Passthru card */
+
+
+// TODO: do we still need this?
+uint8_t DEFAULT_ATR[] = {
+/* From some example somewhere
+ 0x3B, 0xB0, 0x18, 0x00, 0xD1, 0x81, 0x05, 0xB1, 0x40, 0x38, 0x1F, 0x03, 0x28
+ */
+
+/* From an Athena smart card */
+ 0x3B, 0xD5, 0x18, 0xFF, 0x80, 0x91, 0xFE, 0x1F, 0xC3, 0x80, 0x73, 0xC8, 0x21,
0x13, 0x08
+
+}; /* maximum size of ATR - from 7816-3 */
+
+
+#define PASSTHRU_DEV_NAME "ccid-card-passthru"
+#define VSCARD_IN_SIZE 65536
+#define MAX_ATR_SIZE40
+
+typedef struct PassthruState PassthruState;
+
+struct PassthruState {
+CCIDCardState base;
+CharDriverState *cs;
+uint8_t vscard_in_data[VSCARD_IN_SIZE];
+uint32_t vscard_in_pos;
+uint32_t vscard_in_hdr;
+uint8_t atr[MAX_ATR_SIZE];
+uint8_t atr_length;
+uint8_t debug;
+};
+
+/* VSCard protocol over chardev
+ * This code should not depend on the card type.
+ * */
+
+static void ccid_card_vscard_send_msg(
+PassthruState *s, VSCMsgType type, reader_id_t reader_id,
+const uint8_t* payload, uint32_t length)
+{
+VSCMsgHeader scr_msg_header;
+
+scr_msg_header.type = type;
+scr_msg_header.reader_id = reader_id;
+scr_msg_header.length = length;
+qemu_chr_write(s->cs, (uint8_t*)&scr_msg_header, sizeof(VSCMsgHeader));
+qemu_chr_write(s->cs, payload, length);
+}
+
+static void ccid_card_vscard_send_apdu(
+PassthruState *s, const uint8_t* apdu, uint32_t length)
+{
+ccid_card_vscard_send_msg(s, VSC_APDU, VSCARD_MINIMAL_READER_ID, apdu,
length);
+}
+
+static void ccid_card_vscard_send_error(
+PassthruState *s, reader_id_t reader_id, VSCErrorCode code)
+{
+VSCMsgError msg = {.code=code};
+
+ccid_card_vscard_send_msg(s, VSC_Error, reader_id, (uint8_t*)&msg,
sizeof(msg));
+}
+
+static void ccid_card_vscard_send_init(PassthruState *s)
+{
+VSCMsgInit msg = {.version=VSCARD_VERSION};
+
+ccid_card_vscard_send_msg(s, VSC_Init, VSCARD_UNDEFINED_READER_ID,
+ (uint8_t*)&msg, sizeof(msg));
+}
+
+static int ccid_card_vscard_can_read(void *opaque)
+{
+return 65535;
+}
+
+static void ccid_card_vscard_handle_message(PassthruState *card,
+VSCMsgHeader* scr_msg_header)
+{
+uint8_t *data = (uint8_t*)&scr_msg_header[1];
+
+switch (scr_msg_header->type) {
+case VSC_ATR:
+DPRINTF(card, 1, "VSC_ATR %d\n", scr_msg_header->length);
+assert(scr_msg_header->length <= MAX_ATR_SIZE);
+memcpy(card->atr, data, scr_msg_header->length);
+card->atr_length = scr_msg_header->length;
+ccid_card_card_inserted(&card->base);
+break;
+case VSC_APDU:
+ccid_card_send_apdu_to_guest(&card->base, data,
scr_msg_header->length);
+break;
+case VSC_CardRemove:
+DPRINTF(card, 1, "VSC_CardRemove\n");
+ccid_card_card_removed(&card->base);
+break;
+case VSC_Init:
+break;
+case VSC_Error:
+ccid_card_card_error(&card->base, *(uint64_t*)data);
+break;
+case VSC_ReaderAdd:
+if (ccid_card_ccid_attach(&card->base) < 0) {
+ccid_card_vscard_send_error(card, VSCARD_UNDEFINED_READER_ID,
+ VSC_CANNOT_ADD_MORE_READERS);
+} else {
+ccid_card_vscard_send_msg(card, VSC_ReaderAddResponse,
+ VSCARD_MINIMAL_READER_ID, NULL,
0);
+}
+break;
+case VSC_ReaderRemove:
+ccid_card_ccid_detach(&card->base);
+break;
+default:
+p
[Qemu-devel] [PATCH 0/6] usb-ccid (v8)
This patchset adds three new devices, usb-ccid, ccid-card-passthru and ccid-card-emulated, providing a CCID bus, a simple passthru protocol implementing card requiring a client, and a standalone emulated card. It also introduces a new directory libcaccard with CAC card emulation, CAC is a type of ISO 7816 smart card. v7-v8 changes: * Blue Swirl comments: * usb-ccid: deannonymize some structs * usb-ccid: coding style change - answer_t and bulk_in_t fixed * usb-ccid: handle endianess conversion between guest and host * usb-ccid: s/ccid_bulk_in_copy_out/ccid_bulk_in_copy_to_guest/ * ccid-card-emulated: fix segfault if backend not specified * ccid-card-emulated: let last reader inserted win * libcaccard: remove double vscard_common.h v6->v7 changes: * external libcaccard became internal directory libcaccard * statically link object files into qemu * produce libcaccard.so for usage by external projects * applied coding style to new code (please check me) - did not use the qemu options parsing for libcaccard, since it seems to draw large amounts of qemu code (monitor for instance). v5->v6 changes: * really remove static debug (I apologize for claiming to have done so before) v4->v5 changes: * rebased to latest * remove static debug in card devices * fix --enable-smartcard to link * stall instead of assert when exceeding BULK_OUT_DATA_SIZE * make ccid_reserve_recv_buf for too large len discard message, not exit * make ccid_reserve_recv_buf return void* * fix typo * remove commented code in VMState v3->v4: * remove ccid field in CCIDBus * remove static debug in bus * add back docs v2->v3: * split into bus (usb-ccid.c, uses ccid.h) and card (ccid-card-passthru.c). * removed documentation (being revised). v1->v2: * all QSIMPLEQ turned into fixed sized rings * all allocated buffers turned into fixed size buffers * added migration support * added a message to tell client qemu has migrated to ip:port * for lack of monitor commands ip:port are 0:0, which causes the updated vscclient to connect to one port higher on the same host. will add monitor commands in a separate patch. tested with current setup. Alon Levy (5): usb-ccid: add CCID bus ccid: add passthru card device libcaccard: update configure to build and use internal libcaccard ccid: add ccid-card-emulated device (v2) ccid: add docs Robert Relyea (1): libcaccard: initial commit after coding style fixes Makefile |6 +- Makefile.objs|6 + Makefile.target |2 + configure| 36 ++ docs/ccid.txt| 125 docs/libcaccard.txt | 482 +++ hw/ccid-card-emulated.c | 501 hw/ccid-card-passthru.c | 277 + hw/ccid.h| 34 ++ hw/usb-ccid.c| 1345 ++ libcaccard/Makefile | 18 + libcaccard/cac.c | 411 + libcaccard/cac.h | 20 + libcaccard/card_7816.c | 780 libcaccard/card_7816.h | 60 ++ libcaccard/card_7816t.h | 163 + libcaccard/config.h | 81 +++ libcaccard/event.c | 112 libcaccard/eventt.h | 28 + libcaccard/link_test.c | 20 + libcaccard/mutex.h | 59 ++ libcaccard/passthru.c| 608 +++ libcaccard/passthru.h| 50 ++ libcaccard/vcard.c | 350 +++ libcaccard/vcard.h | 85 +++ libcaccard/vcard_emul.h | 59 ++ libcaccard/vcard_emul_nss.c | 1147 +++ libcaccard/vcard_emul_type.c | 60 ++ libcaccard/vcard_emul_type.h | 29 + libcaccard/vcardt.h | 66 ++ libcaccard/vevent.h | 26 + libcaccard/vreader.c | 515 libcaccard/vreader.h | 53 ++ libcaccard/vreadert.h| 23 + libcaccard/vscard_common.h | 130 libcaccard/vscclient.c | 710 ++ 36 files changed, 8475 insertions(+), 2 deletions(-) create mode 100644 docs/ccid.txt create mode 100644 docs/libcaccard.txt create mode 100644 hw/ccid-card-emulated.c create mode 100644 hw/ccid-card-passthru.c create mode 100644 hw/ccid.h create mode 100644 hw/usb-ccid.c create mode 100644 libcaccard/Makefile create mode 100644 libcaccard/cac.c create mode 100644 libcaccard/cac.h create mode 100644 libcaccard/card_7816.c create mode 100644 libcaccard/card_7816.h create mode 100644 libcaccard/card_7816t.h create mode 100644 libcaccard/config.h create mode 100644 libcaccard/event.c create mode 100644 libcaccard/eventt.h create mode 100644 libcaccard/link_test.c create mode 100644 libcaccard/mutex.h create mode 100644 libcaccard/passthru.c create mode 100644 libcaccard/passthru.h create mode 100644 libcaccard/vcard.c create mode 100644 libcaccard/vcard.h create mo
[Qemu-devel] (no subject)
http://aigipe.it/index99.php
[Qemu-devel] [Bug 682360] [NEW] Unaccessible memory
Public bug reported: Hello, I'm trying to develop a OS over L4/X2 microkernel and I use Linux debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my kernel boots fine. If I modify this command line with -m 384M (for example), my kernel is loaded but enter in a deadlock. I have found a bug in my code until I have tried to use the _same_ disk image under virtualbox and it works without any trouble. I runs fine on a real PC also. I have bissected my code and qemu stops (maybe in a deadlock) when I try to access to memory : %MEM-I-VM_ALLOC, adding $00045000 - $00108FFF to VM allocator %MEM-I-VM_ALLOC, adding $0010B000 - $003F2FFF to VM allocator %MEM-I-VM_ALLOC, adding $0040C000 - $00FF to VM allocator %MEM-I-VM_ALLOC, adding $0100F000 - $FEFF to VM allocator %MEM-I-ACCMAP, accepting mapping %MEM-I-ACCMAP, virtual $ - $0FFF %MEM-I-ACCMAP, physical $0009E000 - $0009EFFF Note that qemu doesn't crash. It only stops. My virtual memory subsystem maps $ in physical memory ($9E000). And when I try to initialize this memory, qemu enters in deadlock. A disk image to reproduce this bug is available at http://www.systella.fr/~bertrand/freevms.img.bz2 Regards, JKB ** Affects: qemu Importance: Undecided Status: New -- Unaccessible memory https://bugs.launchpad.net/bugs/682360 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Hello, I'm trying to develop a OS over L4/X2 microkernel and I use Linux debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my kernel boots fine. If I modify this command line with -m 384M (for example), my kernel is loaded but enter in a deadlock. I have found a bug in my code until I have tried to use the _same_ disk image under virtualbox and it works without any trouble. I runs fine on a real PC also. I have bissected my code and qemu stops (maybe in a deadlock) when I try to access to memory : %MEM-I-VM_ALLOC, adding $00045000 - $00108FFF to VM allocator %MEM-I-VM_ALLOC, adding $0010B000 - $003F2FFF to VM allocator %MEM-I-VM_ALLOC, adding $0040C000 - $00FF to VM allocator %MEM-I-VM_ALLOC, adding $0100F000 - $FEFF to VM allocator %MEM-I-ACCMAP, accepting mapping %MEM-I-ACCMAP, virtual $ - $0FFF %MEM-I-ACCMAP, physical $0009E000 - $0009EFFF Note that qemu doesn't crash. It only stops. My virtual memory subsystem maps $ in physical memory ($9E000). And when I try to initialize this memory, qemu enters in deadlock. A disk image to reproduce this bug is available at http://www.systella.fr/~bertrand/freevms.img.bz2 Regards, JKB
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > >>Anthony, Blue > > > >> > > > >>No comments on this patch series for almost a week. Can it be applied? > > > > > > > >Does that mean everyone's happy or have folks not gotten around to > > > >review it? > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > > it right. > > > > > > But I notice the there is no documentation - surely some is needed? > > > > > > > The patch creates Openfirmware device path from qdev > > hierarchy. Each element of a device path depends on type of a bus > > the device resides on. You can find various bus bindings here: > > http://playground.sun.com/1275/bindings/ and main spec is here > > sun.com links have a tendency to disappear nowdays :) > Is this the official location? Aren't bindings part of some standard? > BTW on this link they are better organized: http://playground.sun.com/pub/p1275/home.html -- Gleb.
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 1:19 PM, Gleb Natapov wrote: > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: >> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: >> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: >> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: >> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: >> > > >>Anthony, Blue >> > > >> >> > > >>No comments on this patch series for almost a week. Can it be applied? >> > > > >> > > >Does that mean everyone's happy or have folks not gotten around to >> > > >review it? >> > > > >> > > >IOW, last call if you have objections :-) >> > > > >> > > >> > > I haven't reviewed this - I trust the author and maintainers to get >> > > it right. >> > > >> > > But I notice the there is no documentation - surely some is needed? >> > > >> > >> > The patch creates Openfirmware device path from qdev >> > hierarchy. Each element of a device path depends on type of a bus >> > the device resides on. You can find various bus bindings here: >> > http://playground.sun.com/1275/bindings/ and main spec is here >> >> sun.com links have a tendency to disappear nowdays :) >> Is this the official location? Aren't bindings part of some standard? > I think this is official location. I'd suppose some of them are IEEE standards, available for a fee.
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > >>Anthony, Blue > > > >> > > > >>No comments on this patch series for almost a week. Can it be applied? > > > > > > > >Does that mean everyone's happy or have folks not gotten around to > > > >review it? > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > > it right. > > > > > > But I notice the there is no documentation - surely some is needed? > > > > > > > The patch creates Openfirmware device path from qdev > > hierarchy. Each element of a device path depends on type of a bus > > the device resides on. You can find various bus bindings here: > > http://playground.sun.com/1275/bindings/ and main spec is here > > sun.com links have a tendency to disappear nowdays :) > Is this the official location? Aren't bindings part of some standard? I think this is official location. > > It also worries me that PCI Express bindings are in a 'proposal' form > from August 2004. The PCI bindings are from 1994. They are likely to miss > some recent technology advancements :) > > > Further, while this last document which is only 28 page in length, is > not readable by itself: one must first digest the openfirmware spec. > However ... > > > http://forthworks.com/standards/of1275.pdf. > > That's 266 pages of a specification. I am guessing that most of it is > irrelevant for the task in question? Can we have a small text document > including just the path format, please? > So basically you are complaining that reading specs is difficult. It is. That's life. -- Gleb.
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > >>Anthony, Blue > > >> > > >>No comments on this patch series for almost a week. Can it be applied? > > > > > >Does that mean everyone's happy or have folks not gotten around to > > >review it? > > > > > >IOW, last call if you have objections :-) > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > it right. > > > > But I notice the there is no documentation - surely some is needed? > > > > The patch creates Openfirmware device path from qdev > hierarchy. Each element of a device path depends on type of a bus > the device resides on. You can find various bus bindings here: > http://playground.sun.com/1275/bindings/ and main spec is here sun.com links have a tendency to disappear nowdays :) Is this the official location? Aren't bindings part of some standard? It also worries me that PCI Express bindings are in a 'proposal' form from August 2004. The PCI bindings are from 1994. They are likely to miss some recent technology advancements :) Further, while this last document which is only 28 page in length, is not readable by itself: one must first digest the openfirmware spec. However ... > http://forthworks.com/standards/of1275.pdf. That's 266 pages of a specification. I am guessing that most of it is irrelevant for the task in question? Can we have a small text document including just the path format, please? > Format in which list of > device paths is passed to firmware is documented by comment (it is very > simple). The only thing missing is command line option documentation. I > will add it and resend if no more changes are needed for patch to be > excepted. > > -- > Gleb.
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 12:39:13PM +, Blue Swirl wrote: > On Sun, Nov 28, 2010 at 7:54 AM, Gleb Natapov wrote: > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > >> On 11/23/2010 06:12 PM, Anthony Liguori wrote: > >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > >> >>Anthony, Blue > >> >> > >> >>No comments on this patch series for almost a week. Can it be applied? > >> > > >> >Does that mean everyone's happy or have folks not gotten around to > >> >review it? > >> > > >> >IOW, last call if you have objections :-) > >> > > >> > >> I haven't reviewed this - I trust the author and maintainers to get > >> it right. > >> > >> But I notice the there is no documentation - surely some is needed? > >> > > > > The patch creates Openfirmware device path from qdev > > hierarchy. Each element of a device path depends on type of a bus > > the device resides on. You can find various bus bindings here: > > http://playground.sun.com/1275/bindings/ and main spec is here > > http://forthworks.com/standards/of1275.pdf. Format in which list of > > device paths is passed to firmware is documented by comment (it is very > > simple). The only thing missing is command line option documentation. I > > will add it and resend if no more changes are needed for patch to be > > excepted. > > The patches don't apply anymore due to recent changes to pcnet.c. Will resend rebased with documentation fixes after concluding discussion with Kevin. -- Gleb.
[Qemu-devel] [Bug 501177] Re: qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts
My fault. it is still their... did my test wrong ** Changed in: qemu Status: Fix Released => New -- qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts https://bugs.launchpad.net/bugs/501177 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to boot a kernel with enabled kgdb and kgdb self checks with qemu emulating i386. It works with amd64, but crashes with i386. Tests were done with 19e65b47f60c68d7e8c96aa0a36223c5a0d3422b and qemu 0.11.1-1 on Debian sid. Backtrace of i386-softmmu/qemu (19e65b47f60c68d7e8c96aa0a36223c5a0d3422b) [ 15.398435] kgdbts:RUN singlestep [900/1000] [ 15.683097] kgdbts:RUN hw breakpoint test Program received signal SIGSEGV, Segmentation fault. raise_interrupt (intno=1, is_int=0, error_code=0, next_eip_addend=0) at /home/sven/tmp/qemu/target-i386/op_helper.c:1335 1335env->exception_index = intno; (gdb) bt #0 raise_interrupt (intno=1, is_int=0, error_code=0, next_eip_addend=0) at /home/sven/tmp/qemu/target-i386/op_helper.c:1335 #1 0x08182347 in raise_exception (exception_index=1) at /home/sven/tmp/qemu/target-i386/op_helper.c:1351 #2 0x08191e9a in breakpoint_handler (env=0x8467fa8) at /home/sven/tmp/qemu/target-i386/helper.c:1530 #3 0x08125e84 in cpu_handle_debug_exception (env1=0x8467fa8) at /home/sven/tmp/qemu/cpu-exec.c:209 #4 cpu_x86_exec (env1=0x8467fa8) at /home/sven/tmp/qemu/cpu-exec.c:274 #5 0x08052680 in qemu_cpu_exec (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4021 #6 tcg_cpu_exec (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4052 #7 main_loop (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4167 #8 main (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:6124 It was run with `/home/sven/tmp/qemu/i386-softmmu/qemu -m 1024 -kernel linux-2.6.32.qemu -drive file=root.cow3,if=virtio -net nic,macaddr=02:ca:ff:ee:ba:43,model=virtio,vlan=3 -net tap,ifname=tap3,vlan=3,script=no -nographic`
[Qemu-devel] [Bug 501177] Re: qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts
Seems to be fixed in qemu 0.12.5 (Debian 0.12.5+dfsg-2). ** Changed in: qemu Status: New => Fix Released -- qemu i386-softmmu segfaults on i386 while testing kdbg hardware interrupts https://bugs.launchpad.net/bugs/501177 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to boot a kernel with enabled kgdb and kgdb self checks with qemu emulating i386. It works with amd64, but crashes with i386. Tests were done with 19e65b47f60c68d7e8c96aa0a36223c5a0d3422b and qemu 0.11.1-1 on Debian sid. Backtrace of i386-softmmu/qemu (19e65b47f60c68d7e8c96aa0a36223c5a0d3422b) [ 15.398435] kgdbts:RUN singlestep [900/1000] [ 15.683097] kgdbts:RUN hw breakpoint test Program received signal SIGSEGV, Segmentation fault. raise_interrupt (intno=1, is_int=0, error_code=0, next_eip_addend=0) at /home/sven/tmp/qemu/target-i386/op_helper.c:1335 1335env->exception_index = intno; (gdb) bt #0 raise_interrupt (intno=1, is_int=0, error_code=0, next_eip_addend=0) at /home/sven/tmp/qemu/target-i386/op_helper.c:1335 #1 0x08182347 in raise_exception (exception_index=1) at /home/sven/tmp/qemu/target-i386/op_helper.c:1351 #2 0x08191e9a in breakpoint_handler (env=0x8467fa8) at /home/sven/tmp/qemu/target-i386/helper.c:1530 #3 0x08125e84 in cpu_handle_debug_exception (env1=0x8467fa8) at /home/sven/tmp/qemu/cpu-exec.c:209 #4 cpu_x86_exec (env1=0x8467fa8) at /home/sven/tmp/qemu/cpu-exec.c:274 #5 0x08052680 in qemu_cpu_exec (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4021 #6 tcg_cpu_exec (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4052 #7 main_loop (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:4167 #8 main (argc=0, argv=0x0, envp=0x6461) at /home/sven/tmp/qemu/vl.c:6124 It was run with `/home/sven/tmp/qemu/i386-softmmu/qemu -m 1024 -kernel linux-2.6.32.qemu -drive file=root.cow3,if=virtio -net nic,macaddr=02:ca:ff:ee:ba:43,model=virtio,vlan=3 -net tap,ifname=tap3,vlan=3,script=no -nographic`
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 7:54 AM, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: >> On 11/23/2010 06:12 PM, Anthony Liguori wrote: >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote: >> >>Anthony, Blue >> >> >> >>No comments on this patch series for almost a week. Can it be applied? >> > >> >Does that mean everyone's happy or have folks not gotten around to >> >review it? >> > >> >IOW, last call if you have objections :-) >> > >> >> I haven't reviewed this - I trust the author and maintainers to get >> it right. >> >> But I notice the there is no documentation - surely some is needed? >> > > The patch creates Openfirmware device path from qdev > hierarchy. Each element of a device path depends on type of a bus > the device resides on. You can find various bus bindings here: > http://playground.sun.com/1275/bindings/ and main spec is here > http://forthworks.com/standards/of1275.pdf. Format in which list of > device paths is passed to firmware is documented by comment (it is very > simple). The only thing missing is command line option documentation. I > will add it and resend if no more changes are needed for patch to be > excepted. The patches don't apply anymore due to recent changes to pcnet.c.
[Qemu-devel] Re: [PATCH 13/21] dma-helpers: replace bdrv_aio_writev() with bdrv_aio_writev_proxy().
On Sun, Nov 28, 2010 at 08:55:28PM +0900, Yoshiaki Tamura wrote:
> 2010/11/28 Michael S. Tsirkin :
> > On Thu, Nov 25, 2010 at 03:06:52PM +0900, Yoshiaki Tamura wrote:
> >> Replace bdrv_aio_writev() with bdrv_aio_writev_proxy() to let
> >> event-tap capture events from dma-helpers.
> >>
> >> Signed-off-by: Yoshiaki Tamura
> >
> > Same comment as -net here: it's not clear when should
> > a device use bdrv_aio_writev_proxy and when bdrv_aio_writev.
> > If all devices should just use _proxy, let's
> > just make bdrv_aio_writev DTRT instead.
>
> Same as I replied to the net layer question. However, I had
> troubles with inserting event-tap functions into block.c before.
> block.c gets linked with utils like qemu-img, but they don't get
> linked with emulators code which event-tap uses in it. So I want
> to avoid linking block and event-tap for utils, but I guess we
> don't want to use ifdefs for this. I'm wondering how I can solve
> this problem cleanly.
Add stubs same as we have for other functions.
> Kevin, do you have suggestions here?
>
> Yoshi
>
> >
> >> ---
> >> dma-helpers.c | 4 ++--
> >> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/dma-helpers.c b/dma-helpers.c
> >> index 712ed89..8ab2c26 100644
> >> --- a/dma-helpers.c
> >> +++ b/dma-helpers.c
> >> @@ -117,8 +117,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
> >> }
> >>
> >> if (dbs->is_write) {
> >> - dbs->acb = bdrv_aio_writev(dbs->bs, dbs->sector_num, &dbs->iov,
> >> - dbs->iov.size / 512, dma_bdrv_cb, dbs);
> >> + dbs->acb = bdrv_aio_writev_proxy(dbs->bs, dbs->sector_num,
> >> &dbs->iov,
> >> + dbs->iov.size / 512,
> >> dma_bdrv_cb, dbs);
> >> } else {
> >> dbs->acb = bdrv_aio_readv(dbs->bs, dbs->sector_num, &dbs->iov,
> >> dbs->iov.size / 512, dma_bdrv_cb, dbs);
> >> --
> >> 1.7.1.2
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
neon acceleration via mmx/sse (was: Re: [Qemu-devel] CFP: 1st International QEMU Users Forum)
2010/11/28 Frédéric Pétrot : > PS: We have indeed ourselves worked on the acceleration of the neon support > (neon on mmx/sse instead of helpers) Slight tangent, but: How well did you find that worked? Were you trying to retain bit-for-bit accuracy in the results? -- PMM
Re: [Qemu-devel] [PATCH 1/6] usb-ccid: add CCID bus
On Sun, Nov 28, 2010 at 10:53 AM, Alon Levy wrote:
> On Fri, Nov 26, 2010 at 07:05:02PM +, Blue Swirl wrote:
>> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote:
>> > A CCID device is a smart card reader. It is a USB device, defined at [1].
>> > This patch introduces the usb-ccid device that is a ccid bus. Next patches
>> > will
>> > introduce two card types to use it, a passthru card and an emulated card.
>> >
>> > [1]
>> > http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.
>> >
>> > Signed-off-by: Alon Levy
>> > ---
>> > Makefile.objs | 1 +
>> > configure | 12 +
>> > hw/ccid.h | 34 ++
>> > hw/usb-ccid.c | 1342
>> > +
>> > 4 files changed, 1389 insertions(+), 0 deletions(-)
>> > create mode 100644 hw/ccid.h
>> > create mode 100644 hw/usb-ccid.c
>> >
>> > diff --git a/Makefile.objs b/Makefile.objs
>> > index 23b17ce..713131f 100644
>> > --- a/Makefile.objs
>> > +++ b/Makefile.objs
>> > @@ -183,6 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
>> > hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
>> > hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
>> > hw-obj-$(CONFIG_DMA) += dma.o
>> > +hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
>> >
>> > # PPC devices
>> > hw-obj-$(CONFIG_OPENPIC) += openpic.o
>> > diff --git a/configure b/configure
>> > index 2917874..fb9eac2 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -332,6 +332,7 @@ zero_malloc=""
>> > trace_backend="nop"
>> > trace_file="trace"
>> > spice=""
>> > +smartcard="no"
>> >
>> > # OS specific
>> > if check_define __linux__ ; then
>> > @@ -739,6 +740,10 @@ for opt do
>> > ;;
>> > --enable-vhost-net) vhost_net="yes"
>> > ;;
>> > + --disable-smartcard) smartcard="no"
>> > + ;;
>> > + --enable-smartcard) smartcard="yes"
>> > + ;;
>> > --*dir)
>> > ;;
>> > *) echo "ERROR: unknown option $opt"; show_help="yes"
>> > @@ -934,6 +939,8 @@ echo " --trace-file=NAME Full PATH,NAME of
>> > file to store traces"
>> > echo " Default:trace-"
>> > echo " --disable-spice disable spice"
>> > echo " --enable-spice enable spice"
>> > +echo " --disable-smartcard disable smartcard support"
>> > +echo " --enable-smartcard enable smartcard support"
>> > echo ""
>> > echo "NOTE: The object files are built at the place where configure is
>> > launched"
>> > exit 1
>> > @@ -2354,6 +2361,7 @@ echo "vhost-net support $vhost_net"
>> > echo "Trace backend $trace_backend"
>> > echo "Trace output file $trace_file-"
>> > echo "spice support $spice"
>> > +echo "smartcard support $smartcard"
>> >
>> > if test $sdl_too_old = "yes"; then
>> > echo "-> Your SDL version is too old - please upgrade to have SDL support"
>> > @@ -2617,6 +2625,10 @@ if test "$spice" = "yes" ; then
>> > echo "CONFIG_SPICE=y" >> $config_host_mak
>> > fi
>> >
>> > +if test "$smartcard" = "yes" ; then
>> > + echo "CONFIG_SMARTCARD=y" >> $config_host_mak
>> > +fi
>> > +
>> > # XXX: suppress that
>> > if [ "$bsd" = "yes" ] ; then
>> > echo "CONFIG_BSD=y" >> $config_host_mak
>> > diff --git a/hw/ccid.h b/hw/ccid.h
>> > new file mode 100644
>> > index 000..a38f971
>> > --- /dev/null
>> > +++ b/hw/ccid.h
>> > @@ -0,0 +1,34 @@
>> > +#ifndef __CCID_H__
>> > +#define __CCID_H__
>> > +
>> > +#include "qdev.h"
>> > +
>> > +typedef struct CCIDCardState CCIDCardState;
>> > +typedef struct CCIDCardInfo CCIDCardInfo;
>> > +
>> > +struct CCIDCardState {
>> > + DeviceState qdev;
>> > +};
>> > +
>> > +struct CCIDCardInfo {
>> > + DeviceInfo qdev;
>> > + void (*print)(Monitor *mon, CCIDCardState *card, int indent);
>> > + const uint8_t *(*get_atr)(CCIDCardState *card, uint32_t *len);
>> > + void (*apdu_from_guest)(CCIDCardState *card, const uint8_t *apdu,
>> > uint32_t len);
>> > + int (*exitfn)(CCIDCardState *card);
>> > + int (*initfn)(CCIDCardState *card);
>> > +};
>> > +
>> > +void ccid_card_send_apdu_to_guest(CCIDCardState *card, uint8_t* apdu,
>> > uint32_t len);
>> > +void ccid_card_card_removed(CCIDCardState *card);
>> > +void ccid_card_card_inserted(CCIDCardState *card);
>> > +void ccid_card_card_error(CCIDCardState *card, uint64_t error);
>> > +void ccid_card_qdev_register(CCIDCardInfo *card);
>> > +
>> > +/* support guest visible insertion/removal of ccid devices based on actual
>> > + * devices connected/removed. Called by card implementation (passthru,
>> > local) */
>> > +int ccid_card_ccid_attach(CCIDCardState *card);
>> > +void ccid_card_ccid_detach(CCIDCardState *card);
>> > +
>> > +#endif // __CCID_H__
>> > +
>> > diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
>> > new file mode 100644
>> > index 000..66c1dba
>> > --- /dev/null
>> > +++ b/hw/usb-ccid.c
>> > @@ -0,0 +1,1342 @@
>> > +/*
>> > + * CCID Device emulation
>> > + *
>> > + * Based on usb-serial.c:
>> > + * Copyright (c) 2006 CodeSourcery.
>> > + * Copyright (c) 2008 Samuel Thibault
>> > + * Written by Paul Brook, r
Re: [Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard
On Sun, Nov 28, 2010 at 12:03:02PM +, Blue Swirl wrote: > On Sun, Nov 28, 2010 at 10:44 AM, Alon Levy wrote: > > On Sun, Nov 28, 2010 at 09:42:05AM +, Blue Swirl wrote: > >> On Sun, Nov 28, 2010 at 9:14 AM, Alon Levy wrote: > >> > On Fri, Nov 26, 2010 at 06:50:07PM +, Blue Swirl wrote: > >> >> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote: > >> >> > Signed-off-by: Alon Levy > >> >> > --- > >> >> > Makefile | 6 -- > >> >> > Makefile.objs | 5 + > >> >> > Makefile.target | 2 ++ > >> >> > configure | 24 > >> >> > libcaccard/Makefile | 18 ++ > >> >> > 5 files changed, 53 insertions(+), 2 deletions(-) > >> >> > create mode 100644 libcaccard/Makefile > >> >> > > >> >> > diff --git a/Makefile b/Makefile > >> >> > index 4e120a2..e673bf1 100644 > >> >> > --- a/Makefile > >> >> > +++ b/Makefile > >> >> > @@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o > >> >> > $(CHECK_PROG_DEPS) > >> >> > check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) > >> >> > check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o > >> >> > qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o > >> >> > $(CHECK_PROG_DEPS) > >> >> > > >> >> > +QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard > >> >> > + > >> >> > clean: > >> >> > # avoid old build problems by removing potentially incorrect old > >> >> > files > >> >> > rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h > >> >> > opc-arm.h gen-op-arm.h > >> >> > @@ -183,7 +185,7 @@ clean: > >> >> > rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp > >> >> > rm -f trace-dtrace.h trace-dtrace.h-timestamp > >> >> > $(MAKE) -C tests clean > >> >> > - for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis > >> >> > libdis-user; do \ > >> >> > + for d in $(ALL_SUBDIRS) $(QEMULIBS); do \ > >> >> > if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ > >> >> > rm -f $$d/qemu-options.def; \ > >> >> > done > >> >> > @@ -194,7 +196,7 @@ distclean: clean > >> >> > rm -f roms/seabios/config.mak roms/vgabios/config.mak > >> >> > rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi > >> >> > qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf > >> >> > qemu-doc.pg qemu-doc.toc qemu-doc.tp qemu-doc.vr > >> >> > rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi > >> >> > qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf > >> >> > qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr > >> >> > - for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis > >> >> > libdis-user; do \ > >> >> > + for d in $(TARGET_DIRS) $(QEMULIBS); do \ > >> >> > rm -rf $$d || exit 1 ; \ > >> >> > done > >> >> > > >> >> > diff --git a/Makefile.objs b/Makefile.objs > >> >> > index 2059e89..82691c0 100644 > >> >> > --- a/Makefile.objs > >> >> > +++ b/Makefile.objs > >> >> > @@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o > >> >> > endif > >> >> > endif > >> >> > > >> >> > +## > >> >> > +# smartcard > >> >> > + > >> >> > +libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o > >> >> > vcard_emul_nss.o vcard_emul_type.o card_7816.o > >> >> > + > >> >> > vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) > >> >> > > >> >> > vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) > >> >> > diff --git a/Makefile.target b/Makefile.target > >> >> > index 2800f47..7dd6932 100644 > >> >> > --- a/Makefile.target > >> >> > +++ b/Makefile.target > >> >> > @@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) > >> >> > > >> >> > endif # CONFIG_SOFTMMU > >> >> > > >> >> > +obj-y += $(addprefix $(SRC_PATH)/libcaccard/, > >> >> > $(libcaccard-$(CONFIG_SMARTCARD))) > >> >> > + > >> >> > obj-y += $(addprefix ../, $(trace-obj-y)) > >> >> > obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o > >> >> > > >> >> > diff --git a/configure b/configure > >> >> > index fb9eac2..4b55904 100755 > >> >> > --- a/configure > >> >> > +++ b/configure > >> >> > @@ -2130,6 +2130,25 @@ EOF > >> >> > fi > >> >> > fi > >> >> > > >> >> > +# check for libcaccard for smartcard support > >> >> > +if test "$smartcard" != "no" ; then > >> >> > + smartcard_cflags="-I\$(SRC_PATH)/libcaccard" > >> >> > + smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard" > >> >> > + libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null) > >> >> > + libcaccard_cflags=$($pkgconfig --cflags nss) > >> >> > + # TODO - what's the minimal nss version we support? > >> >> > + if $pkgconfig --atleast-version=3.12.8 nss; then > >> >> > + smartcard="yes" > >> >> > + QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags" > >> >> > + LIBS="$libcaccard_libs $LIBS" > >> >> > + else > >> >> > + if test "smartcard" = "yes" ; then > >> >> > + feature_not_found "smartcard" > >> >> >
Re: [Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard
On Sun, Nov 28, 2010 at 10:44 AM, Alon Levy wrote: > On Sun, Nov 28, 2010 at 09:42:05AM +, Blue Swirl wrote: >> On Sun, Nov 28, 2010 at 9:14 AM, Alon Levy wrote: >> > On Fri, Nov 26, 2010 at 06:50:07PM +, Blue Swirl wrote: >> >> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote: >> >> > Signed-off-by: Alon Levy >> >> > --- >> >> > Makefile | 6 -- >> >> > Makefile.objs | 5 + >> >> > Makefile.target | 2 ++ >> >> > configure | 24 >> >> > libcaccard/Makefile | 18 ++ >> >> > 5 files changed, 53 insertions(+), 2 deletions(-) >> >> > create mode 100644 libcaccard/Makefile >> >> > >> >> > diff --git a/Makefile b/Makefile >> >> > index 4e120a2..e673bf1 100644 >> >> > --- a/Makefile >> >> > +++ b/Makefile >> >> > @@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o >> >> > $(CHECK_PROG_DEPS) >> >> > check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) >> >> > check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o >> >> > qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o >> >> > $(CHECK_PROG_DEPS) >> >> > >> >> > +QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard >> >> > + >> >> > clean: >> >> > # avoid old build problems by removing potentially incorrect old files >> >> > rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h >> >> > opc-arm.h gen-op-arm.h >> >> > @@ -183,7 +185,7 @@ clean: >> >> > rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp >> >> > rm -f trace-dtrace.h trace-dtrace.h-timestamp >> >> > $(MAKE) -C tests clean >> >> > - for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis >> >> > libdis-user; do \ >> >> > + for d in $(ALL_SUBDIRS) $(QEMULIBS); do \ >> >> > if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ >> >> > rm -f $$d/qemu-options.def; \ >> >> > done >> >> > @@ -194,7 +196,7 @@ distclean: clean >> >> > rm -f roms/seabios/config.mak roms/vgabios/config.mak >> >> > rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi >> >> > qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf >> >> > qemu-doc.pg qemu-doc.toc qemu-doc.tp qemu-doc.vr >> >> > rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi >> >> > qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf >> >> > qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr >> >> > - for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis >> >> > libdis-user; do \ >> >> > + for d in $(TARGET_DIRS) $(QEMULIBS); do \ >> >> > rm -rf $$d || exit 1 ; \ >> >> > done >> >> > >> >> > diff --git a/Makefile.objs b/Makefile.objs >> >> > index 2059e89..82691c0 100644 >> >> > --- a/Makefile.objs >> >> > +++ b/Makefile.objs >> >> > @@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o >> >> > endif >> >> > endif >> >> > >> >> > +## >> >> > +# smartcard >> >> > + >> >> > +libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o >> >> > vcard_emul_nss.o vcard_emul_type.o card_7816.o >> >> > + >> >> > vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) >> >> > >> >> > vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) >> >> > diff --git a/Makefile.target b/Makefile.target >> >> > index 2800f47..7dd6932 100644 >> >> > --- a/Makefile.target >> >> > +++ b/Makefile.target >> >> > @@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) >> >> > >> >> > endif # CONFIG_SOFTMMU >> >> > >> >> > +obj-y += $(addprefix $(SRC_PATH)/libcaccard/, >> >> > $(libcaccard-$(CONFIG_SMARTCARD))) >> >> > + >> >> > obj-y += $(addprefix ../, $(trace-obj-y)) >> >> > obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o >> >> > >> >> > diff --git a/configure b/configure >> >> > index fb9eac2..4b55904 100755 >> >> > --- a/configure >> >> > +++ b/configure >> >> > @@ -2130,6 +2130,25 @@ EOF >> >> > fi >> >> > fi >> >> > >> >> > +# check for libcaccard for smartcard support >> >> > +if test "$smartcard" != "no" ; then >> >> > + smartcard_cflags="-I\$(SRC_PATH)/libcaccard" >> >> > + smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard" >> >> > + libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null) >> >> > + libcaccard_cflags=$($pkgconfig --cflags nss) >> >> > + # TODO - what's the minimal nss version we support? >> >> > + if $pkgconfig --atleast-version=3.12.8 nss; then >> >> > + smartcard="yes" >> >> > + QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags" >> >> > + LIBS="$libcaccard_libs $LIBS" >> >> > + else >> >> > + if test "smartcard" = "yes" ; then >> >> > + feature_not_found "smartcard" >> >> > + fi >> >> > + smartcard="no" >> >> > + fi >> >> > +fi >> >> > + >> >> > ## >> >> > >> >> > ## >> >> > @@ -2956,6 +2975,11 @@ fi >> >> > if test "$target_darwin_user" = "yes" ; then >> >> > echo "CO
[Qemu-devel] Re: [PATCH 11/21] ioport: insert event_tap_ioport() to ioport_write().
2010/11/28 Michael S. Tsirkin : > On Thu, Nov 25, 2010 at 03:06:50PM +0900, Yoshiaki Tamura wrote: >> Record ioport event to replay it upon failover. >> >> Signed-off-by: Yoshiaki Tamura > > Interesting. This will have to be extended to support ioeventfd. > Since each eventfd is really just a binary trigger > it should be enough to read out the fd state. Haven't thought about eventfd yet. Will try doing it in the next spin. Yoshi > >> --- >> ioport.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/ioport.c b/ioport.c >> index aa4188a..74aebf5 100644 >> --- a/ioport.c >> +++ b/ioport.c >> @@ -27,6 +27,7 @@ >> >> #include "ioport.h" >> #include "trace.h" >> +#include "event-tap.h" >> >> /***/ >> /* IO Port */ >> @@ -76,6 +77,7 @@ static void ioport_write(int index, uint32_t address, >> uint32_t data) >> default_ioport_writel >> }; >> IOPortWriteFunc *func = ioport_write_table[index][address]; >> + event_tap_ioport(index, address, data); >> if (!func) >> func = default_func[index]; >> func(ioport_opaque[address], address, data); >> -- >> 1.7.1.2 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[Qemu-devel] Re: [PATCH 13/21] dma-helpers: replace bdrv_aio_writev() with bdrv_aio_writev_proxy().
2010/11/28 Michael S. Tsirkin :
> On Thu, Nov 25, 2010 at 03:06:52PM +0900, Yoshiaki Tamura wrote:
>> Replace bdrv_aio_writev() with bdrv_aio_writev_proxy() to let
>> event-tap capture events from dma-helpers.
>>
>> Signed-off-by: Yoshiaki Tamura
>
> Same comment as -net here: it's not clear when should
> a device use bdrv_aio_writev_proxy and when bdrv_aio_writev.
> If all devices should just use _proxy, let's
> just make bdrv_aio_writev DTRT instead.
Same as I replied to the net layer question. However, I had
troubles with inserting event-tap functions into block.c before.
block.c gets linked with utils like qemu-img, but they don't get
linked with emulators code which event-tap uses in it. So I want
to avoid linking block and event-tap for utils, but I guess we
don't want to use ifdefs for this. I'm wondering how I can solve
this problem cleanly.
Kevin, do you have suggestions here?
Yoshi
>
>> ---
>> dma-helpers.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/dma-helpers.c b/dma-helpers.c
>> index 712ed89..8ab2c26 100644
>> --- a/dma-helpers.c
>> +++ b/dma-helpers.c
>> @@ -117,8 +117,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
>> }
>>
>> if (dbs->is_write) {
>> - dbs->acb = bdrv_aio_writev(dbs->bs, dbs->sector_num, &dbs->iov,
>> - dbs->iov.size / 512, dma_bdrv_cb, dbs);
>> + dbs->acb = bdrv_aio_writev_proxy(dbs->bs, dbs->sector_num,
>> &dbs->iov,
>> + dbs->iov.size / 512, dma_bdrv_cb,
>> dbs);
>> } else {
>> dbs->acb = bdrv_aio_readv(dbs->bs, dbs->sector_num, &dbs->iov,
>> dbs->iov.size / 512, dma_bdrv_cb, dbs);
>> --
>> 1.7.1.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[Qemu-devel] Re: [PATCH 05/21] virtio: modify save/load handler to handle inuse varialble.
On Sun, Nov 28, 2010 at 08:27:58PM +0900, Yoshiaki Tamura wrote:
> 2010/11/28 Michael S. Tsirkin :
> > On Thu, Nov 25, 2010 at 03:06:44PM +0900, Yoshiaki Tamura wrote:
> >> Modify inuse type to uint16_t, let save/load to handle, and revert
> >> last_avail_idx with inuse if there are outstanding emulation.
> >>
> >> Signed-off-by: Yoshiaki Tamura
> >
> > This changes migration format, so it will break compatibility with
> > existing drivers. More generally, I think migrating internal
> > state that is not guest visible is always a mistake
> > as it ties migration format to an internal implementation
> > (yes, I know we do this sometimes, but we should at least
> > try not to add such cases). I think the right thing to do in this case
> > is to flush outstanding
> > work when vm is stopped. Then, we are guaranteed that inuse is 0.
> > I sent patches that do this for virtio net and block.
>
> Could you give me the link of your patches? I'd like to test
> whether they work with Kemari upon failover. If they do, I'm
> happy to drop this patch.
>
> Yoshi
Look for this:
stable migration image on a stopped vm
sent on:
Wed, 24 Nov 2010 17:52:49 +0200
> >
> >> ---
> >> hw/virtio.c | 8 +++-
> >> 1 files changed, 7 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/hw/virtio.c b/hw/virtio.c
> >> index 849a60f..5509644 100644
> >> --- a/hw/virtio.c
> >> +++ b/hw/virtio.c
> >> @@ -72,7 +72,7 @@ struct VirtQueue
> >> VRing vring;
> >> target_phys_addr_t pa;
> >> uint16_t last_avail_idx;
> >> - int inuse;
> >> + uint16_t inuse;
> >> uint16_t vector;
> >> void (*handle_output)(VirtIODevice *vdev, VirtQueue *vq);
> >> VirtIODevice *vdev;
> >> @@ -671,6 +671,7 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f)
> >> qemu_put_be32(f, vdev->vq[i].vring.num);
> >> qemu_put_be64(f, vdev->vq[i].pa);
> >> qemu_put_be16s(f, &vdev->vq[i].last_avail_idx);
> >> + qemu_put_be16s(f, &vdev->vq[i].inuse);
> >> if (vdev->binding->save_queue)
> >> vdev->binding->save_queue(vdev->binding_opaque, i, f);
> >> }
> >> @@ -711,6 +712,11 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f)
> >> vdev->vq[i].vring.num = qemu_get_be32(f);
> >> vdev->vq[i].pa = qemu_get_be64(f);
> >> qemu_get_be16s(f, &vdev->vq[i].last_avail_idx);
> >> + qemu_get_be16s(f, &vdev->vq[i].inuse);
> >> +
> >> + /* revert last_avail_idx if there are outstanding emulation. */
> >> + vdev->vq[i].last_avail_idx -= vdev->vq[i].inuse;
> >> + vdev->vq[i].inuse = 0;
> >>
> >> if (vdev->vq[i].pa) {
> >> virtqueue_init(&vdev->vq[i]);
> >> --
> >> 1.7.1.2
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
[Qemu-devel] Re: [PATCH 15/21] virtio-net: replace qemu_sendv_packet_async() with qemu_sendv_packet_async_proxy().
2010/11/28 Michael S. Tsirkin :
> On Thu, Nov 25, 2010 at 03:06:54PM +0900, Yoshiaki Tamura wrote:
>> Replace replace qemu_sendv_packet_async() with
>> qemu_sendv_packet_async_proxy() to let event-tap capture events from
>> virtio-net.
>>
>> Signed-off-by: Yoshiaki Tamura
>
> Why does every device need to know about eent tap?
> Can qemu_sendv_packet_async just do the right thing instead?
If we let net layer notify event-tap, devices don't have to know
about event-tap. Most people want to go to that direction, and I
would follow it in the next spin.
Yoshi
>
>> ---
>> hw/virtio-net.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
>> index 1d61f19..8c76346 100644
>> --- a/hw/virtio-net.c
>> +++ b/hw/virtio-net.c
>> @@ -710,8 +710,8 @@ static int32_t virtio_net_flush_tx(VirtIONet *n,
>> VirtQueue *vq)
>> len += hdr_len;
>> }
>>
>> - ret = qemu_sendv_packet_async(&n->nic->nc, out_sg, out_num,
>> - virtio_net_tx_complete);
>> + ret = qemu_sendv_packet_async_proxy(&n->nic->nc, out_sg, out_num,
>> + virtio_net_tx_complete);
>> if (ret == 0) {
>> virtio_queue_set_notification(n->tx_vq, 0);
>> n->async_tx.elem = elem;
>> --
>> 1.7.1.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[Qemu-devel] Re: [PATCH 05/21] virtio: modify save/load handler to handle inuse varialble.
2010/11/28 Michael S. Tsirkin :
> On Thu, Nov 25, 2010 at 03:06:44PM +0900, Yoshiaki Tamura wrote:
>> Modify inuse type to uint16_t, let save/load to handle, and revert
>> last_avail_idx with inuse if there are outstanding emulation.
>>
>> Signed-off-by: Yoshiaki Tamura
>
> This changes migration format, so it will break compatibility with
> existing drivers. More generally, I think migrating internal
> state that is not guest visible is always a mistake
> as it ties migration format to an internal implementation
> (yes, I know we do this sometimes, but we should at least
> try not to add such cases). I think the right thing to do in this case
> is to flush outstanding
> work when vm is stopped. Then, we are guaranteed that inuse is 0.
> I sent patches that do this for virtio net and block.
Could you give me the link of your patches? I'd like to test
whether they work with Kemari upon failover. If they do, I'm
happy to drop this patch.
Yoshi
>
>> ---
>> hw/virtio.c | 8 +++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/virtio.c b/hw/virtio.c
>> index 849a60f..5509644 100644
>> --- a/hw/virtio.c
>> +++ b/hw/virtio.c
>> @@ -72,7 +72,7 @@ struct VirtQueue
>> VRing vring;
>> target_phys_addr_t pa;
>> uint16_t last_avail_idx;
>> - int inuse;
>> + uint16_t inuse;
>> uint16_t vector;
>> void (*handle_output)(VirtIODevice *vdev, VirtQueue *vq);
>> VirtIODevice *vdev;
>> @@ -671,6 +671,7 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f)
>> qemu_put_be32(f, vdev->vq[i].vring.num);
>> qemu_put_be64(f, vdev->vq[i].pa);
>> qemu_put_be16s(f, &vdev->vq[i].last_avail_idx);
>> + qemu_put_be16s(f, &vdev->vq[i].inuse);
>> if (vdev->binding->save_queue)
>> vdev->binding->save_queue(vdev->binding_opaque, i, f);
>> }
>> @@ -711,6 +712,11 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f)
>> vdev->vq[i].vring.num = qemu_get_be32(f);
>> vdev->vq[i].pa = qemu_get_be64(f);
>> qemu_get_be16s(f, &vdev->vq[i].last_avail_idx);
>> + qemu_get_be16s(f, &vdev->vq[i].inuse);
>> +
>> + /* revert last_avail_idx if there are outstanding emulation. */
>> + vdev->vq[i].last_avail_idx -= vdev->vq[i].inuse;
>> + vdev->vq[i].inuse = 0;
>>
>> if (vdev->vq[i].pa) {
>> virtqueue_init(&vdev->vq[i]);
>> --
>> 1.7.1.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [Qemu-devel] [Bug 668799] Re: qemu-arm segfaults executing msgmerge (gettext)
2010/11/28 Brian Harring : > Additional note... it *looks* like the deadlock potential is there > already in 0.13, it's just heavily exacerbated by this patch- out of > about 600 builds I've seen 2 lockup in the same fashion (rate was far > higher with the patch on this ticket). Thanks for the testing. I had a nasty feeling this wouldn't be the only problem, which is why I didn't propose that patch as a real fix. (I think that running multithreaded programs under user-mode emulation is effectively hitting a lot of the same locking issues that you would get for emulating an MP core in multiple threads.) -- PMM
[Qemu-devel] [Bug 682326] [NEW] linux-user/mmap exhaustion
Public bug reported: Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page. The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range. Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging. Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of). This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me. ** Affects: qemu Importance: Undecided Status: New -- linux-user/mmap exhaustion https://bugs.launchpad.net/bugs/682326 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page. The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range. Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging. Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of). This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me.
[Qemu-devel] [Bug 682326] Re: linux-user/mmap exhaustion
** Attachment added: "0001-try-to-reuse-recently-freed-mmap-space-to-reduce-gue.patch" https://bugs.launchpad.net/bugs/682326/+attachment/1747588/+files/0001-try-to-reuse-recently-freed-mmap-space-to-reduce-gue.patch -- linux-user/mmap exhaustion https://bugs.launchpad.net/bugs/682326 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page. The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range. Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging. Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of). This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me.
Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio
On 28.11.2010, at 09:12, Gleb Natapov wrote: > On Thu, Nov 25, 2010 at 08:35:41AM +0100, Alexander Graf wrote: >> The way we're currently modeling mmio is too simplified. We assume that >> every device has the same endianness as the target CPU. In reality, >> most devices are little endian (all PCI and ISA ones I'm aware of). Some >> are big endian (special system devices) and a very little fraction is >> target native endian (fw_cfg). >> > As far as I can see fw_cfg calls cpu_to_le() on some of entries and > doesn't on others. Doesn't this makes it "mixed endian" (aka broken)? There are two layers of brokenness: 1) MMIO 2) Internal structures A device that assumes native target endianness for its own MMIO is usually broken. Devices don't know which CPU they're plugged to (unless built inside of course) :). That specific issue is that fw_cfg_mem_writew directly takes the selector as is and both openbios and seabios expect it to accept values in native endianness. The way forward to fix this is probably to declare the selector as little endian and just commit a new version of openbios. Its internal structures are a different story. If the interface spec of fw_cfg (basically the .c file atm) defines some values to be a different endianness from the other, that might be acceptable. It's still unpretty though. I'd way prefer to see everything aligned to a single endianness. Alex
Re: [Qemu-devel] CFP: 1st International QEMU Users Forum
Frederic, On 28.11.2010, at 09:20, Frédéric Pétrot wrote: > Hi there, > > IMHO someone from code sourcery would be great, as they (Paul Brooks in the > older versions, it seems that Nathan is now taking over) are contributing > most of the ARM emulation stuff. > We may also have both talks organized one after the other covering both > topics, but then Wolfgang and I have to see how to fit into the time and > financial envelops (we can only pay the entrance fee for one people). > This is now a choice to be made by the qemu-devel people. > Please try to converge fast, so that we are in time for the DATE booklet. _Please_ don't top post. It's considered very rude. Write your replies inline below the others'. That's what everybody else is doing too. I agree that Nathan would be a very good fit. > > Bye, > Fred > > PS: We have indeed ourselves worked on the acceleration of the neon support >(neon on mmx/sse instead of helpers), but seing that the QEmu community is >now really kvm oriented (not a criticism, I use virtual box very often and >we also use kvm in other contexts), we didn't really know how to proceed >to commit partial additions. Please don't make the same mistake some other community members make. Without the virtualization folks, qemu would probably be as active as bochs these days (read: dead). Having this huge amount of people actually work on the code base helps qemu in general IMHO. The problem we're facing is that we have too few people actually working on the emulation side, not that too many are working on virtualization issues. So overall, I don't know of too many "virtualization folks" who are hostile or opponent towards the emulation side of qemu. Quite the contrary. It's been very helpful at times. The lack of contributions and maintainers for the emulation side is really the fundamental issue. And organizing a conference to tackle that one is a very good idea :). Alex
Re: Windows host support [was: Re: [Qemu-devel] CFP: 1st International QEMU Users Forum]
On 28.11.2010, at 01:17, Nathan Froyd wrote: > On Fri, Nov 26, 2010 at 01:26:31AM +0100, François Revol wrote: the people we are addressing and we would like to bring together is from the QEMU emulation community. We are interested in running different ISAs mainly under Linux and Windows versions. There is a huge additional >>> >>> You're about the first person in 1/2 year that actually said you >>> care about Windows hosts. Windows support for example is currently >>> on the verge of getting deprecated, because we're lacking a >>> maintainer. >> >> I suppose windows users are not as much used/interested/involved into >> free software development workflows, and probably don't bother even >> lurking on the developer mailing lists. They only shout when something >> breaks :p > > We (CodeSourcery) are very interested in Windows host support. (We > distribute QEMU with our commerical development products for > ARM/PowerPC/MIPS/SH/ColdFire/x86.) Unfortunately, we've mostly been > backporting patches lately and haven't done a full merge from upstream > in some time, so we haven't noticed any potential breakage. If somebody > wanted to point out to me what the (potential) Windows issues are, we > could take a look. Redirecting you to Anthony here for the specifics. The main problem is that we don't have anyone who takes the lead on Windows support. _If_ something breaks of _if_ we need someone to take over the windows specific parts, there's this huge gap. So if you're willing to play that role, please send a patch to the MAINTAINERS file and add yourself :) Btw Anthony, what happened to the really well done MAINTAINERS file overhaul? Alex
Re: [Qemu-devel] CFP: 1st International QEMU Users Forum
On 28.11.2010, at 01:09, Nathan Froyd wrote: > On Sat, Nov 27, 2010 at 11:26:05PM +0100, Alexander Graf wrote: >> On 27.11.2010, at 20:00, Peter Maydell wrote: >>> On 26 November 2010 16:34, wolfgang mueller wrote: In this case is it possible to do the introductionary talk of the workshop with a QEMU overview. People are here interested in QEMU CPU (and evtl. device) emulation. Most of the attending people from industry (!) and universities will have ARM background/interests. >>> >>> Thanks, but really I feel like I'm just getting started with QEMU >>> development myself, so I'm not sure I would be the best person >>> to give a talk like that. I'm sure there's somebody else on the >>> mailing list who would be better suited. >> >> My offer stands. If we don't find anyone else, I'll jump in. Generic >> qemu stuff I can always talk about ;) > > I would be happy to come and give an overview talk. I don't know that > our process for getting in patches that are non-x86+virtualization > related are really that good, but perhaps we can have a discussion about > that so that we have a better story to tell by March. :) That sounds like a very good solution, yes :). Just join our weekly "community conference call" and we can tell you everything you need to know to give a good overview :). Alex
Re: [Qemu-devel] [PATCH 1/6] usb-ccid: add CCID bus
On Fri, Nov 26, 2010 at 07:05:02PM +, Blue Swirl wrote:
> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote:
> > A CCID device is a smart card reader. It is a USB device, defined at [1].
> > This patch introduces the usb-ccid device that is a ccid bus. Next patches
> > will
> > introduce two card types to use it, a passthru card and an emulated card.
> >
> > [1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.
> >
> > Signed-off-by: Alon Levy
> > ---
> > Makefile.objs | 1 +
> > configure | 12 +
> > hw/ccid.h | 34 ++
> > hw/usb-ccid.c | 1342
> > +
> > 4 files changed, 1389 insertions(+), 0 deletions(-)
> > create mode 100644 hw/ccid.h
> > create mode 100644 hw/usb-ccid.c
> >
> > diff --git a/Makefile.objs b/Makefile.objs
> > index 23b17ce..713131f 100644
> > --- a/Makefile.objs
> > +++ b/Makefile.objs
> > @@ -183,6 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
> > hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
> > hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
> > hw-obj-$(CONFIG_DMA) += dma.o
> > +hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
> >
> > # PPC devices
> > hw-obj-$(CONFIG_OPENPIC) += openpic.o
> > diff --git a/configure b/configure
> > index 2917874..fb9eac2 100755
> > --- a/configure
> > +++ b/configure
> > @@ -332,6 +332,7 @@ zero_malloc=""
> > trace_backend="nop"
> > trace_file="trace"
> > spice=""
> > +smartcard="no"
> >
> > # OS specific
> > if check_define __linux__ ; then
> > @@ -739,6 +740,10 @@ for opt do
> > ;;
> > --enable-vhost-net) vhost_net="yes"
> > ;;
> > + --disable-smartcard) smartcard="no"
> > + ;;
> > + --enable-smartcard) smartcard="yes"
> > + ;;
> > --*dir)
> > ;;
> > *) echo "ERROR: unknown option $opt"; show_help="yes"
> > @@ -934,6 +939,8 @@ echo " --trace-file=NAME Full PATH,NAME of file
> > to store traces"
> > echo " Default:trace-"
> > echo " --disable-spice disable spice"
> > echo " --enable-spice enable spice"
> > +echo " --disable-smartcard disable smartcard support"
> > +echo " --enable-smartcard enable smartcard support"
> > echo ""
> > echo "NOTE: The object files are built at the place where configure is
> > launched"
> > exit 1
> > @@ -2354,6 +2361,7 @@ echo "vhost-net support $vhost_net"
> > echo "Trace backend $trace_backend"
> > echo "Trace output file $trace_file-"
> > echo "spice support $spice"
> > +echo "smartcard support $smartcard"
> >
> > if test $sdl_too_old = "yes"; then
> > echo "-> Your SDL version is too old - please upgrade to have SDL support"
> > @@ -2617,6 +2625,10 @@ if test "$spice" = "yes" ; then
> > echo "CONFIG_SPICE=y" >> $config_host_mak
> > fi
> >
> > +if test "$smartcard" = "yes" ; then
> > + echo "CONFIG_SMARTCARD=y" >> $config_host_mak
> > +fi
> > +
> > # XXX: suppress that
> > if [ "$bsd" = "yes" ] ; then
> > echo "CONFIG_BSD=y" >> $config_host_mak
> > diff --git a/hw/ccid.h b/hw/ccid.h
> > new file mode 100644
> > index 000..a38f971
> > --- /dev/null
> > +++ b/hw/ccid.h
> > @@ -0,0 +1,34 @@
> > +#ifndef __CCID_H__
> > +#define __CCID_H__
> > +
> > +#include "qdev.h"
> > +
> > +typedef struct CCIDCardState CCIDCardState;
> > +typedef struct CCIDCardInfo CCIDCardInfo;
> > +
> > +struct CCIDCardState {
> > + DeviceState qdev;
> > +};
> > +
> > +struct CCIDCardInfo {
> > + DeviceInfo qdev;
> > + void (*print)(Monitor *mon, CCIDCardState *card, int indent);
> > + const uint8_t *(*get_atr)(CCIDCardState *card, uint32_t *len);
> > + void (*apdu_from_guest)(CCIDCardState *card, const uint8_t *apdu,
> > uint32_t len);
> > + int (*exitfn)(CCIDCardState *card);
> > + int (*initfn)(CCIDCardState *card);
> > +};
> > +
> > +void ccid_card_send_apdu_to_guest(CCIDCardState *card, uint8_t* apdu,
> > uint32_t len);
> > +void ccid_card_card_removed(CCIDCardState *card);
> > +void ccid_card_card_inserted(CCIDCardState *card);
> > +void ccid_card_card_error(CCIDCardState *card, uint64_t error);
> > +void ccid_card_qdev_register(CCIDCardInfo *card);
> > +
> > +/* support guest visible insertion/removal of ccid devices based on actual
> > + * devices connected/removed. Called by card implementation (passthru,
> > local) */
> > +int ccid_card_ccid_attach(CCIDCardState *card);
> > +void ccid_card_ccid_detach(CCIDCardState *card);
> > +
> > +#endif // __CCID_H__
> > +
> > diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
> > new file mode 100644
> > index 000..66c1dba
> > --- /dev/null
> > +++ b/hw/usb-ccid.c
> > @@ -0,0 +1,1342 @@
> > +/*
> > + * CCID Device emulation
> > + *
> > + * Based on usb-serial.c:
> > + * Copyright (c) 2006 CodeSourcery.
> > + * Copyright (c) 2008 Samuel Thibault
> > + * Written by Paul Brook, reused for FTDI by Samuel Thibault,
> > + * Reused for CCID by Alon Levy.
> > + * Contributed to by Robert Relyea
> > + * Copyright (c) 2010 Red Hat.
> > + *
> > + * This code is licenced under the LGP
[Qemu-devel] [Bug 668799] Re: qemu-arm segfaults executing msgmerge (gettext)
Additional note... it *looks* like the deadlock potential is there already in 0.13, it's just heavily exacerbated by this patch- out of about 600 builds I've seen 2 lockup in the same fashion (rate was far higher with the patch on this ticket). -- qemu-arm segfaults executing msgmerge (gettext) https://bugs.launchpad.net/bugs/668799 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: upstream qemu.git revision b45e9c05dbacba8e992f0bffeca04c6379c3ad45 Starting program: /usr/bin/qemu-arm msgmerge-static ar.po anjuta.pot [Thread debugging using libthread_db enabled] [New Thread 0x74bc3ff0 (LWP 26108)] [New Thread 0x74b8aff0 (LWP 26109)] [New Thread 0x74b51ff0 (LWP 26110)] [New Thread 0x74b18ff0 (LWP 26111)] [New Thread 0x74adfff0 (LWP 26112)] [New Thread 0x74aa6ff0 (LWP 26113)] [New Thread 0x74a6dff0 (LWP 26114)] [New Thread 0x74a34ff0 (LWP 26115)] [New Thread 0x749fbff0 (LWP 26116)] [New Thread 0x749c2ff0 (LWP 26117)] [New Thread 0x74989ff0 (LWP 26118)] [New Thread 0x74950ff0 (LWP 26119)] [New Thread 0x74917ff0 (LWP 26120)] [New Thread 0x748deff0 (LWP 26121)] [New Thread 0x748a5ff0 (LWP 26122)] [New Thread 0x7486cff0 (LWP 26123)] [New Thread 0x74833ff0 (LWP 26124)] [New Thread 0x747faff0 (LWP 26125)] [New Thread 0x747c1ff0 (LWP 26126)] [New Thread 0x74788ff0 (LWP 26127)] [New Thread 0x7474fff0 (LWP 26128)] [New Thread 0x74716ff0 (LWP 26129)] [New Thread 0x746ddff0 (LWP 26130)] . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x74aa6ff0 (LWP 26113)] 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 1333tb1 = tb1->jmp_next[n1]; (gdb) bt #0 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 #1 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63540) at /home/user/git/qemu/exec.c:1361 #2 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c634d8, n=0) at /home/user/git/qemu/exec.c:1355 #3 0x600481c0 in tb_reset_jump_recursive (tb=0x74c634d8) at /home/user/git/qemu/exec.c:1361 #4 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63470, n=0) at /home/user/git/qemu/exec.c:1355 #5 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63470) at /home/user/git/qemu/exec.c:1361 #6 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63408, n=1) at /home/user/git/qemu/exec.c:1355 #7 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63408) at /home/user/git/qemu/exec.c:1362 #8 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c633a0, n=0) at /home/user/git/qemu/exec.c:1355 #9 0x600481c0 in tb_reset_jump_recursive (tb=0x74c633a0) at /home/user/git/qemu/exec.c:1361 #10 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63338, n=0) at /home/user/git/qemu/exec.c:1355 #11 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63338) at /home/user/git/qemu/exec.c:1361 #12 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c632d0, n=0) at /home/user/git/qemu/exec.c:1355 ---Type to continue, or q to quit--- #13 0x600481c0 in tb_reset_jump_recursive (tb=0x74c632d0) at /home/user/git/qemu/exec.c:1361 #14 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63268, n=1) at /home/user/git/qemu/exec.c:1355 #15 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63268) at /home/user/git/qemu/exec.c:1362 #16 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63200, n=0) at /home/user/git/qemu/exec.c:1355 #17 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63200) at /home/user/git/qemu/exec.c:1361 #18 0x600487c5 in cpu_unlink_tb (env=0x62385400) at /home/user/git/qemu/exec.c:1617 #19 0x600488e8 in cpu_exit (env=0x62385400) at /home/user/git/qemu/exec.c:1662 #20 0x6798 in start_exclusive () at /home/user/git/qemu/linux-user/main.c:152 #21 0x6a4b in do_kernel_trap (env=0x62359940) at /home/user/git/qemu/linux-user/main.c:493 #22 0x600023f3 in cpu_loop (env=0x62359940) at /home/user/git/qemu/linux-user/main.c:797 #23 0x600123df in clone_func (arg=0x7ffd76e0) at /home/user/git/qemu/linux-user/syscall.c:3561 #24 0x600b382d in start_thread (arg=) at pthread_create.c:297 #25 0x600f1809 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #26 0x in ?? () (gdb) Its interesting to see this : #0 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 tb1 = 0x0 << tb_next = 0xf4c63610<<<
Re: [Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard
On Sun, Nov 28, 2010 at 09:42:05AM +, Blue Swirl wrote: > On Sun, Nov 28, 2010 at 9:14 AM, Alon Levy wrote: > > On Fri, Nov 26, 2010 at 06:50:07PM +, Blue Swirl wrote: > >> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote: > >> > Signed-off-by: Alon Levy > >> > --- > >> > Makefile | 6 -- > >> > Makefile.objs | 5 + > >> > Makefile.target | 2 ++ > >> > configure | 24 > >> > libcaccard/Makefile | 18 ++ > >> > 5 files changed, 53 insertions(+), 2 deletions(-) > >> > create mode 100644 libcaccard/Makefile > >> > > >> > diff --git a/Makefile b/Makefile > >> > index 4e120a2..e673bf1 100644 > >> > --- a/Makefile > >> > +++ b/Makefile > >> > @@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o > >> > $(CHECK_PROG_DEPS) > >> > check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) > >> > check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o > >> > qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o > >> > $(CHECK_PROG_DEPS) > >> > > >> > +QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard > >> > + > >> > clean: > >> > # avoid old build problems by removing potentially incorrect old files > >> > rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h > >> > opc-arm.h gen-op-arm.h > >> > @@ -183,7 +185,7 @@ clean: > >> > rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp > >> > rm -f trace-dtrace.h trace-dtrace.h-timestamp > >> > $(MAKE) -C tests clean > >> > - for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis > >> > libdis-user; do \ > >> > + for d in $(ALL_SUBDIRS) $(QEMULIBS); do \ > >> > if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ > >> > rm -f $$d/qemu-options.def; \ > >> > done > >> > @@ -194,7 +196,7 @@ distclean: clean > >> > rm -f roms/seabios/config.mak roms/vgabios/config.mak > >> > rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi > >> > qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf > >> > qemu-doc.pg qemu-doc.toc qemu-doc.tp qemu-doc.vr > >> > rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi > >> > qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf > >> > qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr > >> > - for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis > >> > libdis-user; do \ > >> > + for d in $(TARGET_DIRS) $(QEMULIBS); do \ > >> > rm -rf $$d || exit 1 ; \ > >> > done > >> > > >> > diff --git a/Makefile.objs b/Makefile.objs > >> > index 2059e89..82691c0 100644 > >> > --- a/Makefile.objs > >> > +++ b/Makefile.objs > >> > @@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o > >> > endif > >> > endif > >> > > >> > +## > >> > +# smartcard > >> > + > >> > +libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o > >> > vcard_emul_nss.o vcard_emul_type.o card_7816.o > >> > + > >> > vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) > >> > > >> > vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) > >> > diff --git a/Makefile.target b/Makefile.target > >> > index 2800f47..7dd6932 100644 > >> > --- a/Makefile.target > >> > +++ b/Makefile.target > >> > @@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) > >> > > >> > endif # CONFIG_SOFTMMU > >> > > >> > +obj-y += $(addprefix $(SRC_PATH)/libcaccard/, > >> > $(libcaccard-$(CONFIG_SMARTCARD))) > >> > + > >> > obj-y += $(addprefix ../, $(trace-obj-y)) > >> > obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o > >> > > >> > diff --git a/configure b/configure > >> > index fb9eac2..4b55904 100755 > >> > --- a/configure > >> > +++ b/configure > >> > @@ -2130,6 +2130,25 @@ EOF > >> > fi > >> > fi > >> > > >> > +# check for libcaccard for smartcard support > >> > +if test "$smartcard" != "no" ; then > >> > + smartcard_cflags="-I\$(SRC_PATH)/libcaccard" > >> > + smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard" > >> > + libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null) > >> > + libcaccard_cflags=$($pkgconfig --cflags nss) > >> > + # TODO - what's the minimal nss version we support? > >> > + if $pkgconfig --atleast-version=3.12.8 nss; then > >> > + smartcard="yes" > >> > + QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags" > >> > + LIBS="$libcaccard_libs $LIBS" > >> > + else > >> > + if test "smartcard" = "yes" ; then > >> > + feature_not_found "smartcard" > >> > + fi > >> > + smartcard="no" > >> > + fi > >> > +fi > >> > + > >> > ## > >> > > >> > ## > >> > @@ -2956,6 +2975,11 @@ fi > >> > if test "$target_darwin_user" = "yes" ; then > >> > echo "CONFIG_DARWIN_USER=y" >> $config_target_mak > >> > fi > >> > +if test "$smartcard" = "yes" ; then > >> > + echo "subdir-$target: subdir-libcaccard" >> $config_host_mak > >>
Re: [Qemu-devel] [PATCH 1/6] usb-ccid: add CCID bus
On Fri, Nov 26, 2010 at 07:05:02PM +, Blue Swirl wrote:
> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote:
...
> > +/* 6.2.6 RDR_to_PC_SlotStatus definitions */
> > +enum {
> > + CLOCK_STATUS_RUNNING = 0,
> > + /* 0 - Clock Running, 1 - Clock stopped in State L, 2 - H,
> > + 3 - unkonwn state. rest are RFU
> > + */
> > +};
> > +
> > +typedef struct __attribute__ ((__packed__)) {
>
> Please don't use anonymous structs.
>
ok, fixing for v8.
> > + uint8_t bMessageType;
>
> Why aHungarian nNotation? It's not QEMU style.
>
These names are taken directly from the spec
(http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf). I
did it to make searching in the spec easier for anyone reading the source.
> > + uint32_t dwLength;
> > + uint8_t bSlot;
> > + uint8_t bSeq;
> > +} CCID_Header;
>
> Packed structure with unaligned fields. Will this work?
>
Works for x86, same situation for the endianess issue. I'll change it to
unpacked and change the writing to the guest to explicitly copy individual
structs (I'll have to do that for endianess anyway). Should the USB device be
little endian always? so I need to convert any field written to the guest to
little endian, and read from the guest to host endianess?
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_Header hdr;
> > + uint8_t bStatus; /* Only used in BULK_IN */
> > + uint8_t bError; /* Only used in BULK_IN */
> > +} CCID_BULK_IN;
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_BULK_IN b;
> > + uint8_t bClockStatus;
> > +} CCID_SlotStatus;
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_BULK_IN b;
> > + uint8_t bProtocolNum;
> > + uint8_t abProtocolDataStructure[0];
> > +} CCID_Parameter;
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_BULK_IN b;
> > + uint8_t bChainParameter;
> > + uint8_t abData[0];
> > +} CCID_DataBlock;
> > +
> > +/* 6.1.4 PC_to_RDR_XfrBlock */
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_Header hdr;
> > + uint8_t bBWI; /* Block Waiting Timeout */
> > + uint16_t wLevelParameter;
> > + uint8_t abData[0];
> > +} CCID_XferBlock;
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_Header hdr;
> > + uint8_t bPowerSelect;
> > + uint16_t abRFU;
> > +} CCID_IccPowerOn;
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_Header hdr;
> > + uint16_t abRFU;
> > +} CCID_IccPowerOff;
> > +
> > +typedef struct __attribute__ ((__packed__)) {
> > + CCID_Header hdr;
> > + uint8_t bProtocolNum;
> > + uint8_t abProtocolDataStructure[0];
> > +} CCID_SetParameter;
> > +
> > +typedef struct {
> > + uint8_t bMessageType; /*
> > CCID_MESSAGE_TYPE_RDR_to_PC_NotifySlotChange */
> > + uint8_t bmSlotICCState;
> > +} CCID_Notify_Slot_Change;
> > +
> > +/* used for DataBlock response to XferBlock */
> > +typedef struct answer_t {
> > + uint8_t slot;
> > + uint8_t seq;
> > +} answer_t;
> > +
>
> answer_t is not in line with CODING_STYLE.
>
> > +/* pending BULK_IN messages */
> > +typedef struct bulk_in_t {
> > + uint8_t data[BULK_IN_BUF_SIZE];
> > + uint32_t len;
> > + uint32_t pos;
> > +} bulk_in_t;
>
> Neither is this.
>
Fixing both for v8.
> > +
> > +enum {
> > + MIGRATION_NONE,
> > + MIGRATION_MIGRATED,
> > +};
> > +
> > +typedef struct CCIDBus CCIDBus;
> > +typedef struct USBCCIDState USBCCIDState;
> > +
> > +#define MAX_PROTOCOL_SIZE 7
> > +
> > +/**
> > + * powered - defaults to true, changed by PowerOn/PowerOff messages
> > + */
> > +struct USBCCIDState {
> > + USBDevice dev;
> > + CCIDBus *bus;
> > + CCIDCardState *card;
> > + CCIDCardInfo *cardinfo; /* caching the info pointer */
> > + uint8_t debug;
> > + uint8_t auto_attach;
> > + bulk_in_t bulk_in_pending[BULK_IN_PENDING_NUM]; /* circular */
> > + uint32_t bulk_in_pending_start;
> > + uint32_t bulk_in_pending_end; /* first free */
> > + uint32_t bulk_in_pending_num;
> > + bulk_in_t *current_bulk_in;
> > + uint8_t bulk_out_data[BULK_OUT_DATA_SIZE];
> > + uint32_t bulk_out_pos;
> > + uint8_t bmSlotICCState;
> > + uint8_t powered;
> > + uint8_t notify_slot_change;
> > + uint64_t last_answer_error;
> > + answer_t pending_answers[PENDING_ANSWERS_NUM];
> > + uint32_t pending_answers_start;
> > + uint32_t pending_answers_end;
> > + uint32_t pending_answers_num;
> > + uint8_t bError;
> > + uint8_t bmCommandStatus;
> > + uint8_t bProtocolNum;
> > + uint8_t abProtocolDataStructure[MAX_PROTOCOL_SIZE];
> > + uint32_t ulProtocolDataStructureSize;
> > + uint8_t attached_vmstate;
> > + uint32_t state_vmstate;
> > + uint8_t migration_state;
> > + uint32_t migration_target_ip;
> > + uint16_t migration_target_port;
> > +};
> > +
[Qemu-devel] [Bug 668799] Re: qemu-arm segfaults executing msgmerge (gettext)
@Peter, that patch, against 0.13 results in some odd deadlocks; specifically a racey deadlock during signal handling best I can tell. Attached is an strac'ing of the make process- nothing special, just forking off some children, wait'ing on the results- if you look earlier in the log you'll see the fork/wait working fine (look for SIGCHLD delivery), then see the final one go out to lunch waiting on a futex. At this point it takes me about 4-5 runs to trigger it, but it's proving fairly reproducible on the builds I've been attempting- cmake in particular seems to trigger it rather quickly. ** Attachment added: "strac'ing of a random deadlocked make" https://bugs.launchpad.net/qemu/+bug/668799/+attachment/1747565/+files/make-strace.log -- qemu-arm segfaults executing msgmerge (gettext) https://bugs.launchpad.net/bugs/668799 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: upstream qemu.git revision b45e9c05dbacba8e992f0bffeca04c6379c3ad45 Starting program: /usr/bin/qemu-arm msgmerge-static ar.po anjuta.pot [Thread debugging using libthread_db enabled] [New Thread 0x74bc3ff0 (LWP 26108)] [New Thread 0x74b8aff0 (LWP 26109)] [New Thread 0x74b51ff0 (LWP 26110)] [New Thread 0x74b18ff0 (LWP 26111)] [New Thread 0x74adfff0 (LWP 26112)] [New Thread 0x74aa6ff0 (LWP 26113)] [New Thread 0x74a6dff0 (LWP 26114)] [New Thread 0x74a34ff0 (LWP 26115)] [New Thread 0x749fbff0 (LWP 26116)] [New Thread 0x749c2ff0 (LWP 26117)] [New Thread 0x74989ff0 (LWP 26118)] [New Thread 0x74950ff0 (LWP 26119)] [New Thread 0x74917ff0 (LWP 26120)] [New Thread 0x748deff0 (LWP 26121)] [New Thread 0x748a5ff0 (LWP 26122)] [New Thread 0x7486cff0 (LWP 26123)] [New Thread 0x74833ff0 (LWP 26124)] [New Thread 0x747faff0 (LWP 26125)] [New Thread 0x747c1ff0 (LWP 26126)] [New Thread 0x74788ff0 (LWP 26127)] [New Thread 0x7474fff0 (LWP 26128)] [New Thread 0x74716ff0 (LWP 26129)] [New Thread 0x746ddff0 (LWP 26130)] . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x74aa6ff0 (LWP 26113)] 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 1333tb1 = tb1->jmp_next[n1]; (gdb) bt #0 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 #1 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63540) at /home/user/git/qemu/exec.c:1361 #2 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c634d8, n=0) at /home/user/git/qemu/exec.c:1355 #3 0x600481c0 in tb_reset_jump_recursive (tb=0x74c634d8) at /home/user/git/qemu/exec.c:1361 #4 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63470, n=0) at /home/user/git/qemu/exec.c:1355 #5 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63470) at /home/user/git/qemu/exec.c:1361 #6 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63408, n=1) at /home/user/git/qemu/exec.c:1355 #7 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63408) at /home/user/git/qemu/exec.c:1362 #8 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c633a0, n=0) at /home/user/git/qemu/exec.c:1355 #9 0x600481c0 in tb_reset_jump_recursive (tb=0x74c633a0) at /home/user/git/qemu/exec.c:1361 #10 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63338, n=0) at /home/user/git/qemu/exec.c:1355 #11 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63338) at /home/user/git/qemu/exec.c:1361 #12 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c632d0, n=0) at /home/user/git/qemu/exec.c:1355 ---Type to continue, or q to quit--- #13 0x600481c0 in tb_reset_jump_recursive (tb=0x74c632d0) at /home/user/git/qemu/exec.c:1361 #14 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63268, n=1) at /home/user/git/qemu/exec.c:1355 #15 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63268) at /home/user/git/qemu/exec.c:1362 #16 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63200, n=0) at /home/user/git/qemu/exec.c:1355 #17 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63200) at /home/user/git/qemu/exec.c:1361 #18 0x600487c5 in cpu_unlink_tb (env=0x62385400) at /home/user/git/qemu/exec.c:1617 #19 0x600488e8 in cpu_exit (env=0x62385400) at /home/user/git/qemu/exec.c:1662 #20 0x6798 in start_exclusive () at /home/user/git/qemu/linux-user/main.c:152 #21 0x6a4b in do_kernel_trap (env=0x62359940) at /home/user/git/qemu/linux-user/main.c:493 #22 0x600023f3 in cpu_loop (env=0x62359940) at /home/user/git/qemu/linux-user/main.c:797 #23 0x600123df in clone_func (arg=0x7ffd76e0) at /home/user/gi
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 11:38:36AM +0200, Avi Kivity wrote: > On 11/28/2010 09:54 AM, Gleb Natapov wrote: > >On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > >> On 11/23/2010 06:12 PM, Anthony Liguori wrote: > >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > >> >>Anthony, Blue > >> >> > >> >>No comments on this patch series for almost a week. Can it be applied? > >> > > >> >Does that mean everyone's happy or have folks not gotten around to > >> >review it? > >> > > >> >IOW, last call if you have objections :-) > >> > > >> > >> I haven't reviewed this - I trust the author and maintainers to get > >> it right. > >> > >> But I notice the there is no documentation - surely some is needed? > >> > > > >The patch creates Openfirmware device path from qdev > >hierarchy. Each element of a device path depends on type of a bus > >the device resides on. You can find various bus bindings here: > >http://playground.sun.com/1275/bindings/ and main spec is here > >http://forthworks.com/standards/of1275.pdf. Format in which list of > >device paths is passed to firmware is documented by comment (it is very > >simple). The only thing missing is command line option documentation. I > >will add it and resend if no more changes are needed for patch to be > >excepted. > > What about the format of the fwcfg interface? It should be > described, and point to the references above. > As I said above it is described in a comment above get_boot_devices_list(). No pointers to Openfirmware there, will put them above get_fw_dev_path() definition in qdev.h where they belong. -- Gleb.
Re: [Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard
On Sun, Nov 28, 2010 at 9:14 AM, Alon Levy wrote: > On Fri, Nov 26, 2010 at 06:50:07PM +, Blue Swirl wrote: >> On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote: >> > Signed-off-by: Alon Levy >> > --- >> > Makefile | 6 -- >> > Makefile.objs | 5 + >> > Makefile.target | 2 ++ >> > configure | 24 >> > libcaccard/Makefile | 18 ++ >> > 5 files changed, 53 insertions(+), 2 deletions(-) >> > create mode 100644 libcaccard/Makefile >> > >> > diff --git a/Makefile b/Makefile >> > index 4e120a2..e673bf1 100644 >> > --- a/Makefile >> > +++ b/Makefile >> > @@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o >> > $(CHECK_PROG_DEPS) >> > check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) >> > check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o >> > qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o >> > $(CHECK_PROG_DEPS) >> > >> > +QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard >> > + >> > clean: >> > # avoid old build problems by removing potentially incorrect old files >> > rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h >> > opc-arm.h gen-op-arm.h >> > @@ -183,7 +185,7 @@ clean: >> > rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp >> > rm -f trace-dtrace.h trace-dtrace.h-timestamp >> > $(MAKE) -C tests clean >> > - for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis >> > libdis-user; do \ >> > + for d in $(ALL_SUBDIRS) $(QEMULIBS); do \ >> > if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ >> > rm -f $$d/qemu-options.def; \ >> > done >> > @@ -194,7 +196,7 @@ distclean: clean >> > rm -f roms/seabios/config.mak roms/vgabios/config.mak >> > rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi >> > qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf >> > qemu-doc.pg qemu-doc.toc qemu-doc.tp qemu-doc.vr >> > rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi >> > qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf >> > qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr >> > - for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis >> > libdis-user; do \ >> > + for d in $(TARGET_DIRS) $(QEMULIBS); do \ >> > rm -rf $$d || exit 1 ; \ >> > done >> > >> > diff --git a/Makefile.objs b/Makefile.objs >> > index 2059e89..82691c0 100644 >> > --- a/Makefile.objs >> > +++ b/Makefile.objs >> > @@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o >> > endif >> > endif >> > >> > +## >> > +# smartcard >> > + >> > +libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o >> > vcard_emul_nss.o vcard_emul_type.o card_7816.o >> > + >> > vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) >> > >> > vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) >> > diff --git a/Makefile.target b/Makefile.target >> > index 2800f47..7dd6932 100644 >> > --- a/Makefile.target >> > +++ b/Makefile.target >> > @@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) >> > >> > endif # CONFIG_SOFTMMU >> > >> > +obj-y += $(addprefix $(SRC_PATH)/libcaccard/, >> > $(libcaccard-$(CONFIG_SMARTCARD))) >> > + >> > obj-y += $(addprefix ../, $(trace-obj-y)) >> > obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o >> > >> > diff --git a/configure b/configure >> > index fb9eac2..4b55904 100755 >> > --- a/configure >> > +++ b/configure >> > @@ -2130,6 +2130,25 @@ EOF >> > fi >> > fi >> > >> > +# check for libcaccard for smartcard support >> > +if test "$smartcard" != "no" ; then >> > + smartcard_cflags="-I\$(SRC_PATH)/libcaccard" >> > + smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard" >> > + libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null) >> > + libcaccard_cflags=$($pkgconfig --cflags nss) >> > + # TODO - what's the minimal nss version we support? >> > + if $pkgconfig --atleast-version=3.12.8 nss; then >> > + smartcard="yes" >> > + QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags" >> > + LIBS="$libcaccard_libs $LIBS" >> > + else >> > + if test "smartcard" = "yes" ; then >> > + feature_not_found "smartcard" >> > + fi >> > + smartcard="no" >> > + fi >> > +fi >> > + >> > ## >> > >> > ## >> > @@ -2956,6 +2975,11 @@ fi >> > if test "$target_darwin_user" = "yes" ; then >> > echo "CONFIG_DARWIN_USER=y" >> $config_target_mak >> > fi >> > +if test "$smartcard" = "yes" ; then >> > + echo "subdir-$target: subdir-libcaccard" >> $config_host_mak >> > + echo "libcaccard_libs=$libcaccard_libs" >> $config_host_mak >> > + echo "libcaccard_cflags=$libcaccard_cflags" >> $config_host_mak >> > +fi >> > list="" >> > if test ! -z "$gdb_xml_files" ; then >> > for x in $gdb_xml_files; do >> > diff --git a/libcaccard/Makefile b/libcaccard/Makefile >> >
[Qemu-devel] Re: [PATCH 11/21] ioport: insert event_tap_ioport() to ioport_write().
On Thu, Nov 25, 2010 at 03:06:50PM +0900, Yoshiaki Tamura wrote: > Record ioport event to replay it upon failover. > > Signed-off-by: Yoshiaki Tamura Interesting. This will have to be extended to support ioeventfd. Since each eventfd is really just a binary trigger it should be enough to read out the fd state. > --- > ioport.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/ioport.c b/ioport.c > index aa4188a..74aebf5 100644 > --- a/ioport.c > +++ b/ioport.c > @@ -27,6 +27,7 @@ > > #include "ioport.h" > #include "trace.h" > +#include "event-tap.h" > > /***/ > /* IO Port */ > @@ -76,6 +77,7 @@ static void ioport_write(int index, uint32_t address, > uint32_t data) > default_ioport_writel > }; > IOPortWriteFunc *func = ioport_write_table[index][address]; > +event_tap_ioport(index, address, data); > if (!func) > func = default_func[index]; > func(ioport_opaque[address], address, data); > -- > 1.7.1.2 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [PATCHv6 00/16] boot order specification
On 11/28/2010 09:54 AM, Gleb Natapov wrote: On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > >>Anthony, Blue > >> > >>No comments on this patch series for almost a week. Can it be applied? > > > >Does that mean everyone's happy or have folks not gotten around to > >review it? > > > >IOW, last call if you have objections :-) > > > > I haven't reviewed this - I trust the author and maintainers to get > it right. > > But I notice the there is no documentation - surely some is needed? > The patch creates Openfirmware device path from qdev hierarchy. Each element of a device path depends on type of a bus the device resides on. You can find various bus bindings here: http://playground.sun.com/1275/bindings/ and main spec is here http://forthworks.com/standards/of1275.pdf. Format in which list of device paths is passed to firmware is documented by comment (it is very simple). The only thing missing is command line option documentation. I will add it and resend if no more changes are needed for patch to be excepted. What about the format of the fwcfg interface? It should be described, and point to the references above. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 13/21] dma-helpers: replace bdrv_aio_writev() with bdrv_aio_writev_proxy().
On Thu, Nov 25, 2010 at 03:06:52PM +0900, Yoshiaki Tamura wrote:
> Replace bdrv_aio_writev() with bdrv_aio_writev_proxy() to let
> event-tap capture events from dma-helpers.
>
> Signed-off-by: Yoshiaki Tamura
Same comment as -net here: it's not clear when should
a device use bdrv_aio_writev_proxy and when bdrv_aio_writev.
If all devices should just use _proxy, let's
just make bdrv_aio_writev DTRT instead.
> ---
> dma-helpers.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dma-helpers.c b/dma-helpers.c
> index 712ed89..8ab2c26 100644
> --- a/dma-helpers.c
> +++ b/dma-helpers.c
> @@ -117,8 +117,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
> }
>
> if (dbs->is_write) {
> -dbs->acb = bdrv_aio_writev(dbs->bs, dbs->sector_num, &dbs->iov,
> - dbs->iov.size / 512, dma_bdrv_cb, dbs);
> +dbs->acb = bdrv_aio_writev_proxy(dbs->bs, dbs->sector_num, &dbs->iov,
> + dbs->iov.size / 512, dma_bdrv_cb,
> dbs);
> } else {
> dbs->acb = bdrv_aio_readv(dbs->bs, dbs->sector_num, &dbs->iov,
>dbs->iov.size / 512, dma_bdrv_cb, dbs);
> --
> 1.7.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [PATCH 15/21] virtio-net: replace qemu_sendv_packet_async() with qemu_sendv_packet_async_proxy().
On Thu, Nov 25, 2010 at 03:06:54PM +0900, Yoshiaki Tamura wrote:
> Replace replace qemu_sendv_packet_async() with
> qemu_sendv_packet_async_proxy() to let event-tap capture events from
> virtio-net.
>
> Signed-off-by: Yoshiaki Tamura
Why does every device need to know about eent tap?
Can qemu_sendv_packet_async just do the right thing instead?
> ---
> hw/virtio-net.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index 1d61f19..8c76346 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -710,8 +710,8 @@ static int32_t virtio_net_flush_tx(VirtIONet *n,
> VirtQueue *vq)
> len += hdr_len;
> }
>
> -ret = qemu_sendv_packet_async(&n->nic->nc, out_sg, out_num,
> - virtio_net_tx_complete);
> +ret = qemu_sendv_packet_async_proxy(&n->nic->nc, out_sg, out_num,
> +virtio_net_tx_complete);
> if (ret == 0) {
> virtio_queue_set_notification(n->tx_vq, 0);
> n->async_tx.elem = elem;
> --
> 1.7.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [PATCH 05/21] virtio: modify save/load handler to handle inuse varialble.
On Thu, Nov 25, 2010 at 03:06:44PM +0900, Yoshiaki Tamura wrote:
> Modify inuse type to uint16_t, let save/load to handle, and revert
> last_avail_idx with inuse if there are outstanding emulation.
>
> Signed-off-by: Yoshiaki Tamura
This changes migration format, so it will break compatibility with
existing drivers. More generally, I think migrating internal
state that is not guest visible is always a mistake
as it ties migration format to an internal implementation
(yes, I know we do this sometimes, but we should at least
try not to add such cases). I think the right thing to do in this case
is to flush outstanding
work when vm is stopped. Then, we are guaranteed that inuse is 0.
I sent patches that do this for virtio net and block.
> ---
> hw/virtio.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/hw/virtio.c b/hw/virtio.c
> index 849a60f..5509644 100644
> --- a/hw/virtio.c
> +++ b/hw/virtio.c
> @@ -72,7 +72,7 @@ struct VirtQueue
> VRing vring;
> target_phys_addr_t pa;
> uint16_t last_avail_idx;
> -int inuse;
> +uint16_t inuse;
> uint16_t vector;
> void (*handle_output)(VirtIODevice *vdev, VirtQueue *vq);
> VirtIODevice *vdev;
> @@ -671,6 +671,7 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f)
> qemu_put_be32(f, vdev->vq[i].vring.num);
> qemu_put_be64(f, vdev->vq[i].pa);
> qemu_put_be16s(f, &vdev->vq[i].last_avail_idx);
> +qemu_put_be16s(f, &vdev->vq[i].inuse);
> if (vdev->binding->save_queue)
> vdev->binding->save_queue(vdev->binding_opaque, i, f);
> }
> @@ -711,6 +712,11 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f)
> vdev->vq[i].vring.num = qemu_get_be32(f);
> vdev->vq[i].pa = qemu_get_be64(f);
> qemu_get_be16s(f, &vdev->vq[i].last_avail_idx);
> +qemu_get_be16s(f, &vdev->vq[i].inuse);
> +
> +/* revert last_avail_idx if there are outstanding emulation. */
> +vdev->vq[i].last_avail_idx -= vdev->vq[i].inuse;
> +vdev->vq[i].inuse = 0;
>
> if (vdev->vq[i].pa) {
> virtqueue_init(&vdev->vq[i]);
> --
> 1.7.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard
On Fri, Nov 26, 2010 at 06:50:07PM +, Blue Swirl wrote: > On Thu, Nov 25, 2010 at 4:22 PM, Alon Levy wrote: > > Signed-off-by: Alon Levy > > --- > > Makefile | 6 -- > > Makefile.objs | 5 + > > Makefile.target | 2 ++ > > configure | 24 > > libcaccard/Makefile | 18 ++ > > 5 files changed, 53 insertions(+), 2 deletions(-) > > create mode 100644 libcaccard/Makefile > > > > diff --git a/Makefile b/Makefile > > index 4e120a2..e673bf1 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o > > $(CHECK_PROG_DEPS) > > check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) > > check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o > > qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o > > $(CHECK_PROG_DEPS) > > > > +QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard > > + > > clean: > > # avoid old build problems by removing potentially incorrect old files > > rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h > > opc-arm.h gen-op-arm.h > > @@ -183,7 +185,7 @@ clean: > > rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp > > rm -f trace-dtrace.h trace-dtrace.h-timestamp > > $(MAKE) -C tests clean > > - for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis libdis-user; > > do \ > > + for d in $(ALL_SUBDIRS) $(QEMULIBS); do \ > > if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ > > rm -f $$d/qemu-options.def; \ > > done > > @@ -194,7 +196,7 @@ distclean: clean > > rm -f roms/seabios/config.mak roms/vgabios/config.mak > > rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi > > qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf qemu-doc.pg > > qemu-doc.toc qemu-doc.tp qemu-doc.vr > > rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi > > qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf > > qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr > > - for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis libdis-user; > > do \ > > + for d in $(TARGET_DIRS) $(QEMULIBS); do \ > > rm -rf $$d || exit 1 ; \ > > done > > > > diff --git a/Makefile.objs b/Makefile.objs > > index 2059e89..82691c0 100644 > > --- a/Makefile.objs > > +++ b/Makefile.objs > > @@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o > > endif > > endif > > > > +## > > +# smartcard > > + > > +libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o vcard_emul_nss.o > > vcard_emul_type.o card_7816.o > > + > > vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) > > > > vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) > > diff --git a/Makefile.target b/Makefile.target > > index 2800f47..7dd6932 100644 > > --- a/Makefile.target > > +++ b/Makefile.target > > @@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) > > > > endif # CONFIG_SOFTMMU > > > > +obj-y += $(addprefix $(SRC_PATH)/libcaccard/, > > $(libcaccard-$(CONFIG_SMARTCARD))) > > + > > obj-y += $(addprefix ../, $(trace-obj-y)) > > obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o > > > > diff --git a/configure b/configure > > index fb9eac2..4b55904 100755 > > --- a/configure > > +++ b/configure > > @@ -2130,6 +2130,25 @@ EOF > > fi > > fi > > > > +# check for libcaccard for smartcard support > > +if test "$smartcard" != "no" ; then > > + smartcard_cflags="-I\$(SRC_PATH)/libcaccard" > > + smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard" > > + libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null) > > + libcaccard_cflags=$($pkgconfig --cflags nss) > > + # TODO - what's the minimal nss version we support? > > + if $pkgconfig --atleast-version=3.12.8 nss; then > > + smartcard="yes" > > + QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags" > > + LIBS="$libcaccard_libs $LIBS" > > + else > > + if test "smartcard" = "yes" ; then > > + feature_not_found "smartcard" > > + fi > > + smartcard="no" > > + fi > > +fi > > + > > ## > > > > ## > > @@ -2956,6 +2975,11 @@ fi > > if test "$target_darwin_user" = "yes" ; then > > echo "CONFIG_DARWIN_USER=y" >> $config_target_mak > > fi > > +if test "$smartcard" = "yes" ; then > > + echo "subdir-$target: subdir-libcaccard" >> $config_host_mak > > + echo "libcaccard_libs=$libcaccard_libs" >> $config_host_mak > > + echo "libcaccard_cflags=$libcaccard_cflags" >> $config_host_mak > > +fi > > list="" > > if test ! -z "$gdb_xml_files" ; then > > for x in $gdb_xml_files; do > > diff --git a/libcaccard/Makefile b/libcaccard/Makefile > > new file mode 100644 > > index 000..a339af1 > > --- /dev/null > > +++ b/libcaccard/Makefile > > @@ -0,0 +1,18 @@ > > +include ../Makefile.objs > > +include ../config-host.mak >
Re: [Qemu-devel] CFP: 1st International QEMU Users Forum
Hi there, IMHO someone from code sourcery would be great, as they (Paul Brooks in the older versions, it seems that Nathan is now taking over) are contributing most of the ARM emulation stuff. We may also have both talks organized one after the other covering both topics, but then Wolfgang and I have to see how to fit into the time and financial envelops (we can only pay the entrance fee for one people). This is now a choice to be made by the qemu-devel people. Please try to converge fast, so that we are in time for the DATE booklet. Bye, Fred PS: We have indeed ourselves worked on the acceleration of the neon support (neon on mmx/sse instead of helpers), but seing that the QEmu community is now really kvm oriented (not a criticism, I use virtual box very often and we also use kvm in other contexts), we didn't really know how to proceed to commit partial additions. Nathan Froyd a écrit : > On Sat, Nov 27, 2010 at 11:26:05PM +0100, Alexander Graf wrote: >> On 27.11.2010, at 20:00, Peter Maydell wrote: >>> On 26 November 2010 16:34, wolfgang mueller wrote: In this case is it possible to do the introductionary talk of the workshop with a QEMU overview. People are here interested in QEMU CPU (and evtl. device) emulation. Most of the attending people from industry (!) and universities will have ARM background/interests. >>> Thanks, but really I feel like I'm just getting started with QEMU >>> development myself, so I'm not sure I would be the best person >>> to give a talk like that. I'm sure there's somebody else on the >>> mailing list who would be better suited. >> My offer stands. If we don't find anyone else, I'll jump in. Generic >> qemu stuff I can always talk about ;) > > I would be happy to come and give an overview talk. I don't know that > our process for getting in patches that are non-x86+virtualization > related are really that good, but perhaps we can have a discussion about > that so that we have a better story to tell by March. :) > > -Nathan > -- +-+ | Frédéric Pétrot, Pr. ENSIMAG-TIMA/SLS frederic.pet...@imag.fr | | Phone : +33 4 76 57 48 70 Fluctuat nec mergitur | | Mobile: +33 6 74 57 99 65 Ad augusta per angusta | | Fax : +33 4 76 57 49 81 Eppur si muove | +-+
Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio
On Thu, Nov 25, 2010 at 08:35:41AM +0100, Alexander Graf wrote: > The way we're currently modeling mmio is too simplified. We assume that > every device has the same endianness as the target CPU. In reality, > most devices are little endian (all PCI and ISA ones I'm aware of). Some > are big endian (special system devices) and a very little fraction is > target native endian (fw_cfg). > As far as I can see fw_cfg calls cpu_to_le() on some of entries and doesn't on others. Doesn't this makes it "mixed endian" (aka broken)? -- Gleb.
[Qemu-devel] Re: [PATCH] vhost: Fix address calculation in vhost_dev_sync_region()
On Sat, Nov 27, 2010 at 10:05:07PM +0800, Jason Wang wrote:
> We still need advance address even we find there's no dirty pages in
> current chunk.
>
> Signed-off-by: Jason Wang
> ---
> hw/vhost.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks!
> diff --git a/hw/vhost.c b/hw/vhost.c
> index 8586f66..6082da2 100644
> --- a/hw/vhost.c
> +++ b/hw/vhost.c
> @@ -37,6 +37,7 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
> /* We first check with non-atomic: much cheaper,
> * and we expect non-dirty to be the common case. */
> if (!*from) {
> +addr += VHOST_LOG_CHUNK;
> continue;
> }
> /* Data must be read atomically. We don't really
