Re: [Qemu-devel] [PULL 0/3] Update seabios to 1.7.4
On Di, 2014-02-04 at 11:39 +0400, Michael Tokarev wrote: 03.02.2014 18:45, Gerd Hoffmann wrote: Hi, Sorry for the delay folks, totally forgot that one. Here is the seabios update to 1.7.4 final. FWIW, we updated seabios in Debian testing (with qemu 1.7), and now there are several bugs filed in Debian BTS, at least: http://bugs.debian.org/737142 http://bugs.debian.org/736902 (this last one is a bit messy, all branches/combinations produce different results, and it isn't exactly stable). Dunno what 737142 is. 736902 looks like something with ram detection. Would be interesting to know whenever the blobs from this pull request are failing too. If so a seabios log would be helpful. cheers, Gerd
Re: [Qemu-devel] [PULL 0/2] qtest: don't leak pid files and UNIX domain sockets
On Mon, Feb 03, 2014 at 04:01:00PM +, Peter Maydell wrote: On 3 February 2014 15:20, Stefan Hajnoczi stefa...@redhat.com wrote: This pull request has been rebased onto qemu.git/master and retested. The series fixes init_socket() failures when reused PIDs cause temporary file name collisions. Your pull request appears to be missing the critically important part, ie the git repo/branch/tag information to pull from... (git request-pull is your friend here.) Oops, I ran the wrong script. Here are the full details and signed tag: The following changes since commit 2f61120c10da9128357510debc8e66880cd2bfdc: Merge remote-tracking branch 'qmp-unstable/queue/qmp' into staging (2014-02-01 23:32:31 +) are available in the git repository at: git://github.com/stefanha/qemu.git tags/qtest-for-peter for you to fetch changes up to 56db2e5843256c857addb17deb743109330649be: qtest: unlink UNIX domain sockets after connecting (2014-02-03 16:06:24 +0100) qtest resource cleanup patches Stefan Hajnoczi (2): qtest: unlink QEMU pid file after startup qtest: unlink UNIX domain sockets after connecting tests/libqtest.c | 45 +++-- 1 file changed, 23 insertions(+), 22 deletions(-)
Re: [Qemu-devel] [PATCH] trace backend: introduce multi tracing backend
On Tue, Feb 04, 2014 at 02:24:16PM +0900, Kazuya Saito wrote:
(2014/01/31 6:00), Stefan Hajnoczi wrote: On Tue, Jan 28, 2014 at 01:35:20PM
+0900, Kazuya Saito wrote:
diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 175df08..a0addb5 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -242,14 +242,19 @@ def generate(fevents, format, backend,
if not tracetool.format.exists(mformat):
raise TracetoolError(unknown format: %s % format)
-backend = str(backend)
+backends = str(backend).split(,)
if len(backend) is 0:
Before you modified the code it converted 'backend' to a string. Now it
tests len(backend) without converting it to a string.
I suggest s/backend/backends/ in this line to avoid that semantic
change.
backends is a list not a string. So, I'll modify it to the following.
backends = str(backend).split(,)
for backend in backends:
if len(backend) is 0:
You are right:
''.split(',')
['']
I thought it returns [].
Stefan
Re: [Qemu-devel] [PATCH v5 2/9] qdev: add to BusState hotplug-handler link
On Mon, 03 Feb 2014 13:50:02 -0700
Eric Blake ebl...@redhat.com wrote:
On 02/03/2014 01:38 PM, Igor Mammedov wrote:
+static inline void qbus_set_hotplug_handler(BusState *bus, DeviceState
*handler,
+Error **errp)
+{
+object_property_set_link(OBJECT(bus), OBJECT(handler),
+ QDEV_HOTPLUG_HANDLER_PROPERTY, errp);
+bus-allow_hotplug = 1;
Should we convert allow_hotplug to bool over the course of this series?
There isn't much point in touching it, since it's going to be removed once
all hotplug-able buses are converted to new interface.
After finishing my read through your series, I noticed that you were
using allow_hotplug less and less and instead using a new bool in most
code you added. Does that just mean your series didn't touch every last
client of the old interface, and that there still remains code to be
converted, where this series serves as the example of how?
Yes, beside adding new hotplug mechanism, it converts only PCI hotplug
workflow as example.
Paolo had plans to convert scsi hotplug once this series is in.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
Regards,
Igor
Re: [Qemu-devel] Improving patch tracking - something like gerrit?
Daniel P. Berrange berra...@redhat.com writes: On Mon, Feb 03, 2014 at 12:45:31PM +, Mark Cave-Ayland wrote: Hi all, It should be fairly evident to most people that the volume of patches flowing through the qemu-devel mailing list is continually increasing, and it is becoming increasingly difficult to track which patches have been applied over time. This is particularly a problem where patchsets have dependencies on other patchsets which haven't yet been applied to git master, which can then cause merge conflicts due to length of time taken for the final series to be merged. Is it time for QEMU to start looking at tools such as gerrit to help manage this process? There seems to be an increasing number of ping requests for outstanding patches (including my own) which don't get applied for weeks, and often even months because they target less popular platforms/subsystems and so don't always get the attention of the committers. Having had to use Gerrit for a long time on OpenStack, I'd never willingly use it on a project I was in charge of for a number of reasons - No practical integration with email based workflows for people who don't want to use web UIs to comment. You can download patches from tool using to view the code outside the UI, but to actually comment you need to use the RSI-inducing, pointy-clicky web UI. It's dead, Jim. - Poor handling of patch series - it shows dependancies between If the dead could get any deader, this one would now be. patches but that is basically all it does, and even that has poor UI. People frequently review 1 single patch never noticing that its part of a patch series. There's no way to get a view of all patches in a series ordered correctly. If you tag them with a topic, you can view all patches in the topic, but it randomly re-orders the patches, making it basically useless. - Poor UI for browsing through historical comments on previous versions of the patch. The comments are split between multiple web page views so you again have pointy-clicky hell trying to read through historical comments. And deader again. - Poor UI for browsing/querying pending patches. Reviewers typically find themselves having to write external/command line tools to query gerrit in order to workaround its limited UI. *Boggle* So sure, gerrit can track every single patch submitted and tell you if it is applied or not, but having used it, I can't say that it is a net win overall, particularly if your development process is heavily using large patch series. I think this system would reduce the time I spend on reviewing patches sharply. Sounds like a huge win to me!
Re: [Qemu-devel] [PATCH] trace backend: introduce multi tracing backend
On Tue, Feb 04, 2014 at 02:26:13PM +0900, Kazuya Saito wrote:
(2014/01/31 19:37), Stefan Hajnoczi wrote: On Tue, Jan 28, 2014 at
01:35:20PM +0900, Kazuya Saito wrote:
I hope this
change can be dropped in the next revision of the patch since the ust
backend will no longer be different.
OK. I'll try it.
However, the above should be changed because of events backend even if
it supports ust backend. I think there is two solutions for this.
The first is to define common.events_h() and common.events_c().
The other is to branch it for events backend as below.
if backends == [nop]:
func = tracetool.try_import(tracetool.format. + format,
nop, _empty)[1]
func(events)
elif backends == [events]:
func = tracetool.try_import(tracetool.backend.events,
format, None)[1]
func(events)
else:
func = tracetool.try_import(tracetool.backend.common,
format, None)[1]
func(backends, events)
I think the first is better because backend/__init__.py shouldn't care
events backend. Do you have any suggestions?
Yes, I prefer less special cases too.
def h(events):
+pass
I thought all code generation now happens in backends.common.h(), so
this function will not be called anymore?
It is called in tracetool.backend.compatible(). So, it is required when
selecting only dtrace backend.
The same is true for c() defined in this file.
It is also required for the same reason as dtrace.h().
tracetool.backend.compatible() is testing for the existence of a
function that is not used anywhere else. Backend code doesn't make it
obvious why this is necessary.
We should either make compatible() work (e.g. by testing body_format
and ensuring all formats use the body_ function prefix) or with
something explicit like a backend.supported_formats = ['c', 'h'] list.
+util-obj-$(CONFIG_TRACE_FTRACE) += multi.o ftrace.o
How about adding multi.o to util-obj-y just like control.o below? All
these object files are added to libqemuutil.a. The linker will only
pull in object files that are needed (based on symbol dependencies) so
there is no harm in uncoditionally building multi.o.
If adding multi.o to util-obj-y, compile error occurs when selecting
only dtrace backend. This is because the function trace_print_events(),
trace_event_set_state_dynamic_backend() and trace_backend_init() are
declared doubly in multi.o and default.o.
So, I'm going to leave it. Do you have any suggestions?
I guess it should be:
ifeq ($(CONFIG_TRACE_DEFAULT),y)
util-obj-y += default.o
else
util-obj-y += multi.o
endif
+bool trace_backend_init(const char *events, const char *file)
+{
+bool retval = true;
+
+#ifndef CONFIG_TRACE_SIMPLE
+if (file) {
+fprintf(stderr, error: -trace file=...:
+option not supported by the selected tracing backend\n);
+return false;
+}
+#endif
Not sure if this is right. We may need to use -trace file=... for
simple or ftrace. stderr should just ignore it.
The error message is output if the argument file is set when using
stderr, ftrace or dtrace backend. In other words, only simple
backend uses -trace file=...
This is the reason why I implemented it as seen above.
oops, I misread the code. I thought #ifdef instead of #ifndef.
Re: [Qemu-devel] [PATCH] tests/Makefile: Run qom-test for every architecture
Peter Maydell peter.mayd...@linaro.org writes: Rather than requiring every new architecture to remember to add a line to the Makefile to say that qom-test will work on it, autogenerate the list of supported architectures by looking at the files in default-configs (as configure does), and add qom-test to the test list for all of them automatically. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- Together with Markus' patch for running the test for all known machines for the architecture, this will avoid the problem of coverage being missed because of forgetting to update a whitelist. I applied this on top of Andreas's rebase of my patch rebased to current master. Applies cleanly and works fine. Reviewed-by: Markus Armbruster arm...@redhat.com
Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
Markus Armbruster arm...@redhat.com writes: Peter Crosthwaite peter.crosthwa...@xilinx.com writes: On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 08/01/2014 14:40, Andreas Färber ha scritto: Either you fix info qtree to cope with your change to the device graph, or the change needs to be reverted until somebody fixes it or it goes away. Sharing a backtrace would be a start, rather than just throwing around the word crash to justify reverting patches. :) I mentioned the root cause in the previous message: a Device cannot be added to main_system_bus, but that's what the patch does. The fix isn't trivial, because most of the affected board are not even qdevified. So I made progress here with the needed QOMification. Finally I have a sane info qtree WRT NAND: $ arm-softmmu/qemu-system-arm -M spitz -nographic -S (qemu) info qtree bus: main-system-bus type System ... dev: sl-nand, id manf_id = 236 chip_id = 115 irq 0 mmio 0c00/0040 bus: nand type nand-bus dev: nand, id manufacturer_id = 236 chip_id = 115 drive = null With just the proposed revert info qtree does work again, but is bogus: (qemu) info qtree bus: main-system-bus type System ... dev: nand, id manufacturer_id = 236 chip_id = 115 drive = null irq 0 dev: sl-nand, id manf_id = 236 chip_id = 115 irq 0 mmio 0c00/0040 Progress! Patches sometime next week hopefully. I think we can wait that long :) I just ran into the info qtree crash again, and I can't find your fix right now. Got a pointer for me?
Re: [Qemu-devel] [PATCH] configure: use glib in glib pkg-config check.
On Tue, Feb 04, 2014 at 09:56:38AM +1100, Chris Johns wrote:
On 3/02/2014 9:29 pm, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 03:26:15PM +1100, Chris Johns wrote:
Building against with a recent glib in a custom prefix fails because
the gthread cflags in the pkg-config file do not have the correct path
while the glib pc file does.
Signed-off-by: Chris Johns chr...@rtems.org
---
configure | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index b472694..12f730f 100755
--- a/configure
+++ b/configure
@@ -2343,9 +2343,9 @@ if test $mingw32 = yes; then
else
glib_req_ver=2.12
fi
-if $pkg_config --atleast-version=$glib_req_ver gthread-2.0; then
-glib_cflags=`$pkg_config --cflags gthread-2.0`
-glib_libs=`$pkg_config --libs gthread-2.0`
+if $pkg_config --atleast-version=$glib_req_ver glib-2.0; then
+glib_cflags=`$pkg_config --cflags glib-2.0`
+glib_libs=`$pkg_config --libs glib-2.0`
LIBS=$glib_libs $LIBS
libs_qga=$glib_libs $libs_qga
else
This change will cause -pthread linker + compiler flag to be lost.
I see in gthread-2.0.pc ..
Libs: -L${libdir} -lgthread-2.0
Cflags: -D_REENTRANT
and qemu includes 'glib.h'. Without the glib pc flags being used the
build fails not being able to find 'glib.h'.
I have no idea about the relationship this has with -pthread. Are
both needed ? It is not a problem on darwin. Qemu is building and
running the RTEMS testsuite nicely on the arm architecture (with the
posted zync reset patch).
On Linux there are more flags present in gthread-2.0.pc that are not
present in glib-2.0.pc:
Name: GThread
Description: Thread support for GLib
Requires: glib-2.0
Version: 2.38.2
Libs: -L${libdir} -lgthread-2.0 -pthread
Cflags: -pthread
The 'Requires: glib-2.0' line there means that when QEMU asking for
flags for 'gthread-2.0', it will *also* get any flags listed in the
'glib-2.0.pc' file.
What glib version are you seeing a problem with ?
glib-2.39.3 on darwin 13.0.2 (Mavrick).
It seems we should
really fix glib, since this will affect countless 1000's of apps using
it, not try to workaround in all downstream apps.
This is outside of my field of view; to me it still looks qemu specific.
I don't believe so. What QEMU is currently doing is correct so I
believe this is either a darwin specific glib bug or a flawed
build of glib on darwin.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PULL 0/3] Update seabios to 1.7.4
03.02.2014 18:45, Gerd Hoffmann wrote: are available in the git repository at: git://git.kraxel.org/qemu tags/pull-roms-1 Hmm. Did you forgot to push the tag? for you to fetch changes up to 41419b0f11d125ad792660638eb452c767eddc28: or the commits? Thanks, /mjt
Re: [Qemu-devel] [PATCH V6 5/8] block: Create authorizations mechanism for external snapshot and resize.
Am 04.02.2014 um 01:15 hat Jeff Cody geschrieben:
On Thu, Jan 23, 2014 at 09:31:36PM +0100, Benoît Canet wrote:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block.c | 65
---
block/blkverify.c | 2 +-
blockdev.c| 2 +-
include/block/block.h | 20 +++
include/block/block_int.h | 12 ++---
5 files changed, 77 insertions(+), 24 deletions(-)
diff --git a/block.c b/block.c
index e1bc732..3e0994b 100644
--- a/block.c
+++ b/block.c
@@ -5088,21 +5088,68 @@ int bdrv_amend_options(BlockDriverState *bs,
QEMUOptionParameter *options)
return bs-drv-bdrv_amend_options(bs, options);
}
-ExtSnapshotPerm bdrv_check_ext_snapshot(BlockDriverState *bs)
+/* Used to recurse on single child block filters.
+ * Single child block filter will store their child in bs-file.
+ */
+bool bdrv_generic_is_first_non_filter(BlockDriverState *bs,
+ BlockDriverState *candidate)
{
-if (bs-drv-bdrv_check_ext_snapshot) {
-return bs-drv-bdrv_check_ext_snapshot(bs);
+if (!bs-drv) {
+return false;
+}
+
+if (!bs-drv-authorizations[BS_IS_A_FILTER]) {
+if (bs == candidate) {
+return true;
+} else {
+return false;
+}
This seems to break external snapshots; after this patch, I can no
longer perform live ext snapshots (on qcow2, raw, etc..), unless I am
doing something incorrectly.
Instead of checking for bs == candidate, was it intended to check to
see if !strcmp(bs-filename, candidiate-filename) was true?
If believe the problem is in bdrv_is_first_non_filter(): It starts with
bs-file, whereas the first non-filter is obviously the top-level BDS
itself. I suspect the following patch fixes it (it makes the simple
snapshotting case work again, but I'm not sure if it forbids everything
that should be forbidden).
In any case, this shows that...
- ...our testing is still lacking (no qemu-iotests case for live
snapshots? Seriously? Expect it to be broken then.)
- ...not all patch authors do a good share of manual testing
- ...I have relaxed my reviewing too much. I wasn't convinced that this
patch is right, because the whole logic confused me, but I couldn't
point to a bug. I shouldn't have merged it when in doubt.
Jeff, would you like to submit a qemu-iotests case for snapshotting?
Benoît, can you check whether the patch below is correct?
Kevin
diff --git a/block.c b/block.c
index ac0ccac..1299484 100644
--- a/block.c
+++ b/block.c
@@ -5412,11 +5412,7 @@ bool bdrv_is_first_non_filter(BlockDriverState
*candidate)
QTAILQ_FOREACH(bs, bdrv_states, device_list) {
bool perm;
-if (!bs-file) {
-continue;
-}
-
-perm = bdrv_recurse_is_first_non_filter(bs-file, candidate);
+perm = bdrv_recurse_is_first_non_filter(bs, candidate);
/* candidate is the first non filter */
if (perm) {
Re: [Qemu-devel] [PATCH] qdev: Keep global allocation counter per bus
Actually [PATCH v3]. Alexander Graf ag...@suse.de writes: When we have 2 separate qdev devices that both create a qbus of the same type without specifying a bus name or device name, we end up with two buses of the same name, such as ide.0 on the Mac machines: dev: macio-ide, id bus: ide.0 type IDE dev: macio-ide, id bus: ide.0 type IDE If we now spawn a device that connects to a ide.0 the last created bus gets the device, with the first created bus inaccessible to the command line. After some discussion on IRC we concluded that the best quick fix way forward for this is to make automated bus-class type based allocation count a global counter. That's what this patch implements. With this we instead get dev: macio-ide, id bus: ide.1 type IDE dev: macio-ide, id bus: ide.0 type IDE on the example mentioned above. This also means that if you did -device ...,bus=ide.0 you got a device on the first bus (the last created one) before this patch and get that device on the second one (the first created one) now. Please add: This breaks migration unless you change bus=ide.0 to bus=ide.1 on the destination. Should be mentioned in release notes. Do we have a place where we collect release notes as we go? This is intended and makes the bus enumeration work as expected. As per review request follows a list of otherwise affected boards and the reasoning for the conclusion that they are ok: target machine bus id times -- --- -- - aarch64 n800i2c-bus.0 2 aarch64 n810i2c-bus.0 2 arm n800i2c-bus.0 2 arm n810i2c-bus.0 2 - Devices are created explicitly on one of the two buses, using s-mpu-i2c[0], so no change to the guest. Yes. Bus ID i2c-bus.0 isn't exposed to the user or the guest, so changing its interpretation is harmless. aarch64 vexpress-a15virtio-mmio-bus.0 4 aarch64 vexpress-a9 virtio-mmio-bus.0 4 aarch64 virtvirtio-mmio-bus.0 32 arm vexpress-a15virtio-mmio-bus.0 4 arm vexpress-a9 virtio-mmio-bus.0 4 arm virtvirtio-mmio-bus.0 32 - Migration drivers need to access virtio-mmio-bus.4/32 rather than .0 on the destination from old-new. Bugfix as it allows coldplug for specific buses. from old-new? Do you mean for old-new? Suggest - Makes -device bus= work for all virtio-mmio buses. Breaks migration. Workaround for migration from old to new: specify virtio-mmio-bus.4 or .32 respectively rather than .0 on the destination. aarch64 xilinx-zynq-a9 usb-bus.0 2 arm xilinx-zynq-a9 usb-bus.0 2 mips64elfulong2eusb-bus.0 2 - Normal USB operation not affected. Migration driver needs command line to use the other bus. i386isapc ide.0 2 x86_64 isapc ide.0 2 - Fix part of this patch. Err, what's part of this patch is adapting pc_init1() for the changed bus name, so it doesn't break. No need to mention what you're not breaking. But do mention what you're breaking: migration with bus=ide.0, exactly like in your Mac example. Please replace by something like this: - Makes -device bus= work for all IDE buses. Breaks migration. Workaround for migration from old to new: specify ide.1 rather than ide.0 on the destination. mipsmipside.0 2 mips64 mipside.0 2 mips64elmipside.0 2 mipsel mipside.0 2 - Not affected, the bus is not stored anywhere. Are you sure? I believe these are affected exactly like isapc. ppc g3beige ide.0 2 ppc mac99 ide.0 2 ppc prepide.0 2 ppc64 g3beige ide.0 2 ppc64 mac99 ide.0 2 ppc64 prepide.0 2 - Bugfix Again, just like isapc. CC: Paolo Bonzini pbonz...@redhat.com CC: Markus Armbruster arm...@redhat.com CC: Anthony Liguori aligu...@amazon.com Signed-off-by: Alexander Graf ag...@suse.de Patch looks good.
Re: [Qemu-devel] [PATCH V14 00/13] Quorum block filter
Am 03.02.2014 um 20:11 hat Benoît Canet geschrieben: v14: Use quorum_report_failure in early failure test suggested by Max [Benoît] v13: update copyright date and company legal status Benoît, please slow down a bit with pushing out new versions of this series. Five versions in one day is a bit too much. Give reviewers some time and address everything in one new version a few days later. Kevin
Re: [Qemu-devel] migration: broken ram_save_pending
Il 04/02/2014 08:15, Alexey Kardashevskiy ha scritto:
So. migration_thread() gets dirty pages number, tries to send them in a
loop but every iteration resets the number of pages to 96 and we start
again. After several tries we cross BUFFER_DELAY timeout and calculate new
@max_size and if the host machine is fast enough it is bigger than 393216
and next loop will finally finish the migration.
This should have happened pretty much immediately, because it's not
while (pending()) but rather
while (pending_size pending_size = max_size)
(it's an if in the code, but the idea is the same). And max_size is
the following:
max_size = bandwidth * migrate_max_downtime() / 100;
With the default throttling of 32 MiB/s, bandwidth must be something
like 33000 (expressed in bytes/ms) with the default settings, and then
max_size should be 33000*3*10^9 / 10^6 = 600. Where is my
computation wrong?
Also, did you profile it to find the hotspot? Perhaps the bitmap
operations are taking a lot of time. How big is the guest? Juan's
patches were optimizing the bitmaps but not all of them apply to your
case because of hpratio.
I can only think of something simple like below and not sure it does not
break other things. I would expect ram_save_pending() to return correct
number of bytes QEMU is going to send rather than number of pages
multiplied by 4096 but checking if all these pages are really empty is not
too cheap.
If you use qemu_update_position you will use very little bandwidth in
the case where a lot of pages are zero.
What you mention in ram_save_pending() is not problematic just because
of finding if the pages are empty, but also because you have to find the
nonzero spots in the bitmap!
Paolo
Thanks!
diff --git a/arch_init.c b/arch_init.c
index 2ba297e..90949b0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -537,16 +537,17 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
acct_info.dup_pages++;
}
}
} else if (is_zero_range(p, TARGET_PAGE_SIZE)) {
acct_info.dup_pages++;
bytes_sent = save_block_hdr(f, block, offset, cont,
RAM_SAVE_FLAG_COMPRESS);
qemu_put_byte(f, 0);
+qemu_update_position(f, TARGET_PAGE_SIZE);
bytes_sent++;
} else if (!ram_bulk_stage migrate_use_xbzrle()) {
current_addr = block-offset + offset;
bytes_sent = save_xbzrle_page(f, p, current_addr, block,
offset, cont, last_stage);
if (!last_stage) {
p = get_cached_data(XBZRLE.cache, current_addr);
}
Re: [Qemu-devel] [PATCH] misc: Fix case Qemu - QEMU
On 02/04/14 06:43, Stefan Weil wrote: Signed-off-by: Stefan Weil s...@weilnetz.de --- scripts/switch-timer-api |2 +- tests/i440fx-test.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/switch-timer-api b/scripts/switch-timer-api index a369a08..b0e230b 100755 --- a/scripts/switch-timer-api +++ b/scripts/switch-timer-api @@ -20,7 +20,7 @@ sub Syntax print STDERR STOP; Usage: $FindBin::Script [options] FILE ... -Translate each FILE to the new Qemu timer API. If no files +Translate each FILE to the new QEMU timer API. If no files are passed, a reasonable guess is taken. Options: diff --git a/tests/i440fx-test.c b/tests/i440fx-test.c index fa3e3d6..bcd2181 100644 --- a/tests/i440fx-test.c +++ b/tests/i440fx-test.c @@ -350,7 +350,7 @@ static void test_i440fx_firmware(FirmwareTestFixture *fixture, qtest_start(cmdline); g_free(cmdline); -/* Qemu has loaded the firmware (because qtest_start() only returns after +/* QEMU has loaded the firmware (because qtest_start() only returns after * the QMP handshake completes). We must unlink the firmware blob right * here, because any assertion firing below would leak it in the * filesystem. This is also the reason why we recreate the blob every time (I'm fine both ways.) Reviewed-by: Laszlo Ersek ler...@redhat.com
[Qemu-devel] [PATCH] raw: Fix BlockLimits passthrough
raw copies over the BlockLimits of bs-file during bdrv_open().
However, since commit d34682cd it is immediately overwritten during
bdrv_refresh_limits(). This caused all fields except for
opt_transfer_length and opt_mem_alignment (which happen to be correctly
inherited in generic code) to be zeroed.
Move the BlockLimit assignment to a .bdrv_refresh_limits() callback to
make it work again for all fields.
Reported-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/raw_bsd.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/block/raw_bsd.c b/block/raw_bsd.c
index 978ae7a..af8706d 100644
--- a/block/raw_bsd.c
+++ b/block/raw_bsd.c
@@ -90,6 +90,12 @@ static int raw_get_info(BlockDriverState *bs,
BlockDriverInfo *bdi)
return bdrv_get_info(bs-file, bdi);
}
+static int raw_refresh_limits(BlockDriverState *bs)
+{
+bs-bl = bs-file-bl;
+return 0;
+}
+
static int raw_truncate(BlockDriverState *bs, int64_t offset)
{
return bdrv_truncate(bs-file, offset);
@@ -150,7 +156,6 @@ static int raw_open(BlockDriverState *bs, QDict *options,
int flags,
Error **errp)
{
bs-sg = bs-file-sg;
-bs-bl = bs-file-bl;
return 0;
}
@@ -182,6 +187,7 @@ static BlockDriver bdrv_raw = {
.bdrv_getlength = raw_getlength,
.has_variable_length = true,
.bdrv_get_info= raw_get_info,
+.bdrv_refresh_limits = raw_refresh_limits,
.bdrv_is_inserted = raw_is_inserted,
.bdrv_media_changed = raw_media_changed,
.bdrv_eject = raw_eject,
--
1.8.1.4
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
On 02/03/2014 06:39 PM, Chen Gang wrote: On 02/03/2014 06:34 PM, Daniel P. Berrange wrote: On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote: We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH, so need use snprintf() instead of sprintf(). And also recommend to use ARRAY_SIZE instead of hard code macro for an array size in snprintf(). In the event that there is overflow this will cause the data to be truncated, potentially causing QEMU to access the wrong file on the host. Both snprintf and sprintf are really bad because of their use of fixed buffers. Better to change it to g_strdup_printf which dynamically allocates buffers. After check the details, I guess we can not change to g_strdup_printf or others (e.g. v9fs_string_*). v9fs need use mkdir, remove ... which have MAX_PATH limitation. So if the combined path is longer than MAX_PATH, before it passes to mkdir, remove ..., it has to be truncated just like what rpath() has done. So for me, we have to still use snprintf() instead of sprintf(), but really need provide the related comments under each snprintf(). That sounds reasonable to me, I will send patch v2 for it. Thanks. Thanks. -- Chen Gang Open, share and attitude like air, water and life which God blessed
Re: [Qemu-devel] [PULL 0/3] Update seabios to 1.7.4
On Di, 2014-02-04 at 14:21 +0400, Michael Tokarev wrote: 03.02.2014 18:45, Gerd Hoffmann wrote: are available in the git repository at: git://git.kraxel.org/qemu tags/pull-roms-1 Hmm. Did you forgot to push the tag? It's there: http://www.kraxel.org/cgit/qemu/tag/?id=pull-roms-1 It is a signed tag not a branch though. git fetch --tags ? cheers, Gerd
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote: On 02/03/2014 06:39 PM, Chen Gang wrote: On 02/03/2014 06:34 PM, Daniel P. Berrange wrote: On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote: We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH, so need use snprintf() instead of sprintf(). And also recommend to use ARRAY_SIZE instead of hard code macro for an array size in snprintf(). In the event that there is overflow this will cause the data to be truncated, potentially causing QEMU to access the wrong file on the host. Both snprintf and sprintf are really bad because of their use of fixed buffers. Better to change it to g_strdup_printf which dynamically allocates buffers. After check the details, I guess we can not change to g_strdup_printf or others (e.g. v9fs_string_*). v9fs need use mkdir, remove ... which have MAX_PATH limitation. So if the combined path is longer than MAX_PATH, before it passes to mkdir, remove ..., it has to be truncated just like what rpath() has done. I don't believe you are correct there. Those functions should return errno == ENAMETOOLONG - pathname was too long. The MAX_PATH constant is not even required to exist in POSIX, so I would not expect the spec to mandate anything about MAX_PATH in relation to those functions. Copying Eric who is involved the POSIX spec group to confirm. Even if they are limited, it is still better practice to use dynamic allocation for this, over fixed length buffers IMHO. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PULL 0/3] Update seabios to 1.7.4
04.02.2014 15:03, Gerd Hoffmann wrote: On Di, 2014-02-04 at 14:21 +0400, Michael Tokarev wrote: Hmm. Did you forgot to push the tag? It's there: http://www.kraxel.org/cgit/qemu/tag/?id=pull-roms-1 It is a signed tag not a branch though. git fetch --tags ? Interesting. I always used `git remote update', and it usually fetches all tags too, and it fetched quite a few of your tags and branches, but not the tag in question. I had to explicitly run `git fetch remote --tags' to get this one tag (together with the branch which leads to it). Wonder what's going on... But ok. Thanks, /mjt
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
On 02/04/2014 07:06 PM, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote: On 02/03/2014 06:39 PM, Chen Gang wrote: On 02/03/2014 06:34 PM, Daniel P. Berrange wrote: On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote: We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH, so need use snprintf() instead of sprintf(). And also recommend to use ARRAY_SIZE instead of hard code macro for an array size in snprintf(). In the event that there is overflow this will cause the data to be truncated, potentially causing QEMU to access the wrong file on the host. Both snprintf and sprintf are really bad because of their use of fixed buffers. Better to change it to g_strdup_printf which dynamically allocates buffers. After check the details, I guess we can not change to g_strdup_printf or others (e.g. v9fs_string_*). v9fs need use mkdir, remove ... which have MAX_PATH limitation. So if the combined path is longer than MAX_PATH, before it passes to mkdir, remove ..., it has to be truncated just like what rpath() has done. I don't believe you are correct there. Those functions should return errno == ENAMETOOLONG - pathname was too long. The MAX_PATH constant is not even required to exist in POSIX, so I would not expect the spec to mandate anything about MAX_PATH in relation to those functions. So the original author of v9fs will use truncation instead of return failure to upper users. I guess, we need discuss what original author have done is valuable or not (at least, it's necessary to mention about it in related documents). And at least, we are agree with each other: using sprintf() is a bug. Copying Eric who is involved the POSIX spec group to confirm. Even if they are limited, it is still better practice to use dynamic allocation for this, over fixed length buffers IMHO. Daniel Welcome any members' suggestions, discussion or completions. :-) Thanks. -- Chen Gang Open, share and attitude like air, water and life which God blessed
Re: [Qemu-devel] [PATCH] raw: Fix BlockLimits passthrough
On 02/04/14 12:01, Kevin Wolf wrote:
raw copies over the BlockLimits of bs-file during bdrv_open().
However, since commit d34682cd it is immediately overwritten during
bdrv_refresh_limits(). This caused all fields except for
opt_transfer_length and opt_mem_alignment (which happen to be correctly
inherited in generic code) to be zeroed.
Move the BlockLimit assignment to a .bdrv_refresh_limits() callback to
make it work again for all fields.
Reported-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/raw_bsd.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/block/raw_bsd.c b/block/raw_bsd.c
index 978ae7a..af8706d 100644
--- a/block/raw_bsd.c
+++ b/block/raw_bsd.c
@@ -90,6 +90,12 @@ static int raw_get_info(BlockDriverState *bs,
BlockDriverInfo *bdi)
return bdrv_get_info(bs-file, bdi);
}
+static int raw_refresh_limits(BlockDriverState *bs)
+{
+bs-bl = bs-file-bl;
+return 0;
+}
+
static int raw_truncate(BlockDriverState *bs, int64_t offset)
{
return bdrv_truncate(bs-file, offset);
@@ -150,7 +156,6 @@ static int raw_open(BlockDriverState *bs, QDict *options,
int flags,
Error **errp)
{
bs-sg = bs-file-sg;
-bs-bl = bs-file-bl;
return 0;
}
@@ -182,6 +187,7 @@ static BlockDriver bdrv_raw = {
.bdrv_getlength = raw_getlength,
.has_variable_length = true,
.bdrv_get_info= raw_get_info,
+.bdrv_refresh_limits = raw_refresh_limits,
.bdrv_is_inserted = raw_is_inserted,
.bdrv_media_changed = raw_media_changed,
.bdrv_eject = raw_eject,
Reviewed-by: Laszlo Ersek ler...@redhat.com
Re: [Qemu-devel] [PULL 0/3] Update seabios to 1.7.4
04.02.2014 12:17, Gerd Hoffmann wrote: On Di, 2014-02-04 at 11:39 +0400, Michael Tokarev wrote: FWIW, we updated seabios in Debian testing (with qemu 1.7), and now there are several bugs filed in Debian BTS, at least: http://bugs.debian.org/737142 http://bugs.debian.org/736902 Dunno what 737142 is. 736902 looks like something with ram detection. Would be interesting to know whenever the blobs from this pull request are failing too. If so a seabios log would be helpful. It looks like this mess is entirely due to my brown-paper-bag error. I updated multiboot.S (which we have to carry in seabios source for debian, a long story) from a wrong qemu branch (but at the same time stating in the README that it is from the right commit). Hence it broke. I'm now trying to verify 737142 (PC-BSD is unable to boot), but since it also uses multiboot, it is highly likely that it is the same issue. I'm sorry for the noize. Thanks, /mjt
Re: [Qemu-devel] [PATCH v2 0/5] disas: add libvixl to support A64 disassembly
On Wed, Jan 29, 2014 at 9:51 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 29 January 2014 20:01, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Tue, Jan 28, 2014 at 12:45 PM, Peter Maydell peter.mayd...@linaro.org wrote: Ping for review/testing/comments on this version, please? I still dislike the idea of importing so much code in particular for something that is incomplete: as far as I can see, AdvSIMD instructions are not supported. The very least that should be done would be to add a file that gives a rough status of what is and what is not implemented. I can add some text to a brief README file, sure. And what if the vixl authors never implement AdvSIMD? This is the most difficult part of Aarch64 to disassemble (integer and FP instructions are really easy to disassemble). Will someone add these and will vixl authors accept the changes or will we then start diverging from vixl implementation? Is vixl even still supported or in development (no commit for 6 months)? As I understand the situation, it is supported but the model is more we'll push out a release occasionally when we've done a big chunk of work rather than a continuously updated public-facing git tree. This is no worse at all (in fact better) than the situation we have with the binutils disassemblers in the tree at the moment -- those are effectively totally unmaintained by their upstream as a result of the GPL2/GPL3 split. I agree that it would be nice if we supported the SIMD instructions in the disassembler. Adding them to vixl should be no worse than adding them to anything else, and I'd rather have a disassembler that supported at least the integer set than none at all. That looks OK to me. Thanks, Laurent
Re: [Qemu-devel] [PATCH] qdev: Keep global allocation counter per bus
Il 04/02/2014 11:33, Markus Armbruster ha scritto: This breaks migration unless you change bus=ide.0 to bus=ide.1 on the destination. Should be mentioned in release notes. Do we have a place where we collect release notes as we go? Yes, http://wiki.qemu.org/ChangeLog/Next Paolo
Re: [Qemu-devel] migration: broken ram_save_pending
On 02/04/2014 09:46 PM, Paolo Bonzini wrote:
Il 04/02/2014 08:15, Alexey Kardashevskiy ha scritto:
So. migration_thread() gets dirty pages number, tries to send them in a
loop but every iteration resets the number of pages to 96 and we start
again. After several tries we cross BUFFER_DELAY timeout and calculate new
@max_size and if the host machine is fast enough it is bigger than 393216
and next loop will finally finish the migration.
This should have happened pretty much immediately, because it's not while
(pending()) but rather
while (pending_size pending_size = max_size)
(it's an if in the code, but the idea is the same). And max_size is the
following:
max_size = bandwidth * migrate_max_downtime() / 100;
With the default throttling of 32 MiB/s, bandwidth must be something like
33000 (expressed in bytes/ms) with the default settings, and then max_size
should be 33000*3*10^9 / 10^6 = 600. Where is my computation wrong?
migrate_max_downtime() = 3000 = 3*10^7.
When the migration is in iterating stage, bandwidth is a speed in last
100ms which is usually 5 blocks 250KB each so it is
125/100=12500bytes/s and max_size=12500*3000/10^6=375000 which is
less than the last chunk is.
Also, did you profile it to find the hotspot? Perhaps the bitmap
operations are taking a lot of time. How big is the guest?
1024MB.
Juan's patches
were optimizing the bitmaps but not all of them apply to your case because
of hpratio.
This I had to disable :)
I can only think of something simple like below and not sure it does not
break other things. I would expect ram_save_pending() to return correct
number of bytes QEMU is going to send rather than number of pages
multiplied by 4096 but checking if all these pages are really empty is not
too cheap.
If you use qemu_update_position you will use very little bandwidth in the
case where a lot of pages are zero.
My guest migrates in a second or so. I guess in this case
qemu_file_rate_limit() limits the speed and it does not look at QEMUFile::pos.
What you mention in ram_save_pending() is not problematic just because of
finding if the pages are empty, but also because you have to find the
nonzero spots in the bitmap!
Sure.
Paolo
Thanks!
diff --git a/arch_init.c b/arch_init.c
index 2ba297e..90949b0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -537,16 +537,17 @@ static int ram_save_block(QEMUFile *f, bool
last_stage)
acct_info.dup_pages++;
}
}
} else if (is_zero_range(p, TARGET_PAGE_SIZE)) {
acct_info.dup_pages++;
bytes_sent = save_block_hdr(f, block, offset, cont,
RAM_SAVE_FLAG_COMPRESS);
qemu_put_byte(f, 0);
+qemu_update_position(f, TARGET_PAGE_SIZE);
bytes_sent++;
} else if (!ram_bulk_stage migrate_use_xbzrle()) {
current_addr = block-offset + offset;
bytes_sent = save_xbzrle_page(f, p, current_addr, block,
offset, cont, last_stage);
if (!last_stage) {
p = get_cached_data(XBZRLE.cache, current_addr);
}
--
Alexey
Re: [Qemu-devel] [PATCH v2 0/5] disas: add libvixl to support A64 disassembly
On 4 February 2014 11:47, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Wed, Jan 29, 2014 at 9:51 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 29 January 2014 20:01, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Tue, Jan 28, 2014 at 12:45 PM, Peter Maydell peter.mayd...@linaro.org wrote: Ping for review/testing/comments on this version, please? I still dislike the idea of importing so much code in particular for something that is incomplete: as far as I can see, AdvSIMD instructions are not supported. The very least that should be done would be to add a file that gives a rough status of what is and what is not implemented. I can add some text to a brief README file, sure. And what if the vixl authors never implement AdvSIMD? This is the most difficult part of Aarch64 to disassemble (integer and FP instructions are really easy to disassemble). Will someone add these and will vixl authors accept the changes or will we then start diverging from vixl implementation? Is vixl even still supported or in development (no commit for 6 months)? As I understand the situation, it is supported but the model is more we'll push out a release occasionally when we've done a big chunk of work rather than a continuously updated public-facing git tree. This is no worse at all (in fact better) than the situation we have with the binutils disassemblers in the tree at the moment -- those are effectively totally unmaintained by their upstream as a result of the GPL2/GPL3 split. I agree that it would be nice if we supported the SIMD instructions in the disassembler. Adding them to vixl should be no worse than adding them to anything else, and I'd rather have a disassembler that supported at least the integer set than none at all. That looks OK to me. Thanks. Here's some proposed text for a disas/libvixl/README: ===begin=== The code in this directory is a subset of libvixl: https://github.com/armvixl/vixl (specifically, it is the set of files needed for disassembly only, taken from libvixl 1.1). Bugfixes should preferably be sent upstream initially. The disassembler does not currently support the entire A64 instruction set. Notably: * No Advanced SIMD support. * Limited support for system instructions. * A few miscellaneous integer and floating point instructions are missing. ===endit=== (borrowed from https://github.com/armvixl/vixl/README.md and edited to remove things that only really apply to the simulator). thanks -- PMM
Re: [Qemu-devel] migration: broken ram_save_pending
Il 04/02/2014 12:59, Alexey Kardashevskiy ha scritto: With the default throttling of 32 MiB/s, bandwidth must be something like 33000 (expressed in bytes/ms) with the default settings, and then max_size should be 33000*3*10^9 / 10^6 = 600. Where is my computation wrong? migrate_max_downtime() = 3000 = 3*10^7. Oops, that's the mistake. When the migration is in iterating stage, bandwidth is a speed in last 100ms which is usually 5 blocks 250KB each so it is 125/100=12500bytes/s and max_size=12500*3000/10^6=375000 which is less than the last chunk is. Perhaps our default maximum downtime is too low. 30 ms doesn't seem achievable in practice with 32 MiB/s bandwidth. Just making it 300 ms or so should fix your problem. Paolo
Re: [Qemu-devel] [PATCH] qdev: Keep global allocation counter per bus
Paolo Bonzini pbonz...@redhat.com writes: Il 04/02/2014 11:33, Markus Armbruster ha scritto: This breaks migration unless you change bus=ide.0 to bus=ide.1 on the destination. Should be mentioned in release notes. Do we have a place where we collect release notes as we go? Yes, http://wiki.qemu.org/ChangeLog/Next I can record this change there, but I don't seem to have an account.
Re: [Qemu-devel] migration: broken ram_save_pending
On 02/04/2014 11:07 PM, Paolo Bonzini wrote: Il 04/02/2014 12:59, Alexey Kardashevskiy ha scritto: With the default throttling of 32 MiB/s, bandwidth must be something like 33000 (expressed in bytes/ms) with the default settings, and then max_size should be 33000*3*10^9 / 10^6 = 600. Where is my computation wrong? migrate_max_downtime() = 3000 = 3*10^7. Oops, that's the mistake. Make a patch? :) When the migration is in iterating stage, bandwidth is a speed in last 100ms which is usually 5 blocks 250KB each so it is 125/100=12500bytes/s and max_size=12500*3000/10^6=375000 which is less than the last chunk is. Perhaps our default maximum downtime is too low. 30 ms doesn't seem achievable in practice with 32 MiB/s bandwidth. Just making it 300 ms or so should fix your problem. Well, it will fix it in my particular case but in a long run this does not feel like a fix - there should be a way for migration_thread() to know that ram_save_iterate() sent all dirty pages it had to send, no? -- Alexey
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
Chen Gang gang.chen.5...@gmail.com writes:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use ARRAY_SIZE instead of hard code macro for an
array size in snprintf().
In the event that there is overflow this will cause the data to be
truncated, potentially causing QEMU to access the wrong file on the
host. Both snprintf and sprintf are really bad because of their
use of fixed buffers. Better to change it to g_strdup_printf which
dynamically allocates buffers.
After check the details, I guess we can not change to g_strdup_printf or
others (e.g. v9fs_string_*).
v9fs need use mkdir, remove ... which have MAX_PATH limitation. So if
the combined path is longer than MAX_PATH, before it passes to mkdir,
remove ..., it has to be truncated just like what rpath() has done.
What good could truncating possibly do?
If the pathname is too long for mkdir(), truncating won't make it work,
it will make it do the wrong thing.
Second guessing when a pathname is too long for a system call is not a
good idea. If it's too long, the system call will tell you. As Dan
noted, PATH_MAX is *not* a hard limit.
{PATH_MAX}
Maximum number of bytes the implementation will store as a
pathname in a user-supplied buffer of unspecified size,
including the terminating null character. Minimum number the
implementation will accept as the maximum number of bytes in a
pathname.
[...]
[Qemu-devel] PC-BSD installer does not boot with 1.7.4 (bisected)
We have a bugreport in debian, http://bugs.debian.org/737142, stating that PC-BSD does not work with seabios-1.7.4 anymore. I digged in, and found out that it fails only with -vga std (cirrus works fine). So I bisected the issue - only changing vgabios-stdvga.bin, and found this: 9332f9b172dd59253365a83b5f1c0e40c5f6f66d is the first bad commit commit 9332f9b172dd59253365a83b5f1c0e40c5f6f66d Author: Kevin O'Connor ke...@koconnor.net Date: Sat Nov 30 12:52:44 2013 -0500 vgabios: Work around lack of support for calll in x86emu emulation. Replace 32 bit call instructions with 16 bit call instructions in the vgabios to workaround problems in old versions of x86emu. This change allows fc13 and fc14 to boot. (Other x86emu emulation bugs still prevent fc11 and fc12 from booting.) I'm not sure what is better - to have semi-working FC13 or non-working PC-BSD ;) Seriously, I don't really have any expirience in this area to understand what's going on. Note that PC-BSD fails clearly in some VGA-related code, and this is trivially reproducible. Thanks, /mjt
Re: [Qemu-devel] [libvirt] Looking for project ideas and mentors for Google Summer of Code 2014
On 03.02.2014 08:45, Stefan Hajnoczi wrote: KVM libvirt: you are welcome to join the QEMU umbrella organization like last year. I've updated wiki with a libvirt idea. But I can sense more to come later as I have some time to think about it :) Michal
Re: [Qemu-devel] [PATCH V15 01/13] quorum: Create quorum.c, add QuorumSingleAIOCB and QuorumAIOCB.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
Reviewed-by: Max Reitz mre...@redhat.com
---
block/Makefile.objs | 1 +
block/quorum.c | 54
+
2 files changed, 55 insertions(+)
create mode 100644 block/quorum.c
diff --git a/block/Makefile.objs b/block/Makefile.objs
index 4e8c91e..a2650b9 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -3,6 +3,7 @@ block-obj-y += qcow2.o qcow2-refcount.o qcow2-cluster.o
qcow2-snapshot.o qcow2-c
block-obj-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
block-obj-y += qed-check.o
block-obj-$(CONFIG_VHDX) += vhdx.o vhdx-endian.o vhdx-log.o
+block-obj-y += quorum.o
block-obj-y += parallels.o blkdebug.o blkverify.o
block-obj-y += snapshot.o qapi.o
block-obj-$(CONFIG_WIN32) += raw-win32.o win32-aio.o
diff --git a/block/quorum.c b/block/quorum.c
new file mode 100644
index 000..17695d6
--- /dev/null
+++ b/block/quorum.c
@@ -0,0 +1,54 @@
+/*
+ * Quorum Block filter
+ *
+ * Copyright (C) 2012-2014 Nodalink, EURL.
+ *
+ * Author:
+ * Benoît Canet benoit.ca...@irqsave.net
+ *
+ * Based on the design and code of blkverify.c (Copyright (C) 2010 IBM, Corp)
+ * and blkmirror.c (Copyright (C) 2011 Red Hat, Inc).
I think you were planning to respin anyway, so I'll practice my
nitpicking: The file is called mirror.c, not blkmirror.c.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include block/block_int.h
+
+typedef struct QuorumAIOCB QuorumAIOCB;
+
+/* Quorum will create one instance of the following structure per operation
it
+ * performs on its children.
+ * So for each read/write operation coming from the upper layer there will be
+ * $children_count QuorumSingleAIOCB.
+ */
+typedef struct QuorumSingleAIOCB {
+BlockDriverAIOCB *aiocb;
So this isn't a real AIOCB, but it merely points to one. Perhaps
something like QuorumChildRequest would be a more precise name?
+QEMUIOVector qiov;
+uint8_t *buf;
The combination of a linear buffer and qiov is unusual. It looks like
there may be a reason for it (otherwise qemu_iovec_clone() wouldn't
exist), but I don't understand it yet at this point. Could hint at a
lack of documentation.
I might back come to this later in the patch series.
+int ret;
+QuorumAIOCB *parent;
+} QuorumSingleAIOCB;
+
+/* Quorum will use the following structure to track progress of each
read/write
+ * operation received by the upper layer.
+ * This structure hold pointers to the QuorumSingleAIOCB structures instances
+ * used to do operations on each children and track overall progress.
+ */
+struct QuorumAIOCB {
+BlockDriverAIOCB common;
+
+/* Request metadata */
+uint64_t sector_num;
+int nb_sectors;
+
+QEMUIOVector *qiov; /* calling IOV */
+
+QuorumSingleAIOCB *aios;/* individual AIOs */
+int count; /* number of completed AIOCB */
+int success_count; /* number of successfully completed AIOCB */
+bool *finished; /* completion signal for cancel */
+
+bool is_read;
+int vote_ret;
+};
Kevin
Re: [Qemu-devel] [PATCH V6 8/8] block: Use graph node name as reference in bdrv_file_open().
On 02/03/2014 02:43 AM, Kevin Wolf wrote: Yes, I think allowing bdrv_lookup_bs() to find both node names and device names makes sense. I would still use a common namespace and forbid using the same name for a device and a node. That makes sense for libvirt as well (libvirt has every intention of using a different prefix when referring to a device than when referring to a node, so a shared namespace won't hurt libvirt, and makes the most sense for other operations). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH V6 5/8] block: Create authorizations mechanism for external snapshot and resize.
On Tue, Feb 04, 2014 at 11:25:52AM +0100, Kevin Wolf wrote:
Am 04.02.2014 um 01:15 hat Jeff Cody geschrieben:
On Thu, Jan 23, 2014 at 09:31:36PM +0100, Benoît Canet wrote:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block.c | 65
---
block/blkverify.c | 2 +-
blockdev.c| 2 +-
include/block/block.h | 20 +++
include/block/block_int.h | 12 ++---
5 files changed, 77 insertions(+), 24 deletions(-)
diff --git a/block.c b/block.c
index e1bc732..3e0994b 100644
--- a/block.c
+++ b/block.c
@@ -5088,21 +5088,68 @@ int bdrv_amend_options(BlockDriverState *bs,
QEMUOptionParameter *options)
return bs-drv-bdrv_amend_options(bs, options);
}
-ExtSnapshotPerm bdrv_check_ext_snapshot(BlockDriverState *bs)
+/* Used to recurse on single child block filters.
+ * Single child block filter will store their child in bs-file.
+ */
+bool bdrv_generic_is_first_non_filter(BlockDriverState *bs,
+ BlockDriverState *candidate)
{
-if (bs-drv-bdrv_check_ext_snapshot) {
-return bs-drv-bdrv_check_ext_snapshot(bs);
+if (!bs-drv) {
+return false;
+}
+
+if (!bs-drv-authorizations[BS_IS_A_FILTER]) {
+if (bs == candidate) {
+return true;
+} else {
+return false;
+}
This seems to break external snapshots; after this patch, I can no
longer perform live ext snapshots (on qcow2, raw, etc..), unless I am
doing something incorrectly.
Instead of checking for bs == candidate, was it intended to check to
see if !strcmp(bs-filename, candidiate-filename) was true?
If believe the problem is in bdrv_is_first_non_filter(): It starts with
bs-file, whereas the first non-filter is obviously the top-level BDS
itself. I suspect the following patch fixes it (it makes the simple
snapshotting case work again, but I'm not sure if it forbids everything
that should be forbidden).
In any case, this shows that...
- ...our testing is still lacking (no qemu-iotests case for live
snapshots? Seriously? Expect it to be broken then.)
- ...not all patch authors do a good share of manual testing
- ...I have relaxed my reviewing too much. I wasn't convinced that this
patch is right, because the whole logic confused me, but I couldn't
point to a bug. I shouldn't have merged it when in doubt.
Jeff, would you like to submit a qemu-iotests case for snapshotting?
Yes, I'll do that.
Benoît, can you check whether the patch below is correct?
Kevin
diff --git a/block.c b/block.c
index ac0ccac..1299484 100644
--- a/block.c
+++ b/block.c
@@ -5412,11 +5412,7 @@ bool bdrv_is_first_non_filter(BlockDriverState
*candidate)
QTAILQ_FOREACH(bs, bdrv_states, device_list) {
bool perm;
-if (!bs-file) {
-continue;
-}
-
-perm = bdrv_recurse_is_first_non_filter(bs-file, candidate);
+perm = bdrv_recurse_is_first_non_filter(bs, candidate);
/* candidate is the first non filter */
if (perm) {
Re: [Qemu-devel] [PATCH V15 02/13] quorum: Create BDRVQuorumState and BlkDriver and do init.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
Reviewed-by: Max Reitz mre...@redhat.com
---
block/quorum.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/block/quorum.c b/block/quorum.c
index 17695d6..157efdf 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -15,6 +15,16 @@
#include block/block_int.h
+/* the following structure holds the state of one quorum instance */
+typedef struct {
The convention is to have both a struct name and a typedef name (and
it should be the same in both places, of course).
+BlockDriverState **bs; /* children BlockDriverStates */
+int total; /* children count */
num_children? total could be anything.
+int threshold; /* if less than threshold children reads gave the
+* same result a quorum error occurs.
+*/
+bool is_blkverify; /* true if the driver is in blkverify mode */
Can you describe in detail, what blkverify mode is?
+} BDRVQuorumState;
+
typedef struct QuorumAIOCB QuorumAIOCB;
/* Quorum will create one instance of the following structure per operation
it
@@ -37,6 +47,7 @@ typedef struct QuorumSingleAIOCB {
*/
struct QuorumAIOCB {
BlockDriverAIOCB common;
+BDRVQuorumState *bqs;
/* Request metadata */
uint64_t sector_num;
@@ -52,3 +63,17 @@ struct QuorumAIOCB {
bool is_read;
int vote_ret;
};
+
+static BlockDriver bdrv_quorum = {
+.format_name= quorum,
+.protocol_name = quorum,
+
+.instance_size = sizeof(BDRVQuorumState),
+};
+
+static void bdrv_quorum_init(void)
+{
+bdrv_register(bdrv_quorum);
+}
+
+block_init(bdrv_quorum_init);
I suspect that trying to use the driver will cause segfaults in this
state (has neither bdrv_open nor bdrv_file_open). But okay, we can live
with that.
Kevin
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
On 02/04/2014 04:06 AM, Daniel P. Berrange wrote: v9fs need use mkdir, remove ... which have MAX_PATH limitation. So if the combined path is longer than MAX_PATH, before it passes to mkdir, remove ..., it has to be truncated just like what rpath() has done. I don't believe you are correct there. Those functions should return errno == ENAMETOOLONG - pathname was too long. The MAX_PATH constant is not even required to exist in POSIX, so I would not expect the spec to mandate anything about MAX_PATH in relation to those functions. Copying Eric who is involved the POSIX spec group to confirm. Correct - POSIX intentionally allows GNU Hurd behavior which is no MAX_PATH. You can use openat() and friends to reduce the path length of an operation you are trying, and there, your limit becomes NAME_MAX (255 on many filesystems, but also a value that POSIX allows to be undefined). POSIX merely requires that the system be consistent - it cannot toggle between ENAMETOOLONG errors through one interface and acting on the name through another. Even if they are limited, it is still better practice to use dynamic allocation for this, over fixed length buffers IMHO. Agreed on two counts - dynamic allocation is essential on platforms where MAX_PATH is undefined and thus where path names can be constructed that occupy longer than a system page (because you do NOT want stack allocations longer than a page); and you WANT to try the system call because an ENAMETOOLONG from the system is definitive whereas giving up early because you only guess that it will be too long or because you used snprintf and truncated the string generally causes confusion. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
On 02/04/2014 05:25 AM, Markus Armbruster wrote:
Second guessing when a pathname is too long for a system call is not a
good idea. If it's too long, the system call will tell you. As Dan
noted, PATH_MAX is *not* a hard limit.
{PATH_MAX}
Maximum number of bytes the implementation will store as a
pathname in a user-supplied buffer of unspecified size,
including the terminating null character. Minimum number the
implementation will accept as the maximum number of bytes in a
pathname.
Linux allows unbelievably long absolute names. Jim Meyering proved with
coreutils that you can create an absolute name well over a megabyte in
length. The trick is that you have to access it via relative names
where each relative name is PATH_MAX or less (that is, the Linux kernel
refuses to operate on more than a page at a time when doing file name
resolution), by using openat() and friends. mkdirat() can create a
directory with an absolute name longer than PATH_MAX, even if mkdir() can't.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
On 02/04/2014 09:12 PM, Eric Blake wrote:
On 02/04/2014 05:25 AM, Markus Armbruster wrote:
Second guessing when a pathname is too long for a system call is not a
good idea. If it's too long, the system call will tell you. As Dan
noted, PATH_MAX is *not* a hard limit.
{PATH_MAX}
Maximum number of bytes the implementation will store as a
pathname in a user-supplied buffer of unspecified size,
including the terminating null character. Minimum number the
implementation will accept as the maximum number of bytes in a
pathname.
Linux allows unbelievably long absolute names. Jim Meyering proved with
coreutils that you can create an absolute name well over a megabyte in
length. The trick is that you have to access it via relative names
where each relative name is PATH_MAX or less (that is, the Linux kernel
refuses to operate on more than a page at a time when doing file name
resolution), by using openat() and friends. mkdirat() can create a
directory with an absolute name longer than PATH_MAX, even if mkdir() can't.
OK, thank all of you, what you said sound reasonable to me. I don't
know why the original author/maintainer did not support 'unlimited'
path, so better to get original authors' opinion.
And can we split current discussion into 2 pieces:
- fix sprintf() bug, can use snprintf() to fix it just like other
places have done -- apply this patch (comments need be improved).
- improve 9pfs features -- support 'unlimited' path internally.
before do it, better to get original authors' response firstly.
I guess, we need change quite a few areas and have a full test.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
Re: [Qemu-devel] KVM call agenda for 2014-02-04
Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. * Should we change anything to get more people to sign for the call? There hasn't been a call in quite a long time. Ideas? Any further discussion here? No topics for this week, so call is cancelled. Later, Juan. Thanks, Juan. Call details: 09:00 AM to 10:00 AM EDT Every two weeks If you need phone number details, contact me privately
Re: [Qemu-devel] [Qemu-ppc] standard test image not booting with qemu-system-ppc
Il 04/02/2014 08:55, Alexander Graf ha scritto:
With this change, the
memory system is now refusing to allow an access of size
2 through, because it's greater than the region length. So
Ouch. Yes, for ioport reads/writes we definitely have to only cap the port
range, not the length.
We can do it in general for MMIO. Something like this?
diff --git a/exec.c b/exec.c
index 9ad0a4b..9a1eef3 100644
--- a/exec.c
+++ b/exec.c
@@ -325,7 +325,7 @@ address_space_translate_internal(AddressSpaceDispatch *d,
hwaddr addr, hwaddr *x
hwaddr *plen, bool resolve_subpage)
{
MemoryRegionSection *section;
-Int128 diff, diff_page;
+Int128 diff;
section = address_space_lookup_region(d, addr, resolve_subpage);
/* Compute offset within MemoryRegionSection */
@@ -334,9 +334,7 @@ address_space_translate_internal(AddressSpaceDispatch *d,
hwaddr addr, hwaddr *x
/* Compute offset within MemoryRegion */
*xlat = addr + section-offset_within_region;
-diff_page = int128_make64(((addr TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) -
addr);
diff = int128_sub(section-mr-size, int128_make64(addr));
-diff = int128_min(diff, diff_page);
*plen = int128_get64(int128_min(diff, int128_make64(*plen)));
return section;
}
@@ -370,6 +368,11 @@ MemoryRegion *address_space_translate(AddressSpace *as,
hwaddr addr,
as = iotlb.target_as;
}
+if (memory_access_is_direct(mr, is_write)) {
+hwaddr page = (addr TARGET_PAGE_MASK) + TARGET_PAGE_SIZE - addr;
+len = MIN(page, len);
+}
+
*plen = len;
*xlat = addr;
return mr;
Stefano, Anthony, can you test it on Xen?
I wouldn't mind sticking a xen_enabled() in there, and/or a comment to
document
why we do it.
Paolo
Re: [Qemu-devel] [PATCH V15 03/13] quorum: Add quorum_aio_writev and its dependencies.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block/quorum.c | 104
+
1 file changed, 104 insertions(+)
Starting with writes before the driver can even open an image is a weird
order to do things in. It also doesn't make the review any easier when
you don't know how things are initialised.
diff --git a/block/quorum.c b/block/quorum.c
index 157efdf..81bffdd 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -64,11 +64,115 @@ struct QuorumAIOCB {
int vote_ret;
};
+static void quorum_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+QuorumAIOCB *acb = container_of(blockacb, QuorumAIOCB, common);
+BDRVQuorumState *s = acb-bqs;
+int i;
+
+/* cancel all callback */
callbacks
+for (i = 0; i s-total; i++) {
+bdrv_aio_cancel(acb-aios[i].aiocb);
+}
+}
Don't you want to free acb and similar cleanup?
+
+static AIOCBInfo quorum_aiocb_info = {
+.aiocb_size = sizeof(QuorumAIOCB),
+.cancel = quorum_aio_cancel,
+};
+
+static void quorum_aio_finalize(QuorumAIOCB *acb)
+{
+BDRVQuorumState *s = acb-bqs;
block/quorum.c: In function 'quorum_aio_finalize':
block/quorum.c:86:22: error: unused variable 's' [-Werror=unused-variable]
+int ret = 0;
+
+acb-common.cb(acb-common.opaque, ret);
+if (acb-finished) {
+*acb-finished = true;
+}
+g_free(acb-aios);
+qemu_aio_release(acb);
+}
+
+static QuorumAIOCB *quorum_aio_get(BDRVQuorumState *s,
+ BlockDriverState *bs,
+ QEMUIOVector *qiov,
+ uint64_t sector_num,
+ int nb_sectors,
+ BlockDriverCompletionFunc *cb,
+ void *opaque)
+{
+QuorumAIOCB *acb = qemu_aio_get(quorum_aiocb_info, bs, cb, opaque);
+int i;
+
+acb-bqs = s;
Noticed it only here, but it's really in patch 2 (and should be in
patch 1):
What is acb-bqs good for? Isn't it always the same as
acb-common.bs-opaque?
+acb-sector_num = sector_num;
+acb-nb_sectors = nb_sectors;
+acb-qiov = qiov;
+acb-aios = g_new0(QuorumSingleAIOCB, s-total);
+acb-count = 0;
+acb-success_count = 0;
+acb-finished = NULL;
+acb-is_read = false;
+acb-vote_ret = 0;
+
+for (i = 0; i s-total; i++) {
+acb-aios[i].buf = NULL;
+acb-aios[i].ret = 0;
+acb-aios[i].parent = acb;
+}
+
+return acb;
+}
Kevin
Re: [Qemu-devel] [PATCH v2 1/4] target-mips: add CPU definition for MIPS32R5
ping
http://patchwork.ozlabs.org/patch/313937/
http://patchwork.ozlabs.org/patch/313938/
http://patchwork.ozlabs.org/patch/313944/
http://patchwork.ozlabs.org/patch/313936/
Regards,
Petar
From: Petar Jovanovic [petar.jovano...@rt-rk.com]
Sent: Friday, January 24, 2014 5:18 PM
To: qemu-devel@nongnu.org
Cc: Petar Jovanovic; aurel...@aurel32.net
Subject: [PATCH v2 1/4] target-mips: add CPU definition for MIPS32R5
From: Petar Jovanovic petar.jovano...@imgtec.com
Add mips32r5-generic among CPU definitions for MIPS.
Define ISA_MIPS32R3 and ISA_MIPS32R5.
Signed-off-by: Petar Jovanovic petar.jovano...@imgtec.com
---
target-mips/mips-defs.h |8
target-mips/translate_init.c | 25 +
2 files changed, 33 insertions(+)
diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h
index bf094a3..9dfa516 100644
--- a/target-mips/mips-defs.h
+++ b/target-mips/mips-defs.h
@@ -29,6 +29,8 @@
#defineISA_MIPS32R20x0040
#defineISA_MIPS64 0x0080
#defineISA_MIPS64R20x0100
+#define ISA_MIPS32R3 0x0200
+#define ISA_MIPS32R5 0x0400
/* MIPS ASEs. */
#defineASE_MIPS16 0x1000
@@ -64,6 +66,12 @@
#defineCPU_MIPS32R2(CPU_MIPS32 | ISA_MIPS32R2)
#defineCPU_MIPS64R2(CPU_MIPS64 | CPU_MIPS32R2 |
ISA_MIPS64R2)
+/* MIPS Technologies Release 3 */
+#define CPU_MIPS32R3 (CPU_MIPS32R2 | ISA_MIPS32R3)
+
+/* MIPS Technologies Release 5 */
+#define CPU_MIPS32R5 (CPU_MIPS32R3 | ISA_MIPS32R5)
+
/* Strictly follow the architecture standard:
- Disallow special instruction handling for PMON/SPIM.
Note that we still maintain Count/Compare to match the host clock. */
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index c45b1b2..d74a0af 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -333,6 +333,31 @@ static const mips_def_t mips_defs[] =
.insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_DSPR2,
.mmu_type = MMU_TYPE_R4000,
},
+{
+/* A generic CPU providing MIPS32 Release 5 features.
+ FIXME: Eventually this should be replaced by a real CPU model. */
+.name = mips32r5-generic,
+.CP0_PRid = 0x00019700,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
+(MMU_TYPE_R4000 CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (1 CP0C1_FP) | (15 CP0C1_MMU) |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA) |
+ (1 CP0C1_CA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3,
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 4,
+.SYNCI_Step = 32,
+.CCRes = 2,
+.CP0_Status_rw_bitmask = 0x3778FF1F,
+.CP1_fcr0 = (1 FCR0_F64) | (1 FCR0_L) | (1 FCR0_W) |
+(1 FCR0_D) | (1 FCR0_S) | (0x93 FCR0_PRID),
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R5 | ASE_MIPS16 | ASE_DSP | ASE_DSPR2,
+.mmu_type = MMU_TYPE_R4000,
+},
#if defined(TARGET_MIPS64)
{
.name = R4000,
--
1.7.9.5
Re: [Qemu-devel] [PATCH V15 04/13] blkverify: Extract qemu_iovec_clone() and qemu_iovec_compare() from blkverify.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
Reviewed-by: Max Reitz mre...@redhat.com
---
block/blkverify.c | 108
+-
include/qemu-common.h | 2 +
util/iov.c| 103 +++
3 files changed, 107 insertions(+), 106 deletions(-)
--- a/util/iov.c
+++ b/util/iov.c
@@ -378,6 +378,109 @@ size_t qemu_iovec_memset(QEMUIOVector *qiov, size_t
offset,
return iov_memset(qiov-iov, qiov-niov, offset, fillc, bytes);
}
+/**
+ * Check that I/O vector contents are identical
+ *
+ * @a: I/O vector
+ * @b: I/O vector
+ * @ret:Offset to first mismatching byte or -1 if match
+ */
Perhaps we should update the documentation to state explicitly that the
I/O vectors must have the same structure (i.e. same length of all parts)
and that you should therefore only use it on vectors previously created
with qemu_iovec_clone().
+ssize_t qemu_iovec_compare(QEMUIOVector *a, QEMUIOVector *b)
+{
+int i;
+ssize_t offset = 0;
+
+assert(a-niov == b-niov);
+for (i = 0; i a-niov; i++) {
+size_t len = 0;
+uint8_t *p = (uint8_t *)a-iov[i].iov_base;
+uint8_t *q = (uint8_t *)b-iov[i].iov_base;
+
+assert(a-iov[i].iov_len == b-iov[i].iov_len);
+while (len a-iov[i].iov_len *p++ == *q++) {
+len++;
+}
+
+offset += len;
+
+if (len != a-iov[i].iov_len) {
+return offset;
+}
+}
+return -1;
+}
Kevin
Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models
Am 03.02.2014 20:01, schrieb Eduardo Habkost: On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote: Il 21/01/2014 16:51, Andreas Färber ha scritto: We already do that for other bits (e.g. XSAVE/OSXSAVE), Please point me to the commit, a search for xsave did not come up with a commit changing such a thing - either it did not go through my queue or it slipped me through: Bugs are no excuse to produce more bugs. I meant that -cpu SandyBridge with TCG produces a CPU that doesn't have XSAVE. and in fact it is the same that we do for KVM: the KVM_GET_SUPPORTED_CPUID result is used to trim the generic feature bits. Our model definitions are the place to put stuff that real CPUs have. Either the CPU has it or it doesn't. If it does, then this patch is fully correct and it's TCG's job to mask things out. If we're adding artificial flags to the generic model definitions just to make KVM faster, then it is wrong - we have a choice of post_initialize and realize hooks for that. It would make TCG faster as well, and there would be no reason really to avoid the artificial x2apic on TCG, if TCG implemented x2apic at all. So, the discussion seem to have stalled. Andreas, are you still against the patch, after the arguments from Paolo and me? Yes, I am. I had proposed to discuss solutions at FOSDEM but Paolo was not there, so no solution yet. My main concern still is that if a CPU does not have a certain feature we should not list it as one of its features but add it to its features where sensible. Just because TCG filters it out today is not keeping anyone from implementing it tomorrow, in which case the emulated CPUs would suddenly gain the feature. So my question still is, what rule can we apply for enabling x2apic? (something like greater or equal this family, etc. - then we can put it in your post_initialize hook so that users can still override it) Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH V15 05/13] quorum: Add quorum_aio_readv.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
Reviewed-by: Max Reitz mre...@redhat.com
---
block/quorum.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/block/quorum.c b/block/quorum.c
index 81bffdd..699b512 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -86,10 +86,19 @@ static void quorum_aio_finalize(QuorumAIOCB *acb)
BDRVQuorumState *s = acb-bqs;
int ret = 0;
+for (i = 0; i s-total; i++) {
+qemu_vfree(acb-aios[i].buf);
+acb-aios[i].buf = NULL;
+acb-aios[i].ret = 0;
You free acb-aios anyway, no point in clearing the fields.
+}
+
acb-common.cb(acb-common.opaque, ret);
if (acb-finished) {
*acb-finished = true;
}
+for (i = 0; acb-is_read i s-total; i++) {
As Max noted, pulling acb-is_read into the for loop condition is
clever. Code being unnecessarily clever is usually bad.
+qemu_iovec_destroy(acb-aios[i].qiov);
+}
Any reason to have two separate for loops? I can't see one why the qiov
should be any longer valid than the data in it. I also can't see the
reason for the different conditions, other than qemu_vfree() being a
no-op for writes.
Keep it simple:
if (acb-is_read) {
for (i = 0; i s-total; i++) {
qemu_vfree(acb-aios[i].buf);
qemu_iovec_destroy(acb-aios[i].qiov);
}
}
It's shorter, less clever and more readable than your version.
g_free(acb-aios);
qemu_aio_release(acb);
}
@@ -145,6 +154,34 @@ static void quorum_aio_cb(void *opaque, int ret)
quorum_aio_finalize(acb);
}
+static BlockDriverAIOCB *quorum_aio_readv(BlockDriverState *bs,
+ int64_t sector_num,
+ QEMUIOVector *qiov,
+ int nb_sectors,
+ BlockDriverCompletionFunc *cb,
+ void *opaque)
+{
+BDRVQuorumState *s = bs-opaque;
+QuorumAIOCB *acb = quorum_aio_get(s, bs, qiov, sector_num,
+ nb_sectors, cb, opaque);
+int i;
+
+acb-is_read = true;
+
+for (i = 0; i s-total; i++) {
+acb-aios[i].buf = qemu_blockalign(bs-file, qiov-size);
Shouldn't this be s-bs[i] instead of bs-file?
+qemu_iovec_init(acb-aios[i].qiov, qiov-niov);
+qemu_iovec_clone(acb-aios[i].qiov, qiov, acb-aios[i].buf);
+}
+
+for (i = 0; i s-total; i++) {
+bdrv_aio_readv(s-bs[i], sector_num, qiov, nb_sectors,
+ quorum_aio_cb, acb-aios[i]);
+}
+
+return acb-common;
+}
+
static BlockDriverAIOCB *quorum_aio_writev(BlockDriverState *bs,
int64_t sector_num,
QEMUIOVector *qiov,
@@ -172,6 +209,7 @@ static BlockDriver bdrv_quorum = {
.instance_size = sizeof(BDRVQuorumState),
+.bdrv_aio_readv = quorum_aio_readv,
.bdrv_aio_writev= quorum_aio_writev,
};
Kevin
Re: [Qemu-devel] Commit 9e047b982452c633882b486682966c1d97097015 (piix4: add acpi pci hotplug support) seems to break Xen pci-passthrough
On Tue, Feb 04, 2014 at 12:46:08AM +0100, Sander Eikelenboom wrote: Grmbll my fat fingers hit the send shortcut too soon by accident .. let's try again .. Hi Michael, A git bisect turned out that commit 9e047b982452c633882b486682966c1d97097015 breaks pci-passthrough on Xen. commit 9e047b982452c633882b486682966c1d97097015 Author: Michael S. Tsirkin m...@redhat.com Date: Mon Oct 14 18:01:20 2013 +0300 piix4: add acpi pci hotplug support Add support for acpi pci hotplug using the new infrastructure. PIIX4 legacy interface is maintained as is for machine types 1.7 and older. Signed-off-by: Michael S. Tsirkin m...@redhat.com The error is not very verbose : libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. So it seems there is an issue with preserving the legacy interface. Which machine type is broken? What's the command line used? What's the value of has_acpi_build in hw/i386/pc_piix.c? What happens if you add -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off ? -- Sander
Re: [Qemu-devel] [PATCH] misc: Fix case Qemu - QEMU
Am 04.02.2014 06:43, schrieb Stefan Weil: Signed-off-by: Stefan Weil s...@weilnetz.de --- scripts/switch-timer-api |2 +- tests/i440fx-test.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Andreas Färber afaer...@suse.de but that is the same spelling found in every single mailing list message - any chance we can fix that too? (be it to all-lowercase or all-uppercase) Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [Qemu-ppc] standard test image not booting with qemu-system-ppc
On Tue, 4 Feb 2014, Paolo Bonzini wrote:
Il 04/02/2014 08:55, Alexander Graf ha scritto:
With this change, the
memory system is now refusing to allow an access of size
2 through, because it's greater than the region length. So
Ouch. Yes, for ioport reads/writes we definitely have to only cap the port
range, not the length.
We can do it in general for MMIO. Something like this?
diff --git a/exec.c b/exec.c
index 9ad0a4b..9a1eef3 100644
--- a/exec.c
+++ b/exec.c
@@ -325,7 +325,7 @@ address_space_translate_internal(AddressSpaceDispatch *d,
hwaddr addr, hwaddr *x
hwaddr *plen, bool resolve_subpage)
{
MemoryRegionSection *section;
-Int128 diff, diff_page;
+Int128 diff;
section = address_space_lookup_region(d, addr, resolve_subpage);
/* Compute offset within MemoryRegionSection */
@@ -334,9 +334,7 @@ address_space_translate_internal(AddressSpaceDispatch *d,
hwaddr addr, hwaddr *x
/* Compute offset within MemoryRegion */
*xlat = addr + section-offset_within_region;
-diff_page = int128_make64(((addr TARGET_PAGE_MASK) + TARGET_PAGE_SIZE)
- addr);
diff = int128_sub(section-mr-size, int128_make64(addr));
-diff = int128_min(diff, diff_page);
*plen = int128_get64(int128_min(diff, int128_make64(*plen)));
return section;
}
@@ -370,6 +368,11 @@ MemoryRegion *address_space_translate(AddressSpace *as,
hwaddr addr,
as = iotlb.target_as;
}
+if (memory_access_is_direct(mr, is_write)) {
+hwaddr page = (addr TARGET_PAGE_MASK) + TARGET_PAGE_SIZE - addr;
+len = MIN(page, len);
+}
+
*plen = len;
*xlat = addr;
return mr;
Stefano, Anthony, can you test it on Xen?
I wouldn't mind sticking a xen_enabled() in there, and/or a comment to
document
why we do it.
The patch looks OK as it is, let's see how Anthony's tests turn out.
Re: [Qemu-devel] migration: broken ram_save_pending
Il 04/02/2014 13:16, Alexey Kardashevskiy ha scritto: On 02/04/2014 11:07 PM, Paolo Bonzini wrote: Il 04/02/2014 12:59, Alexey Kardashevskiy ha scritto: With the default throttling of 32 MiB/s, bandwidth must be something like 33000 (expressed in bytes/ms) with the default settings, and then max_size should be 33000*3*10^9 / 10^6 = 600. Where is my computation wrong? migrate_max_downtime() = 3000 = 3*10^7. Oops, that's the mistake. Make a patch? :) I mean, my mistake. :) I assumed 3000 ms = 3*10^9. 30 ms is too little, but 3000 ms is probably too much for a default. When the migration is in iterating stage, bandwidth is a speed in last 100ms which is usually 5 blocks 250KB each so it is 125/100=12500bytes/s and max_size=12500*3000/10^6=375000 which is less than the last chunk is. Perhaps our default maximum downtime is too low. 30 ms doesn't seem achievable in practice with 32 MiB/s bandwidth. Just making it 300 ms or so should fix your problem. Well, it will fix it in my particular case but in a long run this does not feel like a fix - there should be a way for migration_thread() to know that ram_save_iterate() sent all dirty pages it had to send, no? No, because new pages might be dirtied while ram_save_iterate() was running. Paolo
Re: [Qemu-devel] [PATCH 00/12] trace: [tcg] Allow tracing guest events in TCG-generated code
On 4 February 2014 14:57, Richard Henderson r...@twiddle.net wrote: I suppose I have no major objection to the feature, although frankly it's not especially exciting. I can't really imagine ever wanting to bulk trace all of the helpers. Tracing specific helpers on a target-by-target basis, sure. But that can be done just as easily as adding tracing code to any other bit of C. I think the things people seem to actually want (judging from occasional postings to the list) are things like: * trace all guest memory accesses * trace all guest instruction executions Does this patchset get us usefully towards that kind of thing? Not sure... thanks -- PMM
Re: [Qemu-devel] [PATCH 4/6] XBZRLE cache size should not be larger than guest memory size
Orit Wasserman owass...@redhat.com wrote: Signed-off-by: Orit Wasserman owass...@redhat.com Reviewed-by: Juan Quintela quint...@redhat.com
Re: [Qemu-devel] Commit 9e047b982452c633882b486682966c1d97097015 (piix4: add acpi pci hotplug support) seems to break Xen pci-passthrough
Tuesday, February 4, 2014, 3:32:19 PM, you wrote: On Tue, Feb 04, 2014 at 12:46:08AM +0100, Sander Eikelenboom wrote: Grmbll my fat fingers hit the send shortcut too soon by accident .. let's try again .. Hi Michael, A git bisect turned out that commit 9e047b982452c633882b486682966c1d97097015 breaks pci-passthrough on Xen. commit 9e047b982452c633882b486682966c1d97097015 Author: Michael S. Tsirkin m...@redhat.com Date: Mon Oct 14 18:01:20 2013 +0300 piix4: add acpi pci hotplug support Add support for acpi pci hotplug using the new infrastructure. PIIX4 legacy interface is maintained as is for machine types 1.7 and older. Signed-off-by: Michael S. Tsirkin m...@redhat.com The error is not very verbose : libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. So it seems there is an issue with preserving the legacy interface. Which machine type is broken? xenfv What's the command line used? See below the output of the creation of the guest Strange thing is: char device redirected to /dev/pts/15 (label serial0) vgabios-cirrus.bin: ROM id 101300b8 / PCI id 101300b8 efi-e1000.rom: ROM id 8086100e / PCI id 8086100e VNC server running on `127.0.0.1:5900' xen_platform: changed ro/rw state of ROM memory area. now is rw state. [00:05.0] xen_pt_initfn: Assigning real physical device 06:01.0 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x1000 base_addr=0xfe0fd000 type: 0) [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_initfn: Real physical device 06:01.0 registered successfully! [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_initfn: Assigning real physical device 06:01.1 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x1000 base_addr=0xfe0fe000 type: 0) [00:05.0] xen_pt_pci_intx: intx=2 [00:05.0] xen_pt_initfn: Real physical device 06:01.1 registered successfully! [00:05.0] xen_pt_pci_intx: intx=2 [00:05.0] xen_pt_initfn: Assigning real physical device 06:01.2 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0100 base_addr=0xfe0ffc00 type: 0) [00:05.0] xen_pt_pci_intx: intx=3 [00:05.0] xen_pt_initfn: Real physical device 06:01.2 registered successfully! [00:05.0] xen_pt_pci_intx: intx=3 [00:05.0] xen_pt_initfn: Assigning real physical device 08:00.0 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0020 base_addr=0xfe20 type: 0x4) [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_initfn: Real physical device 08:00.0 registered successfully! [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_msi_set_enable: disabling MSI. It's does log succes for registering the pci devices .. however it returns by qmp that the device initialization failed. And an lspci in the guest also doesn't show the devices. What's the value of has_acpi_build in hw/i386/pc_piix.c? static bool has_acpi_build = true; What happens if you add -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off That makes it work again ... -- Sander Parsing config from /etc/xen/domU/production/security.cfg libxl: debug: libxl_create.c:1348:do_domain_create: ao 0x1415900: create: how=(nil) callback=(nil) poller=0x1415960 libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hdb spec.backend=unknown libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=hdb, using backend phy libxl: debug: libxl_create.c:803:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x1415ce8: deregister unregistered xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x9efa8 xc: detail: elf_parse_binary: memory: 0x10 - 0x19efa8 xc: detail: VIRTUAL MEMORY ARRANGEMENT: Loader:0010-0019efa8 Modules: - TOTAL: -3f80 ENTRY ADDRESS: 0010 xc: detail: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0200 2MB PAGES: 0x01fb 1GB PAGES: 0x xc: detail: elf_load_binary: phdr 0 at 0x7fdc08ee7000 - 0x7fdc08f7ce2d libxl: debug:
Re: [Qemu-devel] [PATCH] exec: fix ram_list dirty map optimization
Alexey Kardashevskiy a...@ozlabs.ru wrote: The ae2810c4bb3b383176e8e1b33931b16c01483aab patch introduced optimization for ram_list.dirty_memory update. However it can only work correctly if hpratio is 1 as the @bitmap parameter stores 1 bits per system page size (may vary, 4K or 64K on PPC64) and ram_list.dirty_memory stores 1 bit per TARGET_PAGE_SIZE (which is hardcoded to 4K). This fixes hpratio!=1 case to fall back to the slow path. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: Juan Quintela quint...@redhat.com
Re: [Qemu-devel] [PATCH 00/12] trace: [tcg] Allow tracing guest events in TCG-generated code
On 01/31/2014 08:09 AM, Lluís Vilanova wrote:
Adds the base ability to specify which events in the trace-events file may
be
used to trace guest activity in the TCG code (using the tcg event propery).
Such events generate an extra set of tracing functions that can be called
during
TCG code generation and will automatically redirect a call to the appropriate
backend-dependent tracing functions when the guest code is executed.
Files generating guest code (TCG) must include trace-tcg.h. Files declaring
per-target helpers (${target}/helper.h) must include
trace/generated-helpers.h.
The flow of the generated routines is:
[At translation time]
* trace_${name}_tcg(bool, TCGv)
Declared: trace/generated-tcg-tracers.h
Defined : trace/generated-tcg-tracers.h
* gen_helper_trace_${name}_tcg(bool, TCGv)
Declared: trace/generated-helpers.h
Defined : trace/generated-helpers.h
Automatically transforms all the arguments and allocates them into the
appropriate TCG temporary values (which are also freed). Provides a more
streamlined interface by allowing events in trace-events to take a mix of
tracing-supported types and TCG types.
* gen_helper_trace_${name}_tcg_proxy(TCGi32, TCGv)
Declared: trace/generated-helpers.h
Defined : trace/generated-helpers.h (using helper machinery)
The actual TCG helper function, created using QEMU's TCG helper machinery.
I suppose I have no major objection to the feature, although frankly it's
not especially exciting. I can't really imagine ever wanting to bulk trace
all of the helpers. Tracing specific helpers on a target-by-target basis,
sure. But that can be done just as easily as adding tracing code to any
other bit of C.
If I read these patches right -- and since they're mostly python I'm not
sure that I am -- we go through 5 layers of wrappers to get to the current
trace_foo expansion. Where trace_foo contains the check to see whether the
tracepoint is actually enabled.
I would strongly suggest this is backward. One should perform the check for
the tracepoint being enabled at translation time before emitting the call to
the helper in the first place.
r~
Re: [Qemu-devel] Commit 9e047b982452c633882b486682966c1d97097015 (piix4: add acpi pci hotplug support) seems to break Xen pci-passthrough
On Tue, 4 Feb 2014 16:07:08 +0100
Sander Eikelenboom li...@eikelenboom.it wrote:
Tuesday, February 4, 2014, 3:32:19 PM, you wrote:
On Tue, Feb 04, 2014 at 12:46:08AM +0100, Sander Eikelenboom wrote:
Grmbll my fat fingers hit the send shortcut too soon by accident ..
let's try again ..
Hi Michael,
A git bisect turned out that commit
9e047b982452c633882b486682966c1d97097015 breaks pci-passthrough on Xen.
commit 9e047b982452c633882b486682966c1d97097015
Author: Michael S. Tsirkin m...@redhat.com
Date: Mon Oct 14 18:01:20 2013 +0300
piix4: add acpi pci hotplug support
Add support for acpi pci hotplug using the
new infrastructure.
PIIX4 legacy interface is maintained as is for
machine types 1.7 and older.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
The error is not very verbose :
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
message from QMP server: Device initialization failed.
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
message from QMP server: Device initialization failed.
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
message from QMP server: Device initialization failed.
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error
message from QMP server: Device initialization failed.
So it seems there is an issue with preserving the legacy interface.
Which machine type is broken?
xenfv
What's the command line used?
See below the output of the creation of the guest
Strange thing is:
char device redirected to /dev/pts/15 (label serial0)
vgabios-cirrus.bin: ROM id 101300b8 / PCI id 101300b8
efi-e1000.rom: ROM id 8086100e / PCI id 8086100e
VNC server running on `127.0.0.1:5900'
xen_platform: changed ro/rw state of ROM memory area. now is rw state.
[00:05.0] xen_pt_initfn: Assigning real physical device 06:01.0 to devfn 0x28
[00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x1000
base_addr=0xfe0fd000 type: 0)
[00:05.0] xen_pt_pci_intx: intx=1
[00:05.0] xen_pt_initfn: Real physical device 06:01.0 registered successfully!
[00:05.0] xen_pt_pci_intx: intx=1
[00:05.0] xen_pt_initfn: Assigning real physical device 06:01.1 to devfn 0x28
[00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x1000
base_addr=0xfe0fe000 type: 0)
[00:05.0] xen_pt_pci_intx: intx=2
[00:05.0] xen_pt_initfn: Real physical device 06:01.1 registered successfully!
[00:05.0] xen_pt_pci_intx: intx=2
[00:05.0] xen_pt_initfn: Assigning real physical device 06:01.2 to devfn 0x28
[00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0100
base_addr=0xfe0ffc00 type: 0)
[00:05.0] xen_pt_pci_intx: intx=3
[00:05.0] xen_pt_initfn: Real physical device 06:01.2 registered successfully!
[00:05.0] xen_pt_pci_intx: intx=3
[00:05.0] xen_pt_initfn: Assigning real physical device 08:00.0 to devfn 0x28
[00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0020
base_addr=0xfe20 type: 0x4)
[00:05.0] xen_pt_pci_intx: intx=1
[00:05.0] xen_pt_initfn: Real physical device 08:00.0 registered successfully!
[00:05.0] xen_pt_pci_intx: intx=1
[00:05.0] xen_pt_msi_set_enable: disabling MSI.
It's does log succes for registering the pci devices .. however it returns by
qmp that the device initialization failed.
And an lspci in the guest also doesn't show the devices.
What's the value of has_acpi_build in hw/i386/pc_piix.c?
static bool has_acpi_build = true;
What happens if you add
-global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off
That makes it work again ...
looks like missing bsel property,
could you run qemu with following debug patch to make sure that it's the case:
(run without -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off)
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 4345f5d..fc72cc9 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -192,6 +192,7 @@ int acpi_pcihp_device_hotplug(AcpiPciHpState *s, PCIDevice
*dev, {
int slot = PCI_SLOT(dev-devfn);
int bsel = acpi_pcihp_get_bsel(dev-bus);
+fprintf(stderr, bsel: %d, bus: %s\n, bsel, dev-bus-qbus.name);
if (bsel 0) {
return -1;
}
--
Sander
Parsing config from /etc/xen/domU/production/security.cfg
libxl: debug: libxl_create.c:1348:do_domain_create: ao 0x1415900: create:
how=(nil) callback=(nil) poller=0x1415960
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk
vdev=hda, using backend phy
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk
vdev=hdb spec.backend=unknown
libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk
vdev=hdb, using backend phy
libxl: debug: libxl_create.c:803:initiate_domain_create: running
Re: [Qemu-devel] [Xen-devel] [BUGFIX][PATCH v2] configure: Disable libtool if -fPIE does not work with it (bug #1257099)
Il 03/02/2014 12:59, Stefano Stabellini ha scritto:
On Wed, 15 Jan 2014, Paolo Bonzini wrote:
Il 03/01/2014 03:12, Don Slutz ha scritto:
Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names
to be fixed (TMPB).
Add new functions do_libtool and libtool_prog.
Add check for broken gcc and libtool.
Signed-off-by: Don Slutz dsl...@verizon.com
---
Was posted as an attachment.
https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html
configure | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index edfea95..852d021 100755
--- a/configure
+++ b/configure
@@ -12,7 +12,10 @@ else
fi
TMPC=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c
-TMPO=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o
+TMPB=qemu-conf-${RANDOM}-$$-${RANDOM}
+TMPO=${TMPDIR1}/${TMPB}.o
+TMPL=${TMPDIR1}/${TMPB}.lo
+TMPA=${TMPDIR1}/lib${TMPB}.la
TMPE=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe
# NB: do not call exit in the trap handler; this is buggy with some shells;
@@ -86,6 +89,38 @@ compile_prog() {
do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags
}
+do_libtool() {
+local mode=$1
+shift
+# Run the compiler, capturing its output to the log.
+echo $libtool $mode --tag=CC $cc $@ config.log
+$libtool $mode --tag=CC $cc $@ config.log 21 || return $?
+# Test passed. If this is an --enable-werror build, rerun
+# the test with -Werror and bail out if it fails. This
+# makes warning-generating-errors in configure test code
+# obvious to developers.
+if test $werror != yes; then
+return 0
+fi
+# Don't bother rerunning the compile if we were already using -Werror
+case $* in
+*-Werror*)
+ return 0
+;;
+esac
+echo $libtool $mode --tag=CC $cc -Werror $@ config.log
+$libtool $mode --tag=CC $cc -Werror $@ config.log 21 return $?
+error_exit configure test passed without -Werror but failed with
-Werror. \
+This is probably a bug in the configure script. The failing command \
+will be at the bottom of config.log. \
+You can run configure with --disable-werror to bypass this check.
+}
+
+libtool_prog() {
+do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC ||
return $?
+do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib
+}
+
# symbolically link $1 to $2. Portable version of ln -sf.
symlink() {
rm -rf $2
@@ -1367,6 +1402,32 @@ EOF
fi
fi
+# check for broken gcc and libtool in RHEL5
+if test -n $libtool -a $pie != no ; then
+ cat $TMPC EOF
+
+void *f(unsigned char *buf, int len);
+void *g(unsigned char *buf, int len);
+
+void *
+f(unsigned char *buf, int len)
+{
+return (void*)0L;
+}
+
+void *
+g(unsigned char *buf, int len)
+{
+return f(buf, len);
+}
+
+EOF
+ if ! libtool_prog; then
+echo Disabling libtool due to broken toolchain support
+libtool=
+ fi
+fi
+
##
# __sync_fetch_and_and requires at least -march=i486. Many toolchains
# use i686 as default anyway, but for those that don't, an explicit
I'm applying this to a configure branch on my github repository. Thanks!
Paolo, did this patch ever make it upstream? If so, do you have a commit
id?
I searched it on upstream qemu git (master branch now with qemu 2.0 in
development) and I not found it.
___
Xen-devel mailing list
xen-de...@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Qemu-devel] [PATCH 6/6] Don't abort on memory allocation error
Orit Wasserman owass...@redhat.com wrote: It is better to fail migration in case of failure to allocate new cache item Signed-off-by: Orit Wasserman owass...@redhat.com Reviewed-by: Juan Quintela quint...@redhat.com
[Qemu-devel] [PATCH 8/8] exec: fix ram_list dirty map optimization
From: Alexey Kardashevskiy a...@ozlabs.ru
The ae2810c4bb3b383176e8e1b33931b16c01483aab patch introduced
optimization for ram_list.dirty_memory update. However it can only
work correctly if hpratio is 1 as the @bitmap parameter stores 1 bits
per system page size (may vary, 4K or 64K on PPC64) and
ram_list.dirty_memory stores 1 bit per TARGET_PAGE_SIZE
(which is hardcoded to 4K).
This fixes hpratio!=1 case to fall back to the slow path.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: Juan Quintela quint...@redhat.com
---
include/exec/ram_addr.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 481a447..2edfa96 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -93,7 +93,8 @@ static inline void
cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
unsigned long page = BIT_WORD(start TARGET_PAGE_BITS);
/* start address is aligned at the start of a word? */
-if (((page * BITS_PER_LONG) TARGET_PAGE_BITS) == start) {
+if page * BITS_PER_LONG) TARGET_PAGE_BITS) == start)
+(hpratio == 1)) {
long k;
long nr = BITS_TO_LONGS(pages);
--
1.8.5.3
[Qemu-devel] [PATCH 4/8] migration:fix free XBZRLE decoded_buf wrong
From: Gonglei (Arei) arei.gong...@huawei.com
When qemu do live migration with xbzrle, qemu malloc decoded_buf
at destination end but free it at source end. It will crash qemu
by double free error in some scenarios. Splitting the XBZRLE structure
for clear logic distinguishing src/dst side.
Signed-off-by: ChenLiang chenlian...@huawei.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Orit Wasserman owass...@redhat.com
Signed-off-by: GongLei arei.gong...@huawei.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
arch_init.c | 22 --
include/migration/migration.h | 1 +
migration.c | 1 +
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 8edeabe..5eff80b 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -164,17 +164,15 @@ static struct {
uint8_t *encoded_buf;
/* buffer for storing page content */
uint8_t *current_buf;
-/* buffer used for XBZRLE decoding */
-uint8_t *decoded_buf;
/* Cache for XBZRLE */
PageCache *cache;
} XBZRLE = {
.encoded_buf = NULL,
.current_buf = NULL,
-.decoded_buf = NULL,
.cache = NULL,
};
-
+/* buffer used for XBZRLE decoding */
+static uint8_t *xbzrle_decoded_buf;
int64_t xbzrle_cache_resize(int64_t new_size)
{
@@ -606,6 +604,12 @@ uint64_t ram_bytes_total(void)
return total;
}
+void free_xbzrle_decoded_buf(void)
+{
+g_free(xbzrle_decoded_buf);
+xbzrle_decoded_buf = NULL;
+}
+
static void migration_end(void)
{
if (migration_bitmap) {
@@ -619,11 +623,9 @@ static void migration_end(void)
g_free(XBZRLE.cache);
g_free(XBZRLE.encoded_buf);
g_free(XBZRLE.current_buf);
-g_free(XBZRLE.decoded_buf);
XBZRLE.cache = NULL;
XBZRLE.encoded_buf = NULL;
XBZRLE.current_buf = NULL;
-XBZRLE.decoded_buf = NULL;
}
}
@@ -814,8 +816,8 @@ static int load_xbzrle(QEMUFile *f, ram_addr_t addr, void
*host)
unsigned int xh_len;
int xh_flags;
-if (!XBZRLE.decoded_buf) {
-XBZRLE.decoded_buf = g_malloc(TARGET_PAGE_SIZE);
+if (!xbzrle_decoded_buf) {
+xbzrle_decoded_buf = g_malloc(TARGET_PAGE_SIZE);
}
/* extract RLE header */
@@ -832,10 +834,10 @@ static int load_xbzrle(QEMUFile *f, ram_addr_t addr, void
*host)
return -1;
}
/* load data and decode */
-qemu_get_buffer(f, XBZRLE.decoded_buf, xh_len);
+qemu_get_buffer(f, xbzrle_decoded_buf, xh_len);
/* decode RLE */
-ret = xbzrle_decode_buffer(XBZRLE.decoded_buf, xh_len, host,
+ret = xbzrle_decode_buffer(xbzrle_decoded_buf, xh_len, host,
TARGET_PAGE_SIZE);
if (ret == -1) {
fprintf(stderr, Failed to load XBZRLE page - decode error!\n);
diff --git a/include/migration/migration.h b/include/migration/migration.h
index bfa3951..3e1e6c7 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -109,6 +109,7 @@ MigrationState *migrate_get_current(void);
uint64_t ram_bytes_remaining(void);
uint64_t ram_bytes_transferred(void);
uint64_t ram_bytes_total(void);
+void free_xbzrle_decoded_buf(void);
void acct_update_position(QEMUFile *f, size_t size, bool zero);
diff --git a/migration.c b/migration.c
index 84587e9..46a7305 100644
--- a/migration.c
+++ b/migration.c
@@ -105,6 +105,7 @@ static void process_incoming_migration_co(void *opaque)
ret = qemu_loadvm_state(f);
qemu_fclose(f);
+free_xbzrle_decoded_buf();
if (ret 0) {
fprintf(stderr, load of migration failed\n);
exit(EXIT_FAILURE);
--
1.8.5.3
Re: [Qemu-devel] osx pci vs. 99fd437dee468609de8218f0eb3b16621fb6a9c9
On Mon, Feb 03, 2014 at 04:23:34PM -0500, Gabriel L. Somlo wrote:
Michael,
Prior to commit 99fd437dee468609de8218f0eb3b16621fb6a9c9 (enable
hotplug for pci bridges), PCI cards used to show up in the device
tree of OS X (System Information). E.g., on MountainLion I have:
Hardware - PCI Cards:
Card Type Driver Installed Slot
*ethernet Ethernet Controller Yes PCI Slot 2
pci8086,2934 USB UHC Yes PCI Slot 29
ethernet:
Type: Ethernet Controller
Driver Installed: Yes
MSI: No
Bus: PCI
Slot PCI Slot 2
Vendor ID:0x8086
Device ID:0x100e
Subsystem Vendor ID: 0x1af4
Subsystem ID: 0x1100
Revision ID: 0x0003
Hardware - Ethernet Cards
ethernet:
Type: Ethernet Controller
Bus: PCI
Slot PCI Slot 2
Vendor ID:0x8086
Device ID:0x100e
Subsystem Vendor ID: 0x1af4
Subsystem ID: 0x1100
Revision ID: 0x0003
BSD name: en0
Kext name:AppleIntel8254XEthernet.kext
Location: /System/Library/Extensions/...
Version: 3.1.1b1
After commit 99fd437dee468609de8218f0eb3b16621fb6a9c9, I get:
Hardware - PCI Cards:
This computer doesn't contain any PCI cards. If you installed PCI
cards, make sure they're properly installed.
Hardware - Ethernet Cards
ethernet:
Type: Ethernet Controller
Bus: PCI
Vendor ID:0x8086
Device ID:0x100e
Subsystem Vendor ID: 0x1af4
Subsystem ID: 0x1100
Revision ID: 0x0003
BSD name: en0
Kext name:AppleIntel8254XEthernet.kext
Location: /System/Library/Extensions/...
Version: 3.1.1b1
Ethernet still works, but it's not showing up on the PCI bus, and it
no longer thinks it's plugged in to slot #2, as it used to before the
change.
My command line is
bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -M q35 \
-device isa-applesmc,osk=... \
-usb -device usb-kbd -device usb-mouse \
-smbios file=./dmidecode.bin -kernel ./chameleon_boot \
-device ide-drive,bus=ide.2,drive=MacHDD \
-drive id=MacHDD,if=none,snapshot=on,file=./mac_10.8.img \
where dmidecode.bin is a custom SMBIOS table, chameleon_boot is
the stage-2 bootloader component of Chameleon, and on the kernel side
I have the irq-polarity patch we're currently talking about in a
separate thread
(http://lists.nongnu.org/archive/html/qemu-devel/2014-01/msg04252.html)
and also the monitor==mwait==NOP patch.
Any ideas or thoughts appreciated !
Thanks much,
--Gabriel
Interesting. Possibly OSX wants an ACPI description of all slots
even if they aren't hotpluggable?
Could you try the following? (Note: compiled only, sorry - sick today).
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index bc46b58..6a65ed6 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -643,6 +643,13 @@ static inline char acpi_get_hex(uint32_t val)
#define ACPI_PCIHP_SIZEOF (*ssdt_pcihp_end - *ssdt_pcihp_start)
#define ACPI_PCIHP_AML (ssdp_pcihp_aml + *ssdt_pcihp_start)
+#define ACPI_PCINOHP_OFFSET_HEX (*ssdt_pcinohp_name - *ssdt_pcinohp_start + 1)
+#define ACPI_PCINOHP_OFFSET_ID (*ssdt_pcinohp_id - *ssdt_pcinohp_start)
+#define ACPI_PCINOHP_OFFSET_ADR (*ssdt_pcinohp_adr - *ssdt_pcinohp_start)
+#define ACPI_PCINOHP_OFFSET_EJ0 (*ssdt_pcinohp_ej0 - *ssdt_pcinohp_start)
+#define ACPI_PCINOHP_SIZEOF (*ssdt_pcinohp_end - *ssdt_pcinohp_start)
+#define ACPI_PCINOHP_AML (ssdp_pcihp_aml + *ssdt_pcinohp_start)
+
#define ACPI_SSDT_SIGNATURE 0x54445353 /* SSDT */
#define ACPI_SSDT_HEADER_LENGTH 36
@@ -677,6 +684,16 @@ static void patch_pcihp(int slot, uint8_t *ssdt_ptr)
ssdt_ptr[ACPI_PCIHP_OFFSET_ADR + 2] = slot;
}
+static void patch_pcinohp(int slot, uint8_t *ssdt_ptr)
+{
+unsigned devfn = PCI_DEVFN(slot, 0);
+
+ssdt_ptr[ACPI_PCINOHP_OFFSET_HEX] = acpi_get_hex(devfn 4);
+ssdt_ptr[ACPI_PCINOHP_OFFSET_HEX + 1] = acpi_get_hex(devfn);
+ssdt_ptr[ACPI_PCINOHP_OFFSET_ID] = slot;
+ssdt_ptr[ACPI_PCINOHP_OFFSET_ADR + 2] = slot;
+}
+
/* Assign BSEL property to all buses. In the future, this can be changed
* to only assign to buses that support hotplug.
*/
@@ -737,6 +754,7 @@ static void build_pci_bus_end(PCIBus *bus, void *bus_state)
AcpiBuildPciBusHotplugState *parent = child-parent;
GArray *bus_table = build_alloc_array();
DECLARE_BITMAP(slot_hotplug_enable, PCI_SLOT_MAX);
+DECLARE_BITMAP(slot_device_present, PCI_SLOT_MAX);
uint8_t op;
int i;
QObject *bsel;
@@ -764,38 +782,49 @@ static void build_pci_bus_end(PCIBus *bus, void
[Qemu-devel] [PATCH 3/8] Add check for cache size smaller than page size
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
arch_init.c | 4
migration.c | 10 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch_init.c b/arch_init.c
index 66f5e82..8edeabe 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -178,6 +178,10 @@ static struct {
int64_t xbzrle_cache_resize(int64_t new_size)
{
+if (new_size TARGET_PAGE_SIZE) {
+return -1;
+}
+
if (XBZRLE.cache != NULL) {
return cache_resize(XBZRLE.cache, new_size / TARGET_PAGE_SIZE) *
TARGET_PAGE_SIZE;
diff --git a/migration.c b/migration.c
index 7235c23..84587e9 100644
--- a/migration.c
+++ b/migration.c
@@ -469,6 +469,7 @@ void qmp_migrate_cancel(Error **errp)
void qmp_migrate_set_cache_size(int64_t value, Error **errp)
{
MigrationState *s = migrate_get_current();
+int64_t new_size;
/* Check for truncation */
if (value != (size_t)value) {
@@ -477,7 +478,14 @@ void qmp_migrate_set_cache_size(int64_t value, Error
**errp)
return;
}
-s-xbzrle_cache_size = xbzrle_cache_resize(value);
+new_size = xbzrle_cache_resize(value);
+if (new_size 0) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
+ is smaller than page size);
+return;
+}
+
+s-xbzrle_cache_size = new_size;
}
int64_t qmp_query_migrate_cache_size(Error **errp)
--
1.8.5.3
[Qemu-devel] [PATCH 5/8] XBZRLE cache size should not be larger than guest memory size
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration.c b/migration.c
index 46a7305..25add6f 100644
--- a/migration.c
+++ b/migration.c
@@ -479,6 +479,13 @@ void qmp_migrate_set_cache_size(int64_t value, Error
**errp)
return;
}
+/* Cache should not be larger than guest ram size */
+if (value ram_bytes_total()) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
+ exceeds guest ram size );
+return;
+}
+
new_size = xbzrle_cache_resize(value);
if (new_size 0) {
error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
--
1.8.5.3
Re: [Qemu-devel] [PATCH 12/12] trace: [all] Add guest_vmem event
On 01/31/2014 08:10 AM, Lluís Vilanova wrote:
+#define ldub(p)({ trace_guest_vmem(p, 1, 0); ldub_raw(p);})
Are you sure you want to log these here? Uses of these macros are
not restricted to the guest. Therefore you could wind up with e.g.
PCI device accesses being attributed to the target cpu.
--- a/include/exec/softmmu_header.h
+++ b/include/exec/softmmu_header.h
@@ -25,6 +25,11 @@
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, see
http://www.gnu.org/licenses/.
*/
+
+#if !defined(TRACE_TCG_CODE_ACCESSOR)
+#include trace.h
+#endif
+
#if DATA_SIZE == 8
#define SUFFIX q
#define USUFFIX q
@@ -88,6 +93,10 @@ glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env,
target_ulong ptr)
target_ulong addr;
int mmu_idx;
+#if !defined(TRACE_TCG_CODE_ACCESSOR)
+trace_guest_vmem(ptr, DATA_SIZE, 0);
+#endif
These are going to result in double-logging the same access with
+#define tcg_gen_qemu_ld_i32(val, addr, idx, memop) \
+do {\
+uint8_t _memop_size = _tcg_memop_size(memop); \
+trace_guest_vmem_tcg(addr, _memop_size, 0); \
+tcg_gen_qemu_ld_i32(val, addr, idx, memop); \
+} while (0)
... these.
Of course, those softmmu functions are also used by the system emulators in the
same way the ldub macro above is used for userland emulation. So again you
have non-target accesses being attributed to the target.
Also, doing this action with macros, here, seems truly backward. Why not
simply modify the real tcg_gen_qemu_ld_i32 in tcg.c?
r~
[Qemu-devel] [PULL 0/8] migration queue
Hi This includes: - Peter changes to make VMSTATE_STRUCT_POINTER more consistent - Fix migration with hpratio (ppc on ppc64 basically) - Orit/Arei cleanups/fixes to xbzrle Thanks, please apply. The following changes since commit 8cfc114a2f293c40077d1bdb7500b29db359ca22: linux-user: Fix trampoline code for CRIS (2014-02-03 14:04:00 +) are available in the git repository at: git://github.com/juanquintela/qemu.git tags/migration/20140204 for you to fetch changes up to 2c429c2e4540ff74f2396b41e34371bd97c9337f: exec: fix ram_list dirty map optimization (2014-02-04 15:52:31 +0100) migration/next for 20140204 Alexey Kardashevskiy (1): exec: fix ram_list dirty map optimization Gonglei (Arei) (1): migration:fix free XBZRLE decoded_buf wrong Orit Wasserman (5): Set xbzrle buffers to NULL after freeing them to avoid double free errors Add check for cache size smaller than page size XBZRLE cache size should not be larger than guest memory size Don't abort on out of memory when creating page cache Don't abort on memory allocation error Peter Maydell (1): vmstate: Make VMSTATE_STRUCT_POINTER take type, not ptr-to-type arch_init.c| 47 +++--- hw/arm/pxa2xx.c| 2 +- include/exec/ram_addr.h| 3 ++- include/hw/ptimer.h| 10 ++--- include/migration/migration.h | 1 + include/migration/page_cache.h | 4 +++- include/migration/vmstate.h| 8 +++ migration.c| 18 +++- page_cache.c | 34 ++ 9 files changed, 90 insertions(+), 37 deletions(-)
[Qemu-devel] [PATCH 6/8] Don't abort on out of memory when creating page cache
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
arch_init.c | 16 ++--
page_cache.c | 18 ++
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 5eff80b..806d096 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -664,8 +664,20 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
DPRINTF(Error creating cache\n);
return -1;
}
-XBZRLE.encoded_buf = g_malloc0(TARGET_PAGE_SIZE);
-XBZRLE.current_buf = g_malloc(TARGET_PAGE_SIZE);
+
+/* We prefer not to abort if there is no memory */
+XBZRLE.encoded_buf = g_try_malloc0(TARGET_PAGE_SIZE);
+if (!XBZRLE.encoded_buf) {
+DPRINTF(Error allocating encoded_buf\n);
+return -1;
+}
+
+XBZRLE.current_buf = g_try_malloc(TARGET_PAGE_SIZE);
+if (!XBZRLE.current_buf) {
+DPRINTF(Error allocating current_buf\n);
+return -1;
+}
+
acct_clear();
}
diff --git a/page_cache.c b/page_cache.c
index a05db64..62a53f8 100644
--- a/page_cache.c
+++ b/page_cache.c
@@ -60,8 +60,12 @@ PageCache *cache_init(int64_t num_pages, unsigned int
page_size)
return NULL;
}
-cache = g_malloc(sizeof(*cache));
-
+/* We prefer not to abort if there is no memory */
+cache = g_try_malloc(sizeof(*cache));
+if (!cache) {
+DPRINTF(Failed to allocate cache\n);
+return NULL;
+}
/* round down to the nearest power of 2 */
if (!is_power_of_2(num_pages)) {
num_pages = pow2floor(num_pages);
@@ -74,8 +78,14 @@ PageCache *cache_init(int64_t num_pages, unsigned int
page_size)
DPRINTF(Setting cache buckets to % PRId64 \n, cache-max_num_items);
-cache-page_cache = g_malloc((cache-max_num_items) *
- sizeof(*cache-page_cache));
+/* We prefer not to abort if there is no memory */
+cache-page_cache = g_try_malloc((cache-max_num_items) *
+ sizeof(*cache-page_cache));
+if (!cache-page_cache) {
+DPRINTF(Failed to allocate cache-page_cache\n);
+g_free(cache);
+return NULL;
+}
for (i = 0; i cache-max_num_items; i++) {
cache-page_cache[i].it_data = NULL;
--
1.8.5.3
Re: [Qemu-devel] [PATCH] xen_disk: add discard support
On Tue, 4 Feb 2014, Olaf Hering wrote:
On Mon, Feb 03, Kevin Wolf wrote:
Am 30.01.2014 um 16:02 hat Olaf Hering geschrieben:
+++ b/hw/block/xen_disk.c
+case BLKIF_OP_DISCARD:
+{
+struct blkif_request_discard *discard_req = (void *)ioreq-req;
+bdrv_acct_start(blkdev-bs, ioreq-acct,
+discard_req-nr_sectors * BLOCK_SIZE,
BDRV_ACCT_WRITE);
Neither SCSI nor IDE account for discards. I think we should keep the
behaviour consistent across devices.
Stefano,did you already put this change into your queue?
I will resubmit the patch with the change below.
Go ahead and resubmit. Thanks.
Olaf
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index e74efc7..69ecc98 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -527,8 +527,6 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
case BLKIF_OP_DISCARD:
{
struct blkif_request_discard *discard_req = (void *)ioreq-req;
-bdrv_acct_start(blkdev-bs, ioreq-acct,
-discard_req-nr_sectors * BLOCK_SIZE,
BDRV_ACCT_WRITE);
ioreq-aio_inflight++;
bdrv_aio_discard(blkdev-bs,
discard_req-sector_number, discard_req-nr_sectors,
Re: [Qemu-devel] [PATCH V15 12/13] quorum: Add quorum_open() and quorum_close().
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Example of command line:
-drive if=virtio,file.driver=quorum,\
file.children.0.file.filename=1.raw,\
file.children.0.node-name=1.raw,\
file.children.0.driver=raw,\
file.children.1.file.filename=2.raw,\
file.children.1.node-name=2.raw,\
file.children.1.driver=raw,\
file.children.2.file.filename=3.raw,\
file.children.2.node-name=3.raw,\
file.children.2.driver=raw,\
file.vote_threshold=2
file.blkverify=on with file.vote_threshold=2 and two files can be passed to
emulated blkverify.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block/quorum.c | 171
+++
qapi-schema.json | 21 ++-
2 files changed, 191 insertions(+), 1 deletion(-)
diff --git a/block/quorum.c b/block/quorum.c
index 1e683f8..d2bea29 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -17,8 +17,12 @@
#include gnutls/crypto.h
#include block/block_int.h
#include qapi/qmp/qjson.h
+#include qapi/qmp/types.h
+#include qemu-common.h
#define HASH_LENGTH 32
+#define KEY_PREFIX children.
+#define KEY_FILENAME_SUFFIX .file.filename
/* This union holds a vote hash value */
typedef union QuorumVoteValue {
@@ -712,12 +716,179 @@ static bool
quorum_recurse_is_first_non_filter(BlockDriverState *bs,
return false;
}
+static int quorum_valid_threshold(int threshold,
+ int total,
+ Error **errp)
+{
+
+if (threshold 1) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE,
+ vote-threshold, value = 1);
+return -ERANGE;
+}
+
+if (threshold total) {
+error_setg(errp, threshold may not exceed children count);
+return -ERANGE;
+}
+
+return 0;
+}
+
+static int quorum_open(BlockDriverState *bs,
+ QDict *options,
+ int flags,
+ Error **errp)
+{
+BDRVQuorumState *s = bs-opaque;
+Error *local_err = NULL;
+bool *opened;
+QDict *sub = NULL;
+QList *list = NULL;
+const QListEntry *lentry;
+const QDictEntry *dentry;
+const char *value;
+char *next;
+int i;
+int ret = 0;
+unsigned long long threshold = 0;
+
+qdict_flatten(options);
+qdict_extract_subqdict(options, sub, children.);
+qdict_array_split(sub, list);
+
+/* count how many different children are present and validate */
+s-total = !qlist_size(list) ? qdict_size(sub) : qlist_size(list);
Which case does qdict_size(sub) address?
+if (s-total 2) {
+error_setg(local_err,
+ Number of provided children must be greater than 1);
+ret = -EINVAL;
+goto exit;
+}
+
+ret = qdict_get_try_int(options, vote-threshold, -1);
+/* from QMP */
+if (ret != -1) {
+qdict_del(options, vote-threshold);
+s-threshold = ret;
+/* from command line */
+} else {
+/* retrieve the threshold option from the command line */
+value = qdict_get_try_str(options, vote_threshold);
+if (!value) {
+error_setg(local_err,
+ vote_threshold must be provided);
+ret = -EINVAL;
+goto exit;
+}
+qdict_del(options, vote_threshold);
+
+ret = parse_uint(value, threshold, next, 10);
+
+/* no int found - scan fail */
+if (ret 0) {
+error_setg(local_err,
+ invalid vote_threshold specified);
+ret = -EINVAL;
+goto exit;
+}
+s-threshold = threshold;
+}
This part looks seriously wrong. I think you should consider using an
QemuOpts like other drivers do (have a look at qcow2, for example), that
should parse the integer for you.
+/* and validate it against s-total */
+ret = quorum_valid_threshold(s-threshold, s-total, local_err);
+if (ret 0) {
+goto exit;
+}
+
+/* is the driver in blkverify mode */
+value = qdict_get_try_str(options, blkverify);
+if (value !strcmp(value, on)
+s-total == 2 s-threshold == 2) {
+s-is_blkverify = true;
+} else if (value strcmp(value, off)) {
+fprintf(stderr, blkverify mode is set by setting blkverify=on
+and using two files with vote_threshold=2\n);
+}
+qdict_del(options, blkverify);
And the QemuOpts would also know how to parse a boolean.
+
+/* allocate the children BlockDriverState array */
+s-bs = g_new0(BlockDriverState *, s-total);
+opened = g_new0(bool, s-total);
+
+/* Open by file name or options dict (command line or QMP) */
+if (s-total == qlist_size(list)) {
+for (i = 0, lentry = qlist_first(list); lentry;
+lentry = qlist_next(lentry),
Re: [Qemu-devel] [PULL v2 00/24] QOM devices patch queue 2013-12-24
On Tue, Feb 04, 2014 at 04:56:53PM +0100, Andreas Färber wrote: Michael, Am 24.12.2013 18:04, schrieb Andreas Färber: P.S. I reproducibly get a signal message: TEST: tests/acpi-test... (pid=6364) /i386/acpi/tcg: main-loop: WARNING: I/O thread spun for 1000 iterations qemu: terminating on signal 15 from pid 6364 OK PASS: tests/acpi-test both before and after the queue. I'm still seeing this during make check - are you aware? Is there a fix? Regards, Andreas I didn't notice, sorry. I'll work on this. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] QEMU-Based Android Emulator
Hi, Am 03.02.2014 18:45, schrieb Marinos Tsantekidis: Hi to all! I'm looking to extract some info from QEMU used by Android Emulator. I want to add some printf s to the source code. How do I do that? How do I recompile the source in order for the changes to take effect? Please help!! Please see our Wiki for info on compiling QEMU: http://wiki.qemu.org/Documentation/GettingStartedDevelopers Adding printf()s to device emulation code is trivial and works like in any other C code. For instruction-level tracing it's less easy, you can only add printf()s during translation time, but not generally for execution tracing. If you want information specifically on the Android emulator, you'll have to ask elsewhere since we don't maintain that. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 2/8] Set xbzrle buffers to NULL after freeing them to avoid double free errors
From: Orit Wasserman owass...@redhat.com Signed-off-by: Orit Wasserman owass...@redhat.com Reviewed-by: Juan Quintela quint...@redhat.com Signed-off-by: Juan Quintela quint...@redhat.com --- arch_init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch_init.c b/arch_init.c index 77912e7..66f5e82 100644 --- a/arch_init.c +++ b/arch_init.c @@ -617,6 +617,9 @@ static void migration_end(void) g_free(XBZRLE.current_buf); g_free(XBZRLE.decoded_buf); XBZRLE.cache = NULL; +XBZRLE.encoded_buf = NULL; +XBZRLE.current_buf = NULL; +XBZRLE.decoded_buf = NULL; } } -- 1.8.5.3
[Qemu-devel] [PATCH 1/8] vmstate: Make VMSTATE_STRUCT_POINTER take type, not ptr-to-type
From: Peter Maydell peter.mayd...@linaro.org
The VMSTATE_STRUCT_POINTER macros are a bit odd in that they
must be passed an argument FooType * rather than just taking
the FooType. They're only used in one place, so it's easy to
tidy this up. This also lets us use the macro to replace the
hand-rolled VMSTATE_PTIMER.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/arm/pxa2xx.c | 2 +-
include/hw/ptimer.h | 10 ++
include/migration/vmstate.h | 8
3 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
index 02b7016..25ec549 100644
--- a/hw/arm/pxa2xx.c
+++ b/hw/arm/pxa2xx.c
@@ -1448,7 +1448,7 @@ static const VMStateDescription vmstate_pxa2xx_i2c = {
VMSTATE_UINT8(ibmr, PXA2xxI2CState),
VMSTATE_UINT8(data, PXA2xxI2CState),
VMSTATE_STRUCT_POINTER(slave, PXA2xxI2CState,
- vmstate_pxa2xx_i2c_slave, PXA2xxI2CSlaveState
*),
+ vmstate_pxa2xx_i2c_slave, PXA2xxI2CSlaveState),
VMSTATE_END_OF_LIST()
}
};
diff --git a/include/hw/ptimer.h b/include/hw/ptimer.h
index a33edf4..8ebacbb 100644
--- a/include/hw/ptimer.h
+++ b/include/hw/ptimer.h
@@ -27,14 +27,8 @@ void ptimer_stop(ptimer_state *s);
extern const VMStateDescription vmstate_ptimer;
-#define VMSTATE_PTIMER(_field, _state) { \
-.name = (stringify(_field)), \
-.version_id = (1), \
-.vmsd = vmstate_ptimer, \
-.size = sizeof(ptimer_state *),\
-.flags = VMS_STRUCT|VMS_POINTER,\
-.offset = vmstate_offset_pointer(_state, _field, ptimer_state), \
-}
+#define VMSTATE_PTIMER(_field, _state) \
+VMSTATE_STRUCT_POINTER_V(_field, _state, 1, vmstate_ptimer, ptimer_state)
#define VMSTATE_PTIMER_ARRAY(_f, _s, _n)\
VMSTATE_ARRAY_OF_POINTER_TO_STRUCT(_f, _s, _n, 0, \
diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index be193ba..fbd16a0 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -314,9 +314,9 @@ extern const VMStateInfo vmstate_info_bitmap;
.name = (stringify(_field)), \
.version_id = (_version),\
.vmsd = (_vmsd),\
-.size = sizeof(_type), \
+.size = sizeof(_type *), \
.flags= VMS_STRUCT|VMS_POINTER, \
-.offset = vmstate_offset_value(_state, _field, _type), \
+.offset = vmstate_offset_pointer(_state, _field, _type), \
}
#define VMSTATE_STRUCT_POINTER_TEST_V(_field, _state, _test, _version, _vmsd,
_type) { \
@@ -324,9 +324,9 @@ extern const VMStateInfo vmstate_info_bitmap;
.version_id = (_version),\
.field_exists = (_test), \
.vmsd = (_vmsd),\
-.size = sizeof(_type), \
+.size = sizeof(_type *), \
.flags= VMS_STRUCT|VMS_POINTER, \
-.offset = vmstate_offset_value(_state, _field, _type), \
+.offset = vmstate_offset_pointer(_state, _field, _type), \
}
#define VMSTATE_ARRAY_OF_POINTER(_field, _state, _num, _version, _info, _type)
{\
--
1.8.5.3
Re: [Qemu-devel] [PATCH V15 13/13] quorum: Add unit test.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben: Signed-off-by: Benoit Canet ben...@irqsave.net Reviewed-by: Max Reitz mre...@redhat.com --- tests/qemu-iotests/075 | 95 ++ tests/qemu-iotests/075.out | 34 + tests/qemu-iotests/group | 1 + 3 files changed, 130 insertions(+) create mode 100755 tests/qemu-iotests/075 create mode 100644 tests/qemu-iotests/075.out I believe 081 is the next free number that doesn't cause conflicts. Kevin
[Qemu-devel] [PATCH 7/8] Don't abort on memory allocation error
From: Orit Wasserman owass...@redhat.com
It is better to fail migration in case of failure to
allocate new cache item
Signed-off-by: Orit Wasserman owass...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
arch_init.c| 4 +++-
include/migration/page_cache.h | 4 +++-
page_cache.c | 16 +++-
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 806d096..0bfbc5a 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -284,7 +284,9 @@ static int save_xbzrle_page(QEMUFile *f, uint8_t
*current_data,
if (!cache_is_cached(XBZRLE.cache, current_addr)) {
if (!last_stage) {
-cache_insert(XBZRLE.cache, current_addr, current_data);
+if (cache_insert(XBZRLE.cache, current_addr, current_data) == -1) {
+return -1;
+}
}
acct_info.xbzrle_cache_miss++;
return -1;
diff --git a/include/migration/page_cache.h b/include/migration/page_cache.h
index 87894fe..d156f0d 100644
--- a/include/migration/page_cache.h
+++ b/include/migration/page_cache.h
@@ -60,11 +60,13 @@ uint8_t *get_cached_data(const PageCache *cache, uint64_t
addr);
* cache_insert: insert the page into the cache. the page cache
* will dup the data on insert. the previous value will be overwritten
*
+ * Returns -1 on error
+ *
* @cache pointer to the PageCache struct
* @addr: page address
* @pdata: pointer to the page
*/
-void cache_insert(PageCache *cache, uint64_t addr, uint8_t *pdata);
+int cache_insert(PageCache *cache, uint64_t addr, uint8_t *pdata);
/**
* cache_resize: resize the page cache. In case of size reduction the extra
diff --git a/page_cache.c b/page_cache.c
index 62a53f8..69e8329 100644
--- a/page_cache.c
+++ b/page_cache.c
@@ -150,7 +150,7 @@ uint8_t *get_cached_data(const PageCache *cache, uint64_t
addr)
return cache_get_by_addr(cache, addr)-it_data;
}
-void cache_insert(PageCache *cache, uint64_t addr, uint8_t *pdata)
+int cache_insert(PageCache *cache, uint64_t addr, uint8_t *pdata)
{
CacheItem *it = NULL;
@@ -161,16 +161,22 @@ void cache_insert(PageCache *cache, uint64_t addr,
uint8_t *pdata)
/* actual update of entry */
it = cache_get_by_addr(cache, addr);
-/* free old cached data if any */
-g_free(it-it_data);
-
+/* allocate page */
if (!it-it_data) {
cache-num_items++;
+it-it_data = g_try_malloc(cache-page_size);
+if (!it-it_data) {
+DPRINTF(Error allocating page\n);
+return -1;
+}
}
-it-it_data = g_memdup(pdata, cache-page_size);
+memcpy(it-it_data, pdata, cache-page_size);
+
it-it_age = ++cache-max_item_age;
it-it_addr = addr;
+
+return 0;
}
int64_t cache_resize(PageCache *cache, int64_t new_num_pages)
--
1.8.5.3
Re: [Qemu-devel] [PATCH 0/2] Use g_new() friends where that makes obvious sense
Peter Maydell peter.mayd...@linaro.org writes: On 3 February 2014 08:40, Markus Armbruster arm...@redhat.com wrote: Peter Maydell peter.mayd...@linaro.org writes: On 31 January 2014 15:53, Markus Armbruster arm...@redhat.com wrote: 186 files changed, 376 insertions(+), 415 deletions(-) No objection in principle, but I think this is going to be hideous merge pain since it touches a huge range of files. Could you split it up into separate patches that could reasonably go in via the appropriate submaintainer trees? No merge pain at all if you simply rerun the included Coccinelle patch! Yes, but that requires me to find, install, learn about and use Coccinelle. Splitting the patch may shift some pain from the choke point (you) to submaintainers and me. I don't mind the splitting pain. I do mind the chase the nominal maintainer of obscure corner pain. If you really want it split: what about splitting off just the busy and/or well-maintained subsystems? Yes, that's fine. You can put the miscellaneous leftovers parts through trivial if you like. I just dislike single touches-entire-world patches if they're not absolutely necessary. Unfortunately, our use of macros confuses coccinelle sufficiently to miss quite a few instances of the patterns. Do we want this change anyway?
Re: [Qemu-devel] [BUGFIX][PATCH v2] configure: Disable libtool if -fPIE does not work with it (bug #1257099)
On Tue, 4 Feb 2014, Paolo Bonzini wrote: Il 03/02/2014 12:59, Stefano Stabellini ha scritto: I'm applying this to a configure branch on my github repository. Thanks! Paolo, did this patch ever make it upstream? If so, do you have a commit id? It's still in my branch, where it is commit fcfd805b. As soon as I get a go/no-go for the modules patches I'll post it. In that case I might have to apply the patch to the qemu-xen tree for the Xen 4.4 release before the commit reaches QEMU upstream.
Re: [Qemu-devel] [PATCH 5/8] XBZRLE cache size should not be larger than guest memory size
On 02/04/2014 08:19 AM, Juan Quintela wrote:
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration.c b/migration.c
index 46a7305..25add6f 100644
--- a/migration.c
+++ b/migration.c
@@ -479,6 +479,13 @@ void qmp_migrate_set_cache_size(int64_t value, Error
**errp)
return;
}
+/* Cache should not be larger than guest ram size */
+if (value ram_bytes_total()) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
+ exceeds guest ram size );
Trailing space in the error message.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [BUGFIX][PATCH v2] configure: Disable libtool if -fPIE does not work with it (bug #1257099)
Il 03/02/2014 12:59, Stefano Stabellini ha scritto: I'm applying this to a configure branch on my github repository. Thanks! Paolo, did this patch ever make it upstream? If so, do you have a commit id? It's still in my branch, where it is commit fcfd805b. As soon as I get a go/no-go for the modules patches I'll post it.
Re: [Qemu-devel] QEMU-Based Android Emulator
Maybe I'm not specific enough. I built Android from the source code and I know that the Android Emulator that comes with it, is based on QEMU. I don't want anything from Android. What I'm interested in is the underlying QEMU. I want to see how the program counter changes during translation. To my understanding, in the file target-arm/translate.c there are cases, each one for a different ARM instruction to be translated (write, store, branch etc.). I also know that for optimization purposes, the program counter changes only after a branch instruction. So, if and when I print the program counter, I expect to see it change only after a branch and remain unchanged after any other instruction. To sum up, I want to add printf()s to the source code of QEMU beneath the Android Emulator to see how the program counter behaves. I'm asking how do I do that. How do I recompile the source? How and where do I see the printed information? Please, it's very important. 2014-02-04 Andreas Färber afaer...@suse.de: Hi, Am 03.02.2014 18:45, schrieb Marinos Tsantekidis: Hi to all! I'm looking to extract some info from QEMU used by Android Emulator. I want to add some printf s to the source code. How do I do that? How do I recompile the source in order for the changes to take effect? Please help!! Please see our Wiki for info on compiling QEMU: http://wiki.qemu.org/Documentation/GettingStartedDevelopers Adding printf()s to device emulation code is trivial and works like in any other C code. For instruction-level tracing it's less easy, you can only add printf()s during translation time, but not generally for execution tracing. If you want information specifically on the Android emulator, you'll have to ask elsewhere since we don't maintain that. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 0/2] Use g_new() friends where that makes obvious sense
Il 04/02/2014 17:52, Markus Armbruster ha scritto: Unfortunately, our use of macros confuses coccinelle sufficiently to miss quite a few instances of the patterns. Do we want this change anyway? Yes, we already use g_new anyway. Paolo
Re: [Qemu-devel] [PATCH 5/8] XBZRLE cache size should not be larger than guest memory size
On 02/04/2014 06:26 PM, Eric Blake wrote:
On 02/04/2014 08:19 AM, Juan Quintela wrote:
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration.c b/migration.c
index 46a7305..25add6f 100644
--- a/migration.c
+++ b/migration.c
@@ -479,6 +479,13 @@ void qmp_migrate_set_cache_size(int64_t value, Error
**errp)
return;
}
+/* Cache should not be larger than guest ram size */
+if (value ram_bytes_total()) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
+ exceeds guest ram size );
Trailing space in the error message.
I will send a separate patch to fix this.
Orit
Re: [Qemu-devel] [PULL v2 00/24] QOM devices patch queue 2013-12-24
On Tue, Feb 04, 2014 at 04:56:53PM +0100, Andreas Färber wrote: Michael, Am 24.12.2013 18:04, schrieb Andreas Färber: P.S. I reproducibly get a signal message: TEST: tests/acpi-test... (pid=6364) /i386/acpi/tcg: main-loop: WARNING: I/O thread spun for 1000 iterations qemu: terminating on signal 15 from pid 6364 OK PASS: tests/acpi-test both before and after the queue. I'm still seeing this during make check - are you aware? Is there a fix? Regards, Andreas This seems to trigger on all acpi tests, since commit commit ad6423a7fbbaedc4ec1ed41a9688ca4a10909e89 Author: Michael S. Tsirkin m...@redhat.com Date: Fri Oct 18 00:52:18 2013 +0300 acpi-test: basic acpi unit-test -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PULL v2 00/24] QOM devices patch queue 2013-12-24
Michael, Am 24.12.2013 18:04, schrieb Andreas Färber: P.S. I reproducibly get a signal message: TEST: tests/acpi-test... (pid=6364) /i386/acpi/tcg: main-loop: WARNING: I/O thread spun for 1000 iterations qemu: terminating on signal 15 from pid 6364 OK PASS: tests/acpi-test both before and after the queue. I'm still seeing this during make check - are you aware? Is there a fix? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] kvm control qemu-system-aarch64 state
On 4 February 2014 16:37, Claudio Fontana hw.clau...@gmail.com wrote: On 4 February 2014 16:39, Peter Maydell peter.mayd...@linaro.org wrote: On 4 February 2014 15:36, Claudio Fontana hw.clau...@gmail.com wrote: I just wanted to ask what is the current state of kvm control for qemu-system-aarch64. I tried latest mainline but I think it's not all there yet (it complains about missing cpu when I use -M virt and -cpu host, so I suspect some of VOS patches are still missing). Is your aarch64-kvm still the one branch to look at? Nope, this should all work in mainline. If it doesn't it's worth investigating what exactly is going wrong. (Sanity check, you did pass -enable-kvm, right? If you don't then QEMU will complain about -cpu host, because that only exists if KVM is enabled.) I tried both, without -enable-kvm I get the complaint about -cpu host as you mention, but with -enable-kvm and the latest kernel I get: [ 8489.895747] BUG: Bad page state in process qemu-system-aar pfn:0a5cd [ 8489.895816] page:fdfc002444d8 count:-1 mapcount:0 mapping: (null) index:0x0 [ 8489.895870] page flags: 0x0() [ 8489.895916] page dumped because: nonzero _count [ 8489.895957] Modules linked in: [ 8489.896030] CPU: 0 PID: 3031 Comm: qemu-system-aar Tainted: GB 3.13.0cla-09218-g0e47c96-dirty #2 [ 8489.896085] Call trace: [ 8489.896154] [fe095744] dump_backtrace+0x0/0x12c [ 8489.896231] [fe095884] show_stack+0x14/0x1c [ 8489.896307] [fe3db58c] dump_stack+0x70/0x8c [ 8489.896378] [fe1210d8] bad_page+0xe8/0x134 [ 8489.896453] [fe121740] get_page_from_freelist+0x500/0x608 [ 8489.896532] [fe1220d0] __alloc_pages_nodemask+0x110/0x7ec [ 8489.896619] [fe13ce50] handle_mm_fault+0x760/0x980 [ 8489.896704] [fe09a0cc] do_page_fault+0x228/0x378 [ 8489.896773] [fe090104] do_mem_abort+0x3c/0x9c [ 8489.896833] Exception stack(0xfe0020247e30 to 0xfe0020247f50) [ 8489.896918] 7e20: 0001 aa8505b0 03ff [ 8489.897030] 7e40: aa785a84 03ff 0015e5a8 fe00 [ 8489.897142] 7e60: 20247e70 fe00 000c2e48 fe00 20247ea0 fe00 00095490 fe00 [ 8489.897254] 7e80: 20244000 fe00 aa86f118 03ff [ 8489.897366] 7ea0: fea46360 03ff 0009288c fe00 fea46580 03ff fea463e0 03ff [ 8489.897476] 7ec0: fea46360 03ff 000927ec fe00 00f3f710 00012e61 [ 8489.897584] 7ee0: 00f4d1a0 da91 0001 [ 8489.897694] 7f00: 000d 036a 7f7f7f7f 7f7f7f7f 00680ca8 [ 8489.897800] 7f20: 006d 0020 0078 0080 [ 8489.897884] 7f40: 006812b0 aa852598 03ff If we've managed to trigger a BUG in the host kernel that's a kernel bug and the kvmarm list is probably the best place to ask bout it. [cc'd.] thanks -- PMM
Re: [Qemu-devel] Commit 9e047b982452c633882b486682966c1d97097015 (piix4: add acpi pci hotplug support) seems to break Xen pci-passthrough
On Tue, 4 Feb 2014 16:07:08 +0100 Sander Eikelenboom li...@eikelenboom.it wrote: Tuesday, February 4, 2014, 3:32:19 PM, you wrote: On Tue, Feb 04, 2014 at 12:46:08AM +0100, Sander Eikelenboom wrote: Grmbll my fat fingers hit the send shortcut too soon by accident .. let's try again .. Hi Michael, A git bisect turned out that commit 9e047b982452c633882b486682966c1d97097015 breaks pci-passthrough on Xen. commit 9e047b982452c633882b486682966c1d97097015 Author: Michael S. Tsirkin m...@redhat.com Date: Mon Oct 14 18:01:20 2013 +0300 piix4: add acpi pci hotplug support Add support for acpi pci hotplug using the new infrastructure. PIIX4 legacy interface is maintained as is for machine types 1.7 and older. Signed-off-by: Michael S. Tsirkin m...@redhat.com The error is not very verbose : libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Device initialization failed. So it seems there is an issue with preserving the legacy interface. Which machine type is broken? xenfv What's the command line used? See below the output of the creation of the guest Strange thing is: char device redirected to /dev/pts/15 (label serial0) vgabios-cirrus.bin: ROM id 101300b8 / PCI id 101300b8 efi-e1000.rom: ROM id 8086100e / PCI id 8086100e VNC server running on `127.0.0.1:5900' xen_platform: changed ro/rw state of ROM memory area. now is rw state. [00:05.0] xen_pt_initfn: Assigning real physical device 06:01.0 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x1000 base_addr=0xfe0fd000 type: 0) [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_initfn: Real physical device 06:01.0 registered successfully! [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_initfn: Assigning real physical device 06:01.1 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x1000 base_addr=0xfe0fe000 type: 0) [00:05.0] xen_pt_pci_intx: intx=2 [00:05.0] xen_pt_initfn: Real physical device 06:01.1 registered successfully! [00:05.0] xen_pt_pci_intx: intx=2 [00:05.0] xen_pt_initfn: Assigning real physical device 06:01.2 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0100 base_addr=0xfe0ffc00 type: 0) [00:05.0] xen_pt_pci_intx: intx=3 [00:05.0] xen_pt_initfn: Real physical device 06:01.2 registered successfully! [00:05.0] xen_pt_pci_intx: intx=3 [00:05.0] xen_pt_initfn: Assigning real physical device 08:00.0 to devfn 0x28 [00:05.0] xen_pt_register_regions: IO region 0 registered (size=0x0020 base_addr=0xfe20 type: 0x4) [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_initfn: Real physical device 08:00.0 registered successfully! [00:05.0] xen_pt_pci_intx: intx=1 [00:05.0] xen_pt_msi_set_enable: disabling MSI. It's does log succes for registering the pci devices .. however it returns by qmp that the device initialization failed. And an lspci in the guest also doesn't show the devices. What's the value of has_acpi_build in hw/i386/pc_piix.c? static bool has_acpi_build = true; What happens if you add -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off That makes it work again ... Does it still work with http://www.mail-archive.com/qemu-devel@nongnu.org/msg213815.html -- Sander Parsing config from /etc/xen/domU/production/security.cfg libxl: debug: libxl_create.c:1348:do_domain_create: ao 0x1415900: create: how=(nil) callback=(nil) poller=0x1415960 libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hdb spec.backend=unknown libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk vdev=hdb, using backend phy libxl: debug: libxl_create.c:803:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch w=0x1415ce8: deregister unregistered xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x9efa8 xc: detail: elf_parse_binary: memory: 0x10 - 0x19efa8 xc: detail: VIRTUAL MEMORY ARRANGEMENT: Loader:0010-0019efa8 Modules: - TOTAL:
[Qemu-devel] [PATCH] qtest: don't report signals if qtest driver enabled
qtest driver always uses signals to kill qemu
no need to report it, whatever the accelerator state.
Add API to detect qtest driver, and suppress reporting
signals in this case.
Reported-by: Andreas Färber afaer...@suse.de
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/sysemu/qtest.h | 2 ++
qtest.c| 5 +
vl.c | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/qtest.h b/include/sysemu/qtest.h
index 112a661..6aca8e4 100644
--- a/include/sysemu/qtest.h
+++ b/include/sysemu/qtest.h
@@ -23,6 +23,8 @@ static inline bool qtest_enabled(void)
return qtest_allowed;
}
+bool qtest_driver(void);
+
int qtest_init_accel(void);
void qtest_init(const char *qtest_chrdev, const char *qtest_log);
diff --git a/qtest.c b/qtest.c
index dcf1301..a738afc 100644
--- a/qtest.c
+++ b/qtest.c
@@ -528,3 +528,8 @@ void qtest_init(const char *qtest_chrdev, const char
*qtest_log)
qtest_chr = chr;
}
+
+bool qtest_driver(void)
+{
+return qtest_chr;
+}
diff --git a/vl.c b/vl.c
index 60dbbcb..dddbbce 100644
--- a/vl.c
+++ b/vl.c
@@ -1748,7 +1748,7 @@ static int qemu_shutdown_requested(void)
static void qemu_kill_report(void)
{
-if (!qtest_enabled() shutdown_signal != -1) {
+if (!qtest_driver() shutdown_signal != -1) {
fprintf(stderr, qemu: terminating on signal %d, shutdown_signal);
if (shutdown_pid == 0) {
/* This happens for eg ^C at the terminal, so it's worth
--
MST
Re: [Qemu-devel] [PULL v2 00/24] QOM devices patch queue 2013-12-24
On Tue, Feb 04, 2014 at 04:56:53PM +0100, Andreas Färber wrote:
Michael,
Am 24.12.2013 18:04, schrieb Andreas Färber:
P.S. I reproducibly get a signal message:
TEST: tests/acpi-test... (pid=6364)
/i386/acpi/tcg:
main-loop: WARNING: I/O thread spun for 1000 iterations
qemu: terminating on signal 15 from pid 6364
OK
PASS: tests/acpi-test
both before and after the queue.
I'm still seeing this during make check - are you aware? Is there a fix?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
so the bug seems to be in the reporting:
static void qemu_kill_report(void)
{
if (!qtest_enabled() shutdown_signal != -1) {
fprintf(stderr, qemu: terminating on signal %d,
shutdown_signal);
if (shutdown_pid == 0) {
/* This happens for eg ^C at the terminal, so it's worth
* avoiding printing an odd message in that case.
*/
fputc('\n', stderr);
} else {
fprintf(stderr, from pid FMT_pid \n, shutdown_pid);
}
shutdown_signal = -1;
}
}
it shouldn't print this under qtest driver, instead it checks
accelerator value which is wrong.
I just sent a patch, please try it.
Re: [Qemu-devel] [PULL v4 09/12] lm32_sys: print test result on stderr
Am 2014-02-03 23:59, schrieb Peter Maydell: On 3 February 2014 22:39, Michael Walle mich...@walle.cc wrote: Am 2014-02-01 21:31, schrieb Michael Walle: Am Samstag, 1. Februar 2014, 19:00:01 schrieb Peter Maydell: On 20 January 2014 19:34, Michael Walle mich...@walle.cc wrote: Do not use qemu_log(). Signed-off-by: Michael Walle mich...@walle.cc --- hw/misc/lm32_sys.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/misc/lm32_sys.c b/hw/misc/lm32_sys.c index 8176cdb..6af0cca 100644 --- a/hw/misc/lm32_sys.c +++ b/hw/misc/lm32_sys.c @@ -80,7 +80,7 @@ static void sys_write(void *opaque, hwaddr addr, case R_PASSFAIL: s-regs[addr] = value; testname = (char *)s-testname; -qemu_log(TC %-32s %s\n, testname, (value) ? FAILED : OK); +fprintf(stderr, TC %-32s %s\n, testname, (value) ? FAILED : OK); break; This looks wrong to me -- devices shouldn't print to stderr, ideally. lm32_sys is actually no real device. it is just used for unit testing. Hi Peter, is this ok? or do you have some better idea? ideally, the lm32 target should use semihosting and should print to stdout/stderr itself. but that is not the case atm. Well, I guess for a testbench only kind of device printing to stderr is OK. I've just noticed that the device maps itself into the memory map. That's pretty foul. I can see why it does it, but really this thing is bending a lot of the rules. So if it is ok, i'll leave this patch in this pull request. But i'll also work on the lm32 semihosting so we can get rid of this device entirely. -michael
Re: [Qemu-devel] [PULL 0/8] migration queue
Juan Quintela quint...@redhat.com wrote: Hi This includes: - Peter changes to make VMSTATE_STRUCT_POINTER more consistent - Fix migration with hpratio (ppc on ppc64 basically) - Orit/Arei cleanups/fixes to xbzrle Thanks, please apply. NACK myself. It has the wrong patch series from Orit. Sorry, and resending a new one. Later, Juan.
Re: [Qemu-devel] [PATCH 7/8] Don't abort on memory allocation error
* Juan Quintela (quint...@redhat.com) wrote:
From: Orit Wasserman owass...@redhat.com
if (!it-it_data) {
cache-num_items++;
+it-it_data = g_try_malloc(cache-page_size);
+if (!it-it_data) {
+DPRINTF(Error allocating page\n);
+return -1;
+}
Hmm that wasn't the latest version of that patch (or the previous
one in the series).
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH 7/8] Don't abort on out of memory when creating page cache
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
arch_init.c | 18 --
page_cache.c | 18 ++
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 5eff80b..1fa5f1f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -664,8 +664,22 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
DPRINTF(Error creating cache\n);
return -1;
}
-XBZRLE.encoded_buf = g_malloc0(TARGET_PAGE_SIZE);
-XBZRLE.current_buf = g_malloc(TARGET_PAGE_SIZE);
+
+/* We prefer not to abort if there is no memory */
+XBZRLE.encoded_buf = g_try_malloc0(TARGET_PAGE_SIZE);
+if (!XBZRLE.encoded_buf) {
+DPRINTF(Error allocating encoded_buf\n);
+return -1;
+}
+
+XBZRLE.current_buf = g_try_malloc(TARGET_PAGE_SIZE);
+if (!XBZRLE.current_buf) {
+DPRINTF(Error allocating current_buf\n);
+g_free(XBZRLE.encoded_buf);
+XBZRLE.encoded_buf = NULL;
+return -1;
+}
+
acct_clear();
}
diff --git a/page_cache.c b/page_cache.c
index a05db64..62a53f8 100644
--- a/page_cache.c
+++ b/page_cache.c
@@ -60,8 +60,12 @@ PageCache *cache_init(int64_t num_pages, unsigned int
page_size)
return NULL;
}
-cache = g_malloc(sizeof(*cache));
-
+/* We prefer not to abort if there is no memory */
+cache = g_try_malloc(sizeof(*cache));
+if (!cache) {
+DPRINTF(Failed to allocate cache\n);
+return NULL;
+}
/* round down to the nearest power of 2 */
if (!is_power_of_2(num_pages)) {
num_pages = pow2floor(num_pages);
@@ -74,8 +78,14 @@ PageCache *cache_init(int64_t num_pages, unsigned int
page_size)
DPRINTF(Setting cache buckets to % PRId64 \n, cache-max_num_items);
-cache-page_cache = g_malloc((cache-max_num_items) *
- sizeof(*cache-page_cache));
+/* We prefer not to abort if there is no memory */
+cache-page_cache = g_try_malloc((cache-max_num_items) *
+ sizeof(*cache-page_cache));
+if (!cache-page_cache) {
+DPRINTF(Failed to allocate cache-page_cache\n);
+g_free(cache);
+return NULL;
+}
for (i = 0; i cache-max_num_items; i++) {
cache-page_cache[i].it_data = NULL;
--
1.8.5.3
Re: [Qemu-devel] [PATCH V15 09/13] quorum: Add quorum_co_get_block_status.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
Reviewed-by: Max Reitz mre...@redhat.com
---
block/quorum.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/block/quorum.c b/block/quorum.c
index cef4424..677a96d 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -619,6 +619,56 @@ static void quorum_invalidate_cache(BlockDriverState *bs)
}
}
+static int64_t coroutine_fn quorum_co_get_block_status(BlockDriverState *bs,
+ int64_t sector_num,
+ int nb_sectors,
+ int *pnum)
+{
+BDRVQuorumState *s = bs-opaque;
+QuorumVoteVersion *winner = NULL;
+QuorumVotes result_votes, num_votes;
+QuorumVoteValue result_value, num_value;
+int i, num;
+int64_t result = 0;
+
+QLIST_INIT(result_votes.vote_list);
+QLIST_INIT(num_votes.vote_list);
+result_votes.compare = quorum_64bits_compare;
+num_votes.compare = quorum_64bits_compare;
+
+for (i = 0; i s-total; i++) {
+result = bdrv_get_block_status(s-bs[i], sector_num, nb_sectors,
num);
+/* skip failed requests */
+if (result 0) {
+continue;
+}
+result_value.l = result BDRV_BLOCK_DATA;
+num_value.l = num;
+quorum_count_vote(result_votes, result_value, i);
+quorum_count_vote(num_votes, num_value, i);
+}
This doesn't work. bdrv_get_block_status() doesn't guarantee that it
returns all consecutive blocks with the same status. You need to call it
in a loop here, or change bdrv_get_block_status() so that it loops
itself.
+winner = quorum_get_vote_winner(result_votes);
+if (winner-vote_count s-threshold) {
+result = -EIO;
+goto free_exit;
+}
+result = winner-value.l;
+
+winner = quorum_get_vote_winner(num_votes);
+if (winner-vote_count s-threshold) {
+result = -EIO;
+goto free_exit;
+}
+*pnum = winner-value.l;
You can take the status from one group of devices and the number of
blocks that share this state from another group?!
+
+free_exit:
+quorum_free_vote_list(result_votes);
+quorum_free_vote_list(num_votes);
+
+return result;
+}
+
static BlockDriver bdrv_quorum = {
.format_name= quorum,
.protocol_name = quorum,
@@ -630,6 +680,7 @@ static BlockDriver bdrv_quorum = {
.bdrv_aio_readv = quorum_aio_readv,
.bdrv_aio_writev= quorum_aio_writev,
.bdrv_invalidate_cache = quorum_invalidate_cache,
+.bdrv_co_get_block_status = quorum_co_get_block_status,
};
static void bdrv_quorum_init(void)
Kevin
[Qemu-devel] [PATCH 6/8] XBZRLE cache size should not be larger than guest memory size
From: Orit Wasserman owass...@redhat.com
Signed-off-by: Orit Wasserman owass...@redhat.com
Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration.c b/migration.c
index 46a7305..25add6f 100644
--- a/migration.c
+++ b/migration.c
@@ -479,6 +479,13 @@ void qmp_migrate_set_cache_size(int64_t value, Error
**errp)
return;
}
+/* Cache should not be larger than guest ram size */
+if (value ram_bytes_total()) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
+ exceeds guest ram size );
+return;
+}
+
new_size = xbzrle_cache_resize(value);
if (new_size 0) {
error_set(errp, QERR_INVALID_PARAMETER_VALUE, cache size,
--
1.8.5.3
Re: [Qemu-devel] [PATCH V15 06/13] quorum: Add quorum mechanism.
Am 03.02.2014 um 22:51 hat Benoît Canet geschrieben:
From: Benoît Canet ben...@irqsave.net
Use gnutls's SHA-256 to compare versions.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block/Makefile.objs | 2 +-
block/quorum.c| 386
+-
configure | 36 +
docs/qmp/qmp-events.txt | 33
include/monitor/monitor.h | 2 +
monitor.c | 2 +
6 files changed, 458 insertions(+), 3 deletions(-)
diff --git a/block/Makefile.objs b/block/Makefile.objs
index a2650b9..4ca9d43 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -3,7 +3,7 @@ block-obj-y += qcow2.o qcow2-refcount.o qcow2-cluster.o
qcow2-snapshot.o qcow2-c
block-obj-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
block-obj-y += qed-check.o
block-obj-$(CONFIG_VHDX) += vhdx.o vhdx-endian.o vhdx-log.o
-block-obj-y += quorum.o
+block-obj-$(CONFIG_QUORUM) += quorum.o
block-obj-y += parallels.o blkdebug.o blkverify.o
block-obj-y += snapshot.o qapi.o
block-obj-$(CONFIG_WIN32) += raw-win32.o win32-aio.o
diff --git a/block/quorum.c b/block/quorum.c
index 699b512..837d261 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -13,7 +13,43 @@
* See the COPYING file in the top-level directory.
*/
+#include gnutls/gnutls.h
+#include gnutls/crypto.h
#include block/block_int.h
+#include qapi/qmp/qjson.h
+
+#define HASH_LENGTH 32
+
+/* This union holds a vote hash value */
+typedef union QuorumVoteValue {
+char h[HASH_LENGTH]; /* SHA-256 hash */
+int64_t l; /* simpler 64 bits hash */
+} QuorumVoteValue;
+
+/* A vote item */
+typedef struct QuorumVoteItem {
+int index;
+QLIST_ENTRY(QuorumVoteItem) next;
+} QuorumVoteItem;
+
+/* this structure is a vote version. A version is the set of votes sharing
the
+ * same vote value.
+ * The set of votes will be tracked with the items field and its cardinality
is
+ * vote_count.
+ */
+typedef struct QuorumVoteVersion {
+QuorumVoteValue value;
+int index;
+int vote_count;
+QLIST_HEAD(, QuorumVoteItem) items;
+QLIST_ENTRY(QuorumVoteVersion) next;
+} QuorumVoteVersion;
+
+/* this structure holds a group of vote versions together */
+typedef struct QuorumVotes {
+QLIST_HEAD(, QuorumVoteVersion) vote_list;
+int (*compare)(QuorumVoteValue *a, QuorumVoteValue *b);
+} QuorumVotes;
/* the following structure holds the state of one quorum instance */
typedef struct {
@@ -60,10 +96,14 @@ struct QuorumAIOCB {
int success_count; /* number of successfully completed AIOCB */
bool *finished; /* completion signal for cancel */
+QuorumVotes votes;
+
bool is_read;
int vote_ret;
};
+static void quorum_vote(QuorumAIOCB *acb);
+
static void quorum_aio_cancel(BlockDriverAIOCB *blockacb)
{
QuorumAIOCB *acb = container_of(blockacb, QuorumAIOCB, common);
@@ -81,10 +121,12 @@ static AIOCBInfo quorum_aiocb_info = {
.cancel = quorum_aio_cancel,
};
+static int quorum_vote_error(QuorumAIOCB *acb);
+
What's the reason for putting the forward declaration here? This is
neither directly before the first user nor at the top.
In fact, the next occurence of quorum_vote_error() is the implementation
of the function, so the forward declaration is completely unnecessary.
static void quorum_aio_finalize(QuorumAIOCB *acb)
{
BDRVQuorumState *s = acb-bqs;
-int ret = 0;
+int i, ret = 0;
for (i = 0; i s-total; i++) {
qemu_vfree(acb-aios[i].buf);
@@ -92,6 +134,10 @@ static void quorum_aio_finalize(QuorumAIOCB *acb)
acb-aios[i].ret = 0;
}
+if (acb-vote_ret) {
+ret = acb-vote_ret;
+}
+
acb-common.cb(acb-common.opaque, ret);
if (acb-finished) {
*acb-finished = true;
@@ -103,6 +149,27 @@ static void quorum_aio_finalize(QuorumAIOCB *acb)
qemu_aio_release(acb);
}
+static int quorum_sha256_compare(QuorumVoteValue *a, QuorumVoteValue *b)
+{
+return memcmp(a-h, b-h, HASH_LENGTH);
+}
+
+static int quorum_64bits_compare(QuorumVoteValue *a, QuorumVoteValue *b)
+{
+int64_t i = a-l;
+int64_t j = b-l;
+
+if (i j) {
+return -1;
+}
+
+if (i j) {
+return 1;
+}
+
+return 0;
+}
The usual way to implement this is 'return a-l - b-l;', because if you
expect memcmp() to return a valid value for the compare function you
can't assume that it's normalised to -1/0/1 anyway.
As you only ever use the result as a bool, you could alternatively
even declare the function as such and do 'return a-l != b-l;'.
static QuorumAIOCB *quorum_aio_get(BDRVQuorumState *s,
BlockDriverState *bs,
QEMUIOVector *qiov,
@@ -122,6 +189,7 @@ static QuorumAIOCB
[Qemu-devel] [PATCH 1/8] vmstate: Make VMSTATE_STRUCT_POINTER take type, not ptr-to-type
From: Peter Maydell peter.mayd...@linaro.org
The VMSTATE_STRUCT_POINTER macros are a bit odd in that they
must be passed an argument FooType * rather than just taking
the FooType. They're only used in one place, so it's easy to
tidy this up. This also lets us use the macro to replace the
hand-rolled VMSTATE_PTIMER.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/arm/pxa2xx.c | 2 +-
include/hw/ptimer.h | 10 ++
include/migration/vmstate.h | 8
3 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
index 02b7016..25ec549 100644
--- a/hw/arm/pxa2xx.c
+++ b/hw/arm/pxa2xx.c
@@ -1448,7 +1448,7 @@ static const VMStateDescription vmstate_pxa2xx_i2c = {
VMSTATE_UINT8(ibmr, PXA2xxI2CState),
VMSTATE_UINT8(data, PXA2xxI2CState),
VMSTATE_STRUCT_POINTER(slave, PXA2xxI2CState,
- vmstate_pxa2xx_i2c_slave, PXA2xxI2CSlaveState
*),
+ vmstate_pxa2xx_i2c_slave, PXA2xxI2CSlaveState),
VMSTATE_END_OF_LIST()
}
};
diff --git a/include/hw/ptimer.h b/include/hw/ptimer.h
index a33edf4..8ebacbb 100644
--- a/include/hw/ptimer.h
+++ b/include/hw/ptimer.h
@@ -27,14 +27,8 @@ void ptimer_stop(ptimer_state *s);
extern const VMStateDescription vmstate_ptimer;
-#define VMSTATE_PTIMER(_field, _state) { \
-.name = (stringify(_field)), \
-.version_id = (1), \
-.vmsd = vmstate_ptimer, \
-.size = sizeof(ptimer_state *),\
-.flags = VMS_STRUCT|VMS_POINTER,\
-.offset = vmstate_offset_pointer(_state, _field, ptimer_state), \
-}
+#define VMSTATE_PTIMER(_field, _state) \
+VMSTATE_STRUCT_POINTER_V(_field, _state, 1, vmstate_ptimer, ptimer_state)
#define VMSTATE_PTIMER_ARRAY(_f, _s, _n)\
VMSTATE_ARRAY_OF_POINTER_TO_STRUCT(_f, _s, _n, 0, \
diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index be193ba..fbd16a0 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -314,9 +314,9 @@ extern const VMStateInfo vmstate_info_bitmap;
.name = (stringify(_field)), \
.version_id = (_version),\
.vmsd = (_vmsd),\
-.size = sizeof(_type), \
+.size = sizeof(_type *), \
.flags= VMS_STRUCT|VMS_POINTER, \
-.offset = vmstate_offset_value(_state, _field, _type), \
+.offset = vmstate_offset_pointer(_state, _field, _type), \
}
#define VMSTATE_STRUCT_POINTER_TEST_V(_field, _state, _test, _version, _vmsd,
_type) { \
@@ -324,9 +324,9 @@ extern const VMStateInfo vmstate_info_bitmap;
.version_id = (_version),\
.field_exists = (_test), \
.vmsd = (_vmsd),\
-.size = sizeof(_type), \
+.size = sizeof(_type *), \
.flags= VMS_STRUCT|VMS_POINTER, \
-.offset = vmstate_offset_value(_state, _field, _type), \
+.offset = vmstate_offset_pointer(_state, _field, _type), \
}
#define VMSTATE_ARRAY_OF_POINTER(_field, _state, _num, _version, _info, _type)
{\
--
1.8.5.3
Re: [Qemu-devel] [PATCH] xen_disk: add discard support
On Tue, Feb 04, Olaf Hering wrote:
On Tue, Feb 04, Kevin Wolf wrote:
Now you call bdrv_acct_done() in the callback without having a matching
bdrv_acct_start(). You need to make it conditional in the callback.
Stefano,
Is ioreq_runio_qemu_aio symetric in this regard anyway? In case of
BLKIF_OP_WRITE|BLKIF_OP_FLUSH_DISKCACHE and no ioreq-req.nr_segments
then qemu_aio_complete is called anyway. Will qemu_aio_complete get down
to the bdrv_acct_done call at all in this case?
What I have in mind is something like the (not compile tested) change below.
Olaf
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index e74efc7..99d36b8 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -486,7 +486,16 @@ static void qemu_aio_complete(void *opaque, int ret)
ioreq-status = ioreq-aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
ioreq_unmap(ioreq);
ioreq_finish(ioreq);
-bdrv_acct_done(ioreq-blkdev-bs, ioreq-acct);
+switch (ioreq-req.operation) {
+case BLKIF_OP_DISCARD:
+break;
+case BLKIF_OP_WRITE:
+case BLKIF_OP_FLUSH_DISKCACHE:
+if (!ioreq-req.nr_segments) {
+break;
+}
+bdrv_acct_done(ioreq-blkdev-bs, ioreq-acct);
+}
qemu_bh_schedule(ioreq-blkdev-bh);
}
Re: [Qemu-devel] [PULL] Update OpenBIOS images to r1246
Applied, thanks. -- PMM On 12 January 2014 15:25, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote: Hi Anthony, Please pull the latest OpenBIOS binary images. In particular, these images fix the following two bugs in SPARC32: - Booting with OBP instead of OpenBIOS - Booting from hard disk instead of CDROM (https://bugs.launchpad.net/qemu/+bug/1262081) CC to -stable because these binaries also need to be updated in 1.7 branch too. Many thanks, Mark. The following changes since commit eedc1a5db5e4d941e39e54344322c0b1e89dfdcd: Merge remote-tracking branch 'bonzini/scsi-next' into staging (2014-01-10 11:05:17 -0800) are available in the git repository at: https://github.com/mcayland/qemu.git qemu-openbios for you to fetch changes up to fbb9c590cacf1cefb516f523427a920c2fe8c135: Update OpenBIOS images (2014-01-12 07:52:44 +) Mark Cave-Ayland (1): Update OpenBIOS images pc-bios/QEMU,tcx.bin | Bin 1242 - 1410 bytes pc-bios/README |2 +- pc-bios/openbios-ppc | Bin 729880 - 729912 bytes pc-bios/openbios-sparc32 | Bin 381488 - 381512 bytes pc-bios/openbios-sparc64 | Bin 1598328 - 1598376 bytes roms/openbios|2 +- 6 files changed, 2 insertions(+), 2 deletions(-) -- 12345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8
Re: [Qemu-devel] [PATCH 00/12] trace: [tcg] Allow tracing guest events in TCG-generated code
On 02/04/2014 07:02 AM, Peter Maydell wrote:
On 4 February 2014 14:57, Richard Henderson r...@twiddle.net wrote:
I suppose I have no major objection to the feature, although frankly it's
not especially exciting. I can't really imagine ever wanting to bulk trace
all of the helpers. Tracing specific helpers on a target-by-target basis,
sure. But that can be done just as easily as adding tracing code to any
other bit of C.
I think the things people seem to actually want (judging
from occasional postings to the list) are things like:
* trace all guest memory accesses
* trace all guest instruction executions
Does this patchset get us usefully towards that kind of thing?
Not sure...
If that's the goal, I would suggest that they do not. One does not need to
hook all of the helpers in order to achieve that.
A hook in tcg_gen_qemu_{ld,st}_i{32,64} to (conditionally) emit a call to a
helper to log the access gets you all (non-execution) guest memory accesses.
Guest instruction executions is quite a bit harder, of course. But any start
in that direction could be done through a pair of trace events: Log the insn
address range covered by a TB + a uuid at translation time; log the uuid at the
start of execution of the TB. A script should be able to put the two together
to complete the trace.
r~
[Qemu-devel] file_ram_alloc: unify mem-path, mem-prealloc error handling
-mem-prealloc asks to preallocate memory residing on -mem-path path.
Currently QEMU exits in case:
- Memory file has been created but allocation via explicit write
fails.
And it fallbacks to malloc in case:
- Querying huge page size fails.
- Lack of sync MMU support.
- Open fails.
- mmap fails.
Have the same behaviour for all cases: fail in case -mem-path and
-mem-prealloc are specified for regions where the requested size is
suitable for hugepages.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/exec.c b/exec.c
index 9ad0a4b..1da1ba7 100644
--- a/exec.c
+++ b/exec.c
@@ -996,7 +996,7 @@ static void *file_ram_alloc(RAMBlock *block,
hpagesize = gethugepagesize(path);
if (!hpagesize) {
-return NULL;
+goto error;
}
if (memory hpagesize) {
@@ -1005,7 +1005,7 @@ static void *file_ram_alloc(RAMBlock *block,
if (kvm_enabled() !kvm_has_sync_mmu()) {
fprintf(stderr, host lacks kvm mmu notifiers, -mem-path
unsupported\n);
-return NULL;
+goto error;
}
/* Make name safe to use with mkstemp by replacing '/' with '_'. */
@@ -1023,7 +1023,7 @@ static void *file_ram_alloc(RAMBlock *block,
if (fd 0) {
perror(unable to create backing store for hugepages);
g_free(filename);
-return NULL;
+goto error;
}
unlink(filename);
g_free(filename);
@@ -1043,7 +1043,7 @@ static void *file_ram_alloc(RAMBlock *block,
if (area == MAP_FAILED) {
perror(file_ram_alloc: can't mmap RAM pages);
close(fd);
-return (NULL);
+goto error;
}
if (mem_prealloc) {
@@ -1087,6 +1087,12 @@ static void *file_ram_alloc(RAMBlock *block,
block-fd = fd;
return area;
+
+error:
+if (mem_prealloc) {
+exit(1);
+}
+return NULL;
}
#else
static void *file_ram_alloc(RAMBlock *block,
