[Qemu-devel] help

[Qemu-devel] help

[Carlos Mauricio Moreno Cuevas]

[-- Attachment #1: Type: text/plain, Size: 76 bytes --]

Qemu  and Hp UX is possible, Host  ( Pc Windows XP)

 

Atte.

CMC


[-- Attachment #2: Type: text/html, Size: 2031 bytes --]

Re: [Qemu-devel] help

[Stuart Brady]

On Mon, May 26, 2008 at 04:07:22PM -0400, Carlos Mauricio Moreno Cuevas wrote:
> Qemu  and Hp UX is possible, Host  ( Pc Windows XP)

HP-UX runs on IA-64 and PA-RISC [1], neither of which is emulated by
QEMU, so unfortunately the answer is no.

I made a start on PA-RISC emulation, but there's a lot more work needed
before it will run HP-UX.

KVM is being ported to IA-64, but that requires an IA-64 host.
-- 
Stuart Brady

[1] Older versions also ran on M68K and HP FOCUS.

[Qemu-devel] help

[zdl2004h]

[-- Attachment #1: Type: text/plain, Size: 22482 bytes --]






At 2010-12-17 21:22:29，qemu-devel-request@nongnu.org wrote:

>Send Qemu-devel mailing list submissions to
>	qemu-devel@nongnu.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://lists.nongnu.org/mailman/listinfo/qemu-devel
>or, via email, send a message with subject or body 'help' to
>	qemu-devel-request@nongnu.org
>
>You can reach the person managing the list at
>	qemu-devel-owner@nongnu.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Qemu-devel digest..."
>
>
>Today's Topics:
>
>   1. [PATCH v6 4/4] docs: Document virtio PCI -device
>      ioeventfd=on|off (Stefan Hajnoczi)
>   2. [Bug 680758] Re: balloon only resizes by 2M (a1bert)
>   3. Re: [PATCH 1/1] spice: add chardev (Alon Levy)
>   4. Re: [PATCH v6 0/5] qed: Add QEMU Enhanced Disk format (Kevin Wolf)
>   5. Re: [PATCH v2] ide: Register vm change state handler	once
>      only (Kevin Wolf)
>   6. Re: [PATCH v6 0/5] qed: Add QEMU Enhanced Disk format
>      (Stefan Hajnoczi)
>   7. [PATCH] spice: add chardev (v2) (Alon Levy)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 17 Dec 2010 12:01:52 +0000
>From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>Subject: [Qemu-devel] [PATCH v6 4/4] docs: Document virtio PCI -device
>	ioeventfd=on|off
>To: <qemu-devel@nongnu.org>
>Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,	"Michael S.
>	Tsirkin" <mst@redhat.com>
>Message-ID:
>	<1292587312-24511-5-git-send-email-stefanha@linux.vnet.ibm.com>
>
>Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>---
> docs/qdev-device-use.txt |    8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
>diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
>index f252c8e..f2f9b75 100644
>--- a/docs/qdev-device-use.txt
>+++ b/docs/qdev-device-use.txt
>@@ -97,10 +97,13 @@ The -device argument differs in detail for each kind of drive:
> 
> * if=virtio
> 
>-  -device virtio-blk-pci,drive=DRIVE-ID,class=C,vectors=V
>+  -device virtio-blk-pci,drive=DRIVE-ID,class=C,vectors=V,ioeventfd=IOEVENTFD
> 
>   This lets you control PCI device class and MSI-X vectors.
> 
>+  IOEVENTFD controls whether or not ioeventfd is used for virtqueue notify.  It
>+  can be set to on (default) or off.
>+
>   As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
>   control the PCI device address.
> 
>@@ -240,6 +243,9 @@ For PCI devices, you can add bus=PCI-BUS,addr=DEVFN to control the PCI
> device address, as usual.  The old -net nic provides parameter addr
> for that, it is silently ignored when the NIC is not a PCI device.
> 
>+For virtio-net-pci, you can control whether or not ioeventfd is used for
>+virtqueue notify by setting ioeventfd= to on or off (default).
>+
> -net nic accepts vectors=V for all models, but it's silently ignored
> except for virtio-net-pci (model=virtio).  With -device, only devices
> that support it accept it.
>-- 
>1.7.2.3
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 17 Dec 2010 12:21:10 -0000
>From: a1bert <680758@bugs.launchpad.net>
>Subject: [Qemu-devel] [Bug 680758] Re: balloon only resizes by 2M
>To: qemu-devel@nongnu.org
>Message-ID: <20101217122110.24081.55017.malone@wampee.canonical.com>
>Content-Type: text/plain; charset="utf-8"
>
>the same here:
>
>host debian squeeze: qemu-kvm-0.12.5
>guest: windows 2008 server 
>balloon driver: 6.1.7600.16385  10.8.2010
>
>
>
>~# virsh  -c qemu:///system dominfo 9 | grep Used
>Used memory:    2064384 kB
>~# virsh  -c qemu:///system setmem 9 512000
>
>~# virsh  -c qemu:///system dominfo 9 | grep Used
>Used memory:    2062336 kB
>
>
>the same host,  but winXP guest with the same balloon driver is working, looks like balloon driver issue...
>
>-- 
>You received this bug notification because you are a member of qemu-
>devel-ml, which is subscribed to QEMU.
>https://bugs.launchpad.net/bugs/680758
>
>Title:
>  balloon only resizes by 2M
>
>Status in QEMU:
>  New
>
>Bug description:
>  when in monitor and running balloon 512 from a 1024M VM, the vm dropped the size to 1020 (this value changes), then every subsequent request to balloon 512 will drop it by another 2M.  The system was running at above 60% RAM free when these requests were made.  also requesting to up the ram results in no change above 1024 (I'm guessing this is intentional, but was unable to find any documentation)
>
>Versions:
>
>qemu-kvm 0.13.0
>qemu-kvm.git b377474e589e5a1fe2abc7b13fafa8bad802637a
>
>Qemu Command Line:
>
>./x86_64-softmmu/qemu-system-x86_64 -drive file=/var/machines/seven.base,if=virtio -net nic,model=virtio,macaddr=02:00:00:00:00:01 -net tap,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown -vga std -usb -usbdevice tablet -rtc base=localtime,clock=host -watchdog i6300esb -balloon virtio -m 1024 -no-quit -smp 2 -monitor stdio
>
>Monitor Session:
>
>QEMU 0.13.50 monitor - type 'help' for more information
>(qemu) info balloon
>balloon: actual=1024
>(qemu) balloon 1536
>(qemu) info balloon
>balloon: actual=1024
>(qemu) balloon 512
>(qemu) info balloon
>balloon: actual=1020
>(qemu) info balloon
>balloon: actual=1020
>(qemu) balloon 512
>(qemu) info balloon
>balloon: actual=1018
>
>
>
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Fri, 17 Dec 2010 14:54:10 +0200
>From: Alon Levy <alevy@redhat.com>
>Subject: Re: [Qemu-devel] [PATCH 1/1] spice: add chardev
>To: Gerd Hoffmann <kraxel@redhat.com>
>Cc: qemu-devel@nongnu.org
>Message-ID: <20101217125409.GC3697@playa.redhat.com>
>Content-Type: text/plain; charset=us-ascii
>
>On Thu, Dec 16, 2010 at 05:53:10PM +0100, Gerd Hoffmann wrote:
>>   Hi,
>> 
>> >>>+//#define SPICE_QEMU_CHAR_USE_IOCTL
>> >>
>> >>Why is this disabled?
>> >>Does it depend on the chardev patches from Amit?
>> >>
>> >
>> >There was a long discussion that concluded we don't want IOCTL's at all,
>> >and that there should be some other mechanism for connection state
>> >communication between the two sides. Meanwhile I found out I don't need
>> >these (I don't remember exactly what I used instead, but basically just
>> >the regular results of write/read).
>> 
>> Ok, so when it is obsolete now it can be dropped altogether I guess?
>
>ok, I'll remove it from the patch.
>
>> 
>> cheers,
>>   Gerd
>> 
>> 
>
>
>
>------------------------------
>
>Message: 4
>Date: Fri, 17 Dec 2010 14:08:16 +0100
>From: Kevin Wolf <kwolf@redhat.com>
>Subject: [Qemu-devel] Re: [PATCH v6 0/5] qed: Add QEMU Enhanced Disk
>	format
>To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org,	Avi
>	Kivity <avi@redhat.com>
>Message-ID: <4D0B60C0.5070109@redhat.com>
>Content-Type: text/plain; charset=ISO-8859-15
>
>Am 06.12.2010 17:07, schrieb Stefan Hajnoczi:
>> For a changelog against v5, see below.
>> 
>> QEMU Enhanced Disk format is a disk image format that forgoes features
>> found in qcow2 in favor of better levels of performance and data
>> integrity.  Due to its simpler on-disk layout, it is possible to safely
>> perform metadata updates more efficiently.
>> 
>> Installations, suspend-to-disk, and other allocation-heavy I/O workloads
>> will see increased performance due to fewer I/Os and syncs.  Workloads
>> that do not cause new clusters to be allocated will perform similar to
>> raw images due to in-memory metadata caching.
>> 
>> The format supports sparse disk images.  It does not rely on the host
>> filesystem holes feature, making it a good choice for sparse disk images
>> that need to be transferred over channels where holes are not supported.
>> 
>> Backing files are supported so only deltas against a base image can be
>> stored.  The base image may be smaller than the image file.
>> 
>> The file format is extensible so that additional features can be added
>> later with graceful compatibility handling.  A specification for the file
>> format is included in this patchset.
>> 
>> Internal snapshots are not supported.  This eliminates the need for
>> additional metadata to track copy-on-write clusters.
>> 
>> Compression and encryption are not supported.  They add complexity and can be
>> implemented at other layers in the stack (i.e. inside the guest or on the
>> host).  Encryption has been identified as a potential future extension and the
>> file format allows for this.
>> 
>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>
>Thanks, reluctantly applied to the block branch. ;-)
>
>Kevin
>
>
>
>------------------------------
>
>Message: 5
>Date: Fri, 17 Dec 2010 14:12:34 +0100
>From: Kevin Wolf <kwolf@redhat.com>
>Subject: [Qemu-devel] Re: [PATCH v2] ide: Register vm change state
>	handler	once only
>To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>Cc: qemu-devel@nongnu.org
>Message-ID: <4D0B61C2.7010106@redhat.com>
>Content-Type: text/plain; charset=ISO-8859-15
>
>Am 16.12.2010 16:54, schrieb Stefan Hajnoczi:
>> We register the vm change state handler in a PCI BAR map() function.
>> This function can be called multiple times throughout the lifetime of a
>> PCI IDE device.  This results in duplicate vm change state handlers
>> being register, none of which are ever unregistered.
>> 
>> Instead, register the vm change state handler in the device's init
>> function once and for all.
>> 
>> piix tested, cmd646 and via not tested.
>> 
>> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>
>Thanks, applied to the block branch.
>
>Kevin
>
>
>
>------------------------------
>
>Message: 6
>Date: Fri, 17 Dec 2010 13:22:10 +0000
>From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>Subject: [Qemu-devel] Re: [PATCH v6 0/5] qed: Add QEMU Enhanced Disk
>	format
>To: Kevin Wolf <kwolf@redhat.com>
>Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org,	Avi
>	Kivity <avi@redhat.com>
>Message-ID: <20101217132210.GA25008@stefanha-thinkpad.localdomain>
>Content-Type: text/plain; charset=us-ascii
>
>On Fri, Dec 17, 2010 at 02:08:16PM +0100, Kevin Wolf wrote:
>> Am 06.12.2010 17:07, schrieb Stefan Hajnoczi:
>> > For a changelog against v5, see below.
>> > 
>> > QEMU Enhanced Disk format is a disk image format that forgoes features
>> > found in qcow2 in favor of better levels of performance and data
>> > integrity.  Due to its simpler on-disk layout, it is possible to safely
>> > perform metadata updates more efficiently.
>> > 
>> > Installations, suspend-to-disk, and other allocation-heavy I/O workloads
>> > will see increased performance due to fewer I/Os and syncs.  Workloads
>> > that do not cause new clusters to be allocated will perform similar to
>> > raw images due to in-memory metadata caching.
>> > 
>> > The format supports sparse disk images.  It does not rely on the host
>> > filesystem holes feature, making it a good choice for sparse disk images
>> > that need to be transferred over channels where holes are not supported.
>> > 
>> > Backing files are supported so only deltas against a base image can be
>> > stored.  The base image may be smaller than the image file.
>> > 
>> > The file format is extensible so that additional features can be added
>> > later with graceful compatibility handling.  A specification for the file
>> > format is included in this patchset.
>> > 
>> > Internal snapshots are not supported.  This eliminates the need for
>> > additional metadata to track copy-on-write clusters.
>> > 
>> > Compression and encryption are not supported.  They add complexity and can be
>> > implemented at other layers in the stack (i.e. inside the guest or on the
>> > host).  Encryption has been identified as a potential future extension and the
>> > file format allows for this.
>> > 
>> > Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>> > Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>> 
>> Thanks, reluctantly applied to the block branch. ;-)
>
>Thank you Kevin!
>
>Stefan
>
>
>
>------------------------------
>
>Message: 7
>Date: Fri, 17 Dec 2010 15:22:13 +0200
>From: Alon Levy <alevy@redhat.com>
>Subject: [Qemu-devel] [PATCH] spice: add chardev (v2)
>To: qemu-devel@nongnu.org
>Message-ID: <1292592133-9449-1-git-send-email-alevy@redhat.com>
>
>Adding a chardev backend for spice, for usage by spice vdagent in
>conjunction with a properly named virtio-serial device.
>
>Example usage:
> qemu -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -devic
>
>This is equivalent to the old:
> qemu -device virtio-serial -device spicevmc,subtype=vdagent
>
>longer to write, but generated by libvirt, and requires one less device.
>
>v1->v2 changes:
> * removed spice-qemu-char.h, folded into spice-qemu-char.h
> * removed dead IOCTL code
> * removed comment
> * removed ifdef CONFIG_SPICE from qemu-config.c and qemu-options.hx help.
>---
> Makefile.objs     |    2 +-
> qemu-char.c       |    4 +
> qemu-config.c     |    6 ++
> qemu-options.hx   |   16 ++++-
> spice-qemu-char.c |  185 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> ui/qemu-spice.h   |    3 +
> 6 files changed, 214 insertions(+), 2 deletions(-)
> create mode 100644 spice-qemu-char.c
>
>diff --git a/Makefile.objs b/Makefile.objs
>index cebb945..320b2a9 100644
>--- a/Makefile.objs
>+++ b/Makefile.objs
>@@ -102,7 +102,7 @@ common-obj-$(CONFIG_BRLAPI) += baum.o
> common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o
> common-obj-$(CONFIG_WIN32) += version.o
> 
>-common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o ui/spice-display.o
>+common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o ui/spice-display.o spice-qemu-char.o
> 
> audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o
> audio-obj-$(CONFIG_SDL) += sdlaudio.o
>diff --git a/qemu-char.c b/qemu-char.c
>index edc9ad6..acc7130 100644
>--- a/qemu-char.c
>+++ b/qemu-char.c
>@@ -97,6 +97,7 @@
> #endif
> 
> #include "qemu_socket.h"
>+#include "ui/qemu-spice.h"
> 
> #define READ_BUF_LEN 4096
> 
>@@ -2495,6 +2496,9 @@ static const struct {
>     || defined(__FreeBSD_kernel__)
>     { .name = "parport",   .open = qemu_chr_open_pp },
> #endif
>+#ifdef CONFIG_SPICE
>+    { .name = "spicevmc",     .open = qemu_chr_open_spice },
>+#endif
> };
> 
> CharDriverState *qemu_chr_open_opts(QemuOpts *opts,
>diff --git a/qemu-config.c b/qemu-config.c
>index 965fa46..323d3c2 100644
>--- a/qemu-config.c
>+++ b/qemu-config.c
>@@ -146,6 +146,12 @@ static QemuOptsList qemu_chardev_opts = {
>         },{
>             .name = "signal",
>             .type = QEMU_OPT_BOOL,
>+        },{
>+            .name = "name",
>+            .type = QEMU_OPT_STRING,
>+        },{
>+            .name = "debug",
>+            .type = QEMU_OPT_NUMBER,
>         },
>         { /* end of list */ }
>     },
>diff --git a/qemu-options.hx b/qemu-options.hx
>index 4d99a58..5c13f0f 100644
>--- a/qemu-options.hx
>+++ b/qemu-options.hx
>@@ -1357,6 +1357,9 @@ DEF("chardev", HAS_ARG, QEMU_OPTION_chardev,
> #if defined(__linux__) || defined(__FreeBSD__) || defined(__DragonFly__)
>     "-chardev parport,id=id,path=path[,mux=on|off]\n"
> #endif
>+#if defined(CONFIG_SPICE)
>+    "-chardev spicevmc,id=id,debug=debug,name=name\n"
>+#endif
>     , QEMU_ARCH_ALL
> )
> 
>@@ -1381,7 +1384,8 @@ Backend is one of:
> @option{stdio},
> @option{braille},
> @option{tty},
>-@option{parport}.
>+@option{parport}
>+@option{spicevmc}.
> The specific backend will determine the applicable options.
> 
> All devices must have an id, which can be any string up to 127 characters long.
>@@ -1557,6 +1561,16 @@ Connect to a local parallel port.
> @option{path} specifies the path to the parallel port device. @option{path} is
> required.
> 
>+#if defined(CONFIG_SPICE)
>+@item -chardev spicevmc ,id=@var{id} ,debug=@var{debug}, name=@var{name}
>+
>+@option{debug} debug level for spicevmc
>+
>+@option{name} name of spice channel to connect to
>+
>+Connect to a spice virtual machine channel, such as vdiport.
>+#endif
>+
> @end table
> ETEXI
> 
>diff --git a/spice-qemu-char.c b/spice-qemu-char.c
>new file mode 100644
>index 0000000..0ffa674
>--- /dev/null
>+++ b/spice-qemu-char.c
>@@ -0,0 +1,185 @@
>+#include "config-host.h"
>+#include "ui/qemu-spice.h"
>+#include <spice.h>
>+#include <spice-experimental.h>
>+
>+#include "osdep.h"
>+
>+#define dprintf(_scd, _level, _fmt, ...)                                \
>+    do {                                                                \
>+        static unsigned __dprintf_counter = 0;                          \
>+        if (_scd->debug >= _level) {                                    \
>+            fprintf(stderr, "scd: %3d: " _fmt, ++__dprintf_counter, ## __VA_ARGS__);\
>+        }                                                               \
>+    } while (0)
>+
>+#define VMC_MAX_HOST_WRITE    2048
>+
>+typedef struct SpiceCharDriver {
>+    CharDriverState*      chr;
>+    SpiceCharDeviceInstance     sin;
>+    char                  *subtype;
>+    bool                  active;
>+    uint8_t               *buffer;
>+    uint8_t               *datapos;
>+    ssize_t               bufsize, datalen;
>+    uint32_t              debug;
>+} SpiceCharDriver;
>+
>+static int vmc_write(SpiceCharDeviceInstance *sin, const uint8_t *buf, int len)
>+{
>+    SpiceCharDriver *scd = container_of(sin, SpiceCharDriver, sin);
>+    ssize_t out = 0;
>+    ssize_t last_out;
>+    uint8_t* p = (uint8_t*)buf;
>+
>+    while (len > 0) {
>+        last_out = MIN(len, VMC_MAX_HOST_WRITE);
>+        qemu_chr_read(scd->chr, p, last_out);
>+        if (last_out > 0) {
>+            out += last_out;
>+            len -= last_out;
>+            p += last_out;
>+        } else {
>+            break;
>+        }
>+    }
>+
>+    dprintf(scd, 3, "%s: %lu/%zd\n", __func__, out, len + out);
>+    return out;
>+}
>+
>+static int vmc_read(SpiceCharDeviceInstance *sin, uint8_t *buf, int len)
>+{
>+    SpiceCharDriver *scd = container_of(sin, SpiceCharDriver, sin);
>+    int bytes = MIN(len, scd->datalen);
>+
>+    dprintf(scd, 2, "%s: %p %d/%d/%zd\n", __func__, scd->datapos, len, bytes, scd->datalen);
>+    if (bytes > 0) {
>+        memcpy(buf, scd->datapos, bytes);
>+        scd->datapos += bytes;
>+        scd->datalen -= bytes;
>+        assert(scd->datalen >= 0);
>+        if (scd->datalen == 0) {
>+            scd->datapos = 0;
>+        }
>+    }
>+    return bytes;
>+}
>+
>+static SpiceCharDeviceInterface vmc_interface = {
>+    .base.type          = SPICE_INTERFACE_CHAR_DEVICE,
>+    .base.description   = "spice virtual channel char device",
>+    .base.major_version = SPICE_INTERFACE_CHAR_DEVICE_MAJOR,
>+    .base.minor_version = SPICE_INTERFACE_CHAR_DEVICE_MINOR,
>+    .write              = vmc_write,
>+    .read               = vmc_read,
>+};
>+
>+
>+static void vmc_register_interface(SpiceCharDriver *scd)
>+{
>+    if (scd->active) {
>+        return;
>+    }
>+    dprintf(scd, 1, "%s\n", __func__);
>+    scd->sin.base.sif = &vmc_interface.base;
>+    qemu_spice_add_interface(&scd->sin.base);
>+    scd->active = true;
>+}
>+
>+static void vmc_unregister_interface(SpiceCharDriver *scd)
>+{
>+    if (!scd->active) {
>+        return;
>+    }
>+    dprintf(scd, 1, "%s\n", __func__);
>+    spice_server_remove_interface(&scd->sin.base);
>+    scd->active = false;
>+}
>+
>+
>+static int spice_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
>+{
>+    SpiceCharDriver *s = chr->opaque;
>+
>+    dprintf(s, 2, "%s: %d\n", __func__, len);
>+    vmc_register_interface(s);
>+    assert(s->datalen == 0);
>+    if (s->bufsize < len) {
>+        s->bufsize = len;
>+        s->buffer = qemu_realloc(s->buffer, s->bufsize);
>+    }
>+    memcpy(s->buffer, buf, len);
>+    s->datapos = s->buffer;
>+    s->datalen = len;
>+    spice_server_char_device_wakeup(&s->sin);
>+    return len;
>+}
>+
>+static void spice_chr_close(struct CharDriverState *chr)
>+{
>+    SpiceCharDriver *s = chr->opaque;
>+
>+    printf("%s\n", __func__);
>+    vmc_unregister_interface(s);
>+    qemu_free(s);
>+}
>+
>+static void print_allowed_subtypes(void)
>+{
>+    const char** psubtype;
>+    int i;
>+
>+    fprintf(stderr, "allowed names: ");
>+    for(i=0, psubtype = spice_server_char_device_recognized_subtypes();
>+        *psubtype != NULL; ++psubtype, ++i) {
>+        if (i == 0) {
>+            fprintf(stderr, "%s", *psubtype);
>+        } else {
>+            fprintf(stderr, ", %s", *psubtype);
>+        }
>+    }
>+    fprintf(stderr, "\n");
>+}
>+
>+CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
>+{
>+    CharDriverState *chr;
>+    SpiceCharDriver *s;
>+    const char* name = qemu_opt_get(opts, "name");
>+    uint32_t debug = qemu_opt_get_number(opts, "debug", 0);
>+    const char** psubtype = spice_server_char_device_recognized_subtypes();
>+    const char *subtype = NULL;
>+
>+    if (name == NULL) {
>+        fprintf(stderr, "spice-qemu-char: missing name parameter\n");
>+        print_allowed_subtypes();
>+        return NULL;
>+    }
>+    for(;*psubtype != NULL; ++psubtype) {
>+        if (strcmp(name, *psubtype) == 0) {
>+            subtype = *psubtype;
>+            break;
>+        }
>+    }
>+    if (subtype == NULL) {
>+        fprintf(stderr, "spice-qemu-char: unsupported name\n");
>+        print_allowed_subtypes();
>+        return NULL;
>+    }
>+
>+    chr = qemu_mallocz(sizeof(CharDriverState));
>+    s = qemu_mallocz(sizeof(SpiceCharDriver));
>+    s->chr = chr;
>+    s->debug = debug;
>+    s->active = false;
>+    s->sin.subtype = subtype;
>+    chr->opaque = s;
>+    chr->chr_write = spice_chr_write;
>+    chr->chr_close = spice_chr_close;
>+
>+    qemu_chr_generic_open(chr);
>+
>+    return chr;
>+}
>diff --git a/ui/qemu-spice.h b/ui/qemu-spice.h
>index 0e3ad9b..e06af17 100644
>--- a/ui/qemu-spice.h
>+++ b/ui/qemu-spice.h
>@@ -24,6 +24,7 @@
> 
> #include "qemu-option.h"
> #include "qemu-config.h"
>+#include "qemu-char.h"
> 
> extern int using_spice;
> 
>@@ -33,6 +34,8 @@ void qemu_spice_audio_init(void);
> void qemu_spice_display_init(DisplayState *ds);
> int qemu_spice_add_interface(SpiceBaseInstance *sin);
> 
>+CharDriverState *qemu_chr_open_spice(QemuOpts *opts);
>+
> #else  /* CONFIG_SPICE */
> 
> #define using_spice 0
>-- 
>1.7.3.3
>
>
>
>
>------------------------------
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>End of Qemu-devel Digest, Vol 93, Issue 259
>*******************************************

[-- Attachment #2: Type: text/html, Size: 43064 bytes --]

Re: [Qemu-devel] help

[Mulyadi Santosa]

Is it a request of help or you simply just want to reforward the digest?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

[Qemu-devel] help

[lc]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

hi,everyone
I want to copy a 3M picture from the guest to the host,which method i can use,i think channel is too slow,because i want sent 30 pieces per second.

thanks.

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

Re: [Qemu-devel] help

[Gonglei (Arei)]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

Hi,

Why not configure Nic  for VM to transfer those pictures ?




Best regards,
-Gonglei

From: qemu-devel-bounces+arei.gonglei=huawei.com@nongnu.org [mailto:qemu-devel-bounces+arei.gonglei=huawei.com@nongnu.org] On Behalf Of lc
Sent: Monday, June 23, 2014 9:32 AM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] help

hi,everyone
I want to copy a 3M picture from the guest to the host,which method i can use,i think channel is too slow,because i want sent 30 pieces per second.
thanks.


[-- Attachment #2: Type: text/html, Size: 5678 bytes --]

[Qemu-devel] help

[Serigne Baytir DIENG]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

Hi all,

I am new into this qemu, but i have a pretty good understanding of how it
works. What i am trying to do is to attach a new pci device into the virtio
pci bus. I don't know much what files need to be changed or how could i
achieved that.

Anyone can help?

[-- Attachment #2: Type: text/html, Size: 340 bytes --]

Re: [Qemu-devel] help

[Stefan Hajnoczi]

On Thu, Jul 30, 2015 at 11:17 AM, Serigne Baytir DIENG
<yabrit94@gmail.com> wrote:
> I am new into this qemu, but i have a pretty good understanding of how it
> works. What i am trying to do is to attach a new pci device into the virtio
> pci bus. I don't know much what files need to be changed or how could i
> achieved that.

I don't understand what you are trying to do.  Do you want to
implement a new type of virtio device?

That is largely independent of PCI, although you'll probably want to
hook up the new device following the same pattern as the others in
hw/virtio/virtio-pci.c.

Take a look at the existing virtio device types (blk, net, scsi, rng,
9p, etc) for examples of how to do it.

Stefan

[Qemu-devel] HELP

[Projat Banerjee]

What is the type of proposal should I submit here ? What kind or on what basis should I build my proposal so that I may get easily selected or chances for my selection is high ?

Sent from Mail for Windows 10

Re: [Qemu-devel] HELP

[Stefan Hajnoczi]

On Sat, Mar 17, 2018 at 8:37 PM, Projat Banerjee
<banerjeeprojat.pb@gmail.com> wrote:
> What is the type of proposal should I submit here ? What kind or on what basis should I build my proposal so that I may get easily selected or chances for my selection is high ?

Are you referring to Google Summer of Code?  Outreachy?  Something else?

For Google Summer of Code, please read the GSoC 2018 wiki page:
https://wiki.qemu.org/Google_Summer_of_Code_2018

It contains a list of project ideas that you can choose to apply for.
Please contact the mentor for the project idea you are interested in.

You do not need to send a proposal to qemu-devel@nongnu.org.  How to
apply is covered on the wiki page above.

I have written up some advice for applicants which answers some of
your questions (it's also linked from the wiki page above):
http://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html

For Outreachy, please follow the instructions at:
https://www.outreachy.org/apply/

Stefan