Re: [Qemu-devel] [Qemu-trivial] [PATCH] vl: remove (max_cpus > 255) check from smp_parse
Il 14/02/2014 07:56, Alexey Kardashevskiy ha scritto: > Subject: [PATCH V17 04/11] NUMA: convert -numa option to use OptsVisitor > Message-Id: <1386143939-19142-5-git-send-email-gaowanl...@cn.fujitsu.com> > http://article.gmane.org/gmane.comp.emulators.qemu/244826 Any progress with this? Thanks. Yes, there was some progress though for some reason it happened onlist. Igor/Wanlong, can you send the first patches of the "common" NUMA/memory series, i.e. excluding the memdev backend? Paolo
Re: [Qemu-devel] [PATCH v4 0/8] spapr: bootindex support
Il 14/02/2014 04:25, Alexey Kardashevskiy ha scritto: Nobody seems picking up the bits I am interested in from this :-/ What can I possibly do to get this in upstream?... I feel I am doing something systematically wrong but nobody is telling me what exactly. Thanks. No, you're not. Ping agraf on IRC if he doesn't answer. Paolo
Re: [Qemu-devel] [Qemu-trivial] [PATCH] vl: remove (max_cpus > 255) check from smp_parse
On 12/04/2013 11:48 PM, Eduardo Habkost wrote:
> On Wed, Dec 04, 2013 at 04:50:59PM +1100, Alexey Kardashevskiy wrote:
>> On 12/04/2013 01:47 AM, Eduardo Habkost wrote:
>>> On Tue, Dec 03, 2013 at 02:30:48PM +0100, Andreas Färber wrote:
Am 03.12.2013 00:03, schrieb Alexey Kardashevskiy:
> On 12/03/2013 09:09 AM, Andreas Färber wrote:
>> Am 02.12.2013 18:06, schrieb Michael Tokarev:
>>> 25.11.2013 07:39, Alexey Kardashevskiy wrote:
Since modern POWER7/POWER8 chips can have more that 256 CPU threads
(>2000 actually), remove this check from smp_parse.
The CPUs number is still checked against machine->max_cpus and this
check
should be enough not to break other archs.
>>
>> "should be" is not exactly the highest level of confidence for a
>> "trivial" patch... :/
[...]
>> Alexey, did you actually check that, e.g., x86 machines don't break with
>> 256 or 257 CPUs now?
>
> PC_DEFAULT_MACHINE_OPTIONS sets it to 255. And I cannot find any machine
> which would not define max_cpus, have I missed any?
If you've actually *checked* the other machines' code then fine with me,
just say so in the commit message. :)
>>>
>>> I just grepped for "max_cpus" and checked every match. The largest
>>> values I found were:
>>>
>>> hw/ppc/spapr.c: 256
>>> s390: 255
>>> pc: 255
>>>
>>> All the rest had values <= 32.
>>>
>>> Machines with missing max_cpus value shouldn't be a problem, as
>>> max_cpus==0 is interpreted as 1 by the vl.c code.
>>>
>>> But we still need to add a check for max_cpus > machine->max_cpus to
>>> vl.c, before we eliminate the smp_parse() check.
>>
>>
>> Since smp_parse() checks if (max_cpus >= smp_cpus), this should just work:
>>
>> diff --git a/vl.c b/vl.c
>> index e6ed260..544165a 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -3882,9 +3882,9 @@ int main(int argc, char **argv, char **envp)
>> smp_parse(qemu_opts_find(qemu_find_opts("smp-opts"), NULL));
>>
>> machine->max_cpus = machine->max_cpus ?: 1; /* Default to UP */
>> -if (smp_cpus > machine->max_cpus) {
>> +if (max_cpus > machine->max_cpus) {
>> fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max
>> cpus "
>> -"supported by machine `%s' (%d)\n", smp_cpus,
>> machine->name,
>> +"supported by machine `%s' (%d)\n", max_cpus,
>> machine->name,
>> machine->max_cpus);
>> exit(1);
>> }
>>
>>
>>> There's also this, at main():
>>>
>>> if (i == nb_numa_nodes) {
>>> for (i = 0; i < max_cpus; i++) {
>>> set_bit(i, node_cpumask[i % nb_numa_nodes]);
>>> }
>>> }
>>>
>>> node_cpumask[] is initialized using bitmap_new(MAX_CPUMASK_BITS), and
>>> MAX_CPUMASK_BITS is 255. To fix this, we can initialize node_cpumask[] using
>>> max_cpus instead, if we initialize it after smp_parse().
>>
>>
>> Nope. At the moment when we parse -numa in vl.c, we may not know yet what
>> machine is going to be used and machines can have different max_cpus.
>
> This will be changed by:
>
> Subject: [PATCH V17 04/11] NUMA: convert -numa option to use OptsVisitor
> Message-Id: <1386143939-19142-5-git-send-email-gaowanl...@cn.fujitsu.com>
> http://article.gmane.org/gmane.comp.emulators.qemu/244826
Any progress with this? Thanks.
>>
>> For now, I would simply change MAX_CPUMASK_BITS to something crazy, like
>> 16384 (2KB per numa node), I hope QEMU can survive such a memory waste :)
>>
>> Ok?
>
> I'm OK with that as long the code has proper checks in case max_cpus
> gets set to a crazily large value (larger than MAX_CPUMASK_BITS) in the
> far future, or if we prevent max_cpus from being larger than
> MAX_CPUMASK_BITS.
>
--
Alexey
Re: [Qemu-devel] [PATCH v4 06/22] cpu: Add per-cpu address space
On Tue, Feb 11, 2014 at 08:52:11PM +0100, Andreas Färber wrote: > Edgar, > > Am 03.02.2014 10:44, schrieb Edgar E. Iglesias: > > From: "Edgar E. Iglesias" > > > > Signed-off-by: Edgar E. Iglesias > > --- > > cpus.c | 2 ++ > > cputlb.c| 7 --- > > exec.c | 27 +++ > > include/exec/exec-all.h | 1 + > > include/exec/softmmu_template.h | 6 -- > > include/qom/cpu.h | 3 +++ > > 6 files changed, 33 insertions(+), 13 deletions(-) > > This CPU patch did not get a Reviewed-by or Acked-by from me and was > still committed, even without indicating so here! Had you asked me, you > would've got one and my go-ahead, but what annoys me is that I learned > about you committing this through it breaking my qom-cpu-13 branch with > a conflict in target-i386/helper.c in later patch I had not yet > reviewed... :/ > > Please a) indicate you committed patches as an email reply to that > series and b) read the replies - me, Peter and Paolo were converging on > giving me the okay to take a subset of this series into qom-cpu, you Sorry, I must have missed that part of the discussion. If the merge conflict was bad let me know and I'd be happy to help. Cheers, Edgar > neither asked nor did anyone propose committing them directly on the > mailing list. > > Thanks, > 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 2/2] tests-ppc64: test for -device spapr-pci-host-bridge
On 02/11/2014 02:48 AM, Andreas Färber wrote:
> Am 10.02.2014 04:52, schrieb Alexey Kardashevskiy:
>> This adds a test if SPAPR PHB can be added via the command line.
>>
>> Signed-off-by: Alexey Kardashevskiy
>> ---
>> tests/Makefile | 2 ++
>> tests/spapr-phb-test.c | 28
>> 2 files changed, 30 insertions(+)
>> create mode 100644 tests/spapr-phb-test.c
>>
>> diff --git a/tests/Makefile b/tests/Makefile
>> index 3a00ea7..303225e 100644
>> --- a/tests/Makefile
>> +++ b/tests/Makefile
>> @@ -117,6 +117,7 @@ check-qtest-s390x-y += tests/qom-test$(EXESUF)
>> check-qtest-unicore32-y += tests/qom-test$(EXESUF)
>> check-qtest-xtensa-y += tests/qom-test$(EXESUF)
>> check-qtest-xtensaeb-y = $(check-qtest-xtensa-y)
>> +check-qtest-ppc64-y += tests/spapr-phb-test$(EXESUF)
>>
>> check-qapi-schema-y := $(addprefix tests/qapi-schema/, \
>> comments.json empty.json funny-char.json indented-expr.json \
>> @@ -203,6 +204,7 @@ libqos-omap-obj-y = $(libqos-obj-y)
>> tests/libqos/i2c-omap.o
>> tests/rtc-test$(EXESUF): tests/rtc-test.o
>> tests/m48t59-test$(EXESUF): tests/m48t59-test.o
>> tests/endianness-test$(EXESUF): tests/endianness-test.o
>> +tests/spapr-phb-test$(EXESUF): tests/spapr-phb-test.o $(libqos-obj-y)
>> tests/fdc-test$(EXESUF): tests/fdc-test.o
>> tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y)
>> tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
>> diff --git a/tests/spapr-phb-test.c b/tests/spapr-phb-test.c
>> new file mode 100644
>> index 000..8cad354
>> --- /dev/null
>> +++ b/tests/spapr-phb-test.c
>> @@ -0,0 +1,28 @@
>> +/*
>> + * QTest testcase for SPAPR PHB
>> + *
>
> Missing some IBM or aik copyright?
>
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +#include
>> +
>> +#include "libqtest.h"
>> +
>> +#define TYPE_SPAPR_PCI_HOST_BRIDGE "spapr-pci-host-bridge"
>> +
>> +static void test_phb_device(void)
>> +{
>> +qtest_start("-device " TYPE_SPAPR_PCI_HOST_BRIDGE ",index=100");
>> +
>> +qtest_end();
>> +}
>> +
>> +int main(int argc, char **argv)
>> +{
>> +g_test_init(&argc, &argv, NULL);
>> +
>> +qtest_add_func("/qmp/phb_device", test_phb_device);
>> +
>> +return g_test_run();
>> +}
>> +
>
> Trailing white line FWIW.
>
> This is looking good, thanks for your work. Apart from the device
> there's nothing ppc-specific in here, so I might take it through
> qom-next. One nit here is the test name, which I think should rather be
> /spapr-phb/device (nothing QMP-specific in there) - I could tweak that
> for you.
>
> Another question is, do you plan to test variations of the device?
> Otherwise I would suggest to place the qtest_start() and qtest_end()
> into main(), so that individual future tests can test certain
> functionalities on the instantiated device rather than repeatedly
> launching QEMU processes.
Is this better? It does the job.
I am not quite sure what qtest_add_func() is for. Is there any good example
of calling such a function via json or whatever it is? Thanks.
diff --git a/tests/spapr-phb-test.c b/tests/spapr-phb-test.c
new file mode 100644
index 000..11f186c
--- /dev/null
+++ b/tests/spapr-phb-test.c
@@ -0,0 +1,24 @@
+/*
+ * QTest testcase for SPAPR PHB
+ *
+ * Authors:
+ * Alexey Kardashevskiy
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include
+
+#include "libqtest.h"
+
+#define TYPE_SPAPR_PCI_HOST_BRIDGE "spapr-pci-host-bridge"
+
+int main(int argc, char **argv)
+{
+g_test_init(&argc, &argv, NULL);
+
+qtest_start("-device " TYPE_SPAPR_PCI_HOST_BRIDGE ",index=100");
+qtest_end();
+
+return g_test_run();
+}
--
Alexey
Re: [Qemu-devel] [PATCH 1/2] tests-ppc64: add to cleanup rule
On 02/11/2014 07:32 AM, Andreas Färber wrote: > Am 10.02.2014 04:52, schrieb Alexey Kardashevskiy: >> This adds $(check-qtest-ppc64-y) to the check-clean rule. >> >> Signed-off-by: Alexey Kardashevskiy > > Nice catch! > >> --- >> tests/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tests/Makefile b/tests/Makefile >> index 0aaf657..3a00ea7 100644 >> --- a/tests/Makefile >> +++ b/tests/Makefile >> @@ -319,7 +319,7 @@ check-block: $(patsubst %,check-%, $(check-block-y)) >> check: check-qapi-schema check-unit check-qtest >> check-clean: >> $(MAKE) -C tests/tcg clean >> -rm -rf $(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) >> $(check-qtest-sparc64-y) $(check-qtest-sparc-y) tests/*.o >> $(QEMU_IOTESTS_HELPERS-y) >> +rm -rf $(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) >> $(check-qtest-sparc64-y) $(check-qtest-sparc-y) $(check-qtest-ppc64-y) >> tests/*.o $(QEMU_IOTESTS_HELPERS-y) >> >> clean: check-clean >> > > Can we use a $(foreach ...) for $(check-qtest-*-y) like Peter did for > adding qom-test? > > http://patchwork.ozlabs.org/patch/313650/ Like this? Against what should I rebase my patches and repost them? diff --git a/tests/Makefile b/tests/Makefile index 94b32b7..2577843 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -323,7 +323,9 @@ check-block: $(patsubst %,check-%, $(check-block-y)) check: check-qapi-schema check-unit check-qtest check-clean: $(MAKE) -C tests/tcg clean - rm -rf $(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) $(check-qtest-sparc64-y) $(check-qtest-sparc-y) t + $(eval rmlist = $(check-unit-y) tests/*.o $(QEMU_IOTESTS_HELPERS-y)) + $(foreach target,$(SYSEMU_TARGET_LIST), $(eval rmlist += $(check-qtest-$(target)-y))) + rm -rf $(rmlist) clean: check-clean -- Alexey
Re: [Qemu-devel] [RFC PATCH V2 3/5] qapi script: add event support by qapi-event.py
于 2014/1/7 11:24, Wenchao Xia 写道:
+
+
+# Following are the functions that generate event behavior control
functions.
+# Those functions are put here in the qapi-event.c, since it need
to include
+# qapi-event.h for the event enum type declaration, put them in
other file
+# requiring other file include qapi-event.h, causing a cross
including. For
+# example: if we have qmp-event.c and qmp-event.h, then qmp-event.c
+# ->qmp-event.h->qapi-event.h, qapi-event.c->qmp-event.h. Another
problem
+# follow: test-qapi-event.c will meet event enum double declaration
since it
+# include both test-qapi-event.h and qmp-event.h. One solution is
putting event
+# enum declaration in a separate header file, but then qmp-event.h
need to
+# include test-qapi-event.h or qapi-event.h on compile time
condition. So the
+# easist way is, just generate them here.
+
+def generate_event_behavior_control_decl(event_enum_name):
+ret = mcgen('''
+
+typedef void (*QAPIEventFuncEmit)(%(event_enum_name)s ev,
+ QDict *dict,
+ Error **errp);
Why does the emit function need 'ev'? Doesn't 'dict' contain all the
info it needs? Also, it's better to rename it to 'event' or 'qmp_event'.
ev is for rate limit. I didn't move rate limit logic from callback to
internal, mainly because it is a generated function, which seems
too complex. And the genrated function was not moved into a separte
file mainly because the enum and including issue, see the comments
in script above.
The problem is enum is changing, so the new file include it need
to recompile, for example, test schema and qapi-schema.json may
force recompile twice, I am not sure if it is good to do
some tricks in build system.
I am going to respin this series after sync with upstream.
"ev" will be removed, and will try use a runtime call to solve
issue above.
Re: [Qemu-devel] [PATCH v4 0/8] spapr: bootindex support
On 01/22/2014 11:17 PM, Alexey Kardashevskiy wrote: > On 01/22/2014 09:16 PM, Paolo Bonzini wrote: >> Il 22/01/2014 05:19, Alexey Kardashevskiy ha scritto: >>> On 12/11/2013 09:22 PM, Alexey Kardashevskiy wrote: With the great help from Paolo, I am presenting yet another try of bootindex support on sPAPR, this time with some QOM fixes. Details are in the commit messages. Please, comment. Thanks. Alexey Kardashevskiy (5): boot: extend get_boot_devices_list() to ignore suffixes spapr-llan: add to boot device list spapr-vio: fix firmware names qdev: introduce FWPathProvider interface spapr: define interface to fix device pathname Hervé Poussineau (1): qom: detect bad reentrance during object_class_foreach Paolo Bonzini (2): qom: do not register interface "types" in the type table vl: allow customizing the class of /machine hw/core/Makefile.objs | 1 + hw/core/fw-path-provider.c| 34 ++ hw/core/qdev.c| 18 +- hw/net/spapr_llan.c | 3 ++ hw/nvram/fw_cfg.c | 2 +- hw/ppc/spapr.c| 80 ++- hw/ppc/spapr_vio.c| 2 ++ include/hw/boards.h | 1 + include/hw/fw-path-provider.h | 31 + include/sysemu/sysemu.h | 2 +- qom/object.c | 17 +++-- tests/Makefile| 1 + vl.c | 11 -- 13 files changed, 193 insertions(+), 10 deletions(-) create mode 100644 hw/core/fw-path-provider.c create mode 100644 include/hw/fw-path-provider.h >>> >>> >>> Some bits from this went upstream but none of them is mine. What am I >>> missing here? Thanks. >> >> No idea, perhaps it's because the same patches were present in multiple >> series? Alex, are you picking up what's left? >> >> Paolo > > > In the "Re: [Qemu-devel] [PATCH 2/2] qom: detect bad reentrance during > object_class_foreach" thread Andreas told me: > > === > Be patient. > > 1) I am on holidays and thus not available full-time. > 2) Alex has already sent out his ppc PULL, so no urgency. > 3) As mentioned, I plan to post QOM and CPU PULLs later today. > > And no, you don't need to repost after parts of your series get applied > pretty much unmodified. > === > > So I wonder if I am not just patient enough :) Nobody seems picking up the bits I am interested in from this :-/ What can I possibly do to get this in upstream?... I feel I am doing something systematically wrong but nobody is telling me what exactly. Thanks. -- Alexey
Re: [Qemu-devel] [PATCH V6 00/10] qapi script: support enum as discriminator and better enum name
于 2014/2/13 23:23, Markus Armbruster 写道:
> Wenchao Xia writes:
>
>> This series address two issues:
>>
>> 1. support using enum as discriminator in union.
>> For example, if we have following define in qapi schema:
>> { 'enum': 'EnumOne',
>>'data': [ 'value1', 'value2', 'value3' ] }
>>
>> { 'type': 'UserDefBase0',
>>'data': { 'base-string0': 'str', 'base-enum0': 'EnumOne' } }
>>
>> Before this series, discriminator in union must be a string, and a
>> hidden enum type as discriminator is generated. After this series,
>> qapi schema can directly use predefined enum type:
>> { 'union': 'UserDefEnumDiscriminatorUnion',
>>'base': 'UserDefBase0',
>>'discriminator' : 'base-enum0',
>>'data': { 'value1' : 'UserDefA',
>> 'value2' : 'UserDefInherit',
>> 'value3' : 'UserDefB' } }
>>
>> The benefit is that every thing is defined explicitly in schema file,
>> the discriminator enum type can be used in other API define in schema,
>> and a compile time check will be put to verify the correctness according
>> to enum define. Currently BlockdevOptions used discriminator which can
>> be converted, in the future other union can also use enum discriminator.
>>
>> The implement is done by:
>> 1.1 remember the enum defines by qapi scripts.(patch 1)
>> 1.2 use the remembered enum define to check correctness at compile
>> time.(patch 3), more strict check(patch 2)
>> 1.3 use the same enum name generation rule to avoid C code mismatch,
>> esp for "case [ENUM_VALUE]" in qapi-visit.c.(patch 4,5)
>> 1.4 switch the code path, when pre-defined enum type is used as
>> discriminator,
>> don't generate a hidden enum type, use the enum type instead, add
>> docs/qapi-code-gen.txt.(Patch 6)
>> 1.5 test case shows how it looks like.(Patch 7)
>> 1.6 convert BlockdevOptions. (Patch 8)
>>
>> 2. Better enum name generation
>> Before this patch, AIOContext->A_I_O_CONTEXT, after this patch,
>> AIOContet->AIO_CONTEXT. Since previous patch has foldered enum
>> name generation codes into one function, it is done easily by modifying
>> it.(Patch 9)
>
> Sorry for the lateness of my review. I like this series, but I had a
> few questions related to error reporting. Also, the new errors lack
> tests.
>
> My offer to rebase it on top of my "[PATCH v2 00/13] qapi: Test coverage
> & clean up generated code" stands.
>
As patch 9 is the conflict patch and easy to rebase, I am fine if you
want to apply yours first and rebase mine.
About the error reporting, I am not sure which way is better. If you
like qapi.py do it, I can send a patch later moving the code, since it
is easier than modify multiple patches in this series.
s
Re: [Qemu-devel] [PATCH V6 09/10] tests: add cases for inherited struct and union with discriminator
于 2014/2/13 23:11, Luiz Capitulino 写道: On Thu, 13 Feb 2014 15:53:30 +0100 Markus Armbruster wrote: Wenchao Xia writes: Test for inherit and complex union. This patch conflicts badly with my test coverage work in "[PATCH v2 00/13] qapi: Test coverage & clean up generated code". My series systematically covers code generation in scripts/qapi*py, and that takes me seven patches. If I put your patch first, mine all explode, and I get to start over. Putting my series first looks far easier to resolve, because only this one patch conflicts. Would you mind me rebasing your series on top of mine? If it's only this patch that causes conflicts, what about the following: 1. I apply patches 1-8 plus patch 10 2. Markus rebases patch 9 and adds it to his series 3. Markus post a new version Does this work for everyone? The only drawback is that both series will miss today's boat, but this would happen at this point anyway. I am fine with it.
Re: [Qemu-devel] [PATCH V6 03/10] qapi script: check correctness of discriminator values in union
于 2014/2/13 23:14, Markus Armbruster 写道:
> Wenchao Xia writes:
>
>> It will check whether the values specified are written correctly,
>> and whether all enum values are covered, when discriminator is a
>> pre-defined enum type
>>
>> Signed-off-by: Wenchao Xia
>> Reviewed-by: Eric Blake
>> ---
>> scripts/qapi-visit.py | 17 +
>> scripts/qapi.py | 31 +++
>> 2 files changed, 48 insertions(+), 0 deletions(-)
>>
>> diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
>> index 65f1a54..c0efb5f 100644
>> --- a/scripts/qapi-visit.py
>> +++ b/scripts/qapi-visit.py
>> @@ -255,6 +255,23 @@ def generate_visit_union(expr):
>> assert not base
>> return generate_visit_anon_union(name, members)
>>
>> +# If discriminator is specified and it is a pre-defined enum in schema,
>> +# check its correctness
>> +enum_define = discriminator_find_enum_define(expr)
>> +if enum_define:
>> +for key in members:
>> +if not key in enum_define["enum_values"]:
>> +sys.stderr.write("Discriminator value '%s' is not found in "
>> + "enum '%s'\n" %
>> + (key, enum_define["enum_name"]))
>> +sys.exit(1)
>
> Can this happen? If yes, why isn't it diagnosed in qapi.py, like all
> the other semantic errors?
>
I think the parse procedure contains two part:
1 read qapi-schema.json and parse it into exprs.
2 translate exprs into final output.
Looking at qapi.py, qapi-visit.py, qapi-types.py, it seems qapi.py is
in charge of step 1 handling literal error, and other two script are in
charge of step 2. The above error can be only detected in step 2 after
all enum defines are remembered in step 1, so I didn't add those things
into qapi.py.
I guess you want to place the check inside parse_schema() to let
test case detect it easier, one way to go is, let qapi.py do checks
for step 2:
def parse_schema(fp):
try:
schema = QAPISchema(fp)
except QAPISchemaError, e:
print >>sys.stderr, e
exit(1)
exprs = []
for expr in schema.exprs:
if expr.has_key('enum'):
add_enum(expr['enum'])
elif expr.has_key('union'):
add_union(expr)
add_enum('%sKind' % expr['union'])
elif expr.has_key('type'):
add_struct(expr)
exprs.append(expr)
+for expr in schema.exprs:
+if expr.has_key('union'):
+#check code
return exprs
This way qapi.py can detect such errors. Disadvantage is that,
qapi.py is invloved for step 2 things, so some code in qapi.py
and qapi-visit.py may be dupicated, here the "if union...
discriminator" code may appear in both qapi.py and qapi-visit.py.
>> +for key in enum_define["enum_values"]:
>> +if not key in members:
>> +sys.stderr.write("Enum value '%s' is not covered by a
>> branch "
>> + "of union '%s'\n" %
>> + (key, name))
>> +sys.exit(1)
>> +
>
> Likewise.
>
>> ret = generate_visit_enum('%sKind' % name, members.keys())
>>
>> if base:
>> diff --git a/scripts/qapi.py b/scripts/qapi.py
>> index cf34768..0a3ab80 100644
>> --- a/scripts/qapi.py
>> +++ b/scripts/qapi.py
>> @@ -385,3 +385,34 @@ def guardend(name):
>>
>> ''',
>>name=guardname(name))
>> +
The funtions below are likely helper funtions, I planed to put them
into qapi_helper.py, but they are not much so kepted for easy.
>> +# This function can be used to check whether "base" is valid
>> +def find_base_fields(base):
>> +base_struct_define = find_struct(base)
>> +if not base_struct_define:
>> +return None
>> +return base_struct_define.get('data')
>> +
>> +# Return the discriminator enum define, if discriminator is specified in
>> +# @expr and it is a pre-defined enum type
>> +def discriminator_find_enum_define(expr):
>> +discriminator = expr.get('discriminator')
>> +base = expr.get('base')
>> +
>> +# Only support discriminator when base present
>> +if not (discriminator and base):
>> +return None
>> +
>> +base_fields = find_base_fields(base)
>> +
>> +if not base_fields:
>> +raise StandardError("Base '%s' is not a valid type\n"
>> +% base)
>
> Why not QAPISchemaError, like for other semantic errors?
>
I think QAPISchemaError is a literal error of step 1, here
it can't be used unless we record the text/line number belong to
each expr.
>> +
>> +discriminator_type = base_fields.get(discriminator)
>> +
>> +if not discriminator_type:
>> +raise StandardError("Discriminator '%s' not found in schema\n"
>> +% discriminator)
>
> Likewise.
>
>> +
>> +return find_enum(discriminator_type)
>
> All errors should have a test in tests/qapi-
Re: [Qemu-devel] [PATCH V6 02/10] qapi script: add check for duplicated key
于 2014/2/13 23:14, Markus Armbruster 写道: > Wenchao Xia writes: > >> It is bad that same key was specified twice, especially when a union have >> two branches with same condition. This patch can prevent it. >> >> Signed-off-by: Wenchao Xia >> Reviewed-by: Eric Blake >> --- >> scripts/qapi.py |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/scripts/qapi.py b/scripts/qapi.py >> index aec6bbb..cf34768 100644 >> --- a/scripts/qapi.py >> +++ b/scripts/qapi.py >> @@ -116,6 +116,8 @@ class QAPISchema: >> if self.tok != ':': >> raise QAPISchemaError(self, 'Expected ":"') >> self.accept() >> +if key in expr: >> +raise QAPISchemaError(self, 'Duplicated key "%s"' % key) >> expr[key] = self.get_expr(True) >> if self.tok == '}': >> self.accept() > > All errors should have a test in tests/qapi-schema/. I can try to add > tests for you when I rebase your 09/10. > I considered error path test before but didn't find a good place to go. It would be great if you can add one.
[Qemu-devel] [PATCH] spapr-vlan: flush queue whenever can_receive can go from false to true
When the guests adds buffers to receive queue, the network device
should flush its queue of pending packets. This is done with
qemu_flush_queued_packets.
This adds a call to qemu_flush_queued_packets() which wakes up the main
loop and let QEMU update the network device status which now is "can
receive". The patch basically does the same thing as e8b4c68 does.
Suggested-by: Max Filippov
Signed-off-by: Alexey Kardashevskiy
---
hw/net/spapr_llan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
index 72b0513..a7f00db 100644
--- a/hw/net/spapr_llan.c
+++ b/hw/net/spapr_llan.c
@@ -408,6 +408,8 @@ static target_ulong h_add_logical_lan_buffer(PowerPCCPU
*cpu,
dev->rx_bufs++;
+qemu_flush_queued_packets(qemu_get_queue(dev->nic));
+
DPRINTF("h_add_logical_lan_buffer(): Added buf ptr=%d rx_bufs=%d"
" bd=0x%016llx\n", dev->add_buf_ptr, dev->rx_bufs,
(unsigned long long)buf);
--
1.8.4.rc4
Re: [Qemu-devel] Multi GPU passthrough via VFIO
On Fri, 2014-02-14 at 01:01 +0100, Maik Broemme wrote: > Hi Alex, > > Maik Broemme wrote: > > Hi Alex, > > > > Alex Williamson wrote: > > > On Fri, 2014-02-07 at 01:22 +0100, Maik Broemme wrote: > > > > Interesting is the diff between 1st and 2nd boot, so if I do the lspci > > > > prior to the booting. The only difference between 1st start and 2nd > > > > start are: > > > > > > > > --- 001-lspci.290x.before.1st.log 2014-02-07 01:13:41.498827928 > > > > +0100 > > > > +++ 004-lspci.290x.before.2nd.log 2014-02-07 01:16:50.966611282 > > > > +0100 > > > > @@ -24,7 +24,7 @@ > > > > ClockPM- Surprise- LLActRep- BwNot- > > > > LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- > > > > CommClk+ > > > > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > > > > - LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ > > > > DLActive- BWMgmt- ABWMgmt- > > > > + LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > > > > DLActive- BWMgmt- ABWMgmt- > > > > DevCap2: Completion Timeout: Not Supported, > > > > TimeoutDis-, LTR-, OBFF Not Supported > > > > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, > > > > LTR-, OBFF Disabled > > > > LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- > > > > SpeedDis- > > > > @@ -33,13 +33,13 @@ > > > > LnkSta2: Current De-emphasis Level: -3.5dB, > > > > EqualizationComplete-, EqualizationPhase1- > > > > EqualizationPhase2-, EqualizationPhase3-, > > > > LinkEqualizationRequest- > > > > Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ > > > > - Address: Data: > > > > + Address: fee0 Data: > > > > Capabilities: [100 v1] Vendor Specific Information: ID=0001 > > > > Rev=1 Len=010 > > > > Capabilities: [150 v2] Advanced Error Reporting > > > > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- > > > > UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > > > > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- > > > > UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > > > > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- > > > > UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > > > > - CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > > > > NonFatalErr- > > > > + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > > > > NonFatalErr+ > > > > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > > > > NonFatalErr+ > > > > AERCap: First Error Pointer: 00, GenCap+ CGenEn- > > > > ChkCap+ ChkEn- > > > > Capabilities: [270 v1] #19 > > > > > > > > After that if I do suspend-to-ram / resume trick I have again lspci > > > > output from before 1st boot. > > > > > > The Link Status change after X is stopped seems the most interesting to > > > me. The MSI change is probably explained by the MSI save/restore of the > > > device, but should be harmless since MSI is disabled. I'm a bit > > > surprised the Correctable Error Status in the AER capability didn't get > > > cleared. I would have thought that a bus reset would have caused the > > > link to retrain back to the original speed/width as well. Let's check > > > that we're actually getting a bus reset, try this in addition to the > > > previous qemu patch. This just enables debug logging for the bus resest > > > function. Thanks, > > > > > > > Below are the outputs from 2 boots, VGA, load fglrx and start X. (2nd > > time X gets killed and oops happened) > > > > - 1st boot: > > > > vfio: vfio_pci_hot_reset(:01:00.1) multi > > vfio: :01:00.1: hot reset dependent devices: > > vfio: :01:00.0 group 1 > > vfio: :01:00.1 group 1 > > vfio: :01:00.1 hot reset: Success > > vfio: vfio_pci_hot_reset(:01:00.1) one > > vfio: :01:00.1: hot reset dependent devices: > > vfio: :01:00.0 group 1 > > vfio: vfio: found another in-use device :01:00.0 > > vfio: vfio_pci_hot_reset(:01:00.0) one > > vfio: :01:00.0: hot reset dependent devices: > > vfio: :01:00.0 group 1 > > vfio: :01:00.1 group 1 > > vfio: vfio: found another in-use device :01:00.1 > > > > - 2nd boot: > > > > vfio: vfio_pci_hot_reset(:01:00.1) multi > > vfio: :01:00.1: hot reset dependent devices: > > vfio: :01:00.0 group 1 > > vfio: :01:00.1 group 1 > > vfio: :01:00.1 hot reset: Success > > vfio: vfio_pci_hot_reset(:01:00.1) one > > vfio: :01:00.1: hot reset dependent devices: > > vfio: :01:00.0 group 1 > > vfio: vfio: found another in-use device :01:00.0 > > vfio: vfio_pci_hot_reset(:01:00.0) one > > vfio: :01:00.0: hot reset dependent devices: > > vfio: :01:00.0 group 1 > > vfio: :01:00.1
Re: [Qemu-devel] Multi GPU passthrough via VFIO
Hi Alex, Maik Broemme wrote: > Hi Alex, > > Alex Williamson wrote: > > On Fri, 2014-02-07 at 01:22 +0100, Maik Broemme wrote: > > > Interesting is the diff between 1st and 2nd boot, so if I do the lspci > > > prior to the booting. The only difference between 1st start and 2nd > > > start are: > > > > > > --- 001-lspci.290x.before.1st.log 2014-02-07 01:13:41.498827928 +0100 > > > +++ 004-lspci.290x.before.2nd.log 2014-02-07 01:16:50.966611282 +0100 > > > @@ -24,7 +24,7 @@ > > > ClockPM- Surprise- LLActRep- BwNot- > > > LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+ > > > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > > > - LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ > > > DLActive- BWMgmt- ABWMgmt- > > > + LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > > > DLActive- BWMgmt- ABWMgmt- > > > DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, > > > OBFF Not Supported > > > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, > > > OBFF Disabled > > > LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- > > > @@ -33,13 +33,13 @@ > > > LnkSta2: Current De-emphasis Level: -3.5dB, > > > EqualizationComplete-, EqualizationPhase1- > > >EqualizationPhase2-, EqualizationPhase3-, > > > LinkEqualizationRequest- > > > Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ > > > - Address: Data: > > > + Address: fee0 Data: > > > Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 > > > Len=010 > > > Capabilities: [150 v2] Advanced Error Reporting > > > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > > > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > > > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- > > > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > > > - CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- > > > + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > > > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > > > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- > > > Capabilities: [270 v1] #19 > > > > > > After that if I do suspend-to-ram / resume trick I have again lspci > > > output from before 1st boot. > > > > The Link Status change after X is stopped seems the most interesting to > > me. The MSI change is probably explained by the MSI save/restore of the > > device, but should be harmless since MSI is disabled. I'm a bit > > surprised the Correctable Error Status in the AER capability didn't get > > cleared. I would have thought that a bus reset would have caused the > > link to retrain back to the original speed/width as well. Let's check > > that we're actually getting a bus reset, try this in addition to the > > previous qemu patch. This just enables debug logging for the bus resest > > function. Thanks, > > > > Below are the outputs from 2 boots, VGA, load fglrx and start X. (2nd > time X gets killed and oops happened) > > - 1st boot: > > vfio: vfio_pci_hot_reset(:01:00.1) multi > vfio: :01:00.1: hot reset dependent devices: > vfio: :01:00.0 group 1 > vfio: :01:00.1 group 1 > vfio: :01:00.1 hot reset: Success > vfio: vfio_pci_hot_reset(:01:00.1) one > vfio: :01:00.1: hot reset dependent devices: > vfio: :01:00.0 group 1 > vfio: vfio: found another in-use device :01:00.0 > vfio: vfio_pci_hot_reset(:01:00.0) one > vfio: :01:00.0: hot reset dependent devices: > vfio: :01:00.0 group 1 > vfio: :01:00.1 group 1 > vfio: vfio: found another in-use device :01:00.1 > > - 2nd boot: > > vfio: vfio_pci_hot_reset(:01:00.1) multi > vfio: :01:00.1: hot reset dependent devices: > vfio: :01:00.0 group 1 > vfio: :01:00.1 group 1 > vfio: :01:00.1 hot reset: Success > vfio: vfio_pci_hot_reset(:01:00.1) one > vfio: :01:00.1: hot reset dependent devices: > vfio: :01:00.0 group 1 > vfio: vfio: found another in-use device :01:00.0 > vfio: vfio_pci_hot_reset(:01:00.0) one > vfio: :01:00.0: hot reset dependent devices: > vfio: :01:00.0 group 1 > vfio: :01:00.1 group 1 > vfio: vfio: found another in-use device :01:00.1 > Did you had already a chance to look into it or anything else I can help with? > > Alex > > > > diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c > > index 8db182f..7fec259 100644 > > --- a/hw/misc/vfio.c > > +++ b/hw/misc/vfio.c > > @@ -2927,6 +2927,10 @@ static bool vfio_pci_host_match(PCIHostDeviceAddress > > *hos > > host1->slot == host2->slot && host1->function == >
Re: [Qemu-devel] [PATCH] hw/arm/vexpress: Set reset-cbar property for CPUs
On 13 February 2014 23:39, Peter Crosthwaite wrote: > I've been thinking about the CPU-mpcore problem, and perhaps the most > annoying part of it is propagating the user -cpu argument through to > change to CPU model. On several occasions however we have declared > this to be largely bogus for ARM. E.G. > > qemu-system-arm -M zynq -cpu "cortex-a8" > > doesn't really make any sense. So going into the release (which has a > major revision bump last I knew), can we defeature the -cpu syntax at > least for the MPCore boards, if not all ARM. If you want to BYO cpu, > then it should be done with regular -device style mechanisms (some > patches needed). Yes, I think that makes sense: anything with a set of private peripherals really expects to see the right set, not some random other set, and any real board with a real SoC expects to see that SoC's CPU, not some random other thing. We should probably provide a helpful error message rather than totally ignoring -cpu. If you want to write patches to do that I'll accept them. (The 'virt' board is the odd one out here given that it picks the private peripheral set to match the specified CPU. But 'virt' is odd in lots of ways.) thanks -- PMM
Re: [Qemu-devel] [PATCH] hw/arm/vexpress: Set reset-cbar property for CPUs
On Fri, Feb 14, 2014 at 7:45 AM, Peter Maydell wrote: > On 13 February 2014 21:31, Rob Herring wrote: >> On Thu, Feb 13, 2014 at 8:26 AM, Peter Maydell >> wrote: >>> Newer versions of the Linux kernel (as of commit bc41b8724 in 3.12) >>> now assume that if the CPU is a Cortex-A9 and the reset value of the >>> PERIPHBASE/CBAR register is zero then the CPU is a specific buggy >>> single core A9 SoC, and will not try to start other cores. Since we >>> now have a CPU property for the reset value of the CBAR, we can >>> just fix the vexpress board model to correctly set CBAR so SMP >>> works again. To avoid duplicate boilerplate code in both the A9 >>> and A15 daughterboard init functions, we split out the CPU and >>> private memory region init to its own function. >>> >>> Signed-off-by: Peter Maydell >>> Reported-by: Rob Herring >>> --- >>> Thanks to Rob for tracking down this SMP boot issue and identifying >>> the offending kernel change (which personally I think is a terrible >>> hack, but it's in shipping kernels and our models ought to be >>> accurate for CBAR anyway). >> >> And i was working on the fix as well... > > Ah, sorry. I checked your git repo to see if there was a patch > in it, but didn't find anything so I guessed you'd just done a > quick "get it working" patch. > >>> +static void init_cpus(const char *cpu_model, const char *privdev, >>> + hwaddr periphbase, qemu_irq *pic) >> >> There is nothing really vexpress specific about this function other >> than number of irqs. This is really just expanding cpu_arm_init which >> is the route I was going down. > > However cpu_arm_init() is in target-arm and has no > business instantiating devices. I think the correct long > term approach is going to involve the A9 and A15 > private peripheral devices instantiating the CPUs themselves. Agreed. Most of that common code should go away with the migration of CPU instantiation to MPCore, which should happen sooner or later. That will end up naturally share all the code with Zynq, Highbank and friends. Factoring this out to a global helper is backwards step to the old style of qdev-init helpers. Reviewed-by: Peter Crosthwaite I've been thinking about the CPU-mpcore problem, and perhaps the most annoying part of it is propagating the user -cpu argument through to change to CPU model. On several occasions however we have declared this to be largely bogus for ARM. E.G. qemu-system-arm -M zynq -cpu "cortex-a8" doesn't really make any sense. So going into the release (which has a major revision bump last I knew), can we defeature the -cpu syntax at least for the MPCore boards, if not all ARM. If you want to BYO cpu, then it should be done with regular -device style mechanisms (some patches needed). Regards, Peter > But I figured that two weeks before soft freeze was perhaps > not the best time to open that can of worms, hence this patch > which is localised to just the machine model code. > > thanks > -- PMM >
Re: [Qemu-devel] [PATCH] hw/arm/vexpress: Set reset-cbar property for CPUs
On 13 February 2014 21:31, Rob Herring wrote: > On Thu, Feb 13, 2014 at 8:26 AM, Peter Maydell > wrote: >> Newer versions of the Linux kernel (as of commit bc41b8724 in 3.12) >> now assume that if the CPU is a Cortex-A9 and the reset value of the >> PERIPHBASE/CBAR register is zero then the CPU is a specific buggy >> single core A9 SoC, and will not try to start other cores. Since we >> now have a CPU property for the reset value of the CBAR, we can >> just fix the vexpress board model to correctly set CBAR so SMP >> works again. To avoid duplicate boilerplate code in both the A9 >> and A15 daughterboard init functions, we split out the CPU and >> private memory region init to its own function. >> >> Signed-off-by: Peter Maydell >> Reported-by: Rob Herring >> --- >> Thanks to Rob for tracking down this SMP boot issue and identifying >> the offending kernel change (which personally I think is a terrible >> hack, but it's in shipping kernels and our models ought to be >> accurate for CBAR anyway). > > And i was working on the fix as well... Ah, sorry. I checked your git repo to see if there was a patch in it, but didn't find anything so I guessed you'd just done a quick "get it working" patch. >> +static void init_cpus(const char *cpu_model, const char *privdev, >> + hwaddr periphbase, qemu_irq *pic) > > There is nothing really vexpress specific about this function other > than number of irqs. This is really just expanding cpu_arm_init which > is the route I was going down. However cpu_arm_init() is in target-arm and has no business instantiating devices. I think the correct long term approach is going to involve the A9 and A15 private peripheral devices instantiating the CPUs themselves. But I figured that two weeks before soft freeze was perhaps not the best time to open that can of worms, hence this patch which is localised to just the machine model code. thanks -- PMM
[Qemu-devel] [PATCH/RFC] clear bss memory of ROMS
On 13/02/14 20:39, Christian Borntraeger wrote:
> On 13/02/14 16:15, Richard Henderson wrote:
>> On 02/13/2014 01:17 AM, Christian Borntraeger wrote:
>>> The current code does not initialize next_idx as the qemu
>>> elf loader does not zero the bss section.
>>> Make the initialization explicit.
>>>
>>> Signed-off-by: Christian Borntraeger
>>> ---
>>> pc-bios/s390-ccw/virtio.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
>>> index 4d6e48f..a46914d 100644
>>> --- a/pc-bios/s390-ccw/virtio.c
>>> +++ b/pc-bios/s390-ccw/virtio.c
>>> @@ -124,6 +124,7 @@ static void vring_init(struct vring *vr, unsigned int
>>> num, void *p,
>>> vr->used->flags = VRING_USED_F_NO_NOTIFY;
>>> vr->used->idx = 0;
>>> vr->used_idx = 0;
>>> +vr->next_idx = 0;
>>>
>>> debug_print_addr("init vr", vr);
>>> }
>>>
>>
>> FWIW, I believe that rom_reset needs to do this re-zeroing of the bss.
>> That seems to be the only place we don't take care for datasize != romsize.
>>
>
> Indeed, initializing the data as in my patches isnt wrong (and allows to move
> that structures around e.g. from a global variable to stack), so it still
> makes
> sense to apply both patches, but the main problem was that the bss section
> is
> not cleared on reset.
>
> So we need to memset from rom->data+rom->datasize to rom->data+rom->romsize
> to avoid more of these kind of problems in an add-on patch.
To correct myself. Actually only Patch 2/3 would be fixed by zeroing the bss.
Patch 1/3 is still necessary, since the bios creates the virtqueue not in bss
but
in real memory. Still, bss clearing seems like a good idea, so what about
something
like the following:
loader: reset bss sections of ROMS
The bss section of ELF roms must be zeroed on reset.
Signed-off-by: Christian Borntraeger
[cborntra@r17lp39 qemu]$ git diff
diff --git a/exec.c b/exec.c
index b69fd29..f0f6a94 100644
--- a/exec.c
+++ b/exec.c
@@ -2097,6 +2097,30 @@ void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
address_space_rw(&address_space_memory, addr, buf, len, is_write);
}
+void cpu_physical_memory_clear_rom(AddressSpace *as, hwaddr addr, size_t len)
+{
+hwaddr l;
+uint8_t *ptr;
+hwaddr addr1;
+MemoryRegion *mr;
+
+while (len > 0) {
+l = len;
+mr = address_space_translate(as, addr, &addr1, &l, true);
+
+if (!(memory_region_is_ram(mr) ||
+ memory_region_is_romd(mr))) {
+/* do nothing */
+} else {
+addr1 += memory_region_get_ram_addr(mr);
+ptr = qemu_get_ram_ptr(addr1);
+memset(ptr, 0, l);
+}
+len -= l;
+addr += l;
+}
+}
+
enum write_rom_type {
WRITE_DATA,
FLUSH_CACHE,
diff --git a/hw/core/loader.c b/hw/core/loader.c
index e1a8318..7998a3e 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -786,13 +786,20 @@ static void rom_reset(void *unused)
if (rom->fw_file) {
continue;
}
-if (rom->data == NULL) {
-continue;
-}
if (rom->mr) {
void *host = memory_region_get_ram_ptr(rom->mr);
+memset(host + rom->datasize, 0, rom->romsize - rom->datasize);
+if (rom->data == NULL) {
+continue;
+}
memcpy(host, rom->data, rom->datasize);
} else {
+cpu_physical_memory_clear_rom(&address_space_memory,
+ rom->addr + rom->datasize,
+ rom->romsize - rom->datasize);
+if (rom->data == NULL) {
+continue;
+}
cpu_physical_memory_write_rom(&address_space_memory,
rom->addr, rom->data, rom->datasize);
}
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index a21b65a..948de83 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -108,6 +108,7 @@ void stl_phys(AddressSpace *as, hwaddr addr, uint32_t val);
void stq_phys(AddressSpace *as, hwaddr addr, uint64_t val);
#endif
+void cpu_physical_memory_clear_rom(AddressSpace *as, hwaddr addr, size_t len);
void cpu_physical_memory_write_rom(AddressSpace *as, hwaddr addr,
const uint8_t *buf, int len);
void cpu_flush_icache_range(hwaddr start, int len);
Re: [Qemu-devel] [PATCH] hw/arm/vexpress: Set reset-cbar property for CPUs
On Thu, Feb 13, 2014 at 8:26 AM, Peter Maydell wrote:
> Newer versions of the Linux kernel (as of commit bc41b8724 in 3.12)
> now assume that if the CPU is a Cortex-A9 and the reset value of the
> PERIPHBASE/CBAR register is zero then the CPU is a specific buggy
> single core A9 SoC, and will not try to start other cores. Since we
> now have a CPU property for the reset value of the CBAR, we can
> just fix the vexpress board model to correctly set CBAR so SMP
> works again. To avoid duplicate boilerplate code in both the A9
> and A15 daughterboard init functions, we split out the CPU and
> private memory region init to its own function.
>
> Signed-off-by: Peter Maydell
> Reported-by: Rob Herring
> ---
> Thanks to Rob for tracking down this SMP boot issue and identifying
> the offending kernel change (which personally I think is a terrible
> hack, but it's in shipping kernels and our models ought to be
> accurate for CBAR anyway).
And i was working on the fix as well...
> We should probably propagate this fix to all our A9-based models
> before 2.0 release: I think the remaining ones to fix would be
> realview-pbx-a9 and exynos4210.
>
> QOM syntax cribbed from the zynq board so I assume it is up to
> current standards.
>
> hw/arm/vexpress.c | 116
> +-
> 1 file changed, 54 insertions(+), 62 deletions(-)
>
> diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
> index ef1707a..e4ced8f 100644
> --- a/hw/arm/vexpress.c
> +++ b/hw/arm/vexpress.c
> @@ -32,6 +32,7 @@
> #include "sysemu/blockdev.h"
> #include "hw/block/flash.h"
> #include "sysemu/device_tree.h"
> +#include "qemu/error-report.h"
> #include
>
> #define VEXPRESS_BOARD_ID 0x8e0
> @@ -173,6 +174,57 @@ struct VEDBoardInfo {
> DBoardInitFn *init;
> };
>
> +static void init_cpus(const char *cpu_model, const char *privdev,
> + hwaddr periphbase, qemu_irq *pic)
There is nothing really vexpress specific about this function other
than number of irqs. This is really just expanding cpu_arm_init which
is the route I was going down.
Rob
Re: [Qemu-devel] [pve-devel] QEMU LIve Migration - swap_free: Bad swap file entry
Am 13.02.2014 21:06, schrieb Dr. David Alan Gilbert: * Stefan Priebe (s.pri...@profihost.ag) wrote: Am 10.02.2014 17:07, schrieb Dr. David Alan Gilbert: * Stefan Priebe (s.pri...@profihost.ag) wrote: i could fix it by explicitly disable xbzrle - it seems its automatically on if i do not set the migration caps to false. So it seems to be a xbzrle bug. Stefan can you give me some more info on your hardware and migration setup; that stressapptest (which is a really nice find!) really batters the memory and it means the migration isn't converging for me, so I'm curious what your setup is. That one is devlopment by google and known to me since a few years. Google has detected that memtest and co are not good enough to stress test memory. Hi Stefan, I've just posted a patch to qemu-devel that fixes two bugs that we found; I've only tried a small stressapptest run and it seems to survive with them (where it didn't before); you might like to try it if you're up for rebuilding qemu. It's the one entitled ' [PATCH] Fix two XBZRLE corruption issues' I'll try and get a larger run done myself, but I'd be interested to hear if it fixes it for you (or anyone else who hit the problem). Yes works fine - now no crash but it's sower than without XBZRLE ;-) Without XBZRLE: i needed migrate_downtime 4 around 60s With XBZRLE: i needed migrate_downtime 16 and 240s Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features
virtio: set virtio-net/virtio-mmio host features
Patch sets 'virtio-net/virtio-mmio' host features to enable network
features based on peer capabilities. Currently host features turn
of all features by default.
Signed-off-by: Mario Smarduch
---
hw/virtio/virtio-mmio.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
index 8829eb0..1d940b7 100644
--- a/hw/virtio/virtio-mmio.c
+++ b/hw/virtio/virtio-mmio.c
@@ -23,6 +23,7 @@
#include "hw/virtio/virtio.h"
#include "qemu/host-utils.h"
#include "hw/virtio/virtio-bus.h"
+#include "hw/virtio/virtio-net.h"
/* #define DEBUG_VIRTIO_MMIO */
@@ -92,6 +93,12 @@ typedef struct {
static void virtio_mmio_bus_new(VirtioBusState *bus, size_t bus_size,
VirtIOMMIOProxy *dev);
+/* all possible virtio-net features supported */
+static Property virtio_mmio_net_properties[] = {
+DEFINE_VIRTIO_NET_FEATURES(VirtIOMMIOProxy, host_features),
+DEFINE_PROP_END_OF_LIST(),
+};
+
static uint64_t virtio_mmio_read(void *opaque, hwaddr offset, unsigned size)
{
VirtIOMMIOProxy *proxy = (VirtIOMMIOProxy *)opaque;
@@ -347,11 +354,33 @@ static void virtio_mmio_reset(DeviceState *d)
/* virtio-mmio device */
+/* Walk virtio-net possible supported features and set host_features, this
+ * should be done earlier when the object is instantiated but at that point
+ * you don't know what type of device will be plugged in.
+ */
+static void virtio_mmio_set_net_features(Property *prop, uint32_t *features)
+{
+for (; prop && prop->name; prop++) {
+if (prop->defval == true) {
+*features |= (1 << prop->bitnr);
+} else {
+*features &= ~(1 << prop->bitnr);
+}
+}
+}
+
/* This is called by virtio-bus just after the device is plugged. */
static void virtio_mmio_device_plugged(DeviceState *opaque)
{
VirtIOMMIOProxy *proxy = VIRTIO_MMIO(opaque);
+VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
+Object *obj = OBJECT(vdev);
+/* set host features only for virtio-net */
+if (object_dynamic_cast(obj, TYPE_VIRTIO_NET)) {
+virtio_mmio_set_net_features(virtio_mmio_net_properties,
+&proxy->host_features);
+}
proxy->host_features |= (0x1 << VIRTIO_F_NOTIFY_ON_EMPTY);
proxy->host_features = virtio_bus_get_vdev_features(&proxy->bus,
proxy->host_features);
--
1.7.9.5
Re: [Qemu-devel] [pve-devel] QEMU LIve Migration - swap_free: Bad swap file entry
got it here: http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg02341.html will try asap Am 13.02.2014 21:06, schrieb Dr. David Alan Gilbert: * Stefan Priebe (s.pri...@profihost.ag) wrote: Am 10.02.2014 17:07, schrieb Dr. David Alan Gilbert: * Stefan Priebe (s.pri...@profihost.ag) wrote: i could fix it by explicitly disable xbzrle - it seems its automatically on if i do not set the migration caps to false. So it seems to be a xbzrle bug. Stefan can you give me some more info on your hardware and migration setup; that stressapptest (which is a really nice find!) really batters the memory and it means the migration isn't converging for me, so I'm curious what your setup is. That one is devlopment by google and known to me since a few years. Google has detected that memtest and co are not good enough to stress test memory. Hi Stefan, I've just posted a patch to qemu-devel that fixes two bugs that we found; I've only tried a small stressapptest run and it seems to survive with them (where it didn't before); you might like to try it if you're up for rebuilding qemu. It's the one entitled ' [PATCH] Fix two XBZRLE corruption issues' I'll try and get a larger run done myself, but I'd be interested to hear if it fixes it for you (or anyone else who hit the problem). Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [pve-devel] QEMU LIve Migration - swap_free: Bad swap file entry
Am 13.02.2014 21:06, schrieb Dr. David Alan Gilbert: * Stefan Priebe (s.pri...@profihost.ag) wrote: Am 10.02.2014 17:07, schrieb Dr. David Alan Gilbert: * Stefan Priebe (s.pri...@profihost.ag) wrote: i could fix it by explicitly disable xbzrle - it seems its automatically on if i do not set the migration caps to false. So it seems to be a xbzrle bug. Stefan can you give me some more info on your hardware and migration setup; that stressapptest (which is a really nice find!) really batters the memory and it means the migration isn't converging for me, so I'm curious what your setup is. That one is devlopment by google and known to me since a few years. Google has detected that memtest and co are not good enough to stress test memory. Hi Stefan, I've just posted a patch to qemu-devel that fixes two bugs that we found; I've only tried a small stressapptest run and it seems to survive with them (where it didn't before); you might like to try it if you're up for rebuilding qemu. It's the one entitled ' [PATCH] Fix two XBZRLE corruption issues' Thanks! Really would love to try them but nor google nor myself can find them. http://osdir.com/ml/qemu-devel/2014-02/ Stefan I'll try and get a larger run done myself, but I'd be interested to hear if it fixes it for you (or anyone else who hit the problem). Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH v3] vl: convert -m to QemuOpts
On 02/13/14 18:45, Eric Blake wrote: > On 02/13/2014 09:13 AM, Igor Mammedov wrote: >> Adds option to -m >> "mem" - startup memory amount >> >> For compatibility with legacy CLI if suffix-less number is passed, >> it assumes amount in MiB. >> >> Otherwise user is free to use suffixed number using suffixes b,k/K,M,G >> >> Signed-off-by: Igor Mammedov >> Signed-off-by: Paolo Bonzini >> --- >> v3: >> - fixes suggested by Eric Blake >> - check for empty string in more efficient way >> - fix MB/MiB inconsistency >> - use EXIT_FAILURE instead of 1 >> - add missing exit() if overflow occurres > > Reviewed-by: Eric Blake Me too: Reviewed-by: Laszlo Ersek
Re: [Qemu-devel] [pve-devel] QEMU LIve Migration - swap_free: Bad swap file entry
* Stefan Priebe (s.pri...@profihost.ag) wrote: > Am 10.02.2014 17:07, schrieb Dr. David Alan Gilbert: > >* Stefan Priebe (s.pri...@profihost.ag) wrote: > >>i could fix it by explicitly disable xbzrle - it seems its > >>automatically on if i do not set the migration caps to false. > >> > >>So it seems to be a xbzrle bug. > > > >Stefan can you give me some more info on your hardware and > >migration setup; that stressapptest (which is a really nice > >find!) really batters the memory and it means the migration > >isn't converging for me, so I'm curious what your setup is. > > That one is devlopment by google and known to me since a few years. > Google has detected that memtest and co are not good enough to > stress test memory. Hi Stefan, I've just posted a patch to qemu-devel that fixes two bugs that we found; I've only tried a small stressapptest run and it seems to survive with them (where it didn't before); you might like to try it if you're up for rebuilding qemu. It's the one entitled ' [PATCH] Fix two XBZRLE corruption issues' I'll try and get a larger run done myself, but I'd be interested to hear if it fixes it for you (or anyone else who hit the problem). Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH 0/2] Use g_new() & friends where that makes obvious sense
Peter Maydell writes: > On 13 February 2014 16:36, Markus Armbruster wrote: >> I started splitting the patch, and it bores me to tears. >> >> Peter, any chance for applying as is, with all conflicting hunks >> summarily dropped? > > I'm afraid that sounds like too much manual effort on my part. git-pull -s recursive -X ours ?
[Qemu-devel] [PATCH] Fix two XBZRLE corruption issues
From: "Dr. David Alan Gilbert"
Push zero'd pages into the XBZRLE cache
A page that was cached by XBZRLE, zero'd and then XBZRLE'd again
was being compared against a stale cache value
Don't use 'qemu_put_buffer_async' to put pages from the XBZRLE cache
Since the cache might change before the data hits the wire
Signed-off-by: Dr. David Alan Gilbert
---
arch_init.c| 64 --
include/migration/page_cache.h | 2 +-
page_cache.c | 2 +-
3 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 80574a0..fe17279 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -122,7 +122,6 @@ static void check_guest_throttling(void);
#define RAM_SAVE_FLAG_XBZRLE 0x40
/* 0x80 is reserved in migration.h start with 0x100 next */
-
static struct defconfig_file {
const char *filename;
/* Indicates it is an user config file (disabled by -no-user-config) */
@@ -133,6 +132,7 @@ static struct defconfig_file {
{ NULL }, /* end of list */
};
+static const uint8_t ZERO_TARGET_PAGE[TARGET_PAGE_SIZE];
int qemu_read_default_config_files(bool userconfig)
{
@@ -273,6 +273,34 @@ static size_t save_block_hdr(QEMUFile *f, RAMBlock *block,
ram_addr_t offset,
return size;
}
+/* This is the last block that we have visited serching for dirty pages
+ */
+static RAMBlock *last_seen_block;
+/* This is the last block from where we have sent data */
+static RAMBlock *last_sent_block;
+static ram_addr_t last_offset;
+static unsigned long *migration_bitmap;
+static uint64_t migration_dirty_pages;
+static uint32_t last_version;
+static bool ram_bulk_stage;
+
+/* Update the xbzrle cache to reflect a page that's been sent as all 0.
+ * The important thing is that a stale (not-yet-0'd) page be replaced
+ * by the new data.
+ * As a bonus, if the page wasn't in the cache it gets added so that
+ * when a small write is made into the 0'd page it gets XBZRLE sent
+ */
+static void xbzrle_cache_zero_page(ram_addr_t current_addr)
+{
+if (ram_bulk_stage || !migrate_use_xbzrle()) {
+return;
+}
+
+/* We don't care if this fails to allocate a new cache page
+ * as long as it updated an old one */
+cache_insert(XBZRLE.cache, current_addr, ZERO_TARGET_PAGE);
+}
+
#define ENCODING_FLAG_XBZRLE 0x1
static int save_xbzrle_page(QEMUFile *f, uint8_t *current_data,
@@ -329,18 +357,6 @@ static int save_xbzrle_page(QEMUFile *f, uint8_t
*current_data,
return bytes_sent;
}
-
-/* This is the last block that we have visited serching for dirty pages
- */
-static RAMBlock *last_seen_block;
-/* This is the last block from where we have sent data */
-static RAMBlock *last_sent_block;
-static ram_addr_t last_offset;
-static unsigned long *migration_bitmap;
-static uint64_t migration_dirty_pages;
-static uint32_t last_version;
-static bool ram_bulk_stage;
-
static inline
ram_addr_t migration_bitmap_find_and_reset_dirty(MemoryRegion *mr,
ram_addr_t start)
@@ -512,6 +528,7 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
} else {
int ret;
uint8_t *p;
+bool send_async = true;
int cont = (block == last_sent_block) ?
RAM_SAVE_FLAG_CONTINUE : 0;
@@ -522,6 +539,7 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
ret = ram_control_save_page(f, block->offset,
offset, TARGET_PAGE_SIZE, &bytes_sent);
+current_addr = block->offset + offset;
if (ret != RAM_SAVE_CONTROL_NOT_SUPP) {
if (ret != RAM_SAVE_CONTROL_DELAYED) {
if (bytes_sent > 0) {
@@ -536,19 +554,35 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
RAM_SAVE_FLAG_COMPRESS);
qemu_put_byte(f, 0);
bytes_sent++;
+/* Must let xbzrle know, otherwise a previous (now 0'd) cached
+ * page would be stale
+ */
+xbzrle_cache_zero_page(current_addr);
} 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) {
+/* We must send exactly what's in the xbzrle cache
+ * even if the page wasn't xbzrle compressed, so that
+ * it's right next time.
+ */
p = get_cached_data(XBZRLE.cache, current_addr);
+
+/* Can't send this cached data async, since the cache page
+ * might get updated before it gets to the wire
+ */
+send_async = false;
Re: [Qemu-devel] [PULL 1/3] s390-ccw.img: Fix sporadic reboot hangs: Initialize next_idx
On 13/02/14 16:15, Richard Henderson wrote:
> On 02/13/2014 01:17 AM, Christian Borntraeger wrote:
>> The current code does not initialize next_idx as the qemu
>> elf loader does not zero the bss section.
>> Make the initialization explicit.
>>
>> Signed-off-by: Christian Borntraeger
>> ---
>> pc-bios/s390-ccw/virtio.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
>> index 4d6e48f..a46914d 100644
>> --- a/pc-bios/s390-ccw/virtio.c
>> +++ b/pc-bios/s390-ccw/virtio.c
>> @@ -124,6 +124,7 @@ static void vring_init(struct vring *vr, unsigned int
>> num, void *p,
>> vr->used->flags = VRING_USED_F_NO_NOTIFY;
>> vr->used->idx = 0;
>> vr->used_idx = 0;
>> +vr->next_idx = 0;
>>
>> debug_print_addr("init vr", vr);
>> }
>>
>
> FWIW, I believe that rom_reset needs to do this re-zeroing of the bss.
> That seems to be the only place we don't take care for datasize != romsize.
>
Indeed, initializing the data as in my patches isnt wrong (and allows to move
that structures around e.g. from a global variable to stack), so it still makes
sense to apply both patches, but the main problem was that the bss section is
not cleared on reset.
So we need to memset from rom->data+rom->datasize to rom->data+rom->romsize
to avoid more of these kind of problems in an add-on patch.
Christian
Re: [Qemu-devel] [PATCH RFC] char: fix avail_connections init in qemu_chr_open_eventfd()
Hi David,
I'm not sure which is the correct approach. You could either do what you
did or you could simply remove the qemu_chr_fe_claim_no_fail() from
ivshmem.c. I'm not sure how your change impacts other devices.
Sincerely,
Cam
On Tue, Feb 4, 2014 at 2:17 PM, David Marchand wrote:
> Hello,
>
> First of all, this is a pure RFC patch, I did not take too much time to
> dig into
> qemu source code to find the right solution, but since
> qemu_chr_open_eventfd()
> is only used by the code I was looking at, here is a patch.
>
>
> When trying to use a ivshmem server with qemu, ivshmem init code tries to
> create a CharDriverState object for each eventfd retrieved from the server.
> To create this object, a call to qemu_chr_open_eventfd() is done.
> Right after this, before adding a frontend, qemu_chr_fe_claim_no_fail() is
> called.
> qemu_chr_open_eventfd() does not set avail_connections to 1, so no
> frontend can
> be associated because qemu_chr_fe_claim_no_fail() makes qemu stop right
> away.
>
> I suppose this problem comes from 456d60692310e7ac25cf822cc1e98192ad636ece
> "qemu-char: Call fe_claim / fe_release when not using qdev chr properties".
>
> Fix this, by setting avail_connections to 1 in qemu_chr_open_eventfd().
>
> Signed-off-by: David Marchand
> ---
> qemu-char.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 30c5a6a..c0adb04 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -2492,7 +2492,12 @@ static gboolean tcp_chr_read(GIOChannel *chan,
> GIOCondition cond, void *opaque)
> #ifndef _WIN32
> CharDriverState *qemu_chr_open_eventfd(int eventfd)
> {
> -return qemu_chr_open_fd(eventfd, eventfd);
> +CharDriverState *chr = qemu_chr_open_fd(eventfd, eventfd);
> +
> +if (chr)
> +chr->avail_connections = 1;
> +
> +return chr;
> }
> #endif
>
> --
> David Marchand
>
>
>
Re: [Qemu-devel] [PATCH 2/2] block: Open by reference will try device then node_name.
On 12.02.2014 17:15, Benoît Canet wrote: Since we introduced node_name for named bs of the graph modify the opening by reference to use it as a fallback. This patch also enforce the separation of the device id and graph node namespaces. Signed-off-by: Benoit Canet --- block.c| 10 -- blockdev.c | 6 ++ 2 files changed, 14 insertions(+), 2 deletions(-) Reviewed-by: Max Reitz
Re: [Qemu-devel] [PATCH 1/2] block: Relax bdrv_lookup_bs constraints.
On 12.02.2014 17:15, Benoît Canet wrote: The following patch will reuse bdrv_lookup_bs in order to open images by references so the rules of usage of bdrv_lookup_bs must be relaxed a bit. Signed-off-by: Benoit Canet --- block.c | 26 +++--- 1 file changed, 11 insertions(+), 15 deletions(-) Reviewed-by: Max Reitz
Re: [Qemu-devel] Open by references and close on exit
Hi Benoît, Hm, opening a reference should only result in the refcount of the respective BDS being incremented through bdrv_ref(). Since no new BDS is created, nothing should be added to bdrv_states. When the BDS “closed” through bdrv_unref(), it is only actually closed/deleted if the refcount reaches zero. Until then, it remains in bdrv_states so it can be referenced (since it has not been closed) and closed through bdrv_close_all(). I don't really see how bdrv_close_all() closes the BDS “a second time” – bdrv_unref() should only close the BDS if its refcount reaches zero. And if that's the case, it should be removed from bdrv_states anyway. Kind regards, Max
[Qemu-devel] [Bug 1279500] Re: system_powerdown causes SMP OpenBSD guest to freeze
hoping to increase the OpenBSD developers' inclination to investigate this bug, I reproduced it using OpenBSD 5.4 as the host. I used the stock qemu-1.5.1 that is available as an OpenBSD package. Booting the GENERIC.MP kernel in the VM was painfully slow, but it eventually came up to multi-user mode. The script to run the OpenBSD 5.4 guest on the OpenBSD 5.4 host: -snip- #!/bin/sh qemu-system-x86_64 \ -S \ -m 2048 \ -smp 2,sockets=2,cores=1,threads=1 \ -monitor stdio \ -vnc :0 \ -no-fd-bootchk \ -net nic \ -net user \ -cdrom /space/install54.iso \ -drive file=/space/obsd54test.raw,index=0,media=disk,cache=none,format=raw -snip- As usual, issuing the "system_powerdown" command in the monitor caused the guest to freeze totally. Rob Urban -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1279500 Title: system_powerdown causes SMP OpenBSD guest to freeze Status in QEMU: New Bug description: system_powerdown causes an SMP OpenBSD guest to freeze. I can reproduce it with the following systems/versions: - Debian 6: QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5) - Fedora 20: qemu-system-x86-1.6.1 (from Fedora repository) qemu-1.7.0 (latest release version) qemu-1.7.50 (latest development snapshot, "git cloned" today, 20140212) all of the above hosts are running x86_64 linux. The first OpenBSD version that I ran as a VM, v5.1, experienced the problem. All subsequent versions experience the problem. The above tests were performed using OpenBSD v5.4 (amd64). I will open an OpenBSD bug report for this problem as well, and update this report with the OpenBSD bug ID. There's an interesting RedHat bug report concerning this problem: URL: https://bugzilla.redhat.com/show_bug.cgi?id=508801#c34 Here an excerpt: -snip- Gleb Natapov 2009-12-23 10:37:44 EST I posted patch to provide correct PCI irq routing info in mptable to kvm mailing list. It works for all devices except for SCI interrupt. BIOS programs SCI interrupt to be 9 as spec requires, but OpenBSD thinks that it is smarter and moves it to interrupts 10. Qemu will still send it on vector 9 and OpenBSD will enter the same infinity recursion. This can be triggered by issuing system_powerdown on qemu monitor. -snip- Michael Tokarev reported this problem on the kvm mailing list in 2011: URL: http://www.spinics.net/lists/kvm/msg51311.html I compiled qemu as follows: -snip- cd qemu-src-dir mkdir -p bin/native cd bin/native ../../configure \ --prefix=/usr/local/qemu-dev-snapshot-20140212 \ --target-list=x86_64-softmmu \ --enable-kvm \ --enable-spice \ --with-gtkabi="3.0" \ --audio-drv-list=pa,sdl,alsa,oss \ --extra-cflags='-I/usr/include/SDL' -snip- I'm running OpenBSD with the following command: -snip- #!/bin/bash DEF=/usr/bin/qemu-system-x86_64 QEMU_LATEST=/usr/local/qemu-1.7.0/bin/qemu-system-x86_64 QEMU_DEV=/usr/local/qemu-dev-snapshot-20140212/bin/qemu-system-x86_64 $QEMU_DEV \ -machine accel=kvm \ -name obsdtest-v54 \ -S \ -machine pc-i440fx-1.6,accel=kvm,usb=off \ -boot c \ -m 2048 \ -realtime mlock=off \ -smp 2,sockets=2,cores=1,threads=1 \ -uuid 8b685793-2510-473e-b97e-822a4cf2fbca \ -no-user-config \ -monitor stdio \ -rtc base=utc,driftfix=slew \ -global kvm-pit.lost_tick_policy=discard \ -no-hpet \ -drive file=/guest_images/obsdtest_v54.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw \ -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ -chardev pty,id=charserial0 \ -device isa-serial,chardev=charserial0,id=serial0 \ -k en-us \ -device cirrus-vga,id=video0,bus=pci.0,addr=0x3 \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ -net nic \ -net user -snip- The OpenBSD disk image I used for testing is 143MB compressed, 10G uncompressed. It can be found here: http://www.spielwiese.de/OpenBSD/obsd54.raw.7z The root password is "x". Rob Urban To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1279500/+subscriptions
Re: [Qemu-devel] [PATCH v3] vl: convert -m to QemuOpts
On 02/13/2014 09:13 AM, Igor Mammedov wrote: > Adds option to -m > "mem" - startup memory amount > > For compatibility with legacy CLI if suffix-less number is passed, > it assumes amount in MiB. > > Otherwise user is free to use suffixed number using suffixes b,k/K,M,G > > Signed-off-by: Igor Mammedov > Signed-off-by: Paolo Bonzini > --- > v3: > - fixes suggested by Eric Blake > - check for empty string in more efficient way > - fix MB/MiB inconsistency > - use EXIT_FAILURE instead of 1 > - add missing exit() if overflow occurres Reviewed-by: Eric Blake -- 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 v2] qga: Don't require 'time' argument in guest-set-time command
On 31.01.2014 19:12, Eric Blake wrote: On 01/31/2014 03:29 AM, Michal Privoznik wrote: As the description to the guest-set-time states, the command is there to ease time synchronization after resume. If guest was suspended for longer period of time, its system time can go off so badly, that even NTP refuses to set it. That's why the command was invented: to give users chance to set the time (not necessarily 100% correct). However, there's is no real need for us to require users to pass an arbitrary time. Especially if we can read the correct value from RTC (boiling down to reading host's time). Hence this commit enables logic: guest-set-time() == guest-set-time($now_from_rtc) Signed-off-by: Michal Privoznik --- diff to v1: -Fix checkpatch.pl warnings qga/commands-posix.c | 41 + qga/commands-win32.c | 34 +++--- qga/qapi-schema.json | 9 + 3 files changed, 53 insertions(+), 31 deletions(-) Reviewed-by: Eric Blake May I kindly ask somebody to merge this? Or is 3ACKs required for the guest agent too? Thanks in advance! Michal
[Qemu-devel] Get the dirty bitmap of a whole VM
Hi all,
I'm trying to calculate the dirty bytes rate of a VM by traveling the
corresponding memory dirty bitmaps.
I get a bitmap from KVM kernel space using the following ioctl call :
kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d);
Also, I'm getting the bitmap for each memory slot inside the KVMState
object, but I obtain strange results..
I reused some code from the 'kvm_physical_sync_dirty_bitmap' function
but I wonder if I should really use each available memory slot ? or if
there is a way to obtain the whole 'MemoryRegionSection' of a VM ?
For instance, there is roughly what I do :
/**/
KVMState *s = kvm_state;
KVMDirtyLog d;
for (int i=0; i <=; i++) {
if (&s->slots[i]->memory_size > 0) {
d.slot = &s->slots[i]->slot;
kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d);
}
}
/**/
Any help/advice would be welcome.
Thanks,
--
Vincent KHERBACHE
Re: [Qemu-devel] timer issue on 1.7.0 and later
On 13 February 2014 16:31, Alex Bligh wrote: > The current code (timer_mod_ns_locked) runs the rearm code > if the modified timer is at the front of the timer queue > (only). So if you modify B (in your example above) whether > you extend or reduce the time, it will only 'rearm' if > B now occurs before A. However, if you modify A, it will > currently rearm whether you reduce the expiry time of > A (correct) or whether you extend it so long as it doesn't > now expire after B (this could perhaps be optimised). > > So it's not quite as bad as you think. A little experimentation with the debugger for an SMP A9 guest suggests this may be a red herring anyway. Once it's got started, the only thing that was causing calls to timerlist_notify was the GUI, and if you run with -display none we don't call timerlist_notify at all at the point where we seem to be stalling. thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: fix 32 bit build break in the page table lookup code
On Thu, 13 Feb 2014 15:53:16 +0100
Alexander Graf wrote:
>
> On 13.02.2014, at 04:00, Aneesh Kumar K.V
> wrote:
>
> > Greg Kurz writes:
> >
> >> The 396bb9874 commit reworked page table lookup to support kvm.
> >> Unfortunately this breaks 32 bit build:
> >>
> >> target-ppc/mmu-hash64.h: In function ‘ppc_hash64_load_hpte0’:
> >> target-ppc/mmu-hash64.h:90:23: error: cast to pointer from integer of
> >> different size
> >>
> >> target-ppc/mmu-hash64.h: In function ‘ppc_hash64_load_hpte1’:
> >> target-ppc/mmu-hash64.h:101:23: error: cast to pointer from integer of
> >> different size
> >>
> >> The problem is that we have two cases to handle here:
> >> - the HTAB is external and it is accessed with a pointer
> >> - the HTAB is emulated and it is accessed with a hwaddr
> >>
> >> Depending on the way the HTAB is controlled, we should use the
> >> appropriate type:
> >> - controlled by kvm, it is copied to an allocated buffer (pointer)
> >> - controlled by qemu with an allocated buffer (pointer)
> >> - controlled by qemu with soft mmu (hwaddr)
> >>
> >> This patch introduces an explicit distinction between the two cases in
> >> the new page table lookup code.
> >
> > Reviewed-by: Aneesh Kumar K.V
>
> I wouldn't mind something slightly lighter weight. How about this one
> instead? If you guys think it's better to have an actual type for the
> token I'd pull in this patch as is though.
>
>
> Alex
>
I confess... I consider castings evil and favor explicit typing. :)
On the other hand, I have no strong opinions against your patch. The "token"
code is quite simple and risks of confusion are low, we can live with it.
Please add:
Reviewed-by: Greg Kurz
Thanks for your time.
--
Greg
> diff --git a/target-ppc/mmu-hash64.c b/target-ppc/mmu-hash64.c
> index 4e574d9..3240427 100644
> --- a/target-ppc/mmu-hash64.c
> +++ b/target-ppc/mmu-hash64.c
> @@ -340,7 +340,7 @@ uint64_t ppc_hash64_start_access(PowerPCCPU *cpu,
> target_ulong pte_index)
> * accessible PTEG.
> */
> if (cpu->env.external_htab) {
> -token = (uint64_t) cpu->env.external_htab + pte_offset;
> +token = (uint64_t)(uintptr_t) cpu->env.external_htab +
> pte_offset; } else if (cpu->env.htab_base) {
> token = cpu->env.htab_base + pte_offset;
> }
> diff --git a/target-ppc/mmu-hash64.h b/target-ppc/mmu-hash64.h
> index 9c9ca1d..8fb2ae4 100644
> --- a/target-ppc/mmu-hash64.h
> +++ b/target-ppc/mmu-hash64.h
> @@ -85,22 +85,24 @@ void ppc_hash64_stop_access(uint64_t token);
> static inline target_ulong ppc_hash64_load_hpte0(CPUPPCState *env,
> uint64_t token, int
> index) {
> -index *= HASH_PTE_SIZE_64;
> +uint64_t addr;
> +addr = token + (index * HASH_PTE_SIZE_64) + HASH_PTE_SIZE_64/2;
> if (env->external_htab) {
> -return ldq_p((const void *)(token + index));
> +return ldq_p((const void *)(uintptr_t)addr);
> } else {
> -return ldq_phys(token + index);
> +return ldq_phys(addr);
> }
> }
>
> static inline target_ulong ppc_hash64_load_hpte1(CPUPPCState *env,
> uint64_t token, int
> index) {
> -index *= HASH_PTE_SIZE_64;
> +uint64_t addr;
> +addr = token + (index * HASH_PTE_SIZE_64) + HASH_PTE_SIZE_64/2;
> if (env->external_htab) {
> -return ldq_p((const void *)(token + index +
> HASH_PTE_SIZE_64/2));
> +return ldq_p((const void *)(uintptr_t)addr);
> } else {
> -return ldq_phys(token + index + HASH_PTE_SIZE_64/2);
> +return ldq_phys(addr);
> }
> }
>
>
--
Gregory Kurz kurzg...@fr.ibm.com
gk...@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys http://www.ibm.com
Tel +33 (0)562 165 496
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
Re: [Qemu-devel] [PATCH 0/2] Use g_new() & friends where that makes obvious sense
On 13 February 2014 16:36, Markus Armbruster wrote: > I started splitting the patch, and it bores me to tears. > > Peter, any chance for applying as is, with all conflicting hunks > summarily dropped? I'm afraid that sounds like too much manual effort on my part. thanks -- PMM
Re: [Qemu-devel] [PATCH 0/2] Use g_new() & friends where that makes obvious sense
Peter Maydell writes: > On 3 February 2014 08:40, Markus Armbruster wrote: >> Peter Maydell writes: >>> On 31 January 2014 15:53, Markus Armbruster 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. I started splitting the patch, and it bores me to tears. Peter, any chance for applying as is, with all conflicting hunks summarily dropped?
[Qemu-devel] [PULL 16/22] dump: make kdump-compressed format available for 'dump-guest-memory'
From: qiaonuohan
Make monitor command 'dump-guest-memory' be able to dump in kdump-compressed
format. The command's usage:
dump [-p] protocol [begin] [length] [format]
'format' is used to specified the format of vmcore and can be:
1. 'elf': ELF format, without compression
2. 'kdump-zlib': kdump-compressed format, with zlib-compressed
3. 'kdump-lzo': kdump-compressed format, with lzo-compressed
4. 'kdump-snappy': kdump-compressed format, with snappy-compressed
Without 'format' being set, it is same as 'elf'. And if non-elf format is
specified, paging and filter is not allowed.
Note:
1. The kdump-compressed format is readable only with the crash utility and
makedumpfile, and it can be smaller than the ELF format because of the
compression support.
2. The kdump-compressed format is the 6th edition.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c | 131 ---
hmp.c| 5 ++-
qapi-schema.json | 25 ++-
qmp-commands.hx | 7 ++-
4 files changed, 158 insertions(+), 10 deletions(-)
diff --git a/dump.c b/dump.c
index 31be686..2ebbb23 100644
--- a/dump.c
+++ b/dump.c
@@ -1443,6 +1443,64 @@ out:
return ret;
}
+static int create_kdump_vmcore(DumpState *s)
+{
+int ret;
+
+/*
+ * the kdump-compressed format is:
+ * File offset
+ * +--+ 0x0
+ * |main header (struct disk_dump_header) |
+ * |--+ block 1
+ * |sub header (struct kdump_sub_header) |
+ * |--+ block 2
+ * |1st-dump_bitmap |
+ * |--+ block 2 + X blocks
+ * |2nd-dump_bitmap | (aligned by block)
+ * |--+ block 2 + 2 * X blocks
+ * | page desc for pfn 0 (struct page_desc) | (aligned by block)
+ * | page desc for pfn 1 (struct page_desc) |
+ * |: |
+ * |--| (not aligned by block)
+ * | page data (pfn 0)|
+ * | page data (pfn 1)|
+ * |: |
+ * +--+
+ */
+
+ret = write_start_flat_header(s->fd);
+if (ret < 0) {
+dump_error(s, "dump: failed to write start flat header.\n");
+return -1;
+}
+
+ret = write_dump_header(s);
+if (ret < 0) {
+return -1;
+}
+
+ret = write_dump_bitmap(s);
+if (ret < 0) {
+return -1;
+}
+
+ret = write_dump_pages(s);
+if (ret < 0) {
+return -1;
+}
+
+ret = write_end_flat_header(s->fd);
+if (ret < 0) {
+dump_error(s, "dump: failed to write end flat header.\n");
+return -1;
+}
+
+dump_completed(s);
+
+return 0;
+}
+
static ram_addr_t get_start_block(DumpState *s)
{
GuestPhysBlock *block;
@@ -1479,7 +1537,8 @@ static void get_max_mapnr(DumpState *s)
s->max_mapnr = paddr_to_pfn(last_block->target_end, s->page_shift);
}
-static int dump_init(DumpState *s, int fd, bool paging, bool has_filter,
+static int dump_init(DumpState *s, int fd, bool has_format,
+ DumpGuestMemoryFormat format, bool paging, bool
has_filter,
int64_t begin, int64_t length, Error **errp)
{
CPUState *cpu;
@@ -1487,6 +1546,11 @@ static int dump_init(DumpState *s, int fd, bool paging,
bool has_filter,
Error *err = NULL;
int ret;
+/* kdump-compressed is conflict with paging and filter */
+if (has_format && format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
+assert(!paging && !has_filter);
+}
+
if (runstate_is_running()) {
vm_stop(RUN_STATE_SAVE_VM);
s->resume = true;
@@ -1557,6 +1621,28 @@ static int dump_init(DumpState *s, int fd, bool paging,
bool has_filter,
tmp = DIV_ROUND_UP(DIV_ROUND_UP(s->max_mapnr, CHAR_BIT), s->page_size);
s->len_dump_bitmap = tmp * s->page_size;
+/* init for kdump-compressed format */
+if (has_format && format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
+switch (format) {
+case DUMP_GUEST_MEMORY_FORMAT_KDUMP_ZLIB:
+s->flag_compress = DUMP_DH_COMPRESSED_ZLIB;
+break;
+
+case DUMP_GUEST_MEMORY_FORMAT_KDUMP_LZO:
+s->flag_compress = DUMP_DH_COMPRESSED_LZO;
+break;
+
+case DUMP_GUEST_MEMORY_FORMAT_KDUMP_SNAPPY:
+s->flag_compress = DUMP_DH_COMPRESSED_SNAPPY;
+break;
+
+default:
+s->flag_compress = 0;
+}
+
+return 0;
+}
+
if (s->has_filter) {
memory_mapping_filter(&s->list, s->begin, s->length);
Re: [Qemu-devel] timer issue on 1.7.0 and later
On 13 Feb 2014, at 16:20, Peter Maydell wrote: > On 13 February 2014 16:09, Alex Bligh wrote: >> I suspect the issue is not walking the lists, but calling >> qemu_notify, breaking out of mainloop select etc. etc.; that >> happens on a timer_modify but not on a timer_del. We could >> fix this so that it only happened if the timer's expiry >> time was reduced in timer_mod (I think). > > Surely you only want to do all that work if the fiddling > with the timer means the next most immediate deadline > has changed? If you have two timers, and A is going to > expire before B, then even reducing B's expiry time shouldn't > trigger renotifying unless it's reduced so much it will > expire before A. Correct. The current code (timer_mod_ns_locked) runs the rearm code if the modified timer is at the front of the timer queue (only). So if you modify B (in your example above) whether you extend or reduce the time, it will only 'rearm' if B now occurs before A. However, if you modify A, it will currently rearm whether you reduce the expiry time of A (correct) or whether you extend it so long as it doesn't now expire after B (this could perhaps be optimised). So it's not quite as bad as you think. -- Alex Bligh
Re: [Qemu-devel] [PULL 00/20] acpi,pc,pci fixes and enhancements
On 10 February 2014 16:47, Michael S. Tsirkin wrote: > The following changes since commit 2b2449f7e467957778ca006904471b231dc0ac8e: > > Merge remote-tracking branch 'remotes/borntraeger/tags/kvm-s390-20140131' > into staging (2014-02-04 18:46:33 +) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream > > for you to fetch changes up to 417c45ab2f847c0a47b1232f611aa886df6a97d5: > > ACPI: Remove commented-out code from HPET._CRS (2014-02-10 11:09:33 +0200) Applied, thanks. -- PMM
Re: [Qemu-devel] [PATCH v2 1/4] target-mips: add CPU definition for MIPS32R5
From: Andreas Färber [afaer...@suse.de] Sent: Thursday, February 13, 2014 5:11 PM To: Peter Maydell; Petar Jovanovic Cc: QEMU Developers; Petar Jovanovic; Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH v2 1/4] target-mips: add CPU definition for MIPS32R5 > No objection from my side. I was however expecting Petar to drop the > FIXME in response to my reply, which I believe was still in the PULL. > Peter, are you planning (or did I miss) a follow-up cleaning that up, > whether for your new model or for all? I would leave this FIXME, since we need to fix at least .CP0_PRid value once the real silicon is available, because it will have to match value known to kernel at that time. As for other FIXMEs in the same file, I would change that in a separate patch later. I do plan to update this area more, with additional 5KEc and 5KEf models. Regards, Petar
[Qemu-devel] [PULL 11/22] dump: add members to DumpState and init some of them
From: qiaonuohan
add some members to DumpState that will be used in writing vmcore in
kdump-compressed format. some of them, like page_size, will be initialized
in the patch.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 28
include/sysemu/dump.h | 7 +++
2 files changed, 35 insertions(+)
diff --git a/dump.c b/dump.c
index 2b940bd..3a1944e 100644
--- a/dump.c
+++ b/dump.c
@@ -79,6 +79,16 @@ typedef struct DumpState {
uint8_t *note_buf; /* buffer for notes */
size_t note_buf_offset; /* the writing place in note_buf */
+uint32_t nr_cpus; /* number of guest's cpu */
+size_t page_size; /* guest's page size */
+uint32_t page_shift;/* guest's page shift */
+uint64_t max_mapnr; /* the biggest guest's phys-mem's number */
+size_t len_dump_bitmap; /* the size of the place used to store
+ dump_bitmap in vmcore */
+off_t offset_dump_bitmap; /* offset of dump_bitmap part in vmcore */
+off_t offset_page; /* offset of page part in vmcore */
+size_t num_dumpable;/* number of page that can be dumped */
+uint32_t flag_compress; /* indicate the compression format */
} DumpState;
static int dump_cleanup(DumpState *s)
@@ -796,6 +806,14 @@ static ram_addr_t get_start_block(DumpState *s)
return -1;
}
+static void get_max_mapnr(DumpState *s)
+{
+GuestPhysBlock *last_block;
+
+last_block = QTAILQ_LAST(&s->guest_phys_blocks.head, GuestPhysBlockHead);
+s->max_mapnr = paddr_to_pfn(last_block->target_end, s->page_shift);
+}
+
static int dump_init(DumpState *s, int fd, bool paging, bool has_filter,
int64_t begin, int64_t length, Error **errp)
{
@@ -864,6 +882,16 @@ static int dump_init(DumpState *s, int fd, bool paging,
bool has_filter,
qemu_get_guest_simple_memory_mapping(&s->list, &s->guest_phys_blocks);
}
+s->nr_cpus = nr_cpus;
+s->page_size = TARGET_PAGE_SIZE;
+s->page_shift = ffs(s->page_size) - 1;
+
+get_max_mapnr(s);
+
+uint64_t tmp;
+tmp = DIV_ROUND_UP(DIV_ROUND_UP(s->max_mapnr, CHAR_BIT), s->page_size);
+s->len_dump_bitmap = tmp * s->page_size;
+
if (s->has_filter) {
memory_mapping_filter(&s->list, s->begin, s->length);
}
diff --git a/include/sysemu/dump.h b/include/sysemu/dump.h
index b32b390..995bf47 100644
--- a/include/sysemu/dump.h
+++ b/include/sysemu/dump.h
@@ -20,6 +20,13 @@
#define VERSION_FLAT_HEADER (1)/* version of flattened format */
#define END_FLAG_FLAT_HEADER(-1)
+#define ARCH_PFN_OFFSET (0)
+
+#define paddr_to_pfn(X, page_shift) \
+(((unsigned long long)(X) >> (page_shift)) - ARCH_PFN_OFFSET)
+#define pfn_to_paddr(X, page_shift) \
+(((unsigned long long)(X) + ARCH_PFN_OFFSET) << (page_shift))
+
typedef struct ArchDumpInfo {
int d_machine; /* Architecture */
int d_endian; /* ELFDATA2LSB or ELFDATA2MSB */
--
1.8.1.4
[Qemu-devel] [PATCH] Fix: remove bogus QDECREF()
This extra QDECREF() was causing quorum_close() to crash while doing bdrv_unref(). As the optional options qdict should belong to the block layer so do not use QDECREF() on it. I tested the following inti and qemu exit sequences. tested regular snapshots on device=virtio0 ok tested command line quorum ok tested command line quorum + snapshot transaction ok tested quorum open by reference ok tested quorum open by reference + snapshot transaction ok tested quorum open at once ok tested quorum open at once + snapshot transaction ok Benoît Canet (1): blockdev: Fix wrong usage of QDECREF causing snapshoted quorum to crash on close. blockdev.c | 2 -- 1 file changed, 2 deletions(-) -- 1.8.3.2
[Qemu-devel] [PATCH] blockdev: Fix wrong usage of QDECREF causing snapshoted quorum to crash on close.
As bdrv_open() documentation states:
"The reference to the QDict belongs to the block layer
* after the call (even on failure), so if the caller intends to reuse the
* dictionary, it needs to use QINCREF() before calling bdrv_open."
the optional options dict will not be reused after bdrv_open() and should
belong to the block layer so remove the extra QDECREF(options).
Signed-off-by: Benoit Canet
---
blockdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 5cd50f3..7fbce6c 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1316,8 +1316,6 @@ static void external_snapshot_prepare(BlkTransactionState
*common,
if (ret != 0) {
error_propagate(errp, local_err);
}
-
-QDECREF(options);
}
static void external_snapshot_commit(BlkTransactionState *common)
--
1.8.3.2
[Qemu-devel] [PULL 17/22] dump: Define the architecture for compressed dump format.
From: Ekaterina Tumanova
Signed-off-by: Ekaterina Tumanova
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c | 7 +--
target-i386/cpu.h | 2 ++
target-s390x/cpu.h | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/dump.c b/dump.c
index 2ebbb23..78d226f 100644
--- a/dump.c
+++ b/dump.c
@@ -32,6 +32,9 @@
#ifdef CONFIG_SNAPPY
#include
#endif
+#ifndef ELF_MACHINE_UNAME
+#define ELF_MACHINE_UNAME "Unknown"
+#endif
static uint16_t cpu_convert_to_target16(uint16_t val, int endian)
{
@@ -817,7 +820,7 @@ static int create_header32(DumpState *s)
dh->nr_cpus = cpu_convert_to_target32(s->nr_cpus, endian);
bitmap_blocks = DIV_ROUND_UP(s->len_dump_bitmap, block_size) * 2;
dh->bitmap_blocks = cpu_convert_to_target32(bitmap_blocks, endian);
-memcpy(&(dh->utsname.machine), "i686", 4);
+strncpy(dh->utsname.machine, ELF_MACHINE_UNAME,
sizeof(dh->utsname.machine));
if (s->flag_compress & DUMP_DH_COMPRESSED_ZLIB) {
status |= DUMP_DH_COMPRESSED_ZLIB;
@@ -924,7 +927,7 @@ static int create_header64(DumpState *s)
dh->nr_cpus = cpu_convert_to_target32(s->nr_cpus, endian);
bitmap_blocks = DIV_ROUND_UP(s->len_dump_bitmap, block_size) * 2;
dh->bitmap_blocks = cpu_convert_to_target32(bitmap_blocks, endian);
-memcpy(&(dh->utsname.machine), "x86_64", 6);
+strncpy(dh->utsname.machine, ELF_MACHINE_UNAME,
sizeof(dh->utsname.machine));
if (s->flag_compress & DUMP_DH_COMPRESSED_ZLIB) {
status |= DUMP_DH_COMPRESSED_ZLIB;
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1b94f0f..6abcd23 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -38,8 +38,10 @@
#ifdef TARGET_X86_64
#define ELF_MACHINE EM_X86_64
+#define ELF_MACHINE_UNAME "x86_64"
#else
#define ELF_MACHINE EM_386
+#define ELF_MACHINE_UNAME "i686"
#endif
#define CPUArchState struct CPUX86State
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 96c2b4a..6d46827 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -28,6 +28,7 @@
#define TARGET_LONG_BITS 64
#define ELF_MACHINEEM_S390
+#define ELF_MACHINE_UNAME "S390X"
#define CPUArchState struct CPUS390XState
--
1.8.1.4
Re: [Qemu-devel] timer issue on 1.7.0 and later
On 13 February 2014 16:09, Alex Bligh wrote: > I suspect the issue is not walking the lists, but calling > qemu_notify, breaking out of mainloop select etc. etc.; that > happens on a timer_modify but not on a timer_del. We could > fix this so that it only happened if the timer's expiry > time was reduced in timer_mod (I think). Surely you only want to do all that work if the fiddling with the timer means the next most immediate deadline has changed? If you have two timers, and A is going to expire before B, then even reducing B's expiry time shouldn't trigger renotifying unless it's reduced so much it will expire before A. thanks -- PMM
[Qemu-devel] [PATCH v3] vl: convert -m to QemuOpts
Adds option to -m
"mem" - startup memory amount
For compatibility with legacy CLI if suffix-less number is passed,
it assumes amount in MiB.
Otherwise user is free to use suffixed number using suffixes b,k/K,M,G
Signed-off-by: Igor Mammedov
Signed-off-by: Paolo Bonzini
---
v3:
- fixes suggested by Eric Blake
- check for empty string in more efficient way
- fix MB/MiB inconsistency
- use EXIT_FAILURE instead of 1
- add missing exit() if overflow occurres
v2:
- various fixes suggested by Laszlo Ersek
- check for overflow
- check for empty mem="" case
- reshuffle code to avoid conflicts with another series on list
- some style/typo fixes
---
qemu-options.hx | 12 ++---
vl.c| 73 +--
2 files changed, 68 insertions(+), 17 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 56e5fdf..2057fc6 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -210,14 +210,18 @@ use is discouraged as it may be removed from future
versions.
ETEXI
DEF("m", HAS_ARG, QEMU_OPTION_m,
-"-m megs set virtual RAM size to megs MB [default="
-stringify(DEFAULT_RAM_SIZE) "]\n", QEMU_ARCH_ALL)
+"-m [mem=]size\n"
+"configure guest RAM size\n"
+"mem: initial amount of guest memory (default: "
+stringify(DEFAULT_RAM_SIZE) "MiB)\n",
+QEMU_ARCH_ALL)
STEXI
@item -m @var{megs}
@findex -m
-Set virtual RAM size to @var{megs} megabytes. Default is 128 MiB. Optionally,
+Set virtual RAM size to @var{size} megabytes. Default is 128 MiB. Optionally,
a suffix of ``M'' or ``G'' can be used to signify a value in megabytes or
-gigabytes respectively.
+gigabytes respectively. If @var{size} is provided without unit suffix then MiB
+is assumed.
ETEXI
DEF("mem-path", HAS_ARG, QEMU_OPTION_mempath,
diff --git a/vl.c b/vl.c
index 7f2595c..64a695b 100644
--- a/vl.c
+++ b/vl.c
@@ -302,6 +302,21 @@ static struct {
{ .driver = "qxl-vga", .flag = &default_vga },
};
+#define MEMORY_OPTS "memory-opts"
+static QemuOptsList qemu_mem_opts = {
+.name = MEMORY_OPTS,
+.implied_opt_name = "mem",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_mem_opts.head),
+.merge_lists = true,
+.desc = {
+{
+.name = "mem",
+.type = QEMU_OPT_SIZE,
+},
+{ /* end of list */ }
+},
+};
+
static QemuOptsList qemu_rtc_opts = {
.name = "rtc",
.head = QTAILQ_HEAD_INITIALIZER(qemu_rtc_opts.head),
@@ -2868,6 +2883,8 @@ int main(int argc, char **argv, char **envp)
};
const char *trace_events = NULL;
const char *trace_file = NULL;
+const ram_addr_t default_ram_size = (ram_addr_t)DEFAULT_RAM_SIZE *
+1024 * 1024;
atexit(qemu_run_exit_notifiers);
error_set_progname(argv[0]);
@@ -2884,6 +2901,7 @@ int main(int argc, char **argv, char **envp)
module_call_init(MODULE_INIT_QOM);
+qemu_add_opts(&qemu_mem_opts);
qemu_add_opts(&qemu_drive_opts);
qemu_add_drive_opts(&qemu_legacy_drive_opts);
qemu_add_drive_opts(&qemu_common_drive_opts);
@@ -2921,7 +2939,7 @@ int main(int argc, char **argv, char **envp)
module_call_init(MODULE_INIT_MACHINE);
machine = find_default_machine();
cpu_model = NULL;
-ram_size = 0;
+ram_size = default_ram_size;
snapshot = 0;
cyls = heads = secs = 0;
translation = BIOS_ATA_TRANSLATION_AUTO;
@@ -3198,20 +3216,50 @@ int main(int argc, char **argv, char **envp)
exit(0);
break;
case QEMU_OPTION_m: {
-int64_t value;
uint64_t sz;
-char *end;
+const char *mem_str;
-value = strtosz(optarg, &end);
-if (value < 0 || *end) {
-fprintf(stderr, "qemu: invalid ram size: %s\n", optarg);
-exit(1);
+opts = qemu_opts_parse(qemu_find_opts(MEMORY_OPTS),
+ optarg, 1);
+if (!opts) {
+exit(EXIT_FAILURE);
+}
+
+mem_str = qemu_opt_get(opts, "mem");
+if (!mem_str) {
+fprintf(stderr, "qemu: invalid -m option, missing "
+"'mem' option\n");
+exit(EXIT_FAILURE);
+}
+if (!*mem_str) {
+fprintf(stderr, "qemu: missing 'mem' option value\n");
+exit(EXIT_FAILURE);
+}
+
+sz = qemu_opt_get_size(opts, "mem", ram_size);
+
+/* Fix up legacy suffix-less format */
+if (g_ascii_isdigit(mem_str[strlen(mem_str) - 1])) {
+uint64_t overflow_check = sz;
+
+sz <<= 20;
+if ((sz >> 20) != overflow_check) {
+fprintf(s
Re: [Qemu-devel] [PATCH v2 1/4] target-mips: add CPU definition for MIPS32R5
Am 13.02.2014 15:51, schrieb Peter Maydell:
> On 10 February 2014 15:42, Peter Maydell wrote:
>> On 10 February 2014 13:51, Andreas Färber wrote:
>>> Am 24.01.2014 17:18, schrieb Petar Jovanovic:
From: Petar Jovanovic
--- 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.
*/
>>>
>>> That is not really possible. QEMU needs to keep command line backwards
>>> compatibility, so if you add a generic model now, we will need to live
>>> with the generic model for a long time. What's the difficulty with
>>> taking "a real CPU model"? Is there no silicon yet or just a code name
>>> rather than a marketing name?
>>
>> Good point, though I notice we have two MIPS CPUs already
>> with this same 'FIXME' comment about being generic.
>
> So before I apply the pull request with this patch, does
> anybody want to actually object to adding another 'generic'
> MIPS CPU to the two we have already? It seems reasonable
> enough to me.
No objection from my side. I was however expecting Petar to drop the
FIXME in response to my reply, which I believe was still in the PULL.
Peter, are you planning (or did I miss) a follow-up cleaning that up,
whether for your new model or for all?
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] timer issue on 1.7.0 and later
On 13 Feb 2014, at 15:36, Peter Maydell wrote: > On 10 February 2014 17:15, Rob Herring wrote: >> This doesn't appear to be too useful. The AvgLength is large because >> INT64_MAX / GTIMER_SCALE is used as the next timer value when no timer >> is needed. > > The code already uses timer_del() when no next timer is needed > (that's the "timer disabled" case in gt_recalc_timer()). We only > set the timer to INT64_MAX / GTIMER_SCALE for the case where the > architecture demands an interrupt occurs in the really distant > future. Admittedly the chances of QEMU still running in 200 years > time are quite low, but it seemed at the time to be better to just > write the code to behave correctly, since I assumed that calling > timer_mod with a large timeout wasn't going to be really more > expensive than calling timer_del. (Looking at the code, we end > up walking the list of timers twice rather than once.) I suspect the issue is not walking the lists, but calling qemu_notify, breaking out of mainloop select etc. etc.; that happens on a timer_modify but not on a timer_del. We could fix this so that it only happened if the timer's expiry time was reduced in timer_mod (I think). -- Alex Bligh
[Qemu-devel] [PULL 10/22] dump: add support for lzo/snappy
From: qiaonuohan
kdump-compressed format supports three compression format, zlib/lzo/snappy.
Currently, only zlib is available. This patch is used to support lzo/snappy.
'--enable-lzo/--enable-snappy' is needed to be specified with configure to make
lzo/snappy available for qemu
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
configure | 54 ++
1 file changed, 54 insertions(+)
diff --git a/configure b/configure
index 88133a1..9b2dfd0 100755
--- a/configure
+++ b/configure
@@ -245,6 +245,8 @@ libusb=""
usb_redir=""
glx=""
zlib="yes"
+lzo="no"
+snappy="no"
guest_agent=""
guest_agent_with_vss="no"
vss_win32_sdk=""
@@ -953,6 +955,10 @@ for opt do
;;
--disable-zlib-test) zlib="no"
;;
+ --enable-lzo) lzo="yes"
+ ;;
+ --enable-snappy) snappy="yes"
+ ;;
--enable-guest-agent) guest_agent="yes"
;;
--disable-guest-agent) guest_agent="no"
@@ -1242,6 +1248,8 @@ Advanced options (experts only):
--enable-libusb enable libusb (for usb passthrough)
--disable-usb-redir disable usb network redirection support
--enable-usb-redir enable usb network redirection support
+ --enable-lzo enable the support of lzo compression library
+ --enable-snappy enable the support of snappy compression library
--disable-guest-agentdisable building of the QEMU Guest Agent
--enable-guest-agent enable building of the QEMU Guest Agent
--with-vss-sdk=SDK-path enable Windows VSS support in QEMU Guest Agent
@@ -1546,6 +1554,42 @@ fi
libs_softmmu="$libs_softmmu -lz"
##
+# lzo check
+
+if test "$lzo" != "no" ; then
+cat > $TMPC << EOF
+#include
+int main(void) { lzo_version(); return 0; }
+EOF
+if compile_prog "" "-llzo2" ; then
+:
+else
+error_exit "lzo check failed" \
+"Make sure to have the lzo libs and headers installed."
+fi
+
+libs_softmmu="$libs_softmmu -llzo2"
+fi
+
+##
+# snappy check
+
+if test "$snappy" != "no" ; then
+cat > $TMPC << EOF
+#include
+int main(void) { snappy_max_compressed_length(4096); return 0; }
+EOF
+if compile_prog "" "-lsnappy" ; then
+:
+else
+error_exit "snappy check failed" \
+"Make sure to have the snappy libs and headers installed."
+fi
+
+libs_softmmu="$libs_softmmu -lsnappy"
+fi
+
+##
# libseccomp check
if test "$seccomp" != "no" ; then
@@ -3865,6 +3909,8 @@ echo "libssh2 support $libssh2"
echo "TPM passthrough $tpm_passthrough"
echo "QOM debugging $qom_cast_debug"
echo "vhdx $vhdx"
+echo "lzo support $lzo"
+echo "snappy support$snappy"
if test "$sdl_too_old" = "yes"; then
echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -4180,6 +4226,14 @@ if test "$glx" = "yes" ; then
echo "GLX_LIBS=$glx_libs" >> $config_host_mak
fi
+if test "$lzo" = "yes" ; then
+ echo "CONFIG_LZO=y" >> $config_host_mak
+fi
+
+if test "$snappy" = "yes" ; then
+ echo "CONFIG_SNAPPY=y" >> $config_host_mak
+fi
+
if test "$libiscsi" = "yes" ; then
echo "CONFIG_LIBISCSI=y" >> $config_host_mak
if test "$libiscsi_version" = "1.4.0"; then
--
1.8.1.4
[Qemu-devel] [PULL 14/22] dump: add APIs to operate DataCache
From: qiaonuohan
DataCache is used to store data temporarily, then the data will be written to
vmcore. These functions will be called later when writing data of page to
vmcore.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 47 +++
include/sysemu/dump.h | 9 +
2 files changed, 56 insertions(+)
diff --git a/dump.c b/dump.c
index 5755534..a7a85d3 100644
--- a/dump.c
+++ b/dump.c
@@ -1165,6 +1165,53 @@ out:
return ret;
}
+static void prepare_data_cache(DataCache *data_cache, DumpState *s,
+ off_t offset)
+{
+data_cache->fd = s->fd;
+data_cache->data_size = 0;
+data_cache->buf_size = BUFSIZE_DATA_CACHE;
+data_cache->buf = g_malloc0(BUFSIZE_DATA_CACHE);
+data_cache->offset = offset;
+}
+
+static int write_cache(DataCache *dc, const void *buf, size_t size,
+ bool flag_sync)
+{
+/*
+ * dc->buf_size should not be less than size, otherwise dc will never be
+ * enough
+ */
+assert(size <= dc->buf_size);
+
+/*
+ * if flag_sync is set, synchronize data in dc->buf into vmcore.
+ * otherwise check if the space is enough for caching data in buf, if not,
+ * write the data in dc->buf to dc->fd and reset dc->buf
+ */
+if ((!flag_sync && dc->data_size + size > dc->buf_size) ||
+(flag_sync && dc->data_size > 0)) {
+if (write_buffer(dc->fd, dc->offset, dc->buf, dc->data_size) < 0) {
+return -1;
+}
+
+dc->offset += dc->data_size;
+dc->data_size = 0;
+}
+
+if (!flag_sync) {
+memcpy(dc->buf + dc->data_size, buf, size);
+dc->data_size += size;
+}
+
+return 0;
+}
+
+static void free_data_cache(DataCache *data_cache)
+{
+g_free(data_cache->buf);
+}
+
static ram_addr_t get_start_block(DumpState *s)
{
GuestPhysBlock *block;
diff --git a/include/sysemu/dump.h b/include/sysemu/dump.h
index 6d4d0bc..92a95e4 100644
--- a/include/sysemu/dump.h
+++ b/include/sysemu/dump.h
@@ -41,6 +41,7 @@
#define DISKDUMP_HEADER_BLOCKS (1)
#define BUFSIZE_BITMAP (TARGET_PAGE_SIZE)
#define PFN_BUFBITMAP (CHAR_BIT * BUFSIZE_BITMAP)
+#define BUFSIZE_DATA_CACHE (TARGET_PAGE_SIZE * 4)
typedef struct ArchDumpInfo {
int d_machine; /* Architecture */
@@ -142,6 +143,14 @@ typedef struct QEMU_PACKED KdumpSubHeader64 {
uint64_t max_mapnr_64; /* header_version 6 and later */
} KdumpSubHeader64;
+typedef struct DataCache {
+int fd; /* fd of the file where to write the cached data */
+uint8_t *buf; /* buffer for cached data */
+size_t buf_size;/* size of the buf */
+size_t data_size; /* size of cached data in buf */
+off_t offset; /* offset of the file */
+} DataCache;
+
struct GuestPhysBlockList; /* memory_mapping.h */
int cpu_get_dump_info(ArchDumpInfo *info,
const struct GuestPhysBlockList *guest_phys_blocks);
--
1.8.1.4
Re: [Qemu-devel] [PULL 0/4] user-mode FR switch support for MIPS32r5
> g...@github.com:petar-jovanovic/qemu.git mips-ufrp > I can fix things up manually, so you don't need to resend, but > this isn't a valid git remote URL (at least, it doesn't work > for me). True, for the above link you need ssh key in-place, it's valid for me only. Sorry! > You probably wanted to say: > git://github.com/petar-jovanovic/qemu.git mips-ufrp I should have written that, yes. Thanks. Regards, Petar From: Peter Maydell [peter.mayd...@linaro.org] Sent: Thursday, February 13, 2014 3:59 PM To: Petar Jovanovic Cc: QEMU Developers; Petar Jovanovic; Aurelien Jarno; Andreas Färber Subject: Re: [PULL 0/4] user-mode FR switch support for MIPS32r5 On 10 February 2014 16:19, Petar Jovanovic wrote: > The following changes since commit 1f6b12f75f2c22f861d0202374033a7594c91707: > > Merge remote-tracking branch 'remotes/mwalle/tags/lm32-fixes/20140204' into > staging (2014-02-08 15:57:51 +) > > are available in the git repository at: > > > g...@github.com:petar-jovanovic/qemu.git mips-ufrp I can fix things up manually, so you don't need to resend, but this isn't a valid git remote URL (at least, it doesn't work for me). You probably wanted to say: git://github.com/petar-jovanovic/qemu.git mips-ufrp thanks -- PMM
[Qemu-devel] [PULL 21/22] monitor: Add object_del id argument completion.
From: Hani Benhabiles
Signed-off-by: Hani Benhabiles
Signed-off-by: Luiz Capitulino
---
monitor.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/monitor.c b/monitor.c
index 4ffe44d..5b863c9 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4294,6 +4294,27 @@ static void device_del_completion(ReadLineState *rs,
BusState *bus,
}
}
+static void object_del_completion(ReadLineState *rs, const char *str)
+{
+ObjectPropertyInfoList *list, *start;
+size_t len;
+
+len = strlen(str);
+readline_set_completion_index(rs, len);
+
+start = list = qmp_qom_list("/objects", NULL);
+while (list) {
+ObjectPropertyInfo *info = list->value;
+
+if (!strncmp(info->type, "child<", 5)
+&& !strncmp(info->name, str, len)) {
+readline_add_completion(rs, info->name);
+}
+list = list->next;
+}
+qapi_free_ObjectPropertyInfoList(start);
+}
+
static void monitor_find_completion_by_table(Monitor *mon,
const mon_cmd_t *cmd_table,
char **args,
@@ -4379,6 +4400,8 @@ static void monitor_find_completion_by_table(Monitor *mon,
size_t len = strlen(str);
readline_set_completion_index(mon->rs, len);
device_del_completion(mon->rs, sysbus_get_default(), str, len);
+} else if (!strcmp(cmd->name, "object_del") && nb_args == 2) {
+object_del_completion(mon->rs, str);
}
break;
default:
--
1.8.1.4
[Qemu-devel] [PULL 20/22] monitor: Add device_add device argument completion.
From: Hani Benhabiles
Signed-off-by: Hani Benhabiles
Signed-off-by: Luiz Capitulino
---
monitor.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/monitor.c b/monitor.c
index c90fc1d..4ffe44d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4254,6 +4254,27 @@ static const char *next_arg_type(const char *typestr)
return (p != NULL ? ++p : typestr);
}
+static void device_add_completion(ReadLineState *rs, const char *str)
+{
+GSList *list, *elt;
+size_t len;
+
+len = strlen(str);
+readline_set_completion_index(rs, len);
+list = elt = object_class_get_list(TYPE_DEVICE, false);
+while (elt) {
+const char *name;
+DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, elt->data,
+ TYPE_DEVICE);
+name = object_class_get_name(OBJECT_CLASS(dc));
+if (!strncmp(name, str, len)) {
+readline_add_completion(rs, name);
+}
+elt = elt->next;
+}
+g_slist_free(list);
+}
+
static void device_del_completion(ReadLineState *rs, BusState *bus,
const char *str, size_t len)
{
@@ -4336,6 +4357,11 @@ static void monitor_find_completion_by_table(Monitor
*mon,
readline_set_completion_index(mon->rs, strlen(str));
bdrv_iterate(block_completion_it, &mbs);
break;
+case 'O':
+if (!strcmp(cmd->name, "device_add") && nb_args == 2) {
+device_add_completion(mon->rs, str);
+}
+break;
case 's':
case 'S':
if (!strcmp(cmd->name, "sendkey")) {
--
1.8.1.4
Re: [Qemu-devel] [PATCH v2] SPARC: Add and use CPU_FEATURE_CASA
On 02/13/2014 03:55 PM, Fabien Chouteau wrote:
> On 02/13/2014 02:00 PM, Sebastian Huber wrote:
>> On 2014-02-13 13:01, Fabien Chouteau wrote:
>>> On 02/13/2014 10:52 AM, Sebastian Huber wrote:
The LEON3 processor has support for the CASA instruction which is
normally only available for SPARC V9 processors. Binutils 2.24
and GCC 4.9 will support this instruction for LEON3. GCC uses it to
generate C11 atomic operations.
The CAS synthetic instruction uses an ASI of 0x80. If TARGET_SPARC64 is
not defined use a supervisor data load/store for an ASI of 0x80 in
helper_ld_asi()/helper_st_asi().
>>>
>>> Hello Sebastian,
>>>
>>> If I understand correctly, the difference with V1 is that ASI 0x80. Why
>>> did you chose Supervisor data access against User data access?
>>
>> User data access would work also. I don't have a preference here.
>>
>>> (I cannot
>>> find documentation about 0x80 ASI)
>>
>> GCC will generate CAS instructions, e.g.
>
> ...
>
>> In the GNU Binutils you find:
>>
>> opcodes/sparc-opc.c:{ "cas",F3(3, 0x3c, 0)|ASI(0x80), F3(~3, ~0x3c,
>> ~0)|ASI(~0x80), "[1],2,d", F_ALIAS, 0, v9andleon }, /* casa
>> [rs1]ASI_P,rs2,rd */
>>
>> This is where the 0x80 comes from.
>>
>
> In some leon3 doc I found this:
>
> 62.2.7 Compare and Swap instruction (CASA)
> LEON3 implements the SPARC V9 Compare and Swap Alternative (CASA)
> instruction. The CASA
> is enabled the interger load delay is set to 1 and the NOTAG generic is 0.
> The CASA operates as
> described in the SPARC V9 manual. The instruction is privileged but setting
> ASI = 0xA (user data)
> will allow it to be used in user mode.
>
> Which confirm privileged instruction. I will ask our GCC expert if they
> know where that 0x80 ASI comes from.
>
This ASI 0x80 is really defined nowhere in Leon3 not even in the sources :)
Maybe there's a bug in binutils... Did you try to run this program on a real
board?
--- sparc.vhd ---
subtype asi_type is std_logic_vector(4 downto 0);
constant ASI_SYSR: asi_type := "00010"; -- 0x02
constant ASI_UINST : asi_type := "01000"; -- 0x08
constant ASI_SINST : asi_type := "01001"; -- 0x09
constant ASI_UDATA : asi_type := "01010"; -- 0x0A
constant ASI_SDATA : asi_type := "01011"; -- 0x0B
constant ASI_ITAG: asi_type := "01100"; -- 0x0C
constant ASI_IDATA : asi_type := "01101"; -- 0x0D
constant ASI_DTAG: asi_type := "01110"; -- 0x0E
constant ASI_DDATA : asi_type := "0"; -- 0x0F
constant ASI_IFLUSH : asi_type := "1"; -- 0x10
constant ASI_DFLUSH : asi_type := "10001"; -- 0x11
constant ASI_FLUSH_PAGE : std_logic_vector(4 downto 0) := "1"; -- 0x10
i/dcache flush page
constant ASI_FLUSH_CTX : std_logic_vector(4 downto 0) := "10011"; -- 0x13
i/dcache flush ctx
constant ASI_DCTX : std_logic_vector(4 downto 0) := "10100"; -- 0x14
dcache ctx
constant ASI_ICTX : std_logic_vector(4 downto 0) := "10101"; -- 0x15
icache ctx
constant ASI_MMUFLUSHPROBE : std_logic_vector(4 downto 0) := "11000"; -- 0x18
i/dtlb flush/(probe)
constant ASI_MMUREGS: std_logic_vector(4 downto 0) := "11001"; -- 0x19
mmu regs access
constant ASI_MMU_BP : std_logic_vector(4 downto 0) := "11100"; -- 0x1c
mmu Bypass
constant ASI_MMU_DIAG : std_logic_vector(4 downto 0) := "11101"; -- 0x1d
mmu diagnostic
--constant ASI_MMU_DSU: std_logic_vector(4 downto 0) := "1"; --
0x1f mmu diagnostic
constant ASI_MMUSNOOP_DTAG : std_logic_vector(4 downto 0) := "0"; -- 0x1e
mmusnoop physical dtag
Re: [Qemu-devel] timer issue on 1.7.0 and later
On 10 February 2014 17:15, Rob Herring wrote: > This doesn't appear to be too useful. The AvgLength is large because > INT64_MAX / GTIMER_SCALE is used as the next timer value when no timer > is needed. The code already uses timer_del() when no next timer is needed (that's the "timer disabled" case in gt_recalc_timer()). We only set the timer to INT64_MAX / GTIMER_SCALE for the case where the architecture demands an interrupt occurs in the really distant future. Admittedly the chances of QEMU still running in 200 years time are quite low, but it seemed at the time to be better to just write the code to behave correctly, since I assumed that calling timer_mod with a large timeout wasn't going to be really more expensive than calling timer_del. (Looking at the code, we end up walking the list of timers twice rather than once.) thanks -- PMM
[Qemu-devel] [PULL 18/22] dump: add 'query-dump-guest-memory-capability' command
From: qiaonuohan
'query-dump-guest-memory-capability' is used to query the available formats for
'dump-guest-memory'. The output of the command will be like:
-> { "execute": "query-dump-guest-memory-capability" }
<- { "return": { "formats":
["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
Signed-off-by: Qiao Nuohan
Reviewed-by: Eric Blake
Signed-off-by: Luiz Capitulino
---
dump.c | 33 +
qapi-schema.json | 24
qmp-commands.hx | 20
3 files changed, 77 insertions(+)
diff --git a/dump.c b/dump.c
index 78d226f..c7cd30b 100644
--- a/dump.c
+++ b/dump.c
@@ -1791,3 +1791,36 @@ void qmp_dump_guest_memory(bool paging, const char
*file, bool has_begin,
g_free(s);
}
+
+DumpGuestMemoryCapability *qmp_query_dump_guest_memory_capability(Error **errp)
+{
+DumpGuestMemoryFormatList *item;
+DumpGuestMemoryCapability *cap =
+ g_malloc0(sizeof(DumpGuestMemoryCapability));
+
+/* elf is always available */
+item = g_malloc0(sizeof(DumpGuestMemoryFormatList));
+cap->formats = item;
+item->value = DUMP_GUEST_MEMORY_FORMAT_ELF;
+
+/* kdump-zlib is always available */
+item->next = g_malloc0(sizeof(DumpGuestMemoryFormatList));
+item = item->next;
+item->value = DUMP_GUEST_MEMORY_FORMAT_KDUMP_ZLIB;
+
+/* add new item if kdump-lzo is available */
+#ifdef CONFIG_LZO
+item->next = g_malloc0(sizeof(DumpGuestMemoryFormatList));
+item = item->next;
+item->value = DUMP_GUEST_MEMORY_FORMAT_KDUMP_LZO;
+#endif
+
+/* add new item if kdump-snappy is available */
+#ifdef CONFIG_SNAPPY
+item->next = g_malloc0(sizeof(DumpGuestMemoryFormatList));
+item = item->next;
+item->value = DUMP_GUEST_MEMORY_FORMAT_KDUMP_SNAPPY;
+#endif
+
+return cap;
+}
diff --git a/qapi-schema.json b/qapi-schema.json
index 6ff6d49..47d412b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2805,6 +2805,30 @@
'*length': 'int', '*format': 'DumpGuestMemoryFormat' } }
##
+# @DumpGuestMemoryCapability:
+#
+# A list of the available formats for dump-guest-memory
+#
+# Since: 2.0
+##
+{ 'type': 'DumpGuestMemoryCapability',
+ 'data': {
+ 'formats': ['DumpGuestMemoryFormat'] } }
+
+##
+# @query-dump-guest-memory-capability:
+#
+# Returns the available formats for dump-guest-memory
+#
+# Returns: A @DumpGuestMemoryCapability object listing available formats for
+# dump-guest-memory
+#
+# Since: 2.0
+##
+{ 'command': 'query-dump-guest-memory-capability',
+ 'returns': 'DumpGuestMemoryCapability' }
+
+##
# @netdev_add:
#
# Add a network backend.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 8da11ac..d53c33c 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -829,6 +829,26 @@ Notes:
EQMP
{
+.name = "query-dump-guest-memory-capability",
+.args_type = "",
+.mhandler.cmd_new =
qmp_marshal_input_query_dump_guest_memory_capability,
+},
+
+SQMP
+query-dump-guest-memory-capability
+--
+
+Show available formats for 'dump-guest-memory'
+
+Example:
+
+-> { "execute": "query-dump-guest-memory-capability" }
+<- { "return": { "formats":
+["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
+
+EQMP
+
+{
.name = "netdev_add",
.args_type = "netdev:O",
.mhandler.cmd_new = qmp_netdev_add,
--
1.8.1.4
[Qemu-devel] [PULL 12/22] dump: add API to write dump header
From: qiaonuohan
the functions are used to write header of kdump-compressed format to vmcore.
Header of kdump-compressed format includes:
1. common header: DiskDumpHeader32 / DiskDumpHeader64
2. sub header: KdumpSubHeader32 / KdumpSubHeader64
3. extra information: only elf notes here
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 223 ++
include/sysemu/dump.h | 96 ++
2 files changed, 319 insertions(+)
diff --git a/dump.c b/dump.c
index 3a1944e..4b2799f 100644
--- a/dump.c
+++ b/dump.c
@@ -778,6 +778,229 @@ static int buf_write_note(const void *buf, size_t size,
void *opaque)
return 0;
}
+/* write common header, sub header and elf note to vmcore */
+static int create_header32(DumpState *s)
+{
+int ret = 0;
+DiskDumpHeader32 *dh = NULL;
+KdumpSubHeader32 *kh = NULL;
+size_t size;
+int endian = s->dump_info.d_endian;
+uint32_t block_size;
+uint32_t sub_hdr_size;
+uint32_t bitmap_blocks;
+uint32_t status = 0;
+uint64_t offset_note;
+
+/* write common header, the version of kdump-compressed format is 6th */
+size = sizeof(DiskDumpHeader32);
+dh = g_malloc0(size);
+
+strncpy(dh->signature, KDUMP_SIGNATURE, strlen(KDUMP_SIGNATURE));
+dh->header_version = cpu_convert_to_target32(6, endian);
+block_size = s->page_size;
+dh->block_size = cpu_convert_to_target32(block_size, endian);
+sub_hdr_size = sizeof(struct KdumpSubHeader32) + s->note_size;
+sub_hdr_size = DIV_ROUND_UP(sub_hdr_size, block_size);
+dh->sub_hdr_size = cpu_convert_to_target32(sub_hdr_size, endian);
+/* dh->max_mapnr may be truncated, full 64bit is in kh.max_mapnr_64 */
+dh->max_mapnr = cpu_convert_to_target32(MIN(s->max_mapnr, UINT_MAX),
+endian);
+dh->nr_cpus = cpu_convert_to_target32(s->nr_cpus, endian);
+bitmap_blocks = DIV_ROUND_UP(s->len_dump_bitmap, block_size) * 2;
+dh->bitmap_blocks = cpu_convert_to_target32(bitmap_blocks, endian);
+memcpy(&(dh->utsname.machine), "i686", 4);
+
+if (s->flag_compress & DUMP_DH_COMPRESSED_ZLIB) {
+status |= DUMP_DH_COMPRESSED_ZLIB;
+}
+#ifdef CONFIG_LZO
+if (s->flag_compress & DUMP_DH_COMPRESSED_LZO) {
+status |= DUMP_DH_COMPRESSED_LZO;
+}
+#endif
+#ifdef CONFIG_SNAPPY
+if (s->flag_compress & DUMP_DH_COMPRESSED_SNAPPY) {
+status |= DUMP_DH_COMPRESSED_SNAPPY;
+}
+#endif
+dh->status = cpu_convert_to_target32(status, endian);
+
+if (write_buffer(s->fd, 0, dh, size) < 0) {
+dump_error(s, "dump: failed to write disk dump header.\n");
+ret = -1;
+goto out;
+}
+
+/* write sub header */
+size = sizeof(KdumpSubHeader32);
+kh = g_malloc0(size);
+
+/* 64bit max_mapnr_64 */
+kh->max_mapnr_64 = cpu_convert_to_target64(s->max_mapnr, endian);
+kh->phys_base = cpu_convert_to_target32(PHYS_BASE, endian);
+kh->dump_level = cpu_convert_to_target32(DUMP_LEVEL, endian);
+
+offset_note = DISKDUMP_HEADER_BLOCKS * block_size + size;
+kh->offset_note = cpu_convert_to_target64(offset_note, endian);
+kh->note_size = cpu_convert_to_target32(s->note_size, endian);
+
+if (write_buffer(s->fd, DISKDUMP_HEADER_BLOCKS *
+ block_size, kh, size) < 0) {
+dump_error(s, "dump: failed to write kdump sub header.\n");
+ret = -1;
+goto out;
+}
+
+/* write note */
+s->note_buf = g_malloc0(s->note_size);
+s->note_buf_offset = 0;
+
+/* use s->note_buf to store notes temporarily */
+if (write_elf32_notes(buf_write_note, s) < 0) {
+ret = -1;
+goto out;
+}
+
+if (write_buffer(s->fd, offset_note, s->note_buf,
+ s->note_size) < 0) {
+dump_error(s, "dump: failed to write notes");
+ret = -1;
+goto out;
+}
+
+/* get offset of dump_bitmap */
+s->offset_dump_bitmap = (DISKDUMP_HEADER_BLOCKS + sub_hdr_size) *
+ block_size;
+
+/* get offset of page */
+s->offset_page = (DISKDUMP_HEADER_BLOCKS + sub_hdr_size + bitmap_blocks) *
+ block_size;
+
+out:
+g_free(dh);
+g_free(kh);
+g_free(s->note_buf);
+
+return ret;
+}
+
+/* write common header, sub header and elf note to vmcore */
+static int create_header64(DumpState *s)
+{
+int ret = 0;
+DiskDumpHeader64 *dh = NULL;
+KdumpSubHeader64 *kh = NULL;
+size_t size;
+int endian = s->dump_info.d_endian;
+uint32_t block_size;
+uint32_t sub_hdr_size;
+uint32_t bitmap_blocks;
+uint32_t status = 0;
+uint64_t offset_note;
+
+/* write common header, the version of kdump-compressed format is 6th */
+size = sizeof(DiskDumpHeader64);
+dh = g_malloc0(size);
+
+strncpy(dh->signature, KDUMP_SIGNATURE, strlen(KDUMP_SIGNATURE));
+dh->header_version
[Qemu-devel] [PULL 22/22] monitor: Add object_add class argument completion.
From: Hani Benhabiles
Signed-off-by: Hani Benhabiles
Signed-off-by: Luiz Capitulino
---
monitor.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/monitor.c b/monitor.c
index 5b863c9..de90fba 100644
--- a/monitor.c
+++ b/monitor.c
@@ -56,6 +56,7 @@
#include "qapi/qmp/qjson.h"
#include "qapi/qmp/json-streamer.h"
#include "qapi/qmp/json-parser.h"
+#include
#include "qemu/osdep.h"
#include "cpu.h"
#include "trace.h"
@@ -4275,6 +4276,26 @@ static void device_add_completion(ReadLineState *rs,
const char *str)
g_slist_free(list);
}
+static void object_add_completion(ReadLineState *rs, const char *str)
+{
+GSList *list, *elt;
+size_t len;
+
+len = strlen(str);
+readline_set_completion_index(rs, len);
+list = elt = object_class_get_list(TYPE_USER_CREATABLE, false);
+while (elt) {
+const char *name;
+
+name = object_class_get_name(OBJECT_CLASS(elt->data));
+if (!strncmp(name, str, len) && strcmp(name, TYPE_USER_CREATABLE)) {
+readline_add_completion(rs, name);
+}
+elt = elt->next;
+}
+g_slist_free(list);
+}
+
static void device_del_completion(ReadLineState *rs, BusState *bus,
const char *str, size_t len)
{
@@ -4381,6 +4402,8 @@ static void monitor_find_completion_by_table(Monitor *mon,
case 'O':
if (!strcmp(cmd->name, "device_add") && nb_args == 2) {
device_add_completion(mon->rs, str);
+} else if (!strcmp(cmd->name, "object_add") && nb_args == 2) {
+object_add_completion(mon->rs, str);
}
break;
case 's':
--
1.8.1.4
[Qemu-devel] [PULL 06/22] dump: add argument to write_elfxx_notes
From: qiaonuohan
write_elf32_notes/wirte_elf64_notes use fd_write_vmcore to write elf notes to
vmcore. Adding parameter "WriteCoreDumpFunction f" makes it available to choose
the method of writing elf notes
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/dump.c b/dump.c
index 42622de..c9d3492 100644
--- a/dump.c
+++ b/dump.c
@@ -271,7 +271,7 @@ static inline int cpu_index(CPUState *cpu)
return cpu->cpu_index + 1;
}
-static int write_elf64_notes(DumpState *s)
+static int write_elf64_notes(WriteCoreDumpFunction f, DumpState *s)
{
CPUState *cpu;
int ret;
@@ -279,7 +279,7 @@ static int write_elf64_notes(DumpState *s)
CPU_FOREACH(cpu) {
id = cpu_index(cpu);
-ret = cpu_write_elf64_note(fd_write_vmcore, cpu, id, s);
+ret = cpu_write_elf64_note(f, cpu, id, s);
if (ret < 0) {
dump_error(s, "dump: failed to write elf notes.\n");
return -1;
@@ -287,7 +287,7 @@ static int write_elf64_notes(DumpState *s)
}
CPU_FOREACH(cpu) {
-ret = cpu_write_elf64_qemunote(fd_write_vmcore, cpu, s);
+ret = cpu_write_elf64_qemunote(f, cpu, s);
if (ret < 0) {
dump_error(s, "dump: failed to write CPU status.\n");
return -1;
@@ -321,7 +321,7 @@ static int write_elf32_note(DumpState *s)
return 0;
}
-static int write_elf32_notes(DumpState *s)
+static int write_elf32_notes(WriteCoreDumpFunction f, DumpState *s)
{
CPUState *cpu;
int ret;
@@ -329,7 +329,7 @@ static int write_elf32_notes(DumpState *s)
CPU_FOREACH(cpu) {
id = cpu_index(cpu);
-ret = cpu_write_elf32_note(fd_write_vmcore, cpu, id, s);
+ret = cpu_write_elf32_note(f, cpu, id, s);
if (ret < 0) {
dump_error(s, "dump: failed to write elf notes.\n");
return -1;
@@ -337,7 +337,7 @@ static int write_elf32_notes(DumpState *s)
}
CPU_FOREACH(cpu) {
-ret = cpu_write_elf32_qemunote(fd_write_vmcore, cpu, s);
+ret = cpu_write_elf32_qemunote(f, cpu, s);
if (ret < 0) {
dump_error(s, "dump: failed to write CPU status.\n");
return -1;
@@ -574,7 +574,7 @@ static int dump_begin(DumpState *s)
}
/* write notes to vmcore */
-if (write_elf64_notes(s) < 0) {
+if (write_elf64_notes(fd_write_vmcore, s) < 0) {
return -1;
}
@@ -597,7 +597,7 @@ static int dump_begin(DumpState *s)
}
/* write notes to vmcore */
-if (write_elf32_notes(s) < 0) {
+if (write_elf32_notes(fd_write_vmcore, s) < 0) {
return -1;
}
}
--
1.8.1.4
[Qemu-devel] [PULL 13/22] dump: add API to write dump_bitmap
From: qiaonuohan
functions are used to write 1st and 2nd dump_bitmap of kdump-compressed format,
which is used to indicate whether the corresponded page is existed in vmcore.
1st and 2nd dump_bitmap are same, because dump level is specified to 1 here.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 164 ++
include/sysemu/dump.h | 2 +
2 files changed, 166 insertions(+)
diff --git a/dump.c b/dump.c
index 4b2799f..5755534 100644
--- a/dump.c
+++ b/dump.c
@@ -1001,6 +1001,170 @@ static int write_dump_header(DumpState *s)
}
}
+/*
+ * set dump_bitmap sequencely. the bit before last_pfn is not allowed to be
+ * rewritten, so if need to set the first bit, set last_pfn and pfn to 0.
+ * set_dump_bitmap will always leave the recently set bit un-sync. And setting
+ * (last bit + sizeof(buf) * 8) to 0 will do flushing the content in buf into
+ * vmcore, ie. synchronizing un-sync bit into vmcore.
+ */
+static int set_dump_bitmap(uint64_t last_pfn, uint64_t pfn, bool value,
+ uint8_t *buf, DumpState *s)
+{
+off_t old_offset, new_offset;
+off_t offset_bitmap1, offset_bitmap2;
+uint32_t byte, bit;
+
+/* should not set the previous place */
+assert(last_pfn <= pfn);
+
+/*
+ * if the bit needed to be set is not cached in buf, flush the data in buf
+ * to vmcore firstly.
+ * making new_offset be bigger than old_offset can also sync remained data
+ * into vmcore.
+ */
+old_offset = BUFSIZE_BITMAP * (last_pfn / PFN_BUFBITMAP);
+new_offset = BUFSIZE_BITMAP * (pfn / PFN_BUFBITMAP);
+
+while (old_offset < new_offset) {
+/* calculate the offset and write dump_bitmap */
+offset_bitmap1 = s->offset_dump_bitmap + old_offset;
+if (write_buffer(s->fd, offset_bitmap1, buf,
+ BUFSIZE_BITMAP) < 0) {
+return -1;
+}
+
+/* dump level 1 is chosen, so 1st and 2nd bitmap are same */
+offset_bitmap2 = s->offset_dump_bitmap + s->len_dump_bitmap +
+ old_offset;
+if (write_buffer(s->fd, offset_bitmap2, buf,
+ BUFSIZE_BITMAP) < 0) {
+return -1;
+}
+
+memset(buf, 0, BUFSIZE_BITMAP);
+old_offset += BUFSIZE_BITMAP;
+}
+
+/* get the exact place of the bit in the buf, and set it */
+byte = (pfn % PFN_BUFBITMAP) / CHAR_BIT;
+bit = (pfn % PFN_BUFBITMAP) % CHAR_BIT;
+if (value) {
+buf[byte] |= 1u << bit;
+} else {
+buf[byte] &= ~(1u << bit);
+}
+
+return 0;
+}
+
+/*
+ * exam every page and return the page frame number and the address of the
page.
+ * bufptr can be NULL. note: the blocks here is supposed to reflect guest-phys
+ * blocks, so block->target_start and block->target_end should be interal
+ * multiples of the target page size.
+ */
+static bool get_next_page(GuestPhysBlock **blockptr, uint64_t *pfnptr,
+ uint8_t **bufptr, DumpState *s)
+{
+GuestPhysBlock *block = *blockptr;
+hwaddr addr;
+uint8_t *buf;
+
+/* block == NULL means the start of the iteration */
+if (!block) {
+block = QTAILQ_FIRST(&s->guest_phys_blocks.head);
+*blockptr = block;
+assert(block->target_start % s->page_size == 0);
+assert(block->target_end % s->page_size == 0);
+*pfnptr = paddr_to_pfn(block->target_start, s->page_shift);
+if (bufptr) {
+*bufptr = block->host_addr;
+}
+return true;
+}
+
+*pfnptr = *pfnptr + 1;
+addr = pfn_to_paddr(*pfnptr, s->page_shift);
+
+if ((addr >= block->target_start) &&
+(addr + s->page_size <= block->target_end)) {
+buf = block->host_addr + (addr - block->target_start);
+} else {
+/* the next page is in the next block */
+block = QTAILQ_NEXT(block, next);
+*blockptr = block;
+if (!block) {
+return false;
+}
+assert(block->target_start % s->page_size == 0);
+assert(block->target_end % s->page_size == 0);
+*pfnptr = paddr_to_pfn(block->target_start, s->page_shift);
+buf = block->host_addr;
+}
+
+if (bufptr) {
+*bufptr = buf;
+}
+
+return true;
+}
+
+static int write_dump_bitmap(DumpState *s)
+{
+int ret = 0;
+uint64_t last_pfn, pfn;
+void *dump_bitmap_buf;
+size_t num_dumpable;
+GuestPhysBlock *block_iter = NULL;
+
+/* dump_bitmap_buf is used to store dump_bitmap temporarily */
+dump_bitmap_buf = g_malloc0(BUFSIZE_BITMAP);
+
+num_dumpable = 0;
+last_pfn = 0;
+
+/*
+ * exam memory page by page, and set the bit in dump_bitmap corresponded
+ * to the existing page.
+ */
+while (get_next_page(&block_iter, &pfn, NULL, s)) {
+ret = set_dump_bitmap(last_pfn, pfn, true, dump_bitmap_buf, s);
+if (
[Qemu-devel] [PULL 19/22] monitor: Add device_del id argument completion.
From: Hani Benhabiles
Signed-off-by: Hani Benhabiles
Signed-off-by: Luiz Capitulino
---
monitor.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/monitor.c b/monitor.c
index 690c152..c90fc1d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4254,6 +4254,25 @@ static const char *next_arg_type(const char *typestr)
return (p != NULL ? ++p : typestr);
}
+static void device_del_completion(ReadLineState *rs, BusState *bus,
+ const char *str, size_t len)
+{
+BusChild *kid;
+
+QTAILQ_FOREACH(kid, &bus->children, sibling) {
+DeviceState *dev = kid->child;
+BusState *dev_child;
+
+if (dev->id && !strncmp(str, dev->id, len)) {
+readline_add_completion(rs, dev->id);
+}
+
+QLIST_FOREACH(dev_child, &dev->child_bus, sibling) {
+device_del_completion(rs, dev_child, str, len);
+}
+}
+}
+
static void monitor_find_completion_by_table(Monitor *mon,
const mon_cmd_t *cmd_table,
char **args,
@@ -4330,6 +4349,10 @@ static void monitor_find_completion_by_table(Monitor
*mon,
} else if (!strcmp(cmd->name, "help|?")) {
monitor_find_completion_by_table(mon, cmd_table,
&args[1], nb_args - 1);
+} else if (!strcmp(cmd->name, "device_del") && nb_args == 2) {
+size_t len = strlen(str);
+readline_set_completion_index(mon->rs, len);
+device_del_completion(mon->rs, sysbus_get_default(), str, len);
}
break;
default:
--
1.8.1.4
[Qemu-devel] [PULL 15/22] dump: add API to write dump pages
From: qiaonuohan
functions are used to write page to vmcore. vmcore is written page by page.
page desc is used to store the information of a page, including a page's size,
offset, compression format, etc.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 231 ++
include/sysemu/dump.h | 7 ++
2 files changed, 238 insertions(+)
diff --git a/dump.c b/dump.c
index a7a85d3..31be686 100644
--- a/dump.c
+++ b/dump.c
@@ -25,6 +25,14 @@
#include "qapi/error.h"
#include "qmp-commands.h"
+#include
+#ifdef CONFIG_LZO
+#include
+#endif
+#ifdef CONFIG_SNAPPY
+#include
+#endif
+
static uint16_t cpu_convert_to_target16(uint16_t val, int endian)
{
if (endian == ELFDATA2LSB) {
@@ -1212,6 +1220,229 @@ static void free_data_cache(DataCache *data_cache)
g_free(data_cache->buf);
}
+static size_t get_len_buf_out(size_t page_size, uint32_t flag_compress)
+{
+size_t len_buf_out_zlib, len_buf_out_lzo, len_buf_out_snappy;
+size_t len_buf_out;
+
+/* init buf_out */
+len_buf_out_zlib = len_buf_out_lzo = len_buf_out_snappy = 0;
+
+/* buf size for zlib */
+len_buf_out_zlib = compressBound(page_size);
+
+/* buf size for lzo */
+#ifdef CONFIG_LZO
+if (flag_compress & DUMP_DH_COMPRESSED_LZO) {
+if (lzo_init() != LZO_E_OK) {
+/* return 0 to indicate lzo is unavailable */
+return 0;
+}
+}
+
+/*
+ * LZO will expand incompressible data by a little amount. please check the
+ * following URL to see the expansion calculation:
+ * http://www.oberhumer.com/opensource/lzo/lzofaq.php
+ */
+len_buf_out_lzo = page_size + page_size / 16 + 64 + 3;
+#endif
+
+#ifdef CONFIG_SNAPPY
+/* buf size for snappy */
+len_buf_out_snappy = snappy_max_compressed_length(page_size);
+#endif
+
+/* get the biggest that can store all kinds of compressed page */
+len_buf_out = MAX(len_buf_out_zlib,
+ MAX(len_buf_out_lzo, len_buf_out_snappy));
+
+return len_buf_out;
+}
+
+/*
+ * check if the page is all 0
+ */
+static inline bool is_zero_page(const uint8_t *buf, size_t page_size)
+{
+return buffer_is_zero(buf, page_size);
+}
+
+static int write_dump_pages(DumpState *s)
+{
+int ret = 0;
+DataCache page_desc, page_data;
+size_t len_buf_out, size_out;
+#ifdef CONFIG_LZO
+lzo_bytep wrkmem = NULL;
+#endif
+uint8_t *buf_out = NULL;
+off_t offset_desc, offset_data;
+PageDescriptor pd, pd_zero;
+uint8_t *buf;
+int endian = s->dump_info.d_endian;
+GuestPhysBlock *block_iter = NULL;
+uint64_t pfn_iter;
+
+/* get offset of page_desc and page_data in dump file */
+offset_desc = s->offset_page;
+offset_data = offset_desc + sizeof(PageDescriptor) * s->num_dumpable;
+
+prepare_data_cache(&page_desc, s, offset_desc);
+prepare_data_cache(&page_data, s, offset_data);
+
+/* prepare buffer to store compressed data */
+len_buf_out = get_len_buf_out(s->page_size, s->flag_compress);
+if (len_buf_out == 0) {
+dump_error(s, "dump: failed to get length of output buffer.\n");
+goto out;
+}
+
+#ifdef CONFIG_LZO
+wrkmem = g_malloc(LZO1X_1_MEM_COMPRESS);
+#endif
+
+buf_out = g_malloc(len_buf_out);
+
+/*
+ * init zero page's page_desc and page_data, because every zero page
+ * uses the same page_data
+ */
+pd_zero.size = cpu_convert_to_target32(s->page_size, endian);
+pd_zero.flags = cpu_convert_to_target32(0, endian);
+pd_zero.offset = cpu_convert_to_target64(offset_data, endian);
+pd_zero.page_flags = cpu_convert_to_target64(0, endian);
+buf = g_malloc0(s->page_size);
+ret = write_cache(&page_data, buf, s->page_size, false);
+g_free(buf);
+if (ret < 0) {
+dump_error(s, "dump: failed to write page data(zero page).\n");
+goto out;
+}
+
+offset_data += s->page_size;
+
+/*
+ * dump memory to vmcore page by page. zero page will all be resided in the
+ * first page of page section
+ */
+while (get_next_page(&block_iter, &pfn_iter, &buf, s)) {
+/* check zero page */
+if (is_zero_page(buf, s->page_size)) {
+ret = write_cache(&page_desc, &pd_zero, sizeof(PageDescriptor),
+ false);
+if (ret < 0) {
+dump_error(s, "dump: failed to write page desc.\n");
+goto out;
+}
+} else {
+/*
+ * not zero page, then:
+ * 1. compress the page
+ * 2. write the compressed page into the cache of page_data
+ * 3. get page desc of the compressed page and write it into the
+ *cache of page_desc
+ *
+ * only one compression format will be used here, for
+ * s->flag_compress is set. But when compression fails to work,
+ *
[Qemu-devel] [PULL 05/22] dump: const-qualify the buf of WriteCoreDumpFunction
From: qiaonuohan
WriteCoreDumpFunction is a function pointer that points to the function used to
write content in "buf" into core file, so "buf" should be const-qualify.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 2 +-
include/qom/cpu.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dump.c b/dump.c
index 80a9116..42622de 100644
--- a/dump.c
+++ b/dump.c
@@ -99,7 +99,7 @@ static void dump_error(DumpState *s, const char *reason)
dump_cleanup(s);
}
-static int fd_write_vmcore(void *buf, size_t size, void *opaque)
+static int fd_write_vmcore(const void *buf, size_t size, void *opaque)
{
DumpState *s = opaque;
size_t written_size;
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 367eda1..d734be8 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -28,7 +28,8 @@
#include "qemu/tls.h"
#include "qemu/typedefs.h"
-typedef int (*WriteCoreDumpFunction)(void *buf, size_t size, void *opaque);
+typedef int (*WriteCoreDumpFunction)(const void *buf, size_t size,
+ void *opaque);
/**
* vaddr:
--
1.8.1.4
[Qemu-devel] [PULL 04/22] qmp: expose list of supported character device backends
From: Martin Kletzander
Introduce 'query-chardev-backends' QMP command which lists all
supported character device backends.
Signed-off-by: Martin Kletzander
Reviewed-by: Eric Blake
Signed-off-by: Luiz Capitulino
---
qapi-schema.json | 22 ++
qemu-char.c | 19 +++
qmp-commands.hx | 41 +
3 files changed, 82 insertions(+)
diff --git a/qapi-schema.json b/qapi-schema.json
index 7cfb5e5..9bca13a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -437,6 +437,28 @@
{ 'command': 'query-chardev', 'returns': ['ChardevInfo'] }
##
+# @ChardevBackendInfo:
+#
+# Information about a character device backend
+#
+# @name: The backend name
+#
+# Since: 2.0
+##
+{ 'type': 'ChardevBackendInfo', 'data': {'name': 'str'} }
+
+##
+# @query-chardev-backends:
+#
+# Returns information about character device backends.
+#
+# Returns: a list of @ChardevBackendInfo
+#
+# Since: 2.0
+##
+{ 'command': 'query-chardev-backends', 'returns': ['ChardevBackendInfo'] }
+
+##
# @DataFormat:
#
# An enumeration of data format.
diff --git a/qemu-char.c b/qemu-char.c
index d0b4ac5..4d50838 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3432,6 +3432,25 @@ ChardevInfoList *qmp_query_chardev(Error **errp)
return chr_list;
}
+ChardevBackendInfoList *qmp_query_chardev_backends(Error **errp)
+{
+ChardevBackendInfoList *backend_list = NULL;
+CharDriver *c = NULL;
+GSList *i = NULL;
+
+for (i = backends; i; i = i->next) {
+ChardevBackendInfoList *info = g_malloc0(sizeof(*info));
+c = i->data;
+info->value = g_malloc0(sizeof(*info->value));
+info->value->name = g_strdup(c->name);
+
+info->next = backend_list;
+backend_list = info;
+}
+
+return backend_list;
+}
+
CharDriverState *qemu_chr_find(const char *name)
{
CharDriverState *chr;
diff --git a/qmp-commands.hx b/qmp-commands.hx
index cce6b81..8a0e832 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -1924,6 +1924,47 @@ EQMP
},
SQMP
+query-chardev-backends
+-
+
+List available character device backends.
+
+Each backend is represented by a json-object, the returned value is a
json-array
+of all backends.
+
+Each json-object contains:
+
+- "name": backend name (json-string)
+
+Example:
+
+-> { "execute": "query-chardev-backends" }
+<- {
+ "return":[
+ {
+"name":"udp"
+ },
+ {
+"name":"tcp"
+ },
+ {
+"name":"unix"
+ },
+ {
+"name":"spiceport"
+ }
+ ]
+ }
+
+EQMP
+
+{
+.name = "query-chardev-backends",
+.args_type = "",
+.mhandler.cmd_new = qmp_marshal_input_query_chardev_backends,
+},
+
+SQMP
query-block
---
--
1.8.1.4
[Qemu-devel] [PULL 08/22] dump: add API to write vmcore
From: qiaonuohan
Function is used to write vmcore in flatten format. In flatten format, data is
written block by block, and in front of each block, a struct
MakedumpfileDataHeader is stored there to indicate the offset and size of the
data block.
struct MakedumpfileDataHeader {
int64_t offset;
int64_t buf_size;
};
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/dump.c b/dump.c
index f233b3e..238ffa5 100644
--- a/dump.c
+++ b/dump.c
@@ -728,6 +728,27 @@ static int write_end_flat_header(int fd)
return 0;
}
+static int write_buffer(int fd, off_t offset, const void *buf, size_t size)
+{
+size_t written_size;
+MakedumpfileDataHeader mdh;
+
+mdh.offset = cpu_to_be64(offset);
+mdh.buf_size = cpu_to_be64(size);
+
+written_size = qemu_write_full(fd, &mdh, sizeof(mdh));
+if (written_size != sizeof(mdh)) {
+return -1;
+}
+
+written_size = qemu_write_full(fd, buf, size);
+if (written_size != size) {
+return -1;
+}
+
+return 0;
+}
+
static ram_addr_t get_start_block(DumpState *s)
{
GuestPhysBlock *block;
--
1.8.1.4
[Qemu-devel] [PULL 02/22] QMP: allow JSON dict arguments in qmp-shell
From: Stefan Hajnoczi
qmp-shell hides the QMP wire protocol JSON encoding from the user. Most
of the time this is helpful and makes the command-line human-friendly.
Some QMP commands take a dict as an argument. In order to express this
we need to revert back to JSON notation.
This patch allows JSON dict arguments in qmp-shell so commands like
blockdev-add and nbd-server-start can be invoked:
(QEMU) blockdev-add options={"driver":"file","id":"drive1",...}
Note that spaces are not allowed since str.split() is used to break up
the command-line arguments first.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
Reviewed-by: Benoit Canet
Signed-off-by: Luiz Capitulino
---
scripts/qmp/qmp-shell | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
index d6b420f..d374b35 100755
--- a/scripts/qmp/qmp-shell
+++ b/scripts/qmp/qmp-shell
@@ -31,6 +31,7 @@
# (QEMU)
import qmp
+import json
import readline
import sys
import pprint
@@ -107,6 +108,8 @@ class QMPShell(qmp.QEMUMonitorProtocol):
value = True
elif opt[1] == 'false':
value = False
+elif opt[1].startswith('{'):
+value = json.loads(opt[1])
else:
value = opt[1]
qmpcmd['arguments'][opt[0]] = value
--
1.8.1.4
[Qemu-devel] [PULL 09/22] dump: add API to write elf notes to buffer
From: qiaonuohan
the function can be used by write_elf32_notes/write_elf64_notes to write notes
to a buffer. If fd_write_vmcore is used, write_elf32_notes/write_elf64_notes
will write elf notes to vmcore directly. Instead, if buf_write_note is used,
elf notes will be written to opaque->note_buf at first.
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/dump.c b/dump.c
index 238ffa5..2b940bd 100644
--- a/dump.c
+++ b/dump.c
@@ -76,6 +76,9 @@ typedef struct DumpState {
int64_t begin;
int64_t length;
Error **errp;
+
+uint8_t *note_buf; /* buffer for notes */
+size_t note_buf_offset; /* the writing place in note_buf */
} DumpState;
static int dump_cleanup(DumpState *s)
@@ -749,6 +752,22 @@ static int write_buffer(int fd, off_t offset, const void
*buf, size_t size)
return 0;
}
+static int buf_write_note(const void *buf, size_t size, void *opaque)
+{
+DumpState *s = opaque;
+
+/* note_buf is not enough */
+if (s->note_buf_offset + size > s->note_size) {
+return -1;
+}
+
+memcpy(s->note_buf + s->note_buf_offset, buf, size);
+
+s->note_buf_offset += size;
+
+return 0;
+}
+
static ram_addr_t get_start_block(DumpState *s)
{
GuestPhysBlock *block;
--
1.8.1.4
[Qemu-devel] [PULL 00/22] QMP queue
The following changes since commit 9d74f6fef0801ca2ce5c9d38d59b85bf03c27669: Merge remote-tracking branch 'remotes/alon/pull-libcacard.glusterfs' into staging (2014-02-12 17:53:31 +) are available in the git repository at: git://repo.or.cz/qemu/qmp-unstable.git queue/qmp for you to fetch changes up to ebdc5cbd04a47af74f8b853f8ec95ab6291c7b53: monitor: Add object_add class argument completion. (2014-02-13 08:49:35 -0500) Ekaterina Tumanova (1): dump: Define the architecture for compressed dump format. Hani Benhabiles (4): monitor: Add device_del id argument completion. monitor: Add device_add device argument completion. monitor: Add object_del id argument completion. monitor: Add object_add class argument completion. Markus Armbruster (1): Use error_is_set() only when necessary Martin Kletzander (1): qmp: expose list of supported character device backends Soramichi AKIYAMA (1): hmp: migrate command (without -d) now blocks correctly Stefan Hajnoczi (1): QMP: allow JSON dict arguments in qmp-shell qiaonuohan (13): dump: const-qualify the buf of WriteCoreDumpFunction dump: add argument to write_elfxx_notes dump: add API to write header of flatten format dump: add API to write vmcore dump: add API to write elf notes to buffer dump: add support for lzo/snappy dump: add members to DumpState and init some of them dump: add API to write dump header dump: add API to write dump_bitmap dump: add APIs to operate DataCache dump: add API to write dump pages dump: make kdump-compressed format available for 'dump-guest-memory' dump: add 'query-dump-guest-memory-capability' command block.c| 16 +- block/blkdebug.c | 4 +- block/blkverify.c | 2 +- block/curl.c | 2 +- block/gluster.c| 2 +- block/iscsi.c | 2 +- block/nbd.c| 2 +- block/qapi.c | 4 +- block/qcow2.c | 6 +- block/raw-posix.c | 12 +- block/raw-win32.c | 4 +- block/raw_bsd.c| 2 +- block/rbd.c| 2 +- block/sheepdog.c | 2 +- block/snapshot.c | 2 +- block/vvfat.c | 2 +- blockdev.c | 42 +- blockjob.c | 4 +- configure | 54 +++ dump.c | 960 - hmp.c | 16 +- hw/pci/pci-hotplug-old.c | 4 +- hw/usb/dev-network.c | 2 +- include/qom/cpu.h | 3 +- include/sysemu/dump.h | 138 ++ monitor.c | 95 net/net.c | 12 +- qapi-schema.json | 71 ++- qdev-monitor.c | 2 +- qemu-char.c| 25 +- qemu-img.c | 8 +- qga/commands-posix.c | 18 +- qga/commands-win32.c | 2 +- qmp-commands.hx| 68 ++- savevm.c | 4 +- scripts/qmp/qmp-shell | 3 + target-i386/cpu.h | 2 + target-s390x/cpu.h | 1 + tests/test-qmp-input-strict.c | 16 +- tests/test-qmp-input-visitor.c | 20 +- tests/test-qmp-output-visitor.c| 22 +- tests/test-string-input-visitor.c | 20 +- tests/test-string-output-visitor.c | 14 +- tpm.c | 2 +- util/qemu-config.c | 16 +- util/qemu-option.c | 22 +- vl.c | 2 +- 47 files changed, 1557 insertions(+), 177 deletions(-)
[Qemu-devel] [PULL 07/22] dump: add API to write header of flatten format
From: qiaonuohan
flatten format will be used when writing kdump-compressed format. The format is
also used by makedumpfile, you can refer to the following URL to get more
detailed information about flatten format of kdump-compressed format:
http://sourceforge.net/projects/makedumpfile/
The two functions here are used to write start flat header and end flat header
to vmcore, and they will be called later when flatten format is used.
struct MakedumpfileHeader stored at the head of vmcore is used to indicate the
vmcore is in flatten format.
struct MakedumpfileHeader {
char signature[16]; /* = "makedumpfile" */
int64_t type; /* = 1 */
int64_t version;/* = 1 */
};
And struct MakedumpfileDataHeader, with offset and buf_size set to -1, is used
to indicate the end of vmcore in flatten format.
struct MakedumpfileDataHeader {
int64_t offset; /* = -1 */
int64_t buf_size; /* = -1 */
};
Signed-off-by: Qiao Nuohan
Reviewed-by: Laszlo Ersek
Signed-off-by: Luiz Capitulino
---
dump.c| 42 ++
include/sysemu/dump.h | 17 +
2 files changed, 59 insertions(+)
diff --git a/dump.c b/dump.c
index c9d3492..f233b3e 100644
--- a/dump.c
+++ b/dump.c
@@ -686,6 +686,48 @@ static int create_vmcore(DumpState *s)
return 0;
}
+static int write_start_flat_header(int fd)
+{
+uint8_t *buf;
+MakedumpfileHeader mh;
+int ret = 0;
+
+memset(&mh, 0, sizeof(mh));
+strncpy(mh.signature, MAKEDUMPFILE_SIGNATURE,
+strlen(MAKEDUMPFILE_SIGNATURE));
+
+mh.type = cpu_to_be64(TYPE_FLAT_HEADER);
+mh.version = cpu_to_be64(VERSION_FLAT_HEADER);
+
+buf = g_malloc0(MAX_SIZE_MDF_HEADER);
+memcpy(buf, &mh, sizeof(mh));
+
+size_t written_size;
+written_size = qemu_write_full(fd, buf, MAX_SIZE_MDF_HEADER);
+if (written_size != MAX_SIZE_MDF_HEADER) {
+ret = -1;
+}
+
+g_free(buf);
+return ret;
+}
+
+static int write_end_flat_header(int fd)
+{
+MakedumpfileDataHeader mdh;
+
+mdh.offset = END_FLAG_FLAT_HEADER;
+mdh.buf_size = END_FLAG_FLAT_HEADER;
+
+size_t written_size;
+written_size = qemu_write_full(fd, &mdh, sizeof(mdh));
+if (written_size != sizeof(mdh)) {
+return -1;
+}
+
+return 0;
+}
+
static ram_addr_t get_start_block(DumpState *s)
{
GuestPhysBlock *block;
diff --git a/include/sysemu/dump.h b/include/sysemu/dump.h
index 19fafb2..b32b390 100644
--- a/include/sysemu/dump.h
+++ b/include/sysemu/dump.h
@@ -14,12 +14,29 @@
#ifndef DUMP_H
#define DUMP_H
+#define MAKEDUMPFILE_SIGNATURE "makedumpfile"
+#define MAX_SIZE_MDF_HEADER (4096) /* max size of makedumpfile_header
*/
+#define TYPE_FLAT_HEADER(1)/* type of flattened format */
+#define VERSION_FLAT_HEADER (1)/* version of flattened format */
+#define END_FLAG_FLAT_HEADER(-1)
+
typedef struct ArchDumpInfo {
int d_machine; /* Architecture */
int d_endian; /* ELFDATA2LSB or ELFDATA2MSB */
int d_class;/* ELFCLASS32 or ELFCLASS64 */
} ArchDumpInfo;
+typedef struct QEMU_PACKED MakedumpfileHeader {
+char signature[16]; /* = "makedumpfile" */
+int64_t type;
+int64_t version;
+} MakedumpfileHeader;
+
+typedef struct QEMU_PACKED MakedumpfileDataHeader {
+int64_t offset;
+int64_t buf_size;
+} MakedumpfileDataHeader;
+
struct GuestPhysBlockList; /* memory_mapping.h */
int cpu_get_dump_info(ArchDumpInfo *info,
const struct GuestPhysBlockList *guest_phys_blocks);
--
1.8.1.4
[Qemu-devel] [PULL 01/22] hmp: migrate command (without -d) now blocks correctly
From: Soramichi AKIYAMA
This patch fixes a timing issue that migrate command (without -d) does not
block in some cases.
The original version of hmp.c:hmp_migrate_status_cb checks if the
migration status is 'active' or not to detect the completion of a migration.
However, if this function is executed when the migration status is stil
'setup' (the status before 'active'), migration command returns
immediately even if the user does not specify -d option.
Signed-off-by: Soramichi Akiyama
Signed-off-by: Luiz Capitulino
---
hmp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hmp.c b/hmp.c
index 1af0809..081c121 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1234,7 +1234,8 @@ static void hmp_migrate_status_cb(void *opaque)
MigrationInfo *info;
info = qmp_query_migrate(NULL);
-if (!info->has_status || strcmp(info->status, "active") == 0) {
+if (!info->has_status || strcmp(info->status, "active") == 0 ||
+strcmp(info->status, "setup") == 0) {
if (info->has_disk) {
int progress;
--
1.8.1.4
Re: [Qemu-devel] [PATCH V6 00/10] qapi script: support enum as discriminator and better enum name
Wenchao Xia writes:
> This series address two issues:
>
> 1. support using enum as discriminator in union.
> For example, if we have following define in qapi schema:
> { 'enum': 'EnumOne',
> 'data': [ 'value1', 'value2', 'value3' ] }
>
> { 'type': 'UserDefBase0',
> 'data': { 'base-string0': 'str', 'base-enum0': 'EnumOne' } }
>
> Before this series, discriminator in union must be a string, and a
> hidden enum type as discriminator is generated. After this series,
> qapi schema can directly use predefined enum type:
> { 'union': 'UserDefEnumDiscriminatorUnion',
> 'base': 'UserDefBase0',
> 'discriminator' : 'base-enum0',
> 'data': { 'value1' : 'UserDefA',
> 'value2' : 'UserDefInherit',
> 'value3' : 'UserDefB' } }
>
> The benefit is that every thing is defined explicitly in schema file,
> the discriminator enum type can be used in other API define in schema,
> and a compile time check will be put to verify the correctness according
> to enum define. Currently BlockdevOptions used discriminator which can
> be converted, in the future other union can also use enum discriminator.
>
> The implement is done by:
> 1.1 remember the enum defines by qapi scripts.(patch 1)
> 1.2 use the remembered enum define to check correctness at compile
> time.(patch 3), more strict check(patch 2)
> 1.3 use the same enum name generation rule to avoid C code mismatch,
> esp for "case [ENUM_VALUE]" in qapi-visit.c.(patch 4,5)
> 1.4 switch the code path, when pre-defined enum type is used as discriminator,
> don't generate a hidden enum type, use the enum type instead, add
> docs/qapi-code-gen.txt.(Patch 6)
> 1.5 test case shows how it looks like.(Patch 7)
> 1.6 convert BlockdevOptions. (Patch 8)
>
> 2. Better enum name generation
> Before this patch, AIOContext->A_I_O_CONTEXT, after this patch,
> AIOContet->AIO_CONTEXT. Since previous patch has foldered enum
> name generation codes into one function, it is done easily by modifying
> it.(Patch 9)
Sorry for the lateness of my review. I like this series, but I had a
few questions related to error reporting. Also, the new errors lack
tests.
My offer to rebase it on top of my "[PATCH v2 00/13] qapi: Test coverage
& clean up generated code" stands.
Re: [Qemu-devel] [PATCH V6 00/10] qapi script: support enum as discriminator and better enum name
On Tue, 11 Feb 2014 14:13:19 -0500
Luiz Capitulino wrote:
> On Tue, 11 Feb 2014 05:48:31 +0800
> Wenchao Xia wrote:
>
> > This series address two issues:
> >
> > 1. support using enum as discriminator in union.
> > For example, if we have following define in qapi schema:
> > { 'enum': 'EnumOne',
> > 'data': [ 'value1', 'value2', 'value3' ] }
> >
> > { 'type': 'UserDefBase0',
> > 'data': { 'base-string0': 'str', 'base-enum0': 'EnumOne' } }
> >
> > Before this series, discriminator in union must be a string, and a
> > hidden enum type as discriminator is generated. After this series,
> > qapi schema can directly use predefined enum type:
> > { 'union': 'UserDefEnumDiscriminatorUnion',
> > 'base': 'UserDefBase0',
> > 'discriminator' : 'base-enum0',
> > 'data': { 'value1' : 'UserDefA',
> > 'value2' : 'UserDefInherit',
> > 'value3' : 'UserDefB' } }
> >
> > The benefit is that every thing is defined explicitly in schema file,
> > the discriminator enum type can be used in other API define in schema,
> > and a compile time check will be put to verify the correctness according
> > to enum define. Currently BlockdevOptions used discriminator which can
> > be converted, in the future other union can also use enum discriminator.
> >
> > The implement is done by:
> > 1.1 remember the enum defines by qapi scripts.(patch 1)
> > 1.2 use the remembered enum define to check correctness at compile
> > time.(patch 3), more strict check(patch 2)
> > 1.3 use the same enum name generation rule to avoid C code mismatch,
> > esp for "case [ENUM_VALUE]" in qapi-visit.c.(patch 4,5)
> > 1.4 switch the code path, when pre-defined enum type is used as
> > discriminator,
> > don't generate a hidden enum type, use the enum type instead, add
> > docs/qapi-code-gen.txt.(Patch 6)
> > 1.5 test case shows how it looks like.(Patch 7)
> > 1.6 convert BlockdevOptions. (Patch 8)
> >
> > 2. Better enum name generation
> > Before this patch, AIOContext->A_I_O_CONTEXT, after this patch,
> > AIOContet->AIO_CONTEXT. Since previous patch has foldered enum
> > name generation codes into one function, it is done easily by modifying
> > it.(Patch 9)
>
> Applied to the qmp branch, thanks.
Just to make it clear, I'm not including this series in today's pull
request so that you and Markus can coordinate your work.
>
> >
> >
> > Changes from RFC:
> > Mainly address Eric's comments: fix typo, add patch 2 to allow partly
> > mapping
> > enum value in union, add related test case, remove direct inherit support
> > "_base"
> > and related test case. RFC series at:
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg00363.html
> >
> > v2:
> > General:
> > 3/8: use Raise exception instead of sys.error.write in qapi.py.
> > Address Eric's comments:
> > 2/8,3/8: more check for enum value at compile time, not allow partly
> > mapping.
> > 8/8: correspond test case change.
> >
> > v3:
> > General:
> > move enum name generation patch to last in the series, add convert patch
> > 8/9.
> > Address Luiz and Kevin's comments:
> > Better introduction.
> > 6/9: renamed this patch, add docs/qapi-code-gen.txt part.
> >
> > v4:
> > Address Eric's comments:
> > 5/9: better commit message.
> > 6/9: typo fix in doc.
> > 9/9: typo fix, fix indentation, better incode comment.
> >
> > v5:
> > Address Eric's comments:
> > 6/10: doc typo fix.
> > 8/10: new patch to remove string discriminator.
> > 9/10: removed the string discriminator test case.
> >
> > v6:
> > rebased on upstream by adding "blgdebug" and "blkverify" in
> > qapi-schema.json
> > in patch 7/10.
> >
> > Wenchao Xia (10):
> > 1 qapi script: remember enum values
> > 2 qapi script: add check for duplicated key
> > 3 qapi script: check correctness of discriminator values in union
> > 4 qapi script: code move for generate_enum_name()
> > 5 qapi script: use same function to generate enum string
> > 6 qapi script: support pre-defined enum type as discriminator in union
> > 7 qapi: convert BlockdevOptions to use enum discriminator
> > 8 qapi script: do not allow string discriminator
> > 9 tests: add cases for inherited struct and union with discriminator
> > 10 qapi script: do not add "_" for every capitalized char in enum
> >
> > docs/qapi-code-gen.txt |8 ++-
> > include/qapi/qmp/qerror.h |2 +-
> > qapi-schema.json| 14 -
> > scripts/qapi-types.py | 34 +-
> > scripts/qapi-visit.py | 61 ++---
> > scripts/qapi.py | 84 +--
> > target-i386/cpu.c |2 +-
> > tests/qapi-schema/comments.out |2 +-
> > tests/qapi-schema/qapi-schema-test.json | 22 ++
> > tests/qapi-schema/qapi-schema-test.out | 13 +++-
> > tests/test-qmp-input-visitor.c | 93 +
> >
Re: [Qemu-devel] [PATCH V6 08/10] qapi script: do not allow string discriminator
Wenchao Xia writes:
> Signed-off-by: Wenchao Xia
> ---
> docs/qapi-code-gen.txt |8 +++-
> scripts/qapi-visit.py |6 ++
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
> index a2e7921..c92add9 100644
> --- a/docs/qapi-code-gen.txt
> +++ b/docs/qapi-code-gen.txt
> @@ -123,11 +123,9 @@ And it looks like this on the wire:
>
> Flat union types avoid the nesting on the wire. They are used whenever a
> specific field of the base type is declared as the discriminator ('type' is
> -then no longer generated). The discriminator can be a string field or a
> -predefined enum field. If it is a string field, a hidden enum type will be
> -generated as "[UNION_NAME]Kind". If it is an enum field, a compile time check
> -will be done to verify the correctness. It is recommended to use an enum
> field.
> -The above example can then be modified as follows:
> +then no longer generated). The discriminator should be a predefined enum
> field,
> +and a compile time check will be done to verify the correctness. The above
> +example can then be modified as follows:
>
> { 'enum': 'BlockdevDriver', 'data': [ 'raw', 'qcow2' ] }
> { 'type': 'BlockdevCommonOptions',
> diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
> index 3240921..efa7ec3 100644
> --- a/scripts/qapi-visit.py
> +++ b/scripts/qapi-visit.py
> @@ -280,6 +280,12 @@ def generate_visit_union(expr):
> # Use the predefined enum type as discriminator
> ret = ""
> discriminator_type_name = enum_define['enum_name']
> +elif discriminator:
> +# Do not allow string discriminator
> +sys.stderr.write("Discriminator '%s' is not a pre-defined enum "
> + "type\n" %
> + discriminator)
> +sys.exit(1)
> else:
> # There will always be a discriminator in the C switch code, by
> default it
> # is an enum type generated silently as "'%sKind' % (name)"
Why isn't it diagnosed in qapi.py, like all the other semantic errors?
All errors should have a test in tests/qapi-schema/. I can try to add
tests for you when I rebase your 09/10.
Re: [Qemu-devel] [PATCH V6 09/10] tests: add cases for inherited struct and union with discriminator
On Thu, 13 Feb 2014 15:53:30 +0100 Markus Armbruster wrote: > Wenchao Xia writes: > > > Test for inherit and complex union. > > This patch conflicts badly with my test coverage work in "[PATCH v2 > 00/13] qapi: Test coverage & clean up generated code". My series > systematically covers code generation in scripts/qapi*py, and that takes > me seven patches. > > If I put your patch first, mine all explode, and I get to start over. > > Putting my series first looks far easier to resolve, because only this > one patch conflicts. Would you mind me rebasing your series on top of > mine? If it's only this patch that causes conflicts, what about the following: 1. I apply patches 1-8 plus patch 10 2. Markus rebases patch 9 and adds it to his series 3. Markus post a new version Does this work for everyone? The only drawback is that both series will miss today's boat, but this would happen at this point anyway.
Re: [Qemu-devel] [PULL 1/3] s390-ccw.img: Fix sporadic reboot hangs: Initialize next_idx
On 02/13/2014 01:17 AM, Christian Borntraeger wrote:
> The current code does not initialize next_idx as the qemu
> elf loader does not zero the bss section.
> Make the initialization explicit.
>
> Signed-off-by: Christian Borntraeger
> ---
> pc-bios/s390-ccw/virtio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
> index 4d6e48f..a46914d 100644
> --- a/pc-bios/s390-ccw/virtio.c
> +++ b/pc-bios/s390-ccw/virtio.c
> @@ -124,6 +124,7 @@ static void vring_init(struct vring *vr, unsigned int
> num, void *p,
> vr->used->flags = VRING_USED_F_NO_NOTIFY;
> vr->used->idx = 0;
> vr->used_idx = 0;
> +vr->next_idx = 0;
>
> debug_print_addr("init vr", vr);
> }
>
FWIW, I believe that rom_reset needs to do this re-zeroing of the bss.
That seems to be the only place we don't take care for datasize != romsize.
r~
Re: [Qemu-devel] [PATCH v2 2/2] vl: convert -m to QemuOpts
On 02/13/2014 06:50 AM, Igor Mammedov wrote:
> Adds option to -m
> "mem" - startup memory amount
>
> For compatibility with legacy CLI if suffix-less number is passed,
> it assumes amount in Mb.
>
> Otherwise user is free to use suffixed number using suffixes b,k/K,M,G
>
> Signed-off-by: Igor Mammedov
> Signed-off-by: Paolo Bonzini
> ---
> v2:
> - various fixes suggested by Laszlo Ersek
>- check for overflow
>- check for empty mem="" case
>- reshuffle code to avoid conflicts with another series on list
>- some style/typo fixes
> ---
> qemu-options.hx | 12 ++---
> vl.c| 68
> ++-
> 2 files changed, 65 insertions(+), 15 deletions(-)
>
> +"configure guest RAM size\n"
> +"mem: initial amount of guest memory (default: "
> +stringify(DEFAULT_RAM_SIZE) "MB)\n",
MB here...
> +QEMU_ARCH_ALL)
> STEXI
> @item -m @var{megs}
> @findex -m
> -Set virtual RAM size to @var{megs} megabytes. Default is 128 MiB.
> Optionally,
> +Set virtual RAM size to @var{size} megabytes. Default is 128 MiB.
> Optionally,
> a suffix of ``M'' or ``G'' can be used to signify a value in megabytes or
> -gigabytes respectively.
> +gigabytes respectively. If @var{size} is provided without unit suffix then MB
> +is assumed.
...and inconsistent on MiB vs MB here. If we're going to use MiB (which
is the correct term), it would be worth using it everywhere.
> +opts = qemu_opts_parse(qemu_find_opts(MEMORY_OPTS),
> + optarg, 1);
> +if (!opts) {
> +exit(1);
I prefer EXIT_FAILURE, but that's a change for another patch (you're
just following conventions).
> +if (!strlen(mem_str)) {
More efficient as 'if (!*mem_str)'...
> +fprintf(stderr, "qemu: missing 'mem' option value\n");
> exit(1);
> }
> -sz = QEMU_ALIGN_UP((uint64_t)value, 8192);
> +
> +sz = qemu_opt_get_size(opts, "mem", ram_size);
> +
> +/* Fix up legacy suffix-less format */
> +if (g_ascii_isdigit(mem_str[strlen(mem_str) - 1])) {
...either that, or cache your strlen() result so you only call it once.
> +uint64_t overflow_check = sz;
> +
> +sz <<= 20;
> +if ((sz >> 20) != overflow_check) {
> +fprintf(stderr, "qemu: too large 'mem' option "
> +"value\n");
> +}
> +}
What? We print the warning, but then use the bogus value? Missing exit().
--
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 02/10] qapi script: add check for duplicated key
Wenchao Xia writes: > It is bad that same key was specified twice, especially when a union have > two branches with same condition. This patch can prevent it. > > Signed-off-by: Wenchao Xia > Reviewed-by: Eric Blake > --- > scripts/qapi.py |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/scripts/qapi.py b/scripts/qapi.py > index aec6bbb..cf34768 100644 > --- a/scripts/qapi.py > +++ b/scripts/qapi.py > @@ -116,6 +116,8 @@ class QAPISchema: > if self.tok != ':': > raise QAPISchemaError(self, 'Expected ":"') > self.accept() > +if key in expr: > +raise QAPISchemaError(self, 'Duplicated key "%s"' % key) > expr[key] = self.get_expr(True) > if self.tok == '}': > self.accept() All errors should have a test in tests/qapi-schema/. I can try to add tests for you when I rebase your 09/10.
Re: [Qemu-devel] [PATCH V6 03/10] qapi script: check correctness of discriminator values in union
Wenchao Xia writes:
> It will check whether the values specified are written correctly,
> and whether all enum values are covered, when discriminator is a
> pre-defined enum type
>
> Signed-off-by: Wenchao Xia
> Reviewed-by: Eric Blake
> ---
> scripts/qapi-visit.py | 17 +
> scripts/qapi.py | 31 +++
> 2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
> index 65f1a54..c0efb5f 100644
> --- a/scripts/qapi-visit.py
> +++ b/scripts/qapi-visit.py
> @@ -255,6 +255,23 @@ def generate_visit_union(expr):
> assert not base
> return generate_visit_anon_union(name, members)
>
> +# If discriminator is specified and it is a pre-defined enum in schema,
> +# check its correctness
> +enum_define = discriminator_find_enum_define(expr)
> +if enum_define:
> +for key in members:
> +if not key in enum_define["enum_values"]:
> +sys.stderr.write("Discriminator value '%s' is not found in "
> + "enum '%s'\n" %
> + (key, enum_define["enum_name"]))
> +sys.exit(1)
Can this happen? If yes, why isn't it diagnosed in qapi.py, like all
the other semantic errors?
> +for key in enum_define["enum_values"]:
> +if not key in members:
> +sys.stderr.write("Enum value '%s' is not covered by a branch
> "
> + "of union '%s'\n" %
> + (key, name))
> +sys.exit(1)
> +
Likewise.
> ret = generate_visit_enum('%sKind' % name, members.keys())
>
> if base:
> diff --git a/scripts/qapi.py b/scripts/qapi.py
> index cf34768..0a3ab80 100644
> --- a/scripts/qapi.py
> +++ b/scripts/qapi.py
> @@ -385,3 +385,34 @@ def guardend(name):
>
> ''',
> name=guardname(name))
> +
> +# This function can be used to check whether "base" is valid
> +def find_base_fields(base):
> +base_struct_define = find_struct(base)
> +if not base_struct_define:
> +return None
> +return base_struct_define.get('data')
> +
> +# Return the discriminator enum define, if discriminator is specified in
> +# @expr and it is a pre-defined enum type
> +def discriminator_find_enum_define(expr):
> +discriminator = expr.get('discriminator')
> +base = expr.get('base')
> +
> +# Only support discriminator when base present
> +if not (discriminator and base):
> +return None
> +
> +base_fields = find_base_fields(base)
> +
> +if not base_fields:
> +raise StandardError("Base '%s' is not a valid type\n"
> +% base)
Why not QAPISchemaError, like for other semantic errors?
> +
> +discriminator_type = base_fields.get(discriminator)
> +
> +if not discriminator_type:
> +raise StandardError("Discriminator '%s' not found in schema\n"
> +% discriminator)
Likewise.
> +
> +return find_enum(discriminator_type)
All errors should have a test in tests/qapi-schema/. I can try to add
tests for you when I rebase your 09/10.
Re: [Qemu-devel] [PATCH v2] block: mirror - use local_err to avoid NULL errp
On 02/13/2014 07:23 AM, Jeff Cody wrote:
> When starting a block job, commit_active_start() relies on whether *errp
> is set by mirror_start_job. This allows it to determine if the mirror
> job start failed, so that it can clean up any changes to open flags from
> the bdrv_reopen(). If errp is NULL, then it will not be able to
> determine if mirror_start_job failed or not.
>
> To avoid this, use a local Error variable, and then propagate the error
> (if any) to errp.
>
> Reported-by: Markus Armbruster
> Signed-off-by: Jeff Cody
> ---
> block/mirror.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/block/mirror.c b/block/mirror.c
> index 2a43334..ddb5765 100644
> --- a/block/mirror.c
> +++ b/block/mirror.c
> @@ -633,6 +633,8 @@ void commit_active_start(BlockDriverState *bs,
> BlockDriverState *base,
> {
> int64_t length, base_length;
> int orig_base_flags;
> +Error *local_err = NULL;
> +
>
> orig_base_flags = bdrv_get_flags(base);
Why the double blank line?
Besides that,
Reviewed-by: Eric Blake
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PULL 0/3] PReP patch queue 2014-02-10
On 10 February 2014 16:22, Andreas Färber wrote: > Hello Peter, > > Please pull the PowerPC Reference Platform (PReP) queue into qemu.git master. Applied, thanks. -- PMM
Re: [Qemu-devel] [PATCH] tcg-arm: The shift count of op_rotl_i32 is in args[2] not args[1].
On 02/13/2014 02:26 AM, Huw Davies wrote: > It's this that should be subtracted from 0x20 when converting to a right > rotate. > > Signed-off-by: Huw Davies > --- > tcg/arm/tcg-target.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PULL 0/4] user-mode FR switch support for MIPS32r5
On 10 February 2014 16:19, Petar Jovanovic wrote: > The following changes since commit 1f6b12f75f2c22f861d0202374033a7594c91707: > > Merge remote-tracking branch 'remotes/mwalle/tags/lm32-fixes/20140204' into > staging (2014-02-08 15:57:51 +) > > are available in the git repository at: > > > g...@github.com:petar-jovanovic/qemu.git mips-ufrp I can fix things up manually, so you don't need to resend, but this isn't a valid git remote URL (at least, it doesn't work for me). You probably wanted to say: git://github.com/petar-jovanovic/qemu.git mips-ufrp thanks -- PMM
Re: [Qemu-devel] [PATCH] target-ppc: fix 32 bit build break in the page table lookup code
On 13.02.2014, at 04:00, Aneesh Kumar K.V
wrote:
> Greg Kurz writes:
>
>> The 396bb9874 commit reworked page table lookup to support kvm.
>> Unfortunately this breaks 32 bit build:
>>
>> target-ppc/mmu-hash64.h: In function ‘ppc_hash64_load_hpte0’:
>> target-ppc/mmu-hash64.h:90:23: error: cast to pointer from integer of
>> different size
>>
>> target-ppc/mmu-hash64.h: In function ‘ppc_hash64_load_hpte1’:
>> target-ppc/mmu-hash64.h:101:23: error: cast to pointer from integer of
>> different size
>>
>> The problem is that we have two cases to handle here:
>> - the HTAB is external and it is accessed with a pointer
>> - the HTAB is emulated and it is accessed with a hwaddr
>>
>> Depending on the way the HTAB is controlled, we should use the appropriate
>> type:
>> - controlled by kvm, it is copied to an allocated buffer (pointer)
>> - controlled by qemu with an allocated buffer (pointer)
>> - controlled by qemu with soft mmu (hwaddr)
>>
>> This patch introduces an explicit distinction between the two cases in
>> the new page table lookup code.
>
> Reviewed-by: Aneesh Kumar K.V
I wouldn't mind something slightly lighter weight. How about this one instead?
If you guys think it's better to have an actual type for the token I'd pull in
this patch as is though.
Alex
diff --git a/target-ppc/mmu-hash64.c b/target-ppc/mmu-hash64.c
index 4e574d9..3240427 100644
--- a/target-ppc/mmu-hash64.c
+++ b/target-ppc/mmu-hash64.c
@@ -340,7 +340,7 @@ uint64_t ppc_hash64_start_access(PowerPCCPU *cpu,
target_ulong pte_index)
* accessible PTEG.
*/
if (cpu->env.external_htab) {
-token = (uint64_t) cpu->env.external_htab + pte_offset;
+token = (uint64_t)(uintptr_t) cpu->env.external_htab + pte_offset;
} else if (cpu->env.htab_base) {
token = cpu->env.htab_base + pte_offset;
}
diff --git a/target-ppc/mmu-hash64.h b/target-ppc/mmu-hash64.h
index 9c9ca1d..8fb2ae4 100644
--- a/target-ppc/mmu-hash64.h
+++ b/target-ppc/mmu-hash64.h
@@ -85,22 +85,24 @@ void ppc_hash64_stop_access(uint64_t token);
static inline target_ulong ppc_hash64_load_hpte0(CPUPPCState *env,
uint64_t token, int index)
{
-index *= HASH_PTE_SIZE_64;
+uint64_t addr;
+addr = token + (index * HASH_PTE_SIZE_64) + HASH_PTE_SIZE_64/2;
if (env->external_htab) {
-return ldq_p((const void *)(token + index));
+return ldq_p((const void *)(uintptr_t)addr);
} else {
-return ldq_phys(token + index);
+return ldq_phys(addr);
}
}
static inline target_ulong ppc_hash64_load_hpte1(CPUPPCState *env,
uint64_t token, int index)
{
-index *= HASH_PTE_SIZE_64;
+uint64_t addr;
+addr = token + (index * HASH_PTE_SIZE_64) + HASH_PTE_SIZE_64/2;
if (env->external_htab) {
-return ldq_p((const void *)(token + index + HASH_PTE_SIZE_64/2));
+return ldq_p((const void *)(uintptr_t)addr);
} else {
-return ldq_phys(token + index + HASH_PTE_SIZE_64/2);
+return ldq_phys(addr);
}
}
[Qemu-devel] [PATCH 1/4] gtk: Use gtk generic event signal instead of motion-notify-event
The GDK motion-notify-event isn't generated when the pointer goes out
of the target window even if the pointer is grabbed, which essentially
means to lose the pointer tracking in gtk-ui.
Meanwhile the generic "event" signal is sent when the pointer is
grabbed, so we can use this and pick the motion notify events manually
there instead.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai
---
ui/gtk.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index a633d8934633..4d5ea8e6bb38 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -760,6 +760,13 @@ static gboolean gd_key_event(GtkWidget *widget,
GdkEventKey *key, void *opaque)
return TRUE;
}
+static gboolean gd_event(GtkWidget *widget, GdkEvent *event, void *opaque)
+{
+if (event->type == GDK_MOTION_NOTIFY)
+return gd_motion_event(widget, &event->motion, opaque);
+return FALSE;
+}
+
/** Window Menu Actions **/
static void gd_menu_pause(GtkMenuItem *item, void *opaque)
@@ -1254,8 +1261,8 @@ static void gd_connect_signals(GtkDisplayState *s)
g_signal_connect(s->drawing_area, "expose-event",
G_CALLBACK(gd_expose_event), s);
#endif
-g_signal_connect(s->drawing_area, "motion-notify-event",
- G_CALLBACK(gd_motion_event), s);
+g_signal_connect(s->drawing_area, "event",
+ G_CALLBACK(gd_event), s);
g_signal_connect(s->drawing_area, "button-press-event",
G_CALLBACK(gd_button_event), s);
g_signal_connect(s->drawing_area, "button-release-event",
--
1.8.5.2
[Qemu-devel] [PATCH 0/4] Fix relative pointer tracking on Gtk UI
Hi, this is a series of patches to fix / improve the behavior of Gtk UI in the relative pointer tracking mode. Most people didn't notice the bug likely because it doesn't appear as long as the aboslute mode is used, e.g. when vmmouse input driver is enabled. But I hit this annoying behavior because of the recent regression of vmmouse driver (that doesn't work as default). Or, it might be that this didn't happen with the old Gtk2. Dunno. The last two patches are no actual fixes but rather behavior changes for my tastes. Both are to align the behavior compatible with SDL UI, and I like it better just because I got used to it. So, I don't mind if they are skipped. thanks, Takashi
Re: [Qemu-devel] [PATCH v2] SPARC: Add and use CPU_FEATURE_CASA
On 02/13/2014 02:00 PM, Sebastian Huber wrote:
> On 2014-02-13 13:01, Fabien Chouteau wrote:
>> On 02/13/2014 10:52 AM, Sebastian Huber wrote:
>>> The LEON3 processor has support for the CASA instruction which is
>>> normally only available for SPARC V9 processors. Binutils 2.24
>>> and GCC 4.9 will support this instruction for LEON3. GCC uses it to
>>> generate C11 atomic operations.
>>>
>>> The CAS synthetic instruction uses an ASI of 0x80. If TARGET_SPARC64 is
>>> not defined use a supervisor data load/store for an ASI of 0x80 in
>>> helper_ld_asi()/helper_st_asi().
>>>
>>
>> Hello Sebastian,
>>
>> If I understand correctly, the difference with V1 is that ASI 0x80. Why
>> did you chose Supervisor data access against User data access?
>
> User data access would work also. I don't have a preference here.
>
>> (I cannot
>> find documentation about 0x80 ASI)
>
> GCC will generate CAS instructions, e.g.
...
> In the GNU Binutils you find:
>
> opcodes/sparc-opc.c:{ "cas",F3(3, 0x3c, 0)|ASI(0x80), F3(~3, ~0x3c,
> ~0)|ASI(~0x80), "[1],2,d", F_ALIAS, 0, v9andleon }, /* casa [rs1]ASI_P,rs2,rd
> */
>
> This is where the 0x80 comes from.
>
In some leon3 doc I found this:
62.2.7 Compare and Swap instruction (CASA)
LEON3 implements the SPARC V9 Compare and Swap Alternative (CASA) instruction.
The CASA
is enabled the interger load delay is set to 1 and the NOTAG generic is 0. The
CASA operates as
described in the SPARC V9 manual. The instruction is privileged but setting ASI
= 0xA (user data)
will allow it to be used in user mode.
Which confirm privileged instruction. I will ask our GCC expert if they
know where that 0x80 ASI comes from.
[Qemu-devel] [PATCH 4/4] gtk: Add "Grab On Click" option
I simply like it better, you don't? :)
Signed-off-by: Takashi Iwai
---
ui/gtk.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index e04f0781ae6c..4942c8330505 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -133,6 +133,7 @@ typedef struct GtkDisplayState
GtkWidget *zoom_fit_item;
GtkWidget *grab_item;
GtkWidget *grab_on_hover_item;
+GtkWidget *grab_on_click_item;
GtkWidget *vga_item;
int nb_vcs;
@@ -181,6 +182,11 @@ static bool gd_grab_on_hover(GtkDisplayState *s)
return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->grab_on_hover_item));
}
+static bool gd_grab_on_click(GtkDisplayState *s)
+{
+return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->grab_on_click_item));
+}
+
static bool gd_on_vga(GtkDisplayState *s)
{
return gtk_notebook_get_current_page(GTK_NOTEBOOK(s->notebook)) == 0;
@@ -678,6 +684,12 @@ static gboolean gd_button_event(GtkWidget *widget,
GdkEventButton *button,
int dx, dy;
int n;
+if (button->button == 1 && button->type == GDK_BUTTON_PRESS &&
+ !gd_is_grab_active(s) && gd_grab_on_click(s) && button->button == 1) {
+gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item),
TRUE);
+ return TRUE;
+}
+
if (button->button == 1) {
n = 0x01;
} else if (button->button == 2) {
@@ -1401,6 +1413,9 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState *s,
GtkAccelGroup *accel_g
s->grab_on_hover_item = gtk_check_menu_item_new_with_mnemonic(_("Grab On
_Hover"));
gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s->grab_on_hover_item);
+s->grab_on_click_item = gtk_check_menu_item_new_with_mnemonic(_("Grab On
_Click"));
+gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s->grab_on_click_item);
+
s->grab_item = gtk_check_menu_item_new_with_mnemonic(_("_Grab Input"));
gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->grab_item),
"/View/Grab Input");
--
1.8.5.2
[Qemu-devel] [PATCH 3/4] gtk: Remember the last grabbed pointer position
It's pretty annoying that the pointer reappears at a random place once
after grabbing and ungrabbing the input. Better to restore to the
original position where the pointer was grabbed.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai
---
ui/gtk.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index b72272ebac3f..e04f0781ae6c 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -151,6 +151,8 @@ typedef struct GtkDisplayState
gboolean last_set;
int last_x;
int last_y;
+int grab_x_root;
+int grab_y_root;
double scale_x;
double scale_y;
@@ -965,8 +967,8 @@ static void gd_ungrab_keyboard(GtkDisplayState *s)
static void gd_grab_pointer(GtkDisplayState *s)
{
-#if GTK_CHECK_VERSION(3, 0, 0)
GdkDisplay *display = gtk_widget_get_display(s->drawing_area);
+#if GTK_CHECK_VERSION(3, 0, 0)
GdkDeviceManager *mgr = gdk_display_get_device_manager(display);
GList *devices = gdk_device_manager_list_devices(mgr,
GDK_DEVICE_TYPE_MASTER);
@@ -990,6 +992,8 @@ static void gd_grab_pointer(GtkDisplayState *s)
tmp = tmp->next;
}
g_list_free(devices);
+gdk_device_get_position(gdk_device_manager_get_client_pointer(mgr),
+NULL, &s->grab_x_root, &s->grab_y_root);
#else
gdk_pointer_grab(gtk_widget_get_window(s->drawing_area),
FALSE, /* All events to come to our window directly */
@@ -1001,13 +1005,15 @@ static void gd_grab_pointer(GtkDisplayState *s)
NULL, /* Allow cursor to move over entire desktop */
s->null_cursor,
GDK_CURRENT_TIME);
+gdk_display_get_pointer(display, NULL,
+&s->grab_x_root, &s->grab_y_root, NULL);
#endif
}
static void gd_ungrab_pointer(GtkDisplayState *s)
{
-#if GTK_CHECK_VERSION(3, 0, 0)
GdkDisplay *display = gtk_widget_get_display(s->drawing_area);
+#if GTK_CHECK_VERSION(3, 0, 0)
GdkDeviceManager *mgr = gdk_display_get_device_manager(display);
GList *devices = gdk_device_manager_list_devices(mgr,
GDK_DEVICE_TYPE_MASTER);
@@ -1021,8 +1027,14 @@ static void gd_ungrab_pointer(GtkDisplayState *s)
tmp = tmp->next;
}
g_list_free(devices);
+gdk_device_warp(gdk_device_manager_get_client_pointer(mgr),
+gtk_widget_get_screen(s->drawing_area),
+s->grab_x_root, s->grab_y_root);
#else
gdk_pointer_ungrab(GDK_CURRENT_TIME);
+gdk_display_warp_pointer(display,
+ gtk_widget_get_screen(s->drawing_area),
+ s->grab_x_root, s->grab_y_root);
#endif
}
--
1.8.5.2
Re: [Qemu-devel] [PATCH V6 09/10] tests: add cases for inherited struct and union with discriminator
Wenchao Xia writes: > Test for inherit and complex union. This patch conflicts badly with my test coverage work in "[PATCH v2 00/13] qapi: Test coverage & clean up generated code". My series systematically covers code generation in scripts/qapi*py, and that takes me seven patches. If I put your patch first, mine all explode, and I get to start over. Putting my series first looks far easier to resolve, because only this one patch conflicts. Would you mind me rebasing your series on top of mine?
[Qemu-devel] [PATCH 2/4] gtk: Fix the relative pointer tracking mode
The relative pointer tracking mode was still buggy even after the
previous fix of the motion-notify-event since the events are filtered
out when the pointer moves outside the drawing window due to the
boundary check for the absolute mode.
This patch fixes the issue by moving the unnecessary boundary check
into the if block of absolute mode, and keep the coordinate in the
relative mode even if it's outside the drawing area. But this makes
the coordinate (last_x, last_y) possibly pointing to (-1,-1),
introduce a new flag to indicate the last coordinate has been
updated.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai
---
ui/gtk.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index 4d5ea8e6bb38..b72272ebac3f 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -148,6 +148,7 @@ typedef struct GtkDisplayState
DisplayChangeListener dcl;
DisplaySurface *ds;
int button_mask;
+gboolean last_set;
int last_x;
int last_y;
@@ -604,16 +605,15 @@ static gboolean gd_motion_event(GtkWidget *widget,
GdkEventMotion *motion,
x = (motion->x - mx) / s->scale_x;
y = (motion->y - my) / s->scale_y;
-if (x < 0 || y < 0 ||
-x >= surface_width(s->ds) ||
-y >= surface_height(s->ds)) {
-return TRUE;
-}
-
if (kbd_mouse_is_absolute()) {
+if (x < 0 || y < 0 ||
+x >= surface_width(s->ds) ||
+y >= surface_height(s->ds)) {
+return TRUE;
+}
dx = x * 0x7FFF / (surface_width(s->ds) - 1);
dy = y * 0x7FFF / (surface_height(s->ds) - 1);
-} else if (s->last_x == -1 || s->last_y == -1) {
+} else if (!s->last_set) {
dx = 0;
dy = 0;
} else {
@@ -623,6 +623,7 @@ static gboolean gd_motion_event(GtkWidget *widget,
GdkEventMotion *motion,
s->last_x = x;
s->last_y = y;
+s->last_set = TRUE;
if (kbd_mouse_is_absolute() || gd_is_grab_active(s)) {
kbd_mouse_event(dx, dy, 0, s->button_mask);
@@ -661,8 +662,7 @@ static gboolean gd_motion_event(GtkWidget *widget,
GdkEventMotion *motion,
GdkDisplay *display = gtk_widget_get_display(widget);
gdk_display_warp_pointer(display, screen, x, y);
#endif
-s->last_x = -1;
-s->last_y = -1;
+s->last_set = FALSE;
return FALSE;
}
}
--
1.8.5.2
Re: [Qemu-devel] [PATCH] target-ppc: fix warn_unused_result build break with in-kernel HTAB support
On 13.02.2014, at 04:00, Aneesh Kumar K.V wrote: > Greg Kurz writes: > >> The 7029677e4 commit introduced the following build break: >> >> target-ppc/kvm.c: In function ‘kvmppc_hash64_write_pte’: >> target-ppc/kvm.c:2017:10: error: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Werror=unused-result] >> write(htab_fd, &hpte_buf, sizeof(hpte_buf)); >> ^ >> >> Even though nothing is done for the moment if kvm_htab_write() fails, we >> obviously need to be explicit. Let's add an *empty* return path to please >> gcc. >> > > Reviewed-by: Aneesh Kumar K.V Thanks, applied to ppc-next. Alex
Re: [Qemu-devel] [PATCH v2 1/4] target-mips: add CPU definition for MIPS32R5
On 10 February 2014 15:42, Peter Maydell wrote:
> On 10 February 2014 13:51, Andreas Färber wrote:
>> Am 24.01.2014 17:18, schrieb Petar Jovanovic:
>>> From: Petar Jovanovic
>>> --- 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.
>>> */
>>
>> That is not really possible. QEMU needs to keep command line backwards
>> compatibility, so if you add a generic model now, we will need to live
>> with the generic model for a long time. What's the difficulty with
>> taking "a real CPU model"? Is there no silicon yet or just a code name
>> rather than a marketing name?
>
> Good point, though I notice we have two MIPS CPUs already
> with this same 'FIXME' comment about being generic.
So before I apply the pull request with this patch, does
anybody want to actually object to adding another 'generic'
MIPS CPU to the two we have already? It seems reasonable
enough to me.
thanks
-- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH V10] target-ppc: Fix htab_mask calculation
On 13.02.2014, at 11:40, Greg Kurz wrote: > On Thu, 13 Feb 2014 08:29:28 +0530 > "Aneesh Kumar K.V" wrote: > >> From: "Aneesh Kumar K.V" >> >> Correctly update the htab_mask using the return value of >> KVM_PPC_ALLOCATE_HTAB ioctl. Also we don't update sdr1 >> on GET_SREGS for HV. We check for external htab and if >> found true, we don't need to update sdr1 >> >> Signed-off-by: Aneesh Kumar K.V > > Reviewed-by: Greg Kurz > >> --- >> Changes from V9: >> * Fix TCG breakage >> > > Alex, > > This patch is a complete replacement for commit 1df2d6d900a9 in your > ppc-next branch. > > Please apply so that TCG works again ! :) Thanks, applied to ppc-next. Alex
Re: [Qemu-devel] [PATCH RFC] char: fix avail_connections init in qemu_chr_open_eventfd()
Hello,
Can someone take a look at my previous email and tell me if my patch is
just wrong ?
Thank you.
--
David Marchand
On Tue, Feb 4, 2014 at 10:17 PM, David Marchand wrote:
> Hello,
>
> First of all, this is a pure RFC patch, I did not take too much time to
> dig into
> qemu source code to find the right solution, but since
> qemu_chr_open_eventfd()
> is only used by the code I was looking at, here is a patch.
>
>
> When trying to use a ivshmem server with qemu, ivshmem init code tries to
> create a CharDriverState object for each eventfd retrieved from the server.
> To create this object, a call to qemu_chr_open_eventfd() is done.
> Right after this, before adding a frontend, qemu_chr_fe_claim_no_fail() is
> called.
> qemu_chr_open_eventfd() does not set avail_connections to 1, so no
> frontend can
> be associated because qemu_chr_fe_claim_no_fail() makes qemu stop right
> away.
>
> I suppose this problem comes from 456d60692310e7ac25cf822cc1e98192ad636ece
> "qemu-char: Call fe_claim / fe_release when not using qdev chr properties".
>
> Fix this, by setting avail_connections to 1 in qemu_chr_open_eventfd().
>
> Signed-off-by: David Marchand
> ---
> qemu-char.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 30c5a6a..c0adb04 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -2492,7 +2492,12 @@ static gboolean tcp_chr_read(GIOChannel *chan,
> GIOCondition cond, void *opaque)
> #ifndef _WIN32
> CharDriverState *qemu_chr_open_eventfd(int eventfd)
> {
> -return qemu_chr_open_fd(eventfd, eventfd);
> +CharDriverState *chr = qemu_chr_open_fd(eventfd, eventfd);
> +
> +if (chr)
> +chr->avail_connections = 1;
> +
> +return chr;
> }
> #endif
>
> --
> David Marchand
>
>
Re: [Qemu-devel] [PATCH v10 13/13] dump: add 'query-dump-guest-memory-capability' command
On Thu, 13 Feb 2014 09:48:33 +0800
Qiao Nuohan wrote:
> On 02/12/2014 10:49 PM, Luiz Capitulino wrote:
> > On Wed, 12 Feb 2014 14:34:19 +0800
> > Qiao Nuohan wrote:
> >
> >> 'query-dump-guest-memory-capability' is used to query the available
> >> formats for
> >> 'dump-guest-memory'. The output of the command will be like:
> >>
> >> -> { "execute": "query-dump-guest-memory-capability" }
> >> <- { "return": { "formats":
> >> ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
> >>
> >> Signed-off-by: Qiao Nuohan
> >
> > The new command looks good to me, but the patch itself is broken. It doesn't
> > apply and I could identify at least one breakage below...
>
> I think it is because of the 80 character limit.If I am wrong, please correct
> me. And I have attach the new patch with this mail, please check.
Applied to the qmp branch, thanks.
>
> >
> >> ---
> >>dump.c | 33 +
> >>qapi-schema.json | 23 +++
> >>qmp-commands.hx | 20
> >>3 files changed, 76 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/dump.c b/dump.c
> >> index 2ebbb23..3a8d55e 100644
> >> --- a/dump.c
> >> +++ b/dump.c
> >> @@ -1788,3 +1788,36 @@ void qmp_dump_guest_memory(bool paging, const char
> >> *file,
> >> bool has_begin,
> >>
> >>g_free(s);
> >>}
> >> +
> >> +DumpGuestMemoryCapability *qmp_query_dump_guest_memory_capability(Error
> >> **errp)
> >> +{
> >> +DumpGuestMemoryFormatList *item;
> >> +DumpGuestMemoryCapability *cap =
> >> +
> >> g_malloc0(sizeof(DumpGuestMemoryCapability));
> >> +
> >> +/* elf is always available */
> >> +item = g_malloc0(sizeof(DumpGuestMemoryFormatList));
> >> +cap->formats = item;
> >> +item->value = DUMP_GUEST_MEMORY_FORMAT_ELF;
> >> +
> >> +/* kdump-zlib is always available */
> >> +item->next = g_malloc0(sizeof(DumpGuestMemoryFormatList));
> >> +item = item->next;
> >> +item->value = DUMP_GUEST_MEMORY_FORMAT_KDUMP_ZLIB;
> >> +
> >> +/* add new item if kdump-lzo is available */
> >> +#ifdef CONFIG_LZO
> >> +item->next = g_malloc0(sizeof(DumpGuestMemoryFormatList));
> >> +item = item->next;
> >> +item->value = DUMP_GUEST_MEMORY_FORMAT_KDUMP_LZO;
> >> +#endif
> >> +
> >> +/* add new item if kdump-snappy is available */
> >> +#ifdef CONFIG_SNAPPY
> >> +item->next = g_malloc0(sizeof(DumpGuestMemoryFormatList));
> >> +item = item->next;
> >> +item->value = DUMP_GUEST_MEMORY_FORMAT_KDUMP_SNAPPY;
> >> +#endif
> >> +
> >> +return cap;
> >> +}
> >> diff --git a/qapi-schema.json b/qapi-schema.json
> >> index 7f62007..a097e6c 100644
> >> --- a/qapi-schema.json
> >> +++ b/qapi-schema.json
> >> @@ -2783,6 +2783,29 @@
> >>'*length': 'int', '*format': 'DumpGuestMemoryFormat' } }
> >>
> >>##
> >> +# @DumpGuestMemoryCapability:
> >> +#
> >> +# A list of the available formats for dump-guest-memory
> >> +#
> >> +# Since: 2.0
> >> +##
> >> +{ 'type': 'DumpGuestMemoryCapability',
> >> + 'data': {
> >> + 'formats': ['DumpGuestMemoryFormat'] } }
> >> +
> >> +##
> >> +# @query-dump-guest-memory-capability:
> >> +#
> >> +# Returns the available formats for dump-guest-memory
> >> +#
> >> +# Returns: A @DumpGuestMemoryCapability object listing available formats
> >> for
> >> +# dump-guest-memory
> >> +#
> >> +# Since: 2.0
> >> +##
> >> +{ 'command': 'query-dump-guest-memory-capability', 'returns':
> >> 'DumpGuestMemoryCapability' }
> >
> > Here.
> >
> >> +
> >> +##
> >># @netdev_add:
> >>#
> >># Add a network backend.
> >> diff --git a/qmp-commands.hx b/qmp-commands.hx
> >> index 019dde6..029cb3d 100644
> >> --- a/qmp-commands.hx
> >> +++ b/qmp-commands.hx
> >> @@ -829,6 +829,26 @@ Notes:
> >>EQMP
> >>
> >>{
> >> +.name = "query-dump-guest-memory-capability",
> >> +.args_type = "",
> >> +.mhandler.cmd_new =
> >> qmp_marshal_input_query_dump_guest_memory_capability,
> >> +},
> >> +
> >> +SQMP
> >> +query-dump-guest-memory-capability
> >> +--
> >> +
> >> +Show available formats for 'dump-guest-memory'
> >> +
> >> +Example:
> >> +
> >> +-> { "execute": "query-dump-guest-memory-capability" }
> >> +<- { "return": { "formats":
> >> +["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
> >> +
> >> +EQMP
> >> +
> >> +{
> >>.name = "netdev_add",
> >>.args_type = "netdev:O",
> >>.mhandler.cmd_new = qmp_netdev_add,
> >
> >
>
>
