[Qemu-devel] Supporting emulation of IOMMUs
A few months ago, Eduard - Gabriel Munteanu posted a series of patches
implementing support for emulating the AMD PCI IOMMU
(http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg03196.html).
In fact, this series implemented a general DMA/IOMMU layer which can
be used by any device model, and one translation backend for this
implementing the AMD specific PCI IOMMU.
These patches don't seem to have gone anywhere for the last few
months, however, and so far I've been unable to contact the author
(trying again with this mail).
I have an interest in this code, because the pSeries machine will also
need IOMMU emulation support. At present we only support virtual
devices, through the PAPR interface, and we have support for the
hypervisor-controller IOMMU translation in the PAPR VIO code.
However, we want to add PCI device support and this will also need
IOMMU translation.
The series seems to have the right basic approach, so if the author is
indeed MIA, I was planning to pick up the patches and resubmit them
(with support for the pSeries IOMMU added).
Before I do that, I was hoping to get some consensus that this is the
right way to go. For reference, I have an updated version of the
first patch (which adds the core IOMMU layer) below.
From: Eduard - Gabriel Munteanu
Date: Fri, 4 Feb 2011 01:32:55 +0200
Subject: [PATCH] Generic DMA memory access interface
This introduces replacements for memory access functions like
cpu_physical_memory_read(). The new interface can handle address
translation and access checking through an IOMMU.
David Gibson: I have made several bugfixes and cleanups to Eduard's
original patch.
* dma_memory_rw() was incorrectly using (uninitialized) plen instead
of len in the fallback to no-IOMMU case.
* the dma_memory_map() tracking was storing the guest physical
address of each mapping, but not the qemu user virtual address.
However in unmap() it was then attempting to lookup by virtual
using a completely bogus cast.
* The dma_memory_rw() function is moved from dma_rw.h to dma_rw.c, it
was a bit too much code for an inline.
* IOMMU support is now available on all target platforms, not just
i386, but is configurable (--enable-iommu/--disable-iommu). Stubs
are used so that individual drivers can use the new dma interface
and it will turn into old-style cpu physical accesses at no cost on
IOMMU-less builds.
Signed-off-by: Eduard - Gabriel Munteanu
Signed-off-by: David Gibson
---
Makefile.target |1 +
configure | 12
hw/dma_rw.c | 147 +++
hw/dma_rw.h | 156 +++
4 files changed, 316 insertions(+), 0 deletions(-)
create mode 100644 hw/dma_rw.c
create mode 100644 hw/dma_rw.h
diff --git a/Makefile.target b/Makefile.target
index 95f5eda..c3d36c6 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -198,6 +198,7 @@ obj-$(CONFIG_REALLY_VIRTFS) += virtio-9p.o
obj-y += rwhandler.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_NO_KVM) += kvm-stub.o
+obj-$(CONFIG_IOMMU) += dma_rw.o
LIBS+=-lz
QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
diff --git a/configure b/configure
index da2da04..fa6f4d5 100755
--- a/configure
+++ b/configure
@@ -130,6 +130,7 @@ xen=""
linux_aio=""
attr=""
vhost_net=""
+iommu="no"
xfs=""
gprof="no"
@@ -723,6 +724,10 @@ for opt do
;;
--enable-vhost-net) vhost_net="yes"
;;
+ --enable-iommu) iommu="yes"
+ ;;
+ --disable-iommu) iommu="no"
+ ;;
--disable-opengl) opengl="no"
;;
--enable-opengl) opengl="yes"
@@ -934,6 +939,8 @@ echo " --enable-docsenable documentation build"
echo " --disable-docs disable documentation build"
echo " --disable-vhost-net disable vhost-net acceleration support"
echo " --enable-vhost-net enable vhost-net acceleration support"
+echo " --disable-iommu disable IOMMU emulation support"
+echo " --enable-vhost-net enable IOMMU emulation support"
echo " --enable-trace-backend=B Set trace backend"
echo " Available backends:"
$("$source_path"/scripts/tracetool --list-backends)
echo " --with-trace-file=NAME Full PATH,NAME of file to store traces"
@@ -2608,6 +2615,7 @@ echo "madvise $madvise"
echo "posix_madvise $posix_madvise"
echo "uuid support $uuid"
echo "vhost-net support $vhost_net"
+echo "IOMMU support $iommu"
echo "Trace backend $trace_backend"
echo "Trace output file $trace_file-"
echo "spice support $spice"
@@ -3412,6 +3420,10 @@ if test "$target_softmmu" = "yes" -a \( \
echo "CONFIG_NEED_MMU=y" >> $config_target_mak
fi
+if test "$iommu" = "yes" ; then
+ echo "CONFIG_IOMMU=y" >> $config_target_mak
+fi
+
if test "$gprof" = "yes" ; then
echo "TARGET_GPROF=yes" >> $config_target_mak
if test "$target_linux_user" = "yes" ; then
diff --git a/hw/dma_rw.c b/hw/dma_rw.c
new file mode 100644
index 000..627835c
--- /dev/n
Re: [Qemu-devel] How to use qemu-kvm with Fedora15-beta gnome3 (better vga driver ?)
On 04/21/2011 05:40 AM, Cheng Renquan wrote: I'm trying to use qemu-kvm to run Fedora15-beta with gnome3, but it told me graphics hardware failed to run gnome3 specific features and it fallback to gnome2; Sorry, none of the cards provided by KVM (including the SPICE-specific QXL card) currently provide the 3D acceleration abilities required by GNOME 3. Paolo
Re: [Qemu-devel] QEMU-KVM and hardened (GRSEC/PaX) kernel
On 04/20/2011 07:47 PM, Антон Кочков wrote: Yes. first thing working ok. And second fails. I'm using Intel iCore 7 (see attached dmesg output and kernel config - host dmesg and host config) Also, as this is probably kernel-kvm module bug, i'm open https://bugzilla.kernel.org/show_bug.cgi?id=33762 It's impossible to fix it since grsec/pax is not usptream. Please close it. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v2 3/5] ide/atapi: Use table instead of switch for commands
Am 20.04.2011 20:13, schrieb Blue Swirl:
> On Wed, Apr 20, 2011 at 2:30 PM, Kevin Wolf wrote:
>> Signed-off-by: Kevin Wolf
>> ---
>> hw/ide/atapi.c | 115
>> +++
>> 1 files changed, 48 insertions(+), 67 deletions(-)
>>
>> diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
>> index d161bf7..d0bf7fd 100644
>> --- a/hw/ide/atapi.c
>> +++ b/hw/ide/atapi.c
>> @@ -533,10 +533,11 @@ static unsigned int event_status_media(IDEState *s,
>> return 8; /* We wrote to 4 extra bytes from the header */
>> }
>>
>> -static void handle_get_event_status_notification(IDEState *s,
>> - uint8_t *buf,
>> - const uint8_t *packet)
>> +static void cmd_get_event_status_notification(IDEState *s,
>> + uint8_t *buf)
>> {
>> +const uint8_t *packet = buf;
>> +
>> struct {
>> uint8_t opcode;
>> uint8_t polled;/* lsb bit is polled; others are reserved */
>> @@ -1064,6 +1065,38 @@ static void cmd_set_speed(IDEState *s, uint8_t* buf)
>> ide_atapi_cmd_ok(s);
>> }
>>
>> +enum {
>> +/*
>> + * Only commands flagged as ALLOW_UA are allowed to run under a
>> + * unit attention condition. (See MMC-5, section 4.1.6.1)
>> + */
>> +ALLOW_UA = 0x01,
>> +};
>> +
>> +struct {
>> +void (*handler)(IDEState *s, uint8_t *buf);
>> +int flags;
>> +} atapi_cmd_table[0x100] = {
>> +[ 0x00 ] = { cmd_test_unit_ready, 0 },
>
> How about using symbols here, like
> [ GPCMD_TEST_UNIT_READY ] = { cmd_test_unit_ready, 0 },
> ?
I avoided symbols intentionally. In fact, I'm even considering to remove
the symbols from the header file because most of them are unused now
(and it should be easy enough to get rid of the rest of them so that the
only occurrence of the literal opcode is in the table).
The point here is that this table contains all the information about a
command in one place. If you used symbols, you would have the command
name twice, and the opcode would be missing. So not using symbolic
constants but rather literal opcodes improves readability in this case.
> The table can probably be static const.
Right, will fix.
Kevin
Re: [Qemu-devel] [RFC][PATCH v2 08/17] qapi: fix Error usage in qemu-sockets.c
On 04/18/11 17:02, Michael Roth wrote:
> Fix spurious errors due to not initializing Error pointer to NULL before
> checking for errors.
>
> Signed-off-by: Michael Roth
> ---
> qemu-sockets.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-sockets.c b/qemu-sockets.c
> index dc8beeb..e709e5f 100644
> --- a/qemu-sockets.c
> +++ b/qemu-sockets.c
> @@ -630,7 +630,7 @@ int unix_connect(const char *path)
> {
> QemuOpts *opts;
> int sock;
> -Error *err;
> +Error *err = NULL;
>
> opts = qemu_opts_create(&dummy_opts, NULL, 0, &err);
> if (err) {
This one really should go into the tree asap, even if the rest of the
virt agent patches are still pending.
Reviewed-by: Jes Sorensen
Re: [Qemu-devel] How to use qemu-kvm with Fedora15-beta gnome3 (better vga driver ?)
On Thu, Apr 21, 2011 at 12:57 AM, Paolo Bonzini wrote: > On 04/21/2011 05:40 AM, Cheng Renquan wrote: >> >> I'm trying to use qemu-kvm to run Fedora15-beta with gnome3, >> but it told me graphics hardware failed to run gnome3 specific >> features and it fallback to gnome2; > > Sorry, none of the cards provided by KVM (including the SPICE-specific QXL > card) currently provide the 3D acceleration abilities required by GNOME 3. Later when I tried VirtualBox I found VB video driver has such 3D acceleration abilities, but I just don't like VB style slow performance; Then are there some plans / possibilities to add more virtual graphics hardware drivers for qemu kvm ? Any specification to follow? Pointers for me to explore this way? cheng@cheng-tux ~ $ ls -lh /usr/share/qemu/vgabios* -rw-r--r-- 1 root root 35K Oct 14 2010 /usr/share/qemu/vgabios-cirrus.bin -rw-r--r-- 1 root root 39K Oct 14 2010 /usr/share/qemu/vgabios.bin cheng@cheng-tux ~ $ file /usr/share/qemu/vgabios* /usr/share/qemu/vgabios-cirrus.bin: BIOS (ia32) ROM Ext. IBM comp. Video (70*512) /usr/share/qemu/vgabios.bin:BIOS (ia32) ROM Ext. IBM comp. Video (78*512)
Re: [Qemu-devel] [RFC][PATCH v2 09/17] qmp proxy: core code for proxying qmp requests to guest
On 04/18/11 17:02, Michael Roth wrote:
> diff --git a/qmp-core.c b/qmp-core.c
> index 9f3d182..dab50a1 100644
> --- a/qmp-core.c
> +++ b/qmp-core.c
> @@ -937,7 +937,15 @@ void qmp_async_complete_command(QmpCommandState *cmd,
> QObject *retval, Error *er
> qemu_free(cmd);
> }
>
> +extern QmpProxy *qmp_proxy_default;
Please put this in a header file.
> +static void qmp_proxy_process_control_event(QmpProxy *p, const QDict *evt)
> +{
> +const char *cmd;
> +int host_sid, guest_sid;
> +
> +cmd = qdict_get_try_str(evt, "_control_event");
> +if (!cmd) {
> +fprintf(stderr, "received NULL control event\n");
> +} else if (strcmp(cmd, "guest_ack") == 0) {
> +host_sid = qdict_get_try_int(evt, "_control_arg_host_sid", 0);
> +if (!host_sid) {
> +fprintf(stderr, "invalid guest_ack: wrong host sid\n");
> +return;
> +}
> +/* guest responded to host_init, return a host_ack */
> +/* reset outstanding requests, then send an ack with the
> + * session id they passed us
> + */
> +guest_sid = qdict_get_try_int(evt, "_control_arg_guest_sid", 0);
I am wondering if it would make sense to put these arguments in a header
file as #define's to make sure you don't have to chase down a typo on
one side at some point? Just an idea, dunno if it is worth it.
Cheers,
Jes
[Qemu-devel] iSCSI support for QEMU
Please find attached a new version of the patch for iSCSI support. iSCSI support is automaticallt detected and activated during configure/build if the libiscsi library is available on the build host. This library is available at : https://github.com/sahlberg/libiscsi This new version contains two changes since previous versions * avoid copying data in the read path and use the api for reading directly into the application buffers * use proper task management functions to abort tasks that are cancelled by qemu A built in iSCSI initiator has many benefits * the LUNs used are local to the guest and are not exposed to the host, nor any of the processes running on the host. * it provides very high performance out-of-the-box, compared to open-iscsi that requires several special flags to iscsi to match libiscsi * it avoids cache trashing and having two copies of the same data, once in the hosts cache and a second copy in the guest. I.e. O_DIRECT like behaviour. * management of LUNs are much easier for high-end or enterprise users with very many iscsi devices. You no longer need to expose many hundreds of devices to the local host and have them pollute the caches. Performance is acceptable with libiscsi. Some basic tests thatve been performed show it to be significantly faster than an out-of-the-box open-iscsi mounted LUN being accessed by default QEMU i/o options. Test was performed as booting a Ubuntu 10.04 host, mounted on a 8GB STGT LUN exposed across a 1GbE network. Test was once the system booted, how long would it take to run, inside the guest, "sudo time dd if=/dev/sda of=/dev/null bs=1M" i.e. just have the guest read the 8GB system disk. QEMU+libiscsi : 228 seconds QEMU, default device options: 273 seconds QEMU with cache=none: 387 seconds QEMU with cache=none,aio=native : 218 seconds Please review and consider for inclusion. regards ronnie sahlberg From: Ronnie Sahlberg Subject: iSCSI support for QEMU In-Reply-To:
[Qemu-devel] [PATCH] iSCSI block driver support
This patch adds a new block driver : block.iscsi.c
This driver interfaces with the multiplatform posix library
for iscsi initiator/client access to iscsi devices hosted at
git://github.com/sahlberg/libiscsi.git
The patch adds the driver to interface with the iscsi library.
It also updated the configure script to
* by default, probe is libiscsi is available and if so, build
qemu against libiscsi.
* --enable-libiscsi
Force a build against libiscsi. If libiscsi is not available
the build will fail.
* --disable-libiscsi
Do not link against libiscsi, even if it is available.
When linked with libiscsi, qemu gains support to access iscsi resources
such as disks and cdrom directly, without having to make the devices visible
to the host.
You can specify devices using a iscsi url of the form :
iscsi://[[:@]][:/
When using authentication, the password can optionally be set with
LIBISCSI_CHAP_PASSWORD="password" to avoid it showing up in the process list
Example:
-drive file=iscsi://10.1.1.1:3260/iqn.ronnie.test/1
-cdrom iscsi://10.1.1.1:3260/iqn.ronnie.test/2
Signed-off-by: Ronnie Sahlberg
---
Makefile.objs |1 +
block/iscsi.c | 590 +
configure | 31 +++
trace-events |6 +
4 files changed, 628 insertions(+), 0 deletions(-)
create mode 100644 block/iscsi.c
diff --git a/Makefile.objs b/Makefile.objs
index 44ce368..8403c66 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -25,6 +25,7 @@ block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
block-nested-$(CONFIG_POSIX) += raw-posix.o
+block-nested-$(CONFIG_LIBISCSI) += iscsi.o
block-nested-$(CONFIG_CURL) += curl.o
block-nested-$(CONFIG_RBD) += rbd.o
diff --git a/block/iscsi.c b/block/iscsi.c
new file mode 100644
index 000..31831ec
--- /dev/null
+++ b/block/iscsi.c
@@ -0,0 +1,590 @@
+/*
+ * QEMU Block driver for iSCSI images
+ *
+ * Copyright (c) 2010 Ronnie Sahlberg
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "config-host.h"
+
+#include
+#include "sysemu.h"
+#include "qemu-common.h"
+#include "qemu-error.h"
+#include "block_int.h"
+#include "trace.h"
+
+#include
+#include
+
+
+typedef struct IscsiLun {
+struct iscsi_context *iscsi;
+int lun;
+int block_size;
+unsigned long num_blocks;
+} IscsiLun;
+
+typedef struct IscsiAIOCB {
+BlockDriverAIOCB common;
+QEMUIOVector *qiov;
+QEMUBH *bh;
+IscsiLun *iscsilun;
+struct scsi_task *task;
+uint8_t *buf;
+int canceled;
+int status;
+size_t read_size;
+size_t read_offset;
+} IscsiAIOCB;
+
+struct IscsiTask {
+IscsiLun *iscsilun;
+int status;
+int complete;
+};
+
+static void
+iscsi_abort_task_cb(struct iscsi_context *iscsi, int status, void
*command_data,
+ void *private_data)
+{
+}
+
+static void
+iscsi_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+IscsiAIOCB *acb = (IscsiAIOCB *)blockacb;
+IscsiLun *iscsilun = acb->iscsilun;
+
+acb->status = -ECANCELED;
+acb->common.cb(acb->common.opaque, acb->status);
+acb->canceled = 1;
+
+iscsi_task_mgmt_abort_task_async(iscsilun->iscsi, acb->task,
+ iscsi_abort_task_cb, NULL);
+}
+
+static AIOPool iscsi_aio_pool = {
+.aiocb_size = sizeof(IscsiAIOCB),
+.cancel = iscsi_aio_cancel,
+};
+
+
+static void iscsi_process_read(void *arg);
+static void iscsi_process_write(void *arg);
+
+static int iscsi_process_flush(void *arg)
+{
+IscsiLun *iscsilun = arg;
+
+return iscsi_queue_length(iscsilun->iscsi) > 0;
+}
+
+static void
+iscsi_set_events(IscsiLun *iscsilun)
+{
+struct iscsi_context *iscsi = iscsilun->iscsi;
+
+qemu_aio_set_fd_handler(iscsi_get_fd(iscsi), iscsi_process_read,
+ (iscsi_which_events(iscsi) & POLLOUT)
+ ? iscsi_process
Re: [Qemu-devel] [RFC][PATCH v2 12/17] guest agent: worker thread class
On 04/18/11 17:02, Michael Roth wrote:
> diff --git a/qga/guest-agent-worker.c b/qga/guest-agent-worker.c
> new file mode 100644
> index 000..e3295da
> --- /dev/null
> +++ b/qga/guest-agent-worker.c
> @@ -0,0 +1,173 @@
> +/*
> + * QEMU Guest Agent worker thread interfaces
> + *
> + * Copyright IBM Corp. 2011
> + *
> + * Authors:
> + * Michael Roth
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "guest-agent.h"
> +#include "../error.h"
Oh dear! do not do that please! Fix the Makefile to include the
appropriate path.
> +struct GAWorker {
> +pthread_t thread;
> +ga_worker_func execute;
> +pthread_mutex_t input_mutex;
> +pthread_cond_t input_avail_cond;
> +void *input;
> +bool input_avail;
> +pthread_mutex_t output_mutex;
> +pthread_cond_t output_avail_cond;
You really should use QemuMutex and friends here.
> +void *output;
> +Error *output_error;
> +bool output_avail;
> +};
> +
> +static void *worker_run(void *worker_p)
> +{
> +GAWorker *worker = worker_p;
> +Error *err;
> +void *input, *output;
> +
> +while (1) {
> +/* wait for input */
> +pthread_mutex_lock(&worker->input_mutex);
qemu_mutex_lock()
> +while (!worker->input_avail) {
> +pthread_cond_wait(&worker->input_avail_cond,
> &worker->input_mutex);
> +}
again
> +input = worker->input;
> +worker->input_avail = false;
> +pthread_mutex_unlock(&worker->input_mutex);
and again I'll stop. Basically there really should be no references
to pthread_*
Jes
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 06:43:10PM +1000, Ronnie Sahlberg wrote: > Some basic tests thatve been performed show it to be significantly faster > than an out-of-the-box open-iscsi mounted LUN being accessed by default > QEMU i/o options. Which isn't a useful comparism. qemu's default is the braindead cache=writethrough behaviour, which forces writes out to disk, and bloats the pagecache, while your mail sounds you silently always implement O_DIRECT-like semantics. Also the implementation has data integrity issues due this. It does not actually force writes out to disk in the default cache mode, despite qemu claiming to have WCE=0 in the default mode, i.e. you never flush the cache. You'll need set the FUA bits on all writes if cache=writethrough is used, with a fallback to a real cache flush in case the target doesn't support the FUA bit.
Re: [Qemu-devel] [RFC][PATCH v2 15/17] guest agent: qemu-ga daemon
On 04/18/11 17:02, Michael Roth wrote:
> +static const char *ga_log_level_str(GLogLevelFlags level)
> +{
> +switch (level & G_LOG_LEVEL_MASK) {
> +case G_LOG_LEVEL_ERROR: return "error";
> +case G_LOG_LEVEL_CRITICAL: return "critical";
> +case G_LOG_LEVEL_WARNING: return "warning";
> +case G_LOG_LEVEL_MESSAGE: return "message";
> +case G_LOG_LEVEL_INFO: return "info";
> +case G_LOG_LEVEL_DEBUG: return "debug";
> +default:return "user";
> +}
Urgh!
No two statements on the same line please!
Jes
Re: [Qemu-devel] iSCSI support for QEMU
Please re-read my post or read the patch. It has O_DIRECT like behaviour in that it will not pollute the hosts cache. This for the simple reason that the host is not aware that there is any block i/o happening. In my patch, there are NO data integrity issues. Data is sent out on the wire immediately as the guest issues the write. Once the guest issues a flush call, the flush call will not terminate until the SYNCCACHE10 task has completed. I do not have any cache at all in libiscsi or the patch. All I/O are always sent to the iSCSI target. No data is ever cached anywhere. I am just saying that in the tests I did, I had to use 'cache=none,aio=native' to come anywhere near the libiscsi performance. All other options performed significantly worse. I have no idea what those options have for effect on data integrity or open-iscsi. There should not be any integrity issues in libiscsi since it does not cache at all, ever. regards ronnie sahlberg On Thu, Apr 21, 2011 at 6:50 PM, Christoph Hellwig wrote: > On Thu, Apr 21, 2011 at 06:43:10PM +1000, Ronnie Sahlberg wrote: >> Some basic tests thatve been performed show it to be significantly faster >> than an out-of-the-box open-iscsi mounted LUN being accessed by default >> QEMU i/o options. > > Which isn't a useful comparism. qemu's default is the braindead > cache=writethrough behaviour, which forces writes out to disk, and bloats the > pagecache, while your mail sounds you silently always implement O_DIRECT-like > semantics. > > Also the implementation has data integrity issues due this. It does > not actually force writes out to disk in the default cache mode, despite > qemu claiming to have WCE=0 in the default mode, i.e. you never flush > the cache. You'll need set the FUA bits on all writes if cache=writethrough > is used, with a fallback to a real cache flush in case the target doesn't > support the FUA bit. > >
Re: [Qemu-devel] iSCSI support for QEMU
> In my patch, there are NO data integrity issues. > Data is sent out on the wire immediately as the guest issues the write. > Once the guest issues a flush call, the flush call will not terminate > until the SYNCCACHE10 task has completed. No guest will even issue a cache flush, as we claim to be WCE=0 by default. Now if you target has WCE=1 it will cache data internally, and your iscsi initiator will never flush it out to disk. We only claim WCE=1 to the guest if cache=writeback or cache=none are set. So ignoring the issue of having a cache on the initiator side you must implement stable writes for the default cache=writethrough behaviour by either seeting the FUA bit on your writes, or doing a cache flush after every write in case the target does not support FUA.
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: >> In my patch, there are NO data integrity issues. >> Data is sent out on the wire immediately as the guest issues the write. >> Once the guest issues a flush call, the flush call will not terminate >> until the SYNCCACHE10 task has completed. > > No guest will even issue a cache flush, as we claim to be WCE=0 by default. > Now if you target has WCE=1 it will cache data internally, and your > iscsi initiator will never flush it out to disk. My target does not do any caching at all. It happily ignores both FUA and FUA_NV bits and always destage all data to stable storage before sending SCSI_STATUS_GOOD back to the initiator. I use the same target and the same LUN and the same settings for both testing QEMU+openiscsi-mounted-lun and QEMU+libiscsi I do not understand why my target would have data integrity problem when used with libiscsi but not with open-iscsi mounted lun? > > We only claim WCE=1 to the guest if cache=writeback or cache=none are > set. So ignoring the issue of having a cache on the initiator side > you must implement stable writes for the default cache=writethrough > behaviour by either seeting the FUA bit on your writes, or doing > a cache flush after every write in case the target does not support FUA. My target right now does such flushes for writes. I fail to see why FUA, FUA_NV or flushes have any relevance to a test that just involves reading data off the lun. I think this discussion is strange. I would like discussion about the merits of my patch and if features like built-in iscsi support that enterprise users find useful are desireable in QEMU. I do not find discussions about semantics of my particular iscsi target to be meaningful for that purpose. regards ronnie sahlberg
Re: [Qemu-devel] Supporting emulation of IOMMUs
On 21.04.2011, at 09:03, David Gibson wrote:
> A few months ago, Eduard - Gabriel Munteanu posted a series of patches
> implementing support for emulating the AMD PCI IOMMU
> (http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg03196.html).
>
> In fact, this series implemented a general DMA/IOMMU layer which can
> be used by any device model, and one translation backend for this
> implementing the AMD specific PCI IOMMU.
>
> These patches don't seem to have gone anywhere for the last few
> months, however, and so far I've been unable to contact the author
> (trying again with this mail).
>
> I have an interest in this code, because the pSeries machine will also
> need IOMMU emulation support. At present we only support virtual
> devices, through the PAPR interface, and we have support for the
> hypervisor-controller IOMMU translation in the PAPR VIO code.
> However, we want to add PCI device support and this will also need
> IOMMU translation.
>
> The series seems to have the right basic approach, so if the author is
> indeed MIA, I was planning to pick up the patches and resubmit them
> (with support for the pSeries IOMMU added).
>
> Before I do that, I was hoping to get some consensus that this is the
> right way to go. For reference, I have an updated version of the
> first patch (which adds the core IOMMU layer) below.
>
> From: Eduard - Gabriel Munteanu
> Date: Fri, 4 Feb 2011 01:32:55 +0200
> Subject: [PATCH] Generic DMA memory access interface
>
> This introduces replacements for memory access functions like
> cpu_physical_memory_read(). The new interface can handle address
> translation and access checking through an IOMMU.
>
> David Gibson: I have made several bugfixes and cleanups to Eduard's
> original patch.
>
> * dma_memory_rw() was incorrectly using (uninitialized) plen instead
> of len in the fallback to no-IOMMU case.
>
> * the dma_memory_map() tracking was storing the guest physical
> address of each mapping, but not the qemu user virtual address.
> However in unmap() it was then attempting to lookup by virtual
> using a completely bogus cast.
>
> * The dma_memory_rw() function is moved from dma_rw.h to dma_rw.c, it
> was a bit too much code for an inline.
>
> * IOMMU support is now available on all target platforms, not just
> i386, but is configurable (--enable-iommu/--disable-iommu). Stubs
> are used so that individual drivers can use the new dma interface
> and it will turn into old-style cpu physical accesses at no cost on
> IOMMU-less builds.
>
> Signed-off-by: Eduard - Gabriel Munteanu
> Signed-off-by: David Gibson
> ---
> Makefile.target |1 +
> configure | 12
> hw/dma_rw.c | 147 +++
> hw/dma_rw.h | 156 +++
> 4 files changed, 316 insertions(+), 0 deletions(-)
> create mode 100644 hw/dma_rw.c
> create mode 100644 hw/dma_rw.h
>
> diff --git a/Makefile.target b/Makefile.target
> index 95f5eda..c3d36c6 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -198,6 +198,7 @@ obj-$(CONFIG_REALLY_VIRTFS) += virtio-9p.o
> obj-y += rwhandler.o
> obj-$(CONFIG_KVM) += kvm.o kvm-all.o
> obj-$(CONFIG_NO_KVM) += kvm-stub.o
> +obj-$(CONFIG_IOMMU) += dma_rw.o
> LIBS+=-lz
>
> QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
> diff --git a/configure b/configure
> index da2da04..fa6f4d5 100755
> --- a/configure
> +++ b/configure
> @@ -130,6 +130,7 @@ xen=""
> linux_aio=""
> attr=""
> vhost_net=""
> +iommu="no"
> xfs=""
>
> gprof="no"
> @@ -723,6 +724,10 @@ for opt do
> ;;
> --enable-vhost-net) vhost_net="yes"
> ;;
> + --enable-iommu) iommu="yes"
> + ;;
> + --disable-iommu) iommu="no"
> + ;;
> --disable-opengl) opengl="no"
> ;;
> --enable-opengl) opengl="yes"
> @@ -934,6 +939,8 @@ echo " --enable-docsenable documentation
> build"
> echo " --disable-docs disable documentation build"
> echo " --disable-vhost-net disable vhost-net acceleration support"
> echo " --enable-vhost-net enable vhost-net acceleration support"
> +echo " --disable-iommu disable IOMMU emulation support"
> +echo " --enable-vhost-net enable IOMMU emulation support"
eeh?
> echo " --enable-trace-backend=B Set trace backend"
> echo " Available backends:"
> $("$source_path"/scripts/tracetool --list-backends)
> echo " --with-trace-file=NAME Full PATH,NAME of file to store traces"
> @@ -2608,6 +2615,7 @@ echo "madvise $madvise"
> echo "posix_madvise $posix_madvise"
> echo "uuid support $uuid"
> echo "vhost-net support $vhost_net"
> +echo "IOMMU support $iommu"
> echo "Trace backend $trace_backend"
> echo "Trace output file $trace_file-"
> echo "spice support $spice"
> @@ -3412,6 +3420,10 @@ if test "$target_softmmu" = "yes" -a \( \
> echo "CONFIG_NEED_MMU=y" >> $config_target_mak
> fi
>
> +if test "$iommu" = "yes" ; then
> + echo "CONFIG_IOMMU
Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)
On 04/18/11 17:02, Michael Roth wrote:
> These apply on top of Anthony's glib tree, commit
> 03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained
> from:
> git://repo.or.cz/qemu/mdroth.git qga_v2
>
> Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider
> pulling these into your glib tree. The json fix-ups may need further
> evaluation, but I'm confident they're at least an improvement. The QAPI ones
> are mostly trivial fix-ups.
>
> Changes since V1:
>
> - Added guest agent worker thread to execute RPCs in the guest. With this in
> place we have a reliable timeout mechanism for hung commands, currently set
> at 30 seconds.
> - Add framework for registering init/cleanup routines for stateful RPCs to
> clean up after themselves after a timeout.
> - Added the following RPCs: guest-file-{open,close,read,write,seek},
> guest-shutdown, guest-info, and removed stubs for guest-view-file (now
> deprecated)
> - Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
> - Switched to a TCP-style host-initiated 3-way handshake for channel
> negotiation, this simplifies client negotiation/interaction over the wire
> - Added configurable log level/log file/pid file options for guest agent
> - Various fixes for bugs/memory leaks and checkpatch.pl fixups
>
> ISSUES/TODOS:
>
> - Fix QMP proxy handling of error responses sent by guest agent, currently
> ignored
> - Add unit tests for guest agent wire protocol
> - Add unit tests for QMP interfaces
> - Add host-side timeout mechanism for async QMP commands
> - Return error for guest commands if guest up event has not yet been recieved
> - Make QMP param names more consistent between related commands
> - Clean up logging
>
Hi,
I had a look through this patchset and generally it looks pretty good.
There were a few nits, and I ignored all the python gibberish to avoid
getting a headache.
Did you do anything with the fsfreeze patches, or were they dropped in
the migration to qapi?
Cheers,
Jes
Re: [Qemu-devel] iSCSI support for QEMU
Christoph, I think you misread my test. My test is pure reading : sudo time dd if=/dev/sda of=/dev/null bs=1M There are no writes involved at all in this test, only a huge number of READ10 being sent to the target, or in the case of when using QEMU+openiscsi-mounted-lun sometimes being served out of the pagecache of the host. Since open-iscsi mounted LUNs by default perform so very poorly against libiscsi, I assume that there are very few blocks that are be served out of the cache of the host. This is based on that a block served out of cache would have significantly, many orders or magnitudes, lower access latency than a block that needs to be fetched across a 1GbE network. As open-iscsi performs so much poorly in this case compared to libiscsi, I just speculate that very few blocks are delivered by cache hits. I have absolutely no idea on why, QEMU+open-iscsi would perform so much better for a read-intensive workload like this when setting cache=none,aio=native. That is for the qemu developers to explain. Maybe doing READ10 through open-iscsi is very expensive? Maybe something else in the linux kernel makes reads very expensive unless you use "cache=none,aio=native"? Who knows? I have no idea, other than without using "cache=none,aio=native" QEMU performance for read intensive tasks are significantly slower than QEMU doing the exact same reads using libiscsi. I really don't care why QEMU+openiscsi performs so bad either. That is of very little interest to me. As long as libiscsi is not significantly worse than open-iscsi I care very little about why. regards ronnie sahlberg On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: >> In my patch, there are NO data integrity issues. >> Data is sent out on the wire immediately as the guest issues the write. >> Once the guest issues a flush call, the flush call will not terminate >> until the SYNCCACHE10 task has completed. > > No guest will even issue a cache flush, as we claim to be WCE=0 by default. > Now if you target has WCE=1 it will cache data internally, and your > iscsi initiator will never flush it out to disk. > > We only claim WCE=1 to the guest if cache=writeback or cache=none are > set. So ignoring the issue of having a cache on the initiator side > you must implement stable writes for the default cache=writethrough > behaviour by either seeting the FUA bit on your writes, or doing > a cache flush after every write in case the target does not support FUA. > >
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg wrote: > On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: >> We only claim WCE=1 to the guest if cache=writeback or cache=none are >> set. So ignoring the issue of having a cache on the initiator side >> you must implement stable writes for the default cache=writethrough >> behaviour by either seeting the FUA bit on your writes, or doing >> a cache flush after every write in case the target does not support FUA. > > My target right now does such flushes for writes. > > > I fail to see why FUA, FUA_NV or flushes have any relevance to a test > that just involves reading data off the lun. I'll try to rephrase what Christoph has pointed out. When QEMU is run with cache=writethrough (default), QEMU does not report a write cache on the emulated disk. The guest believes that all writes are stable because there is no disk write cache. Therefore the guest does not need to issue synchronize cache commands ever. In order to meet these semantics with libiscsi, we would need to set FUA or send a synchronize cache command for every write. (QEMU's raw-posix.c file I/O meets these semantics by opening the image file with O_DSYNC when cache=writethrough.) > I do not understand why my target would have data integrity problem > when used with libiscsi > but not with open-iscsi mounted lun? In the open-iscsi cache=writethrough case, QEMU's raw-posix.c opens the file with O_DSYNC. Open-iscsi must set the FUA bit or synchronize cache for each write request. How does libiscsi behave in this case? Stefan
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi wrote: > On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg > wrote: >> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: >>> We only claim WCE=1 to the guest if cache=writeback or cache=none are >>> set. So ignoring the issue of having a cache on the initiator side >>> you must implement stable writes for the default cache=writethrough >>> behaviour by either seeting the FUA bit on your writes, or doing >>> a cache flush after every write in case the target does not support FUA. >> >> My target right now does such flushes for writes. >> >> >> I fail to see why FUA, FUA_NV or flushes have any relevance to a test >> that just involves reading data off the lun. > > I'll try to rephrase what Christoph has pointed out. > > When QEMU is run with cache=writethrough (default), QEMU does not > report a write cache on the emulated disk. The guest believes that > all writes are stable because there is no disk write cache. Therefore > the guest does not need to issue synchronize cache commands ever. > > In order to meet these semantics with libiscsi, we would need to set > FUA or send a synchronize cache command for every write. (QEMU's > raw-posix.c file I/O meets these semantics by opening the image file > with O_DSYNC when cache=writethrough.) > >> I do not understand why my target would have data integrity problem >> when used with libiscsi >> but not with open-iscsi mounted lun? > > In the open-iscsi cache=writethrough case, QEMU's raw-posix.c opens > the file with O_DSYNC. Open-iscsi must set the FUA bit or synchronize > cache for each write request. > > How does libiscsi behave in this case? libiscsi ignores the O_DSYNC flag. It does not matter for two reasons: * my target always destage to disk before replying. I.e. my target ALWAYS write data synchronously to stable storage * this test we are talking about is for READ10, reads, not writes. Serioulsly, please explain, in what exact way are write semantics and FUA bits and write destage policy relevant here : sudo time dd if=/dev/sda of=/dev/null bs=1M I seriously do not understand. Please educate me. regards ronnie sahlberg
Re: [Qemu-devel] [PATCH 1/3] rtl8139: use TARGET_FMT_plx in debug messages
On Thu, Apr 21, 2011 at 12:39 AM, Benjamin Poirier wrote: > Prevents a compilation failure when DEBUG_RTL8139 is defined: > > CC libhw32/rtl8139.o > cc1: warnings being treated as errors > hw/rtl8139.c: In function ‘rtl8139_cplus_transmit_one’: > hw/rtl8139.c:1960: error: format ‘%8lx’ expects type ‘long unsigned int’, but > argument 5 has type ‘target_phys_addr_t’ > make[1]: *** [rtl8139.o] Error 1 > > Signed-off-by: Benjamin Poirier > Cc: Igor V. Kovalenko > --- > hw/rtl8139.c | 15 +-- > 1 files changed, 9 insertions(+), 6 deletions(-) Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg wrote: > On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi wrote: >> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg >> wrote: >>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: We only claim WCE=1 to the guest if cache=writeback or cache=none are set. So ignoring the issue of having a cache on the initiator side you must implement stable writes for the default cache=writethrough behaviour by either seeting the FUA bit on your writes, or doing a cache flush after every write in case the target does not support FUA. >>> >>> My target right now does such flushes for writes. >>> >>> >>> I fail to see why FUA, FUA_NV or flushes have any relevance to a test >>> that just involves reading data off the lun. >> >> I'll try to rephrase what Christoph has pointed out. >> >> When QEMU is run with cache=writethrough (default), QEMU does not >> report a write cache on the emulated disk. The guest believes that >> all writes are stable because there is no disk write cache. Therefore >> the guest does not need to issue synchronize cache commands ever. >> >> In order to meet these semantics with libiscsi, we would need to set >> FUA or send a synchronize cache command for every write. (QEMU's >> raw-posix.c file I/O meets these semantics by opening the image file >> with O_DSYNC when cache=writethrough.) >> >>> I do not understand why my target would have data integrity problem >>> when used with libiscsi >>> but not with open-iscsi mounted lun? >> >> In the open-iscsi cache=writethrough case, QEMU's raw-posix.c opens >> the file with O_DSYNC. Open-iscsi must set the FUA bit or synchronize >> cache for each write request. >> >> How does libiscsi behave in this case? > > libiscsi ignores the O_DSYNC flag. > It does not matter for two reasons: > * my target always destage to disk before replying. I.e. my target > ALWAYS write data synchronously to stable storage Does libiscsi initiator ensure this? What if I use a different target or configure it differently, will libiscsi take care to ensure the semantics are still met? > * this test we are talking about is for READ10, reads, not writes. I was not talking about a specific test. > Serioulsly, please explain, > in what exact way are write semantics and FUA bits and write destage > policy relevant here : > > sudo time dd if=/dev/sda of=/dev/null bs=1M > > > I seriously do not understand. Please educate me. Write semantics are completely independent of this dd read example. Stefan
[Qemu-devel] [PATCH qemu-glib] Add missing files to distclean list
From: Jes Sorensen Signed-off-by: Jes Sorensen --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index a7c1503..bebe3bd 100644 --- a/Makefile +++ b/Makefile @@ -301,6 +301,7 @@ distclean: clean for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis libdis-user; do \ rm -rf $$d || exit 1 ; \ done + rm -f qmp.h qmp-marshal.c qmp-marshal-types.* KEYMAPS=da en-gb et fr fr-ch is lt modifiers no pt-br sv \ ar de en-us fi fr-be hr it lv nl pl ru th \ -- 1.7.4.4
Re: [Qemu-devel] [PATCH] xen-upstream-qemu: get vncpassword through xenstore, enable VNC_AUTH_VNC
On Thu, 21 Apr 2011, ZhouPeng wrote: > Thank you for your review. > > Does this means the xen-upsteam-qemu will give up xenstore? > > Many features of xen except for vncpasswd > may need that xl send||receive msg to||from xen-qemu. > I think some other part of xen may need to read xenstore which may be > updated by qemu. > xenstore's sharing characteristic give much convenience for many-way > msg communication, > but the RPC may only give single-way. > > So I am somewhat in doubt xen-upstream-qemu will give up xenstore. > > IMO, I don't think qemu may accept xenstore's code only used by xen, > > except > qemu need to add a new general shared many-way msg exchange mechanism, > like xenstore database. > Even though a "QMP bus" could be useful, I don't think there is anything like that at the moment. Also considering that each qemu instance takes care of a single guest, the usefulness of such a mechanism is reduced. Anyhow in this particular case using QMP seems appropriate: I would welcome patches to add QMP support to libxenlight, even though I realize that it is a bigger effort than this single patch.
Re: [Qemu-devel] iSCSI support for QEMU
Stephan, I understand. Let me re-send a patch tomorrow that can optionally enable/force FUA bits for write. There are some high-volume arrays that advertise support but fail any cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional. regards ronnie sahlberg On Thu, Apr 21, 2011 at 9:21 PM, Stefan Hajnoczi wrote: > On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg > wrote: >> On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi wrote: >>> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg >>> wrote: On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote: > We only claim WCE=1 to the guest if cache=writeback or cache=none are > set. So ignoring the issue of having a cache on the initiator side > you must implement stable writes for the default cache=writethrough > behaviour by either seeting the FUA bit on your writes, or doing > a cache flush after every write in case the target does not support FUA. My target right now does such flushes for writes. I fail to see why FUA, FUA_NV or flushes have any relevance to a test that just involves reading data off the lun. >>> >>> I'll try to rephrase what Christoph has pointed out. >>> >>> When QEMU is run with cache=writethrough (default), QEMU does not >>> report a write cache on the emulated disk. The guest believes that >>> all writes are stable because there is no disk write cache. Therefore >>> the guest does not need to issue synchronize cache commands ever. >>> >>> In order to meet these semantics with libiscsi, we would need to set >>> FUA or send a synchronize cache command for every write. (QEMU's >>> raw-posix.c file I/O meets these semantics by opening the image file >>> with O_DSYNC when cache=writethrough.) >>> I do not understand why my target would have data integrity problem when used with libiscsi but not with open-iscsi mounted lun? >>> >>> In the open-iscsi cache=writethrough case, QEMU's raw-posix.c opens >>> the file with O_DSYNC. Open-iscsi must set the FUA bit or synchronize >>> cache for each write request. >>> >>> How does libiscsi behave in this case? >> >> libiscsi ignores the O_DSYNC flag. >> It does not matter for two reasons: >> * my target always destage to disk before replying. I.e. my target >> ALWAYS write data synchronously to stable storage > > Does libiscsi initiator ensure this? What if I use a different target > or configure it differently, will libiscsi take care to ensure the > semantics are still met? > >> * this test we are talking about is for READ10, reads, not writes. > > I was not talking about a specific test. > >> Serioulsly, please explain, >> in what exact way are write semantics and FUA bits and write destage >> policy relevant here : >> >> sudo time dd if=/dev/sda of=/dev/null bs=1M >> >> >> I seriously do not understand. Please educate me. > > Write semantics are completely independent of this dd read example. > > Stefan >
Re: [Qemu-devel] iSCSI support for QEMU
Am 21.04.2011 13:36, schrieb ronnie sahlberg: > Stephan, > > I understand. > > Let me re-send a patch tomorrow that can optionally enable/force FUA > bits for write. > There are some high-volume arrays that advertise support but fail any > cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional. You should make it dependent on the cache mode, i.e. you set FUA for cache=writethrough and leave it alone for the other cache modes. Kevin
Re: [Qemu-devel] [PATCH 1/2] Implement basic part of SA-1110/SA-1100
On 4/20/11, Aurelien Jarno wrote: > On Tue, Apr 19, 2011 at 06:56:45PM +0400, Dmitry Eremin-Solenikov wrote: >> Basic implementation of DEC/Intel SA-1100/SA-1110 chips emulation. >> Implemented: >> - IRQs >> - GPIO >> - PPC >> - RTC >> - UARTs (no IrDA/etc.) >> - OST reused from pxa25x >> >> Everything else is TODO (esp. PM/idle/sleep!) - see the todo in the >> hw/strongarm.c >> >> V6: >> * license fixup >> * DPRINTF >> >> V5: >> * syntax fixup >> >> V4: >> * use bitnames to access RTC and UART registers >> * drop unused casts >> * disable debug printfs in GPIO code >> >> V3: >> * fix the name of UART VMSD >> * fix RTSR reg offset >> * add SSP support >> >> V2: >> * removed all strongarm variants except latest >> * dropped unused casts >> * fixed PIC vmstate >> * fixed new devices created with version_id = 1 >> >> Signed-off-by: Dmitry Eremin-Solenikov >> >> --- >> Makefile.target |1 + >> hw/strongarm.c | 1600 >> +++ >> hw/strongarm.h | 64 ++ >> target-arm/cpu.h|3 + >> target-arm/helper.c |9 + >> 5 files changed, 1677 insertions(+), 0 deletions(-) >> create mode 100644 hw/strongarm.c >> create mode 100644 hw/strongarm.h > > Thanks, applied. Thank you! -- With best wishes Dmitry
Re: [Qemu-devel] [PATCH 0/7] Rework PCMCIA subsystem
Hello, On 4/11/11, Dmitry Eremin-Solenikov wrote: > Please pull the following changeset that makes PCMCIA subsystem to use > QBus and Qdev for managing devices. Currently the only implementation > of PCMCIA host is a PXA2xx host and the only possible PCMCIA device is > IDE MicroDrive (dscm1). > > With this patchset I can create a microdrive device from command line: > -device dscm1 -device ide-drive,drive=test -drive > if=none,id=test,file=/dev/null > > > Dmitry Eremin-Solenikov (7): > pxa2xx_pcmcia: qdevify > PCMCIA: start qdev'ication > microdrive: qdevify > pcmcia: move all card callbacks to PCMCIACardInfo > pcmcia: move attach and detach socket methods to PCMCIASocket > pxa: change order of pcmcia devices instantiation, so that the socket > 0 will be default > ide-core: allocate metadata storage for CFATA drives > > Makefile.objs |3 + > hw/ide/core.c |4 ++ > hw/ide/internal.h |2 + > hw/ide/microdrive.c | 88 +++--- > hw/mainstone.c | 14 +++-- > hw/pcmcia.c | 145 > + > hw/pcmcia.h | 49 - > hw/pxa.h|9 +--- > hw/pxa2xx.c |9 ++-- > hw/pxa2xx_pcmcia.c | 148 > ++- > hw/spitz.c | 26 ++ > hw/tosa.c | 18 --- > vl.c| 43 --- > 13 files changed, 372 insertions(+), 186 deletions(-) > create mode 100644 hw/pcmcia.c Pinging again about this patchset. Any objections? Comments? Etc.? -- With best wishes Dmitry
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 12:36 PM, ronnie sahlberg wrote: > I understand. > > Let me re-send a patch tomorrow that can optionally enable/force FUA > bits for write. > There are some high-volume arrays that advertise support but fail any > cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional. Maybe we should just disable write cache on the LUN (setting WCE=0) if cache=writethrough? Then we don't need to worry about FUA or synchronize cache. Stefan
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: > On 04/20/2011 08:46 AM, Tristan Gingold wrote: >> Right, but you could create an ev67 machine with a single PCI >> controller (or put all the devices on the same PCI controller). > > Even the lowly ds10 has two hoses. > > I'll admit I hadn't considered engineering the second hose to > be "present" but always appear empty. It's something to consider. > >> Ah, ok I understand. I fear that if you implement your own ISR, you will >> only be able to boot linux... >> which I suppose is your primary target. OTOH, it will be much faster than a >> native ISR. > > Yes, Linux is the primary goal. > > But I suspect that if I implemented enough of CALL_PAL CSERVE, > you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. Tristan.
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 09:36:12PM +1000, ronnie sahlberg wrote: > There are some high-volume arrays that advertise support but fail any > cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional. Which on would that be? Linux uses the FUA bit if the device advertises support via the DPOFUA bit since 2005, and prints a warning if a FUA write fails, and since last year even fails the request hard. I'd be really surprised if a common device fails FUA writes and we didn't know about it by now. Either way you'll have to still guarantee data made it to non-volatile storage for cache=writethrough mode, either by disabling the WCE bit using MODE SELECT, or by flushing the cache after every write.
Re: [Qemu-devel] [RFC][PATCH v2 09/17] qmp proxy: core code for proxying qmp requests to guest
On 04/21/2011 03:30 AM, Jes Sorensen wrote:
On 04/18/11 17:02, Michael Roth wrote:
diff --git a/qmp-core.c b/qmp-core.c
index 9f3d182..dab50a1 100644
--- a/qmp-core.c
+++ b/qmp-core.c
@@ -937,7 +937,15 @@ void qmp_async_complete_command(QmpCommandState *cmd,
QObject *retval, Error *er
qemu_free(cmd);
}
+extern QmpProxy *qmp_proxy_default;
Please put this in a header file.
+static void qmp_proxy_process_control_event(QmpProxy *p, const QDict *evt)
+{
+const char *cmd;
+int host_sid, guest_sid;
+
+cmd = qdict_get_try_str(evt, "_control_event");
+if (!cmd) {
+fprintf(stderr, "received NULL control event\n");
+} else if (strcmp(cmd, "guest_ack") == 0) {
+host_sid = qdict_get_try_int(evt, "_control_arg_host_sid", 0);
+if (!host_sid) {
+fprintf(stderr, "invalid guest_ack: wrong host sid\n");
+return;
+}
+/* guest responded to host_init, return a host_ack */
+/* reset outstanding requests, then send an ack with the
+ * session id they passed us
+ */
+guest_sid = qdict_get_try_int(evt, "_control_arg_guest_sid", 0);
I am wondering if it would make sense to put these arguments in a header
file as #define's to make sure you don't have to chase down a typo on
one side at some point? Just an idea, dunno if it is worth it.
That's probably a good idea.
Cheers,
Jes
[Qemu-devel] [PATCH] configure: Support --target-list=? to list available targets
Add support for getting configure to print the list of all targets
that can be built, via the option '--target-list=?'.
Signed-off-by: Peter Maydell
---
Yes, you can get the list of targets by running configure without
any arguments and then scrolling up to find the target list in
the screenful of output, but I think this is a bit more user-friendly.
configure | 36 ++--
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/configure b/configure
index da2da04..15330ea 100755
--- a/configure
+++ b/configure
@@ -834,7 +834,8 @@ echo " --help print this message"
echo " --prefix=PREFIX install in PREFIX [$prefix]"
echo " --interp-prefix=PREFIX where to find shared libraries, etc."
echo " use %M for cpu name [$interp_prefix]"
-echo " --target-list=LIST set target list [$target_list]"
+echo " --target-list=LIST set target list (default: build everything)"
+echo " use --target-list=? to list available targets"
echo ""
echo "Advanced options (experts only):"
echo " --source-path=PATH path of source code [$source_path]"
@@ -1004,11 +1005,11 @@ if test "$solaris" = "yes" ; then
fi
fi
+default_target_list=""
-if test -z "$target_list" ; then
# these targets are portable
-if [ "$softmmu" = "yes" ] ; then
-target_list="\
+if [ "$softmmu" = "yes" ] ; then
+default_target_list="\
i386-softmmu \
x86_64-softmmu \
arm-softmmu \
@@ -1029,10 +1030,10 @@ sh4eb-softmmu \
sparc-softmmu \
sparc64-softmmu \
"
-fi
+fi
# the following are Linux specific
-if [ "$linux_user" = "yes" ] ; then
-target_list="${target_list}\
+if [ "$linux_user" = "yes" ] ; then
+default_target_list="${default_target_list}\
i386-linux-user \
x86_64-linux-user \
alpha-linux-user \
@@ -1054,20 +1055,27 @@ sparc64-linux-user \
sparc32plus-linux-user \
unicore32-linux-user \
"
-fi
+fi
# the following are Darwin specific
-if [ "$darwin_user" = "yes" ] ; then
-target_list="$target_list i386-darwin-user ppc-darwin-user "
-fi
+if [ "$darwin_user" = "yes" ] ; then
+default_target_list="$default_target_list i386-darwin-user ppc-darwin-user
"
+fi
# the following are BSD specific
-if [ "$bsd_user" = "yes" ] ; then
-target_list="${target_list}\
+if [ "$bsd_user" = "yes" ] ; then
+default_target_list="${default_target_list}\
i386-bsd-user \
x86_64-bsd-user \
sparc-bsd-user \
sparc64-bsd-user \
"
-fi
+fi
+
+if test -z "$target_list" ; then
+target_list="$default_target_list"
+elif [ "$target_list" = "?" ]; then
+echo "Supported targets: "
+echo "$default_target_list"
+exit 0
else
target_list=`echo "$target_list" | sed -e 's/,/ /g'`
fi
--
1.7.1
Re: [Qemu-devel] [RFC][PATCH v2 12/17] guest agent: worker thread class
On 04/21/2011 03:44 AM, Jes Sorensen wrote:
On 04/18/11 17:02, Michael Roth wrote:
diff --git a/qga/guest-agent-worker.c b/qga/guest-agent-worker.c
new file mode 100644
index 000..e3295da
--- /dev/null
+++ b/qga/guest-agent-worker.c
@@ -0,0 +1,173 @@
+/*
+ * QEMU Guest Agent worker thread interfaces
+ *
+ * Copyright IBM Corp. 2011
+ *
+ * Authors:
+ * Michael Roth
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "guest-agent.h"
+#include "../error.h"
Oh dear! do not do that please! Fix the Makefile to include the
appropriate path.
+struct GAWorker {
+pthread_t thread;
+ga_worker_func execute;
+pthread_mutex_t input_mutex;
+pthread_cond_t input_avail_cond;
+void *input;
+bool input_avail;
+pthread_mutex_t output_mutex;
+pthread_cond_t output_avail_cond;
You really should use QemuMutex and friends here.
+void *output;
+Error *output_error;
+bool output_avail;
+};
+
+static void *worker_run(void *worker_p)
+{
+GAWorker *worker = worker_p;
+Error *err;
+void *input, *output;
+
+while (1) {
+/* wait for input */
+pthread_mutex_lock(&worker->input_mutex);
qemu_mutex_lock()
+while (!worker->input_avail) {
+pthread_cond_wait(&worker->input_avail_cond,&worker->input_mutex);
+}
again
+input = worker->input;
+worker->input_avail = false;
+pthread_mutex_unlock(&worker->input_mutex);
and again I'll stop. Basically there really should be no references
to pthread_*
This is on the guest side of things where I'm trying to use GLib
wherever possible to keep things somewhat portable: logging/list
utilities/io events/etc. And I *really* wanted to use GThreads here, but
the problem is that GThread does not have any sane means to kill off a
thread when a timeout occurs: there's no analogue to pthread_cancel(),
and to use signals you need to break the abstraction to get the
underlying pid. The new QemuThread stuff is using GThread underneath the
covers so same limitation there.
pthreads provides these things and is fairly portable however, so I
opted to make it an explicit dependency on the guest side. So
glib+pthreads are the current dependencies.
Jes
Re: [Qemu-devel] [RFC][PATCH v2 12/17] guest agent: worker thread class
On 04/21/11 15:15, Michael Roth wrote: > On 04/21/2011 03:44 AM, Jes Sorensen wrote: >> and again I'll stop. Basically there really should be no references >> to pthread_* > > This is on the guest side of things where I'm trying to use GLib > wherever possible to keep things somewhat portable: logging/list > utilities/io events/etc. And I *really* wanted to use GThreads here, but > the problem is that GThread does not have any sane means to kill off a > thread when a timeout occurs: there's no analogue to pthread_cancel(), > and to use signals you need to break the abstraction to get the > underlying pid. The new QemuThread stuff is using GThread underneath the > covers so same limitation there. > > pthreads provides these things and is fairly portable however, so I > opted to make it an explicit dependency on the guest side. So > glib+pthreads are the current dependencies. That is really unfortunate - is there no way around it? It really would be ideal if we could build the guest relying on QemuThreads for portability. Either way, please fix the include issue. Jes
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: > On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: > > > On 04/20/2011 08:46 AM, Tristan Gingold wrote: > >> Right, but you could create an ev67 machine with a single PCI > >> controller (or put all the devices on the same PCI controller). > > > > Even the lowly ds10 has two hoses. > > > > I'll admit I hadn't considered engineering the second hose to > > be "present" but always appear empty. It's something to consider. > > > >> Ah, ok I understand. I fear that if you implement your own ISR, you will > >> only be able to boot linux... > >> which I suppose is your primary target. OTOH, it will be much faster than > >> a native ISR. > > > > Yes, Linux is the primary goal. > > > > But I suspect that if I implemented enough of CALL_PAL CSERVE, > > you could boot Tru64, or at least one of the BSDs. > > BSD should be doable, but I doubt for Tru64. Do you have technical doc about > the SRM ? > IIRC, the SRM uses its own palcode and SRM specific pal calls. > The palcode with milo was a subset of the tru64 palcode, I think. Looking at the arch reference manual and assuming that the calls take the same parameters, the only difference is that tru64 has "urti - return from user mode trap" and linux doesn't.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: > On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: >> On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: >> >>> On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). >>> >>> Even the lowly ds10 has two hoses. >>> >>> I'll admit I hadn't considered engineering the second hose to >>> be "present" but always appear empty. It's something to consider. >>> Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. >>> >>> Yes, Linux is the primary goal. >>> >>> But I suspect that if I implemented enough of CALL_PAL CSERVE, >>> you could boot Tru64, or at least one of the BSDs. >> >> BSD should be doable, but I doubt for Tru64. Do you have technical doc >> about the SRM ? >> IIRC, the SRM uses its own palcode and SRM specific pal calls. >> > > The palcode with milo was a subset of the tru64 palcode, I think. > Looking at the arch reference manual and assuming that the calls take > the same parameters, the only difference is that tru64 has "urti - > return from user mode trap" and linux doesn't. Yes, Linux runs on Tru64 palcode. But the issue is booting the Tru64 kernel. Tristan.
Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)
On 04/21/2011 04:46 AM, Jes Sorensen wrote:
On 04/18/11 17:02, Michael Roth wrote:
These apply on top of Anthony's glib tree, commit
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained
from:
git://repo.or.cz/qemu/mdroth.git qga_v2
Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider
pulling these into your glib tree. The json fix-ups may need further
evaluation, but I'm confident they're at least an improvement. The QAPI ones
are mostly trivial fix-ups.
Changes since V1:
- Added guest agent worker thread to execute RPCs in the guest. With this in
place we have a reliable timeout mechanism for hung commands, currently set at
30 seconds.
- Add framework for registering init/cleanup routines for stateful RPCs to
clean up after themselves after a timeout.
- Added the following RPCs: guest-file-{open,close,read,write,seek},
guest-shutdown, guest-info, and removed stubs for guest-view-file (now
deprecated)
- Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
- Switched to a TCP-style host-initiated 3-way handshake for channel
negotiation, this simplifies client negotiation/interaction over the wire
- Added configurable log level/log file/pid file options for guest agent
- Various fixes for bugs/memory leaks and checkpatch.pl fixups
ISSUES/TODOS:
- Fix QMP proxy handling of error responses sent by guest agent, currently
ignored
- Add unit tests for guest agent wire protocol
- Add unit tests for QMP interfaces
- Add host-side timeout mechanism for async QMP commands
- Return error for guest commands if guest up event has not yet been recieved
- Make QMP param names more consistent between related commands
- Clean up logging
Hi,
I had a look through this patchset and generally it looks pretty good.
There were a few nits, and I ignored all the python gibberish to avoid
getting a headache.
Did you do anything with the fsfreeze patches, or were they dropped in
the migration to qapi?
They were pending some changes required on the agent side that weren't
really addressed/doable until this patchset, namely:
1) server-side timeout mechanism to recover from RPCs that can hang
indefinitely or take a really long time (fsfreeze, fopen, etc),
currently it's 30 seconds, may need to bump it to 60 for fsfreeze, or
potentially add an RPC to change the server-side timeout
2) a simple way to temporarily turn off logging so agent doesn't
deadlock itself
3) a way to register a cleanup handler when a timeout occurs.
4) disabling RPCs where proper accounting/logging is required
(guest-open-file, guest-shutdown, etc)
#4 isn't implemented...I think this could be done fairly in-evasively
with something like:
Response important_rpc():
if (!ga_log("syslog", LEVEL_CRITICAL, "important stuff happening"))
return ERROR_LOGGING_CURRENTLY_DISABLED
...
bool ga_log(log_domain, level, msg):
if (log_domain == "syslog")
if (!logging_enabled && is_critical(log_level))
return False;
syslog(msg, ...)
else
if (logging_enabled)
normallog(msg, ...)
return True
With that I think we could actually drop the fsfreeze stuff in. Thoughts?
Cheers,
Jes
Re: [Qemu-devel] [PATCH 1/3] linux-user: Don't use MAP_FIXED in do_brk()
On 18 April 2011 16:34, Peter Maydell wrote: > Since mmap() with MAP_FIXED will map over the top of existing mappings, > it's a bad idea to use it to implement brk(), because brk() with a > large size is likely to overwrite important things like qemu itself > or the host libc. So we drop MAP_FIXED and handle "mapped but at > different address" as an error case instead. I've had a report from Martin Mohring that this patch breaks some programs which previously worked in linux-user mode (one wonders if they were overwriting some chunk of memory that they happened not to be using for anything important...) Anyway, probably better to hold off on applying this patch pending further investigation. Patches 2/3 and 3/3 in this set should still be fine to apply though. -- PMM
[Qemu-devel] Failure to compile latest git (target-i386/kvm.c:953:29: error: variable ‘fop’ set but not used)
Fedora 15beta/x64, latest git: [ykaul@ykaul qemu]$ make CCx86_64-softmmu/kvm.o /home/ykaul/qemu/target-i386/kvm.c: In function ‘kvm_get_xsave’: /home/ykaul/qemu/target-i386/kvm.c:953:29: error: variable ‘fop’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[1]: *** [kvm.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 [ykaul@ykaul qemu]$ gcc --version gcc (GCC) 4.6.0 20110419 (Red Hat 4.6.0-5) - Does happen even though I've used --target-list=x86_64-softmmu - Doesn't happen with --disable-kvm in ./configure. Then I'm getting: /home/ykaul/qemu/tcg/tcg.c: In function ‘tcg_gen_callN’: /home/ykaul/qemu/tcg/tcg.c:589:9: error: variable ‘call_type’ set but not used [-Werror=unused-but-set-variable]
Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)
On 04/18/11 17:02, Michael Roth wrote:
> These apply on top of Anthony's glib tree, commit
> 03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained
> from:
> git://repo.or.cz/qemu/mdroth.git qga_v2
>
> Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider
> pulling these into your glib tree. The json fix-ups may need further
> evaluation, but I'm confident they're at least an improvement. The QAPI ones
> are mostly trivial fix-ups.
>
> Changes since V1:
>
> - Added guest agent worker thread to execute RPCs in the guest. With this in
> place we have a reliable timeout mechanism for hung commands, currently set
> at 30 seconds.
> - Add framework for registering init/cleanup routines for stateful RPCs to
> clean up after themselves after a timeout.
> - Added the following RPCs: guest-file-{open,close,read,write,seek},
> guest-shutdown, guest-info, and removed stubs for guest-view-file (now
> deprecated)
> - Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
> - Switched to a TCP-style host-initiated 3-way handshake for channel
> negotiation, this simplifies client negotiation/interaction over the wire
> - Added configurable log level/log file/pid file options for guest agent
> - Various fixes for bugs/memory leaks and checkpatch.pl fixups
>
> ISSUES/TODOS:
>
> - Fix QMP proxy handling of error responses sent by guest agent, currently
> ignored
> - Add unit tests for guest agent wire protocol
> - Add unit tests for QMP interfaces
> - Add host-side timeout mechanism for async QMP commands
> - Return error for guest commands if guest up event has not yet been recieved
> - Make QMP param names more consistent between related commands
> - Clean up logging
Michael,
One thing I cannot seem to figure out with this tree - the agent
commands do not seem to show up in the monitor? What am I missing?
Cheers,
Jes
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Thu, 2011-04-21 at 15:43 +0200, Tristan Gingold wrote: > On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: > > > On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: > >> On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: > >> > >>> On 04/20/2011 08:46 AM, Tristan Gingold wrote: > Right, but you could create an ev67 machine with a single PCI > controller (or put all the devices on the same PCI controller). > >>> > >>> Even the lowly ds10 has two hoses. > >>> > >>> I'll admit I hadn't considered engineering the second hose to > >>> be "present" but always appear empty. It's something to consider. > >>> > Ah, ok I understand. I fear that if you implement your own ISR, you > will only be able to boot linux... > which I suppose is your primary target. OTOH, it will be much faster > than a native ISR. > >>> > >>> Yes, Linux is the primary goal. > >>> > >>> But I suspect that if I implemented enough of CALL_PAL CSERVE, > >>> you could boot Tru64, or at least one of the BSDs. > >> > >> BSD should be doable, but I doubt for Tru64. Do you have technical doc > >> about the SRM ? > >> IIRC, the SRM uses its own palcode and SRM specific pal calls. > >> > > > > The palcode with milo was a subset of the tru64 palcode, I think. > > Looking at the arch reference manual and assuming that the calls take > > the same parameters, the only difference is that tru64 has "urti - > > return from user mode trap" and linux doesn't. > > Yes, Linux runs on Tru64 palcode. But the issue is booting the Tru64 kernel. > > Tristan. > Ah, gotcha. It almost seems like the console could actually be implemented in qemu itself, rather than a guest side thing, as long as it looks like part III of the ARM :) It might simplify things quite a bit: the console callbacks look like they can be translated into qemu calls and the bootstrapping looks like its a read block zero of selected device + other blocks specified, setup hwrpb and start emulation. It looks like its standard across all OSes, with the possible exception of NT. *shrug* I'm just an innocent bystander, though.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On 04/21/2011 07:48 AM, Brian Wheeler wrote: > On Thu, 2011-04-21 at 15:43 +0200, Tristan Gingold wrote: >> On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: >> >>> On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: > On 04/20/2011 08:46 AM, Tristan Gingold wrote: BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. IIRC the main thing that was lacking between SRM and the Evaluation Board PALcode that was used in MILO is the Console Callback (CCB) structure and routines. > Ah, gotcha. It almost seems like the console could actually be > implemented in qemu itself, rather than a guest side thing, as long as > it looks like part III of the ARM :) My first try last year was going down this path. It turned out to be irritatingly difficult to manage the data setup inside QEMU itself. Thus I came to be writing a custom PALcode image that makes a number of simplifying assumptions based on the ability to off-load some work to QEMU. r~
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko wrote: >>> Do you have public test case? >>> It is possible to code this delay slot write test but real issue may >>> be corruption elsewhere. The test case is trivial: it's just the two instructions, branch and wrpr. > In theory there could be multiple issues including compiler induced ones. > I'd prefer to see some kind of reproducible testcase. Ok, attached a 40 byte long test (the first 32 bytes are not used and needed only because the bios entry point is 0x20). $ git pull && make && sparc64-softmmu/qemu-system-sparc64 -bios test-wrpr.bin -nographic Already up-to-date. make[1]: Nothing to be done for `all'. /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error Aborted HTH, Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ test-wrpr.bin Description: Binary data
Re: [Qemu-devel] Failure to compile latest git (target-i386/kvm.c:953:29: error: variable ‘fop’ set but not used)
On Thu, Apr 21, 2011 at 3:10 PM, Yaniv Kaul wrote: > Fedora 15beta/x64, latest git: > [ykaul@ykaul qemu]$ make > CC x86_64-softmmu/kvm.o > /home/ykaul/qemu/target-i386/kvm.c: In function ‘kvm_get_xsave’: > /home/ykaul/qemu/target-i386/kvm.c:953:29: error: variable ‘fop’ set but not > used [-Werror=unused-but-set-variable] > cc1: all warnings being treated as errors > > make[1]: *** [kvm.o] Error 1 > make: *** [subdir-x86_64-softmmu] Error 2 > > > [ykaul@ykaul qemu]$ gcc --version > gcc (GCC) 4.6.0 20110419 (Red Hat 4.6.0-5) > > > - Does happen even though I've used --target-list=x86_64-softmmu > > - Doesn't happen with --disable-kvm in ./configure. > > Then I'm getting: > > /home/ykaul/qemu/tcg/tcg.c: In function ‘tcg_gen_callN’: > /home/ykaul/qemu/tcg/tcg.c:589:9: error: variable ‘call_type’ set but not > used [-Werror=unused-but-set-variable] Hi Yaniv, Do you want to take a stab at fixing these warnings and sending patches? http://wiki.qemu.org/Contribute/SubmitAPatch If these warnings are preventing you from using QEMU, try: $ ./configure --disable-werror Stefan
Re: [Qemu-devel] Failure to compile latest git (target-i386/kvm.c:953:29: error: variable ‘fop’ set but not used)
On 2011-04-21 16:10, Yaniv Kaul wrote: > Fedora 15beta/x64, latest git: > [ykaul@ykaul qemu]$ make > CCx86_64-softmmu/kvm.o > /home/ykaul/qemu/target-i386/kvm.c: In function ‘kvm_get_xsave’: > /home/ykaul/qemu/target-i386/kvm.c:953:29: error: variable ‘fop’ set but > not used [-Werror=unused-but-set-variable] > cc1: all warnings being treated as errors > > make[1]: *** [kvm.o] Error 1 > make: *** [subdir-x86_64-softmmu] Error 2 > This one looks a bit suspicious: Avi, why do we have kvm_fpu::last_* in the ABI, copying that information from/to user land, but do not handle it otherwise? To my understanding this fop here in xsave corresponds to kvm_fpu::last_opcode in the SET/GET_FPU case, right? It's set to 0 on SET_XSAVE and ignored on GET_XSAVE as this warnings tells us. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko wrote: > On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko > wrote: Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. > > The test case is trivial: it's just the two instructions, branch and wrpr. > >> In theory there could be multiple issues including compiler induced ones. >> I'd prefer to see some kind of reproducible testcase. > > Ok, attached a 40 byte long test (the first 32 bytes are not used and > needed only because the bios entry point is 0x20). > > $ git pull && make && sparc64-softmmu/qemu-system-sparc64 -bios > test-wrpr.bin -nographic > Already up-to-date. > make[1]: Nothing to be done for `all'. > /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error > Aborted The problem seems to be that wrpr is using a non-local TCG tmp (cpu_tmp0). Laurent
[Qemu-devel] [PATCH] target-arm: Minimal implementation of performance counters
Newer Linux kernels assume the existence of the performance counter
cp15 registers. Provide a minimal implementation of these registers.
We support no events. This should be compliant with the ARM ARM,
except that we don't implement the cycle counter.
Signed-off-by: Peter Maydell
---
This is the last fix required to be able to boot a stock Linaro
versatile express image on upstream QEMU...
target-arm/cpu.h |8 ++-
target-arm/helper.c| 159
target-arm/machine.c | 12
target-arm/translate.c | 20 ++-
4 files changed, 183 insertions(+), 16 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index d5af644..b8e7419 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -129,6 +129,12 @@ typedef struct CPUARMState {
uint32_t c7_par; /* Translation result. */
uint32_t c9_insn; /* Cache lockdown registers. */
uint32_t c9_data;
+uint32_t c9_pmcr; /* performance monitor control register */
+uint32_t c9_pmcnten; /* perf monitor counter enables */
+uint32_t c9_pmovsr; /* perf monitor overflow status */
+uint32_t c9_pmxevtyper; /* perf monitor event type */
+uint32_t c9_pmuserenr; /* perf monitor user enable */
+uint32_t c9_pminten; /* perf monitor interrupt enables */
uint32_t c13_fcse; /* FCSE PID. */
uint32_t c13_context; /* Context ID. */
uint32_t c13_tls1; /* User RW Thread register. */
@@ -434,7 +440,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
#define cpu_signal_handler cpu_arm_signal_handler
#define cpu_list arm_cpu_list
-#define CPU_SAVE_VERSION 3
+#define CPU_SAVE_VERSION 4
/* MMU modes definitions */
#define MMU_MODE0_SUFFIX _kernel
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 62ae72e..b051b8c 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -270,6 +270,10 @@ void cpu_reset(CPUARMState *env)
}
env->vfp.xregs[ARM_VFP_FPEXC] = 0;
env->cp15.c2_base_mask = 0xc000u;
+/* v7 performance monitor control register: same implementor
+ * field as main ID register, and we implement no event counters.
+ */
+env->cp15.c9_pmcr = (id & 0xff00);
#endif
set_flush_to_zero(1, &env->vfp.standard_fp_status);
set_flush_inputs_to_zero(1, &env->vfp.standard_fp_status);
@@ -1587,6 +1591,81 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
case 1: /* TCM memory region registers. */
/* Not implemented. */
goto bad_reg;
+case 12: /* Performance monitor control */
+/* Performance monitors are implementation defined in v7,
+ * but with an ARM recommended set of registers, which we
+ * follow (although we don't actually implement any counters)
+ */
+if (!arm_feature(env, ARM_FEATURE_V7)) {
+goto bad_reg;
+}
+switch (op2) {
+case 0: /* performance monitor control register */
+/* only the DP, X, D and E bits are writable */
+env->cp15.c9_pmcr &= ~0x39;
+env->cp15.c9_pmcr |= (val & 0x39);
+break;
+case 1: /* Count enable set register */
+val &= (1 << 31);
+env->cp15.c9_pmcnten |= val;
+break;
+case 2: /* Count enable clear */
+val &= (1 << 31);
+env->cp15.c9_pmcnten &= ~val;
+break;
+case 3: /* Overflow flag status */
+env->cp15.c9_pmovsr &= ~val;
+break;
+case 4: /* Software increment */
+/* RAZ/WI since we don't implement the software-count event */
+break;
+case 5: /* Event counter selection register */
+/* Since we don't implement any events, writing to this
register
+ * is actually UNPREDICTABLE. So we choose to RAZ/WI.
+ */
+break;
+default:
+goto bad_reg;
+}
+break;
+case 13: /* Performance counters */
+if (!arm_feature(env, ARM_FEATURE_V7)) {
+goto bad_reg;
+}
+switch (op2) {
+case 0: /* Cycle count register: not implemented, so RAZ/WI */
+break;
+case 1: /* Event type select */
+env->cp15.c9_pmxevtyper = val & 0xff;
+break;
+case 2: /* Event count register */
+/* Unimplemented (we have no events), RAZ/WI */
+break;
+default:
+goto bad_reg;
+}
+break;
+case 14: /* Performance monitor control */
+if (!arm_feature(env, ARM_FEATURE_V7)) {
+goto bad_reg;
+}
+switch (op2) {
+case 0: /
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support
I still get the same error: akhaleel@depot5 qemu_0.14_q35 $ git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack : : error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb while processing commit . rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/clone-tmp': Directory not empty _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org Sent: Wed, 20 Apr 2011 21:07:46 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support Okay. Can you please try git clone again? On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > Something is still wrong, > > I get the following errors now: > > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > Adnan > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > [mailto:ad...@khaleel.us] > Cc: qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci > express support > > I forgot to changet its HEAD. Now it's fixed. > So please change the branch manually or clone the repo again. > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > This patch series adds basic q35 chipset support for native pci > express > > > > > support. Some bios related patches are still needed. > > > > > For those who want to try it, the following repo is avaiable. > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > seabios > > > > > > > > Hi, > > > > > > > > When I visit the links, the pages say 'You dont have permission'. > Could > > > > you make these git-repos avaiable again? Thanks in advance. > > > > > > The link is not for human-reading. Just issue the git command. > > > > Done. Thanks:) > > > > > -- > > > yamahata > > > > -- > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native?pci?express support
git clone works for me. Hmmm git installation issue? My git is $ git --version git version 1.7.1.1 thanks, On Thu, Apr 21, 2011 at 11:12:37AM -0500, Adnan Khaleel wrote: > I still get the same error: > > akhaleel@depot5 qemu_0.14_q35 $ git clone > http://people.valinux.co.jp/~yamahata > /qemu/q35/20110316/qemu > Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/ > 20110316/qemu/ > Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu/ > Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > : > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory > `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Adnan Khaleel [mailto:ad...@khaleel.us] > Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 21:07:46 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native > pci? > express support > > Okay. Can you please try git clone again? > > On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > > Something is still wrong, > > > > I get the following errors now: > > > > : > > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from > /users > / > > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under > http:// > > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > > while processing commit . > > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/ > qemu_0.14_q35/ > > qemu/.git/clone-tmp': Directory not empty > > > > Adnan > > > > > > ? > > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > > [mailto:ad...@khaleel.us] > > Cc: qemu-devel@nongnu.org > > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native > pci > > express support > > > > I forgot to changet its HEAD. Now it's fixed. > > So please change the branch manually or clone the repo again. > > > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > > This patch series adds basic q35 chipset support for native pci > > express > > > > > > support. Some bios related patches are still needed. > > > > > > For those who want to try it, the following repo is avaiable. > > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > > > git clone > http://people.valinux.co.jp/~yamahata/qemu/q35/20110316 > / > > qemu > > > > > > git clone > http://people.valinux.co.jp/~yamahata/qemu/q35/20110316 > / > > seabios > > > > > > > > > > Hi, > > > > > > > > > > When I visit the links, the pages say 'You dont have permission'. > > Could > > > > > you make these git-repos avaiable again? Thanks in advance. > > > > > > > > The link is not for human-reading. Just issue the git command. > > > > > > Done. Thanks:) > > > > > > > -- > > > > yamahata > > > > > > > -- > > yamahata > > > > -- > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native?pci?express support
Yes, it was a git version conflict. Thanks. Adnan _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org Sent: Thu, 21 Apr 2011 11:38:36 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native?pci?express support git clone works for me. Hmmm git installation issue? My git is $ git --version git version 1.7.1.1 thanks, On Thu, Apr 21, 2011 at 11:12:37AM -0500, Adnan Khaleel wrote: > I still get the same error: > > akhaleel@depot5 qemu_0.14_q35 $ git clone http://people.valinux.co.jp/~yamahata > /qemu/q35/20110316/qemu > Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/ > 20110316/qemu/ > Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu/ > Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > : > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Adnan Khaleel [mailto:ad...@khaleel.us] > Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 21:07:46 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci? > express support > > Okay. Can you please try git clone again? > > On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > > Something is still wrong, > > > > I get the following errors now: > > > > : > > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users > / > > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under > http:// > > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > > while processing commit . > > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/ > qemu_0.14_q35/ > > qemu/.git/clone-tmp': Directory not empty > > > > Adnan > > > > > > ? > > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > > [mailto:ad...@khaleel.us] > > Cc: qemu-devel@nongnu.org > > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native > pci > > express support > > > > I forgot to changet its HEAD. Now it's fixed. > > So please change the branch manually or clone the repo again. > > > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > > This patch series adds basic q35 chipset support for native pci > > express > > > > > > support. Some bios related patches are still needed. > > > > > > For those who want to try it, the following repo is avaiable. > > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316 > / > > qemu > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316 > / > > seabios > > > > > > > > > > Hi, > > > > > > > > > > When I visit the links, the pages say 'You dont have permission'. > > Could > > > > > you make these git-repos avaiable again? Thanks in advance. > > > > > > > > The link is not for human-reading.
[Qemu-devel] KVM Forum 2011: Call For Participation
= KVM Forum 2011: Call For Participation August 15-16, 2011 - Hyatt Regency Vancouver - Vancouver, Canada = KVM is an industry leading open source hypervisor that provides an ideal platform for datacenter virtualization, virtual desktop infrastructure, and cloud computing. Once again, it's time to bring together the community of developers and users that define the KVM ecosystem for our annual technical conference. We will discuss the current state of affairs and plan for the future of KVM, its surrounding infrastructure, and management tools. So mark your calendar and join us in advancing KVM. http://events.linuxfoundation.org/events/kvm-forum/ We are colocated with The Linux Foundation's LinuxCon again this year. KVM Forum attendees will be eligible to attend LinuxCon for a discounted rate. http://events.linuxfoundation.org/events/kvm-forum/register We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2011. http://events.linuxfoundation.org/cfp Suggested topics: KVM - Scaling and performance - Nested virtualization - I/O improvements - PCI device assignment - Driver domains - Time keeping - Resource management (cpu, memory, i/o) - Memory management (page sharing, swapping, huge pages, etc) - Fault tolerance - VEPA, VN-Link, vswitch - Security QEMU - Device model improvements - New devices - Scaling and performance - Desktop virtualization - Spice - Increasing robustness and hardening - Security model - Management interfaces - QMP protocol and implementation - Image formats - Live migration - Live snapshots and merging Virtio - Speeding up existing devices - Alternatives - Virtio on non-Linux Management infrastructure - Libvirt - KVM autotest - OpenStack - Network virtualization management - Enterprise storage management Cloud computing - Scalable storage - Virtual networking - Security - Provisioning - Hybrid SUBMISSION REQUIREMENTS Abstracts due: May 16th, 2011 Notification: May 31th, 2011 Please submit a short abstract (~150 words) describing your presentation proposal. In your submission please note how long your talk will take. Slots vary in length up to 45 minutes. Also include in your proposal the proposal type -- one of: - technical talk - end-user talk - BOF (birds of a feather) session Sumbit your proposal here: http://events.linuxfoundation.org/cfp You will receive a notification whether or not your presentation proposal was accepted by May 31st. END-USER COLLABORATION One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user collaboration proposal. As and end user, this is a unique opportunity to get your input to developers. BOF SESSION We will reserve some slots in the evening after the main conference tracks, for birds of a feather sessions. These sessions will be less formal than presentation tracks and targetted for people who would like to discuss specific issues with other developers and/or users. If you are interested in getting developers and/or uses together to discuss a specific problem, please submit a BOF proposal. LIGHTNING TALKS In addition to submitted talks we will also have some room for lightning talks. These are short (5 minute) discussions to highlight new work or ideas that aren't complete enough to warrant a full presentation slot. Lightning talk submissions and scheduling will be handled on-site at KVM Forum. HOTEL / TRAVEL The KVM Forum 2011 will be held in Vancouver BC at the Hyatt Regency Vancouver. http://events.linuxfoundation.org/events/kvm-forum/travel Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2011 in August! Thanks, your KVM Forum 2011 Program Commitee Please contact us with any questions or comments. kvm-forum-2011...@redhat.com
Re: [Qemu-devel] [PATCH] configure: Support --target-list=? to list available targets
Am 21.04.2011 15:10, schrieb Peter Maydell: Add support for getting configure to print the list of all targets that can be built, via the option '--target-list=?'. Signed-off-by: Peter Maydell --- Yes, you can get the list of targets by running configure without any arguments and then scrolling up to find the target list in the screenful of output, but I think this is a bit more user-friendly. configure | 36 ++-- 1 files changed, 22 insertions(+), 14 deletions(-) The qemu executable supports this use pattern (-cpu ?), but it's unusual for configure. Other options (--audio-drv-list=LIST, --audio-card-list=LIST) show the available values in the help message (configure --help). What about a similar help text for --target-list? Like this: --target-list=LIST set target list [] Available targets: i386-softmmu ... i386-linux-user ... Users would not have to call configure twice to get the list of available targets (the first call is configure --help because they don't know whether it is --target, --targets, --targetlist or --target-list).
Re: [Qemu-devel] Supporting emulation of IOMMUs
On Thu, Apr 21, 2011 at 05:03:47PM +1000, David Gibson wrote: > A few months ago, Eduard - Gabriel Munteanu posted a series of patches > implementing support for emulating the AMD PCI IOMMU > (http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg03196.html). > > In fact, this series implemented a general DMA/IOMMU layer which can > be used by any device model, and one translation backend for this > implementing the AMD specific PCI IOMMU. > > These patches don't seem to have gone anywhere for the last few > months, however, and so far I've been unable to contact the author > (trying again with this mail). > > I have an interest in this code, because the pSeries machine will also > need IOMMU emulation support. At present we only support virtual > devices, through the PAPR interface, and we have support for the > hypervisor-controller IOMMU translation in the PAPR VIO code. > However, we want to add PCI device support and this will also need > IOMMU translation. > > The series seems to have the right basic approach, so if the author is > indeed MIA, I was planning to pick up the patches and resubmit them > (with support for the pSeries IOMMU added). Hi, Not really MIA, but I've been a bit busy lately, so I'm sorry if I couldn't answer your mail in a timely fashion. I'll try making another merge attempt tonight/tomorrow. > Before I do that, I was hoping to get some consensus that this is the > right way to go. For reference, I have an updated version of the > first patch (which adds the core IOMMU layer) below. Some developers expressed a few concerns during my last merge attempt, I'm going to go through them and see if they have been solved. > From: Eduard - Gabriel Munteanu > Date: Fri, 4 Feb 2011 01:32:55 +0200 > Subject: [PATCH] Generic DMA memory access interface > > This introduces replacements for memory access functions like > cpu_physical_memory_read(). The new interface can handle address > translation and access checking through an IOMMU. > > David Gibson: I have made several bugfixes and cleanups to Eduard's > original patch. > > * dma_memory_rw() was incorrectly using (uninitialized) plen instead >of len in the fallback to no-IOMMU case. > > * the dma_memory_map() tracking was storing the guest physical >address of each mapping, but not the qemu user virtual address. >However in unmap() it was then attempting to lookup by virtual >using a completely bogus cast. Thanks. Map invalidation didn't get much testing, maybe figuring out a way to trigger it from a guest would be nice, say a testcase. > * The dma_memory_rw() function is moved from dma_rw.h to dma_rw.c, it >was a bit too much code for an inline. > > * IOMMU support is now available on all target platforms, not just >i386, but is configurable (--enable-iommu/--disable-iommu). Stubs >are used so that individual drivers can use the new dma interface >and it will turn into old-style cpu physical accesses at no cost on >IOMMU-less builds. My impression was people were in favor of having the IOMMU code always built in (and go through the direct cpu_physical_* when not configured by the guest). And perhaps poison the old interfaces once everything goes through the new DMA layer. I'm okay any way, though. > Signed-off-by: Eduard - Gabriel Munteanu > Signed-off-by: David Gibson > --- > Makefile.target |1 + > configure | 12 > hw/dma_rw.c | 147 +++ > hw/dma_rw.h | 156 > +++ > 4 files changed, 316 insertions(+), 0 deletions(-) > create mode 100644 hw/dma_rw.c > create mode 100644 hw/dma_rw.h > > diff --git a/Makefile.target b/Makefile.target > index 95f5eda..c3d36c6 100644 > --- a/Makefile.target > +++ b/Makefile.target > @@ -198,6 +198,7 @@ obj-$(CONFIG_REALLY_VIRTFS) += virtio-9p.o > obj-y += rwhandler.o > obj-$(CONFIG_KVM) += kvm.o kvm-all.o > obj-$(CONFIG_NO_KVM) += kvm-stub.o > +obj-$(CONFIG_IOMMU) += dma_rw.o > LIBS+=-lz > > QEMU_CFLAGS += $(VNC_TLS_CFLAGS) > diff --git a/configure b/configure > index da2da04..fa6f4d5 100755 > --- a/configure > +++ b/configure > @@ -130,6 +130,7 @@ xen="" > linux_aio="" > attr="" > vhost_net="" > +iommu="no" > xfs="" > > gprof="no" > @@ -723,6 +724,10 @@ for opt do >;; >--enable-vhost-net) vhost_net="yes" >;; > + --enable-iommu) iommu="yes" > + ;; > + --disable-iommu) iommu="no" > + ;; >--disable-opengl) opengl="no" >;; >--enable-opengl) opengl="yes" > @@ -934,6 +939,8 @@ echo " --enable-docsenable documentation > build" > echo " --disable-docs disable documentation build" > echo " --disable-vhost-net disable vhost-net acceleration support" > echo " --enable-vhost-net enable vhost-net acceleration support" > +echo " --disable-iommu disable IOMMU emulation support" > +echo " --enable-vhost-net enable IOMMU emula
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues wrote: > On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko wrote: >> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >> wrote: > Do you have public test case? > It is possible to code this delay slot write test but real issue may > be corruption elsewhere. >> >> The test case is trivial: it's just the two instructions, branch and wrpr. >> >>> In theory there could be multiple issues including compiler induced ones. >>> I'd prefer to see some kind of reproducible testcase. >> >> Ok, attached a 40 byte long test (the first 32 bytes are not used and >> needed only because the bios entry point is 0x20). >> >> $ git pull && make && sparc64-softmmu/qemu-system-sparc64 -bios >> test-wrpr.bin -nographic >> Already up-to-date. >> make[1]: Nothing to be done for `all'. >> /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error >> Aborted > > The problem seems to be that wrpr is using a non-local > TCG tmp (cpu_tmp0). Just tried the test case with write to %pil - seems like write itself is OK. The issue appears to be with save_state() call since adding save_state to %pil case provokes the same tcg abort. -- Kind regards, Igor V. Kovalenko
[Qemu-devel] iSCSI support for QEMU, update
iSCSI block driver for QEMU Please find an updated iSCSI patch. This patch adds setting FUA on all writes when the bit BDRV_O_CACHE_WB is not set. regards ronnie sahlberg From: Ronnie Sahlberg Subject: iSCSI support for QEMU, update In-Reply-To:
[Qemu-devel] [PATCH] iSCSI block driver support
From: Ronnie Sahlberg
This patch adds a new block driver : block.iscsi.c
This driver interfaces with the multiplatform posix library
for iscsi initiator/client access to iscsi devices hosted at
git://github.com/sahlberg/libiscsi.git
The patch adds the driver to interface with the iscsi library.
It also updated the configure script to
* by default, probe is libiscsi is available and if so, build
qemu against libiscsi.
* --enable-libiscsi
Force a build against libiscsi. If libiscsi is not available
the build will fail.
* --disable-libiscsi
Do not link against libiscsi, even if it is available.
When linked with libiscsi, qemu gains support to access iscsi resources
such as disks and cdrom directly, without having to make the devices visible
to the host.
You can specify devices using a iscsi url of the form :
iscsi://[[:@]][:/
When using authentication, the password can optionally be set with
LIBISCSI_CHAP_PASSWORD="password" to avoid it showing up in the process list
Example:
-drive file=iscsi://10.1.1.1:3260/iqn.ronnie.test/1
Signed-off-by: Ronnie Sahlberg
---
Makefile.objs |1 +
block/iscsi.c | 596 +
configure | 31 +++
trace-events |6 +
4 files changed, 634 insertions(+), 0 deletions(-)
create mode 100644 block/iscsi.c
diff --git a/Makefile.objs b/Makefile.objs
index 44ce368..8403c66 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -25,6 +25,7 @@ block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
block-nested-$(CONFIG_POSIX) += raw-posix.o
+block-nested-$(CONFIG_LIBISCSI) += iscsi.o
block-nested-$(CONFIG_CURL) += curl.o
block-nested-$(CONFIG_RBD) += rbd.o
diff --git a/block/iscsi.c b/block/iscsi.c
new file mode 100644
index 000..a21ff70
--- /dev/null
+++ b/block/iscsi.c
@@ -0,0 +1,596 @@
+/*
+ * QEMU Block driver for iSCSI images
+ *
+ * Copyright (c) 2010 Ronnie Sahlberg
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "config-host.h"
+
+#include
+#include "sysemu.h"
+#include "qemu-common.h"
+#include "qemu-error.h"
+#include "block_int.h"
+#include "trace.h"
+
+#include
+#include
+
+
+typedef struct IscsiLun {
+struct iscsi_context *iscsi;
+int lun;
+int block_size;
+unsigned long num_blocks;
+} IscsiLun;
+
+typedef struct IscsiAIOCB {
+BlockDriverAIOCB common;
+QEMUIOVector *qiov;
+QEMUBH *bh;
+IscsiLun *iscsilun;
+struct scsi_task *task;
+uint8_t *buf;
+int canceled;
+int status;
+size_t read_size;
+size_t read_offset;
+} IscsiAIOCB;
+
+struct IscsiTask {
+IscsiLun *iscsilun;
+int status;
+int complete;
+};
+
+static void
+iscsi_abort_task_cb(struct iscsi_context *iscsi, int status, void
*command_data,
+ void *private_data)
+{
+}
+
+static void
+iscsi_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+IscsiAIOCB *acb = (IscsiAIOCB *)blockacb;
+IscsiLun *iscsilun = acb->iscsilun;
+
+acb->status = -ECANCELED;
+acb->common.cb(acb->common.opaque, acb->status);
+acb->canceled = 1;
+
+iscsi_task_mgmt_abort_task_async(iscsilun->iscsi, acb->task,
+ iscsi_abort_task_cb, NULL);
+}
+
+static AIOPool iscsi_aio_pool = {
+.aiocb_size = sizeof(IscsiAIOCB),
+.cancel = iscsi_aio_cancel,
+};
+
+
+static void iscsi_process_read(void *arg);
+static void iscsi_process_write(void *arg);
+
+static int iscsi_process_flush(void *arg)
+{
+IscsiLun *iscsilun = arg;
+
+return iscsi_queue_length(iscsilun->iscsi) > 0;
+}
+
+static void
+iscsi_set_events(IscsiLun *iscsilun)
+{
+struct iscsi_context *iscsi = iscsilun->iscsi;
+
+qemu_aio_set_fd_handler(iscsi_get_fd(iscsi), iscsi_process_read,
+ (iscsi_which_events(iscsi) & POLLOUT)
+ ? iscsi_process_write : NULL,
+
Re: [Qemu-devel] iSCSI support for QEMU
On Thu, Apr 21, 2011 at 10:49 PM, Christoph Hellwig wrote: > On Thu, Apr 21, 2011 at 09:36:12PM +1000, ronnie sahlberg wrote: >> There are some high-volume arrays that advertise support but fail any >> cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional. > > Which on would that be? Linux uses the FUA bit if the device advertises > support > via the DPOFUA bit since 2005, and prints a warning if a FUA write fails, > and since last year even fails the request hard. I'd be really surprised > if a common device fails FUA writes and we didn't know about it by now. > > Either way you'll have to still guarantee data made it to non-volatile > storage for cache=writethrough mode, either by disabling the WCE bit > using MODE SELECT, or by flushing the cache after every write. > Thankyou for your patience. I understand and I have updated the patch to set FUA when the _WB flag is not set. regards ronnie sahlberg
Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)
On 04/21/2011 09:10 AM, Jes Sorensen wrote:
On 04/18/11 17:02, Michael Roth wrote:
These apply on top of Anthony's glib tree, commit
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained
from:
git://repo.or.cz/qemu/mdroth.git qga_v2
Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider
pulling these into your glib tree. The json fix-ups may need further
evaluation, but I'm confident they're at least an improvement. The QAPI ones
are mostly trivial fix-ups.
Changes since V1:
- Added guest agent worker thread to execute RPCs in the guest. With this in
place we have a reliable timeout mechanism for hung commands, currently set at
30 seconds.
- Add framework for registering init/cleanup routines for stateful RPCs to
clean up after themselves after a timeout.
- Added the following RPCs: guest-file-{open,close,read,write,seek},
guest-shutdown, guest-info, and removed stubs for guest-view-file (now
deprecated)
- Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
- Switched to a TCP-style host-initiated 3-way handshake for channel
negotiation, this simplifies client negotiation/interaction over the wire
- Added configurable log level/log file/pid file options for guest agent
- Various fixes for bugs/memory leaks and checkpatch.pl fixups
ISSUES/TODOS:
- Fix QMP proxy handling of error responses sent by guest agent, currently
ignored
- Add unit tests for guest agent wire protocol
- Add unit tests for QMP interfaces
- Add host-side timeout mechanism for async QMP commands
- Return error for guest commands if guest up event has not yet been recieved
- Make QMP param names more consistent between related commands
- Clean up logging
Michael,
One thing I cannot seem to figure out with this tree - the agent
commands do not seem to show up in the monitor? What am I missing?
Hmm, for some reason this email never hit my inbox.
You mean with the human monitor? Currently, with these new patches,
we're QMP only. And most of the command names/semantics have changed as
well. The qapi-schema.json changes in patch 16 have the new prototypes,
and the 0 patch has some usage examples.
Cheers,
Jes
Re: [Qemu-devel] [PATCH] iSCSI block driver support
List, This updated version of the patch adds setting FUA on all writes unless the writeback flag is set. regards ronnie sahlberg
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko wrote: > On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues > wrote: >> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko >> wrote: >>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>> wrote: >> Do you have public test case? >> It is possible to code this delay slot write test but real issue may >> be corruption elsewhere. >>> >>> The test case is trivial: it's just the two instructions, branch and wrpr. >>> In theory there could be multiple issues including compiler induced ones. I'd prefer to see some kind of reproducible testcase. >>> >>> Ok, attached a 40 byte long test (the first 32 bytes are not used and >>> needed only because the bios entry point is 0x20). >>> >>> $ git pull && make && sparc64-softmmu/qemu-system-sparc64 -bios >>> test-wrpr.bin -nographic >>> Already up-to-date. >>> make[1]: Nothing to be done for `all'. >>> /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error >>> Aborted >> >> The problem seems to be that wrpr is using a non-local >> TCG tmp (cpu_tmp0). > > Just tried the test case with write to %pil - seems like write itself is OK. > The issue appears to be with save_state() call since adding save_state > to %pil case provokes the same tcg abort. The problem is that cpu_tmp0, not being a local tmp, doesn't need to be saved across helper calls. This results in the TCG "optimizer" getting rid of it even though it's later used. Look at the log and you'll see what I mean :-) Laurent
Re: [Qemu-devel] [PATCH] configure: Support --target-list=? to list available targets
On 21 April 2011 18:45, Stefan Weil wrote: > Am 21.04.2011 15:10, schrieb Peter Maydell: >> Add support for getting configure to print the list of all targets >> that can be built, via the option '--target-list=?'. > The qemu executable supports this use pattern (-cpu ?), > but it's unusual for configure. > > Other options (--audio-drv-list=LIST, --audio-card-list=LIST) > show the available values in the help message (configure --help). > > What about a similar help text for --target-list? Like this: > > --target-list=LIST set target list [] > Available targets: i386-softmmu ... > i386-linux-user ... The "[]" here is wrong, incidentally, because the bit in [] is supposed to be the default value, which for the target list is not "build no targets" but "build all targets". So we could either say: --target-list=LIST set target list (default: build everything) Available targets: i386-softmmu ... i386-linux-user ... or --target-list=LIST set target list [i386-softmmu ... i386-linux-user ...] I vaguely prefer the first but have no strong feelings. The other issue is that the target list is vastly longer than any of the existing lists in the help, so it probably needs something to automatically format it so it doesn't mess up the formatting of the --help message. (We could perhaps support --option=? for all the options that take a list, in addition to giving the supported values in --help, but maybe that's overkill.) -- PMM
[Qemu-devel] [PATCH] net/socket: remove hardcoded packet size in favor of new mtu parameter
Also mention the default value 4096.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I have a driver that sends 4352 byte packets. Tested with tcp socket only.
There's also 4096 byte buffers in vde, but I don't use/test it.
net.c |4
net/socket.c| 54 ++
qemu-options.hx | 11 +++
3 files changed, 49 insertions(+), 20 deletions(-)
diff --git a/net.c b/net.c
index 4f777c3..74dffa3 100644
--- a/net.c
+++ b/net.c
@@ -1000,6 +1000,10 @@ static const struct {
.name = "localaddr",
.type = QEMU_OPT_STRING,
.help = "source address for multicast packets",
+}, {
+.name = "mtu",
+.type = QEMU_OPT_NUMBER,
+.help = "MTU size",
},
{ /* end of list */ }
},
diff --git a/net/socket.c b/net/socket.c
index 7337f4f..99a9b39 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -38,7 +38,8 @@ typedef struct NetSocketState {
int state; /* 0 = getting length, 1 = getting data */
unsigned int index;
unsigned int packet_len;
-uint8_t buf[4096];
+unsigned int mtu;
+uint8_t *buf, *buf1;
struct sockaddr_in dgram_dst; /* contains inet host and port destination
iff connectionless (SOCK_DGRAM) */
} NetSocketState;
@@ -47,6 +48,7 @@ typedef struct NetSocketListenState {
char *model;
char *name;
int fd;
+unsigned int mtu;
} NetSocketListenState;
/* XXX: we consider we can send the whole packet without blocking */
@@ -73,10 +75,10 @@ static void net_socket_send(void *opaque)
NetSocketState *s = opaque;
int size, err;
unsigned l;
-uint8_t buf1[4096];
+uint8_t *buf1 = s->buf1;
const uint8_t *buf;
-size = recv(s->fd, (void *)buf1, sizeof(buf1), 0);
+size = recv(s->fd, (void *)buf1, s->mtu, 0);
if (size < 0) {
err = socket_error();
if (err != EWOULDBLOCK)
@@ -111,7 +113,7 @@ static void net_socket_send(void *opaque)
l = s->packet_len - s->index;
if (l > size)
l = size;
-if (s->index + l <= sizeof(s->buf)) {
+if (s->index + l <= s->mtu) {
memcpy(s->buf + s->index, buf, l);
} else {
fprintf(stderr, "serious error: oversized packet received,"
@@ -138,7 +140,7 @@ static void net_socket_send_dgram(void *opaque)
NetSocketState *s = opaque;
int size;
-size = recv(s->fd, (void *)s->buf, sizeof(s->buf), 0);
+size = recv(s->fd, (void *)s->buf, s->mtu, 0);
if (size < 0)
return;
if (size == 0) {
@@ -238,6 +240,7 @@ static NetClientInfo net_dgram_socket_info = {
};
static NetSocketState *net_socket_fd_init_dgram(VLANState *vlan,
+unsigned int mtu,
const char *model,
const char *name,
int fd, int is_connected)
@@ -288,6 +291,10 @@ static NetSocketState *net_socket_fd_init_dgram(VLANState
*vlan,
s = DO_UPCAST(NetSocketState, nc, nc);
+s->mtu = mtu;
+s->buf = qemu_malloc(s->mtu);
+s->buf1 = qemu_malloc(s->mtu);
+
s->fd = fd;
qemu_set_fd_handler(s->fd, net_socket_send_dgram, NULL, s);
@@ -312,6 +319,7 @@ static NetClientInfo net_socket_info = {
};
static NetSocketState *net_socket_fd_init_stream(VLANState *vlan,
+ unsigned int mtu,
const char *model,
const char *name,
int fd, int is_connected)
@@ -325,6 +333,10 @@ static NetSocketState *net_socket_fd_init_stream(VLANState
*vlan,
s = DO_UPCAST(NetSocketState, nc, nc);
+s->mtu = mtu;
+s->buf = qemu_malloc(s->mtu);
+s->buf1 = qemu_malloc(s->mtu);
+
s->fd = fd;
if (is_connected) {
@@ -335,7 +347,7 @@ static NetSocketState *net_socket_fd_init_stream(VLANState
*vlan,
return s;
}
-static NetSocketState *net_socket_fd_init(VLANState *vlan,
+static NetSocketState *net_socket_fd_init(VLANState *vlan, unsigned int mtu,
const char *model, const char *name,
int fd, int is_connected)
{
@@ -348,13 +360,16 @@ static NetSocketState *net_socket_fd_init(VLANState *vlan,
}
switch(so_type) {
case SOCK_DGRAM:
-return net_socket_fd_init_dgram(vlan, model, name, fd, is_connected);
+return net_socket_fd_init_dgram(vlan, mtu, model, name,
+fd, is_connected);
case SOCK_STREAM:
-return net_socket_fd_init_stream(vlan, model, name, fd, is_connected);
+return net_socket_fd_init_stream(vlan, mtu, model, name,
Re: [Qemu-devel] iSCSI support for QEMU, update
On Fri, Apr 22, 2011 at 06:23:58AM +1000, ronniesahlb...@gmail.com wrote: > iSCSI block driver for QEMU > > Please find an updated iSCSI patch. > This patch adds setting FUA on all writes when the bit > BDRV_O_CACHE_WB is not set. At this point you need to check for BDRV_O_CACHE_WB and BDRV_O_NOCACHE as they both have writeback cache semantics. I submitted a patch to clean that up, but it didn't get merged yet.
Re: [Qemu-devel] iSCSI support for QEMU, update
Thanks, On Fri, Apr 22, 2011 at 2:08 PM, Christoph Hellwig wrote: > On Fri, Apr 22, 2011 at 06:23:58AM +1000, ronniesahlb...@gmail.com wrote: >> iSCSI block driver for QEMU >> >> Please find an updated iSCSI patch. >> This patch adds setting FUA on all writes when the bit >> BDRV_O_CACHE_WB is not set. > > At this point you need to check for BDRV_O_CACHE_WB and BDRV_O_NOCACHE > as they both have writeback cache semantics. I submitted a patch to clean > that up, but it didn't get merged yet. > So I should set FUA when BDRV_O_CACHE_WB==0 or BDRV_O_NOCACHE==1 right? regards ronnie sahlberg
Re: [Qemu-devel] iSCSI support for QEMU, update
On Fri, Apr 22, 2011 at 04:08:57PM +1000, ronnie sahlberg wrote: > So I should set FUA when > BDRV_O_CACHE_WB==0 or BDRV_O_NOCACHE==1 > right? At this point you need to set it if either the BDRV_O_CACHE_WB and BDRV_O_NOCACHE flags are set. And yes, the naming of the nocache flag is rather confusing. Take a look at block.c:bdrv_open_common(): /* * Yes, BDRV_O_NOCACHE aka O_DIRECT means we have to present a * write cache to the guest. We do need the fdatasync to flush * out transactions for block allocations, and we maybe have a * volatile write cache in our backing device to deal with. */ if (flags & (BDRV_O_CACHE_WB|BDRV_O_NOCACHE)) bs->enable_write_cache = 1;
Re: [Qemu-devel] [PATCH] net/socket: remove hardcoded packet size in favor of new mtu parameter
2011/4/22 Nguyễn Thái Ngọc Duy : > @@ -288,6 +291,10 @@ static NetSocketState > *net_socket_fd_init_dgram(VLANState *vlan, > > s = DO_UPCAST(NetSocketState, nc, nc); > > + s->mtu = mtu; > + s->buf = qemu_malloc(s->mtu); > + s->buf1 = qemu_malloc(s->mtu); These need to be freed in net_socket_cleanup(). Stefan
Re: [Qemu-devel] [RFC][PATCH v2 15/17] guest agent: qemu-ga daemon
On 04/21/2011 03:50 AM, Jes Sorensen wrote:
On 04/18/11 17:02, Michael Roth wrote:
+static const char *ga_log_level_str(GLogLevelFlags level)
+{
+switch (level& G_LOG_LEVEL_MASK) {
+case G_LOG_LEVEL_ERROR: return "error";
+case G_LOG_LEVEL_CRITICAL: return "critical";
+case G_LOG_LEVEL_WARNING: return "warning";
+case G_LOG_LEVEL_MESSAGE: return "message";
+case G_LOG_LEVEL_INFO: return "info";
+case G_LOG_LEVEL_DEBUG: return "debug";
+default:return "user";
+}
Urgh!
No two statements on the same line please!
Darn, I was hoping my surplus on coding style points for actually
indenting my case statements would make up for that :)
Jes
Re: [Qemu-devel] iSCSI support for QEMU, update
Ok, I am confused On Fri, Apr 22, 2011 at 4:13 PM, Christoph Hellwig wrote: > On Fri, Apr 22, 2011 at 04:08:57PM +1000, ronnie sahlberg wrote: >> So I should set FUA when >> BDRV_O_CACHE_WB==0 or BDRV_O_NOCACHE==1 >> right? > > At this point you need to set it if either the BDRV_O_CACHE_WB and > BDRV_O_NOCACHE flags are set. And yes, the naming of the nocache > flag is rather confusing. > > Take a look at block.c:bdrv_open_common(): > > /* > * Yes, BDRV_O_NOCACHE aka O_DIRECT means we have to present a > * write cache to the guest. We do need the fdatasync to flush > * out transactions for block allocations, and we maybe have a > * volatile write cache in our backing device to deal with. > */ > if (flags & (BDRV_O_CACHE_WB|BDRV_O_NOCACHE)) > bs->enable_write_cache = 1; > I have to set FUA if the WB(I guessed this meant write-back) flag is set? Not the opposite (I assume opposite of write-back is write-through) ? So that would mean if (flags & (BDRV_O_CACHE_WB|BDRV_O_NOCACHE)) caching is NOT ok, write with FUA=1 else caching is ok, write with FUA=0 right ? regards ronnie sahlberg
Re: [Qemu-devel] iSCSI support for QEMU, update
On Fri, Apr 22, 2011 at 04:35:11PM +1000, ronnie sahlberg wrote: > Ok, I am confused And this time it's my fault, sorry. > I have to set FUA if the WB(I guessed this meant write-back) flag is set? > Not the opposite (I assume opposite of write-back is write-through) ? Sorry, I meant exactly the opposite. You do not have to set FUA if either of those two flags is present, so: if (flags & (BDRV_O_CACHE_WB|BDRV_O_NOCACHE)) caching is ok, write with FUA=0 else caching is NOT ok, write with FUA=1
[Qemu-devel] [PATCH] usb-uhci: Use defines for base address registers, instead of magic numbers
Signed-off-by: Brad Hards
---
hw/usb-uhci.c | 58 ++--
hw/usb.h |6 +
2 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 346db3e..210b918 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -75,6 +75,18 @@
#define NB_PORTS 2
+/* address offsets for PCI config registers - UHCI 1.1d spec Table 2 */
+#define UHCI_REG_USBCMD 0x00
+#define UHCI_REG_USBSTS 0x02
+#define UHCI_REG_USBINTR0x04
+#define UHCI_REG_FRNUM 0x06
+#define UHCI_REG_FLBASEADD 0x08
+#define UHCI_REG_SOF_MOD0x0c
+#define UHCI_REG_PORTSC 0x10
+
+#define UHCI_REG_PORTSC_TOP 0x1F /* last potential Port address */
+#define UHCI_BAR_SIZE 0x20 /* the size of the base address registers */
+
#ifdef DEBUG
#define DPRINTF printf
@@ -407,7 +419,7 @@ static void uhci_ioport_writeb(void *opaque, uint32_t addr,
uint32_t val)
addr &= 0x1f;
switch(addr) {
-case 0x0c:
+case UHCI_REG_SOF_MOD:
s->sof_timing = val;
break;
}
@@ -420,7 +432,7 @@ static uint32_t uhci_ioport_readb(void *opaque, uint32_t
addr)
addr &= 0x1f;
switch(addr) {
-case 0x0c:
+case UHCI_REG_SOF_MOD:
val = s->sof_timing;
break;
default:
@@ -438,7 +450,7 @@ static void uhci_ioport_writew(void *opaque, uint32_t addr,
uint32_t val)
DPRINTF("uhci: writew port=0x%04x val=0x%04x\n", addr, val);
switch(addr) {
-case 0x00:
+case UHCI_REG_USBCMD:
if ((val & UHCI_CMD_RS) && !(s->cmd & UHCI_CMD_RS)) {
/* start frame processing */
qemu_mod_timer(s->frame_timer, qemu_get_clock_ns(vm_clock));
@@ -468,7 +480,7 @@ static void uhci_ioport_writew(void *opaque, uint32_t addr,
uint32_t val)
}
s->cmd = val;
break;
-case 0x02:
+case UHCI_REG_USBSTS:
s->status &= ~val;
/* XXX: the chip spec is not coherent, so we add a hidden
register to distinguish between IOC and SPD */
@@ -476,15 +488,15 @@ static void uhci_ioport_writew(void *opaque, uint32_t
addr, uint32_t val)
s->status2 = 0;
uhci_update_irq(s);
break;
-case 0x04:
+case UHCI_REG_USBINTR:
s->intr = val;
uhci_update_irq(s);
break;
-case 0x06:
+case UHCI_REG_FRNUM:
if (s->status & UHCI_STS_HCHALTED)
s->frnum = val & 0x7ff;
break;
-case 0x10 ... 0x1f:
+case UHCI_REG_PORTSC ... UHCI_REG_PORTSC_TOP:
{
UHCIPort *port;
USBDevice *dev;
@@ -518,19 +530,19 @@ static uint32_t uhci_ioport_readw(void *opaque, uint32_t
addr)
addr &= 0x1f;
switch(addr) {
-case 0x00:
+case UHCI_REG_USBCMD:
val = s->cmd;
break;
-case 0x02:
+case UHCI_REG_USBSTS:
val = s->status;
break;
-case 0x04:
+case UHCI_REG_USBINTR:
val = s->intr;
break;
-case 0x06:
+case UHCI_REG_FRNUM:
val = s->frnum;
break;
-case 0x10 ... 0x1f:
+case UHCI_REG_PORTSC ... UHCI_REG_PORTSC_TOP:
{
UHCIPort *port;
int n;
@@ -560,7 +572,7 @@ static void uhci_ioport_writel(void *opaque, uint32_t addr,
uint32_t val)
DPRINTF("uhci: writel port=0x%04x val=0x%08x\n", addr, val);
switch(addr) {
-case 0x08:
+case UHCI_REG_FLBASEADD:
s->fl_base_addr = val & ~0xfff;
break;
}
@@ -573,7 +585,7 @@ static uint32_t uhci_ioport_readl(void *opaque, uint32_t
addr)
addr &= 0x1f;
switch(addr) {
-case 0x08:
+case UHCI_REG_FLBASEADD:
val = s->fl_base_addr;
break;
default:
@@ -1101,12 +1113,12 @@ static void uhci_map(PCIDevice *pci_dev, int region_num,
{
UHCIState *s = (UHCIState *)pci_dev;
-register_ioport_write(addr, 32, 2, uhci_ioport_writew, s);
-register_ioport_read(addr, 32, 2, uhci_ioport_readw, s);
-register_ioport_write(addr, 32, 4, uhci_ioport_writel, s);
-register_ioport_read(addr, 32, 4, uhci_ioport_readl, s);
-register_ioport_write(addr, 32, 1, uhci_ioport_writeb, s);
-register_ioport_read(addr, 32, 1, uhci_ioport_readb, s);
+register_ioport_write(addr, UHCI_BAR_SIZE, 2, uhci_ioport_writew, s);
+register_ioport_read(addr, UHCI_BAR_SIZE, 2, uhci_ioport_readw, s);
+register_ioport_write(addr, UHCI_BAR_SIZE, 4, uhci_ioport_writel, s);
+register_ioport_read(addr, UHCI_BAR_SIZE, 4, uhci_ioport_readl, s);
+register_ioport_write(addr, UHCI_BAR_SIZE, 1, uhci_ioport_writeb, s);
+register_ioport_read(addr, UHCI_BAR_SIZE, 1, uhci_ioport_readb, s);
}
static USBPortOps uhci_port_ops = {
@@ -1125,7 +1137,7 @@ static int usb_uhci_common_initfn(UHCIState *s)
pci_config_set_class(pci_conf, PCI_CLASS_SERIAL_USB);
/* TODO: reset value should be 0. */
pci_conf[PCI_INTERRUPT_PIN] = 4; // interrupt pin 3
-pci_conf[0x60] = 0x10; //
