Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 18/11/2012 23:00, Stefan Priebe ha scritto: > Hi Paolo, > > Am 06.11.2012 23:42, schrieb Paolo Bonzini: >> >>> i wantes to use scsi unmap with rbd. rbd documention says you need to >>> set discard_granularity=512 for the device. I'm using qemu 1.2. >>> >>> If i set this and send an UNMAP command i get this kernel output: >> >> The discard request is failing. Please check why with a breakpoint on >> rbd_aio_discard_wrapper or scsi_handle_rw_error for example. >> >> Paolo > > I'm sorry the discard requests aren't failing. Qemu / Block driver > starts to cancel a bunch of requests. That is being done in the kernel (the guest, I think) because the UNMAPs are taking too long. Paolo > [ 39.577194] sd 2:0:0:1: [sdb] > [ 39.577194] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 39.577194] sd 2:0:0:1: [sdb] > [ 39.577194] Sense Key : Aborted Command [current] > [ 39.577194] sd 2:0:0:1: [sdb] > [ 39.577194] Add. Sense: I/O process terminated > [ 39.577194] sd 2:0:0:1: [sdb] CDB: > [ 39.577194] Write same(16): 93 08 00 00 00 00 04 7f ff f7 00 62 00 09 > 00 00 > [ 39.577194] end_request: I/O error, dev sdb, sector 75497463
Re: [Qemu-devel] [PATCH] hw/virtio-serial-bus: post_load send_event when vm is running
Il 18/11/2012 20:17, Blue Swirl ha scritto:
>> > +struct {
>>> >>
>>> >> Please add a name, for example PostLoad.
>> >
>> > Why? This is not C++ and the namespace would be global. It's just to
>> > have a nice grouping.
> Otherwise the structure will be anonymous and those were only added to
> C11, not C99.
No, the name here is "post_load". Unnamed struct *types* are present
all the way to C89 and probably even K&R.
Paolo
>> >
>> > Paolo
>> >
>> > +QEMUTimer *timer;
>> > +int nr_active_ports;
>> > +struct {
>> > +VirtIOSerialPort *port;
>> > +uint8_t host_connected;
>> > +} *connected;
>> > +} post_load;
Re: [Qemu-devel] buildbot failure in qemu on default_i386_debian_6_0
Il 19/11/2012 07:50, Stefan Weil ha scritto: > Am 19.11.2012 00:43, schrieb q...@buildbot.b1-systems.de: >> The Buildbot has detected a new failure on builder >> default_i386_debian_6_0 while building qemu. >> Full details are available at: >> >> http://buildbot.b1-systems.de/qemu/builders/default_i386_debian_6_0/builds/454 >> >> >> Buildbot URL: http://buildbot.b1-systems.de/qemu/ >> >> Buildslave for this Build: yuzuki >> >> Build Reason: The Nightly scheduler named 'nightly_default' triggered >> this build >> Build Source Stamp: [branch master] HEAD >> Blamelist: >> >> BUILD FAILED: failed test >> >> sincerely, >> -The Buildbot > > LINK tests/test-coroutine > osdep.o: In function `qemu_close': > osdep.c:(.text+0x4b1): undefined reference to `monitor_fdset_dup_fd_find' > osdep.c:(.text+0x51b): undefined reference to `monitor_fdset_dup_fd_remove' > > At least some test executables need libqemustub.a. > > I also noted that QEMU tries to build several 32 bit applications for the > tests > even on 64 bit hosts. Hmm, that's a bug. A 64-bit build should be 100% 64-bit. Paolo > We currently don't check whether the host supports > 32 bit builds. Here a check in configure should be added. On a Debian host, > I had to install those packages: > > 2012-11-19 07:24:41 status installed libc6-i386 2.11.3-4 > 2012-11-19 07:24:41 status installed libc6-dev-i386 2.11.3-4 > 2012-11-19 07:30:22 status installed lib32gcc1 1:4.4.5-8 > 2012-11-19 07:30:22 status installed lib32gomp1 4.4.5-8 > 2012-11-19 07:30:22 status installed gcc-4.4-multilib 4.4.5-8 > 2012-11-19 07:30:22 status installed gcc-multilib 4:4.4.5-1 > > 'make test' still fails because more 32 bit packages are missing: > > gcc -m32 -o test_path test_path.o -lrt -pthread -lgthread-2.0 -lrt > -lglib-2.0 > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libgthread-2.0.so when > searching for -lgthread-2.0 > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libgthread-2.0.a when > searching for -lgthread-2.0 > /usr/bin/ld: skipping incompatible /usr/lib/libgthread-2.0.so when > searching for -lgthread-2.0 > /usr/bin/ld: skipping incompatible /usr/lib/libgthread-2.0.a when > searching for -lgthread-2.0 > /usr/bin/ld: cannot find -lgthread-2.0 > collect2: ld returned 1 exit status > make[1]: *** [test_path] Fehler 1 > > This needs a configure check, too (or 'make test' should skip that test > if there is no 32 bit libgthread-2.0). > > Regards > Stefan >
Re: [Qemu-devel] [PATCH] iscsi: do not assume device is zero initialized
Il 17/11/2012 16:20, Peter Lieven ha scritto:
> Without any complex checks we can't assume that an
> iscsi target is initialized to zero.
>
> Signed-off-by: Peter Lieven
> ---
> block/iscsi.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/block/iscsi.c b/block/iscsi.c
> index eb586cb..d685f20 100644
> --- a/block/iscsi.c
> +++ b/block/iscsi.c
> @@ -991,6 +991,11 @@ out:
> return ret;
> }
>
> +static int iscsi_has_zero_init(BlockDriverState *bs)
> +{
> +return 0;
> +}
> +
> static QEMUOptionParameter iscsi_create_options[] = {
> {
> .name = BLOCK_OPT_SIZE,
> @@ -1017,6 +1022,7 @@ static BlockDriver bdrv_iscsi = {
> .bdrv_aio_flush = iscsi_aio_flush,
>
> .bdrv_aio_discard = iscsi_aio_discard,
> +.bdrv_has_zero_init = iscsi_has_zero_init,
>
> #ifdef __linux__
> .bdrv_ioctl = iscsi_ioctl,
>
Applied to scsi-next branch.
Paolo
Re: [Qemu-devel] [PATCH] iscsi: add iscsi_create support
Il 17/11/2012 16:13, Peter Lieven ha scritto:
> This patch adds support for bdrv_create. This allows e.g.
> to use qemu-img to convert from any supported device to
> an iscsi backed storage as destination.
>
> Signed-off-by: Peter Lieven
>
> diff --git a/block/iscsi.c b/block/iscsi.c
> index 4bc3d4b..eb586cb 100644
> --- a/block/iscsi.c
> +++ b/block/iscsi.c
> @@ -952,6 +952,54 @@ static void iscsi_close(BlockDriverState *bs)
> memset(iscsilun, 0, sizeof(IscsiLun));
> }
>
> +static int iscsi_create(const char *filename, QEMUOptionParameter *options) {
Incorrect brace positioning, fixed it myself.
+int ret = 0;
> +int64_t total_size = 0;
> +BlockDriverState bs;
> +IscsiLun *iscsilun = NULL;
> +
> +memset(&bs, 0, sizeof(BlockDriverState));
> +
> +/* Read out options */
> +while (options && options->name) {
> +if (!strcmp(options->name, "size")) {
> +total_size = options->value.n / BDRV_SECTOR_SIZE;
> +}
> +options++;
> +}
> +
> +bs.opaque = g_malloc0(sizeof(struct IscsiLun));
> +iscsilun = bs.opaque;
> +
> +if ((ret = iscsi_open(&bs, filename, 0)) != 0) {
> +goto out;
> +}
> +if (iscsilun->type != TYPE_DISK) {
> +ret = -ENODEV;
> +goto out;
> +}
> +if (bs.total_sectors < total_size) {
> +ret = -ENOSPC;
> +}
> +
> +ret = 0;
> +out:
> +if (iscsilun->iscsi != NULL) {
> +iscsi_destroy_context(iscsilun->iscsi);
> +}
> +g_free(bs.opaque);
> +return ret;
> +}
> +
> +static QEMUOptionParameter iscsi_create_options[] = {
> +{
> +.name = BLOCK_OPT_SIZE,
> +.type = OPT_SIZE,
> +.help = "Virtual disk size"
> +},
> +{ NULL }
> +};
> +
> static BlockDriver bdrv_iscsi = {
> .format_name = "iscsi",
> .protocol_name = "iscsi",
> @@ -959,6 +1007,8 @@ static BlockDriver bdrv_iscsi = {
> .instance_size = sizeof(IscsiLun),
> .bdrv_file_open = iscsi_open,
> .bdrv_close = iscsi_close,
> +.bdrv_create = iscsi_create,
> +.create_options = iscsi_create_options,
>
> .bdrv_getlength = iscsi_getlength,
>
>
Applied to scsi-next branch.
Paolo
Re: [Qemu-devel] [PATCH v2] iscsi: fix deadlock during login
Il 17/11/2012 14:37, Peter Lieven ha scritto: > If the connection is interrupted before the first login is successfully > completed qemu-kvm is waiting forever in qemu_aio_wait(). > > This is fixed by performing an sync login to the target. If the > connection breaks after the first successful login errors are > handled internally by libiscsi. > > v2: > changed the complete iscsi_open routine to sync tasks. Applied to scsi-next branch, thanks. Paolo
Re: [Qemu-devel] [PATCH] arm: a9mpcore: remove un-used ptimer_iomem field
On 19 November 2012 05:13, Peter Crosthwaite wrote: > I'm guessing this is a hangover from a previous coreification of the mptimer > sub-module. This field is completely unused - removed. > > Signed-off-by: Peter Crosthwaite Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] QOMification of SCU in a9mpcore
On 19 November 2012 05:23, Peter Crosthwaite wrote: > Im currently doing some re-factoring in and around the A9mpcore for > our work on dynamic machine model creation. Id like to change the SCU > component currently implemented in a9mpcore to be its own QOM object, > just like with the GIC and the mptimer. Any reasons not to? Would this > change be acceptable or is there a motivation to have it as one > object? If changed, A9 mpcore will become just a container object for > the three submodules, GIC, mptimer and SCU. Sounds like a sensible cleanup to me. I think at the time I last worked on the mpcore objects I was mostly interested in pulling out the common bits (ie mptimer) and didn't worry so much about the bits that were genuinely core specific. But splitting out the SCU is really the right way to model it. Better done sooner than later (ie months, not years), at some point we're going to have to stop allowing ourselves to break ARM migration compatibility... -- PMM
Re: [Qemu-devel] [PATCH] Fix spelling (prefered -> preferred)
On Sun, Nov 18, 2012 at 08:35:24PM +0100, Stefan Weil wrote:
> Am 02.11.2012 08:14, schrieb Stefan Weil:
> >Signed-off-by: Stefan Weil
> >---
> > configure |2 +-
> > net/tap-win32.c |7 ---
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> >diff --git a/configure b/configure
> >index 79701ea..860859b 100755
> >--- a/configure
> >+++ b/configure
> >@@ -2115,7 +2115,7 @@ if test "$pixman" = "system"; then
> > else
> >if test ! -d ${source_path}/pixman/pixman; then
> > echo "ERROR: pixman not present. Your options:"
> >-echo " (1) Prefered: Install the pixman devel package (any recent"
> >+echo " (1) Preferred: Install the pixman devel package (any recent"
> > echo " distro should have packages as Xorg needs pixman too)."
> > echo " (2) Fetch the pixman submodule, using:"
> > echo " git submodule update --init pixman"
> >diff --git a/net/tap-win32.c b/net/tap-win32.c
> >index 8d2d32b..f9bd741 100644
> >--- a/net/tap-win32.c
> >+++ b/net/tap-win32.c
> >@@ -565,7 +565,7 @@ static void tap_win32_free_buffer(tap_win32_overlapped_t
> >*overlapped,
> > }
> >
> > static int tap_win32_open(tap_win32_overlapped_t **phandle,
> >- const char *prefered_name)
> >+ const char *preferred_name)
> > {
> > char device_path[256];
> > char device_guid[0x100];
> >@@ -581,8 +581,9 @@ static int tap_win32_open(tap_win32_overlapped_t
> >**phandle,
> > DWORD version_len;
> > DWORD idThread;
> >
> >-if (prefered_name != NULL)
> >-snprintf(name_buffer, sizeof(name_buffer), "%s", prefered_name);
> >+if (preferred_name != NULL) {
> >+snprintf(name_buffer, sizeof(name_buffer), "%s", preferred_name);
> >+}
> >
> > rc = get_device_guid(device_guid, sizeof(device_guid), name_buffer,
> > sizeof(name_buffer));
> > if (rc)
>
> ping?
Thanks, applied to the trivial patches tree. Sorry I missed this one.
There is currently a pending trivial patches pull request - this patch
will be in the next pull request.
Stefan
Re: [Qemu-devel] [PATCH] Fix comments (adress -> address, layed -> laid, wierd -> weird)
On Sun, Nov 18, 2012 at 08:34:11PM +0100, Stefan Weil wrote:
> Am 02.11.2012 08:29, schrieb Stefan Weil:
> >Remove also a duplicated 'the'.
> >
> >Signed-off-by: Stefan Weil
> >---
> > slirp/ip_icmp.c |2 +-
> > tcg/tcg.h |4 ++--
> > uri.c |4 ++--
> > 3 files changed, 5 insertions(+), 5 deletions(-)
> >
> >diff --git a/slirp/ip_icmp.c b/slirp/ip_icmp.c
> >index d571fd0..9f1cb08 100644
> >--- a/slirp/ip_icmp.c
> >+++ b/slirp/ip_icmp.c
> >@@ -352,7 +352,7 @@ icmp_error(struct mbuf *msrc, u_char type, u_char code,
> >int minsize,
> >
> >ip->ip_ttl = MAXTTL;
> >ip->ip_p = IPPROTO_ICMP;
> >- ip->ip_dst = ip->ip_src;/* ip adresses */
> >+ ip->ip_dst = ip->ip_src;/* ip addresses */
> >ip->ip_src = m->slirp->vhost_addr;
> >
> >(void ) ip_output((struct socket *)NULL, m);
> >diff --git a/tcg/tcg.h b/tcg/tcg.h
> >index a6c9256..db86a73 100644
> >--- a/tcg/tcg.h
> >+++ b/tcg/tcg.h
> >@@ -272,8 +272,8 @@ typedef int TCGv_i64;
> > #define TCG_CALL_DUMMY_TCGV MAKE_TCGV_I32(-1)
> > #define TCG_CALL_DUMMY_ARG ((TCGArg)(-1))
> >
> >-/* Conditions. Note that these are layed out for easy manipulation by
> >- the the functions below:
> >+/* Conditions. Note that these are laid out for easy manipulation by
> >+ the functions below:
> > bit 0 is used for inverting;
> > bit 1 is signed,
> > bit 2 is unsigned,
> >diff --git a/uri.c b/uri.c
> >index dd922de..138547b 100644
> >--- a/uri.c
> >+++ b/uri.c
> >@@ -432,7 +432,7 @@ rfc3986_parse_host(URI *uri, const char **str)
> >
> > host = cur;
> > /*
> >- * IPv6 and future adressing scheme are enclosed between brackets
> >+ * IPv6 and future addressing scheme are enclosed between brackets
> > */
> > if (*cur == '[') {
> > cur++;
> >@@ -1917,7 +1917,7 @@ done:
> > * http://site1.com/docs/pic1.gif http://site1.com/docs/pic1.gif
> > *
> > *
> >- * Note: if the URI reference is really wierd or complicated, it may be
> >+ * Note: if the URI reference is really weird or complicated, it may be
> > * worthwhile to first convert it into a "nice" one by calling
> > * uri_resolve (using 'base') before calling this routine,
> > * since this routine (for reasonable efficiency) assumes URI has
>
> ping?
>
Thanks, applied to the trivial patches tree. There is currently a
pending pull request - this patch will be in the next pull request.
Stefan
Re: [Qemu-devel] [Qemu-trivial] [PATCH] s390x: Spelling fixes (endianess -> endianness, occured -> occurred)
On Fri, Nov 02, 2012 at 08:35:54AM +0100, Stefan Weil wrote: > Replace also "write into" by "write to". > > Signed-off-by: Stefan Weil > --- > > I think "write to" is better, but I am not sure about this, > so please wait until a native speaker has reviewed that patch. "write to" is better. Applied to the trivial patches tree. There is a pending pull request - this patch will be in the next pull request. Stefan
Re: [Qemu-devel] QOMification of SCU in a9mpcore
On Mon, Nov 19, 2012 at 6:35 PM, Peter Maydell wrote: > On 19 November 2012 05:23, Peter Crosthwaite > wrote: >> Im currently doing some re-factoring in and around the A9mpcore for >> our work on dynamic machine model creation. Id like to change the SCU >> component currently implemented in a9mpcore to be its own QOM object, >> just like with the GIC and the mptimer. Any reasons not to? Would this >> change be acceptable or is there a motivation to have it as one >> object? If changed, A9 mpcore will become just a container object for >> the three submodules, GIC, mptimer and SCU. > > Sounds like a sensible cleanup to me. I think at the time I last > worked on the mpcore objects I was mostly interested in pulling > out the common bits (ie mptimer) and didn't worry so much about > the bits that were genuinely core specific. I had a look at a11 SCU and it seems to have functional overlap. Could parameterise the differences to remove some code replication in the process. QOM string property for versions "a9" "a11" etc? Regards, Peter But splitting out > the SCU is really the right way to model it. > > Better done sooner than later (ie months, not years), at some point > we're going to have to stop allowing ourselves to break ARM migration > compatibility... > > -- PMM >
Re: [Qemu-devel] TCP based PCIE request forwarding
On Fri, Nov 16, 2012 at 02:05:29PM +0100, lementec fabien wrote: > Actually, I wanted to be independant of the QEMU event loop. Plus, > some proprietary simulation environment provides a closed socket > based interface to 'stimulate' the emulated device, at the PCIE level > for instance. These environments are sometimes installed on cluster > not running QEMU. The socket based approach fits quite well. > > Not knowing about QEMU internals, I spent some hours trying to find > out the best way to plug into QEMU, and did not find ivhsmem appropriate. > Honestly, I wanted to have a working solution asap, and it did not take > long before I opted for the socket based approach. Now that it is working, > I can take time to reconsider stuffs according to others need, and ideally > an integration to QEMU. I suggest writing up a spec for the socket protocol. It can be put in docs/specs/ (like the ivshmem spec). This is both a good way to increase discussion and important for others who may wish to make use of this feature. Stefan
Re: [Qemu-devel] [PATCH] vnc: added initial websockets support
On 11/19/12 00:29, Tim Hardeck wrote: > Hi Stefan, > > thanks for your input but how should it be implemented? > > I personally would like activating Websockets as a VNC option like: > " -vnc :0 -vnc :1,websockets" I have already tested this locally > and it does work but only for one protocol since QEMU does only > interpret the last vnc option. So is allowing more than one VNC > command line entry in combination with having more than one VNC > thread for the same display worth working on or do you have > something different in mind? -vnc :0,websock=$portnr ? cheers, Gerd
[Qemu-devel] Fwd: buildbot failure in qemu on fedora-mingw32
Original Message Subject: buildbot failure in qemu on fedora-mingw32 Date: Sun, 18 Nov 2012 22:55:08 +0100 From: build...@spunk.home.kraxel.org To: kraxel...@gmail.com The Buildbot has detected a failed build on builder fedora-mingw32 while building qemu. Full details are available at: http://www.kraxel.org/bb/builders/fedora-mingw32/builds/697 Buildbot URL: http://www.kraxel.org/bb/ Buildslave for this Build: fedora.xeni Build Reason: scheduler Build Source Stamp: [branch master] e24dc9feb0d68142d54dc3c097f57588836d1338 Blamelist: Paolo Bonzini ,Stefan Weil BUILD FAILED: failed compile sincerely, -The Buildbot == log tail == CCbuffered_file.o CCmigration.o CCmigration-tcp.o CCqemu-char.o CCblock-migration.o CCbitmap.o CCbitops.o CCpage_cache.o RCversion.o CCbt-host.o CCbt-vhci.o CCdma-helpers.o CCacl.o CCqtest.o CCvl.o GEN qmp-marshal.c CCqmp-marshal.o CCqmp.o CChmp.o CCaudio/audio.o CCaudio/noaudio.o CCaudio/wavaudio.o CCaudio/mixeng.o CCaudio/winwaveaudio.o CCaudio/audio_win_int.o CCaudio/wavcapture.o CCbackends/rng.o CCbackends/rng-random.o backends/rng-random.c: In function 'rng_random_opened': backends/rng-random.c:77:46: error: 'O_NONBLOCK' undeclared (first use in this function) backends/rng-random.c:77:46: note: each undeclared identifier is reported only once for each function it appears in make: *** [backends/rng-random.o] Error 1 == full log == http://www.kraxel.org/bb/builders/fedora-mingw32/builds/697/steps/compile/logs/stdio
Re: [Qemu-devel] QOMification of SCU in a9mpcore
On 19 November 2012 08:44, Peter Crosthwaite wrote: > I had a look at a11 SCU and it seems to have functional overlap. Could > parameterise the differences to remove some code replication in the > process. QOM string property for versions "a9" "a11" etc? I don't think that's worth doing, really. PS there is no A11. -- PMM
Re: [Qemu-devel] [PATCH] vnc: added initial websockets support
On Mon, Nov 19, 2012 at 12:29:44AM +0100, Tim Hardeck wrote: > Hi Stefan, > > thanks for your input but how should it be implemented? > > I personally would like activating Websockets as a VNC option like: " > -vnc :0 -vnc :1,websockets" > I have already tested this locally and it does work but only for one > protocol since QEMU does only interpret the last vnc option. > So is allowing more than one VNC command line entry in combination with > having more than one VNC thread for the same display worth working on or > do you have something different in mind? I'm not familiar enough with the VNC code to suggest how to best implement this. One thing to think about is that Websockets is a transport. Perhaps the VNC code itself shouldn't speak it, instead generic QEMU socket code should implement Websockets so that non-VNC components can also make use of it in the future. Stefan
Re: [Qemu-devel] [PULL 00/26] Block patches
Am 14.11.2012 19:47, schrieb Kevin Wolf: > The following changes since commit ce34cf72fe508b27a78f83c184142e8d1e6a048a: > > Merge remote-tracking branch 'awilliam/tags/vfio-pci-for-qemu-1.3.0-rc0' > into staging (2012-11-14 08:53:40 -0600) > > are available in the git repository at: > > git://repo.or.cz/qemu/kevin.git for-anthony > > Bharata B Rao (1): > qemu: Document GlusterFS block driver usage > > Gerhard Wiesinger (1): > vmdk: Fix data corruption bug in WRITE and READ handling > > Hervé Poussineau (12): > fdc-test: split test_media_change() test, so insert part can be reused > fdc-test: insert media before fuzzing registers > fdc-test: add tests for non-DMA READ command > fdc: use status0 field instead of a local variable > fdc: fix FD_SR0_SEEK for non-DMA transfers and multi sectors transfers > fdc: fix FD_SR0_SEEK for initial seek on DMA transfers > fdc: fix false FD_SR0_SEEK > fdc: implement VERIFY command > fdc-tests: add tests for VERIFY command > fdc: remove double affectation of FD_MSR_CMDBUSY flag > fdc: fix typo in zero constant > fdc: remove last usage of FD_STATE_SEEK > > Kevin Wolf (6): > qcow2: Fix refcount table size calculation > qemu-iotests: qcow2: Test growing large refcount table > fdc: Remove status0 parameter from fdctrl_set_fifo() > fdc-test: Check READ ID > megasas: Use bdrv_drain_all instead of qemu_aio_flush > qemu-io: Use bdrv_drain_all instead of qemu_aio_flush > > Nick Thomas (1): > tests: allow qemu-iotests to be run against nbd backend > > Stefan Hajnoczi (4): > MAINTAINERS: add Stefan Hajnoczi as block and virtio-blk co-maintainer > aio: switch aiocb_size type int -> size_t > aio: use g_slice_alloc() for AIOCB pooling > aio: rename AIOPool to AIOCBInfo > > Stefan Weil (1): > block: Workaround for older versions of MinGW gcc > > MAINTAINERS |2 + > block.c | 31 +++ > block/blkdebug.c |4 +- > block/blkverify.c|4 +- > block/curl.c |4 +- > block/gluster.c |6 +- > block/iscsi.c| 12 +- > block/linux-aio.c|4 +- > block/qcow2-refcount.c |3 +- > block/qed.c |4 +- > block/rbd.c |4 +- > block/sheepdog.c |4 +- > block/vmdk.c | 10 ++- > block/win32-aio.c| 14 ++-- > dma-helpers.c|4 +- > hw/fdc.c | 121 +--- > hw/ide/core.c|4 +- > hw/megasas.c |2 +- > qemu-aio.h | 12 +-- > qemu-doc.texi| 49 ++ > qemu-io.c|2 +- > qemu-options.hx | 17 > tests/fdc-test.c | 192 > +- > tests/qemu-iotests/044 | 117 +++ > tests/qemu-iotests/044.out |6 + > tests/qemu-iotests/common| 13 ++- > tests/qemu-iotests/common.config | 10 +- > tests/qemu-iotests/common.rc | 23 +- > tests/qemu-iotests/group |1 + > tests/qemu-iotests/iotests.py|6 +- > tests/qemu-iotests/qcow2.py |9 +- > thread-pool.c|4 +- > 32 files changed, 556 insertions(+), 142 deletions(-) > create mode 100755 tests/qemu-iotests/044 > create mode 100644 tests/qemu-iotests/044.out Ping?
[Qemu-devel] [PATCH] Fix the inconsistency in x509-dh-key-file parameter
Commit c448e8552b0f6135dabddf944a7110f929c08320 (spice: tls support) added options to the -spice command line. But there is an inconsistency between the declaration of the option 'x509-dh-key-file' to -spice command line and its parameter parsing 'x509-dh-file' in function qemu_spice_init. https://bugs.launchpad.net/qemu/+bug/1035042 Reported-by: Alon Bar-Lev Signed-off-by: Lei Li --- ui/spice-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ui/spice-core.c b/ui/spice-core.c index 5147365..261c6f2 100644 --- a/ui/spice-core.c +++ b/ui/spice-core.c @@ -610,7 +610,7 @@ void qemu_spice_init(void) } x509_key_password = qemu_opt_get(opts, "x509-key-password"); -x509_dh_file = qemu_opt_get(opts, "x509-dh-file"); +x509_dh_file = qemu_opt_get(opts, "x509-dh-key-file"); tls_ciphers = qemu_opt_get(opts, "tls-ciphers"); } -- 1.7.7.6
[Qemu-devel] [PATCH] curses: Remove OpenBSD workaround
I removed the same sort of workaround for OpenBSD within the configure script with commit 4dcc3f5876fa638d5c35bd47be3b717ea74cc2e7 but didn't bother to grep further to come across this same chunk of code in the curses code itself. So the following diff removes the same workaround chunk within the curses code. Signed-off-by: Brad Smith diff --git a/ui/curses.c b/ui/curses.c index b40b223..5dc0b2c 100644 --- a/ui/curses.c +++ b/ui/curses.c @@ -28,10 +28,6 @@ #include #endif -#ifdef __OpenBSD__ -#define resize_term resizeterm -#endif - #include "qemu-common.h" #include "console.h" #include "sysemu.h" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Hi Paolo, Am 19.11.2012 09:10, schrieb Paolo Bonzini: I'm sorry the discard requests aren't failing. Qemu / Block driver starts to cancel a bunch of requests. That is being done in the kernel (the guest, I think) because the UNMAPs are taking too long. That makes sense. RBD handles discards as buffered I/O. When i do an mkfs.xfs on a 30GB device i see around 900 pending discard requests. rbd finishes them all before reporting success. If it is correct that a 3.6.7 kernel sends as many discard requests i only the a solution in using unbuffered I/O for discards. Do you know what is the correct way? Greets, Stefan
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 10:36, Stefan Priebe - Profihost AG ha scritto: > Hi Paolo, > > Am 19.11.2012 09:10, schrieb Paolo Bonzini: >>> I'm sorry the discard requests aren't failing. Qemu / Block driver >>> starts to cancel a bunch of requests. >> >> That is being done in the kernel (the guest, I think) because the UNMAPs >> are taking too long. > > That makes sense. RBD handles discards as buffered I/O. When i do an > mkfs.xfs on a 30GB device i see around 900 pending discard requests. rbd > finishes them all before reporting success. > > If it is correct that a 3.6.7 kernel sends as many discard requests i > only the a solution in using unbuffered I/O for discards. > > Do you know what is the correct way? I think the correct fix is to serialize them in the kernel. Paolo
[Qemu-devel] [PULL urgent 0/4] build system fixes for 1.3
Anyone, the following changes since commit e24dc9feb0d68142d54dc3c097f57588836d1338: tci: Support deposit operations (2012-11-18 20:40:08 +) are available in the git repository at: git://github.com/bonzini/qemu.git build-urgent for you to fetch changes up to 16529cedcef18bf116f10279e9c9abb6645467d6: Makefile: Add missing dependency (fix parallel builds) (2012-11-19 10:48:32 +0100) Thanks, Paolo Paolo Bonzini (3): libcacard: make unnesting rules available to Makefile.objs libcacard: link in stubs tests: link in stubs Stefan Weil (1): Makefile: Add missing dependency (fix parallel builds) Makefile | 2 ++ libcacard/Makefile | 4 ++-- tests/Makefile | 4 ++-- 3 file modificati, 6 inserzioni(+), 4 rimozioni(-) -- 1.7.12.1
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Am 19.11.2012 10:54, schrieb Paolo Bonzini: Il 19/11/2012 10:36, Stefan Priebe - Profihost AG ha scritto: Hi Paolo, Am 19.11.2012 09:10, schrieb Paolo Bonzini: I'm sorry the discard requests aren't failing. Qemu / Block driver starts to cancel a bunch of requests. That is being done in the kernel (the guest, I think) because the UNMAPs are taking too long. That makes sense. RBD handles discards as buffered I/O. When i do an mkfs.xfs on a 30GB device i see around 900 pending discard requests. rbd finishes them all before reporting success. If it is correct that a 3.6.7 kernel sends as many discard requests i only the a solution in using unbuffered I/O for discards. Do you know what is the correct way? I think the correct fix is to serialize them in the kernel. So you mean this is not a bug in rbd or qemu this is a general bug in the linux kernel since they implemented discard? Greets, Stefan
Re: [Qemu-devel] [PATCH] Fix the inconsistency in x509-dh-key-file parameter
On 11/19/12 10:15, Lei Li wrote: > Commit c448e8552b0f6135dabddf944a7110f929c08320 (spice: tls > support) added options to the -spice command line. But there > is an inconsistency between the declaration of the option > 'x509-dh-key-file' to -spice command line and its parameter > parsing 'x509-dh-file' in function qemu_spice_init. Patch added to spice patch queue. thanks, Gerd
Re: [Qemu-devel] [PATCH] rng-egd: don't use gslist_free_full
Am 16.11.2012 20:10, schrieb Anthony Liguori: > This function was only introduced in glib 2.28.0. > > Signed-off-by: Anthony Liguori In fact it seems that this file should use typesafe qemu-queue.h lists instead of GSList. Kevin
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 10:59, Stefan Priebe - Profihost AG ha scritto: >>> >>> >>> Do you know what is the correct way? >> >> I think the correct fix is to serialize them in the kernel. > > So you mean this is not a bug in rbd or qemu this is a general bug in > the linux kernel since they implemented discard? Yes. Paolo
Re: [Qemu-devel] [PATCH] iscsi: do not assume device is zero initialized
Am 19.11.2012 um 09:25 schrieb Paolo Bonzini :
> Il 17/11/2012 16:20, Peter Lieven ha scritto:
>> Without any complex checks we can't assume that an
>> iscsi target is initialized to zero.
>>
>> Signed-off-by: Peter Lieven
>> ---
>> block/iscsi.c |6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/block/iscsi.c b/block/iscsi.c
>> index eb586cb..d685f20 100644
>> --- a/block/iscsi.c
>> +++ b/block/iscsi.c
>> @@ -991,6 +991,11 @@ out:
>> return ret;
>> }
>>
>> +static int iscsi_has_zero_init(BlockDriverState *bs)
>> +{
>> +return 0;
>> +}
>> +
>> static QEMUOptionParameter iscsi_create_options[] = {
>> {
>> .name = BLOCK_OPT_SIZE,
>> @@ -1017,6 +1022,7 @@ static BlockDriver bdrv_iscsi = {
>> .bdrv_aio_flush = iscsi_aio_flush,
>>
>> .bdrv_aio_discard = iscsi_aio_discard,
>> +.bdrv_has_zero_init = iscsi_has_zero_init,
>>
>> #ifdef __linux__
>> .bdrv_ioctl = iscsi_ioctl,
>>
>
> Applied to scsi-next branch.
Thank you.
Wouldn`t it be better to have has_zero_init == 0 as default and set it to 1 for
the backends
that support it?
Peter
>
> Paolo
Re: [Qemu-devel] [PATCH] vnc: added initial websockets support
On 11/19/2012 09:56 AM, Gerd Hoffmann wrote: > On 11/19/12 00:29, Tim Hardeck wrote: >> Hi Stefan, >> >> thanks for your input but how should it be implemented? >> >> I personally would like activating Websockets as a VNC option like: >> " -vnc :0 -vnc :1,websockets" I have already tested this locally >> and it does work but only for one protocol since QEMU does only >> interpret the last vnc option. So is allowing more than one VNC >> command line entry in combination with having more than one VNC >> thread for the same display worth working on or do you have >> something different in mind? > > -vnc :0,websock=$portnr ? This sounds resonable although maybe the websockets port could just always be display + 1 so there is no need to parse a port. Regards Tim -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany T: +49 (0) 911 74053-0 F: +49 (0) 911 74053-483 http://www.suse.de/ signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Am 19.11.2012 11:06, schrieb Paolo Bonzini: Il 19/11/2012 10:59, Stefan Priebe - Profihost AG ha scritto: Do you know what is the correct way? I think the correct fix is to serialize them in the kernel. So you mean this is not a bug in rbd or qemu this is a general bug in the linux kernel since they implemented discard? Yes. As you're known in the linux dev community ;-) Might you open a thread / discussion in the linux kernel mailinglist CC'ing me regarding this problem? I think when i open one - no one will listen ;-) Greets Stefan
[Qemu-devel] [PATCH 4/4] Makefile: Add missing dependency (fix parallel builds)
From: Stefan Weil The executables in i386-softmmu, i386-linux-user, ... depend on the recently added libqemustub.a. Signed-off-by: Stefan Weil Signed-off-by: Paolo Bonzini --- Makefile | 2 ++ 1 file modificato, 2 inserzioni(+) diff --git a/Makefile b/Makefile index b8301a2..3e8d441 100644 --- a/Makefile +++ b/Makefile @@ -127,6 +127,8 @@ pixman/Makefile: $(SRC_PATH)/pixman/configure $(SRC_PATH)/pixman/configure: (cd $(SRC_PATH)/pixman; autoreconf -v --install) +$(SUBDIR_RULES): libqemustub.a + $(filter %-softmmu,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) $(common-obj-y) $(extra-obj-y) subdir-libdis $(filter %-user,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) subdir-libdis-user subdir-libuser -- 1.7.12.1
[Qemu-devel] [BUG] qemu crash when using "lsilogic"
Hi all and Avi,
I met the upstream qemu crash when using "lsilogic", my first sight is that I
can't access the VNC view, it gave me a black screen, here is my command line,
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -m 3096 -M pc-0.15
-enable-kvm -smp 4,sockets=4,cores=1,threads=1 -drive
file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 -device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-vnc 127.0.0.1:7 -device lsi,id=scsi0,bus=pci.0,addr=0x8 -drive
file=/vm/scsi-disks/scsi1.img,if=none,id=drive-scsi0-0-0,format=raw -device
scsi-hd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0
After that, I run a bisect, and here is my bisect log:
$ git bisect log
git bisect start
# bad: [e24dc9feb0d68142d54dc3c097f57588836d1338] tci: Support deposit
operations
git bisect bad e24dc9feb0d68142d54dc3c097f57588836d1338
# good: [8db972cfa469b4e4afd9c65e54e796b83b5ce3a2] Update version for 1.2.0
git bisect good 8db972cfa469b4e4afd9c65e54e796b83b5ce3a2
# good: [7762c2c1e02e44fdc473cbe75105faba08b906cc] memory: rename
'exec-obsolete.h'
git bisect good 7762c2c1e02e44fdc473cbe75105faba08b906cc
# bad: [f3cdbc329fa7621ece7e673f23c3101e6b0c952b] hw/vexpress.c: Don't
prematurely explode QEMUMachineInitArgs
git bisect bad f3cdbc329fa7621ece7e673f23c3101e6b0c952b
# bad: [3cbc002c34aa85ea952ee9b169a3ff97d350516a] block: prepare code for
adding block notifiers
git bisect bad 3cbc002c34aa85ea952ee9b169a3ff97d350516a
# good: [f354b1a1ee7a1c72d51b42808724a2b10eec315f] fix CONFIG_QEMU_HELPERDIR
generation again
git bisect good f354b1a1ee7a1c72d51b42808724a2b10eec315f
# good: [aa723c23147e93fef8475bd80fd29e633378c34d] cpus: create
qemu_in_vcpu_thread()
git bisect good aa723c23147e93fef8475bd80fd29e633378c34d
# bad: [90734e02bd2fb137346d4184cec6c5d26e68f29b] serial: add pci-serial
documentation
git bisect bad 90734e02bd2fb137346d4184cec6c5d26e68f29b
# bad: [1d71148eace669827ba15101819b54b20fcca616] memory: move tcg flush into a
tcg memory listener
git bisect bad 1d71148eace669827ba15101819b54b20fcca616
# bad: [975aefe011197453284a4ab777000183e6096d5b] memory: provide defaults for
MemoryListener operations
git bisect bad 975aefe011197453284a4ab777000183e6096d5b
# bad: [12b40e471f33e552fa3d962887b416cf67831446] xen_pt: use separate
MemoryListeners for memory and I/O
git bisect bad 12b40e471f33e552fa3d962887b416cf67831446
# bad: [d22b096ef6e0b20810193b68a1d472f3fb8a4f9e] kvm: use separate
MemoryListeners for memory and I/O
git bisect bad d22b096ef6e0b20810193b68a1d472f3fb8a4f9e
# good: [0fada67420e29f389119ca6f44285203400e0730] vhost: use MemoryListener
filtering to only monitor RAM address space
git bisect good 0fada67420e29f389119ca6f44285203400e0730
After the last bisect step, it showed below,
$ git bisect good
d22b096ef6e0b20810193b68a1d472f3fb8a4f9e is the first bad commit
commit d22b096ef6e0b20810193b68a1d472f3fb8a4f9e
Author: Avi Kivity
Date: Sun Sep 30 22:21:11 2012 +0200
kvm: use separate MemoryListeners for memory and I/O
The construct
if (address_space == get_system_memory()) {
// memory thing
} else {
// io thing
}
fails if we have more than two address spaces. Use a separate listener
for memory and I/O, and utilize MemoryListener's address space filtering to
fix this.
Signed-off-by: Avi Kivity
:100644 100644 92a71374ed1e040cef5ad70a6cb00adabf671dd4
c69e01200461c7a87440f7a915bd171a9fc8f318 M kvm-all.c
Ops, I didn't find any error in above patch, can you guys help to
investigate this bug?
Thanks,
Wanlong Gao
[Qemu-devel] [PATCH 1/4] libcacard: make unnesting rules available to Makefile.objs
Signed-off-by: Paolo Bonzini --- libcacard/Makefile | 2 +- 1 file modificato, 1 inserzione(+). 1 rimozione(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index 487f434..f501cec 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -1,6 +1,6 @@ -include ../config-host.mak --include $(SRC_PATH)/Makefile.objs -include $(SRC_PATH)/rules.mak +-include $(SRC_PATH)/Makefile.objs libcacard_includedir=$(includedir)/cacard -- 1.7.12.1
[Qemu-devel] [PATCH 3/4] tests: link in stubs
Signed-off-by: Paolo Bonzini --- tests/Makefile | 4 ++-- 1 file modificato, 2 inserzioni(+), 2 rimozioni(-) diff --git a/tests/Makefile b/tests/Makefile index 9bf0765..ca680e5 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -48,7 +48,7 @@ tests/check-qdict$(EXESUF): tests/check-qdict.o qdict.o qfloat.o qint.o qstring. tests/check-qlist$(EXESUF): tests/check-qlist.o qlist.o qint.o tests/check-qfloat$(EXESUF): tests/check-qfloat.o qfloat.o tests/check-qjson$(EXESUF): tests/check-qjson.o $(qobject-obj-y) qemu-tool.o -tests/test-coroutine$(EXESUF): tests/test-coroutine.o $(coroutine-obj-y) $(tools-obj-y) $(block-obj-y) iov.o +tests/test-coroutine$(EXESUF): tests/test-coroutine.o $(coroutine-obj-y) $(tools-obj-y) $(block-obj-y) iov.o libqemustub.a tests/test-iov$(EXESUF): tests/test-iov.o iov.o tests/test-qapi-types.c tests/test-qapi-types.h :\ @@ -81,7 +81,7 @@ TARGETS=$(patsubst %-softmmu,%, $(filter %-softmmu,$(TARGET_DIRS))) QTEST_TARGETS=$(foreach TARGET,$(TARGETS), $(if $(check-qtest-$(TARGET)-y), $(TARGET),)) check-qtest-$(CONFIG_POSIX)=$(foreach TARGET,$(TARGETS), $(check-qtest-$(TARGET)-y)) -qtest-obj-y = tests/libqtest.o $(oslib-obj-y) +qtest-obj-y = tests/libqtest.o $(oslib-obj-y) libqemustub.a $(check-qtest-y): $(qtest-obj-y) .PHONY: check-help -- 1.7.12.1
[Qemu-devel] [PATCH 3/5] virtio-9p: use symbolic constant, add to pci-ids.txt
Signed-off-by: Paolo Bonzini --- docs/specs/pci-ids.txt | 1 + hw/9pfs/virtio-9p-device.c | 2 +- hw/pci.h | 1 + 3 file modificati, 3 inserzioni(+). 1 rimozione(-) diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt index 445b293..28dcf90 100644 --- a/docs/specs/pci-ids.txt +++ b/docs/specs/pci-ids.txt @@ -20,6 +20,7 @@ maintained as part of the virtio specification. 1af4:1003 console device 1af4:1004 SCSI host bus adapter device 1af4:1005 entropy generator device +1af4:1009 9p filesystem device 1af4:10f0 Available for experimental usage without registration. Must get to official ID when the code leaves the test lab (i.e. when seeking diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index b8220ab..e338c46 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -170,7 +170,7 @@ static void virtio_9p_class_init(ObjectClass *klass, void *data) k->init = virtio_9p_init_pci; k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET; -k->device_id = 0x1009; +k->device_id = PCI_DEVICE_ID_VIRTIO_9P; k->revision = VIRTIO_PCI_ABI_VERSION; k->class_id = 0x2; dc->props = virtio_9p_properties; diff --git a/hw/pci.h b/hw/pci.h index 4da0c2a..0719521 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -77,6 +77,7 @@ #define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003 #define PCI_DEVICE_ID_VIRTIO_SCSI0x1004 #define PCI_DEVICE_ID_VIRTIO_RNG 0x1005 +#define PCI_DEVICE_ID_VIRTIO_9P 0x1009 #define FMT_PCIBUS PRIx64 -- 1.7.12.1
[Qemu-devel] [PATCH 4/5] ivshmem: use symbolic constant for PCI ID, add to pci-ids.txt
Signed-off-by: Paolo Bonzini --- docs/specs/pci-ids.txt | 2 ++ hw/ivshmem.c | 2 +- hw/pci.h | 1 + 3 file modificati, 4 inserzioni(+). 1 rimozione(-) diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt index 28dcf90..6b5cf42 100644 --- a/docs/specs/pci-ids.txt +++ b/docs/specs/pci-ids.txt @@ -29,4 +29,6 @@ maintained as part of the virtio specification. 1af4:1100 Used as PCI Subsystem ID for existing hardware devices emulated by qemu. +1af4:1110 ivshmem device (shared memory, docs/specs/ivshmem_device_spec.txt) + All other device IDs are reserved. diff --git a/hw/ivshmem.c b/hw/ivshmem.c index f6dbb21..8adeb2c 100644 --- a/hw/ivshmem.c +++ b/hw/ivshmem.c @@ -800,7 +800,7 @@ static void ivshmem_class_init(ObjectClass *klass, void *data) k->init = pci_ivshmem_init; k->exit = pci_ivshmem_uninit; k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET; -k->device_id = 0x1110; +k->device_id = PCI_DEVICE_ID_QUMRANET_IVSHMEM; k->class_id = PCI_CLASS_MEMORY_RAM; dc->reset = ivshmem_reset; dc->props = ivshmem_properties; diff --git a/hw/pci.h b/hw/pci.h index 0719521..3704d5f 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -78,6 +78,7 @@ #define PCI_DEVICE_ID_VIRTIO_SCSI0x1004 #define PCI_DEVICE_ID_VIRTIO_RNG 0x1005 #define PCI_DEVICE_ID_VIRTIO_9P 0x1009 +#define PCI_DEVICE_ID_QUMRANET_IVSHMEM 0x1110 #define FMT_PCIBUS PRIx64 -- 1.7.12.1
Re: [Qemu-devel] [PATCH v3] DSDT: Fix HPET _CRS Method
On 16.11.2012, at 19:46, Kevin O'Connor wrote: > On Fri, Nov 16, 2012 at 01:02:18PM -0500, Gabriel L. Somlo wrote: >> ping >> >> On Thu, Nov 08, 2012 at 12:35:17PM -0500, Gabriel L. Somlo wrote: >>> Updated _CRS method for HPET, bringing it in line with the way it is >>> presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, etc); >>> Allows it to be detected and utilized from Mac OS X; Also tested OK on >>> Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). >>> >>> Signed-off-by: Gabriel Somlo > > I'm okay with the patch. I'm looking to see an Ack from one of the > kvm/qemu developers. (I saw Gerd was okay with the last version of > the patch.) IIRC Marcelo was the one changing the DSDT code from what this patch produces to what we have today. My initial HPET DSDT entry was also copied from real hardware. Marcelo, any memory on this? :) Keep in mind I might be misremembering - maybe it was someone else after all ;). Alex
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 11:13, Stefan Priebe - Profihost AG ha scritto: >>> >>> So you mean this is not a bug in rbd or qemu this is a general bug in >>> the linux kernel since they implemented discard? >> >> Yes. > > As you're known in the linux dev community ;-) Might you open a thread / > discussion in the linux kernel mailinglist CC'ing me regarding this > problem? I think when i open one - no one will listen ;-) Yeah, I'll try making and sending a patch, that's usually a good way to convince those guys to listen... Paolo
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Am 19.11.2012 11:23, schrieb Paolo Bonzini: Il 19/11/2012 11:13, Stefan Priebe - Profihost AG ha scritto: So you mean this is not a bug in rbd or qemu this is a general bug in the linux kernel since they implemented discard? Yes. As you're known in the linux dev community ;-) Might you open a thread / discussion in the linux kernel mailinglist CC'ing me regarding this problem? I think when i open one - no one will listen ;-) Yeah, I'll try making and sending a patch, that's usually a good way to convince those guys to listen... Thanks. But do you have any idea why it works with an iscsi / libiscsi backend? In that case the kernel does not cancel the I/O. Greets, Stefan
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 11:30, Stefan Priebe - Profihost AG ha scritto: > > > But do you have any idea why it works with an iscsi / libiscsi backend? > In that case the kernel does not cancel the I/O. It tries to, but the command ultimately succeeds and the success response "undoes" the cancel. http://thread.gmane.org/gmane.comp.emulators.qemu/166232/focus=166316 See also the whole thread (and I think there as a part of it offlist, too). Paolo
Re: [Qemu-devel] [PATCH 7/7] virtio-blk: add x-data-plane=on|off performance feature
Am 16.11.2012 07:22, schrieb Stefan Hajnoczi: > On Thu, Nov 15, 2012 at 10:08 PM, Anthony Liguori wrote: >> Stefan Hajnoczi writes: >> >>> The virtio-blk-data-plane feature is easy to integrate into >>> hw/virtio-blk.c. The data plane can be started and stopped similar to >>> vhost-net. >>> >>> Users can take advantage of the virtio-blk-data-plane feature using the >>> new -device virtio-blk-pci,x-data-plane=on property. >> >> I don't think this should be a property of virtio-blk-pci but rather a >> separate device. > > The hw/virtio-blk.c code still needs to be used since > hw/dataplane/virtio-blk.c is only a subset of virtio-blk. > > So we're talking about adding a new virtio-blk-data-plane-pci device > type to hw/virtio-pci.c? A new device sounds wrong to me, it's the very same thing from a guest perspective. Which makes me wonder if in the final version it shouldn't be a -blockdev option rather than a -device one... Kevin
[Qemu-devel] [PATCH 1/5] docs: move pci-ids.txt to docs/specs/
Signed-off-by: Paolo Bonzini --- pci-ids.txt => docs/specs/pci-ids.txt | 0 1 file modificato, 0 inserzioni(+), 0 rimozioni(-) rename pci-ids.txt => docs/specs/pci-ids.txt (100%) diff --git a/pci-ids.txt b/docs/specs/pci-ids.txt similarity index 100% rename from pci-ids.txt rename to docs/specs/pci-ids.txt -- 1.7.12.1
Re: [Qemu-devel] [PATCH] vnc: added initial websockets support
On 11/19/2012 10:07 AM, Stefan Hajnoczi wrote: > On Mon, Nov 19, 2012 at 12:29:44AM +0100, Tim Hardeck wrote: >> Hi Stefan, >> >> thanks for your input but how should it be implemented? >> >> I personally would like activating Websockets as a VNC option like: " >> -vnc :0 -vnc :1,websockets" >> I have already tested this locally and it does work but only for one >> protocol since QEMU does only interpret the last vnc option. >> So is allowing more than one VNC command line entry in combination with >> having more than one VNC thread for the same display worth working on or >> do you have something different in mind? > > I'm not familiar enough with the VNC code to suggest how to best > implement this. > > One thing to think about is that Websockets is a transport. Perhaps the > VNC code itself shouldn't speak it, instead generic QEMU socket code > should implement Websockets so that non-VNC components can also make use > of it in the future. I have talked about this with a colleague and it seems like quite some effort for no use case besides VNC. It might be interesting in the long run though. Is the rest of my implementation OK besides the protocol recognition by timeout - which should only be an issue for high latency websockets connection? Regards Tim -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany T: +49 (0) 911 74053-0 F: +49 (0) 911 74053-483 http://www.suse.de/ signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 2/5] reorganize pci-ids.txt
Some devices were missing, and we're using two PCI vendor ids. This patch only adds devices that are already documented in hw/pci.h. Signed-off-by: Paolo Bonzini --- docs/specs/pci-ids.txt | 26 +- 1 file modificato, 13 inserzioni(+), 13 rimozioni(-) diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt index 73125a8..445b293 100644 --- a/docs/specs/pci-ids.txt +++ b/docs/specs/pci-ids.txt @@ -3,29 +3,30 @@ PCI IDs for qemu Red Hat, Inc. donates a part of its device ID range to qemu, to be used for -virtual devices. The vendor ID is 1af4 (formerly Qumranet ID). +virtual devices. The vendor IDs are 1af4 (formerly Qumranet ID) and 1b36. -The 1000 -> 10ff device ID range is used for VirtIO devices. +Contact Gerd Hoffmann to get a device ID assigned +for your devices. -The 1100 device ID is used as PCI Subsystem ID for existing hardware -devices emulated by qemu. +1af4 vendor ID +-- -All other device IDs are reserved. - - -VirtIO Device IDs -- +The 1000 -> 10ff device ID range is used as follows for virtio-pci devices. +Note that this allocation separate from the virtio device IDs, which are +maintained as part of the virtio specification. 1af4:1000 network device 1af4:1001 block device 1af4:1002 balloon device 1af4:1003 console device - -1af4:1004 Reserved. - to Contact Gerd Hoffmann to get a -1af4:10ef device ID assigned for your new virtio device. +1af4:1004 SCSI host bus adapter device +1af4:1005 entropy generator device 1af4:10f0 Available for experimental usage without registration. Must get to official ID when the code leaves the test lab (i.e. when seeking 1af4:10ff upstream merge or shipping a distro/product) to avoid conflicts. +1af4:1100 Used as PCI Subsystem ID for existing hardware devices emulated + by qemu. + +All other device IDs are reserved. -- 1.7.12.1
Re: [Qemu-devel] [PATCH 0/5] Improve consistency of pci-ids.txt, use symbolic constants for QEMU devices
On 11/19/12 11:21, Paolo Bonzini wrote: > Five small, boring patches. Inspired by Gerd's patch at > http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg05229.html which > unfortunately is already out of date. Thanks for picking this up, series looks good. cheers, Gerd
[Qemu-devel] [PATCH 2/4] libcacard: link in stubs
Signed-off-by: Paolo Bonzini --- libcacard/Makefile | 2 +- 1 file modificato, 1 inserzione(+). 1 rimozione(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index f501cec..c26aac6 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -7,7 +7,7 @@ libcacard_includedir=$(includedir)/cacard $(call set-vpath, $(SRC_PATH)) # objects linked into a shared library, built with libtool with -fPIC if required -QEMU_OBJS=$(oslib-obj-y) qemu-timer-common.o $(trace-obj-y) +QEMU_OBJS=$(oslib-obj-y) qemu-timer-common.o $(trace-obj-y) $(stub-obj-y) QEMU_OBJS_LIB=$(patsubst %.o,%.lo,$(QEMU_OBJS)) QEMU_CFLAGS+=-I../ -- 1.7.12.1
Re: [Qemu-devel] [Qemu-ppc] [PATCH] free the memory malloced by load_at()
On 16.11.2012, at 07:47, Olivia Yin wrote: > Signed-off-by: Olivia Yin > --- > hw/elf_ops.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/hw/elf_ops.h b/hw/elf_ops.h > index db4630e..4495932 100644 > --- a/hw/elf_ops.h > +++ b/hw/elf_ops.h > @@ -178,6 +178,8 @@ static int glue(load_symbols, SZ)(struct elfhdr *ehdr, > int fd, int must_swab, > s->disas_strtab = str; ^ > s->next = syminfos; > syminfos = s; > +g_free(syms); > +g_free(str); Syms and str can both still be dereferenced at this point in time. Alex > g_free(shdr_table); > return 0; > fail: > -- > 1.7.0.4 > > >
[Qemu-devel] [PATCH 5/5] pci: use constants for devices under the 1B36 device ID, document them
Signed-off-by: Paolo Bonzini
---
docs/specs/pci-ids.txt | 15 +++
hw/pci.h | 7 +++
hw/pci_bridge_dev.c| 8 ++--
hw/serial-pci.c| 12 ++--
4 file modificati, 30 inserzioni(+), 12 rimozioni(-)
diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt
index 6b5cf42..2f4a557 100644
--- a/docs/specs/pci-ids.txt
+++ b/docs/specs/pci-ids.txt
@@ -32,3 +32,18 @@ maintained as part of the virtio specification.
1af4:1110 ivshmem device (shared memory, docs/specs/ivshmem_device_spec.txt)
All other device IDs are reserved.
+
+1b36 vendor ID
+--
+
+The -> 00ff device ID range is used as follows for QEMU-specific
+PCI devices (other than virtio):
+
+1b36:0001 PCI-PCI bridge
+1b36:0002 PCI serial port (16550A) adapter (docs/specs/pci-serial.txt)
+1b36:0003 PCI Dual-port 16550A adapter (docs/specs/pci-serial.txt)
+1b36:0004 PCI Quad-port 16550A adapter (docs/specs/pci-serial.txt)
+
+All these devices are documented in docs/specs.
+
+The 0100 device ID is used for the QXL video card device.
+
+All other device IDs are reserved.
diff --git a/hw/pci.h b/hw/pci.h
index 3704d5f..9344842 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -80,6 +80,13 @@
#define PCI_DEVICE_ID_VIRTIO_9P 0x1009
#define PCI_DEVICE_ID_QUMRANET_IVSHMEM 0x1110
+#define PCI_VENDOR_ID_REDHAT 0x1b36
+#define PCI_DEVICE_ID_REDHAT_BRIDGE 0x0001
+#define PCI_DEVICE_ID_REDHAT_SERIAL 0x0002
+#define PCI_DEVICE_ID_REDHAT_SERIAL2 0x0003
+#define PCI_DEVICE_ID_REDHAT_SERIAL4 0x0004
+#define PCI_DEVICE_ID_REDHAT_QXL 0x0100
+
#define FMT_PCIBUS PRIx64
typedef void PCIConfigWriteFunc(PCIDevice *pci_dev,
diff --git a/hw/pci_bridge_dev.c b/hw/pci_bridge_dev.c
index f706396..d72bd3d 100644
--- a/hw/pci_bridge_dev.c
+++ b/hw/pci_bridge_dev.c
@@ -27,10 +27,6 @@
#include "memory.h"
#include "pci_internals.h"
-#define REDHAT_PCI_VENDOR_ID 0x1b36
-#define PCI_BRIDGE_DEV_VENDOR_ID REDHAT_PCI_VENDOR_ID
-#define PCI_BRIDGE_DEV_DEVICE_ID 0x1
-
struct PCIBridgeDev {
PCIBridge bridge;
MemoryRegion bar;
@@ -146,8 +142,8 @@ static void pci_bridge_dev_class_init(ObjectClass *klass,
void *data)
k->init = pci_bridge_dev_initfn;
k->exit = pci_bridge_dev_exitfn;
k->config_write = pci_bridge_dev_write_config;
-k->vendor_id = PCI_BRIDGE_DEV_VENDOR_ID;
-k->device_id = PCI_BRIDGE_DEV_DEVICE_ID;
+k->vendor_id = PCI_VENDOR_ID_REDHAT;
+k->device_id = PCI_DEVICE_ID_REDHAT_BRIDGE;
k->class_id = PCI_CLASS_BRIDGE_PCI;
k->is_bridge = 1,
dc->desc = "Standard PCI Bridge";
diff --git a/hw/serial-pci.c b/hw/serial-pci.c
index 95dc5c8..f7be5fd 100644
--- a/hw/serial-pci.c
+++ b/hw/serial-pci.c
@@ -185,8 +185,8 @@ static void serial_pci_class_initfn(ObjectClass *klass,
void *data)
PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
pc->init = serial_pci_init;
pc->exit = serial_pci_exit;
-pc->vendor_id = 0x1b36; /* Red Hat */
-pc->device_id = 0x0002;
+pc->vendor_id = PCI_VENDOR_ID_REDHAT;
+pc->device_id = PCI_DEVICE_ID_REDHAT_SERIAL;
pc->revision = 1;
pc->class_id = PCI_CLASS_COMMUNICATION_SERIAL;
dc->vmsd = &vmstate_pci_serial;
@@ -199,8 +199,8 @@ static void multi_2x_serial_pci_class_initfn(ObjectClass
*klass, void *data)
PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
pc->init = multi_serial_pci_init;
pc->exit = multi_serial_pci_exit;
-pc->vendor_id = 0x1b36; /* Red Hat */
-pc->device_id = 0x0003;
+pc->vendor_id = PCI_VENDOR_ID_REDHAT;
+pc->device_id = PCI_DEVICE_ID_REDHAT_SERIAL2;
pc->revision = 1;
pc->class_id = PCI_CLASS_COMMUNICATION_SERIAL;
dc->vmsd = &vmstate_pci_multi_serial;
@@ -213,8 +213,8 @@ static void multi_4x_serial_pci_class_initfn(ObjectClass
*klass, void *data)
PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
pc->init = multi_serial_pci_init;
pc->exit = multi_serial_pci_exit;
-pc->vendor_id = 0x1b36; /* Red Hat */
-pc->device_id = 0x0004;
+pc->vendor_id = PCI_VENDOR_ID_REDHAT;
+pc->device_id = PCI_DEVICE_ID_REDHAT_SERIAL4;
pc->revision = 1;
pc->class_id = PCI_CLASS_COMMUNICATION_SERIAL;
dc->vmsd = &vmstate_pci_multi_serial;
--
1.7.12.1
[Qemu-devel] [PATCH 0/5] Improve consistency of pci-ids.txt, use symbolic constants for QEMU devices
Five small, boring patches. Inspired by Gerd's patch at http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg05229.html which unfortunately is already out of date. Paolo Bonzini (5): docs: move pci-ids.txt to docs/specs/ reorganize pci-ids.txt virtio-9p: use symbolic constant, add to pci-ids.txt ivshmem: use symbolic constant for PCI ID, add to pci-ids.txt pci: use constants for devices under the 1B36 device ID, document them docs/specs/pci-ids.txt | 49 ++ hw/9pfs/virtio-9p-device.c | 2 +- hw/ivshmem.c | 2 +- hw/pci.h | 9 + hw/pci_bridge_dev.c| 8 ++-- hw/serial-pci.c| 12 ++-- pci-ids.txt| 31 - 7 file modificati, 68 inserzioni(+), 45 rimozioni(-) create mode 100644 docs/specs/pci-ids.txt delete mode 100644 pci-ids.txt -- 1.7.12.1
Re: [Qemu-devel] [PATCH 7/7] virtio-blk: add x-data-plane=on|off performance feature
Il 19/11/2012 11:38, Kevin Wolf ha scritto: > Am 16.11.2012 07:22, schrieb Stefan Hajnoczi: >> On Thu, Nov 15, 2012 at 10:08 PM, Anthony Liguori >> wrote: >>> Stefan Hajnoczi writes: >>> The virtio-blk-data-plane feature is easy to integrate into hw/virtio-blk.c. The data plane can be started and stopped similar to vhost-net. Users can take advantage of the virtio-blk-data-plane feature using the new -device virtio-blk-pci,x-data-plane=on property. >>> >>> I don't think this should be a property of virtio-blk-pci but rather a >>> separate device. >> >> The hw/virtio-blk.c code still needs to be used since >> hw/dataplane/virtio-blk.c is only a subset of virtio-blk. >> >> So we're talking about adding a new virtio-blk-data-plane-pci device >> type to hw/virtio-pci.c? > > A new device sounds wrong to me, it's the very same thing from a guest > perspective. Which makes me wonder if in the final version it shouldn't > be a -blockdev option rather than a -device one... In the final version it shouldn't be an option at all. :) Paolo
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Yeah thats my old thread regarding iscsi und unmap but this works fine now since you patched qemu. Stefan Am 19.11.2012 11:36, schrieb Paolo Bonzini: Il 19/11/2012 11:30, Stefan Priebe - Profihost AG ha scritto: But do you have any idea why it works with an iscsi / libiscsi backend? In that case the kernel does not cancel the I/O. It tries to, but the command ultimately succeeds and the success response "undoes" the cancel. http://thread.gmane.org/gmane.comp.emulators.qemu/166232/focus=166316 See also the whole thread (and I think there as a part of it offlist, too). Paolo
Re: [Qemu-devel] [PATCH 2/3] hd-geometry.c/s390: Disable geometry translation
On 18/11/12 20:14, Blue Swirl wrote: > On Sun, Nov 18, 2012 at 4:10 PM, Paolo Bonzini wrote: >> Il 17/11/2012 17:07, Blue Swirl ha scritto: >>> On Tue, Nov 13, 2012 at 8:50 AM, Christian Borntraeger >>> wrote: From: Einar Lueck This patch disables the translation of geometry information read from disks on s390. On s390 such translations lead to wrong geometries being advertized to the guest because there is no entity doing these kinds of translation on this architecture. Signed-off-by Einar Lueck Signed-off-by Christian Borntraeger --- hw/hd-geometry.c |5 + 1 file changed, 5 insertions(+) diff --git a/hw/hd-geometry.c b/hw/hd-geometry.c index 4cf040d..db1dc81 100644 --- a/hw/hd-geometry.c +++ b/hw/hd-geometry.c @@ -144,6 +144,10 @@ static int guess_disk_msdosgeo(BlockDriverState *bs, continue; } +#ifdef __s390__ >>> >>> No, this would make all system emulators (e.g. x86) on s390 host to >>> use this translation, not just s390. I think you want to use #ifdef >>> CONFIG_S390X instead. >> >> This symbol is not available because this file is compiled just once. >> Which non-x86 targets actually care about translation stuff? > > I meant TARGET_S390X, sorry. I have no idea, but hosts and targets > should not be confused. Would a modified patch with TARGET_S390X be acceptable?
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 11:57, Stefan Priebe - Profihost AG ha scritto: > Yeah thats my old thread regarding iscsi und unmap but this works fine > now since you patched qemu. It still causes hangs no? Though it works apart from that. Paolo > Stefan > > Am 19.11.2012 11:36, schrieb Paolo Bonzini: >> Il 19/11/2012 11:30, Stefan Priebe - Profihost AG ha scritto: >>> >>> >>> But do you have any idea why it works with an iscsi / libiscsi backend? >>> In that case the kernel does not cancel the I/O. >> >> It tries to, but the command ultimately succeeds and the success >> response "undoes" the cancel. >> >> http://thread.gmane.org/gmane.comp.emulators.qemu/166232/focus=166316 >> >> See also the whole thread (and I think there as a part of it offlist, >> too). >> >> Paolo >>
Re: [Qemu-devel] [PATCH 2/3] hd-geometry.c/s390: Disable geometry translation
On 19.11.2012, at 11:59, Christian Borntraeger wrote: > On 18/11/12 20:14, Blue Swirl wrote: >> On Sun, Nov 18, 2012 at 4:10 PM, Paolo Bonzini wrote: >>> Il 17/11/2012 17:07, Blue Swirl ha scritto: On Tue, Nov 13, 2012 at 8:50 AM, Christian Borntraeger wrote: > From: Einar Lueck > > This patch disables the translation of geometry information read from > disks on s390. On s390 such translations lead to wrong geometries being > advertized to the guest because there is no entity doing these kinds > of translation on this architecture. > > Signed-off-by Einar Lueck > Signed-off-by Christian Borntraeger > --- > hw/hd-geometry.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/hw/hd-geometry.c b/hw/hd-geometry.c > index 4cf040d..db1dc81 100644 > --- a/hw/hd-geometry.c > +++ b/hw/hd-geometry.c > @@ -144,6 +144,10 @@ static int guess_disk_msdosgeo(BlockDriverState *bs, > continue; > } > > +#ifdef __s390__ No, this would make all system emulators (e.g. x86) on s390 host to use this translation, not just s390. I think you want to use #ifdef CONFIG_S390X instead. >>> >>> This symbol is not available because this file is compiled just once. >>> Which non-x86 targets actually care about translation stuff? >> >> I meant TARGET_S390X, sorry. I have no idea, but hosts and targets >> should not be confused. > > Would a modified patch with TARGET_S390X be acceptable? If TARGET_S390X is defined in that file (read: it's compiled individually for every target), yes. Otherwise please make this a runtime check and set the runtime checked variable in code that is target specific. Alex
Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH v4 2/3] use uimage_reset to reload uimage
On 16.11.2012, at 07:11, Yin Olivia-R63875 wrote:
> Hi Stuart,
>
> load_uimage() is a public function which is called by below files:
> hw/dummy_m68k.c:kernel_size = load_uimage(kernel_filename,
> &entry, NULL, NULL);
> hw/an5206.c:kernel_size = load_uimage(kernel_filename, &entry,
> NULL, NULL);
> hw/ppc440_bamboo.c:success = load_uimage(kernel_filename,
> &entry, &loadaddr, NULL);
> hw/openrisc_sim.c:kernel_size =
> load_uimage(kernel_filename, entry, NULL, NULL);
> hw/ppc/e500.c:kernel_size =
> load_uimage(params->kernel_filename, &entry, &loadaddr, NULL);
> hw/arm_boot.c:kernel_size = load_uimage(info->kernel_filename,
> &entry, NULL, &is_linux);
> hw/microblaze_boot.c:kernel_size =
> load_uimage(kernel_filename, &uentry, &loadaddr, 0);
> hw/mcf5208.c:kernel_size = load_uimage(kernel_filename, &entry,
> NULL, NULL);
>
> Most value of *is_linux is NULL, only arm_boot.c will check the value of
> is_linux.
> I just define an static variable is_linux other than include it into
> structure ImageFile.
Just load the uImage once on load_uimage, so that you can populate all the
passed down return variables (entry, loadaddr, is_linux). No need for a global
here.
> To define static variable kernel_loaded because function
> uimage_physical_loader() will
> be called twice.
> 1) load_uimage() which will run only one time when startup.
> 2) uimage_reset() which will run once reset, so it maybe run many times.
> Since "ROM images must be loaded at startup", it means rom_add_*() should not
> be called by any reset handlers.
> So I use variable kernel_loaded to decide the booting is startup or reset.
Pass it as a function argument then?
Alex
>
>
> Best Regards,
> Olivia
>
>
>> -Original Message-
>> From: Stuart Yoder [mailto:b08...@gmail.com]
>> Sent: Friday, November 16, 2012 4:46 AM
>> To: Yin Olivia-R63875
>> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org
>> Subject: Re: [Qemu-devel] [RFC PATCH v4 2/3] use uimage_reset to reload
>> uimage
>>
>> On Wed, Nov 14, 2012 at 2:28 PM, Olivia Yin
>> wrote:
>>> Signed-off-by: Olivia Yin
>>> ---
>>> hw/loader.c | 64 ++-
>> ---
>>> 1 files changed, 46 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/hw/loader.c b/hw/loader.c index a8a0a09..1a909d0 100644
>>> --- a/hw/loader.c
>>> +++ b/hw/loader.c
>>> @@ -55,6 +55,8 @@
>>> #include
>>>
>>> static int roms_loaded;
>>> +static int kernel_loaded;
>>> +static int *is_linux;
>>
>> Why do we need these 2 new variables?
>>
>>> /* return the size or -1 if error */
>>> int get_image_size(const char *filename) @@ -472,15 +474,14 @@ static
>>> ssize_t gunzip(void *dst, size_t dstlen, uint8_t *src,
>>> return dstbytes;
>>> }
>>>
>>> -/* Load a U-Boot image. */
>>> -int load_uimage(const char *filename, hwaddr *ep,
>>> -hwaddr *loadaddr, int *is_linux)
>>> +/* write uimage into memory */
>>> +static int uimage_physical_loader(const char *filename, uint8_t **data,
>>> + hwaddr *loadaddr, int *is_linux)
>>> {
>>> int fd;
>>> int size;
>>> uboot_image_header_t h;
>>> uboot_image_header_t *hdr = &h;
>>> -uint8_t *data = NULL;
>>> int ret = -1;
>>>
>>> fd = open(filename, O_RDONLY | O_BINARY); @@ -521,10 +522,9 @@
>>> int load_uimage(const char *filename, hwaddr *ep,
>>> *is_linux = 0;
>>> }
>>>
>>> -*ep = hdr->ih_ep;
>>> -data = g_malloc(hdr->ih_size);
>>> +*data = g_malloc(hdr->ih_size);
>>>
>>> -if (read(fd, data, hdr->ih_size) != hdr->ih_size) {
>>> +if (read(fd, *data, hdr->ih_size) != hdr->ih_size) {
>>> fprintf(stderr, "Error reading file\n");
>>> goto out;
>>> }
>>> @@ -534,11 +534,11 @@ int load_uimage(const char *filename, hwaddr *ep,
>>> size_t max_bytes;
>>> ssize_t bytes;
>>>
>>> -compressed_data = data;
>>> +compressed_data = *data;
>>> max_bytes = UBOOT_MAX_GUNZIP_BYTES;
>>> -data = g_malloc(max_bytes);
>>> +*data = g_malloc(max_bytes);
>>>
>>> -bytes = gunzip(data, max_bytes, compressed_data, hdr->ih_size);
>>> +bytes = gunzip(*data, max_bytes, compressed_data,
>>> + hdr->ih_size);
>>> g_free(compressed_data);
>>> if (bytes < 0) {
>>> fprintf(stderr, "Unable to decompress gzipped image!\n");
>>> @@ -547,7 +547,9 @@ int load_uimage(const char *filename, hwaddr *ep,
>>> hdr->ih_size = bytes;
>>> }
>>>
>>> -rom_add_blob_fixed(filename, data, hdr->ih_size, hdr->ih_load);
>>> +if (!kernel_loaded) {
>>> +rom_add_blob_fixed(filename, *data, hdr->ih_size, hdr-
>>> ih_load);
>>> +}
>>
>> Why do we need to keep the rom_add_blob_fixed() call? I thought the
>> point of this was to remove adding roms.
>>
>>> if (loadaddr)
>>>
Re: [Qemu-devel] [Qemu-trivial] [PATCH] block: Fix regression for MinGW (assertion caused by short string)
On Sun, Nov 18, 2012 at 09:26:15AM +0100, Stefan Weil wrote:
> The local string tmp_filename is passed to function get_tmp_filename
> which expects a string with minimum size MAX_PATH for w32 hosts.
>
> MAX_PATH is 260 and PATH_MAX is 259, so tmp_filename was too short.
>
> Commit eba25057b9a5e19d10ace2bc7716667a31297169 introduced this
> regression.
>
> Signed-off-by: Stefan Weil
> ---
> block.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block.c b/block.c
> index 49dd6bb..8739635 100644
> --- a/block.c
> +++ b/block.c
> @@ -787,7 +787,7 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
> int flags,
>BlockDriver *drv)
> {
> int ret;
> -char tmp_filename[PATH_MAX];
> +char tmp_filename[PATH_MAX + 1];
This is not maintainable - the patch is making an assumption about the relative
values of MAX_PATH and PATH_MAX. There is no comment explaining this so it's
likely to be changed and break in the future again.
A clean solution is to change get_tmp_filename() so the caller doesn't need to
pass in a fixed size:
/*
* Create a uniquely-named empty temporary file.
* Return 0 upon success, otherwise a negative errno value.
*
* The filename must be freed with g_free() when it is no longer needed.
*/
int get_tmp_filename(char **filename)
The existing get_tmp_filename() code has another problem. Here is the Windows
get_tmp_filename() code:
char temp_dir[MAX_PATH];
/* GetTempFileName requires that its output buffer (4th param)
have length MAX_PATH or greater. */
assert(size >= MAX_PATH);
return (GetTempPath(MAX_PATH, temp_dir)
&& GetTempFileName(temp_dir, "qem", 0, filename)
? 0 : -GetLastError());
The assert has an off-by-one error because the documentation says:
"This buffer should be MAX_PATH characters to accommodate the path plus the
terminating null character."
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991(v=vs.85).aspx
Since the function returns -errno the assert could be turned into:
/* GetTempFileName requires that its output buffer (4th param)
have length MAX_PATH + 1 or greater. */
if (size < MAX_PATH + 1) {
return -ENOSPC;
}
Stefan
Re: [Qemu-devel] [PATCH v3] DSDT: Fix HPET _CRS Method
On Mon, Nov 19, 2012 at 11:22:48AM +0100, Alexander Graf wrote: > > On 16.11.2012, at 19:46, Kevin O'Connor wrote: > > > On Fri, Nov 16, 2012 at 01:02:18PM -0500, Gabriel L. Somlo wrote: > >> ping > >> > >> On Thu, Nov 08, 2012 at 12:35:17PM -0500, Gabriel L. Somlo wrote: > >>> Updated _CRS method for HPET, bringing it in line with the way it is > >>> presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, etc); > >>> Allows it to be detected and utilized from Mac OS X; Also tested OK on > >>> Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). > >>> > >>> Signed-off-by: Gabriel Somlo > > > > I'm okay with the patch. I'm looking to see an Ack from one of the > > kvm/qemu developers. (I saw Gerd was okay with the last version of > > the patch.) > > IIRC Marcelo was the one changing the DSDT code from what this patch produces > to what we have today. My initial HPET DSDT entry was also copied from real > hardware. > > Marcelo, any memory on this? :) Keep in mind I might be misremembering - > maybe it was someone else after all ;). > I think you are misremembering. Git shows that HPET entry was taken from pcbios code and my old pcbios git tree says that the dsdt code was contributed by Beth Kon and it is the same as we have it now in SeaBIOS. The patch looks OK. -- Gleb.
Re: [Qemu-devel] [Bug 1080086] Re: MC146818 RTC breaks when SET bit in Register B is on.
> [...] the patch is almost good for inclusion. I'd ask for two changes: > 1) please test == 0, not != REG_B_SET; > 2) please leave the fuzzicsng test last I have attached a new patch with the requested changes. This patch also improves the quality of the functional test by checking that RTC_SECONDS is equal (==) to the previously written data provided the SET flag in Register B is still enabled. This is justified by the data sheet which states that an enabled SET bit "stops an existing update" and prevents "a new one from occurring" [1, p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS check uses an inequality (>=) as in the original test case. Out of curiosity, does anyone know how long this particular bug has been undetected or how/when it was introduced? This could help me explain to others my research interest in symbolic execution of hardware models and its application in form of automated test generation. Finally, if there is interest to improve the robustness of the RTC model, I could send a patch with several verification conditions (i.e. assertions) which can help to expose these kind of bugs in the RTC hardware model. Recall that most compiler can usually optimize these assertions away unless a developer explicitly enables them. They also serve as unambiguous code documentation. With best regards, Alex [1] http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf On 18 November 2012 08:52, Paolo Bonzini wrote: > Il 17/11/2012 19:47, Alex Horn ha scritto: >> I have attached a patch for the most recent version of the file >> hw/mc146818rtc.c [1]. The patch also features a functional test which >> executes through the QTest framework. >> >> I would appreciate your thoughts on this. >> >> [1] >> http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563 >> >> ** Patch added: "register_b_set_flag.patch" >> >> https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch >> > > Hi Alex, the patch is almost good for inclusion. I'd ask for two > changes: 1) please test == 0, not != REG_B_SET; 2) please leave the > fuzzing test last, because it may leave some registers in an undefined > state. > > Paolo register_b_set_flag_v2.patch Description: Binary data
Re: [Qemu-devel] [PATCH v3] DSDT: Fix HPET _CRS Method
On 19.11.2012, at 12:33, Gleb Natapov wrote: > On Mon, Nov 19, 2012 at 11:22:48AM +0100, Alexander Graf wrote: >> >> On 16.11.2012, at 19:46, Kevin O'Connor wrote: >> >>> On Fri, Nov 16, 2012 at 01:02:18PM -0500, Gabriel L. Somlo wrote: ping On Thu, Nov 08, 2012 at 12:35:17PM -0500, Gabriel L. Somlo wrote: > Updated _CRS method for HPET, bringing it in line with the way it is > presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, etc); > Allows it to be detected and utilized from Mac OS X; Also tested OK on > Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). > > Signed-off-by: Gabriel Somlo >>> >>> I'm okay with the patch. I'm looking to see an Ack from one of the >>> kvm/qemu developers. (I saw Gerd was okay with the last version of >>> the patch.) >> >> IIRC Marcelo was the one changing the DSDT code from what this patch >> produces to what we have today. My initial HPET DSDT entry was also copied >> from real hardware. >> >> Marcelo, any memory on this? :) Keep in mind I might be misremembering - >> maybe it was someone else after all ;). >> > I think you are misremembering. Git shows that HPET entry was taken from > pcbios code and my old pcbios git tree says that the dsdt code was > contributed by Beth Kon and it is the same as we have it now in SeaBIOS. Hrm. I'm 100% sure that from my code (which Beth based on) to the code that we have, someone had completely rewritten the DSDT entry. Either way, not complaining as long as we get it sorted out eventually :). > The patch looks OK. Mind to make this a formal acked-by? :) Alex
Re: [Qemu-devel] [PATCH] virtio-blk: Remove duplicate property definition
On Thu, Nov 15, 2012 at 01:12:14PM +1100, David Gibson wrote: > For the virtio-blk device (via virtio-pci) the property "config-wce" is > defined in two places. First, it's defined from the > DEFINE_VIRTIO_BLK_FEATURES macro, second it's defined directly in > virtio-pci, just two lines above the call to that macro. > > The direct definition in virtio-pci.c is broken, since it operates on the > 'config_wce' field of VirtIOBlkConf, which is never used anywhere else. > Therefore, this patch removes both the extra property definition and the > redundant field it works on. > > Cc: Kevin Wolf > Cc: Anthony Liguori > Cc: Paul 'Rusty' Russell > > Signed-off-by: David Gibson > --- > hw/virtio-blk.h |1 - > hw/virtio-pci.c |1 - > 2 files changed, 2 deletions(-) Thanks, applied to the block-next tree: https://github.com/stefanha/qemu/commits/block-next Stefan
Re: [Qemu-devel] [PATCH v2 000/147] target-s390 reorg
Hey Richard, On 16.11.2012, at 01:09, Richard Henderson wrote: > Ping. > > I've updated the branch at > > git://repo.or.cz/qemu/rth.git s390-reorg > > to rebase vs mainline (ce34cf72fe508b27a78f83c184142e8d1e6a048a). > There are minor changes due to Aurel's TCG_CALL_NO_* rewrite, but > is otherwise unchanged. > > I can re-post the 140+ patches if required... I'd like to leave the series out for 1.3, but get it in early in the 1.4 development cycle, so that we can have actual code exposure during the development cycle :). Fundamentally, I don't object to your changes. I find the new code very hard to read, but considering that after this rewrite you authored 99% of the code base, I'd basically just declare you the maintainer for the s390 tcg target and then you have to worry about that bit yourself ;). Alex > > > r~ > > On 2012-09-27 15:39, Richard Henderson wrote: >> Tons of changes since v1. I believe I incorproated all of the feedback >> that I received. The patch set is relative to the "TCGCond" patch set >> that I sent out earlier this week. Both trees are available at >> >> git://repo.or.cz/qemu/rth.git tcg-cond >> git://repo.or.cz/qemu/rth.git s390-reorg >> >> This passes the gcc testsuite in userland with no unexpected failures >> (considering anything that touches threads to be "expected"). It boots >> a debian system image as well as (or as poorly as) mainline -- agraf >> and I had a rather long session re those failures on IRC the other day. >> >> Note that patches 2-11 are bug fixes for the *existing* code base. I >> found that I had to fix those in order to be able to properly bisect >> problems in the later patches. >> >> The last 7 patches are new, and improve the generated code for a >> variety of stuff I noticed while staring at dumps. Not that the >> last 25 patches or so made it to the list last time... >> >> >> r~ >> >> >> Alexander Graf (1): >> s390x: fix -initrd in virtio machine >> >> Richard Henderson (146): >> tcg: Add TCGV_IS_UNUSED_* >> target-s390: Disassemble more z10 and z196 opcodes >> target-s390: Fix disassembly of cpsdr >> target-s390: Fix gdbstub >> target-s390: Add missing temp_free in gen_op_calc_cc >> target-s390: Use TCG registers for FPR >> target-s390: Register helpers >> target-s390: Fix SACF exit >> target-s390: Fix BCR >> target-s390: Tidy unconditional BRCL >> target-s390: Fix PSW_MASK handling >> target-s390: Add format based disassassmbly infrastructure >> target-s390: Split out disas_jcc >> target-s390: Reorg exception handling >> target-s390: Convert ADD HALFWORD >> target-s390: Implement SUBTRACT HALFWORD >> target-s390: Implement ADD LOGICAL WITH SIGNED IMMEDIATE >> target-s390: Convert MULTIPLY HALFWORD, SINGLE >> target-s390: Convert 32-bit MULTIPLY, MULTIPLY LOGICAL >> target-s390: Convert 64-bit MULTIPLY LOGICAL >> target-s390: Convert AND, OR, XOR >> target-s390: Convert COMPARE, COMPARE LOGICAL >> target-s390: Convert LOAD, LOAD LOGICAL >> target-s390: Convert LOAD ADDRESS >> target-s390: Convert LOAD (LOGICAL) BYTE, CHARACTER, HALFWORD >> target-s390: Convert LOAD AND TEST >> target-s390: Convert LOAD LOGICAL IMMEDIATE >> target-s390: Convert LOAD COMPLIMENT, POSITIVE, NEGATIVE >> target-s390: Convert AND, OR, XOR, INSERT IMMEDIATE >> target-s390: Convert STORE >> target-s390: Convert ADD LOGICAL CARRY and SUBTRACT LOGICAL BORROW >> target-s390: Convert BRANCH AND SAVE >> target-s390: Convert BRANCH ON CONDITION >> target-s390: Convert BRANCH ON COUNT >> target-s390: Convert DIVIDE >> target-s390: Send signals for divide >> target-s390: Convert TEST UNDER MASK >> target-s390: Convert SET ADDRESSING MODE >> target-s390: Convert SUPERVISOR CALL >> target-s390: Convert MOVE LONG >> target-s390: Convert FP LOAD >> target-s390: Convert INSERT CHARACTER >> target-s390: Cleanup cc computation helpers >> target-s390: Convert INSERT CHARACTERS UNDER MASK >> target-s390: Convert EXECUTE >> target-s390: Convert FP STORE >> target-s390: Convert CONVERT TO DECIMAL >> target-s390: Convert SET SYSTEM MASK >> target-s390: Convert LOAD PSW >> target-s390: Convert DIAGNOSE >> target-s390: Convert SHIFT, ROTATE SINGLE >> target-s390: Convert SHIFT DOUBLE >> target-s390: Convert LOAD, STORE MULTIPLE >> target-s390: Convert MOVE >> target-s390: Convert NI, XI, OI >> target-s390: Convert STNSM, STOSM >> target-s390: Convert LAM, STAM >> target-s390: Convert CLCLE, MVCLE >> target-s390: Convert MVC >> target-s390: Convert NC, XC, OC, TR, UNPK >> target-s390: Convert CLC >> target-s390: Convert MVCP, MVCS >> target-s390: Convert LRA >> target-s390: Convert SIGP >> target-s390: Convert EFPC, STFPC >> target-s390: Convert LCTL, STCTL >> target-s390: Convert COMPARE AND SWAP >> target-s390: Convert CLM >> target-s390: Convert STCM >> target-s390: Convert TPROT >> target-s390: Convert LOAD CONTROL, part 2 >> target-s390: Convert LOAD REVERSED >> target-s390: Convert S
Re: [Qemu-devel] [PATCH] block: vpc initialize the uuid footer field
On Fri, Nov 02, 2012 at 09:54:24AM -0600, Charles Arnold wrote: > block/vpc: Initialize the uuid field in the footer with a generated uuid. > > Signed-off-by: Charles Arnold Thanks, applied to the block-next tree: https://github.com/stefanha/qemu/commits/block-next Stefan
Re: [Qemu-devel] [Bug 1080086] Re: MC146818 RTC breaks when SET bit in Register B is on.
Il 19/11/2012 12:34, Alex Horn ha scritto: >> [...] the patch is almost good for inclusion. I'd ask for two changes: >> 1) please test == 0, not != REG_B_SET; >> 2) please leave the fuzzicsng test last > > I have attached a new patch with the requested changes. > > This patch also improves the quality of the functional test by > checking that RTC_SECONDS is equal (==) to the previously written data > provided the SET flag in Register B is still enabled. This is > justified by the data sheet which states that an enabled SET bit > "stops an existing update" and prevents "a new one from occurring" [1, > p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS > check uses an inequality (>=) as in the original test case. Right. > Out of curiosity, does anyone know how long this particular bug has > been undetected or how/when it was introduced? Probably it was introduced last September when the model was rewritten. But it's really unlikely that the bug would have been detected. On the other hand, the bug in commit b6db4ac (which also includes a qtest) was detected by autotest. Could your tool find it, too? > This could help me explain to others my research interest in symbolic > execution of hardware models and its application in form of automated > test generation. Very interesting (at least to me :)). > Finally, if there is interest to improve the robustness of the RTC > model, I could send a patch with several verification conditions (i.e. > assertions) which can help to expose these kind of bugs in the RTC > hardware model. Sure, that's welcome. In particular, I assume you verified the "next alarm" code to be correct? :) Paolo > Recall that most compiler can usually optimize these > assertions away unless a developer explicitly enables them. They also > serve as unambiguous code documentation. > > With best regards, > Alex > > [1] > http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf > > On 18 November 2012 08:52, Paolo Bonzini wrote: >> Il 17/11/2012 19:47, Alex Horn ha scritto: >>> I have attached a patch for the most recent version of the file >>> hw/mc146818rtc.c [1]. The patch also features a functional test which >>> executes through the QTest framework. >>> >>> I would appreciate your thoughts on this. >>> >>> [1] >>> http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563 >>> >>> ** Patch added: "register_b_set_flag.patch" >>> >>> https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch >>> >> >> Hi Alex, the patch is almost good for inclusion. I'd ask for two >> changes: 1) please test == 0, not != REG_B_SET; 2) please leave the >> fuzzing test last, because it may leave some registers in an undefined >> state. >> >> Paolo
Re: [Qemu-devel] [Bug 1080086] Re: MC146818 RTC breaks when SET bit in Register B is on.
Il 19/11/2012 12:34, Alex Horn ha scritto: > I have attached a new patch with the requested changes. Could you please resend it using "git send-email", so that it has a commit message and a "Signed-off-by: Alex Horn <...@...>" line? Thanks! Paolo
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Am 19.11.2012 12:16, schrieb Paolo Bonzini: Il 19/11/2012 11:57, Stefan Priebe - Profihost AG ha scritto: Yeah thats my old thread regarding iscsi und unmap but this works fine now since you patched qemu. It still causes hangs no? Though it works apart from that. iscsi/libiscsi and discards works fine since your latest patches: 1bd075f29ea6d11853475c7c42734595720c3ac6 cfb3f5064af2d2e29c976e292c9472dfe9d61e31 27cbd828c617944c0f9603763fdf4fa87e7ad923 b20909195745c34a819aed14ae996b60ab0f591f But in rbd it starts to cancel the discard requests. Both using the same guest and host kernel with the same QEMU version. Greets, Stefan
Re: [Qemu-devel] [PATCH] block: vpc support for ~2 TB disks
On Tue, Oct 30, 2012 at 08:59:32PM -0600, Charles Arnold wrote: > The VHD specification allows for up to a 2 TB disk size. The current > implementation in qemu emulates EIDE and ATA-2 hardware which only allows > for up to 127 GB. This disk size limitation can be overridden by allowing > up to 255 heads instead of the normal 4 bit limitation of 16. Doing so > allows disk images to be created of up to nearly 2 TB. This change does > not violate the VHD format specification nor does it change how smaller > disks (ie, <=127GB) are defined. > > Signed-off-by: Charles Arnold Thanks, applied to my block-next tree: https://github.com/stefanha/qemu/commits/block-next Stefan
Re: [Qemu-devel] [PATCH v3] DSDT: Fix HPET _CRS Method
On Mon, Nov 19, 2012 at 12:35:47PM +0100, Alexander Graf wrote: > > On 19.11.2012, at 12:33, Gleb Natapov wrote: > > > On Mon, Nov 19, 2012 at 11:22:48AM +0100, Alexander Graf wrote: > >> > >> On 16.11.2012, at 19:46, Kevin O'Connor wrote: > >> > >>> On Fri, Nov 16, 2012 at 01:02:18PM -0500, Gabriel L. Somlo wrote: > ping > > On Thu, Nov 08, 2012 at 12:35:17PM -0500, Gabriel L. Somlo wrote: > > Updated _CRS method for HPET, bringing it in line with the way it is > > presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, etc); > > Allows it to be detected and utilized from Mac OS X; Also tested OK on > > Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). > > > > Signed-off-by: Gabriel Somlo > >>> > >>> I'm okay with the patch. I'm looking to see an Ack from one of the > >>> kvm/qemu developers. (I saw Gerd was okay with the last version of > >>> the patch.) > >> > >> IIRC Marcelo was the one changing the DSDT code from what this patch > >> produces to what we have today. My initial HPET DSDT entry was also copied > >> from real hardware. > >> > >> Marcelo, any memory on this? :) Keep in mind I might be misremembering - > >> maybe it was someone else after all ;). > >> > > I think you are misremembering. Git shows that HPET entry was taken from > > pcbios code and my old pcbios git tree says that the dsdt code was > > contributed by Beth Kon and it is the same as we have it now in SeaBIOS. > > Hrm. I'm 100% sure that from my code (which Beth based on) to the code that > we have, someone had completely rewritten the DSDT entry. Either way, not > complaining as long as we get it sorted out eventually :). > Here is Beth's commit in bochs :) http://0x0badc0.de/gitweb?p=bochs/.git;a=commitdiff;h=874040e817e49811c30405d7c5d14b4c42161ca1;hp=1d2bac352688c75e8fdf8010f012b8ec85ba68d1 I added _STA logic in SeaBIOS but otherwise the code is the same. > > The patch looks OK. > > Mind to make this a formal acked-by? :) > Sure, will do. -- Gleb.
Re: [Qemu-devel] [PATCH] raw-posix: inline paio_ioctl into hdev_aio_ioctl
On Fri, Nov 02, 2012 at 04:14:20PM +0100, Paolo Bonzini wrote: > clang now warns about an unused function: > CCblock/raw-posix.o > block/raw-posix.c:707:26: warning: unused function paio_ioctl > [-Wunused-function] > static BlockDriverAIOCB *paio_ioctl(BlockDriverState *bs, int fd, > ^ > 1 warning generated. > > because the only use of paio_ioctl() is inside a #if defined(__linux__) > guard and it is static now. > > Reported-by: Peter Maydell > Signed-off-by: Paolo Bonzini > --- > block/raw-posix.c | 27 ++- > 1 file modificato, 10 inserzioni(+), 17 rimozioni(-) Thanks, applied to my block-next tree: https://github.com/stefanha/qemu/commits/block-next Stefan
Re: [Qemu-devel] [PATCH v3] DSDT: Fix HPET _CRS Method
On 19.11.2012, at 12:51, Gleb Natapov wrote: > On Mon, Nov 19, 2012 at 12:35:47PM +0100, Alexander Graf wrote: >> >> On 19.11.2012, at 12:33, Gleb Natapov wrote: >> >>> On Mon, Nov 19, 2012 at 11:22:48AM +0100, Alexander Graf wrote: On 16.11.2012, at 19:46, Kevin O'Connor wrote: > On Fri, Nov 16, 2012 at 01:02:18PM -0500, Gabriel L. Somlo wrote: >> ping >> >> On Thu, Nov 08, 2012 at 12:35:17PM -0500, Gabriel L. Somlo wrote: >>> Updated _CRS method for HPET, bringing it in line with the way it is >>> presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, etc); >>> Allows it to be detected and utilized from Mac OS X; Also tested OK on >>> Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). >>> >>> Signed-off-by: Gabriel Somlo > > I'm okay with the patch. I'm looking to see an Ack from one of the > kvm/qemu developers. (I saw Gerd was okay with the last version of > the patch.) IIRC Marcelo was the one changing the DSDT code from what this patch produces to what we have today. My initial HPET DSDT entry was also copied from real hardware. Marcelo, any memory on this? :) Keep in mind I might be misremembering - maybe it was someone else after all ;). >>> I think you are misremembering. Git shows that HPET entry was taken from >>> pcbios code and my old pcbios git tree says that the dsdt code was >>> contributed by Beth Kon and it is the same as we have it now in SeaBIOS. >> >> Hrm. I'm 100% sure that from my code (which Beth based on) to the code that >> we have, someone had completely rewritten the DSDT entry. Either way, not >> complaining as long as we get it sorted out eventually :). >> > Here is Beth's commit in bochs :) > http://0x0badc0.de/gitweb?p=bochs/.git;a=commitdiff;h=874040e817e49811c30405d7c5d14b4c42161ca1;hp=1d2bac352688c75e8fdf8010f012b8ec85ba68d1 Ah, apparently Beth's DSDT bits were a rewrite done by Ryan. My original version looked like this: http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00180.html but obviously broke quite a few things along the way ;). Also, I do remember that I extracted the HPET bits from there and submitted them individually, but I might really just be misremembering and it's not like that makes any difference. > > I added _STA logic in SeaBIOS but otherwise the code is the same. > >>> The patch looks OK. >> >> Mind to make this a formal acked-by? :) >> > Sure, will do. Just reply with the line ;) Alex
Re: [Qemu-devel] buildbot failure in qemu on rhel5-default
On 15.11.2012, at 12:28, Peter Maydell wrote: > On 15 November 2012 08:22, Gerd Hoffmann wrote: >> CCs390x-softmmu/hw/s390x/event-facility.o >> cc1: warnings being treated as errors >> /home/buildbot/slave-spunk/rhel5-default/build/hw/s390x/event-facility.c: In >> function ‘command_handler’: >> /home/buildbot/slave-spunk/rhel5-default/build/hw/s390x/event-facility.c:110: >> warning: ‘rc’ may be used uninitialized in this function >> make[1]: *** [hw/s390x/event-facility.o] Error 1 >> make: *** [subdir-s390x-softmmu] Error 2 > > handle_write_event_buf() doesn't consider the case of the qbus.children > list being empty, in which case it will return an uninitialized value. > Introduced in commit 559a17a14. Heinz, ping? Alex
Re: [Qemu-devel] [PATCH v3] DSDT: Fix HPET _CRS Method
On Mon, Nov 19, 2012 at 01:00:56PM +0100, Alexander Graf wrote: > > On 19.11.2012, at 12:51, Gleb Natapov wrote: > > > On Mon, Nov 19, 2012 at 12:35:47PM +0100, Alexander Graf wrote: > >> > >> On 19.11.2012, at 12:33, Gleb Natapov wrote: > >> > >>> On Mon, Nov 19, 2012 at 11:22:48AM +0100, Alexander Graf wrote: > > On 16.11.2012, at 19:46, Kevin O'Connor wrote: > > > On Fri, Nov 16, 2012 at 01:02:18PM -0500, Gabriel L. Somlo wrote: > >> ping > >> > >> On Thu, Nov 08, 2012 at 12:35:17PM -0500, Gabriel L. Somlo wrote: > >>> Updated _CRS method for HPET, bringing it in line with the way it is > >>> presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, > >>> etc); > >>> Allows it to be detected and utilized from Mac OS X; Also tested OK on > >>> Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). > >>> > >>> Signed-off-by: Gabriel Somlo > > > > I'm okay with the patch. I'm looking to see an Ack from one of the > > kvm/qemu developers. (I saw Gerd was okay with the last version of > > the patch.) > > IIRC Marcelo was the one changing the DSDT code from what this patch > produces to what we have today. My initial HPET DSDT entry was also > copied from real hardware. > > Marcelo, any memory on this? :) Keep in mind I might be misremembering - > maybe it was someone else after all ;). > > >>> I think you are misremembering. Git shows that HPET entry was taken from > >>> pcbios code and my old pcbios git tree says that the dsdt code was > >>> contributed by Beth Kon and it is the same as we have it now in SeaBIOS. > >> > >> Hrm. I'm 100% sure that from my code (which Beth based on) to the code > >> that we have, someone had completely rewritten the DSDT entry. Either way, > >> not complaining as long as we get it sorted out eventually :). > >> > > Here is Beth's commit in bochs :) > > http://0x0badc0.de/gitweb?p=bochs/.git;a=commitdiff;h=874040e817e49811c30405d7c5d14b4c42161ca1;hp=1d2bac352688c75e8fdf8010f012b8ec85ba68d1 > > Ah, apparently Beth's DSDT bits were a rewrite done by Ryan. My original > version looked like this: > > http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00180.html > > but obviously broke quite a few things along the way ;). Also, I do remember > that I extracted the HPET bits from there and submitted them individually, > but I might really just be misremembering and it's not like that makes any > difference. > Just wanted to make sure that we do not revert someone's change without understanding why it was done in the first place. > > > > I added _STA logic in SeaBIOS but otherwise the code is the same. > > > >>> The patch looks OK. > >> > >> Mind to make this a formal acked-by? :) > >> > > Sure, will do. > > Just reply with the line ;) > Did it in a most formal way by answering to the patch itself :) -- Gleb.
[Qemu-devel] [Bug 1080086] Re: MC146818 RTC breaks when SET bit in Register B is on.
Cross reference: https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg01759.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1080086 Title: MC146818 RTC breaks when SET bit in Register B is on. Status in QEMU: New Bug description: This bug occurs when the SET flag of Register B is enabled. When an RTC data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set, the data is (as expected) correctly stored in the cmos_data array. However, since the SET flag is enabled, the function rtc_set_time is not invoked. As a result, the field base_rtc in RTCState remains uninitialized. This appears to cause a problem on subsequent writes which can end up overwriting data. To see this, consider writing data to Register A after having written data to any of the RTC data registers; the following figure illustrates the call stack for the Register A write operation: +- cmos_io_port_write +-- check_update_timer + get_next_alarm +-- rtc_update_time In rtc_update_time, get_guest_rtc calculates the wrong time and overwrites the previously written RTC data register values. I have created a standalone test case which exposes this bug: https://github.com/ahorn/benchmarks/commit/fff1ca40694bbef6f7f9de323bb0bed63419ef99 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1080086/+subscriptions
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 12:49, Stefan Priebe - Profihost AG ha scritto: >> >> It still causes hangs no? Though it works apart from that. > > iscsi/libiscsi and discards works fine since your latest patches: > 1bd075f29ea6d11853475c7c42734595720c3ac6 > cfb3f5064af2d2e29c976e292c9472dfe9d61e31 > 27cbd828c617944c0f9603763fdf4fa87e7ad923 > b20909195745c34a819aed14ae996b60ab0f591f Does the console still hang though? > But in rbd it starts to cancel the discard requests. Both using the same > guest and host kernel with the same QEMU version. rbd's cancellation is broken like libiscsi's was. So the cancellation succeeds apparently, but it is subject to the same race introduced in commit 64e69e8 (iscsi: Fix NULL dereferences / races between task completion and abort, 2012-08-15) for libiscsi. It risks corruption in case the following happens: guest qemu rbd server = send write 1 > send write 1 --> cancel write 1 --> cancel write 1 > <-- cancelled send write 2 > send write 2 --> <--- completed write 2 <-- completed write 2 <--- completed write 1 Here, the guest would see write 2 superseding write 1, when in fact the outcome could have been the opposite. The right behavior is to return only after the target says whether the cancellation was done or not. For libiscsi, it was implemented by the commits you mention. Paolo
[Qemu-devel] KVM call agenda for 2012-11-20
Hi Please send in any agenda topics you are interested in. Later, Juan.
[Qemu-devel] [Bug 1080086] Re: MC146818 RTC breaks when SET bit in Register B is on.
** Attachment added: "register_b_set_flag_v2.patch" https://bugs.launchpad.net/bugs/1080086/+attachment/3438594/+files/register_b_set_flag_v2.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1080086 Title: MC146818 RTC breaks when SET bit in Register B is on. Status in QEMU: New Bug description: This bug occurs when the SET flag of Register B is enabled. When an RTC data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set, the data is (as expected) correctly stored in the cmos_data array. However, since the SET flag is enabled, the function rtc_set_time is not invoked. As a result, the field base_rtc in RTCState remains uninitialized. This appears to cause a problem on subsequent writes which can end up overwriting data. To see this, consider writing data to Register A after having written data to any of the RTC data registers; the following figure illustrates the call stack for the Register A write operation: +- cmos_io_port_write +-- check_update_timer + get_next_alarm +-- rtc_update_time In rtc_update_time, get_guest_rtc calculates the wrong time and overwrites the previously written RTC data register values. I have created a standalone test case which exposes this bug: https://github.com/ahorn/benchmarks/commit/fff1ca40694bbef6f7f9de323bb0bed63419ef99 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1080086/+subscriptions
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Am 19.11.2012 13:24, schrieb Paolo Bonzini: Il 19/11/2012 12:49, Stefan Priebe - Profihost AG ha scritto: It still causes hangs no? Though it works apart from that. iscsi/libiscsi and discards works fine since your latest patches: 1bd075f29ea6d11853475c7c42734595720c3ac6 cfb3f5064af2d2e29c976e292c9472dfe9d61e31 27cbd828c617944c0f9603763fdf4fa87e7ad923 b20909195745c34a819aed14ae996b60ab0f591f Does the console still hang though? No everything is absolutely fine. But in rbd it starts to cancel the discard requests. Both using the same guest and host kernel with the same QEMU version. rbd's cancellation is broken like libiscsi's was. So the cancellation succeeds apparently, but it is subject to the same race introduced in commit 64e69e8 (iscsi: Fix NULL dereferences / races between task completion and abort, 2012-08-15) for libiscsi. It risks corruption in case the following happens: guest qemu rbd server = send write 1 > send write 1 --> cancel write 1 --> cancel write 1 > <-- cancelled send write 2 > send write 2 --> <--- completed write 2 <-- completed write 2 <--- completed write 1 Here, the guest would see write 2 superseding write 1, when in fact the outcome could have been the opposite. The right behavior is to return only after the target says whether the cancellation was done or not. For libiscsi, it was implemented by the commits you mention. So the whole bunch of changes is needed for rbd? Or just 64e69e8? Or all mentioned except 64e69e8 as 64e69e8 introduced the problem? Stefan
[Qemu-devel] [PATCH] m25p80: Fix wrong jedec id for Numonyx n25q128
The jedec id of "n25q128" should be 0x20bb18, not 0x20ba18.
Signed-off-by: Liming Wang
---
hw/m25p80.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/m25p80.c b/hw/m25p80.c
index 3895e73..58ae754 100644
--- a/hw/m25p80.c
+++ b/hw/m25p80.c
@@ -177,7 +177,7 @@ static const FlashPartInfo known_devices[] = {
{ INFO("w25q64", 0xef4017, 0, 64 << 10, 128, ER_4K) },
/* Numonyx -- n25q128 */
-{ INFO("n25q128", 0x20ba18, 0, 64 << 10, 256, 0) },
+{ INFO("n25q128", 0x20bb18, 0, 64 << 10, 256, 0) },
{ },
};
--
1.7.9.5
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 14:01, Stefan Priebe - Profihost AG ha scritto: >> The right behavior is to return >> only after the target says whether the cancellation was done or not. >> For libiscsi, it was implemented by the commits you mention. > > So the whole bunch of changes is needed for rbd? Something like the first three: 1bd075f29ea6d11853475c7c42734595720c3ac6 cfb3f5064af2d2e29c976e292c9472dfe9d61e31 27cbd828c617944c0f9603763fdf4fa87e7ad923 Paolo
Re: [Qemu-devel] [PATCH 06/24] Remove local ram_size that hides global one
On 13.11.2012, at 13:11, Christian Borntraeger wrote:
> From: Heinz Graalfs
>
> The global variable 'ram_size' is hidden by the local variable
> declaration in s390_init()
That's the point of Eduardo's patch, no? Or do we need access to the global to
change its value afterwards? If so, please write a reasonable patch description
that actually explains the problem.
Alex
>
> Signed-off-by: Heinz Graalfs
> Signed-off-by: Christian Borntraeger
> ---
> hw/s390-virtio.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> index ebec844..78477af 100644
> --- a/hw/s390-virtio.c
> +++ b/hw/s390-virtio.c
> @@ -155,7 +155,6 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
> static void s390_init(QEMUMachineInitArgs *args)
> {
> ram_addr_t my_ram_size = args->ram_size;
> -ram_addr_t ram_size = args->ram_size;
> const char *cpu_model = args->cpu_model;
> const char *kernel_filename = args->kernel_filename;
> const char *kernel_cmdline = args->kernel_cmdline;
> --
> 1.7.10.1
>
Re: [Qemu-devel] [PATCH 06/24] Remove local ram_size that hides global one
On 19 November 2012 13:14, Alexander Graf wrote: > > On 13.11.2012, at 13:11, Christian Borntraeger wrote: > >> From: Heinz Graalfs >> >> The global variable 'ram_size' is hidden by the local variable >> declaration in s390_init() > > That's the point of Eduardo's patch, no? Or do we need access > to the global to change its value afterwards? The function later does: /* lets propagate the changed ram size into the global variable. */ ram_size = my_ram_size; which frankly I think is pretty nasty but then we've never had a very good mechanism for specifying board-specific restrictions around the memory size. -- PMM
[Qemu-devel] no monitor after disable vnc
Dear All When i compile qemu in ubuntu 12.10 with "./configure --target-list=i386-softmmu --prefix=/root/qemu --enable-debug --disable-vnc --disable-werror" , after i start qemu, no screen output, how to enable it? Thanksfrom Peter
Re: [Qemu-devel] [PATCH 2/3] s390: Virtual channel subsystem support.
On 31.10.2012, at 17:24, Cornelia Huck wrote:
> Provide a mechanism for qemu to provide fully virtual subchannels to
> the guest. In the KVM case, this relies on the kernel's css support
> for I/O and machine check interrupt handling. The !KVM case handles
> interrupts on its own.
>
> Signed-off-by: Cornelia Huck
> ---
> hw/s390x/Makefile.objs |1 +
> hw/s390x/css.c | 1209
> hw/s390x/css.h | 90
> target-s390x/Makefile.objs |2 +-
> target-s390x/cpu.h | 232 +
> target-s390x/helper.c | 146 ++
> target-s390x/ioinst.c | 737 +++
> target-s390x/ioinst.h | 213
> target-s390x/kvm.c | 251 -
> target-s390x/misc_helper.c |6 +-
> 10 files changed, 2872 insertions(+), 15 deletions(-)
> create mode 100644 hw/s390x/css.c
> create mode 100644 hw/s390x/css.h
> create mode 100644 target-s390x/ioinst.c
> create mode 100644 target-s390x/ioinst.h
>
> diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
> index 096dfcd..378b099 100644
> --- a/hw/s390x/Makefile.objs
> +++ b/hw/s390x/Makefile.objs
> @@ -4,3 +4,4 @@ obj-y := $(addprefix ../,$(obj-y))
> obj-y += sclp.o
> obj-y += event-facility.o
> obj-y += sclpquiesce.o sclpconsole.o
> +obj-y += css.o
> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> new file mode 100644
> index 000..9adffb3
> --- /dev/null
> +++ b/hw/s390x/css.c
> @@ -0,0 +1,1209 @@
> +/*
> + * Channel subsystem base support.
> + *
> + * Copyright 2012 IBM Corp.
> + * Author(s): Cornelia Huck
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or (at
> + * your option) any later version. See the COPYING file in the top-level
> + * directory.
> + */
> +
> +#include "qemu-thread.h"
> +#include "qemu-queue.h"
> +#include
> +#include "bitops.h"
> +#include "kvm.h"
> +#include "cpu.h"
> +#include "ioinst.h"
> +#include "css.h"
> +#include "virtio-ccw.h"
> +
> +typedef struct CrwContainer {
> +CRW crw;
> +QTAILQ_ENTRY(CrwContainer) sibling;
> +} CrwContainer;
> +
> +typedef struct ChpInfo {
> +uint8_t in_use;
> +uint8_t type;
> +uint8_t is_virtual;
> +} ChpInfo;
> +
> +typedef struct SubchSet {
> +SubchDev *sch[MAX_SCHID + 1];
> +unsigned long schids_used[BITS_TO_LONGS(MAX_SCHID + 1)];
> +unsigned long devnos_used[BITS_TO_LONGS(MAX_SCHID + 1)];
> +} SubchSet;
> +
> +typedef struct CssImage {
> +SubchSet *sch_set[MAX_SSID + 1];
> +ChpInfo chpids[MAX_CHPID + 1];
> +} CssImage;
> +
> +typedef struct ChannelSubSys {
> +QTAILQ_HEAD(, CrwContainer) pending_crws;
> +bool do_crw_mchk;
> +bool crws_lost;
> +uint8_t max_cssid;
> +uint8_t max_ssid;
> +bool chnmon_active;
> +uint64_t chnmon_area;
> +CssImage *css[MAX_CSSID + 1];
> +uint8_t default_cssid;
> +} ChannelSubSys;
> +
> +static ChannelSubSys *channel_subsys;
> +
> +int css_create_css_image(uint8_t cssid, bool default_image)
> +{
> +if (cssid > MAX_CSSID) {
> +return -EINVAL;
> +}
> +if (channel_subsys->css[cssid]) {
> +return -EBUSY;
> +}
> +channel_subsys->css[cssid] = g_try_malloc0(sizeof(CssImage));
> +if (!channel_subsys->css[cssid]) {
> +return -ENOMEM;
> +}
> +if (default_image) {
> +channel_subsys->default_cssid = cssid;
> +}
> +return 0;
> +}
> +
> +static void css_write_phys_pmcw(uint64_t addr, PMCW *pmcw)
> +{
> +int i;
> +uint32_t offset = 0;
> +struct copy_pmcw {
> +uint32_t intparm;
> +uint16_t flags;
> +uint16_t devno;
> +uint8_t lpm;
> +uint8_t pnom;
> +uint8_t lpum;
> +uint8_t pim;
> +uint16_t mbi;
> +uint8_t pom;
> +uint8_t pam;
> +uint8_t chpid[8];
> +uint32_t chars;
> +} *copy;
This needs to be packed. Also, it might be a good idea to separate the struct
definition from the actual code ;).
> +
> +copy = (struct copy_pmcw *)pmcw;
This will break on any system that doesn't coincidently stick to the same
bitfield order as s390x. Please drop any usage of bitfields in QEMU source code
:).
> +stl_phys(addr + offset, copy->intparm);
> +offset += sizeof(copy->intparm);
Can't you just use cpu_physical_memory_map() and assign things left and right
as you see fit? Or prepare the target endianness struct on the stack and
cpu_physical_memory_read/write it from/to guest memory.
Also, please split this patch into smaller patches :). As it is now it's very
hard to review. However, apart from the above issues (which may happen in other
places of the code further down, I just didn't comment then) I couldn't see
major problems so far. But please split it nevertheless so that I have an
easier time reviewing it :)
Alex
Re: [Qemu-devel] [PATCH 06/24] Remove local ram_size that hides global one
On Mon, Nov 19, 2012 at 02:14:27PM +0100, Alexander Graf wrote:
>
> On 13.11.2012, at 13:11, Christian Borntraeger wrote:
>
> > From: Heinz Graalfs
> >
> > The global variable 'ram_size' is hidden by the local variable
> > declaration in s390_init()
>
> That's the point of Eduardo's patch, no? Or do we need access to the global
> to change its value afterwards? If so, please write a reasonable patch
> description that actually explains the problem.
>
Actually, I wanted to keep the existing behavior (whatever it was), and
use local variables to replace the old function parameters, and change
nothing else. Most machines used a local variable named 'ram_size', but
the parameter to s390_init() was named 'my_ram_size'.
So, considering that this at least restores the previous behavior:
Reviewed-by: Eduardo Habkost
>
> Alex
>
> >
> > Signed-off-by: Heinz Graalfs
> > Signed-off-by: Christian Borntraeger
> > ---
> > hw/s390-virtio.c |1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> > index ebec844..78477af 100644
> > --- a/hw/s390-virtio.c
> > +++ b/hw/s390-virtio.c
> > @@ -155,7 +155,6 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
> > static void s390_init(QEMUMachineInitArgs *args)
> > {
> > ram_addr_t my_ram_size = args->ram_size;
> > -ram_addr_t ram_size = args->ram_size;
> > const char *cpu_model = args->cpu_model;
> > const char *kernel_filename = args->kernel_filename;
> > const char *kernel_cmdline = args->kernel_cmdline;
> > --
> > 1.7.10.1
> >
>
--
Eduardo
Re: [Qemu-devel] [PATCH 1/1] Support default block interfaces per QEMUMachine
On 12.11.2012, at 09:22, Christian Borntraeger wrote:
> There are QEMUMachines that have neither IF_IDE nor IF_SCSI as a
> default/standard interface to their block devices / drives. Therfore,
> this patch introduces a new field default_block per QEMUMachine struct.
> The prior use_scsi field becomes thereby obsolete and is replaced through
> .default_block = DEFAULT_SCSI.
>
> Based on an initial patch from Einar Lueck
>
> Signed-off-by: Christian Borntraeger
> ---
> blockdev.c |4 ++--
> blockdev.h | 29 -
> hw/boards.h |3 ++-
> hw/device-hotplug.c |2 +-
> hw/highbank.c |2 +-
> hw/leon3.c |1 -
> hw/mips_jazz.c |4 ++--
> hw/pc_sysfw.c |2 +-
> hw/puv3.c |1 -
> hw/realview.c |7 ---
> hw/s390-virtio.c| 16 +---
> hw/spapr.c |2 +-
> hw/sun4m.c | 24
> hw/versatilepb.c|4 ++--
> hw/vexpress.c |4 ++--
> hw/xilinx_zynq.c|2 +-
> vl.c| 20 +++-
> 17 files changed, 71 insertions(+), 56 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index e73fd6e..aca3c14 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -275,7 +275,7 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
> return true;
> }
>
> -DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
> +DriveInfo *drive_init(QemuOpts *opts, BlockDefault block_default)
> {
> const char *buf;
> const char *file = NULL;
> @@ -325,7 +325,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
> return NULL;
> }
> } else {
> -type = default_to_scsi ? IF_SCSI : IF_IDE;
> +type = block_if_from_default(block_default);
> }
>
> max_devs = if_max_devs[type];
> diff --git a/blockdev.h b/blockdev.h
> index 5f27b64..aba6d77 100644
> --- a/blockdev.h
> +++ b/blockdev.h
> @@ -24,6 +24,33 @@ typedef enum {
> IF_COUNT
> } BlockInterfaceType;
>
> +/* For machine default interface. */
> +typedef enum {
> +DEFAULT_IDE = 0,
> +DEFAULT_SCSI,
> +DEFAULT_FLOPPY,
> +DEFAULT_PFLASH,
> +DEFAULT_MTD,
> +DEFAULT_SD,
> +DEFAULT_VIRTIO,
> +DEFAULT_XEN
> +} BlockDefault;
Why a new enum? Can't we just reuse the IF_ ones?
Also, traditionally Markus has had very strong opinions on anything IF_ and
-drive related. It's probably a good idea to get him in the loop :).
Alex
> +
> +static inline BlockInterfaceType block_if_from_default(BlockDefault d)
> +{
> +switch (d) {
> +case DEFAULT_IDE:return IF_IDE;
> +case DEFAULT_SCSI: return IF_SCSI;
> +case DEFAULT_FLOPPY: return IF_FLOPPY;
> +case DEFAULT_PFLASH: return IF_PFLASH;
> +case DEFAULT_MTD:return IF_MTD;
> +case DEFAULT_SD: return IF_SD;
> +case DEFAULT_VIRTIO: return IF_VIRTIO;
> +case DEFAULT_XEN:return IF_XEN;
> +default: return IF_COUNT; /* will cause errors */
> +}
> +}
> +
> struct DriveInfo {
> BlockDriverState *bdrv;
> char *id;
> @@ -51,7 +78,7 @@ DriveInfo *drive_get_by_blockdev(BlockDriverState *bs);
> QemuOpts *drive_def(const char *optstr);
> QemuOpts *drive_add(BlockInterfaceType type, int index, const char *file,
> const char *optstr);
> -DriveInfo *drive_init(QemuOpts *arg, int default_to_scsi);
> +DriveInfo *drive_init(QemuOpts *arg, BlockDefault block_default);
>
> /* device-hotplug */
>
> diff --git a/hw/boards.h b/hw/boards.h
> index 813d0e5..04017bf 100644
> --- a/hw/boards.h
> +++ b/hw/boards.h
> @@ -3,6 +3,7 @@
> #ifndef HW_BOARDS_H
> #define HW_BOARDS_H
>
> +#include "blockdev.h"
> #include "qdev.h"
>
> typedef struct QEMUMachineInitArgs {
> @@ -24,7 +25,7 @@ typedef struct QEMUMachine {
> const char *desc;
> QEMUMachineInitFunc *init;
> QEMUMachineResetFunc *reset;
> -int use_scsi;
> +BlockDefault block_default;
> int max_cpus;
> unsigned int no_serial:1,
> no_parallel:1,
> diff --git a/hw/device-hotplug.c b/hw/device-hotplug.c
> index eec0fe3..7f5be92 100644
> --- a/hw/device-hotplug.c
> +++ b/hw/device-hotplug.c
> @@ -39,7 +39,7 @@ DriveInfo *add_init_drive(const char *optstr)
> if (!opts)
> return NULL;
>
> -dinfo = drive_init(opts, current_machine->use_scsi);
> +dinfo = drive_init(opts, current_machine->block_default);
> if (!dinfo) {
> qemu_opts_del(opts);
> return NULL;
> diff --git a/hw/highbank.c b/hw/highbank.c
> index afbb005..de1027b 100644
> --- a/hw/highbank.c
> +++ b/hw/highbank.c
> @@ -326,7 +326,7 @@ static QEMUMachine highbank_machine = {
> .name = "highbank",
> .desc = "Calxeda Highbank (ECX-1000)",
> .init = highbank_init,
> -.use_scsi = 1,
> +.block_default = DEFAULT_SCSI,
> .max_cpus = 4,
> };
>
> diff --git a/hw/leon3.c b/hw/leon3.c
> index 7742738..ef83dff 100644
> --- a/hw/leon3.c
> +++ b/hw/leon3.c
> @@ -212,7 +21
Re: [Qemu-devel] no monitor after disable vnc
Il 19/11/2012 14:25, Peter Cheung ha scritto: > Dear All > When i compile qemu in ubuntu 12.10 with "./configure > --target-list=i386-softmmu --prefix=/root/qemu --enable-debug > --disable-vnc --disable-werror" , after i start qemu, no screen output, > how to enable it? Please attach your config.log. Paolo
Re: [Qemu-devel] [PATCH 1/1] Support default block interfaces per QEMUMachine
On 19/11/12 14:36, Alexander Graf wrote:
>
> On 12.11.2012, at 09:22, Christian Borntraeger wrote:
>
>> There are QEMUMachines that have neither IF_IDE nor IF_SCSI as a
>> default/standard interface to their block devices / drives. Therfore,
>> this patch introduces a new field default_block per QEMUMachine struct.
>> The prior use_scsi field becomes thereby obsolete and is replaced through
>> .default_block = DEFAULT_SCSI.
>>
>> Based on an initial patch from Einar Lueck
>>
>> Signed-off-by: Christian Borntraeger
>> ---
>> blockdev.c |4 ++--
>> blockdev.h | 29 -
>> hw/boards.h |3 ++-
>> hw/device-hotplug.c |2 +-
>> hw/highbank.c |2 +-
>> hw/leon3.c |1 -
>> hw/mips_jazz.c |4 ++--
>> hw/pc_sysfw.c |2 +-
>> hw/puv3.c |1 -
>> hw/realview.c |7 ---
>> hw/s390-virtio.c| 16 +---
>> hw/spapr.c |2 +-
>> hw/sun4m.c | 24
>> hw/versatilepb.c|4 ++--
>> hw/vexpress.c |4 ++--
>> hw/xilinx_zynq.c|2 +-
>> vl.c| 20 +++-
>> 17 files changed, 71 insertions(+), 56 deletions(-)
>>
>> diff --git a/blockdev.c b/blockdev.c
>> index e73fd6e..aca3c14 100644
>> --- a/blockdev.c
>> +++ b/blockdev.c
>> @@ -275,7 +275,7 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
>> return true;
>> }
>>
>> -DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>> +DriveInfo *drive_init(QemuOpts *opts, BlockDefault block_default)
>> {
>> const char *buf;
>> const char *file = NULL;
>> @@ -325,7 +325,7 @@ DriveInfo *drive_init(QemuOpts *opts, int
>> default_to_scsi)
>> return NULL;
>> }
>> } else {
>> -type = default_to_scsi ? IF_SCSI : IF_IDE;
>> +type = block_if_from_default(block_default);
>> }
>>
>> max_devs = if_max_devs[type];
>> diff --git a/blockdev.h b/blockdev.h
>> index 5f27b64..aba6d77 100644
>> --- a/blockdev.h
>> +++ b/blockdev.h
>> @@ -24,6 +24,33 @@ typedef enum {
>> IF_COUNT
>> } BlockInterfaceType;
>>
>> +/* For machine default interface. */
>> +typedef enum {
>> +DEFAULT_IDE = 0,
>> +DEFAULT_SCSI,
>> +DEFAULT_FLOPPY,
>> +DEFAULT_PFLASH,
>> +DEFAULT_MTD,
>> +DEFAULT_SD,
>> +DEFAULT_VIRTIO,
>> +DEFAULT_XEN
>> +} BlockDefault;
>
> Why a new enum? Can't we just reuse the IF_ ones?
>
> Also, traditionally Markus has had very strong opinions on anything IF_ and
> -drive related. It's probably a good idea to get him in the loop :).
>
> Alex
Review feedback from the first cycle. Anthony wanted to make the default (field
is not specified at all) a
sane default, which means IDE must be 0.
Re: [Qemu-devel] [PATCH 06/24] Remove local ram_size that hides global one
On 19.11.2012, at 14:35, Eduardo Habkost wrote: > On Mon, Nov 19, 2012 at 02:14:27PM +0100, Alexander Graf wrote: >> >> On 13.11.2012, at 13:11, Christian Borntraeger wrote: >> >>> From: Heinz Graalfs >>> >>> The global variable 'ram_size' is hidden by the local variable >>> declaration in s390_init() >> >> That's the point of Eduardo's patch, no? Or do we need access to the global >> to change its value afterwards? If so, please write a reasonable patch >> description that actually explains the problem. >> > > Actually, I wanted to keep the existing behavior (whatever it was), and > use local variables to replace the old function parameters, and change > nothing else. Most machines used a local variable named 'ram_size', but > the parameter to s390_init() was named 'my_ram_size'. > > So, considering that this at least restores the previous behavior: > > Reviewed-by: Eduardo Habkost Yup, Heinz, please resend with a patch description that actually tells us what the problem is. Alex
Re: [Qemu-devel] [PATCH 1/1] Support default block interfaces per QEMUMachine
On 19.11.2012, at 14:44, Christian Borntraeger wrote:
> On 19/11/12 14:36, Alexander Graf wrote:
>>
>> On 12.11.2012, at 09:22, Christian Borntraeger wrote:
>>
>>> There are QEMUMachines that have neither IF_IDE nor IF_SCSI as a
>>> default/standard interface to their block devices / drives. Therfore,
>>> this patch introduces a new field default_block per QEMUMachine struct.
>>> The prior use_scsi field becomes thereby obsolete and is replaced through
>>> .default_block = DEFAULT_SCSI.
>>>
>>> Based on an initial patch from Einar Lueck
>>>
>>> Signed-off-by: Christian Borntraeger
>>> ---
>>> blockdev.c |4 ++--
>>> blockdev.h | 29 -
>>> hw/boards.h |3 ++-
>>> hw/device-hotplug.c |2 +-
>>> hw/highbank.c |2 +-
>>> hw/leon3.c |1 -
>>> hw/mips_jazz.c |4 ++--
>>> hw/pc_sysfw.c |2 +-
>>> hw/puv3.c |1 -
>>> hw/realview.c |7 ---
>>> hw/s390-virtio.c| 16 +---
>>> hw/spapr.c |2 +-
>>> hw/sun4m.c | 24
>>> hw/versatilepb.c|4 ++--
>>> hw/vexpress.c |4 ++--
>>> hw/xilinx_zynq.c|2 +-
>>> vl.c| 20 +++-
>>> 17 files changed, 71 insertions(+), 56 deletions(-)
>>>
>>> diff --git a/blockdev.c b/blockdev.c
>>> index e73fd6e..aca3c14 100644
>>> --- a/blockdev.c
>>> +++ b/blockdev.c
>>> @@ -275,7 +275,7 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
>>>return true;
>>> }
>>>
>>> -DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>>> +DriveInfo *drive_init(QemuOpts *opts, BlockDefault block_default)
>>> {
>>>const char *buf;
>>>const char *file = NULL;
>>> @@ -325,7 +325,7 @@ DriveInfo *drive_init(QemuOpts *opts, int
>>> default_to_scsi)
>>>return NULL;
>>> }
>>>} else {
>>> -type = default_to_scsi ? IF_SCSI : IF_IDE;
>>> +type = block_if_from_default(block_default);
>>>}
>>>
>>>max_devs = if_max_devs[type];
>>> diff --git a/blockdev.h b/blockdev.h
>>> index 5f27b64..aba6d77 100644
>>> --- a/blockdev.h
>>> +++ b/blockdev.h
>>> @@ -24,6 +24,33 @@ typedef enum {
>>>IF_COUNT
>>> } BlockInterfaceType;
>>>
>>> +/* For machine default interface. */
>>> +typedef enum {
>>> +DEFAULT_IDE = 0,
>>> +DEFAULT_SCSI,
>>> +DEFAULT_FLOPPY,
>>> +DEFAULT_PFLASH,
>>> +DEFAULT_MTD,
>>> +DEFAULT_SD,
>>> +DEFAULT_VIRTIO,
>>> +DEFAULT_XEN
>>> +} BlockDefault;
>>
>> Why a new enum? Can't we just reuse the IF_ ones?
>>
>> Also, traditionally Markus has had very strong opinions on anything IF_ and
>> -drive related. It's probably a good idea to get him in the loop :).
>>
>> Alex
>
> Review feedback from the first cycle. Anthony wanted to make the default
> (field is not specified at all) a
> sane default, which means IDE must be 0.
IF_ are internal constants, we can change them to our liking. So if we just
make IF_IDE=0, all is well, no? Worst case we can always have an IF_DEFAULT=0
that falls back to IF_IDE.
I really dislike having the same list twice, just with different but almost
identical names.
Alex
Re: [Qemu-devel] slow virtio network with vhost=on and multiple cores
On 13.11.2012 17:33, Michael S. Tsirkin wrote: On Tue, Nov 13, 2012 at 06:22:56PM +0200, Michael S. Tsirkin wrote: On Tue, Nov 13, 2012 at 12:49:03PM +0100, Peter Lieven wrote: On 09.11.2012 19:03, Peter Lieven wrote: Remark: If i disable interrupts on CPU1-3 for virtio the performance is ok again. Now we need someone with deeper knowledge of the in-kernel irqchip and the virtio/vhost driver development to say if this is a regression in qemu-kvm or a problem with the old virtio drivers if they receive the interrupt on different CPUs. anyone? Looks like the problem is not in the guest: I tried ubuntu guest on a rhel host, I got 8GB/s with vhost and 4GB/s without on a host to guest banchmark. Tried with upstream qemu on rhel kernel and that's even a bit faster. So it's ubuntu kernel. vanilla 2.6.32 didn't have vhost at all so maybe their vhost backport is broken insome way. Do you remember since which version of the vanilla kernel vhost-net was officially included? Peter
Re: [Qemu-devel] [PATCH 1/1] Support default block interfaces per QEMUMachine
Alexander Graf writes:
> On 19.11.2012, at 14:44, Christian Borntraeger wrote:
>
>> On 19/11/12 14:36, Alexander Graf wrote:
>>>
>>> On 12.11.2012, at 09:22, Christian Borntraeger wrote:
>>>
There are QEMUMachines that have neither IF_IDE nor IF_SCSI as a
default/standard interface to their block devices / drives. Therfore,
this patch introduces a new field default_block per QEMUMachine struct.
The prior use_scsi field becomes thereby obsolete and is replaced through
.default_block = DEFAULT_SCSI.
Based on an initial patch from Einar Lueck
Signed-off-by: Christian Borntraeger
---
blockdev.c |4 ++--
blockdev.h | 29 -
hw/boards.h |3 ++-
hw/device-hotplug.c |2 +-
hw/highbank.c |2 +-
hw/leon3.c |1 -
hw/mips_jazz.c |4 ++--
hw/pc_sysfw.c |2 +-
hw/puv3.c |1 -
hw/realview.c |7 ---
hw/s390-virtio.c| 16 +---
hw/spapr.c |2 +-
hw/sun4m.c | 24
hw/versatilepb.c|4 ++--
hw/vexpress.c |4 ++--
hw/xilinx_zynq.c|2 +-
vl.c| 20 +++-
17 files changed, 71 insertions(+), 56 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index e73fd6e..aca3c14 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -275,7 +275,7 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
return true;
}
-DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
+DriveInfo *drive_init(QemuOpts *opts, BlockDefault block_default)
{
const char *buf;
const char *file = NULL;
@@ -325,7 +325,7 @@ DriveInfo *drive_init(QemuOpts *opts, int
default_to_scsi)
return NULL;
}
} else {
-type = default_to_scsi ? IF_SCSI : IF_IDE;
+type = block_if_from_default(block_default);
}
max_devs = if_max_devs[type];
diff --git a/blockdev.h b/blockdev.h
index 5f27b64..aba6d77 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -24,6 +24,33 @@ typedef enum {
IF_COUNT
} BlockInterfaceType;
+/* For machine default interface. */
+typedef enum {
+DEFAULT_IDE = 0,
+DEFAULT_SCSI,
+DEFAULT_FLOPPY,
+DEFAULT_PFLASH,
+DEFAULT_MTD,
+DEFAULT_SD,
+DEFAULT_VIRTIO,
+DEFAULT_XEN
+} BlockDefault;
>>>
>>> Why a new enum? Can't we just reuse the IF_ ones?
>>>
>>> Also, traditionally Markus has had very strong opinions on anything
>>> IF_ and -drive related. It's probably a good idea to get him in the
>>> loop :).
>>>
>>> Alex
>>
>> Review feedback from the first cycle. Anthony wanted to make the
>> default (field is not specified at all) a
>> sane default, which means IDE must be 0.
>
> IF_ are internal constants, we can change them to our liking. So if we
> just make IF_IDE=0, all is well, no? Worst case we can always have an
> IF_DEFAULT=0 that falls back to IF_IDE.
>
> I really dislike having the same list twice, just with different but
> almost identical names.
Generalizing QEMUMachine member use_scsi to a default BlockInterfaceType
makes plenty of sense to me.
I'm not sure "no initializer means IDE" is such a hot idea, but since
it's how use_scsi has always worked, I'm okay with making its
replacement work like that, too.
Like Alex, I dislike inventing yet another enumeration for this
purpose. Let's use BlockInterfaceType.
In theory, we can change values of internal enumerations freely. In
practice, such changes can run afoul of leaky abstractions, such as C89
array initializers and sloppy tests against zero. Careful review
advised.
Re: [Qemu-devel] [Bug 1080086] Re: MC146818 RTC breaks when SET bit in Register B is on.
>> Out of curiosity, does anyone know how long this particular bug has >> been undetected or how/when it was introduced? > > Probably it was introduced last September when the model was rewritten. > But it's really unlikely that the bug would have been detected. Thanks for that quick assessment. > On the other hand, the bug in commit b6db4ac (which also includes a > qtest) was detected by autotest. Could your tool find it, too? That's a very respectable achievement. I understand that Autotest runs predefined (i.e. hand-written) tests on a large scale. In contrast, we seek a higher degree of automation but on a smaller scale. These differences could make a comparison difficult. However, your example is much appreciated because it helps us to set our work in perspective. >> This could help me explain to others my research interest in symbolic >> execution of hardware models and its application in form of automated >> test generation. > > Very interesting (at least to me :)). Perhaps you find the following background helpful. To kick start our work, we extracted from QEMU a standalone RTC hardware model [2] because QOM, QMP, TCG or QTest would render the semi-automatic analysis infeasible. As a next step, we would like to combine this standalone hardware model with a Linux x86 driver [3]. The reported bug is a good exemplar of the type of firmware/hardware interface properties we are interested in. Note that this is only the initial phase of our research and there is much work yet to be done. Of course, any comments or collaboration are always welcome. With kind regards, Alex [2] https://github.com/ahorn/benchmarks/tree/master/qemu-hw [3] https://github.com/ahorn/benchmarks/tree/master/sw-hw/linux/rtc_x86 On 19 November 2012 11:42, Paolo Bonzini wrote: > Il 19/11/2012 12:34, Alex Horn ha scritto: >>> [...] the patch is almost good for inclusion. I'd ask for two changes: >>> 1) please test == 0, not != REG_B_SET; >>> 2) please leave the fuzzicsng test last >> >> I have attached a new patch with the requested changes. >> >> This patch also improves the quality of the functional test by >> checking that RTC_SECONDS is equal (==) to the previously written data >> provided the SET flag in Register B is still enabled. This is >> justified by the data sheet which states that an enabled SET bit >> "stops an existing update" and prevents "a new one from occurring" [1, >> p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS >> check uses an inequality (>=) as in the original test case. > > Right. > >> Out of curiosity, does anyone know how long this particular bug has >> been undetected or how/when it was introduced? > > Probably it was introduced last September when the model was rewritten. > But it's really unlikely that the bug would have been detected. > > On the other hand, the bug in commit b6db4ac (which also includes a > qtest) was detected by autotest. Could your tool find it, too? > >> This could help me explain to others my research interest in symbolic >> execution of hardware models and its application in form of automated >> test generation. > > Very interesting (at least to me :)). > >> Finally, if there is interest to improve the robustness of the RTC >> model, I could send a patch with several verification conditions (i.e. >> assertions) which can help to expose these kind of bugs in the RTC >> hardware model. > > Sure, that's welcome. > > In particular, I assume you verified the "next alarm" code to be correct? :) > > Paolo > >> Recall that most compiler can usually optimize these >> assertions away unless a developer explicitly enables them. They also >> serve as unambiguous code documentation. >> >> With best regards, >> Alex >> >> [1] >> http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf >> >> On 18 November 2012 08:52, Paolo Bonzini wrote: >>> Il 17/11/2012 19:47, Alex Horn ha scritto: I have attached a patch for the most recent version of the file hw/mc146818rtc.c [1]. The patch also features a functional test which executes through the QTest framework. I would appreciate your thoughts on this. [1] http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563 ** Patch added: "register_b_set_flag.patch" https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch >>> >>> Hi Alex, the patch is almost good for inclusion. I'd ask for two >>> changes: 1) please test == 0, not != REG_B_SET; 2) please leave the >>> fuzzing test last, because it may leave some registers in an undefined >>> state. >>> >>> Paolo >
[Qemu-devel] [PATCH 1/2] slirp: Don't crash on packets from 0.0.0.0/8.
From: Nickolai Zeldovich
LWIP can generate packets with a source of 0.0.0.0, which triggers an
assertion failure in arp_table_add(). Instead of crashing, simply return
to avoid adding an invalid ARP table entry.
Signed-off-by: Nickolai Zeldovich
Signed-off-by: Jan Kiszka
---
slirp/arp_table.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/slirp/arp_table.c b/slirp/arp_table.c
index 5d7b8ac..bf698c1 100644
--- a/slirp/arp_table.c
+++ b/slirp/arp_table.c
@@ -38,7 +38,9 @@ void arp_table_add(Slirp *slirp, uint32_t ip_addr, uint8_t
ethaddr[ETH_ALEN])
ethaddr[3], ethaddr[4], ethaddr[5]));
/* Check 0.0.0.0/8 invalid source-only addresses */
-assert((ip_addr & htonl(~(0xf << 28))) != 0);
+if ((ip_addr & htonl(~(0xf << 28))) == 0) {
+return;
+}
if (ip_addr == 0x || ip_addr == broadcast_addr) {
/* Do not register broadcast addresses */
--
1.7.3.4
[Qemu-devel] [PATCH 2/2] slirp: Add domain-search option to slirp's DHCP server
From: Klaus Stengel
This patch will allow the user to include the domain-search option in
replies from the built-in DHCP server. The domain suffixes can be
specified by adding dnssearch= entries to the "-net user" parameter.
[Jan: tiny style adjustments]
Signed-off-by: Klaus Stengel
Signed-off-by: Jan Kiszka
---
net/slirp.c | 35 +-
qapi-schema.json|4 +
qemu-options.hx | 18 +++-
slirp/Makefile.objs |2 +-
slirp/bootp.c | 12 ++
slirp/dnssearch.c | 314 +++
slirp/libslirp.h|3 +-
slirp/slirp.c |8 +-
slirp/slirp.h |5 +
9 files changed, 392 insertions(+), 9 deletions(-)
create mode 100644 slirp/dnssearch.c
diff --git a/net/slirp.c b/net/slirp.c
index bf86a44..afb52c3 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -136,7 +136,7 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
const char *vhostname, const char *tftp_export,
const char *bootfile, const char *vdhcp_start,
const char *vnameserver, const char *smb_export,
- const char *vsmbserver)
+ const char *vsmbserver, const char **dnssearch)
{
/* default settings according to historic slirp */
struct in_addr net = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
@@ -242,7 +242,7 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
s = DO_UPCAST(SlirpState, nc, nc);
s->slirp = slirp_init(restricted, net, mask, host, vhostname,
- tftp_export, bootfile, dhcp, dns, s);
+ tftp_export, bootfile, dhcp, dns, dnssearch, s);
QTAILQ_INSERT_TAIL(&slirp_stacks, s, entry);
for (config = slirp_configs; config; config = config->next) {
@@ -699,6 +699,31 @@ net_init_slirp_configs(const StringList *fwd, int flags)
}
}
+static const char **slirp_dnssearch(const StringList *dnsname)
+{
+const StringList *c = dnsname;
+size_t i = 0, num_opts = 0;
+const char **ret;
+
+while (c) {
+num_opts++;
+c = c->next;
+}
+
+if (num_opts == 0) {
+return NULL;
+}
+
+ret = g_malloc((num_opts + 1) * sizeof(*ret));
+c = dnsname;
+while (c) {
+ret[i++] = c->value->str;
+c = c->next;
+}
+ret[i] = NULL;
+return ret;
+}
+
int net_init_slirp(const NetClientOptions *opts, const char *name,
NetClientState *peer)
{
@@ -706,6 +731,7 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
char *vnet;
int ret;
const NetdevUserOptions *user;
+const char **dnssearch;
assert(opts->kind == NET_CLIENT_OPTIONS_KIND_USER);
user = opts->user;
@@ -714,6 +740,8 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
user->has_ip ? g_strdup_printf("%s/24", user->ip) :
NULL;
+dnssearch = slirp_dnssearch(user->dnssearch);
+
/* all optional fields are initialized to "all bits zero" */
net_init_slirp_configs(user->hostfwd, SLIRP_CFG_HOSTFWD);
@@ -722,7 +750,7 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
ret = net_slirp_init(peer, "user", name, user->q_restrict, vnet,
user->host, user->hostname, user->tftp,
user->bootfile, user->dhcpstart, user->dns, user->smb,
- user->smbserver);
+ user->smbserver, dnssearch);
while (slirp_configs) {
config = slirp_configs;
@@ -731,6 +759,7 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
}
g_free(vnet);
+g_free(dnssearch);
return ret;
}
diff --git a/qapi-schema.json b/qapi-schema.json
index 542e3ac..5dfa052 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2404,6 +2404,9 @@
#
# @dns: #optional guest-visible address of the virtual nameserver
#
+# @dnssearch: #optional list of DNS suffixes to search, passed as DHCP option
+# to the guest
+#
# @smb: #optional root directory of the built-in SMB server
#
# @smbserver: #optional IP address of the built-in SMB server
@@ -2426,6 +2429,7 @@
'*bootfile': 'str',
'*dhcpstart': 'str',
'*dns': 'str',
+'*dnssearch': ['String'],
'*smb': 'str',
'*smbserver': 'str',
'*hostfwd': ['String'],
diff --git a/qemu-options.hx b/qemu-options.hx
index fe8f15c..a165cff 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1318,8 +1318,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
"create a new Network Interface Card and connect it to
VLAN 'n'\n"
#ifdef CONFIG_SLIRP
"-net
user[,vlan=n][,name=str][,net=addr[/mask]][,host=addr][,restrict=on|off]\n"
-"
[,hostname=host][,dhcpstart=addr][,dns=addr][,tftp=dir][,bootfile=f]\n"
-" [,hostfwd=rule][,guestfwd=rule]"
[Qemu-devel] [PATCH 0/2] [PULL] slirp: Fix for ARP assert and DSN search DHCP option
The following changes since commit ce34cf72fe508b27a78f83c184142e8d1e6a048a: Merge remote-tracking branch 'awilliam/tags/vfio-pci-for-qemu-1.3.0-rc0' into staging (2012-11-14 08:53:40 -0600) are available in the git repository at: git://git.kiszka.org/qemu.git queues/slirp Klaus Stengel (1): slirp: Add domain-search option to slirp's DHCP server Nickolai Zeldovich (1): slirp: Don't crash on packets from 0.0.0.0/8. net/slirp.c | 35 +- qapi-schema.json|4 + qemu-options.hx | 18 +++- slirp/Makefile.objs |2 +- slirp/arp_table.c |4 +- slirp/bootp.c | 12 ++ slirp/dnssearch.c | 314 +++ slirp/libslirp.h|3 +- slirp/slirp.c |8 +- slirp/slirp.h |5 + 10 files changed, 395 insertions(+), 10 deletions(-) create mode 100644 slirp/dnssearch.c CC: Klaus Stengel CC: Nickolai Zeldovich Klaus Stengel (1): slirp: Add domain-search option to slirp's DHCP server Nickolai Zeldovich (1): slirp: Don't crash on packets from 0.0.0.0/8. net/slirp.c | 35 +- qapi-schema.json|4 + qemu-options.hx | 18 +++- slirp/Makefile.objs |2 +- slirp/arp_table.c |4 +- slirp/bootp.c | 12 ++ slirp/dnssearch.c | 314 +++ slirp/libslirp.h|3 +- slirp/slirp.c |8 +- slirp/slirp.h |5 + 10 files changed, 395 insertions(+), 10 deletions(-) create mode 100644 slirp/dnssearch.c -- 1.7.3.4
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Hi Paolo, Hi Josh, i started to port the iscsi fixes to rbd. The one think i'm missing is. How to tell / call rbd to cancel I/O on the server side? I grepped librbd source code for abort / cancel but didn't find anything. Qemu must be able to tell rbd to cancel a specific I/O request. Greets, Stefan Am 19.11.2012 14:06, schrieb Paolo Bonzini: Il 19/11/2012 14:01, Stefan Priebe - Profihost AG ha scritto: The right behavior is to return only after the target says whether the cancellation was done or not. For libiscsi, it was implemented by the commits you mention. So the whole bunch of changes is needed for rbd? Something like the first three: 1bd075f29ea6d11853475c7c42734595720c3ac6 cfb3f5064af2d2e29c976e292c9472dfe9d61e31 27cbd828c617944c0f9603763fdf4fa87e7ad923 Paolo
[Qemu-devel] [PATCH 0/2] i2c: Add AT24Cxx EEPROM model
See patches for details. Jan Kiszka (2): i2c: Introduce device address mask Add AT24Cxx I2C EEPROM device model hw/Makefile.objs |2 +- hw/at24.c| 363 ++ hw/ds1338.c |2 +- hw/i2c.c |9 +- hw/i2c.h |3 +- hw/lm832x.c |2 +- hw/max7310.c |2 +- hw/pxa2xx.c |3 +- hw/smbus.c |2 +- hw/ssd0303.c |2 +- hw/tmp105.c |2 +- hw/tosa.c|2 +- hw/twl92230.c|2 +- hw/wm8750.c |2 +- hw/z2.c |2 +- 15 files changed, 383 insertions(+), 17 deletions(-) create mode 100644 hw/at24.c -- 1.7.3.4
[Qemu-devel] [PATCH 2/2] Add AT24Cxx I2C EEPROM device model
This implements I2C EEPROMs of the AT24Cxx series. Sizes from 1Kbit to
1024Kbit are supported. Each EEPROM is backed by a block device. Its
size can be explicitly specified by the "size" property (required for
sizes < 512, the blockdev sector size) or is derived from the size of
the backing block device. Device addresses are built from the device
number property. Write protection can be configured by declaring the
block device read-only.
Signed-off-by: Jan Kiszka
---
hw/Makefile.objs |2 +-
hw/at24.c| 363 ++
2 files changed, 364 insertions(+), 1 deletions(-)
create mode 100644 hw/at24.c
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index ea46f81..0c64712 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -170,7 +170,7 @@ common-obj-$(CONFIG_SSD0323) += ssd0323.o
common-obj-$(CONFIG_ADS7846) += ads7846.o
common-obj-$(CONFIG_MAX111X) += max111x.o
common-obj-$(CONFIG_DS1338) += ds1338.o
-common-obj-y += i2c.o smbus.o smbus_eeprom.o
+common-obj-y += i2c.o smbus.o smbus_eeprom.o at24.o
common-obj-y += eeprom93xx.o
common-obj-y += scsi-disk.o cdrom.o hd-geometry.o block-common.o
common-obj-y += scsi-generic.o scsi-bus.o
diff --git a/hw/at24.c b/hw/at24.c
new file mode 100644
index 000..e34f2da
--- /dev/null
+++ b/hw/at24.c
@@ -0,0 +1,363 @@
+/*
+ * AT24Cxx EEPROM emulation
+ *
+ * Copyright (c) 2012 Siemens AG
+ * Author: Jan Kiszka
+ *
+ * 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 "hw.h"
+#include "i2c.h"
+#include "blockdev.h"
+#include "hw/block-common.h"
+
+#define AT24_BASE_ADDRESS 0x50
+#define AT24_MAX_PAGE_LEN 256
+
+typedef enum AT24TransferState {
+AT24_IDLE,
+AT24_RD_ADDR,
+AT24_WR_ADDR_HI,
+AT24_WR_ADDR_LO,
+AT24_RW_DATA0,
+AT24_RD_DATA,
+AT24_WR_DATA,
+} AT24TransferState;
+
+typedef struct AT24State {
+I2CSlave i2c;
+BlockConf block_conf;
+BlockDriverState *bs;
+uint32_t size;
+bool wp;
+unsigned int addr_mask;
+unsigned int page_mask;
+bool addr16;
+unsigned int hi_addr_mask;
+uint8_t device;
+AT24TransferState transfer_state;
+uint8_t sector_buffer[BDRV_SECTOR_SIZE];
+int cached_sector;
+bool cache_dirty;
+uint32_t transfer_addr;
+} AT24State;
+
+static void at24_flush_transfer_buffer(AT24State *s)
+{
+if (s->cached_sector < 0 || !s->cache_dirty) {
+return;
+}
+bdrv_write(s->bs, s->cached_sector, s->sector_buffer, 1);
+s->cache_dirty = false;
+}
+
+static void at24_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
+{
+AT24State *s = DO_UPCAST(AT24State, i2c, i2c);
+
+switch (event) {
+case I2C_START_SEND:
+switch (s->transfer_state) {
+case AT24_IDLE:
+if (s->addr16) {
+s->transfer_addr = (param & s->hi_addr_mask) << 16;
+s->transfer_state = AT24_WR_ADDR_HI;
+} else {
+s->transfer_addr = (param & s->hi_addr_mask) << 8;
+s->transfer_state = AT24_WR_ADDR_LO;
+}
+break;
+default:
+s->transfer_state = AT24_IDLE;
+break;
+}
+break;
+case I2C_START_RECV:
+switch (s->transfer_state) {
+case AT24_IDLE:
+s->transfer_state = AT24_RD_ADDR;
+break;
+case AT24_RW_DATA0:
+s->transfer_state = AT24_RD_DATA;
+break;
+default:
+s->transfer_state = AT24_IDLE;
+break;
+}
+break;
+case I2C_FINISH:
+switch (s->transfer_state) {
+case AT24_WR_DATA:
+at24_flush_transfer_buffer(s);
+/* fall through */
+default:
+s->transfer_state = AT24_IDLE;
+break;
+}
+break;
+default:
+s->transfer_state = AT24_IDLE;
+break;
+}
+}
+
+static int at24_cache_sector(AT2
[Qemu-devel] [PATCH 1/2] i2c: Introduce device address mask
Some devices react on multiple addresses. To emulate this, we could
register them multiple times, but that is cumbersome. The AT24C16, e.g.
listens on 8 different addresses.
Instead, introduce a device address mask that is applied on the
transmitted address before matching it against the stored one. Moreover,
the transmitted address is passed as additional parameter to the event
callback of the device.
Signed-off-by: Jan Kiszka
---
hw/ds1338.c |2 +-
hw/i2c.c |9 +
hw/i2c.h |3 ++-
hw/lm832x.c |2 +-
hw/max7310.c |2 +-
hw/pxa2xx.c |3 ++-
hw/smbus.c|2 +-
hw/ssd0303.c |2 +-
hw/tmp105.c |2 +-
hw/tosa.c |2 +-
hw/twl92230.c |2 +-
hw/wm8750.c |2 +-
hw/z2.c |2 +-
13 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..59fcc01 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -75,7 +75,7 @@ static void inc_regptr(DS1338State *s)
}
}
-static void ds1338_event(I2CSlave *i2c, enum i2c_event event)
+static void ds1338_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
{
DS1338State *s = FROM_I2C_SLAVE(DS1338State, i2c);
diff --git a/hw/i2c.c b/hw/i2c.c
index 296bece..72b8f07 100644
--- a/hw/i2c.c
+++ b/hw/i2c.c
@@ -93,7 +93,7 @@ int i2c_start_transfer(i2c_bus *bus, uint8_t address, int
recv)
QTAILQ_FOREACH(kid, &bus->qbus.children, sibling) {
DeviceState *qdev = kid->child;
I2CSlave *candidate = I2C_SLAVE_FROM_QDEV(qdev);
-if (candidate->address == address) {
+if (candidate->address == (address & candidate->address_mask)) {
slave = candidate;
break;
}
@@ -108,7 +108,7 @@ int i2c_start_transfer(i2c_bus *bus, uint8_t address, int
recv)
start condition. */
bus->current_dev = slave;
if (sc->event) {
-sc->event(slave, recv ? I2C_START_RECV : I2C_START_SEND);
+sc->event(slave, recv ? I2C_START_RECV : I2C_START_SEND, address);
}
return 0;
}
@@ -124,7 +124,7 @@ void i2c_end_transfer(i2c_bus *bus)
sc = I2C_SLAVE_GET_CLASS(dev);
if (sc->event) {
-sc->event(dev, I2C_FINISH);
+sc->event(dev, I2C_FINISH, 0);
}
bus->current_dev = NULL;
@@ -175,7 +175,7 @@ void i2c_nack(i2c_bus *bus)
sc = I2C_SLAVE_GET_CLASS(dev);
if (sc->event) {
-sc->event(dev, I2C_NACK);
+sc->event(dev, I2C_NACK, 0);
}
}
@@ -207,6 +207,7 @@ static int i2c_slave_qdev_init(DeviceState *dev)
I2CSlave *s = I2C_SLAVE_FROM_QDEV(dev);
I2CSlaveClass *sc = I2C_SLAVE_GET_CLASS(s);
+s->address_mask = 0x7f;
return sc->init(s);
}
diff --git a/hw/i2c.h b/hw/i2c.h
index 0f5682b..6cf164b 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -39,7 +39,7 @@ typedef struct I2CSlaveClass
int (*recv)(I2CSlave *s);
/* Notify the slave of a bus state change. */
-void (*event)(I2CSlave *s, enum i2c_event event);
+void (*event)(I2CSlave *s, enum i2c_event event, uint8_t param);
} I2CSlaveClass;
struct I2CSlave
@@ -48,6 +48,7 @@ struct I2CSlave
/* Remaining fields for internal use by the I2C code. */
uint8_t address;
+uint8_t address_mask;
};
i2c_bus *i2c_init_bus(DeviceState *parent, const char *name);
diff --git a/hw/lm832x.c b/hw/lm832x.c
index 8e09f9b..d69aa4b 100644
--- a/hw/lm832x.c
+++ b/hw/lm832x.c
@@ -378,7 +378,7 @@ static void lm_kbd_write(LM823KbdState *s, int reg, int
byte, uint8_t value)
}
}
-static void lm_i2c_event(I2CSlave *i2c, enum i2c_event event)
+static void lm_i2c_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
{
LM823KbdState *s = FROM_I2C_SLAVE(LM823KbdState, i2c);
diff --git a/hw/max7310.c b/hw/max7310.c
index 1ed18ba..63999be 100644
--- a/hw/max7310.c
+++ b/hw/max7310.c
@@ -123,7 +123,7 @@ static int max7310_tx(I2CSlave *i2c, uint8_t data)
return 0;
}
-static void max7310_event(I2CSlave *i2c, enum i2c_event event)
+static void max7310_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
{
MAX7310State *s = (MAX7310State *) i2c;
s->len = 0;
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index e616979..fb1fd0d 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -1239,7 +1239,8 @@ static void pxa2xx_i2c_update(PXA2xxI2CState *s)
}
/* These are only stubs now. */
-static void pxa2xx_i2c_event(I2CSlave *i2c, enum i2c_event event)
+static void pxa2xx_i2c_event(I2CSlave *i2c, enum i2c_event event,
+ uint8_t param)
{
PXA2xxI2CSlaveState *slave = FROM_I2C_SLAVE(PXA2xxI2CSlaveState, i2c);
PXA2xxI2CState *s = slave->host;
diff --git a/hw/smbus.c b/hw/smbus.c
index e3cf6a2..7d070d9 100644
--- a/hw/smbus.c
+++ b/hw/smbus.c
@@ -66,7 +66,7 @@ static void smbus_do_write(SMBusDevice *dev)
}
}
-static void smbus_i2c_event(I2CSlave *s, enum i2c_event event)
+static void smbus_i2c_event(I2CSlave *s, enum i2c_event event, uint8_t param)
{
SMBusDevice *dev = SMBUS_D
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Hi Paolo,
this is my current work status on porting these fixes to rbd. Right now
the discards get still canceled by the client kernel.
Might you have a look what i have forgotten?
Thanks!
Stefan
Am 19.11.2012 14:06, schrieb Paolo Bonzini:
Il 19/11/2012 14:01, Stefan Priebe - Profihost AG ha scritto:
The right behavior is to return
only after the target says whether the cancellation was done or not.
For libiscsi, it was implemented by the commits you mention.
So the whole bunch of changes is needed for rbd?
Something like the first three:
1bd075f29ea6d11853475c7c42734595720c3ac6
cfb3f5064af2d2e29c976e292c9472dfe9d61e31
27cbd828c617944c0f9603763fdf4fa87e7ad923
Paolo
>From 486fdb8b18310ff32ca64fbb2e0217c37319cff4 Mon Sep 17 00:00:00 2001
From: Stefan Priebe
Date: Mon, 19 Nov 2012 14:31:40 +0100
Subject: [PATCH 1/2] do not check for cancellation in qemu_rbd_complete_aio
Signed-off-by: Stefan Priebe
---
block/rbd.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/block/rbd.c b/block/rbd.c
index 5a0f79f..583bcc3 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -376,12 +376,6 @@ static void qemu_rbd_complete_aio(RADOSCB *rcb)
RBDAIOCB *acb = rcb->acb;
int64_t r;
-if (acb->cancelled) {
-qemu_vfree(acb->bounce);
-qemu_aio_release(acb);
-goto done;
-}
-
r = rcb->ret;
if (acb->cmd == RBD_AIO_WRITE ||
@@ -409,7 +403,7 @@ static void qemu_rbd_complete_aio(RADOSCB *rcb)
/* Note that acb->bh can be NULL in case where the aio was cancelled */
acb->bh = qemu_bh_new(rbd_aio_bh_cb, acb);
qemu_bh_schedule(acb->bh);
-done:
+
g_free(rcb);
}
--
1.7.10.4
>From e9eac2c7ed7b98ff102ab7da4573f081ebca32fa Mon Sep 17 00:00:00 2001
From: Stefan Priebe
Date: Mon, 19 Nov 2012 15:01:16 +0100
Subject: [PATCH 2/2] rbd: fix races between io completition and abort
Signed-off-by: Stefan Priebe
---
block/rbd.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/block/rbd.c b/block/rbd.c
index 583bcc3..ae1d03b 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -77,6 +77,7 @@ typedef struct RBDAIOCB {
int error;
struct BDRVRBDState *s;
int cancelled;
+int status;
} RBDAIOCB;
typedef struct RADOSCB {
@@ -376,6 +377,10 @@ static void qemu_rbd_complete_aio(RADOSCB *rcb)
RBDAIOCB *acb = rcb->acb;
int64_t r;
+if (acb->bh) {
+return;
+}
+
r = rcb->ret;
if (acb->cmd == RBD_AIO_WRITE ||
@@ -560,6 +565,20 @@ static void qemu_rbd_close(BlockDriverState *bs)
rados_shutdown(s->cluster);
}
+static void qemu_rbd_aio_abort(void *private_data)
+{
+RBDAIOCB *acb = (RBDAIOCB *) private_data;
+
+acb->status = -ECANCELED;
+
+if (acb->bh) {
+return;
+}
+
+acb->bh = qemu_bh_new(rbd_aio_bh_cb, acb);
+qemu_bh_schedule(acb->bh);
+}
+
/*
* Cancel aio. Since we don't reference acb in a non qemu threads,
* it is safe to access it here.
@@ -567,7 +586,22 @@ static void qemu_rbd_close(BlockDriverState *bs)
static void qemu_rbd_aio_cancel(BlockDriverAIOCB *blockacb)
{
RBDAIOCB *acb = (RBDAIOCB *) blockacb;
+
+if (acb->status != -EINPROGRESS) {
+return;
+}
+
acb->cancelled = 1;
+
+// TODO / FIXME: send an abort command to rbd
+// Normally we should call abort librbd and
+// librbd gets qemu_rbd_aio_abort as a callback function
+// i wasn't able to find an abort function in librbd at all
+qemu_rbd_aio_abort(acb);
+
+while (acb->status == -EINPROGRESS) {
+qemu_aio_wait();
+}
}
static AIOPool rbd_aio_pool = {
@@ -636,10 +670,13 @@ static void rbd_aio_bh_cb(void *opaque)
qemu_iovec_from_buf(acb->qiov, 0, acb->bounce, acb->qiov->size);
}
qemu_vfree(acb->bounce);
-acb->common.cb(acb->common.opaque, (acb->ret > 0 ? 0 : acb->ret));
qemu_bh_delete(acb->bh);
acb->bh = NULL;
+if (acb->cancelled == 0) {
+acb->common.cb(acb->common.opaque, (acb->ret > 0 ? 0 : acb->ret));
+}
+
qemu_aio_release(acb);
}
@@ -685,6 +722,7 @@ static BlockDriverAIOCB *rbd_start_aio(BlockDriverState *bs,
acb->s = s;
acb->cancelled = 0;
acb->bh = NULL;
+acb->status = -EINPROGRESS;
if (cmd == RBD_AIO_WRITE) {
qemu_iovec_to_buf(acb->qiov, 0, acb->bounce, qiov->size);
--
1.7.10.4
Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Il 19/11/2012 15:16, Stefan Priebe - Profihost AG ha scritto: > Hi Paolo, > Hi Josh, > > i started to port the iscsi fixes to rbd. The one think i'm missing is. > How to tell / call rbd to cancel I/O on the server side? > > I grepped librbd source code for abort / cancel but didn't find anything. > > Qemu must be able to tell rbd to cancel a specific I/O request. Just don't. QEMU will wait for rbd to finish the operation, instead of actually having it cancelled. Paolo
