Re: [Qemu-devel] [PATCH v5 23/24] replay: add BH oneshot event for block layer

[Pavel Dovgalyuk]

> -Original Message-
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Sent: Friday, July 27, 2018 7:45 PM
> To: Pavel Dovgalyuk
> Cc: 'Pavel Dovgalyuk'; qemu-devel@nongnu.org; kw...@redhat.com; 
> peter.mayd...@linaro.org;
> war2jor...@live.com; crosthwaite.pe...@gmail.com; boost.li...@gmail.com; 
> quint...@redhat.com;
> ciro.santi...@gmail.com; jasow...@redhat.com; m...@redhat.com; 
> zuban...@gmail.com;
> arm...@redhat.com; maria.klimushenk...@ispras.ru; kra...@redhat.com;
> thomas.dull...@googlemail.com; pbonz...@redhat.com; mre...@redhat.com; 
> dgilb...@redhat.com;
> r...@twiddle.net
> Subject: Re: [PATCH v5 23/24] replay: add BH oneshot event for block layer
> 
> 
> Pavel Dovgalyuk  writes:
> 
> >> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> >> > Replay is capable of recording normal BH events, but sometimes
> >> > there are single use callbacks scheduled with aio_bh_schedule_oneshot
> >> > function. This patch enables recording and replaying such callbacks.
> >> > Block layer uses these events for calling the completion function.
> >> > Replaying these calls makes the execution deterministic.
> >> >
> >> > Signed-off-by: Pavel Dovgalyuk 
> >>
> >> I'm not sure what about this commit causes the compile breakage I'm
> >> seeing:
> >>
> >>   LINKaarch64-linux-user/qemu-aarch64
> >> ../libqemuutil.a(cpu-get-icount.o):(.bss+0x0): multiple definition of 
> >> `use_icount'
> >> exec.o:(.bss+0x58): first defined here
> >> collect2: error: ld returned 1 exit status
> >> Makefile:199: recipe for target 'qemu-aarch64' failed
> >> make[1]: *** [qemu-aarch64] Error 1
> >> Makefile:481: recipe for target 'subdir-aarch64-linux-user' failed
> >> make: *** [subdir-aarch64-linux-user] Error 2
> >>
> >> It only occurs on a make clean && make -j on that commit though. It's
> >> hidden if you do incremental builds.
> >
> > make distclean works for me in such cases.
> 
> Hmmm
> 
> make distclean
> ./configure
> make
> 
> And I get:
> 
> LINKaarch64-linux-user/qemu-aarch64
> ../libqemuutil.a(cpu-get-icount.o):(.bss+0x0): multiple definition of 
> `use_icount'
> exec.o:(.bss+0x58): first defined here
> collect2: error: ld returned 1 exit status
> Makefile:199: recipe for target 'qemu-aarch64' failed
> make[1]: *** [qemu-aarch64] Error 1
> Makefile:481: recipe for target 'subdir-aarch64-linux-user' failed
> make: *** [subdir-aarch64-linux-user] Error 2

That's strange. As I understand, linux-user emulators does not include block 
layer.
They also don't include record/replay.
Why then block- and record-related stub affects the build?

Pavel Dovgalyuk

Re: [Qemu-devel] 'make vm-build-freebsd' don't work if KVM isn't enabled

[Fam Zheng]

On Mon, 07/30 16:20, Peter Maydell wrote:
> On 30 July 2018 at 14:40, Peter Maydell  wrote:
> > On 30 July 2018 at 14:36, Peter Maydell  wrote:
> >> On 30 July 2018 at 14:23, Peter Maydell  wrote:
> >>> The tests in tests/vm/ seem to make some attempt to cope with the
> >>> host system not allowing the user to use KVM, but it doesn't quite
> >>> work.
> >>
> >> Also, passing V=1 to the outer make command like:
> >>  make vm-build-freebsd J=16 V=1
> >> isn't propagated through to the VM: test output looks like
> >>   GTESTER check-qtest-aarch64
> >>   GTESTER check-qtest-alpha
> >> instead of the proper verbose output with a line per subtest.
> >
> > Nor is the J=16 option passed through to "make check":
> 
> Patches for these things on the way, once I've completed a test run.

All good catches! Looking forward to the fixes. Thanks.

Fam

Re: [Qemu-devel] [PATCH v2 21/23] libqtest: Remove qtest_qmp_discard_response() & friends

[Thomas Huth]

On 08/02/2018 06:53 AM, Markus Armbruster wrote:
> Thomas Huth  writes:
> 
>> On 07/30/2018 08:32 AM, Markus Armbruster wrote:
>>> Eric Blake  writes:
>>>
 On 07/27/2018 11:46 AM, Thomas Huth wrote:
> On 07/27/2018 05:13 PM, Markus Armbruster wrote:
>> qtest_qmp_discard_response(...) is shorthand for
>> qobject_unref(qtest_qmp(...), except it's not actually shorter.
>
> But the latter is IMHO harder to read.
>>>
>>> Doing things sloppily looks a bit uglier now.  That's a feature.
>>>
 Maybe, but then it lends itself well to:

 QObject *rsp = qtest_qmp(...);
 qobject_unref(rsp);

 which is where you do insert tests for valid responses.

> And it might be shorter in the compiled binary (one function call vs. 
> two).
>>>
>>> I'd be quite sympathetic to this argument...
>>>
 The size of the test binaries is not our biggest concern.
>>>
>>> ... outside tests/.
>>>
>> Moreover, the presence of these functions encourage sloppy testing.
>
> Shouldn't we then rather fix the tests to check for valid responses
> instead of replacing this function with harder-to-read code?
>>>
>>> I'd welcome such patches, but this series is already pretty long.
>>
>> Then maybe rather drop this patch from this series, and fix the issues
>> in a separate series instead?
> 
> Do you insist?

No. But I'd still like to convince you that this patch is unnecessary
right now.

> I fail to see how changing
> 
> qmp_discard_response("{ 'execute': 'system_reset' }");
> 
> to
> 
> qobject_unref(qmp("{ 'execute': 'system_reset' }"));
> 
> is so awful it would justify demanding I pause my work on libqtest to
> first figure out which parts of ignored responses are worth checking,
> then code up the checks.

First, you don't have to pause this series just because of this, since
the remaining two patches do not depend on this one.
Then, I still fail to see the real benefit here. You've found something
that needs proper clean up later (by adding checks for valid responses).
So IMHO simply add a big fat warning comment to the description of
qmp_discard_response would be sufficient. Then you can easily grep for
"qmp_discard_response" later to find the spots that need fixing. If you
replace it with that ugly nested construct instead, we still should fix
it later, but it's a little bit harder to grep, and since we need to
change it later again anyway, it just sounds like unnecessary code churn
to me. So do you really need this so badly (for your later work?), or
could you simply skip this patch?

> Would you accept
> 
> rsp = qmp("{ 'execute': 'system_reset' }"));
> qobject_unref(rsp);
> 
> ?

While this is easier to read, I think we lose the easy way to grep for
the spots that need fixing later here, so let's better not do this.

> If none of the above is acceptable to you, then I'll push the crap that
> needs to go from libqtest into the crap-using tests, like this:
> 
> /* TODO actually test the results and get rid of this */
> #define qmp_discard_response(...) qobject_unref(qmp(__VA_ARGS__));

Fine for me.

 Thomas

Re: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host bridge into separate pci domain

[no-reply]

Hi,

This series failed docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 1533177924-24765-1-git-send-email-whois.zihan.y...@gmail.com
Subject: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host 
bridge into separate pci domain

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
453612f703 pci_expander_bridge: add start_bus property
7e0df5e261 pci_expander_bridge: Add ioport for pxb host bus
a20115d9f1 pci_expander_bridge: Add config_read callback
05844a4f35 i386/acpi-build: describe new pci domain in AML
97e32a9b49 acpi-build: allocate mcfg for pxb-pcie host bridges
0fd3d73fc5 pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

=== OUTPUT BEGIN ===
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-zotc4hms/src'
  GEN 
/var/tmp/patchew-tester-tmp-zotc4hms/src/docker-src.2018-08-02-00.59.02.6989/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-zotc4hms/src/docker-src.2018-08-02-00.59.02.6989/qemu.tar.vroot'...
done.
Checking out files:  42% (2687/6322)   
Checking out files:  43% (2719/6322)   
Checking out files:  44% (2782/6322)   
Checking out files:  45% (2845/6322)   
Checking out files:  46% (2909/6322)   
Checking out files:  47% (2972/6322)   
Checking out files:  48% (3035/6322)   
Checking out files:  49% (3098/6322)   
Checking out files:  50% (3161/6322)   
Checking out files:  51% (3225/6322)   
Checking out files:  52% (3288/6322)   
Checking out files:  53% (3351/6322)   
Checking out files:  53% (3366/6322)   
Checking out files:  54% (3414/6322)   
Checking out files:  55% (3478/6322)   
Checking out files:  56% (3541/6322)   
Checking out files:  57% (3604/6322)   
Checking out files:  58% (3667/6322)   
Checking out files:  59% (3730/6322)   
Checking out files:  60% (3794/6322)   
Checking out files:  61% (3857/6322)   
Checking out files:  62% (3920/6322)   
Checking out files:  63% (3983/6322)   
Checking out files:  64% (4047/6322)   
Checking out files:  65% (4110/6322)   
Checking out files:  66% (4173/6322)   
Checking out files:  67% (4236/6322)   
Checking out files:  68% (4299/6322)   
Checking out files:  69% (4363/6322)   
Checking out files:  70% (4426/6322)   
Checking out files:  71% (4489/6322)   
Checking out files:  72% (4552/6322)   
Checking out files:  73% (4616/6322)   
Checking out files:  74% (4679/6322)   
Checking out files:  75% (4742/6322)   
Checking out files:  76% (4805/6322)   
Checking out files:  77% (4868/6322)   
Checking out files:  78% (4932/6322)   
Checking out files:  79% (4995/6322)   
Checking out files:  80% (5058/6322)   
Checking out files:  81% (5121/6322)   
Checking out files:  82% (5185/6322)   
Checking out files:  83% (5248/6322)   
Checking out files:  84% (5311/6322)   
Checking out files:  85% (5374/6322)   
Checking out files:  86% (5437/6322)   
Checking out files:  87% (5501/6322)   
Checking out files:  88% (5564/6322)   
Checking out files:  89% (5627/6322)   
Checking out files:  90% (5690/6322)   
Checking out files:  91% (5754/6322)   
Checking out files:  92% (5817/6322)   
Checking out files:  93% (5880/6322)   
Checking out files:  94% (5943/6322)   
Checking out files:  95% (6006/6322)   
Checking out files:  96% (6070/6322)   
Checking out files:  97% (6133/6322)   
Checking out files:  98% (6196/6322)   
Checking out files:  99% (6259/6322)   
Checking out files: 100% (6322/6322)   
Checking out files: 100% (6322/6322), done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-zotc4hms/src/docker-src.2018-08-02-00.59.02.6989/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-zotc4hms/src/docker-src.2018-08-02-00.59.02.6989/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-mingw in qemu:fedora 
Packages installed:
SDL2-devel-2.0.8-5.fc28.x86_64
bc-1.07.1-5.fc28.x86_64
bison-3.0.4-9.fc28.x86_64
bluez-libs-devel-5.49-3.fc28.x86_64
brlapi-devel-0.6.7-12.fc28.x86_64
bzip2-1.0.6-26.fc28.x86_64
bzip2-devel-1.0.6-26.fc28.x86_64
ccache-3.4.2-2.fc28.x86_64
clang-6.0.0-5.fc28.x86_64
device-mapper-multipath-devel-0.7.4-2.git07e7bd5.fc28.x86_64
findutils-4.6.0-19.fc28.x86_64
flex-2.6.1-7.fc28.x86_64
gcc-8.1.1-1.fc28.x86_64
gcc-c++-8.1.1-1.fc28.x86_64
gettext-0.19.8.1-14.fc28.x86_64
git-2.17.1-2.fc28.x86_64
glib2-devel-2.56.1-3.fc28.x86_64
glusterfs-api-devel-4.0.2-1.fc28.x86_64

Re: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host bridge into separate pci domain

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1533177924-24765-1-git-send-email-whois.zihan.y...@gmail.com
Subject: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host 
bridge into separate pci domain

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
453612f703 pci_expander_bridge: add start_bus property
7e0df5e261 pci_expander_bridge: Add ioport for pxb host bus
a20115d9f1 pci_expander_bridge: Add config_read callback
05844a4f35 i386/acpi-build: describe new pci domain in AML
97e32a9b49 acpi-build: allocate mcfg for pxb-pcie host bridges
0fd3d73fc5 pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

=== OUTPUT BEGIN ===
Checking PATCH 1/6: pci_expander_bridge: add type TYPE_PXB_PCIE_HOST...
WARNING: line over 80 characters
#92: FILE: hw/pci-bridge/pci_expander_bridge.c:156:
+static void pxb_pcie_host_get_mmcfg_size(Object *obj, Visitor *v, const char 
*name,

ERROR: space prohibited between function name and open parenthesis '('
#188: FILE: hw/pci-bridge/pci_expander_bridge.c:332:
+g_assert (pxb->max_bus >= pxb->bus_nr);

WARNING: line over 80 characters
#207: FILE: hw/pci-bridge/pci_expander_bridge.c:399:
+DEFINE_PROP_UINT16(PROP_PXB_NUMA_NODE, PXBDev, numa_node, 
NUMA_NODE_UNASSIGNED),

WARNING: line over 80 characters
#213: FILE: hw/pci-bridge/pci_expander_bridge.c:405:
+DEFINE_PROP_UINT16(PROP_PXB_NUMA_NODE, PXBDev, numa_node, 
NUMA_NODE_UNASSIGNED),

total: 1 errors, 3 warnings, 211 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/6: acpi-build: allocate mcfg for pxb-pcie host bridges...
ERROR: do not use C99 // comments
#34: FILE: hw/i386/acpi-build.c:94:
+uint8_t bus_nr; // start bus number

ERROR: do not use assignment in if condition
#189: FILE: hw/i386/acpi-build.c:2790:
+if ((mcfg = acpi_get_mcfg()) != NULL) {

ERROR: do not initialise statics to 0 or NULL
#278: FILE: hw/pci-bridge/pci_expander_bridge.c:125:
+static uint64_t pxb_mcfg_hole_size = 0;

WARNING: line over 80 characters
#353: FILE: hw/pci-bridge/pci_expander_bridge.c:351:
+pxb->domain_nr ? pxb_pcie_mcfg_base : 
MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT);

ERROR: braces {} are necessary for all arms of this statement
#357: FILE: hw/pci-bridge/pci_expander_bridge.c:355:
+if (pxb->domain_nr)
[...]

ERROR: braces {} are necessary for all arms of this statement
#366: FILE: hw/pci-bridge/pci_expander_bridge.c:468:
+if (0 == pxb_pcie_mcfg_base)
[...]

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#439: 
new file mode 100644

total: 5 errors, 2 warnings, 399 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 3/6: i386/acpi-build: describe new pci domain in AML...
ERROR: do not use C99 // comments
#28: FILE: hw/i386/acpi-build.c:1879:
+i = 1; // PCI0 is q35 host, pxb starts from 1

WARNING: line over 80 characters
#111: FILE: hw/i386/acpi-build.c:2168:
+aml_append(dev, aml_name_decl("_HID", 
aml_eisaid("PNP0C31")));

total: 1 errors, 1 warnings, 112 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 4/6: pci_expander_bridge: Add config_read callback...
ERROR: line over 90 characters
#43: FILE: hw/pci-bridge/pci_expander_bridge.c:354:
+object_property_add_child(qdev_get_machine(), "pxb-pcie-host[*]", 
OBJECT(ds), NULL);

ERROR: switch and case should be at the same indent
#63: FILE: hw/pci-bridge/pci_expander_bridge.c:435:
+   switch (address) {
+case MCH_HOST_BRIDGE_PCIEXBAR:
[...]
+case MCH_HOST_BRIDGE_PCIEXBAR + 4:
[...]
+case MCH_HOST_BRIDGE_PCIEXBAR + 8:  // Fix me!
[...]
+default:

WARNING: line over 80 characters
#67: FILE: hw/pci-bridge/pci_expander_bridge.c:439:
+val = object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) & 
0x;

ERROR: line over 90 characters
#72: FILE: hw/pci-bridge/pci_expander_bridge.c:444:
+val = (object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) >> 
32) & 0x;

ERROR: do not use C99 // comments
#74: FILE: 

Re: [Qemu-devel] [PATCH v2 21/23] libqtest: Remove qtest_qmp_discard_response() & friends

[Markus Armbruster]

Thomas Huth  writes:

> On 07/30/2018 08:32 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> On 07/27/2018 11:46 AM, Thomas Huth wrote:
 On 07/27/2018 05:13 PM, Markus Armbruster wrote:
> qtest_qmp_discard_response(...) is shorthand for
> qobject_unref(qtest_qmp(...), except it's not actually shorter.

 But the latter is IMHO harder to read.
>> 
>> Doing things sloppily looks a bit uglier now.  That's a feature.
>> 
>>> Maybe, but then it lends itself well to:
>>>
>>> QObject *rsp = qtest_qmp(...);
>>> qobject_unref(rsp);
>>>
>>> which is where you do insert tests for valid responses.
>>>
 And it might be shorter in the compiled binary (one function call vs. two).
>> 
>> I'd be quite sympathetic to this argument...
>> 
>>> The size of the test binaries is not our biggest concern.
>> 
>> ... outside tests/.
>> 
> Moreover, the presence of these functions encourage sloppy testing.

 Shouldn't we then rather fix the tests to check for valid responses
 instead of replacing this function with harder-to-read code?
>> 
>> I'd welcome such patches, but this series is already pretty long.
>
> Then maybe rather drop this patch from this series, and fix the issues
> in a separate series instead?

Do you insist?

I fail to see how changing

qmp_discard_response("{ 'execute': 'system_reset' }");

to

qobject_unref(qmp("{ 'execute': 'system_reset' }"));

is so awful it would justify demanding I pause my work on libqtest to
first figure out which parts of ignored responses are worth checking,
then code up the checks.

Would you accept

rsp = qmp("{ 'execute': 'system_reset' }"));
qobject_unref(rsp);

?

If none of the above is acceptable to you, then I'll push the crap that
needs to go from libqtest into the crap-using tests, like this:

/* TODO actually test the results and get rid of this */
#define qmp_discard_response(...) qobject_unref(qmp(__VA_ARGS__));

Re: [Qemu-devel] microblaze build failure due to definition clash on riscv

[Michael Clark]

On Thu, Aug 2, 2018 at 3:57 PM, Philippe Mathieu-Daudé 
wrote:

> Oops I just realized I forgot to Cc the QEMU list, doing it now.
>
> On 07/31/2018 07:40 AM, Edgar E. Iglesias wrote:
> > On Mon, Jul 30, 2018 at 03:22:46PM -0300, Philippe Mathieu-Daudé wrote:
> >> Hi, I'm getting this error while building microblaze on riscv host:
> >>
> >>   ...
> >>   CC  disas/microblaze.o
> >> disas/microblaze.c:179:0: error: "REG_SP" redefined [-Werror]
> >>
> >>  #define REG_SP  1 /* stack pointer */
> >>
> >> In file included from /usr/include/signal.h:306:0,
> >>  from include/qemu/osdep.h:101,
> >>  from disas/microblaze.c:36:
> >> /usr/include/sys/ucontext.h:36:0: note: this is the location of the
> >> previous definition
> >>  # define REG_SP 2
> >>
> >> cc1: all warnings being treated as errors
> >> make: *** [rules.mak:69: disas/microblaze.o] Error 1
> >>
> >>
> >> Having /usr/include/sys/ucontext.h:
> >>
> >>  31 #ifdef __USE_MISC
> >>  32 # define NGREG  32
> >>  33
> >>  34 # define REG_PC 0
> >>  35 # define REG_RA 1
> >>  36 # define REG_SP 2
> >>  37 # define REG_TP 4
> >>  38 # define REG_S0 8
> >>  39 # define REG_S1 9
> >>  40 # define REG_A0 10
> >>  41 # define REG_S2 18
> >>  42 # define REG_NARGS 8
> >>
> >> Edgar is it OK to rename REG_* -> MB_REG_*?
> >
> > Yes, no problems with me!
> >
> > Allthough it doesn't seem to be a good idea to have such generic names
> in riscv system header files.
>
> OK this might be a Linux problem indeed, maybe this file lacks some
> #ifdef __riscv (previous to the __USE_MISC?).
>
> I'll wait for the riscv folks before to send a dumb rename patch.
>

It seems to be a generic Linux problem or perhaps even a microblaze problem
in this case, where QEMU microblaze definitions just happen to clash with
system definitions. It depends on which way around you look at the problem.

x86_64 has REG_R8, REG_R9, REG_R10, etc so RISC-V is just following the
Linux scheme.

Indeed RISC-V in QEMU unlike microblaze has this in disas/riscv.c

typedef enum {
rv_ireg_zero,
rv_ireg_ra,
rv_ireg_sp,
rv_ireg_gp,
rv_ireg_tp,
rv_ireg_t0,
rv_ireg_t1,
rv_ireg_t2,
rv_ireg_s0,
rv_ireg_s1,
rv_ireg_a0,
rv_ireg_a1,
rv_ireg_a2,
rv_ireg_a3,
rv_ireg_a4,
rv_ireg_a5,
rv_ireg_a6,
rv_ireg_a7,
rv_ireg_s2,
rv_ireg_s3,
rv_ireg_s4,
rv_ireg_s5,
rv_ireg_s6,
rv_ireg_s7,
rv_ireg_s8,
rv_ireg_s9,
rv_ireg_s10,
rv_ireg_s11,
rv_ireg_t3,
rv_ireg_t4,
rv_ireg_t5,
rv_ireg_t6,
} rv_ireg;

So from that perspective, one could suggest to change microblaze. It will
be a lot harder to change glibc given it is already baked into a large
number of binary images, and they are system headers.

Prefixing the definitions inside the mircoblaze disassembler would cause
the least havoc. Changing system headers in glibc will take a long time to
propagate via the current distros.

Re: [Qemu-devel] microblaze build failure due to definition clash on riscv

[Philippe Mathieu-Daudé]

Oops I just realized I forgot to Cc the QEMU list, doing it now.

On 07/31/2018 07:40 AM, Edgar E. Iglesias wrote:
> On Mon, Jul 30, 2018 at 03:22:46PM -0300, Philippe Mathieu-Daudé wrote:
>> Hi, I'm getting this error while building microblaze on riscv host:
>>
>>   ...
>>   CC  disas/microblaze.o
>> disas/microblaze.c:179:0: error: "REG_SP" redefined [-Werror]
>>
>>  #define REG_SP  1 /* stack pointer */
>>
>> In file included from /usr/include/signal.h:306:0,
>>  from include/qemu/osdep.h:101,
>>  from disas/microblaze.c:36:
>> /usr/include/sys/ucontext.h:36:0: note: this is the location of the
>> previous definition
>>  # define REG_SP 2
>>
>> cc1: all warnings being treated as errors
>> make: *** [rules.mak:69: disas/microblaze.o] Error 1
>>
>>
>> Having /usr/include/sys/ucontext.h:
>>
>>  31 #ifdef __USE_MISC
>>  32 # define NGREG  32
>>  33
>>  34 # define REG_PC 0
>>  35 # define REG_RA 1
>>  36 # define REG_SP 2
>>  37 # define REG_TP 4
>>  38 # define REG_S0 8
>>  39 # define REG_S1 9
>>  40 # define REG_A0 10
>>  41 # define REG_S2 18
>>  42 # define REG_NARGS 8
>>
>> Edgar is it OK to rename REG_* -> MB_REG_*?
> 
> Yes, no problems with me!
> 
> Allthough it doesn't seem to be a good idea to have such generic names in 
> riscv system header files.

OK this might be a Linux problem indeed, maybe this file lacks some
#ifdef __riscv (previous to the __USE_MISC?).

I'll wait for the riscv folks before to send a dumb rename patch.

Regards,

Phil.



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host bridge into separate pci domain

[no-reply]

Hi,

This series failed docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 1533177743-20894-1-git-send-email-whois.zihan.y...@gmail.com
Subject: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host 
bridge into separate pci domain

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
e2cec939da pci_expander_bridge: add start_bus property
082004294c pci_expander_bridge: Add ioport for pxb host bus
3fed4b00b6 pci_expander_bridge: Add config_read callback
bc045b582c i386/acpi-build: describe new pci domain in AML
5dcf56e320 acpi-build: allocate mcfg for pxb-pcie host bridges
61a5c0b2b9 pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

=== OUTPUT BEGIN ===
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-jwuxbpij/src'
  GEN 
/var/tmp/patchew-tester-tmp-jwuxbpij/src/docker-src.2018-08-01-22.53.40.2785/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-jwuxbpij/src/docker-src.2018-08-01-22.53.40.2785/qemu.tar.vroot'...
done.
Checking out files:  37% (2366/6322)   
Checking out files:  38% (2403/6322)   
Checking out files:  39% (2466/6322)   
Checking out files:  40% (2529/6322)   
Checking out files:  41% (2593/6322)   
Checking out files:  42% (2656/6322)   
Checking out files:  43% (2719/6322)   
Checking out files:  44% (2782/6322)   
Checking out files:  45% (2845/6322)   
Checking out files:  46% (2909/6322)   
Checking out files:  47% (2972/6322)   
Checking out files:  48% (3035/6322)   
Checking out files:  49% (3098/6322)   
Checking out files:  50% (3161/6322)   
Checking out files:  51% (3225/6322)   
Checking out files:  52% (3288/6322)   
Checking out files:  53% (3351/6322)   
Checking out files:  54% (3414/6322)   
Checking out files:  55% (3478/6322)   
Checking out files:  56% (3541/6322)   
Checking out files:  57% (3604/6322)   
Checking out files:  58% (3667/6322)   
Checking out files:  59% (3730/6322)   
Checking out files:  60% (3794/6322)   
Checking out files:  61% (3857/6322)   
Checking out files:  62% (3920/6322)   
Checking out files:  63% (3983/6322)   
Checking out files:  64% (4047/6322)   
Checking out files:  65% (4110/6322)   
Checking out files:  66% (4173/6322)   
Checking out files:  67% (4236/6322)   
Checking out files:  68% (4299/6322)   
Checking out files:  69% (4363/6322)   
Checking out files:  70% (4426/6322)   
Checking out files:  71% (4489/6322)   
Checking out files:  72% (4552/6322)   
Checking out files:  73% (4616/6322)   
Checking out files:  74% (4679/6322)   
Checking out files:  75% (4742/6322)   
Checking out files:  76% (4805/6322)   
Checking out files:  77% (4868/6322)   
Checking out files:  78% (4932/6322)   
Checking out files:  79% (4995/6322)   
Checking out files:  80% (5058/6322)   
Checking out files:  81% (5121/6322)   
Checking out files:  82% (5185/6322)   
Checking out files:  83% (5248/6322)   
Checking out files:  84% (5311/6322)   
Checking out files:  85% (5374/6322)   
Checking out files:  86% (5437/6322)   
Checking out files:  87% (5501/6322)   
Checking out files:  88% (5564/6322)   
Checking out files:  89% (5627/6322)   
Checking out files:  89% (5673/6322)   
Checking out files:  90% (5690/6322)   
Checking out files:  91% (5754/6322)   
Checking out files:  92% (5817/6322)   
Checking out files:  93% (5880/6322)   
Checking out files:  94% (5943/6322)   
Checking out files:  95% (6006/6322)   
Checking out files:  96% (6070/6322)   
Checking out files:  97% (6133/6322)   
Checking out files:  98% (6196/6322)   
Checking out files:  99% (6259/6322)   
Checking out files: 100% (6322/6322)   
Checking out files: 100% (6322/6322), done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-jwuxbpij/src/docker-src.2018-08-01-22.53.40.2785/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-jwuxbpij/src/docker-src.2018-08-01-22.53.40.2785/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-mingw in qemu:fedora 
Packages installed:
SDL2-devel-2.0.8-5.fc28.x86_64
bc-1.07.1-5.fc28.x86_64
bison-3.0.4-9.fc28.x86_64
bluez-libs-devel-5.49-3.fc28.x86_64
brlapi-devel-0.6.7-12.fc28.x86_64
bzip2-1.0.6-26.fc28.x86_64
bzip2-devel-1.0.6-26.fc28.x86_64
ccache-3.4.2-2.fc28.x86_64
clang-6.0.0-5.fc28.x86_64
device-mapper-multipath-devel-0.7.4-2.git07e7bd5.fc28.x86_64
findutils-4.6.0-19.fc28.x86_64
flex-2.6.1-7.fc28.x86_64

Re: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host bridge into separate pci domain

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1533177743-20894-1-git-send-email-whois.zihan.y...@gmail.com
Subject: [Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host 
bridge into separate pci domain

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/1533177743-20894-1-git-send-email-whois.zihan.y...@gmail.com -> 
patchew/1533177743-20894-1-git-send-email-whois.zihan.y...@gmail.com
Switched to a new branch 'test'
e2cec939da pci_expander_bridge: add start_bus property
082004294c pci_expander_bridge: Add ioport for pxb host bus
3fed4b00b6 pci_expander_bridge: Add config_read callback
bc045b582c i386/acpi-build: describe new pci domain in AML
5dcf56e320 acpi-build: allocate mcfg for pxb-pcie host bridges
61a5c0b2b9 pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

=== OUTPUT BEGIN ===
Checking PATCH 1/6: pci_expander_bridge: add type TYPE_PXB_PCIE_HOST...
WARNING: line over 80 characters
#92: FILE: hw/pci-bridge/pci_expander_bridge.c:156:
+static void pxb_pcie_host_get_mmcfg_size(Object *obj, Visitor *v, const char 
*name,

ERROR: space prohibited between function name and open parenthesis '('
#188: FILE: hw/pci-bridge/pci_expander_bridge.c:332:
+g_assert (pxb->max_bus >= pxb->bus_nr);

WARNING: line over 80 characters
#207: FILE: hw/pci-bridge/pci_expander_bridge.c:399:
+DEFINE_PROP_UINT16(PROP_PXB_NUMA_NODE, PXBDev, numa_node, 
NUMA_NODE_UNASSIGNED),

WARNING: line over 80 characters
#213: FILE: hw/pci-bridge/pci_expander_bridge.c:405:
+DEFINE_PROP_UINT16(PROP_PXB_NUMA_NODE, PXBDev, numa_node, 
NUMA_NODE_UNASSIGNED),

total: 1 errors, 3 warnings, 211 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/6: acpi-build: allocate mcfg for pxb-pcie host bridges...
ERROR: do not use C99 // comments
#34: FILE: hw/i386/acpi-build.c:94:
+uint8_t bus_nr; // start bus number

ERROR: do not use assignment in if condition
#189: FILE: hw/i386/acpi-build.c:2790:
+if ((mcfg = acpi_get_mcfg()) != NULL) {

ERROR: do not initialise statics to 0 or NULL
#278: FILE: hw/pci-bridge/pci_expander_bridge.c:125:
+static uint64_t pxb_mcfg_hole_size = 0;

WARNING: line over 80 characters
#353: FILE: hw/pci-bridge/pci_expander_bridge.c:351:
+pxb->domain_nr ? pxb_pcie_mcfg_base : 
MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT);

ERROR: braces {} are necessary for all arms of this statement
#357: FILE: hw/pci-bridge/pci_expander_bridge.c:355:
+if (pxb->domain_nr)
[...]

ERROR: braces {} are necessary for all arms of this statement
#366: FILE: hw/pci-bridge/pci_expander_bridge.c:468:
+if (0 == pxb_pcie_mcfg_base)
[...]

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#439: 
new file mode 100644

total: 5 errors, 2 warnings, 399 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 3/6: i386/acpi-build: describe new pci domain in AML...
ERROR: do not use C99 // comments
#28: FILE: hw/i386/acpi-build.c:1879:
+i = 1; // PCI0 is q35 host, pxb starts from 1

WARNING: line over 80 characters
#111: FILE: hw/i386/acpi-build.c:2168:
+aml_append(dev, aml_name_decl("_HID", 
aml_eisaid("PNP0C31")));

total: 1 errors, 1 warnings, 112 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 4/6: pci_expander_bridge: Add config_read callback...
ERROR: line over 90 characters
#43: FILE: hw/pci-bridge/pci_expander_bridge.c:354:
+object_property_add_child(qdev_get_machine(), "pxb-pcie-host[*]", 
OBJECT(ds), NULL);

ERROR: switch and case should be at the same indent
#63: FILE: hw/pci-bridge/pci_expander_bridge.c:435:
+   switch (address) {
+case MCH_HOST_BRIDGE_PCIEXBAR:
[...]
+case MCH_HOST_BRIDGE_PCIEXBAR + 4:
[...]
+case MCH_HOST_BRIDGE_PCIEXBAR + 8:  // Fix me!
[...]
+default:

WARNING: line over 80 characters
#67: FILE: hw/pci-bridge/pci_expander_bridge.c:439:
+val = object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) & 
0x;

ERROR: line 

[Qemu-devel] QEMU 3.0 RC3 mouse problem with Windows 3.1 and NT 4.0

[Programmingkid]

The mouse cursor stops working properly under Windows 3.1 and Windows NT 4.0 
after a few minutes of use. The cursor will want to stay at the very edges of 
the QEMU window. 

[Qemu-devel] [RFC v3 6/6] pci_expander_bridge: add start_bus property

[Zihan Yang]

The former bus_nr property indicates the bus number of pxb-pcie device on
pcie.0 bus, not the Base Bus Number of pxb-pcie host bridge. Use start_bus
property to represent this BBN when building acpi table

Signed-off-by: Zihan Yang 
---
 hw/i386/acpi-build.c| 22 +++---
 hw/pci-bridge/pci_expander_bridge.c | 25 ++---
 include/hw/pci-bridge/pci_expander_bridge.h |  2 +-
 3 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4b6ef78..874e0fa 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -91,7 +91,7 @@ typedef struct AcpiMcfgInfo {
 uint64_t mcfg_base;
 uint32_t mcfg_size;
 uint32_t domain_nr;
-uint8_t bus_nr; // start bus number
+uint8_t start_bus; // start bus number
 struct AcpiMcfgInfo *next;
 } AcpiMcfgInfo;
 
@@ -2129,7 +2129,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 QObject *o;
 PCIBus *bus = NULL;
 uint32_t domain_nr;
-uint8_t bus_nr;
+uint8_t start_bus;
 int index = 0;
 
 pci_host = acpi_get_i386_pci_host();
@@ -2145,12 +2145,12 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 domain_nr = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 
-o = object_property_get_qobject(pci_host, "bus_nr", NULL);
+o = object_property_get_qobject(pci_host, "start_bus", NULL);
 if (!o) {
 /* we are in q35 host */
-bus_nr = 0;
+start_bus = 0;
 } else {
-bus_nr = qnum_get_uint(qobject_to(QNum, o));
+start_bus = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 }
 
@@ -2158,7 +2158,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 if (bus) {
 Aml *scope = aml_scope("PCI%d", index);
 aml_append(scope, aml_name_decl("_SEG", aml_int(domain_nr)));
-aml_append(scope, aml_name_decl("_BBN", aml_int(bus_nr)));
+aml_append(scope, aml_name_decl("_BBN", aml_int(start_bus)));
 /* Scan all PCI buses. Generate tables to support hotplug. */
 build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
 
@@ -2486,8 +2486,8 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
AcpiMcfgInfo *info)
 while (info) {
 mcfg[count].allocation[0].address = cpu_to_le64(info->mcfg_base);
 mcfg[count].allocation[0].pci_segment = cpu_to_le16(info->domain_nr);
-mcfg[count].allocation[0].start_bus_number = info->bus_nr;
-mcfg[count++].allocation[0].end_bus_number = info->bus_nr + \
+mcfg[count].allocation[0].start_bus_number = info->start_bus;
+mcfg[count++].allocation[0].end_bus_number = info->start_bus + \
 PCIE_MMCFG_BUS(info->mcfg_size - 1);
 info = info->next;
 }
@@ -2710,12 +2710,12 @@ static AcpiMcfgInfo *acpi_get_mcfg(void)
 mcfg->mcfg_size = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 
-o = object_property_get_qobject(obj, PROP_PXB_BUS_NR, NULL);
+o = object_property_get_qobject(obj, PROP_PXB_PCIE_START_BUS, NULL);
 if (!o) {
 /* we are in q35 host again */
-mcfg->bus_nr = 0;
+mcfg->start_bus = 0;
 } else {
-mcfg->bus_nr = qnum_get_uint(qobject_to(QNum, o));
+mcfg->start_bus = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 }
 
diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index 38212db..85630ff 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -46,6 +46,7 @@ typedef struct PXBBus {
 #define TYPE_PXB_PCIE_DEVICE "pxb-pcie"
 #define PXB_PCIE_DEV(obj) OBJECT_CHECK(PXBDev, (obj), TYPE_PXB_PCIE_DEVICE)
 
+#define PROP_PXB_BUS_NR "bus_nr"
 #define PROP_PXB_PCIE_MAX_BUS "max_bus"
 #define PROP_PXB_NUMA_NODE "numa_node"
 
@@ -62,8 +63,9 @@ typedef struct PXBDev {
 PXBPCIEHost *pxbhost;
 
 uint32_t domain_nr; /* PCI domain number, non-zero means separate domain */
+uint8_t start_bus;  /* indicates the BBN of pxb-pcie-host bridge */
 uint8_t max_bus;/* max bus number to use(including this one) */
-uint8_t bus_nr;
+uint8_t bus_nr; /* bus number of pxb-pcie device on pcei.0 bus */
 uint16_t numa_node;
 } PXBDev;
 
@@ -137,8 +139,8 @@ static void pxb_pcie_foreach(gpointer data, gpointer 
user_data)
 
 if (pxb->domain_nr > 0) {
 /* only reserve what users ask for to reduce memory cost. Plus one
- * as the interval [bus_nr, max_bus] has (max_bus-bus_nr+1) buses */
-pxb_mcfg_hole_size += ((pxb->max_bus - pxb->bus_nr + 1ULL) * MiB);
+ * as the interval [start_bus, max_bus] has (max_bus-start_bus+1) 
buses */

[Qemu-devel] [RFC v3 4/6] pci_expander_bridge: Add config_read callback

[Zihan Yang]

This allows SeaBIOS to retrieve MCFG base and size when it initializes
pxb host bridges.

A backlink to PXBPCIEHost is added in PXBDev to achieve above goal

Signed-off-by: Zihan Yang 
---
 hw/pci-bridge/pci_expander_bridge.c | 55 +
 include/hw/pci-bridge/pci_expander_bridge.h |  1 +
 2 files changed, 56 insertions(+)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index f50938f..cdfdb90 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -49,11 +49,18 @@ typedef struct PXBBus {
 #define PROP_PXB_PCIE_MAX_BUS "max_bus"
 #define PROP_PXB_NUMA_NODE "numa_node"
 
+typedef struct PXBPCIEHost PXBPCIEHost;
+typedef struct PXBDev PXBDev;
+
 typedef struct PXBDev {
 /*< private >*/
 PCIDevice parent_obj;
 /*< public >*/
 
+/* backlink to PXBPCIEHost, this makes it easier to get
+ * mcfg properties in pxb-pcie-host bridge */
+PXBPCIEHost *pxbhost;
+
 uint32_t domain_nr; /* PCI domain number, non-zero means separate domain */
 uint8_t max_bus;/* max bus number to use(including this one) */
 uint8_t bus_nr;
@@ -342,9 +349,15 @@ static void pxb_dev_realize_common(PCIDevice *dev, bool 
pcie, Error **errp)
 if (pcie) {
 g_assert (pxb->max_bus >= pxb->bus_nr);
 ds = qdev_create(NULL, TYPE_PXB_PCIE_HOST);
+/* attach it under /machine, so that we can resolve a valid path in
+ * object_property_set_link below */
+object_property_add_child(qdev_get_machine(), "pxb-pcie-host[*]", 
OBJECT(ds), NULL);
 
+/* set link and backlink between PXBPCIEHost and PXBDev */
 object_property_set_link(OBJECT(ds), OBJECT(pxb),
  PROP_PXB_PCIE_DEV, errp);
+object_property_set_link(OBJECT(pxb), OBJECT(ds),
+ PROP_PXB_PCIE_HOST, errp);
 
 /* will be overwritten by firmware, but kept for readability */
 qdev_prop_set_uint64(ds, PCIE_HOST_MCFG_BASE,
@@ -413,6 +426,36 @@ static void pxb_dev_exitfn(PCIDevice *pci_dev)
 pxb_dev_list = g_list_remove(pxb_dev_list, pxb);
 }
 
+static uint32_t pxb_pcie_config_read(PCIDevice *d, uint32_t address, int len)
+{
+PXBDev *pxb = convert_to_pxb(d);
+uint32_t val;
+Object *host;
+
+   switch (address) {
+case MCH_HOST_BRIDGE_PCIEXBAR:
+host = object_property_get_link(OBJECT(pxb), PROP_PXB_PCIE_HOST, NULL);
+assert(host);
+val = object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) & 
0x;
+break;
+case MCH_HOST_BRIDGE_PCIEXBAR + 4:
+host = object_property_get_link(OBJECT(pxb), PROP_PXB_PCIE_HOST, NULL);
+assert(host);
+val = (object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) >> 
32) & 0x;
+break;
+case MCH_HOST_BRIDGE_PCIEXBAR + 8:  // Fix me!
+host = object_property_get_link(OBJECT(pxb), PROP_PXB_PCIE_HOST, NULL);
+assert(host);
+val = object_property_get_uint(host, PCIE_HOST_MCFG_SIZE, NULL) & 
0x;
+break;
+default:
+val = pci_default_read_config(d, address, len);
+break;
+}
+
+return val;
+}
+
 static Property pxb_dev_properties[] = {
 /* Note: 0 is not a legal PXB bus number. */
 DEFINE_PROP_UINT8(PROP_PXB_BUS_NR, PXBDev, bus_nr, 0),
@@ -447,6 +490,16 @@ static void pxb_dev_class_init(ObjectClass *klass, void 
*data)
 set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
 }
 
+static void pxb_pcie_dev_initfn(Object *obj)
+{
+PXBDev *pxb = PXB_PCIE_DEV(obj);
+
+/* Add backlink to pxb-pcie-host */
+object_property_add_link(obj, PROP_PXB_PCIE_HOST, TYPE_PXB_PCIE_HOST,
+ (Object **)>pxbhost,
+ qdev_prop_allow_set_link_before_realize, 0, NULL);
+}
+
 static const TypeInfo pxb_dev_info = {
 .name  = TYPE_PXB_DEVICE,
 .parent= TYPE_PCI_DEVICE,
@@ -478,6 +531,7 @@ static void pxb_pcie_dev_class_init(ObjectClass *klass, 
void *data)
 
 k->realize = pxb_pcie_dev_realize;
 k->exit = pxb_dev_exitfn;
+k->config_read = pxb_pcie_config_read;
 k->vendor_id = PCI_VENDOR_ID_REDHAT;
 k->device_id = PCI_DEVICE_ID_REDHAT_PXB_PCIE;
 k->class_id = PCI_CLASS_BRIDGE_HOST;
@@ -492,6 +546,7 @@ static const TypeInfo pxb_pcie_dev_info = {
 .name  = TYPE_PXB_PCIE_DEVICE,
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(PXBDev),
+.instance_init = pxb_pcie_dev_initfn,
 .class_init= pxb_pcie_dev_class_init,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
diff --git a/include/hw/pci-bridge/pci_expander_bridge.h 
b/include/hw/pci-bridge/pci_expander_bridge.h
index 870c4cd..1119210 100644
--- a/include/hw/pci-bridge/pci_expander_bridge.h
+++ b/include/hw/pci-bridge/pci_expander_bridge.h
@@ -2,6 +2,7 @@
 #define HW_PCI_EXPANDER_H
 
 #define PROP_PXB_PCIE_DEV "pxbdev"

[Qemu-devel] [RFC v3 2/6] acpi-build: allocate mcfg for pxb-pcie host bridges

[Zihan Yang]

Allocate new segment for pxb-pcie host bridges in MCFG table, and reserve
corresponding MCFG space for them. This allows user-defined pxb-pcie
host bridges to be placed in different pci domain than q35 host.

The pci_host_bridges list is changed to be tail list to ensure the q35 host
is always the first element when traversing the list, because q35 host is
inserted beofre pxb-pcie hosts

Signed-off-by: Zihan Yang 
---
 hw/i386/acpi-build.c| 115 +++-
 hw/i386/pc.c|  14 +++-
 hw/pci-bridge/pci_expander_bridge.c |  57 ++
 hw/pci-host/q35.c   |   2 +
 hw/pci/pci.c|   9 ++-
 include/hw/i386/pc.h|   1 +
 include/hw/pci-bridge/pci_expander_bridge.h |  11 +++
 include/hw/pci-host/q35.h   |   1 +
 include/hw/pci/pci_host.h   |   2 +-
 9 files changed, 168 insertions(+), 44 deletions(-)
 create mode 100644 include/hw/pci-bridge/pci_expander_bridge.h

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 9e8350c..30bd0d5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -55,6 +55,7 @@
 #include "hw/i386/ich9.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/pci-host/q35.h"
+#include "hw/pci-bridge/pci_expander_bridge.h"
 #include "hw/i386/x86-iommu.h"
 
 #include "hw/acpi/aml-build.h"
@@ -89,6 +90,9 @@
 typedef struct AcpiMcfgInfo {
 uint64_t mcfg_base;
 uint32_t mcfg_size;
+uint32_t domain_nr;
+uint8_t bus_nr; // start bus number
+struct AcpiMcfgInfo *next;
 } AcpiMcfgInfo;
 
 typedef struct AcpiPmInfo {
@@ -2427,14 +2431,16 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
AcpiMcfgInfo *info)
 {
 AcpiTableMcfg *mcfg;
 const char *sig;
-int len = sizeof(*mcfg) + 1 * sizeof(mcfg->allocation[0]);
+int len, count = 0;
+AcpiMcfgInfo *cfg = info;
+
+while (cfg) {
+++count;
+cfg = cfg->next;
+}
+len = sizeof(*mcfg) + count * sizeof(mcfg->allocation[0]);
 
 mcfg = acpi_data_push(table_data, len);
-mcfg->allocation[0].address = cpu_to_le64(info->mcfg_base);
-/* Only a single allocation so no need to play with segments */
-mcfg->allocation[0].pci_segment = cpu_to_le16(0);
-mcfg->allocation[0].start_bus_number = 0;
-mcfg->allocation[0].end_bus_number = PCIE_MMCFG_BUS(info->mcfg_size - 1);
 
 /* MCFG is used for ECAM which can be enabled or disabled by guest.
  * To avoid table size changes (which create migration issues),
@@ -2448,6 +2454,16 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
AcpiMcfgInfo *info)
 } else {
 sig = "MCFG";
 }
+
+while (info) {
+mcfg[count].allocation[0].address = cpu_to_le64(info->mcfg_base);
+mcfg[count].allocation[0].pci_segment = cpu_to_le16(info->domain_nr);
+mcfg[count].allocation[0].start_bus_number = info->bus_nr;
+mcfg[count++].allocation[0].end_bus_number = info->bus_nr + \
+PCIE_MMCFG_BUS(info->mcfg_size - 1);
+info = info->next;
+}
+
 build_header(linker, table_data, (void *)mcfg, sig, len, 1, NULL, NULL);
 }
 
@@ -2602,26 +2618,83 @@ struct AcpiBuildState {
 MemoryRegion *linker_mr;
 } AcpiBuildState;
 
-static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
+static inline void cleanup_mcfg(AcpiMcfgInfo *mcfg)
+{
+AcpiMcfgInfo *tmp;
+while (mcfg) {
+tmp = mcfg->next;
+g_free(mcfg);
+mcfg = tmp;
+}
+}
+
+static AcpiMcfgInfo *acpi_get_mcfg(void)
 {
 Object *pci_host;
 QObject *o;
+uint32_t domain_nr;
+AcpiMcfgInfo *head = NULL, *tail, *mcfg;
 
 pci_host = acpi_get_i386_pci_host();
 g_assert(pci_host);
 
-o = object_property_get_qobject(pci_host, PCIE_HOST_MCFG_BASE, NULL);
-if (!o) {
-return false;
+while (pci_host) {
+/* pxb-pcie-hosts does not have domain_nr property, but a link
+ * to PXBDev. We first try to get pxbdev property, if NULL,
+ * then it is q35 host, otherwise it is pxb-pcie-host */
+Object *obj = object_property_get_link(pci_host,
+   PROP_PXB_PCIE_DEV, NULL);
+if (!obj) {
+/* we are in q35 host */
+obj = pci_host;
+}
+o = object_property_get_qobject(obj, PROP_PXB_PCIE_DOMAIN_NR, NULL);
+assert(o);
+domain_nr = qnum_get_uint(qobject_to(QNum, o));
+qobject_unref(o);
+
+/* Skip bridges that reside in the same domain with q35 host.
+ * Q35 always stays in pci domain 0, and is the first element
+ * in the pci_host_bridges list */
+if (head && domain_nr == 0) {
+pci_host = OBJECT(QTAILQ_NEXT(PCI_HOST_BRIDGE(pci_host), next));
+continue;
+}
+
+mcfg = g_new0(AcpiMcfgInfo, 1);
+mcfg->next = NULL;
+if (!head) {
+tail = 

[Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host bridge into separate pci domain

[Zihan Yang]

(Forgot about the cc, repost it here)

NOTE: This patch set relies on seabios change. Unfortunately, I haven't got
it fully working in seabios, but I still post them here because patches
involve some port layout change to be reviewed, and it has been a long delay
since my last version. I'm trying to catch things up recently.

If you would like to see current status of seabios part, please refer to
https://mail.coreboot.org/pipermail/seabios/2018-August/012385.html

Currently only q35 host bridge is allocated an item in MCFG table, all pxb
host bridges stay within pci domain 0. This series of patches put each pxb
host bridge in separate pci domain, allocating a new MCFG table item for it.

Users can configure whether to put pxb host bridge into separate domain
by passing parameter domain_nr to pxb pcie device. start_bus property
indicates the Base Bus Number(BBN) of the pxb host bridge. Another property
max_bus specifies the maximum desired bus numbers to reduce MCFG space cost.
Example command is

-device pxb-pcie,id=br3,bus="pcie.0",start_bus=0,domain_nr=1,max_bus=15

Then this pxb-pcie host bridge is placed at pci domain 1, and only reserve
(15+1)=16 buses, which is much smaller than the default 256 buses.

The pxb host does not have an mch in it, as q35 host already has one. All
pxb host bridges just serve as expander bridges in QEMU, which makes them
a little simpler than q35 host bridge.

v3 <- v2:
- Replace duplicate properties in pxb pcie host with link property to PXBDev
- Allow seabios to access config space and data space of expander bridge
  through a different ioport, because 0xcf8 is attached only to sysbus.
- Add a new property start_bus to indicate the BBN of pxb host bridge. The
  bus_nr property is used as the bus number of pxb-pcie device on pcie.0 bus

v2 <- v1:
- Allow user to configure whether to put pxb-pcie into seperate domain
- Add AML description part of each host bridge
- Modify the location of MCFG space to between RAM hotplug and pci hole64



Zihan Yang (6):
  pci_expander_bridge: add type TYPE_PXB_PCIE_HOST
  acpi-build: allocate mcfg for pxb-pcie host bridges
  i386/acpi-build: describe new pci domain in AML
  pci_expander_bridge: Add config_read callback
  pci_expander_bridge: Add ioport for pxb host bus
  pci_expander_bridge: add start_bus property

 hw/i386/acpi-build.c| 193 +--
 hw/i386/pc.c|  14 +-
 hw/pci-bridge/pci_expander_bridge.c | 229 +++-
 hw/pci-host/q35.c   |   2 +
 hw/pci/pci.c|   9 +-
 include/hw/i386/pc.h|   1 +
 include/hw/pci-bridge/pci_expander_bridge.h |  15 ++
 include/hw/pci-host/q35.h   |   1 +
 include/hw/pci/pci_host.h   |   2 +-
 9 files changed, 406 insertions(+), 60 deletions(-)
 create mode 100644 include/hw/pci-bridge/pci_expander_bridge.h

-- 
2.7.4

[Qemu-devel] [RFC v3 5/6] pci_expander_bridge: Add ioport for pxb host bus

[Zihan Yang]

This enables seabios to read config file in pxb host bus other than sysbus

Signed-off-by: Zihan Yang 
---
 hw/pci-bridge/pci_expander_bridge.c | 15 +++
 include/hw/pci-bridge/pci_expander_bridge.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index cdfdb90..38212db 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -226,6 +226,20 @@ static void pxb_pcie_host_initfn(Object *obj)
  qdev_prop_allow_set_link_before_realize, 0, NULL);
 }
 
+static void pxb_pcie_host_realize(DeviceState *dev, Error **errp)
+{
+PCIHostState *pci = PCI_HOST_BRIDGE(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+// FIX ME! Use specific port number for pxb-pcie host bridge, not scalable!
+/* port layout is | pxb1_cmd | pxb1_data | pxb2_cmd | pxb2_data | ... | */
+sysbus_add_io(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_ADDR_BASE, >conf_mem);
+sysbus_init_ioports(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_ADDR_BASE + 
g_list_length(pxb_dev_list) * 8, 4);
+
+sysbus_add_io(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_DATA_BASE, >data_mem);
+sysbus_init_ioports(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_DATA_BASE + 
g_list_length(pxb_dev_list) * 8, 4);
+}
+
 static Property pxb_pcie_host_props[] = {
 DEFINE_PROP_UINT64(PCIE_HOST_MCFG_BASE, PXBPCIEHost, parent_obj.base_addr,
 PCIE_BASE_ADDR_UNMAPPED),
@@ -254,6 +268,7 @@ static void pxb_pcie_host_class_init(ObjectClass *class, 
void *data)
 
 dc->fw_name = "pcie";
 dc->props = pxb_pcie_host_props;
+dc->realize = pxb_pcie_host_realize;
 /* Reason: Internal part of the pxb/pxb-pcie device, not usable by itself 
*/
 dc->user_creatable = false;
 sbc->explicit_ofw_unit_address = pxb_host_ofw_unit_address;
diff --git a/include/hw/pci-bridge/pci_expander_bridge.h 
b/include/hw/pci-bridge/pci_expander_bridge.h
index 1119210..e6d3b67 100644
--- a/include/hw/pci-bridge/pci_expander_bridge.h
+++ b/include/hw/pci-bridge/pci_expander_bridge.h
@@ -7,6 +7,9 @@
 #define PROP_PXB_PCIE_DOMAIN_NR "domain_nr"
 #define PROP_PXB_BUS_NR "bus_nr"
 
+#define PXB_PCIE_HOST_BRIDGE_CONFIG_ADDR_BASE 0x1000
+#define PXB_PCIE_HOST_BRIDGE_CONFIG_DATA_BASE 0x1004
+
 uint64_t pxb_pcie_mcfg_hole(void);
 
 #endif
-- 
2.7.4

[Qemu-devel] [RFC v3 1/6] pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

[Zihan Yang]

The inner host bridge created by pxb-pcie is TYPE_PXB_PCI_HOST by default,
change it to a new type TYPE_PXB_PCIE_HOST to better utilize ECAM of PCIe

Signed-off-by: Zihan Yang 
---
 hw/pci-bridge/pci_expander_bridge.c | 127 ++--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index e62de42..6dd38de 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -15,10 +15,12 @@
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_host.h"
+#include "hw/pci/pcie_host.h"
 #include "hw/pci/pci_bridge.h"
 #include "qemu/range.h"
 #include "qemu/error-report.h"
 #include "sysemu/numa.h"
+#include "qapi/visitor.h"
 
 #define TYPE_PXB_BUS "pxb-bus"
 #define PXB_BUS(obj) OBJECT_CHECK(PXBBus, (obj), TYPE_PXB_BUS)
@@ -40,11 +42,20 @@ typedef struct PXBBus {
 #define TYPE_PXB_PCIE_DEVICE "pxb-pcie"
 #define PXB_PCIE_DEV(obj) OBJECT_CHECK(PXBDev, (obj), TYPE_PXB_PCIE_DEVICE)
 
+#define PROP_PXB_PCIE_DEV "pxbdev"
+
+#define PROP_PXB_PCIE_DOMAIN_NR "domain_nr"
+#define PROP_PXB_PCIE_MAX_BUS "max_bus"
+#define PROP_PXB_BUS_NR "bus_nr"
+#define PROP_PXB_NUMA_NODE "numa_node"
+
 typedef struct PXBDev {
 /*< private >*/
 PCIDevice parent_obj;
 /*< public >*/
 
+uint32_t domain_nr; /* PCI domain number, non-zero means separate domain */
+uint8_t max_bus;/* max bus number to use(including this one) */
 uint8_t bus_nr;
 uint16_t numa_node;
 } PXBDev;
@@ -58,6 +69,16 @@ static PXBDev *convert_to_pxb(PCIDevice *dev)
 static GList *pxb_dev_list;
 
 #define TYPE_PXB_HOST "pxb-host"
+#define TYPE_PXB_PCIE_HOST "pxb-pcie-host"
+#define PXB_PCIE_HOST_DEVICE(obj) \
+ OBJECT_CHECK(PXBPCIEHost, (obj), TYPE_PXB_PCIE_HOST)
+
+typedef struct PXBPCIEHost {
+PCIExpressHost parent_obj;
+
+/* pointers to PXBDev */
+PXBDev *pxbdev;
+} PXBPCIEHost;
 
 static int pxb_bus_num(PCIBus *bus)
 {
@@ -111,6 +132,35 @@ static const char *pxb_host_root_bus_path(PCIHostState 
*host_bridge,
 return bus->bus_path;
 }
 
+/* Use a dedicated function for PCIe since pxb-host does
+ * not have a domain_nr field */
+static const char *pxb_pcie_host_root_bus_path(PCIHostState *host_bridge,
+  PCIBus *rootbus)
+{
+if (!pci_bus_is_express(rootbus)) {
+/* pxb-pcie-host cannot reside on a PCI bus */
+return NULL;
+}
+PXBBus *bus = PXB_PCIE_BUS(rootbus);
+
+/* get the pointer to PXBDev */
+Object *obj = object_property_get_link(OBJECT(host_bridge),
+   PROP_PXB_PCIE_DEV, NULL);
+
+snprintf(bus->bus_path, 8, "%04lx:%02x",
+ object_property_get_uint(obj, PROP_PXB_PCIE_DOMAIN_NR, NULL),
+ pxb_bus_num(rootbus));
+return bus->bus_path;
+}
+
+static void pxb_pcie_host_get_mmcfg_size(Object *obj, Visitor *v, const char 
*name,
+void *opaque, Error **errp)
+{
+PCIExpressHost *e = PCIE_HOST_BRIDGE(obj);
+
+visit_type_uint64(v, name, >size, errp);
+}
+
 static char *pxb_host_ofw_unit_address(const SysBusDevice *dev)
 {
 const PCIHostState *pxb_host;
@@ -142,6 +192,31 @@ static char *pxb_host_ofw_unit_address(const SysBusDevice 
*dev)
 return NULL;
 }
 
+static void pxb_pcie_host_initfn(Object *obj)
+{
+PXBPCIEHost *s = PXB_PCIE_HOST_DEVICE(obj);
+PCIHostState *phb = PCI_HOST_BRIDGE(obj);
+
+memory_region_init_io(>conf_mem, obj, _host_conf_le_ops, phb,
+  "pci-conf-idx", 4);
+memory_region_init_io(>data_mem, obj, _host_data_le_ops, phb,
+  "pci-conf-data", 4);
+
+object_property_add(obj, PCIE_HOST_MCFG_SIZE, "uint64",
+ pxb_pcie_host_get_mmcfg_size,
+ NULL, NULL, NULL, NULL);
+
+object_property_add_link(obj, PROP_PXB_PCIE_DEV, TYPE_PXB_PCIE_DEVICE,
+ (Object **)>pxbdev,
+ qdev_prop_allow_set_link_before_realize, 0, NULL);
+}
+
+static Property pxb_pcie_host_props[] = {
+DEFINE_PROP_UINT64(PCIE_HOST_MCFG_BASE, PXBPCIEHost, parent_obj.base_addr,
+PCIE_BASE_ADDR_UNMAPPED),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void pxb_host_class_init(ObjectClass *class, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(class);
@@ -155,12 +230,34 @@ static void pxb_host_class_init(ObjectClass *class, void 
*data)
 hc->root_bus_path = pxb_host_root_bus_path;
 }
 
+static void pxb_pcie_host_class_init(ObjectClass *class, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(class);
+SysBusDeviceClass *sbc = SYS_BUS_DEVICE_CLASS(class);
+PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(class);
+
+dc->fw_name = "pcie";
+dc->props = pxb_pcie_host_props;
+/* Reason: Internal part of the pxb/pxb-pcie device, not usable by itself 
*/
+dc->user_creatable = false;
+ 

[Qemu-devel] [RFC v3 6/6] pci_expander_bridge: add start_bus property

[Zihan Yang]

The former bus_nr property indicates the bus number of pxb-pcie device on
pcie.0 bus, not the Base Bus Number of pxb-pcie host bridge. Use start_bus
property to represent this BBN when building acpi table

Signed-off-by: Zihan Yang 
---
 hw/i386/acpi-build.c| 22 +++---
 hw/pci-bridge/pci_expander_bridge.c | 25 ++---
 include/hw/pci-bridge/pci_expander_bridge.h |  2 +-
 3 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4b6ef78..874e0fa 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -91,7 +91,7 @@ typedef struct AcpiMcfgInfo {
 uint64_t mcfg_base;
 uint32_t mcfg_size;
 uint32_t domain_nr;
-uint8_t bus_nr; // start bus number
+uint8_t start_bus; // start bus number
 struct AcpiMcfgInfo *next;
 } AcpiMcfgInfo;
 
@@ -2129,7 +2129,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 QObject *o;
 PCIBus *bus = NULL;
 uint32_t domain_nr;
-uint8_t bus_nr;
+uint8_t start_bus;
 int index = 0;
 
 pci_host = acpi_get_i386_pci_host();
@@ -2145,12 +2145,12 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 domain_nr = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 
-o = object_property_get_qobject(pci_host, "bus_nr", NULL);
+o = object_property_get_qobject(pci_host, "start_bus", NULL);
 if (!o) {
 /* we are in q35 host */
-bus_nr = 0;
+start_bus = 0;
 } else {
-bus_nr = qnum_get_uint(qobject_to(QNum, o));
+start_bus = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 }
 
@@ -2158,7 +2158,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 if (bus) {
 Aml *scope = aml_scope("PCI%d", index);
 aml_append(scope, aml_name_decl("_SEG", aml_int(domain_nr)));
-aml_append(scope, aml_name_decl("_BBN", aml_int(bus_nr)));
+aml_append(scope, aml_name_decl("_BBN", aml_int(start_bus)));
 /* Scan all PCI buses. Generate tables to support hotplug. */
 build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
 
@@ -2486,8 +2486,8 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
AcpiMcfgInfo *info)
 while (info) {
 mcfg[count].allocation[0].address = cpu_to_le64(info->mcfg_base);
 mcfg[count].allocation[0].pci_segment = cpu_to_le16(info->domain_nr);
-mcfg[count].allocation[0].start_bus_number = info->bus_nr;
-mcfg[count++].allocation[0].end_bus_number = info->bus_nr + \
+mcfg[count].allocation[0].start_bus_number = info->start_bus;
+mcfg[count++].allocation[0].end_bus_number = info->start_bus + \
 PCIE_MMCFG_BUS(info->mcfg_size - 1);
 info = info->next;
 }
@@ -2710,12 +2710,12 @@ static AcpiMcfgInfo *acpi_get_mcfg(void)
 mcfg->mcfg_size = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 
-o = object_property_get_qobject(obj, PROP_PXB_BUS_NR, NULL);
+o = object_property_get_qobject(obj, PROP_PXB_PCIE_START_BUS, NULL);
 if (!o) {
 /* we are in q35 host again */
-mcfg->bus_nr = 0;
+mcfg->start_bus = 0;
 } else {
-mcfg->bus_nr = qnum_get_uint(qobject_to(QNum, o));
+mcfg->start_bus = qnum_get_uint(qobject_to(QNum, o));
 qobject_unref(o);
 }
 
diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index 38212db..85630ff 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -46,6 +46,7 @@ typedef struct PXBBus {
 #define TYPE_PXB_PCIE_DEVICE "pxb-pcie"
 #define PXB_PCIE_DEV(obj) OBJECT_CHECK(PXBDev, (obj), TYPE_PXB_PCIE_DEVICE)
 
+#define PROP_PXB_BUS_NR "bus_nr"
 #define PROP_PXB_PCIE_MAX_BUS "max_bus"
 #define PROP_PXB_NUMA_NODE "numa_node"
 
@@ -62,8 +63,9 @@ typedef struct PXBDev {
 PXBPCIEHost *pxbhost;
 
 uint32_t domain_nr; /* PCI domain number, non-zero means separate domain */
+uint8_t start_bus;  /* indicates the BBN of pxb-pcie-host bridge */
 uint8_t max_bus;/* max bus number to use(including this one) */
-uint8_t bus_nr;
+uint8_t bus_nr; /* bus number of pxb-pcie device on pcei.0 bus */
 uint16_t numa_node;
 } PXBDev;
 
@@ -137,8 +139,8 @@ static void pxb_pcie_foreach(gpointer data, gpointer 
user_data)
 
 if (pxb->domain_nr > 0) {
 /* only reserve what users ask for to reduce memory cost. Plus one
- * as the interval [bus_nr, max_bus] has (max_bus-bus_nr+1) buses */
-pxb_mcfg_hole_size += ((pxb->max_bus - pxb->bus_nr + 1ULL) * MiB);
+ * as the interval [start_bus, max_bus] has (max_bus-start_bus+1) 
buses */

[Qemu-devel] [RFC v3 1/6] pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

[Zihan Yang]

The inner host bridge created by pxb-pcie is TYPE_PXB_PCI_HOST by default,
change it to a new type TYPE_PXB_PCIE_HOST to better utilize ECAM of PCIe

Signed-off-by: Zihan Yang 
---
 hw/pci-bridge/pci_expander_bridge.c | 127 ++--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index e62de42..6dd38de 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -15,10 +15,12 @@
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_host.h"
+#include "hw/pci/pcie_host.h"
 #include "hw/pci/pci_bridge.h"
 #include "qemu/range.h"
 #include "qemu/error-report.h"
 #include "sysemu/numa.h"
+#include "qapi/visitor.h"
 
 #define TYPE_PXB_BUS "pxb-bus"
 #define PXB_BUS(obj) OBJECT_CHECK(PXBBus, (obj), TYPE_PXB_BUS)
@@ -40,11 +42,20 @@ typedef struct PXBBus {
 #define TYPE_PXB_PCIE_DEVICE "pxb-pcie"
 #define PXB_PCIE_DEV(obj) OBJECT_CHECK(PXBDev, (obj), TYPE_PXB_PCIE_DEVICE)
 
+#define PROP_PXB_PCIE_DEV "pxbdev"
+
+#define PROP_PXB_PCIE_DOMAIN_NR "domain_nr"
+#define PROP_PXB_PCIE_MAX_BUS "max_bus"
+#define PROP_PXB_BUS_NR "bus_nr"
+#define PROP_PXB_NUMA_NODE "numa_node"
+
 typedef struct PXBDev {
 /*< private >*/
 PCIDevice parent_obj;
 /*< public >*/
 
+uint32_t domain_nr; /* PCI domain number, non-zero means separate domain */
+uint8_t max_bus;/* max bus number to use(including this one) */
 uint8_t bus_nr;
 uint16_t numa_node;
 } PXBDev;
@@ -58,6 +69,16 @@ static PXBDev *convert_to_pxb(PCIDevice *dev)
 static GList *pxb_dev_list;
 
 #define TYPE_PXB_HOST "pxb-host"
+#define TYPE_PXB_PCIE_HOST "pxb-pcie-host"
+#define PXB_PCIE_HOST_DEVICE(obj) \
+ OBJECT_CHECK(PXBPCIEHost, (obj), TYPE_PXB_PCIE_HOST)
+
+typedef struct PXBPCIEHost {
+PCIExpressHost parent_obj;
+
+/* pointers to PXBDev */
+PXBDev *pxbdev;
+} PXBPCIEHost;
 
 static int pxb_bus_num(PCIBus *bus)
 {
@@ -111,6 +132,35 @@ static const char *pxb_host_root_bus_path(PCIHostState 
*host_bridge,
 return bus->bus_path;
 }
 
+/* Use a dedicated function for PCIe since pxb-host does
+ * not have a domain_nr field */
+static const char *pxb_pcie_host_root_bus_path(PCIHostState *host_bridge,
+  PCIBus *rootbus)
+{
+if (!pci_bus_is_express(rootbus)) {
+/* pxb-pcie-host cannot reside on a PCI bus */
+return NULL;
+}
+PXBBus *bus = PXB_PCIE_BUS(rootbus);
+
+/* get the pointer to PXBDev */
+Object *obj = object_property_get_link(OBJECT(host_bridge),
+   PROP_PXB_PCIE_DEV, NULL);
+
+snprintf(bus->bus_path, 8, "%04lx:%02x",
+ object_property_get_uint(obj, PROP_PXB_PCIE_DOMAIN_NR, NULL),
+ pxb_bus_num(rootbus));
+return bus->bus_path;
+}
+
+static void pxb_pcie_host_get_mmcfg_size(Object *obj, Visitor *v, const char 
*name,
+void *opaque, Error **errp)
+{
+PCIExpressHost *e = PCIE_HOST_BRIDGE(obj);
+
+visit_type_uint64(v, name, >size, errp);
+}
+
 static char *pxb_host_ofw_unit_address(const SysBusDevice *dev)
 {
 const PCIHostState *pxb_host;
@@ -142,6 +192,31 @@ static char *pxb_host_ofw_unit_address(const SysBusDevice 
*dev)
 return NULL;
 }
 
+static void pxb_pcie_host_initfn(Object *obj)
+{
+PXBPCIEHost *s = PXB_PCIE_HOST_DEVICE(obj);
+PCIHostState *phb = PCI_HOST_BRIDGE(obj);
+
+memory_region_init_io(>conf_mem, obj, _host_conf_le_ops, phb,
+  "pci-conf-idx", 4);
+memory_region_init_io(>data_mem, obj, _host_data_le_ops, phb,
+  "pci-conf-data", 4);
+
+object_property_add(obj, PCIE_HOST_MCFG_SIZE, "uint64",
+ pxb_pcie_host_get_mmcfg_size,
+ NULL, NULL, NULL, NULL);
+
+object_property_add_link(obj, PROP_PXB_PCIE_DEV, TYPE_PXB_PCIE_DEVICE,
+ (Object **)>pxbdev,
+ qdev_prop_allow_set_link_before_realize, 0, NULL);
+}
+
+static Property pxb_pcie_host_props[] = {
+DEFINE_PROP_UINT64(PCIE_HOST_MCFG_BASE, PXBPCIEHost, parent_obj.base_addr,
+PCIE_BASE_ADDR_UNMAPPED),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void pxb_host_class_init(ObjectClass *class, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(class);
@@ -155,12 +230,34 @@ static void pxb_host_class_init(ObjectClass *class, void 
*data)
 hc->root_bus_path = pxb_host_root_bus_path;
 }
 
+static void pxb_pcie_host_class_init(ObjectClass *class, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(class);
+SysBusDeviceClass *sbc = SYS_BUS_DEVICE_CLASS(class);
+PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(class);
+
+dc->fw_name = "pcie";
+dc->props = pxb_pcie_host_props;
+/* Reason: Internal part of the pxb/pxb-pcie device, not usable by itself 
*/
+dc->user_creatable = false;
+ 

[Qemu-devel] [RFC v3 5/6] pci_expander_bridge: Add ioport for pxb host bus

[Zihan Yang]

This enables seabios to read config file in pxb host bus other than sysbus

Signed-off-by: Zihan Yang 
---
 hw/pci-bridge/pci_expander_bridge.c | 15 +++
 include/hw/pci-bridge/pci_expander_bridge.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index cdfdb90..38212db 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -226,6 +226,20 @@ static void pxb_pcie_host_initfn(Object *obj)
  qdev_prop_allow_set_link_before_realize, 0, NULL);
 }
 
+static void pxb_pcie_host_realize(DeviceState *dev, Error **errp)
+{
+PCIHostState *pci = PCI_HOST_BRIDGE(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+// FIX ME! Use specific port number for pxb-pcie host bridge, not scalable!
+/* port layout is | pxb1_cmd | pxb1_data | pxb2_cmd | pxb2_data | ... | */
+sysbus_add_io(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_ADDR_BASE, >conf_mem);
+sysbus_init_ioports(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_ADDR_BASE + 
g_list_length(pxb_dev_list) * 8, 4);
+
+sysbus_add_io(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_DATA_BASE, >data_mem);
+sysbus_init_ioports(sbd, PXB_PCIE_HOST_BRIDGE_CONFIG_DATA_BASE + 
g_list_length(pxb_dev_list) * 8, 4);
+}
+
 static Property pxb_pcie_host_props[] = {
 DEFINE_PROP_UINT64(PCIE_HOST_MCFG_BASE, PXBPCIEHost, parent_obj.base_addr,
 PCIE_BASE_ADDR_UNMAPPED),
@@ -254,6 +268,7 @@ static void pxb_pcie_host_class_init(ObjectClass *class, 
void *data)
 
 dc->fw_name = "pcie";
 dc->props = pxb_pcie_host_props;
+dc->realize = pxb_pcie_host_realize;
 /* Reason: Internal part of the pxb/pxb-pcie device, not usable by itself 
*/
 dc->user_creatable = false;
 sbc->explicit_ofw_unit_address = pxb_host_ofw_unit_address;
diff --git a/include/hw/pci-bridge/pci_expander_bridge.h 
b/include/hw/pci-bridge/pci_expander_bridge.h
index 1119210..e6d3b67 100644
--- a/include/hw/pci-bridge/pci_expander_bridge.h
+++ b/include/hw/pci-bridge/pci_expander_bridge.h
@@ -7,6 +7,9 @@
 #define PROP_PXB_PCIE_DOMAIN_NR "domain_nr"
 #define PROP_PXB_BUS_NR "bus_nr"
 
+#define PXB_PCIE_HOST_BRIDGE_CONFIG_ADDR_BASE 0x1000
+#define PXB_PCIE_HOST_BRIDGE_CONFIG_DATA_BASE 0x1004
+
 uint64_t pxb_pcie_mcfg_hole(void);
 
 #endif
-- 
2.7.4

[Qemu-devel] [RFC v3 4/6] pci_expander_bridge: Add config_read callback

[Zihan Yang]

This allows SeaBIOS to retrieve MCFG base and size when it initializes
pxb host bridges.

A backlink to PXBPCIEHost is added in PXBDev to achieve above goal

Signed-off-by: Zihan Yang 
---
 hw/pci-bridge/pci_expander_bridge.c | 55 +
 include/hw/pci-bridge/pci_expander_bridge.h |  1 +
 2 files changed, 56 insertions(+)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index f50938f..cdfdb90 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -49,11 +49,18 @@ typedef struct PXBBus {
 #define PROP_PXB_PCIE_MAX_BUS "max_bus"
 #define PROP_PXB_NUMA_NODE "numa_node"
 
+typedef struct PXBPCIEHost PXBPCIEHost;
+typedef struct PXBDev PXBDev;
+
 typedef struct PXBDev {
 /*< private >*/
 PCIDevice parent_obj;
 /*< public >*/
 
+/* backlink to PXBPCIEHost, this makes it easier to get
+ * mcfg properties in pxb-pcie-host bridge */
+PXBPCIEHost *pxbhost;
+
 uint32_t domain_nr; /* PCI domain number, non-zero means separate domain */
 uint8_t max_bus;/* max bus number to use(including this one) */
 uint8_t bus_nr;
@@ -342,9 +349,15 @@ static void pxb_dev_realize_common(PCIDevice *dev, bool 
pcie, Error **errp)
 if (pcie) {
 g_assert (pxb->max_bus >= pxb->bus_nr);
 ds = qdev_create(NULL, TYPE_PXB_PCIE_HOST);
+/* attach it under /machine, so that we can resolve a valid path in
+ * object_property_set_link below */
+object_property_add_child(qdev_get_machine(), "pxb-pcie-host[*]", 
OBJECT(ds), NULL);
 
+/* set link and backlink between PXBPCIEHost and PXBDev */
 object_property_set_link(OBJECT(ds), OBJECT(pxb),
  PROP_PXB_PCIE_DEV, errp);
+object_property_set_link(OBJECT(pxb), OBJECT(ds),
+ PROP_PXB_PCIE_HOST, errp);
 
 /* will be overwritten by firmware, but kept for readability */
 qdev_prop_set_uint64(ds, PCIE_HOST_MCFG_BASE,
@@ -413,6 +426,36 @@ static void pxb_dev_exitfn(PCIDevice *pci_dev)
 pxb_dev_list = g_list_remove(pxb_dev_list, pxb);
 }
 
+static uint32_t pxb_pcie_config_read(PCIDevice *d, uint32_t address, int len)
+{
+PXBDev *pxb = convert_to_pxb(d);
+uint32_t val;
+Object *host;
+
+   switch (address) {
+case MCH_HOST_BRIDGE_PCIEXBAR:
+host = object_property_get_link(OBJECT(pxb), PROP_PXB_PCIE_HOST, NULL);
+assert(host);
+val = object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) & 
0x;
+break;
+case MCH_HOST_BRIDGE_PCIEXBAR + 4:
+host = object_property_get_link(OBJECT(pxb), PROP_PXB_PCIE_HOST, NULL);
+assert(host);
+val = (object_property_get_uint(host, PCIE_HOST_MCFG_BASE, NULL) >> 
32) & 0x;
+break;
+case MCH_HOST_BRIDGE_PCIEXBAR + 8:  // Fix me!
+host = object_property_get_link(OBJECT(pxb), PROP_PXB_PCIE_HOST, NULL);
+assert(host);
+val = object_property_get_uint(host, PCIE_HOST_MCFG_SIZE, NULL) & 
0x;
+break;
+default:
+val = pci_default_read_config(d, address, len);
+break;
+}
+
+return val;
+}
+
 static Property pxb_dev_properties[] = {
 /* Note: 0 is not a legal PXB bus number. */
 DEFINE_PROP_UINT8(PROP_PXB_BUS_NR, PXBDev, bus_nr, 0),
@@ -447,6 +490,16 @@ static void pxb_dev_class_init(ObjectClass *klass, void 
*data)
 set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
 }
 
+static void pxb_pcie_dev_initfn(Object *obj)
+{
+PXBDev *pxb = PXB_PCIE_DEV(obj);
+
+/* Add backlink to pxb-pcie-host */
+object_property_add_link(obj, PROP_PXB_PCIE_HOST, TYPE_PXB_PCIE_HOST,
+ (Object **)>pxbhost,
+ qdev_prop_allow_set_link_before_realize, 0, NULL);
+}
+
 static const TypeInfo pxb_dev_info = {
 .name  = TYPE_PXB_DEVICE,
 .parent= TYPE_PCI_DEVICE,
@@ -478,6 +531,7 @@ static void pxb_pcie_dev_class_init(ObjectClass *klass, 
void *data)
 
 k->realize = pxb_pcie_dev_realize;
 k->exit = pxb_dev_exitfn;
+k->config_read = pxb_pcie_config_read;
 k->vendor_id = PCI_VENDOR_ID_REDHAT;
 k->device_id = PCI_DEVICE_ID_REDHAT_PXB_PCIE;
 k->class_id = PCI_CLASS_BRIDGE_HOST;
@@ -492,6 +546,7 @@ static const TypeInfo pxb_pcie_dev_info = {
 .name  = TYPE_PXB_PCIE_DEVICE,
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(PXBDev),
+.instance_init = pxb_pcie_dev_initfn,
 .class_init= pxb_pcie_dev_class_init,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
diff --git a/include/hw/pci-bridge/pci_expander_bridge.h 
b/include/hw/pci-bridge/pci_expander_bridge.h
index 870c4cd..1119210 100644
--- a/include/hw/pci-bridge/pci_expander_bridge.h
+++ b/include/hw/pci-bridge/pci_expander_bridge.h
@@ -2,6 +2,7 @@
 #define HW_PCI_EXPANDER_H
 
 #define PROP_PXB_PCIE_DEV "pxbdev"

[Qemu-devel] [RFC v3 3/6] i386/acpi-build: describe new pci domain in AML

[Zihan Yang]

Describe new pci segments of host bridges in AML as new pci devices,
with _SEG and _BBN to let them be in DSDT

Signed-off-by: Zihan Yang 
---
 hw/i386/acpi-build.c | 78 +++-
 1 file changed, 53 insertions(+), 25 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 30bd0d5..4b6ef78 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1832,6 +1832,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 aml_append(dev, aml_name_decl("_UID", aml_int(1)));
 aml_append(dev, build_q35_osc_method());
 aml_append(sb_scope, dev);
+
 aml_append(dsdt, sb_scope);
 
 build_hpet_aml(dsdt);
@@ -1875,6 +1876,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 
 crs_range_set_init(_range_set);
 bus = PC_MACHINE(machine)->bus;
+i = 1; // PCI0 is q35 host, pxb starts from 1
 if (bus) {
 QLIST_FOREACH(bus, >child, sibling) {
 uint8_t bus_num = pci_bus_num(bus);
@@ -1890,10 +1892,9 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 }
 
 scope = aml_scope("\\_SB");
-dev = aml_device("PC%.02X", bus_num);
+dev = aml_device("PCI%d", i++);
 aml_append(dev, aml_name_decl("_UID", aml_int(bus_num)));
 aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
-aml_append(dev, aml_name_decl("_BBN", aml_int(bus_num)));
 if (pci_bus_is_express(bus)) {
 aml_append(dev, build_q35_osc_method());
 }
@@ -2125,36 +2126,63 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 sb_scope = aml_scope("\\_SB");
 {
 Object *pci_host;
+QObject *o;
 PCIBus *bus = NULL;
+uint32_t domain_nr;
+uint8_t bus_nr;
+int index = 0;
 
 pci_host = acpi_get_i386_pci_host();
-if (pci_host) {
+while (pci_host) {
+Object *obj = object_property_get_link(pci_host,
+   PROP_PXB_PCIE_DEV, NULL);
+if (!obj) {
+/* we are in q35 host */
+obj = pci_host;
+}
+o = object_property_get_qobject(obj, PROP_PXB_PCIE_DOMAIN_NR, 
NULL);
+assert(o);
+domain_nr = qnum_get_uint(qobject_to(QNum, o));
+qobject_unref(o);
+
+o = object_property_get_qobject(pci_host, "bus_nr", NULL);
+if (!o) {
+/* we are in q35 host */
+bus_nr = 0;
+} else {
+bus_nr = qnum_get_uint(qobject_to(QNum, o));
+qobject_unref(o);
+}
+
 bus = PCI_HOST_BRIDGE(pci_host)->bus;
-}
+if (bus) {
+Aml *scope = aml_scope("PCI%d", index);
+aml_append(scope, aml_name_decl("_SEG", aml_int(domain_nr)));
+aml_append(scope, aml_name_decl("_BBN", aml_int(bus_nr)));
+/* Scan all PCI buses. Generate tables to support hotplug. */
+build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
 
-if (bus) {
-Aml *scope = aml_scope("PCI0");
-/* Scan all PCI buses. Generate tables to support hotplug. */
-build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
+/* Only add TPM once */
+if (index++ == 0 && TPM_IS_TIS(tpm_find())) {
+dev = aml_device("ISA.TPM");
+aml_append(dev, aml_name_decl("_HID", 
aml_eisaid("PNP0C31")));
+aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
+crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
+   TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
+/*
+FIXME: TPM_TIS_IRQ=5 conflicts with PNP0C0F irqs,
+Rewrite to take IRQ from TPM device model and
+fix default IRQ value there to use some unused IRQ
+ */
+/* aml_append(crs, aml_irq_no_flags(TPM_TIS_IRQ)); */
+aml_append(dev, aml_name_decl("_CRS", crs));
+aml_append(scope, dev);
+}
 
-if (TPM_IS_TIS(tpm_find())) {
-dev = aml_device("ISA.TPM");
-aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0C31")));
-aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
-crs = aml_resource_template();
-aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
-   TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
-/*
-FIXME: TPM_TIS_IRQ=5 conflicts with PNP0C0F irqs,
-Rewrite to take IRQ from TPM device model and
-fix default IRQ value 

[Qemu-devel] [RFC v3 3/6] i386/acpi-build: describe new pci domain in AML

[Zihan Yang]

Describe new pci segments of host bridges in AML as new pci devices,
with _SEG and _BBN to let them be in DSDT

Signed-off-by: Zihan Yang 
---
 hw/i386/acpi-build.c | 78 +++-
 1 file changed, 53 insertions(+), 25 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 30bd0d5..4b6ef78 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1832,6 +1832,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 aml_append(dev, aml_name_decl("_UID", aml_int(1)));
 aml_append(dev, build_q35_osc_method());
 aml_append(sb_scope, dev);
+
 aml_append(dsdt, sb_scope);
 
 build_hpet_aml(dsdt);
@@ -1875,6 +1876,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 
 crs_range_set_init(_range_set);
 bus = PC_MACHINE(machine)->bus;
+i = 1; // PCI0 is q35 host, pxb starts from 1
 if (bus) {
 QLIST_FOREACH(bus, >child, sibling) {
 uint8_t bus_num = pci_bus_num(bus);
@@ -1890,10 +1892,9 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 }
 
 scope = aml_scope("\\_SB");
-dev = aml_device("PC%.02X", bus_num);
+dev = aml_device("PCI%d", i++);
 aml_append(dev, aml_name_decl("_UID", aml_int(bus_num)));
 aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
-aml_append(dev, aml_name_decl("_BBN", aml_int(bus_num)));
 if (pci_bus_is_express(bus)) {
 aml_append(dev, build_q35_osc_method());
 }
@@ -2125,36 +2126,63 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 sb_scope = aml_scope("\\_SB");
 {
 Object *pci_host;
+QObject *o;
 PCIBus *bus = NULL;
+uint32_t domain_nr;
+uint8_t bus_nr;
+int index = 0;
 
 pci_host = acpi_get_i386_pci_host();
-if (pci_host) {
+while (pci_host) {
+Object *obj = object_property_get_link(pci_host,
+   PROP_PXB_PCIE_DEV, NULL);
+if (!obj) {
+/* we are in q35 host */
+obj = pci_host;
+}
+o = object_property_get_qobject(obj, PROP_PXB_PCIE_DOMAIN_NR, 
NULL);
+assert(o);
+domain_nr = qnum_get_uint(qobject_to(QNum, o));
+qobject_unref(o);
+
+o = object_property_get_qobject(pci_host, "bus_nr", NULL);
+if (!o) {
+/* we are in q35 host */
+bus_nr = 0;
+} else {
+bus_nr = qnum_get_uint(qobject_to(QNum, o));
+qobject_unref(o);
+}
+
 bus = PCI_HOST_BRIDGE(pci_host)->bus;
-}
+if (bus) {
+Aml *scope = aml_scope("PCI%d", index);
+aml_append(scope, aml_name_decl("_SEG", aml_int(domain_nr)));
+aml_append(scope, aml_name_decl("_BBN", aml_int(bus_nr)));
+/* Scan all PCI buses. Generate tables to support hotplug. */
+build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
 
-if (bus) {
-Aml *scope = aml_scope("PCI0");
-/* Scan all PCI buses. Generate tables to support hotplug. */
-build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
+/* Only add TPM once */
+if (index++ == 0 && TPM_IS_TIS(tpm_find())) {
+dev = aml_device("ISA.TPM");
+aml_append(dev, aml_name_decl("_HID", 
aml_eisaid("PNP0C31")));
+aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
+crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
+   TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
+/*
+FIXME: TPM_TIS_IRQ=5 conflicts with PNP0C0F irqs,
+Rewrite to take IRQ from TPM device model and
+fix default IRQ value there to use some unused IRQ
+ */
+/* aml_append(crs, aml_irq_no_flags(TPM_TIS_IRQ)); */
+aml_append(dev, aml_name_decl("_CRS", crs));
+aml_append(scope, dev);
+}
 
-if (TPM_IS_TIS(tpm_find())) {
-dev = aml_device("ISA.TPM");
-aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0C31")));
-aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
-crs = aml_resource_template();
-aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
-   TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
-/*
-FIXME: TPM_TIS_IRQ=5 conflicts with PNP0C0F irqs,
-Rewrite to take IRQ from TPM device model and
-fix default IRQ value 

[Qemu-devel] [RFC v3 0/6] pci_expander_brdige: Put pxb-pcie host bridge into separate pci domain

[Zihan Yang]

NOTE: This patch set relies on seabios change. Unfortunately, I haven't got
it fully working in seabios, but I still post them here because patches
involve some port layout change to be reviewed, and it has been a long delay
since my last version. I'm trying to catch things up recently.

If you would like to see current status of seabios part, please refer to
https://mail.coreboot.org/pipermail/seabios/2018-August/012385.html

Currently only q35 host bridge is allocated an item in MCFG table, all pxb
host bridges stay within pci domain 0. This series of patches put each pxb
host bridge in separate pci domain, allocating a new MCFG table item for it.

Users can configure whether to put pxb host bridge into separate domain
by passing parameter domain_nr to pxb pcie device. start_bus property
indicates the Base Bus Number(BBN) of the pxb host bridge. Another property
max_bus specifies the maximum desired bus numbers to reduce MCFG space cost.
Example command is

-device pxb-pcie,id=br3,bus="pcie.0",start_bus=0,domain_nr=1,max_bus=15

Then this pxb-pcie host bridge is placed at pci domain 1, and only reserve
(15+1)=16 buses, which is much smaller than the default 256 buses.

The pxb host does not have an mch in it, as q35 host already has one. All
pxb host bridges just serve as expander bridges in QEMU, which makes them
a little simpler than q35 host bridge.

v3 <- v2:
- Replace duplicate properties in pxb pcie host with link property to PXBDev
- Allow seabios to access config space and data space of expander bridge
  through a different ioport, because 0xcf8 is attached only to sysbus.
- Add a new property start_bus to indicate the BBN of pxb host bridge. The
  bus_nr property is used as the bus number of pxb-pcie device on pcie.0 bus

v2 <- v1:
- Allow user to configure whether to put pxb-pcie into seperate domain
- Add AML description part of each host bridge
- Modify the location of MCFG space to between RAM hotplug and pci hole64



Zihan Yang (6):
  pci_expander_bridge: add type TYPE_PXB_PCIE_HOST
  acpi-build: allocate mcfg for pxb-pcie host bridges
  i386/acpi-build: describe new pci domain in AML
  pci_expander_bridge: Add config_read callback
  pci_expander_bridge: Add ioport for pxb host bus
  pci_expander_bridge: add start_bus property

 hw/i386/acpi-build.c| 193 +--
 hw/i386/pc.c|  14 +-
 hw/pci-bridge/pci_expander_bridge.c | 229 +++-
 hw/pci-host/q35.c   |   2 +
 hw/pci/pci.c|   9 +-
 include/hw/i386/pc.h|   1 +
 include/hw/pci-bridge/pci_expander_bridge.h |  15 ++
 include/hw/pci-host/q35.h   |   1 +
 include/hw/pci/pci_host.h   |   2 +-
 9 files changed, 406 insertions(+), 60 deletions(-)
 create mode 100644 include/hw/pci-bridge/pci_expander_bridge.h

-- 
2.7.4

[Qemu-devel] [RFC v3 2/6] acpi-build: allocate mcfg for pxb-pcie host bridges

[Zihan Yang]

Allocate new segment for pxb-pcie host bridges in MCFG table, and reserve
corresponding MCFG space for them. This allows user-defined pxb-pcie
host bridges to be placed in different pci domain than q35 host.

The pci_host_bridges list is changed to be tail list to ensure the q35 host
is always the first element when traversing the list, because q35 host is
inserted beofre pxb-pcie hosts

Signed-off-by: Zihan Yang 
---
 hw/i386/acpi-build.c| 115 +++-
 hw/i386/pc.c|  14 +++-
 hw/pci-bridge/pci_expander_bridge.c |  57 ++
 hw/pci-host/q35.c   |   2 +
 hw/pci/pci.c|   9 ++-
 include/hw/i386/pc.h|   1 +
 include/hw/pci-bridge/pci_expander_bridge.h |  11 +++
 include/hw/pci-host/q35.h   |   1 +
 include/hw/pci/pci_host.h   |   2 +-
 9 files changed, 168 insertions(+), 44 deletions(-)
 create mode 100644 include/hw/pci-bridge/pci_expander_bridge.h

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 9e8350c..30bd0d5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -55,6 +55,7 @@
 #include "hw/i386/ich9.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/pci-host/q35.h"
+#include "hw/pci-bridge/pci_expander_bridge.h"
 #include "hw/i386/x86-iommu.h"
 
 #include "hw/acpi/aml-build.h"
@@ -89,6 +90,9 @@
 typedef struct AcpiMcfgInfo {
 uint64_t mcfg_base;
 uint32_t mcfg_size;
+uint32_t domain_nr;
+uint8_t bus_nr; // start bus number
+struct AcpiMcfgInfo *next;
 } AcpiMcfgInfo;
 
 typedef struct AcpiPmInfo {
@@ -2427,14 +2431,16 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
AcpiMcfgInfo *info)
 {
 AcpiTableMcfg *mcfg;
 const char *sig;
-int len = sizeof(*mcfg) + 1 * sizeof(mcfg->allocation[0]);
+int len, count = 0;
+AcpiMcfgInfo *cfg = info;
+
+while (cfg) {
+++count;
+cfg = cfg->next;
+}
+len = sizeof(*mcfg) + count * sizeof(mcfg->allocation[0]);
 
 mcfg = acpi_data_push(table_data, len);
-mcfg->allocation[0].address = cpu_to_le64(info->mcfg_base);
-/* Only a single allocation so no need to play with segments */
-mcfg->allocation[0].pci_segment = cpu_to_le16(0);
-mcfg->allocation[0].start_bus_number = 0;
-mcfg->allocation[0].end_bus_number = PCIE_MMCFG_BUS(info->mcfg_size - 1);
 
 /* MCFG is used for ECAM which can be enabled or disabled by guest.
  * To avoid table size changes (which create migration issues),
@@ -2448,6 +2454,16 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
AcpiMcfgInfo *info)
 } else {
 sig = "MCFG";
 }
+
+while (info) {
+mcfg[count].allocation[0].address = cpu_to_le64(info->mcfg_base);
+mcfg[count].allocation[0].pci_segment = cpu_to_le16(info->domain_nr);
+mcfg[count].allocation[0].start_bus_number = info->bus_nr;
+mcfg[count++].allocation[0].end_bus_number = info->bus_nr + \
+PCIE_MMCFG_BUS(info->mcfg_size - 1);
+info = info->next;
+}
+
 build_header(linker, table_data, (void *)mcfg, sig, len, 1, NULL, NULL);
 }
 
@@ -2602,26 +2618,83 @@ struct AcpiBuildState {
 MemoryRegion *linker_mr;
 } AcpiBuildState;
 
-static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
+static inline void cleanup_mcfg(AcpiMcfgInfo *mcfg)
+{
+AcpiMcfgInfo *tmp;
+while (mcfg) {
+tmp = mcfg->next;
+g_free(mcfg);
+mcfg = tmp;
+}
+}
+
+static AcpiMcfgInfo *acpi_get_mcfg(void)
 {
 Object *pci_host;
 QObject *o;
+uint32_t domain_nr;
+AcpiMcfgInfo *head = NULL, *tail, *mcfg;
 
 pci_host = acpi_get_i386_pci_host();
 g_assert(pci_host);
 
-o = object_property_get_qobject(pci_host, PCIE_HOST_MCFG_BASE, NULL);
-if (!o) {
-return false;
+while (pci_host) {
+/* pxb-pcie-hosts does not have domain_nr property, but a link
+ * to PXBDev. We first try to get pxbdev property, if NULL,
+ * then it is q35 host, otherwise it is pxb-pcie-host */
+Object *obj = object_property_get_link(pci_host,
+   PROP_PXB_PCIE_DEV, NULL);
+if (!obj) {
+/* we are in q35 host */
+obj = pci_host;
+}
+o = object_property_get_qobject(obj, PROP_PXB_PCIE_DOMAIN_NR, NULL);
+assert(o);
+domain_nr = qnum_get_uint(qobject_to(QNum, o));
+qobject_unref(o);
+
+/* Skip bridges that reside in the same domain with q35 host.
+ * Q35 always stays in pci domain 0, and is the first element
+ * in the pci_host_bridges list */
+if (head && domain_nr == 0) {
+pci_host = OBJECT(QTAILQ_NEXT(PCI_HOST_BRIDGE(pci_host), next));
+continue;
+}
+
+mcfg = g_new0(AcpiMcfgInfo, 1);
+mcfg->next = NULL;
+if (!head) {
+tail = 

Re: [Qemu-devel] [virtio-dev] Re: [v23 1/2] virtio-crypto: Add virtio crypto device specification

[Longpeng (Mike)]

Hi Halil,

On 2018/8/2 4:21, Halil Pasic wrote:

> 
> 
> On 07/27/2018 01:51 PM, Michael S. Tsirkin wrote:
>> On Thu, Jul 26, 2018 at 06:55:44PM +0200, Halil Pasic wrote:
>>> Sorry I did not have any time for this last days. And this
>>> to make it worse this is a follow up to something that was
>>> half a year ago. That means I have to re-familiarize myself
>>> with the topic.
>>>
>>> If I don't get around to answer in couple of weeks, feel
>>> free to ping me.
>>>
>>> Since from what I've seen most of the questions were of type
>>> 'Can we do it like this?', maybe sending out a new version
>>> is the best. So people (like me) can read through the whole
>>> thing and point out problems if any.
>>>
>>> Regards,
>>> Halil
>>
>>
>> While two weeks for review is borderline reasonable as an exception, it
>> does trouble me that  we are at v23, for something that is used
>> in the field so it's not like we can just change things at will.
>> So I hope everyone concerned makes an effort to try to converge on a spec
>> ASAP.
>>
> 
> What I tried to say: I'm busy with other stuff, and I'm not too
> happy to resume a complex topic after 6 months hiatus.
> 
> The series is now at v24 and has apparently no acks or r-bs. I don't think
> I'm the only one to blame for that.
> 

> It seems, I won't have the time to do a conscientious review in a
> timely fashion. If the rest of the bunch thinks what we have is good
> enough, I am happy to abstain when voting on this -- and avoiding
> holding it up any further.
> 

Thanks for your conscientious reviews on previous versions and your suggestions
are really useful to make the spec better. I'm sorry that I should be to blame
for the half a year hiatus, not you.

I've do some offline discussions with Gonglei and Intel guys, it seems that
there is no big arguments on v23 and the following small problems can be fixed
by follow-up patches.

I hope guys who care about this spec could post your opinion, I'll suggest
Gonglei to start a vote for the spec if no.

> Regards,
> Halil
> 
> 
> .
> 


-- 
Regards,
Longpeng(Mike)

Re: [Qemu-devel] [PATCH for-3.1] s390x: remove 's390-squash-mcss' option

[Fam Zheng]

On Wed, Aug 1, 2018 at 9:18 PM Cornelia Huck  wrote:
>
> On Wed, 1 Aug 2018 15:11:23 +0200
> Cornelia Huck  wrote:
>
> > On Wed, 1 Aug 2018 14:54:51 +0200
> > Cornelia Huck  wrote:
> >
> > > On Wed, 1 Aug 2018 18:21:27 +0800
> > > Fam Zheng  wrote:
> > >
> > > > On Tue, 07/24 11:24, Cornelia Huck wrote:
> > > > > diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c
> > > > > index a02d708239..1bd6c8b458 100644
> > > > > --- a/hw/s390x/css-bridge.c
> > > > > +++ b/hw/s390x/css-bridge.c
> > > > > @@ -106,7 +106,6 @@ VirtualCssBus *virtual_css_bus_init(void)
> > > > >  /* Create bus on bridge device */
> > > > >  bus = qbus_create(TYPE_VIRTUAL_CSS_BUS, dev, "virtual-css");
> > > > >  cbus = VIRTUAL_CSS_BUS(bus);
> > > >
> > > > Not used now?
> > > >
> > > > Fam
> > >
> > > Indeed, we can ditch the cbus variable.
> >
> > ...or not :) We still need it for the return value, which is processed
> > in ccw_init(). We could change the return code of the function to
> > BusState, but I'm not sure it is worth the hassle.
>
> ...but we can indeed get rid of the cbus and qbus variables in
> s390_ccw_realize().

I got this from a patchew.org test (make docker-test-clang@ubuntu):

/tmp/qemu-test/src/hw/s390x/3270-ccw.c:103:20: error: unused variable
'cbus' [-Werror,-Wunused-variable]
VirtualCssBus *cbus = VIRTUAL_CSS_BUS(qbus);
   ^
1 error generated.
/tmp/qemu-test/src/rules.mak:69: recipe for target 'hw/s390x/3270-ccw.o' failed

[Qemu-devel] [Bug 1784900] Re: QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline

[Stefan Berger]

This patch here fixes the issue, but is likely introducing inefficiency.
There are two if statements above the patch that should set full_update
= 1 due to 'some change', but none of them triggers it. So I think the
surface is wrong and needs to be recreated.

diff --git a/hw/display/vga.c b/hw/display/vga.c
index ed476e4e80..71b5684994 100644
--- a/hw/display/vga.c
+++ b/hw/display/vga.c
@@ -1571,6 +1571,7 @@ static void vga_draw_graphic(VGACommonState *s, int 
full_update)
  * must be updated with the new base address */
 full_update = 1;
 }
+full_update = 1;

 if (full_update) {
 if (share_surface) {


A better solution may be this one here:

diff --git a/hw/display/vga.c b/hw/display/vga.c
index ed476e4e80..4f365b6d43 100644
--- a/hw/display/vga.c
+++ b/hw/display/vga.c
@@ -1566,7 +1566,7 @@ static void vga_draw_graphic(VGACommonState *s, int 
full_update)
 full_update = 1;
 }
 if (surface_data(surface) != s->vram_ptr + (s->start_addr * 4)
-&& is_buffer_shared(surface)) {
+/*&& is_buffer_shared(surface)*/) {
 /* base address changed (page flip) -> shared display surfaces
  * must be updated with the new base address */
 full_update = 1;

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784900

Title:
  QEMU (frontend) crashes upon warm reboot with virtio-gpu device and
  vga=775 on Linux cmdline

Status in QEMU:
  New

Bug description:
  With vga=775 on the Linux command line a first boot of the VM running
  Linux works fine. After a warm reboot it crashes during Linux boot.
  The VM was used remotely via virt-manager and VNC.

  Bisecting the code lead to the following patch that introduced the
  bug:

  commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
  Author: Gerd Hoffmann 
  Date:   Mon Jul 2 18:24:43 2018 +0200

  virtio-gpu: disable scanout when backing resource is destroyed

  Signed-off-by: Gerd Hoffmann 
  Reviewed-by: Marc-André Lureau 
  Message-id: 20180702162443.16796-4-kra...@redhat.com

  diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
  index 336dc59007..08cd567218 100644
  --- a/hw/display/virtio-gpu.c
  +++ b/hw/display/virtio-gpu.c
  @@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int 
scanout_id)
   static void virtio_gpu_resource_destroy(VirtIOGPU *g,
   struct virtio_gpu_simple_resource 
*res)
   {
  +int i;
  +
  +if (res->scanout_bitmask) {
  +for (i = 0; i < g->conf.max_outputs; i++) {
  +if (res->scanout_bitmask & (1 << i)) {
  +virtio_gpu_disable_scanout(g, i);
  +}
  +}
  +}
  +
   pixman_image_unref(res->image);
   virtio_gpu_cleanup_mapping(res);
   QTAILQ_REMOVE(>reslist, res, next);

  
  Reported backtraces can be found here:  
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784900/+subscriptions

[Qemu-devel] [PATCH] qga: Support Unicode paths in guest-file-open on win32

[Jonathon Reinhart]

Currently, the win32 port of QEMU Guest Agent does not properly handle Unicode
paths. The JSON decoder produces a valid UTF-8 path string, but this is passed
directly to CreateFileA, which is expecting an ANSI string and not UTF-8. This
leads to mangled filenames.

This patch follows the example of qmp_guest_set_user_password() and uses
g_utf8_to_utf16() to convert the string to UTF-16 and calls CreateFileW()
explicitly.

Signed-off-by: Jonathon Reinhart 
---
 qga/commands-win32.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 98d9735389..416343b97b 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -160,13 +160,15 @@ static void handle_set_nonblocking(HANDLE fh)
 int64_t qmp_guest_file_open(const char *path, bool has_mode,
 const char *mode, Error **errp)
 {
-int64_t fd;
+int64_t fd = -1;
 HANDLE fh;
 HANDLE templ_file = NULL;
 DWORD share_mode = FILE_SHARE_READ;
 DWORD flags_and_attr = FILE_ATTRIBUTE_NORMAL;
 LPSECURITY_ATTRIBUTES sa_attr = NULL;
 OpenFlags *guest_flags;
+GError *gerr = NULL;
+wchar_t *w_path = NULL;

 if (!has_mode) {
 mode = "r";
@@ -175,16 +177,21 @@ int64_t qmp_guest_file_open(const char *path,
bool has_mode,
 guest_flags = find_open_flag(mode);
 if (guest_flags == NULL) {
 error_setg(errp, "invalid file open mode");
-return -1;
+goto done;
+}
+
+w_path = g_utf8_to_utf16(path, -1, NULL, NULL, );
+if (!w_path) {
+goto done;
 }

-fh = CreateFile(path, guest_flags->desired_access, share_mode, sa_attr,
+fh = CreateFileW(w_path, guest_flags->desired_access, share_mode, sa_attr,
 guest_flags->creation_disposition, flags_and_attr,
 templ_file);
 if (fh == INVALID_HANDLE_VALUE) {
 error_setg_win32(errp, GetLastError(), "failed to open file '%s'",
  path);
-return -1;
+goto done;
 }

 /* set fd non-blocking to avoid common use cases (like reading from a
@@ -196,10 +203,17 @@ int64_t qmp_guest_file_open(const char *path,
bool has_mode,
 if (fd < 0) {
 CloseHandle(fh);
 error_setg(errp, "failed to add handle to qmp handle table");
-return -1;
+goto done;
 }

 slog("guest-file-open, handle: % " PRId64, fd);
+
+done:
+if (gerr) {
+error_setg(errp, QERR_QGA_COMMAND_FAILED, gerr->message);
+g_error_free(gerr);
+}
+g_free(w_path);
 return fd;
 }

-- 
2.11.0

[Qemu-devel] [Bug 1784900] Re: QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline

[Stefan Berger]

The reason for this bug is memory corruption in glibc's memory chunk
header that is in front of some bitmap pixman is allocating and
maintaining as image->bits.free_me. I set a memory watchpoint to this
memory location and this code here triggered it and corrupted what seems
to be a memory chunk size indicator, which upon free() causes print of
'invalid pointer' by glibc:

Thread 1 "qemu-system-x86" hit Hardware watchpoint 2: *0x7f6160361d88

Old value = 3145749
New value = 0
vga_draw_line8 (vga=vga@entry=0x556d68549b30, d=0x7f6160361d80 "", 
d@entry=0x7f61603615e0 "", addr=983528, width=)
at /home/stefanb/tmp/qemu-tip/hw/display/vga-helpers.h:297
297 ((uint32_t *)d)[3] = palette[vga_read_byte(vga, addr + 3)];


(gdb) bt
#0  vga_draw_line8 (vga=vga@entry=0x556d68549b30, d=0x7f6160361d80 "", 
d@entry=0x7f61603615e0 "", addr=983528, width=)
at /home/stefanb/tmp/qemu-tip/hw/display/vga-helpers.h:297
#1  0x556d659918ee in vga_draw_graphic (full_update=0, s=0x556d68549b30) at 
/home/stefanb/tmp/qemu-tip/hw/display/vga.c:1695
#2  vga_update_display (opaque=0x556d68549b30) at 
/home/stefanb/tmp/qemu-tip/hw/display/vga.c:1782
#3  0x556d65c0cd92 in vnc_refresh (dcl=0x556d683055a8) at ui/vnc.c:3046
#4  0x556d65bff702 in dpy_refresh (s=0x556d686be540) at ui/console.c:1658
#5  gui_update (opaque=0x556d686be540) at ui/console.c:205
#6  0x556d65d0deac in timerlist_run_timers (timer_list=0x556d66de0e00) at 
util/qemu-timer.c:536
#7  0x556d65d0e0f7 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at 
util/qemu-timer.c:547
#8  qemu_clock_run_all_timers () at util/qemu-timer.c:674
#9  0x556d65d0e5d1 in main_loop_wait (nonblocking=) at 
util/main-loop.c:503
#10 0x556d65a5f2ee in main_loop () at vl.c:1865
#11 0x556d658ff166 in main (argc=, argv=, 
envp=) at vl.c:4643

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784900

Title:
  QEMU (frontend) crashes upon warm reboot with virtio-gpu device and
  vga=775 on Linux cmdline

Status in QEMU:
  New

Bug description:
  With vga=775 on the Linux command line a first boot of the VM running
  Linux works fine. After a warm reboot it crashes during Linux boot.
  The VM was used remotely via virt-manager and VNC.

  Bisecting the code lead to the following patch that introduced the
  bug:

  commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
  Author: Gerd Hoffmann 
  Date:   Mon Jul 2 18:24:43 2018 +0200

  virtio-gpu: disable scanout when backing resource is destroyed

  Signed-off-by: Gerd Hoffmann 
  Reviewed-by: Marc-André Lureau 
  Message-id: 20180702162443.16796-4-kra...@redhat.com

  diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
  index 336dc59007..08cd567218 100644
  --- a/hw/display/virtio-gpu.c
  +++ b/hw/display/virtio-gpu.c
  @@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int 
scanout_id)
   static void virtio_gpu_resource_destroy(VirtIOGPU *g,
   struct virtio_gpu_simple_resource 
*res)
   {
  +int i;
  +
  +if (res->scanout_bitmask) {
  +for (i = 0; i < g->conf.max_outputs; i++) {
  +if (res->scanout_bitmask & (1 << i)) {
  +virtio_gpu_disable_scanout(g, i);
  +}
  +}
  +}
  +
   pixman_image_unref(res->image);
   virtio_gpu_cleanup_mapping(res);
   QTAILQ_REMOVE(>reslist, res, next);

  
  Reported backtraces can be found here:  
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784900/+subscriptions

Re: [Qemu-devel] [PATCH] sdl2: redraw correctly when scanout_mode enabled.

[吴涛@Eng]

On Fri, Jul 27, 2018 at 6:59 AM Tao Wu  wrote:
>
> When scanout_mode enabled, surface is out of sync with actual screen.
> In such case, we just call sdl2_gl_scanout_flush to do redraw. This
> fixes bug reported in
> https://lists.freedesktop.org/archives/virglrenderer-devel/2018-July/001330.html
>
> Signed-off-by: Tao Wu 
> ---
>  ui/sdl2-gl.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
> index 83b71853d1..1bf4542d8d 100644
> --- a/ui/sdl2-gl.c
> +++ b/ui/sdl2-gl.c
> @@ -124,6 +124,11 @@ void sdl2_gl_redraw(struct sdl2_console *scon)
>  {
>  assert(scon->opengl);
>
> +if (scon->scanout_mode) {
> +/* sdl2_gl_scanout_flush actually only care about
> + * the first argument. */
> +return sdl2_gl_scanout_flush(>dcl, 0, 0, 0, 0);
> +}
>  if (scon->surface) {
>  sdl2_gl_render_surface(scon);
>  }
> --
> 2.18.0.345.g5c9ce644c3-goog
>
Ping, thanks!

Re: [Qemu-devel] [PATCH QEMU] hw/char/sh_serial: Add timeout handling to unbreak serial input

[Rich Felker]

On Tue, Jul 31, 2018 at 11:36:46AM -0500, Rob Landley wrote:
> On 07/30/2018 10:18 AM, Ulrich Hecht wrote:>> On July 30, 2018 at 3:02 PM 
> Geert
> Uytterhoeven  wrote:
> >> Fix this by adding basic timeout handling.  As the QEMU SCIF emulation
> >> ignores any serial speed programming, the timeout value used conforms to
> >> a default speed of 9600 bps, which is fine for any interative console.
> >>
> >> Reported-by: Rob Landley 
> >> Signed-off-by: Geert Uytterhoeven 
> > 
> > Works for me, kernel 4.18-rc7 for rts7751r2dplus.
> 
> Works for me too.
> 
> Tested-by: Rob Landley 

Me too. This would be a very welcome fix for a longstanding and
annoying problem.

Tested-by: Rich Felker 

Rich

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[John Snow]

On 08/01/2018 04:47 PM, Denis V. Lunev wrote:
> On 08/01/2018 09:56 PM, John Snow wrote:
>>
>> On 08/01/2018 02:42 PM, Denis V. Lunev wrote:
>>> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
 * John Snow (js...@redhat.com) wrote:
> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
>> * John Snow (js...@redhat.com) wrote:
>>
>> 
>>
>>> I'd rather do something like this:
>>> - Always flush bitmaps to disk on inactivate.
>> Does that increase the time taken by the inactivate measurably?
>> If it's small relative to everything else that's fine; it's just I
>> always worry a little since I think this happens after we've stopped the
>> CPU on the source, so is part of the 'downtime'.
>>
>> Dave
>> --
>> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>>
> I'm worried that if we don't, we're leaving behind unusable, partially
> complete files behind us. That's a bad design and we shouldn't push for
> it just because it's theoretically faster.
 Oh I don't care about theoretical speed; but if it's actually unusably
 slow in practice then it needs fixing.

 Dave
>>> This is not "theoretical" speed. This is real practical speed and
>>> instability.
>> It's theoretical until I see performance testing numbers; do you have
>> any? How much faster does the pivot happen by avoiding making the qcow2
>> consistent on close?
>>
>> I don't argue that it's faster to just simply not write data, but what's
>> not obvious is how much time it actually saves in practice and if that's
>> worth doing unintuitive and undocumented things like "the source file
>> loses bitmaps after a migration because it was faster."
> 
> Also, frankly speaking, I do not understand the goal of this purism.
> 

The goal of my series originally was just to limit some corner cases. At
the time it was not evident that avoiding a flush was a *goal* of that
series rather than a *side-effect* or a means to an end (avoiding
migrating a bitmap over two different channels).

It was not immediately obvious to me that intentionally leaving behind
partially flushed qcow2 files was expected behavior. I still think it's
probably not the best behavior in general, but it's also not really
catastrophic either. If you had benchmarks it'd be useful to show an
obvious benefit to doing something unconventional.

In this case, I *do* consider not writing metadata back out to disk on
close something "unconventional."

Clearly my series missed missed an important case, so it can't be used
at all, and the status quo is also broken for several cases and also
cannot be used. With your performance concerns in mind, I'm looking at
Vladimir's series again. It might just require some more concise
comments explaining why you're taking the exact approach that you are.

--js

> There 2 main cases - shared and non-shared storage. On shared
> storage:
> - normally migration is finished successfully. Source is shut down,
>   target is started. The data in the file on shared storage would be
>   __IMMEDIATELY__ marked as stale on target, i.e. you will save CBT
>  on source (with IO over networked fs), load CBT on target (with IO
>  over networked FS), mark CBT as stale (IO again). CBT data written
>  is marked as lost
> - failed migration. OK, we have CBT data written on source, CBT
>   data read on source, CBT data marked stale. Thus any CBT on
>   disk while VM is running is pure overhead.
> 
> The same situation is when we use non-shared migration. In this
> case the situation is even worse. You save CBT and put it to trash
> upon migration complete.
> 
> Please also note, that CBT saving almost does not protect us
> from powerlosses as the power should be lost at the very
> specific moment to allow data to survive and most likely
> we will have to drop CBT completely.
> 
> Den
> 

Re: [Qemu-devel] [PATCH] vhost: check region type before casting

[Michael S. Tsirkin]

On Wed, Aug 01, 2018 at 11:13:34AM +0100, Peter Maydell wrote:
> On 1 August 2018 at 09:22, Tiwei Bie  wrote:
> > Ping..
> >
> > It seems that the final release for QEMU 3.0 will be
> > out soon [1]. But this fix hasn't been merged yet.
> >
> > [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg06004.html
> 
> :-(
> 
> You just missed rc3 (which we tagged yesterday), and I'm
> not sure if this meets the barrier for causing us to put
> out an rc4. It is a regression, but when does it happen?
> The commit message isn't very clear whether this is a
> corner case or not.
> 
> thanks
> -- PMM

There's also Igor's fix for memory hotplug.
Pretty small fixes for sure, and I'd like to have them in if possible,
but if I'm the only one maybe we can put it in stable ...

I have collected these two in my tree meanwhile. Let me know.

-- 
MST

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Denis V. Lunev]

On 08/01/2018 09:56 PM, John Snow wrote:
>
> On 08/01/2018 02:42 PM, Denis V. Lunev wrote:
>> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
>>> * John Snow (js...@redhat.com) wrote:
 On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
> * John Snow (js...@redhat.com) wrote:
>
> 
>
>> I'd rather do something like this:
>> - Always flush bitmaps to disk on inactivate.
> Does that increase the time taken by the inactivate measurably?
> If it's small relative to everything else that's fine; it's just I
> always worry a little since I think this happens after we've stopped the
> CPU on the source, so is part of the 'downtime'.
>
> Dave
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
 I'm worried that if we don't, we're leaving behind unusable, partially
 complete files behind us. That's a bad design and we shouldn't push for
 it just because it's theoretically faster.
>>> Oh I don't care about theoretical speed; but if it's actually unusably
>>> slow in practice then it needs fixing.
>>>
>>> Dave
>> This is not "theoretical" speed. This is real practical speed and
>> instability.
> It's theoretical until I see performance testing numbers; do you have
> any? How much faster does the pivot happen by avoiding making the qcow2
> consistent on close?
>
> I don't argue that it's faster to just simply not write data, but what's
> not obvious is how much time it actually saves in practice and if that's
> worth doing unintuitive and undocumented things like "the source file
> loses bitmaps after a migration because it was faster."

Also, frankly speaking, I do not understand the goal of this purism.

There 2 main cases - shared and non-shared storage. On shared
storage:
- normally migration is finished successfully. Source is shut down,
  target is started. The data in the file on shared storage would be
  __IMMEDIATELY__ marked as stale on target, i.e. you will save CBT
 on source (with IO over networked fs), load CBT on target (with IO
 over networked FS), mark CBT as stale (IO again). CBT data written
 is marked as lost
- failed migration. OK, we have CBT data written on source, CBT
  data read on source, CBT data marked stale. Thus any CBT on
  disk while VM is running is pure overhead.

The same situation is when we use non-shared migration. In this
case the situation is even worse. You save CBT and put it to trash
upon migration complete.

Please also note, that CBT saving almost does not protect us
from powerlosses as the power should be lost at the very
specific moment to allow data to survive and most likely
we will have to drop CBT completely.

Den

Normally migration is executed as follows:
- source is gently shutdowned, all da

Re: [Qemu-devel] [PATCH v5 07/76] elf: Remove duplicate preprocessor constant definition

[Laurent Vivier]

Le 01/08/2018 à 22:01, Aleksandar Markovic a écrit :
>>
>> From: Peter Maydell 
>> Sent: Wednesday, August 1, 2018 9:37 PM
>>
>>> The simplest way to do that is just to delete
>>> the second (original) EF_MIPS_ARCH #define, the one just
>>> below the EF_MIPS_NAN2008 define.
>>>
>>> We could line up with the order the glibc headers use, but
>>> that seems like overkill compared to just deleting a line.
>>
> 
> This sounds reasonable to me, and, if nobody disputes it, I will implement it 
> this way in the next version.

I agree

Laurent

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Denis V. Lunev]

On 08/01/2018 09:56 PM, John Snow wrote:
>
> On 08/01/2018 02:42 PM, Denis V. Lunev wrote:
>> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
>>> * John Snow (js...@redhat.com) wrote:
 On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
> * John Snow (js...@redhat.com) wrote:
>
> 
>
>> I'd rather do something like this:
>> - Always flush bitmaps to disk on inactivate.
> Does that increase the time taken by the inactivate measurably?
> If it's small relative to everything else that's fine; it's just I
> always worry a little since I think this happens after we've stopped the
> CPU on the source, so is part of the 'downtime'.
>
> Dave
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
 I'm worried that if we don't, we're leaving behind unusable, partially
 complete files behind us. That's a bad design and we shouldn't push for
 it just because it's theoretically faster.
>>> Oh I don't care about theoretical speed; but if it's actually unusably
>>> slow in practice then it needs fixing.
>>>
>>> Dave
>> This is not "theoretical" speed. This is real practical speed and
>> instability.
> It's theoretical until I see performance testing numbers; do you have
> any? How much faster does the pivot happen by avoiding making the qcow2
> consistent on close?
>
> I don't argue that it's faster to just simply not write data, but what's
> not obvious is how much time it actually saves in practice and if that's
> worth doing unintuitive and undocumented things like "the source file
> loses bitmaps after a migration because it was faster."
John,

pls see my letter to Dave. Speaking about theoretical things I can
avoid waiting of any guest IO. At least we have started research
in that direction.

With this code merged we'll have IO when we can avoid it completely.
That is why this approach should not be taken.

You should know, as we have discussed things originally, that
technically we can lost CBT completely and this is just one time
problem. The data will not be lost. You will just have to call full backup
once. Thus there is no need to create something much slower
and complex where there are faster ways.

Den

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Denis V. Lunev]

On 08/01/2018 09:55 PM, Dr. David Alan Gilbert wrote:
> * Denis V. Lunev (d...@openvz.org) wrote:
>> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
>>> * John Snow (js...@redhat.com) wrote:
 On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
> * John Snow (js...@redhat.com) wrote:
>
> 
>
>> I'd rather do something like this:
>> - Always flush bitmaps to disk on inactivate.
> Does that increase the time taken by the inactivate measurably?
> If it's small relative to everything else that's fine; it's just I
> always worry a little since I think this happens after we've stopped the
> CPU on the source, so is part of the 'downtime'.
>
> Dave
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
 I'm worried that if we don't, we're leaving behind unusable, partially
 complete files behind us. That's a bad design and we shouldn't push for
 it just because it's theoretically faster.
>>> Oh I don't care about theoretical speed; but if it's actually unusably
>>> slow in practice then it needs fixing.
>>>
>>> Dave
>> This is not "theoretical" speed. This is real practical speed and
>> instability.
>> EACH IO operation can be performed unpredictably slow and thus with
>> IO operations in mind you can not even calculate or predict downtime,
>> which should be done according to the migration protocol.
> We end up doing some IO anyway, even ignoring these new bitmaps,
> at the end of the migration when we pause the CPU, we do a
> bdrv_inactivate_all to flush any outstanding writes; so we've already
> got that unpredictable slowness.
>
> So, not being a block person, but with some interest in making sure
> downtime doesn't increase, I just wanted to understand whether the
> amount of writes we're talking about here is comparable to that
> which already exists or a lot smaller or a lot larger.
> If the amount of IO you're talking about is much smaller than what
> we typically already do, then John has a point and you may as well
> do the write.
> If the amount of IO for the bitmap is much larger and would slow
> the downtime a lot then you've got a point and that would be unworkable.
>
> Dave
This is not theoretical difference.

For 1 Tb drive and 64 kb bitmap granularity the size of bitmap is
2 Mb + some metadata (64 Kb). Thus we will have to write
2 Mb of data per bitmap. For some case there are 2-3-5 bitmaps
this we will have 10 Mb of data. With 16 Tb drive the amount of
data to write will be multiplied by 16 which gives 160 Mb to
write. More disks and bigger the size - more data to write.

Above amount should be multiplied by 2 - x Mb to be written
on source, x Mb to be read on target which gives 320 Mb to
write.

That is why this is not good - we have linear increase with the
size and amount of disks.

There is also some thoughts on normal guest IO. Theoretically
we can think on replaying IO on the target closing the file
immediately or block writes to changed areas and notify
target upon IO completion or invent other fancy dances.
At least we think right now on these optimizations for regular
migration paths.

The problem right that such things are not needed now for CBT
but will become necessary and pretty much useless upon
introducing this stuff.

Den

Re: [Qemu-devel] [virtio-dev] Re: [v23 1/2] virtio-crypto: Add virtio crypto device specification

[Halil Pasic]

On 07/27/2018 01:51 PM, Michael S. Tsirkin wrote:

On Thu, Jul 26, 2018 at 06:55:44PM +0200, Halil Pasic wrote:

Sorry I did not have any time for this last days. And this
to make it worse this is a follow up to something that was
half a year ago. That means I have to re-familiarize myself
with the topic.

If I don't get around to answer in couple of weeks, feel
free to ping me.

Since from what I've seen most of the questions were of type
'Can we do it like this?', maybe sending out a new version
is the best. So people (like me) can read through the whole
thing and point out problems if any.

Regards,
Halil



While two weeks for review is borderline reasonable as an exception, it
does trouble me that  we are at v23, for something that is used
in the field so it's not like we can just change things at will.
So I hope everyone concerned makes an effort to try to converge on a spec
ASAP.



What I tried to say: I'm busy with other stuff, and I'm not too
happy to resume a complex topic after 6 months hiatus.

The series is now at v24 and has apparently no acks or r-bs. I don't think
I'm the only one to blame for that.

It seems, I won't have the time to do a conscientious review in a
timely fashion. If the rest of the bunch thinks what we have is good
enough, I am happy to abstain when voting on this -- and avoiding
holding it up any further.

Regards,
Halil

Re: [Qemu-devel] [PATCH 0/4] target/arm sve fixes

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180801123111.3595-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH 0/4] target/arm sve fixes

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
316eefdbc8 target/arm: Fix typo in helper_sve_movz_d
4b115c0c0d target/arm: Reorganize SVE WHILE
b5f496f5e7 target/arm: Fix typo in do_sat_addsub_64
795c7bee8d target/arm: Fix sign of sve_cmpeq_ppzw/sve_cmpne_ppzw

=== OUTPUT BEGIN ===
Checking PATCH 1/4: target/arm: Fix sign of sve_cmpeq_ppzw/sve_cmpne_ppzw...
ERROR: spaces required around that '==' (ctx:WxB)
#31: FILE: target/arm/sve_helper.c:2439:
+DO_CMP_PPZW_B(sve_cmpeq_ppzw_b, int8_t,  uint64_t, ==)
^

ERROR: spaces required around that '==' (ctx:WxB)
#32: FILE: target/arm/sve_helper.c:2440:
+DO_CMP_PPZW_H(sve_cmpeq_ppzw_h, int16_t, uint64_t, ==)
^

ERROR: spaces required around that '==' (ctx:WxB)
#33: FILE: target/arm/sve_helper.c:2441:
+DO_CMP_PPZW_S(sve_cmpeq_ppzw_s, int32_t, uint64_t, ==)
^

ERROR: spaces required around that '!=' (ctx:WxB)
#38: FILE: target/arm/sve_helper.c:2443:
+DO_CMP_PPZW_B(sve_cmpne_ppzw_b, int8_t,  uint64_t, !=)
^

ERROR: spaces required around that '!=' (ctx:WxB)
#39: FILE: target/arm/sve_helper.c:2444:
+DO_CMP_PPZW_H(sve_cmpne_ppzw_h, int16_t, uint64_t, !=)
^

ERROR: spaces required around that '!=' (ctx:WxB)
#40: FILE: target/arm/sve_helper.c:2445:
+DO_CMP_PPZW_S(sve_cmpne_ppzw_s, int32_t, uint64_t, !=)
^

total: 6 errors, 0 warnings, 19 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/4: target/arm: Fix typo in do_sat_addsub_64...
Checking PATCH 3/4: target/arm: Reorganize SVE WHILE...
Checking PATCH 4/4: target/arm: Fix typo in helper_sve_movz_d...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v5 07/76] elf: Remove duplicate preprocessor constant definition

[Aleksandar Markovic]

> 
> From: Peter Maydell 
> Sent: Wednesday, August 1, 2018 9:37 PM
> 
> > The simplest way to do that is just to delete
> > the second (original) EF_MIPS_ARCH #define, the one just
> > below the EF_MIPS_NAN2008 define.
> >
> > We could line up with the order the glibc headers use, but
> > that seems like overkill compared to just deleting a line.
> 

This sounds reasonable to me, and, if nobody disputes it, I will implement it 
this way in the next version.

Aleksandar

Re: [Qemu-devel] [PATCH v5 07/76] elf: Remove duplicate preprocessor constant definition

[Peter Maydell]

On 1 August 2018 at 19:51, Aleksandar Markovic  wrote:
> Hi, Laurent.
>
>> From: Laurent Vivier 
>> Sent: Monday, July 30, 2018 6:49 PM
>>
>> Le 30/07/2018 à 18:11, Aleksandar Markovic a écrit :
>> > diff --git a/include/elf.h b/include/elf.h
>> > index 934dbbd..c8aaa2a 100644
>> > --- a/include/elf.h
>> > +++ b/include/elf.h
>> > @@ -33,7 +33,6 @@ typedef int64_t  Elf64_Sxword;
>> >
>> >  /* Flags in the e_flags field of the header */
>> >  /* MIPS architecture level. */
>> > -#define EF_MIPS_ARCH0xf000
>> >
>> >  /* Legal values for MIPS architecture level.  */
>> >  #define EF_MIPS_ARCH_1   0x  /* -mips1 code.  */
>> >
>>
>> You should move the comment "MIPS architecture level" where the other
>> EF_MIPS_ARCH is defined (see glibc or system elf.h).
>>
>> Thanks,
>> Laurent
>
> The comment "/* MIPS architecture level */" was present both
> before and after the commit 45506bdd. The scope of this patch
> is to rollback a duplicate preprocessor definition originating
> from the commit 45506bdd. This means that moving/modifying
> comments should not be in this patch. Can you please clarify
> for me what additional changes you suggest (but these should
> definitely be in a separate patch)? Do you want to sync this
> segment of QEMU's elf.h (copied below) with glibc corresponding
> section from its elf.h (also below)?

It seems to me that the logical place for defining EF_MIPS_ARCH
is next to the definitions EF_MIPS_ARCH_1  which give the
valid values for that field. It's likely because the
pre-45506bdd QEMU header didn't put the two together as
you'd expect that the duplicate got added.

We should fix the duplication not by just rolling back to
pre-45506bdd, but in a way that gets us to having the
EF_MIPS_ARCH and EF_MIPS_ARCH_1  in the same place in
the file. The simplest way to do that is just to delete
the second (original) EF_MIPS_ARCH #define, the one just
below the EF_MIPS_NAN2008 define.

We could line up with the order the glibc headers use, but
that seems like overkill compared to just deleting a line.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v5 24/24] slirp: fix ipv6 timers

[Samuel Thibault]

Pavel Dovgalyuk, le mar. 31 juil. 2018 09:58:26 +0300, a ecrit:
> > From: Samuel Thibault [mailto:samuel.thiba...@gnu.org]
> > Pavel Dovgalyuk, le jeu. 26 juil. 2018 11:37:57 +0300, a ecrit:
> > > Or the timers are related to the network devices (e.g., servers in the
> > > outer world)?
> > 
> > No.
> > 
> > > > > > > this service is not related to the guest state.
> > > >
> > > > seems incorrect. At the moment the ip6_icmp timer's current value is not
> > > > saved in the guest state, but in principle it should, so that the guest
> > > > does see the RAs at a regular rate. In practice we don't care because
> > > > the timing is randomized anyway.
> > >
> > > Isn't this just a side effect?
> > > I mean that slirp may be replaced by, say, tap, and the guest should not 
> > > notice
> > > the difference.
> > 
> > Well, if a guest is connected through a tap, the virtual time should
> > really run as fast as the realtime, and it should not be paused.
> > Otherwise TCP connections will break since the guest won't be able to
> > reply fast enough, without even knowing about the issue. Slirp can
> > compensate this thanks to a buffer between what happens in the real
> > world and what happens in the virtual world. Real world timings are
> > handled by the OS socket implementation, and virtual world timings are
> > handled with the qemu timer.
> 
> Then maybe the solution is the new clock with the frequency of the virtual
> clock, but which does not affect the replayed core?
> This clock should stop when VM is paused.
> It also could be saved in vmstate. As it does not affect the replay,
> saving and restoring its state won't break anything.

I guess so.

Samuel

Re: [Qemu-devel] [PATCH v5 07/76] elf: Remove duplicate preprocessor constant definition

[Aleksandar Markovic]

Hi again, Laurent.

Did you mean to move the comment from THE CURRENT to THE RIGHT position, as 
displayed here:

QEMU's elf.h:

/* MIPS architecture level. */  <--- THE CURRENT POSITION
#define EF_MIPS_ARCH0xf000 <- duplicate

/* Legal values for MIPS architecture level.  */
#define EF_MIPS_ARCH_1  0x  /* -mips1 code.  */
#define EF_MIPS_ARCH_2  0x1000  /* -mips2 code.  */
#define EF_MIPS_ARCH_3  0x2000  /* -mips3 code.  */
#define EF_MIPS_ARCH_4  0x3000  /* -mips4 code.  */
#define EF_MIPS_ARCH_5  0x4000  /* -mips5 code.  */
#define EF_MIPS_ARCH_32 0x5000  /* MIPS32 code.  */
#define EF_MIPS_ARCH_64 0x6000  /* MIPS64 code.  */
#define EF_MIPS_ARCH_32R2   0x7000  /* MIPS32r2 code.  */
#define EF_MIPS_ARCH_64R2   0x8000  /* MIPS64r2 code.  */
#define EF_MIPS_ARCH_32R6   0x9000  /* MIPS32r6 code.  */
#define EF_MIPS_ARCH_64R6   0xa000  /* MIPS64r6 code.  */

/* The ABI of a file. */
#define EF_MIPS_ABI_O32 0x1000  /* O32 ABI.  */
#define EF_MIPS_ABI_O64 0x2000  /* O32 extended for 64 bit.  */

#define EF_MIPS_NOREORDER 0x0001
#define EF_MIPS_PIC   0x0002
#define EF_MIPS_CPIC  0x0004
#define EF_MIPS_ABI20x0020
#define EF_MIPS_OPTIONS_FIRST   0x0080
#define EF_MIPS_32BITMODE   0x0100
#define EF_MIPS_ABI 0xf000
#define EF_MIPS_FP64  0x0200
#define EF_MIPS_NAN2008   0x0400
#define EF_MIPS_ARCH  0xf000 /* MIPS architecture level. */ <--- THE 
RIGHT POSITION



> From: Aleksandar Markovic
> Sent: Wednesday, August 1, 2018 8:51 PM
> 
> Hi, Laurent.
> 
> > From: Laurent Vivier 
> > Sent: Monday, July 30, 2018 6:49 PM
> >
> > Le 30/07/2018 à 18:11, Aleksandar Markovic a écrit :
> > > From: Aleksandar Markovic 
> > >
> > > Remove duplicate preprocessor constant definition for EF_MIPS_ARCH.
> > >
> > > The duplicate was introduced in commit 45506bdd.
> > >
> > > Signed-off-by: Aleksandar Markovic 
> > > Reviewed-by: Richard Henderson 
> > > ---
> > >  include/elf.h | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/include/elf.h b/include/elf.h
> > > index 934dbbd..c8aaa2a 100644
> > > --- a/include/elf.h
> > > +++ b/include/elf.h
> > > @@ -33,7 +33,6 @@ typedef int64_t  Elf64_Sxword;
> > >
> > >  /* Flags in the e_flags field of the header */
> > >  /* MIPS architecture level. */
> > > -#define EF_MIPS_ARCH0xf000
> > >
> > >  /* Legal values for MIPS architecture level.  */
> > >  #define EF_MIPS_ARCH_1   0x  /* -mips1 code.  */
> > >
> >
> > You should move the comment "MIPS architecture level" where the other
> > EF_MIPS_ARCH is defined (see glibc or system elf.h).
> >
> > Thanks,
> > Laurent
> 
> The comment "/* MIPS architecture level */" was present both before and after 
> the commit 45506bdd. The scope of this patch is to rollback a duplicate 
> preprocessor definition originating from the commit 45506bdd. This means that 
> moving/modifying comments should not be in this patch. Can you please clarify 
> for me what additional changes you suggest (but these should definitely be in 
> a separate patch)? Do you want to sync this segment of QEMU's elf.h (copied 
> below) with glibc corresponding section from its elf.h (also below)?
> 
> QEMU's elf.h:
> 
> /* MIPS architecture level. */
> #define EF_MIPS_ARCH0xf000 <- duplicate
> 
> /* Legal values for MIPS architecture level.  */
> #define EF_MIPS_ARCH_1  0x  /* -mips1 code.  */
> #define EF_MIPS_ARCH_2  0x1000  /* -mips2 code.  */
> #define EF_MIPS_ARCH_3  0x2000  /* -mips3 code.  */
> #define EF_MIPS_ARCH_4  0x3000  /* -mips4 code.  */
> #define EF_MIPS_ARCH_5  0x4000  /* -mips5 code.  */
> #define EF_MIPS_ARCH_32 0x5000  /* MIPS32 code.  */
> #define EF_MIPS_ARCH_64 0x6000  /* MIPS64 code.  */
> #define EF_MIPS_ARCH_32R2   0x7000  /* MIPS32r2 code.  */
> #define EF_MIPS_ARCH_64R2   0x8000  /* MIPS64r2 code.  */
> #define EF_MIPS_ARCH_32R6   0x9000  /* MIPS32r6 code.  */
> #define EF_MIPS_ARCH_64R6   0xa000  /* MIPS64r6 code.  */
> 
> /* The ABI of a file. */
> #define EF_MIPS_ABI_O32 0x1000  /* O32 ABI.  */
> #define EF_MIPS_ABI_O64 0x2000  /* O32 extended for 64 bit.  
> */
> 
> #define EF_MIPS_NOREORDER 0x0001
> #define EF_MIPS_PIC   0x0002
> #define EF_MIPS_CPIC  0x0004
> #define EF_MIPS_ABI20x0020
> #define EF_MIPS_OPTIONS_FIRST   0x0080
> #define EF_MIPS_32BITMODE   0x0100
> #define EF_MIPS_ABI 0xf000
> #define EF_MIPS_FP64  0x0200
> #define EF_MIPS_NAN2008   0x0400
> #define EF_MIPS_ARCH  

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[John Snow]

On 08/01/2018 02:42 PM, Denis V. Lunev wrote:
> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
>> * John Snow (js...@redhat.com) wrote:
>>>
>>> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
 * John Snow (js...@redhat.com) wrote:

 

> I'd rather do something like this:
> - Always flush bitmaps to disk on inactivate.
 Does that increase the time taken by the inactivate measurably?
 If it's small relative to everything else that's fine; it's just I
 always worry a little since I think this happens after we've stopped the
 CPU on the source, so is part of the 'downtime'.

 Dave
 --
 Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

>>> I'm worried that if we don't, we're leaving behind unusable, partially
>>> complete files behind us. That's a bad design and we shouldn't push for
>>> it just because it's theoretically faster.
>> Oh I don't care about theoretical speed; but if it's actually unusably
>> slow in practice then it needs fixing.
>>
>> Dave
> 
> This is not "theoretical" speed. This is real practical speed and
> instability.

It's theoretical until I see performance testing numbers; do you have
any? How much faster does the pivot happen by avoiding making the qcow2
consistent on close?

I don't argue that it's faster to just simply not write data, but what's
not obvious is how much time it actually saves in practice and if that's
worth doing unintuitive and undocumented things like "the source file
loses bitmaps after a migration because it was faster."

> EACH IO operation can be performed unpredictably slow and thus with
> IO operations in mind you can not even calculate or predict downtime,
> which should be done according to the migration protocol.
> 
> That is why we have very specifically (for the purpose) improved
> migration protocol to migrate CBT via postcopy method, which
> does not influence downtime.
> 
> That is why we strictly opposes any CBT writing operation in migration
> code. It should also be noted, that CBT can be calculated for all discs,
> including raw but could be written for QCOW2 only. With external CBT storage
> for such discs the situation during migration would become even worse.
> 
> Den
> 

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Dr. David Alan Gilbert]

* Denis V. Lunev (d...@openvz.org) wrote:
> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
> > * John Snow (js...@redhat.com) wrote:
> >>
> >> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
> >>> * John Snow (js...@redhat.com) wrote:
> >>>
> >>> 
> >>>
>  I'd rather do something like this:
>  - Always flush bitmaps to disk on inactivate.
> >>> Does that increase the time taken by the inactivate measurably?
> >>> If it's small relative to everything else that's fine; it's just I
> >>> always worry a little since I think this happens after we've stopped the
> >>> CPU on the source, so is part of the 'downtime'.
> >>>
> >>> Dave
> >>> --
> >>> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> >>>
> >> I'm worried that if we don't, we're leaving behind unusable, partially
> >> complete files behind us. That's a bad design and we shouldn't push for
> >> it just because it's theoretically faster.
> > Oh I don't care about theoretical speed; but if it's actually unusably
> > slow in practice then it needs fixing.
> >
> > Dave
> 
> This is not "theoretical" speed. This is real practical speed and
> instability.
> EACH IO operation can be performed unpredictably slow and thus with
> IO operations in mind you can not even calculate or predict downtime,
> which should be done according to the migration protocol.

We end up doing some IO anyway, even ignoring these new bitmaps,
at the end of the migration when we pause the CPU, we do a
bdrv_inactivate_all to flush any outstanding writes; so we've already
got that unpredictable slowness.

So, not being a block person, but with some interest in making sure
downtime doesn't increase, I just wanted to understand whether the
amount of writes we're talking about here is comparable to that
which already exists or a lot smaller or a lot larger.
If the amount of IO you're talking about is much smaller than what
we typically already do, then John has a point and you may as well
do the write.
If the amount of IO for the bitmap is much larger and would slow
the downtime a lot then you've got a point and that would be unworkable.

Dave

> That is why we have very specifically (for the purpose) improved
> migration protocol to migrate CBT via postcopy method, which
> does not influence downtime.
> 
> That is why we strictly opposes any CBT writing operation in migration
> code. It should also be noted, that CBT can be calculated for all discs,
> including raw but could be written for QCOW2 only. With external CBT storage
> for such discs the situation during migration would become even worse.

> Den
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v5 07/76] elf: Remove duplicate preprocessor constant definition

[Aleksandar Markovic]

Hi, Laurent.

> From: Laurent Vivier 
> Sent: Monday, July 30, 2018 6:49 PM
> 
> Le 30/07/2018 à 18:11, Aleksandar Markovic a écrit :
> > From: Aleksandar Markovic 
> >
> > Remove duplicate preprocessor constant definition for EF_MIPS_ARCH.
> >
> > The duplicate was introduced in commit 45506bdd.
> >
> > Signed-off-by: Aleksandar Markovic 
> > Reviewed-by: Richard Henderson 
> > ---
> >  include/elf.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/include/elf.h b/include/elf.h
> > index 934dbbd..c8aaa2a 100644
> > --- a/include/elf.h
> > +++ b/include/elf.h
> > @@ -33,7 +33,6 @@ typedef int64_t  Elf64_Sxword;
> >
> >  /* Flags in the e_flags field of the header */
> >  /* MIPS architecture level. */
> > -#define EF_MIPS_ARCH0xf000
> >
> >  /* Legal values for MIPS architecture level.  */
> >  #define EF_MIPS_ARCH_1   0x  /* -mips1 code.  */
> >
> 
> You should move the comment "MIPS architecture level" where the other
> EF_MIPS_ARCH is defined (see glibc or system elf.h).
> 
> Thanks,
> Laurent

The comment "/* MIPS architecture level */" was present both before and after 
the commit 45506bdd. The scope of this patch is to rollback a duplicate 
preprocessor definition originating from the commit 45506bdd. This means that 
moving/modifying comments should not be in this patch. Can you please clarify 
for me what additional changes you suggest (but these should definitely be in a 
separate patch)? Do you want to sync this segment of QEMU's elf.h (copied 
below) with glibc corresponding section from its elf.h (also below)?

QEMU's elf.h:

/* MIPS architecture level. */
#define EF_MIPS_ARCH0xf000 <- duplicate

/* Legal values for MIPS architecture level.  */
#define EF_MIPS_ARCH_1  0x  /* -mips1 code.  */
#define EF_MIPS_ARCH_2  0x1000  /* -mips2 code.  */
#define EF_MIPS_ARCH_3  0x2000  /* -mips3 code.  */
#define EF_MIPS_ARCH_4  0x3000  /* -mips4 code.  */
#define EF_MIPS_ARCH_5  0x4000  /* -mips5 code.  */
#define EF_MIPS_ARCH_32 0x5000  /* MIPS32 code.  */
#define EF_MIPS_ARCH_64 0x6000  /* MIPS64 code.  */
#define EF_MIPS_ARCH_32R2   0x7000  /* MIPS32r2 code.  */
#define EF_MIPS_ARCH_64R2   0x8000  /* MIPS64r2 code.  */
#define EF_MIPS_ARCH_32R6   0x9000  /* MIPS32r6 code.  */
#define EF_MIPS_ARCH_64R6   0xa000  /* MIPS64r6 code.  */

/* The ABI of a file. */
#define EF_MIPS_ABI_O32 0x1000  /* O32 ABI.  */
#define EF_MIPS_ABI_O64 0x2000  /* O32 extended for 64 bit.  */

#define EF_MIPS_NOREORDER 0x0001
#define EF_MIPS_PIC   0x0002
#define EF_MIPS_CPIC  0x0004
#define EF_MIPS_ABI20x0020
#define EF_MIPS_OPTIONS_FIRST   0x0080
#define EF_MIPS_32BITMODE   0x0100
#define EF_MIPS_ABI 0xf000
#define EF_MIPS_FP64  0x0200
#define EF_MIPS_NAN2008   0x0400
#define EF_MIPS_ARCH  0xf000


glibc's elf.h:

/* Legal values for e_flags field of Elf32_Ehdr.  */

#define EF_MIPS_NOREORDER   1 /* A .noreorder directive was used.  */
#define EF_MIPS_PIC 2 /* Contains PIC code.  */
#define EF_MIPS_CPIC4 /* Uses PIC calling sequence.  */
#define EF_MIPS_XGOT8
#define EF_MIPS_64BIT_WHIRL 16
#define EF_MIPS_ABI232
#define EF_MIPS_ABI_ON3264
#define EF_MIPS_FP64512  /* Uses FP64 (12 callee-saved).  */
#define EF_MIPS_NAN2008 1024  /* Uses IEEE 754-2008 NaN encoding.  */
#define EF_MIPS_ARCH0xf000 /* MIPS architecture level.  */

/* Legal values for MIPS architecture level.  */

#define EF_MIPS_ARCH_1  0x /* -mips1 code.  */
#define EF_MIPS_ARCH_2  0x1000 /* -mips2 code.  */
#define EF_MIPS_ARCH_3  0x2000 /* -mips3 code.  */
#define EF_MIPS_ARCH_4  0x3000 /* -mips4 code.  */
#define EF_MIPS_ARCH_5  0x4000 /* -mips5 code.  */
#define EF_MIPS_ARCH_32 0x5000 /* MIPS32 code.  */
#define EF_MIPS_ARCH_64 0x6000 /* MIPS64 code.  */
#define EF_MIPS_ARCH_32R2   0x7000 /* MIPS32r2 code.  */
#define EF_MIPS_ARCH_64R2   0x8000 /* MIPS64r2 code.  */


Regards,
Aleksandar

Re: [Qemu-devel] [PATCH v4 0/2] s390x: Enable KVM huge page backing support

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180801131905.148778-1-fran...@linux.ibm.com
Subject: [Qemu-devel] [PATCH v4 0/2] s390x: Enable KVM huge page backing support

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
4290dbe857 s390x: Enable KVM huge page backing support
adfd7a6890 kvm: sync linux headers

=== OUTPUT BEGIN ===
Checking PATCH 1/2: kvm: sync linux headers...
Checking PATCH 2/2: s390x: Enable KVM huge page backing support...
ERROR: braces {} are necessary for all arms of this statement
#59: FILE: target/s390x/kvm.c:291:
+if (path_psize == 4 * KiB)
[...]

total: 1 errors, 0 warnings, 63 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [Bug 1784919] [NEW] native libgfapi glusterfs support for virtio 9p filesystem passthrough

[Hans]

Public bug reported:

I can add block devices on glusterfs natively to my virtual machines since qemu 
1.3 
I would like to see the same feature for virtio 9p filesystems added on my VM. 

Accessing a filesystem mounted on the Metal is my favorite solution for
storage that is to be shared between more than one VM. But because my
VMs are not running as root, they are not able to passthrough userids
and gids to gluster-fuse. uid mapping is also not possible because no
xattr support.

So all I can do is either setting up seperate NFS Servers to bring the
Filesystem in via Network, or to start qemu as root or to add fuse_xattr
on top of glusterfs_fuse. I do expect however that the fastest and most
relieable solution is to make something like this possible:

-fsdev
local,id=test_dev,path=gluster://this.node/test_mount,security_model=passthrough
-device virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount

regards

Hans

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784919

Title:
  native libgfapi  glusterfs support for virtio 9p filesystem
  passthrough

Status in QEMU:
  New

Bug description:
  I can add block devices on glusterfs natively to my virtual machines since 
qemu 1.3 
  I would like to see the same feature for virtio 9p filesystems added on my 
VM. 

  Accessing a filesystem mounted on the Metal is my favorite solution
  for storage that is to be shared between more than one VM. But because
  my VMs are not running as root, they are not able to passthrough
  userids and gids to gluster-fuse. uid mapping is also not possible
  because no xattr support.

  So all I can do is either setting up seperate NFS Servers to bring the
  Filesystem in via Network, or to start qemu as root or to add
  fuse_xattr on top of glusterfs_fuse. I do expect however that the
  fastest and most relieable solution is to make something like this
  possible:

  -fsdev
  
local,id=test_dev,path=gluster://this.node/test_mount,security_model=passthrough
  -device virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount

  regards

  Hans

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784919/+subscriptions

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Denis V. Lunev]

On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
> * John Snow (js...@redhat.com) wrote:
>>
>> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
>>> * John Snow (js...@redhat.com) wrote:
>>>
>>> 
>>>
 I'd rather do something like this:
 - Always flush bitmaps to disk on inactivate.
>>> Does that increase the time taken by the inactivate measurably?
>>> If it's small relative to everything else that's fine; it's just I
>>> always worry a little since I think this happens after we've stopped the
>>> CPU on the source, so is part of the 'downtime'.
>>>
>>> Dave
>>> --
>>> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>>>
>> I'm worried that if we don't, we're leaving behind unusable, partially
>> complete files behind us. That's a bad design and we shouldn't push for
>> it just because it's theoretically faster.
> Oh I don't care about theoretical speed; but if it's actually unusably
> slow in practice then it needs fixing.
>
> Dave

This is not "theoretical" speed. This is real practical speed and
instability.
EACH IO operation can be performed unpredictably slow and thus with
IO operations in mind you can not even calculate or predict downtime,
which should be done according to the migration protocol.

That is why we have very specifically (for the purpose) improved
migration protocol to migrate CBT via postcopy method, which
does not influence downtime.

That is why we strictly opposes any CBT writing operation in migration
code. It should also be noted, that CBT can be calculated for all discs,
including raw but could be written for QCOW2 only. With external CBT storage
for such discs the situation during migration would become even worse.

Den

Re: [Qemu-devel] [PATCH] qemu-binfmt-conf.sh: add x86_64 target

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180801102944.23457-1-laur...@vivier.eu
Subject: [Qemu-devel] [PATCH] qemu-binfmt-conf.sh: add x86_64 target

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
50e6cc3a12 qemu-binfmt-conf.sh: add x86_64 target

=== OUTPUT BEGIN ===
Checking PATCH 1/1: qemu-binfmt-conf.sh: add x86_64 target...
WARNING: line over 80 characters
#28: FILE: scripts/qemu-binfmt-conf.sh:17:
+x86_64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00'

ERROR: line over 90 characters
#29: FILE: scripts/qemu-binfmt-conf.sh:18:
+x86_64_mask='\xff\xff\xff\xff\xff\xfe\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'

total: 1 errors, 1 warnings, 18 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[Dr. David Alan Gilbert]

* John Snow (js...@redhat.com) wrote:
> 
> 
> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
> > * John Snow (js...@redhat.com) wrote:
> > 
> > 
> > 
> >> I'd rather do something like this:
> >> - Always flush bitmaps to disk on inactivate.
> > 
> > Does that increase the time taken by the inactivate measurably?
> > If it's small relative to everything else that's fine; it's just I
> > always worry a little since I think this happens after we've stopped the
> > CPU on the source, so is part of the 'downtime'.
> > 
> > Dave
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > 
> 
> I'm worried that if we don't, we're leaving behind unusable, partially
> complete files behind us. That's a bad design and we shouldn't push for
> it just because it's theoretically faster.

Oh I don't care about theoretical speed; but if it's actually unusably
slow in practice then it needs fixing.

Dave

> --js
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[John Snow]

On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
> * John Snow (js...@redhat.com) wrote:
> 
> 
> 
>> I'd rather do something like this:
>> - Always flush bitmaps to disk on inactivate.
> 
> Does that increase the time taken by the inactivate measurably?
> If it's small relative to everything else that's fine; it's just I
> always worry a little since I think this happens after we've stopped the
> CPU on the source, so is part of the 'downtime'.
> 
> Dave
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> 

I'm worried that if we don't, we're leaving behind unusable, partially
complete files behind us. That's a bad design and we shouldn't push for
it just because it's theoretically faster.

--js

[Qemu-devel] [Bug 1784900] Re: QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline

[Dr. David Alan Gilbert]

I also hit this with gtk frontend rather than vnc althought he backtrace
looks very different.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784900

Title:
  QEMU (frontend) crashes upon warm reboot with virtio-gpu device and
  vga=775 on Linux cmdline

Status in QEMU:
  New

Bug description:
  With vga=775 on the Linux command line a first boot of the VM running
  Linux works fine. After a warm reboot it crashes during Linux boot.
  The VM was used remotely via virt-manager and VNC.

  Bisecting the code lead to the following patch that introduced the
  bug:

  commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
  Author: Gerd Hoffmann 
  Date:   Mon Jul 2 18:24:43 2018 +0200

  virtio-gpu: disable scanout when backing resource is destroyed

  Signed-off-by: Gerd Hoffmann 
  Reviewed-by: Marc-André Lureau 
  Message-id: 20180702162443.16796-4-kra...@redhat.com

  diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
  index 336dc59007..08cd567218 100644
  --- a/hw/display/virtio-gpu.c
  +++ b/hw/display/virtio-gpu.c
  @@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int 
scanout_id)
   static void virtio_gpu_resource_destroy(VirtIOGPU *g,
   struct virtio_gpu_simple_resource 
*res)
   {
  +int i;
  +
  +if (res->scanout_bitmask) {
  +for (i = 0; i < g->conf.max_outputs; i++) {
  +if (res->scanout_bitmask & (1 << i)) {
  +virtio_gpu_disable_scanout(g, i);
  +}
  +}
  +}
  +
   pixman_image_unref(res->image);
   virtio_gpu_cleanup_mapping(res);
   QTAILQ_REMOVE(>reslist, res, next);

  
  Reported backtraces can be found here:  
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784900/+subscriptions

Re: [Qemu-devel] [PATCH] es1370: simplify MemoryRegionOps

[Philippe Mathieu-Daudé]

On 08/01/2018 02:06 PM, Paolo Bonzini wrote:
> Use the automatic subregister extraction from the memory API, and avoid
> that Coverity complains about missing fallthrough comments.
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/audio/es1370.c | 235 +-
>  1 file changed, 25 insertions(+), 210 deletions(-)
> 
> diff --git a/hw/audio/es1370.c b/hw/audio/es1370.c
> index 59cf252754..dd75c9e8f5 100644
> --- a/hw/audio/es1370.c
> +++ b/hw/audio/es1370.c
> @@ -474,82 +474,7 @@ static inline uint32_t es1370_fixup (ES1370State *s, 
> uint32_t addr)
>  return addr;
>  }
>  
> -static void es1370_writeb(void *opaque, uint32_t addr, uint32_t val)
> -{
> -ES1370State *s = opaque;
> -uint32_t shift, mask;
> -
> -addr = es1370_fixup (s, addr);
> -
> -switch (addr) {
> -case ES1370_REG_CONTROL:
> -case ES1370_REG_CONTROL + 1:
> -case ES1370_REG_CONTROL + 2:
> -case ES1370_REG_CONTROL + 3:
> -shift = (addr - ES1370_REG_CONTROL) << 3;
> -mask = 0xff << shift;
> -val = (s->ctl & ~mask) | ((val & 0xff) << shift);
> -es1370_update_voices (s, val, s->sctl);
> -print_ctl (val);
> -break;
> -case ES1370_REG_MEMPAGE:
> -s->mempage = val;
> -break;
> -case ES1370_REG_SERIAL_CONTROL:
> -case ES1370_REG_SERIAL_CONTROL + 1:
> -case ES1370_REG_SERIAL_CONTROL + 2:
> -case ES1370_REG_SERIAL_CONTROL + 3:
> -shift = (addr - ES1370_REG_SERIAL_CONTROL) << 3;
> -mask = 0xff << shift;
> -val = (s->sctl & ~mask) | ((val & 0xff) << shift);

I guess this code bypass the access_with_adjusted_size() big-endian
bug... But I have no idea if this devices on BE platforms, so for this
nice cleanup:
Reviewed-by: Philippe Mathieu-Daudé 

> -es1370_maybe_lower_irq (s, val);
> -es1370_update_voices (s, s->ctl, val);
> -print_sctl (val);
> -break;
> -default:
> -lwarn ("writeb %#x <- %#x\n", addr, val);
> -break;
> -}
> -}
> -
> -static void es1370_writew(void *opaque, uint32_t addr, uint32_t val)
> -{
> -ES1370State *s = opaque;
> -addr = es1370_fixup (s, addr);
> -uint32_t shift, mask;
> -struct chan *d = >chan[0];
> -
> -switch (addr) {
> -case ES1370_REG_CODEC:
> -dolog ("ignored codec write address %#x, data %#x\n",
> -   (val >> 8) & 0xff, val & 0xff);
> -s->codec = val;
> -break;
> -
> -case ES1370_REG_CONTROL:
> -case ES1370_REG_CONTROL + 2:
> -shift = (addr != ES1370_REG_CONTROL) << 4;
> -mask = 0x << shift;
> -val = (s->ctl & ~mask) | ((val & 0x) << shift);
> -es1370_update_voices (s, val, s->sctl);
> -print_ctl (val);
> -break;
> -
> -case ES1370_REG_ADC_SCOUNT:
> -d++;
> -case ES1370_REG_DAC2_SCOUNT:
> -d++;
> -case ES1370_REG_DAC1_SCOUNT:
> -d->scount = (d->scount & ~0x) | (val & 0x);
> -break;
> -
> -default:
> -lwarn ("writew %#x <- %#x\n", addr, val);
> -break;
> -}
> -}
> -
> -static void es1370_writel(void *opaque, uint32_t addr, uint32_t val)
> +static void es1370_write(void *opaque, hwaddr addr, uint64_t val, unsigned 
> size)
>  {
>  ES1370State *s = opaque;
>  struct chan *d = >chan[0];
> @@ -572,21 +497,19 @@ static void es1370_writel(void *opaque, uint32_t addr, 
> uint32_t val)
>  print_sctl (val);
>  break;
>  
> -case ES1370_REG_ADC_SCOUNT:
> -d++;
> -case ES1370_REG_DAC2_SCOUNT:
> -d++;
>  case ES1370_REG_DAC1_SCOUNT:
> +case ES1370_REG_DAC2_SCOUNT:
> +case ES1370_REG_ADC_SCOUNT:
> +d += (addr - ES1370_REG_DAC1_SCOUNT) >> 2;
>  d->scount = (val & 0x) | (d->scount & ~0x);
>  ldebug ("chan %td CURR_SAMP_CT %d, SAMP_CT %d\n",
>  d - >chan[0], val >> 16, (val & 0x));
>  break;
>  
> -case ES1370_REG_ADC_FRAMEADR:
> -d++;
> -case ES1370_REG_DAC2_FRAMEADR:
> -d++;
>  case ES1370_REG_DAC1_FRAMEADR:
> +case ES1370_REG_DAC2_FRAMEADR:
> +case ES1370_REG_ADC_FRAMEADR:
> +d += (addr - ES1370_REG_DAC1_FRAMEADR) >> 3;
>  d->frame_addr = val;
>  ldebug ("chan %td frame address %#x\n", d - >chan[0], val);
>  break;
> @@ -598,11 +521,10 @@ static void es1370_writel(void *opaque, uint32_t addr, 
> uint32_t val)
>  lwarn ("writing to phantom frame address %#x\n", val);
>  break;
>  
> -case ES1370_REG_ADC_FRAMECNT:
> -d++;
> -case ES1370_REG_DAC2_FRAMECNT:
> -d++;
>  case ES1370_REG_DAC1_FRAMECNT:
> +case ES1370_REG_DAC2_FRAMECNT:
> +case ES1370_REG_ADC_FRAMECNT:
> +d += (addr - ES1370_REG_DAC1_FRAMECNT) >> 3;
>  d->frame_cnt = val;
>  d->leftover = 0;
>  ldebug ("chan %td frame count %d, buffer size %d\n",
> @@ -615,84 +537,7 @@ static void 

Re: [Qemu-devel] [PATCH v5 19/76] target/mips: Add emulation of nanoMIPS 16-bit arithmetic instructions

[Richard Henderson]

On 08/01/2018 12:02 PM, Aleksandar Markovic wrote:
>> I suggest a "target_long imm;" at the top of the function to handle all such
>> that will be required when this function is filled out.
> 
> gen_arith_imm() and similar functions have "int" as the type of offset/imm 
> parameter (in this case the last parameter) - shouldn't "int" be more 
> appropriate type for local variable than "target_long"?
Fair enough.  It certainly fits all of the immediates that nanomips can 
generate.

If you eventually split up gen_arith_imm etc as previously suggested, I suggest
changing to target_long though.  That would allow e.g. the decode for the
MIPS64R6 DATI and DAHI instructions to use the basic gen_daddiu expander with
the immediate already shifted into place in the high 32 bits.


r~

[Qemu-devel] [PATCH] es1370: simplify MemoryRegionOps

[Paolo Bonzini]

Use the automatic subregister extraction from the memory API, and avoid
that Coverity complains about missing fallthrough comments.

Signed-off-by: Paolo Bonzini 
---
 hw/audio/es1370.c | 235 +-
 1 file changed, 25 insertions(+), 210 deletions(-)

diff --git a/hw/audio/es1370.c b/hw/audio/es1370.c
index 59cf252754..dd75c9e8f5 100644
--- a/hw/audio/es1370.c
+++ b/hw/audio/es1370.c
@@ -474,82 +474,7 @@ static inline uint32_t es1370_fixup (ES1370State *s, 
uint32_t addr)
 return addr;
 }
 
-static void es1370_writeb(void *opaque, uint32_t addr, uint32_t val)
-{
-ES1370State *s = opaque;
-uint32_t shift, mask;
-
-addr = es1370_fixup (s, addr);
-
-switch (addr) {
-case ES1370_REG_CONTROL:
-case ES1370_REG_CONTROL + 1:
-case ES1370_REG_CONTROL + 2:
-case ES1370_REG_CONTROL + 3:
-shift = (addr - ES1370_REG_CONTROL) << 3;
-mask = 0xff << shift;
-val = (s->ctl & ~mask) | ((val & 0xff) << shift);
-es1370_update_voices (s, val, s->sctl);
-print_ctl (val);
-break;
-case ES1370_REG_MEMPAGE:
-s->mempage = val;
-break;
-case ES1370_REG_SERIAL_CONTROL:
-case ES1370_REG_SERIAL_CONTROL + 1:
-case ES1370_REG_SERIAL_CONTROL + 2:
-case ES1370_REG_SERIAL_CONTROL + 3:
-shift = (addr - ES1370_REG_SERIAL_CONTROL) << 3;
-mask = 0xff << shift;
-val = (s->sctl & ~mask) | ((val & 0xff) << shift);
-es1370_maybe_lower_irq (s, val);
-es1370_update_voices (s, s->ctl, val);
-print_sctl (val);
-break;
-default:
-lwarn ("writeb %#x <- %#x\n", addr, val);
-break;
-}
-}
-
-static void es1370_writew(void *opaque, uint32_t addr, uint32_t val)
-{
-ES1370State *s = opaque;
-addr = es1370_fixup (s, addr);
-uint32_t shift, mask;
-struct chan *d = >chan[0];
-
-switch (addr) {
-case ES1370_REG_CODEC:
-dolog ("ignored codec write address %#x, data %#x\n",
-   (val >> 8) & 0xff, val & 0xff);
-s->codec = val;
-break;
-
-case ES1370_REG_CONTROL:
-case ES1370_REG_CONTROL + 2:
-shift = (addr != ES1370_REG_CONTROL) << 4;
-mask = 0x << shift;
-val = (s->ctl & ~mask) | ((val & 0x) << shift);
-es1370_update_voices (s, val, s->sctl);
-print_ctl (val);
-break;
-
-case ES1370_REG_ADC_SCOUNT:
-d++;
-case ES1370_REG_DAC2_SCOUNT:
-d++;
-case ES1370_REG_DAC1_SCOUNT:
-d->scount = (d->scount & ~0x) | (val & 0x);
-break;
-
-default:
-lwarn ("writew %#x <- %#x\n", addr, val);
-break;
-}
-}
-
-static void es1370_writel(void *opaque, uint32_t addr, uint32_t val)
+static void es1370_write(void *opaque, hwaddr addr, uint64_t val, unsigned 
size)
 {
 ES1370State *s = opaque;
 struct chan *d = >chan[0];
@@ -572,21 +497,19 @@ static void es1370_writel(void *opaque, uint32_t addr, 
uint32_t val)
 print_sctl (val);
 break;
 
-case ES1370_REG_ADC_SCOUNT:
-d++;
-case ES1370_REG_DAC2_SCOUNT:
-d++;
 case ES1370_REG_DAC1_SCOUNT:
+case ES1370_REG_DAC2_SCOUNT:
+case ES1370_REG_ADC_SCOUNT:
+d += (addr - ES1370_REG_DAC1_SCOUNT) >> 2;
 d->scount = (val & 0x) | (d->scount & ~0x);
 ldebug ("chan %td CURR_SAMP_CT %d, SAMP_CT %d\n",
 d - >chan[0], val >> 16, (val & 0x));
 break;
 
-case ES1370_REG_ADC_FRAMEADR:
-d++;
-case ES1370_REG_DAC2_FRAMEADR:
-d++;
 case ES1370_REG_DAC1_FRAMEADR:
+case ES1370_REG_DAC2_FRAMEADR:
+case ES1370_REG_ADC_FRAMEADR:
+d += (addr - ES1370_REG_DAC1_FRAMEADR) >> 3;
 d->frame_addr = val;
 ldebug ("chan %td frame address %#x\n", d - >chan[0], val);
 break;
@@ -598,11 +521,10 @@ static void es1370_writel(void *opaque, uint32_t addr, 
uint32_t val)
 lwarn ("writing to phantom frame address %#x\n", val);
 break;
 
-case ES1370_REG_ADC_FRAMECNT:
-d++;
-case ES1370_REG_DAC2_FRAMECNT:
-d++;
 case ES1370_REG_DAC1_FRAMECNT:
+case ES1370_REG_DAC2_FRAMECNT:
+case ES1370_REG_ADC_FRAMECNT:
+d += (addr - ES1370_REG_DAC1_FRAMECNT) >> 3;
 d->frame_cnt = val;
 d->leftover = 0;
 ldebug ("chan %td frame count %d, buffer size %d\n",
@@ -615,84 +537,7 @@ static void es1370_writel(void *opaque, uint32_t addr, 
uint32_t val)
 }
 }
 
-static uint32_t es1370_readb(void *opaque, uint32_t addr)
-{
-ES1370State *s = opaque;
-uint32_t val;
-
-addr = es1370_fixup (s, addr);
-
-switch (addr) {
-case 0x1b:  /* Legacy */
-lwarn ("Attempt to read from legacy register\n");
-val = 5;
-break;
-case ES1370_REG_MEMPAGE:
-val = s->mempage;
-break;
-case ES1370_REG_CONTROL + 0:
-case ES1370_REG_CONTROL + 1:
-

Re: [Qemu-devel] [PATCH v5 23/24] replay: add BH oneshot event for block layer

[Paolo Bonzini]

On 26/07/2018 19:17, Alex Bennée wrote:
>> +
>> +void replay_bh_schedule_oneshot_event(AioContext *ctx,
>> +QEMUBHFunc *cb,void *opaque)
>> +{
>> +aio_bh_schedule_oneshot(ctx, cb, opaque);
>> +}
> It seems wrong to have something in stubs that actively does stuff.
> Isn't this meant to be a bunch of NOPs?

No, not necessarily, for example

int64_t cpu_get_clock(void)
{
return get_clock_realtime();
}

or even

void error_vprintf(const char *fmt, va_list ap)
{
if (g_test_initialized() && !g_test_subprocess() &&
getenv("QTEST_SILENT_ERRORS")) {
char *msg = g_strdup_vprintf(fmt, ap);
g_test_message("%s", msg);
g_free(msg);
} else {
vfprintf(stderr, fmt, ap);
}
}

Paolo

[Qemu-devel] [Bug 1784900] Re: QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline

[Daniel Berrange]

** Summary changed:

- QEMU (frontend) crashes upon warm reboot with vga=775 on Linux cmdline
+ QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 
on Linux cmdline

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784900

Title:
  QEMU (frontend) crashes upon warm reboot with virtio-gpu device and
  vga=775 on Linux cmdline

Status in QEMU:
  New

Bug description:
  With vga=775 on the Linux command line a first boot of the VM running
  Linux works fine. After a warm reboot it crashes during Linux boot.
  The VM was used remotely via virt-manager and VNC.

  Bisecting the code lead to the following patch that introduced the
  bug:

  commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
  Author: Gerd Hoffmann 
  Date:   Mon Jul 2 18:24:43 2018 +0200

  virtio-gpu: disable scanout when backing resource is destroyed

  Signed-off-by: Gerd Hoffmann 
  Reviewed-by: Marc-André Lureau 
  Message-id: 20180702162443.16796-4-kra...@redhat.com

  diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
  index 336dc59007..08cd567218 100644
  --- a/hw/display/virtio-gpu.c
  +++ b/hw/display/virtio-gpu.c
  @@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int 
scanout_id)
   static void virtio_gpu_resource_destroy(VirtIOGPU *g,
   struct virtio_gpu_simple_resource 
*res)
   {
  +int i;
  +
  +if (res->scanout_bitmask) {
  +for (i = 0; i < g->conf.max_outputs; i++) {
  +if (res->scanout_bitmask & (1 << i)) {
  +virtio_gpu_disable_scanout(g, i);
  +}
  +}
  +}
  +
   pixman_image_unref(res->image);
   virtio_gpu_cleanup_mapping(res);
   QTAILQ_REMOVE(>reslist, res, next);

  
  Reported backtraces can be found here:  
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784900/+subscriptions

[Qemu-devel] [Bug 1784900] [NEW] QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline

[Stefan Berger]

Public bug reported:

With vga=775 on the Linux command line a first boot of the VM running
Linux works fine. After a warm reboot it crashes during Linux boot. The
VM was used remotely via virt-manager and VNC.

Bisecting the code lead to the following patch that introduced the bug:

commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
Author: Gerd Hoffmann 
Date:   Mon Jul 2 18:24:43 2018 +0200

virtio-gpu: disable scanout when backing resource is destroyed

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Marc-André Lureau 
Message-id: 20180702162443.16796-4-kra...@redhat.com

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 336dc59007..08cd567218 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int 
scanout_id)
 static void virtio_gpu_resource_destroy(VirtIOGPU *g,
 struct virtio_gpu_simple_resource *res)
 {
+int i;
+
+if (res->scanout_bitmask) {
+for (i = 0; i < g->conf.max_outputs; i++) {
+if (res->scanout_bitmask & (1 << i)) {
+virtio_gpu_disable_scanout(g, i);
+}
+}
+}
+
 pixman_image_unref(res->image);
 virtio_gpu_cleanup_mapping(res);
 QTAILQ_REMOVE(>reslist, res, next);


Reported backtraces can be found here:  
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1784900

Title:
  QEMU (frontend) crashes upon warm reboot with virtio-gpu device and
  vga=775 on Linux cmdline

Status in QEMU:
  New

Bug description:
  With vga=775 on the Linux command line a first boot of the VM running
  Linux works fine. After a warm reboot it crashes during Linux boot.
  The VM was used remotely via virt-manager and VNC.

  Bisecting the code lead to the following patch that introduced the
  bug:

  commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad)
  Author: Gerd Hoffmann 
  Date:   Mon Jul 2 18:24:43 2018 +0200

  virtio-gpu: disable scanout when backing resource is destroyed

  Signed-off-by: Gerd Hoffmann 
  Reviewed-by: Marc-André Lureau 
  Message-id: 20180702162443.16796-4-kra...@redhat.com

  diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
  index 336dc59007..08cd567218 100644
  --- a/hw/display/virtio-gpu.c
  +++ b/hw/display/virtio-gpu.c
  @@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int 
scanout_id)
   static void virtio_gpu_resource_destroy(VirtIOGPU *g,
   struct virtio_gpu_simple_resource 
*res)
   {
  +int i;
  +
  +if (res->scanout_bitmask) {
  +for (i = 0; i < g->conf.max_outputs; i++) {
  +if (res->scanout_bitmask & (1 << i)) {
  +virtio_gpu_disable_scanout(g, i);
  +}
  +}
  +}
  +
   pixman_image_unref(res->image);
   virtio_gpu_cleanup_mapping(res);
   QTAILQ_REMOVE(>reslist, res, next);

  
  Reported backtraces can be found here:  
https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1784900/+subscriptions

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 2/2] s390x: Enable KVM huge page backing support

[Thomas Huth]

On 08/01/2018 03:19 PM, Janosch Frank wrote:
> QEMU has had huge page support for a longer time already, but KVM
> memory management under s390x needed some changes to work with huge
> backings.
> 
> Now that we have support, let's enable it if requested and
> available. Otherwise we now properly tell the user if there is no
> support and back out instead of failing to run the VM later on.
> 
> Signed-off-by: Janosch Frank 
> ---
>  target/s390x/kvm.c | 34 --
>  1 file changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index d923cf4240..d1c72975cf 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -34,6 +34,8 @@
>  #include "qapi/error.h"
>  #include "qemu/error-report.h"
>  #include "qemu/timer.h"
> +#include "qemu/units.h"
> +#include "qemu/mmap-alloc.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/hw_accel.h"
>  #include "hw/hw.h"
> @@ -139,6 +141,7 @@ static int cap_mem_op;
>  static int cap_s390_irq;
>  static int cap_ri;
>  static int cap_gs;
> +static int cap_hpage_1m;
>  
>  static int active_cmma;
>  
> @@ -220,9 +223,9 @@ static void kvm_s390_enable_cmma(void)
>  .attr = KVM_S390_VM_MEM_ENABLE_CMMA,
>  };
>  
> -if (mem_path) {
> +if (cap_hpage_1m) {
>  warn_report("CMM will not be enabled because it is not "
> -"compatible with hugetlbfs.");
> +"compatible with huge memory backings.");
>  return;
>  }
>  rc = kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, );
> @@ -281,10 +284,37 @@ void kvm_s390_crypto_reset(void)
>  }
>  }
>  
> +static int kvm_s390_configure_mempath_backing(KVMState *s)
> +{
> +size_t path_psize = qemu_mempath_getpagesize(mem_path);
> +
> +if (path_psize == 4 * KiB)
> +return 0;

Missing curly braces.

> +if (path_psize != 1 * MiB) {
> +error_report("Memory backing with 2G pages was specified, "
> + "but KVM does not support this memory backing");

May I suggest to use a text that rather matches the condition of the
if-statement (just in case there will be other sizes in the future...),
e.g. "Memory backing is only supported for 1 MiB huge pages" or
something similar.

 Thomas

Re: [Qemu-devel] [qemu-s390x] [PATCH] tests: virtio: separate ccw tests from libqos

[Paolo Bonzini]

On 01/08/2018 18:39, Thomas Huth wrote:
> I think you could omit the virtio_net_nop test here, since we already
> check that device in tests/pxe-test.c (and maybe also virtio_blk and
> virtio_scsi since they are tested in tests/cdrom-test.c).
> 
> Anyway:
> 
> Reviewed-by: Thomas Huth 

Thanks Conny and Thomas for the quick review.

Emanuele, please add this patch to your qgraph branch!  You can use "git
am -s" and cut-and-paste the original message source from thunderbird or
gmail into the Terminal.

Paolo

Re: [Qemu-devel] [qemu-s390x] [PATCH] tests: virtio: separate ccw tests from libqos

[Thomas Huth]

On 08/01/2018 03:27 PM, Paolo Bonzini wrote:
> Because qtest does not support s390 channel I/O, s390 only performs smoke 
> tests on
> those few devices that do not have any functional tests.  Therefore, every 
> time we
> add functional tests for a virtio device, the choice is between removing
> those tests from the s390 suite (so that s390 actually _loses_ coverage)
> or sprinkling the test with architecture checks.
> 
> This patch simply creates a ccw-specific test that only performs smoke tests 
> on
> all virtio-ccw devices.  If channel I/O support is ever added to qtest and 
> libqos,
> then this file can go away.  In the meanwhile, it simplifies maintenance and
> makes sure that all virtio devices are tested.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  tests/Makefile.include  |   5 +-
>  tests/virtio-ccw-test.c | 118 
>  2 files changed, 120 insertions(+), 3 deletions(-)
>  create mode 100644 tests/virtio-ccw-test.c
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index a49282704e..cf835f2fd0 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -401,9 +401,7 @@ check-qtest-s390x-$(CONFIG_SLIRP) += 
> tests/test-netfilter$(EXESUF)
>  check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-mirror$(EXESUF)
>  check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-redirector$(EXESUF)
>  check-qtest-s390x-y += tests/drive_del-test$(EXESUF)
> -check-qtest-s390x-y += tests/virtio-balloon-test$(EXESUF)
> -check-qtest-s390x-y += tests/virtio-console-test$(EXESUF)
> -check-qtest-s390x-y += tests/virtio-serial-test$(EXESUF)
> +check-qtest-s390x-y += tests/virtio-ccw-test$(EXESUF)
>  check-qtest-s390x-y += tests/cpu-plug-test$(EXESUF)
>  
>  check-qtest-generic-y += tests/machine-none-test$(EXESUF)
> @@ -807,6 +805,7 @@ tests/wdt_ib700-test$(EXESUF): tests/wdt_ib700-test.o
>  tests/tco-test$(EXESUF): tests/tco-test.o $(libqos-pc-obj-y)
>  tests/virtio-balloon-test$(EXESUF): tests/virtio-balloon-test.o 
> $(libqos-virtio-obj-y)
>  tests/virtio-blk-test$(EXESUF): tests/virtio-blk-test.o 
> $(libqos-virtio-obj-y)
> +tests/virtio-ccw-test$(EXESUF): tests/virtio-ccw-test.o
>  tests/virtio-net-test$(EXESUF): tests/virtio-net-test.o $(libqos-pc-obj-y) 
> $(libqos-virtio-obj-y)
>  tests/virtio-rng-test$(EXESUF): tests/virtio-rng-test.o $(libqos-pc-obj-y)
>  tests/virtio-scsi-test$(EXESUF): tests/virtio-scsi-test.o 
> $(libqos-virtio-obj-y)
> diff --git a/tests/virtio-ccw-test.c b/tests/virtio-ccw-test.c
> new file mode 100644
> index 00..0af3a7bb31
> --- /dev/null
> +++ b/tests/virtio-ccw-test.c
> @@ -0,0 +1,118 @@
> +/*
> + * QTest testcase for VirtIO CCW
> + *
> + * Copyright (c) 2014 SUSE LINUX Products GmbH
> + * Copyright (c) 2018 Red Hat, Inc.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +/* Until we have a full libqos implementation of virtio-ccw (which requires
> + * also to add support for I/O channels to qtest), we can only do simple
> + * tests that initialize the devices.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "libqtest.h"
> +#include "libqos/virtio.h"
> +
> +static void virtio_balloon_nop(void)
> +{
> +global_qtest = qtest_startf("-device virtio-balloon-ccw");
> +qtest_end();
> +}
> +
> +static void virtconsole_nop(void)
> +{
> +global_qtest = qtest_startf("-device virtio-serial-ccw,id=vser0 "
> +"-device virtconsole,bus=vser0.0");
> +qtest_end();
> +}
> +
> +static void virtserialport_nop(void)
> +{
> +global_qtest = qtest_startf("-device virtio-serial-ccw,id=vser0 "
> +"-device virtserialport,bus=vser0.0");
> +qtest_end();
> +}
> +
> +static void virtio_serial_nop(void)
> +{
> +global_qtest = qtest_startf("-device virtio-serial-ccw");
> +qtest_end();
> +}
> +
> +static void virtio_serial_hotplug(void)
> +{
> +global_qtest = qtest_startf("-device virtio-serial-ccw");
> +qtest_qmp_device_add("virtserialport", "hp-port", NULL);
> +qtest_qmp_device_del("hp-port");
> +qtest_end();
> +}
> +
> +static void virtio_blk_nop(void)
> +{
> +global_qtest = qtest_startf("-drive 
> if=none,id=drv0,file=null-co://,format=raw "
> +"-device virtio-blk-ccw,drive=drv0");
> +qtest_end();
> +}
> +
> +static void virtio_net_nop(void)
> +{
> +global_qtest = qtest_startf("-device virtio-net-ccw");
> +qtest_end();
> +}
> +
> +static void virtio_9p_nop(void)
> +{
> +global_qtest = qtest_startf("-fsdev synth,id=fsdev0 "
> +"-device 
> virtio-9p-ccw,fsdev=fsdev0,mount_tag=qtest");
> +qtest_end();
> +}
> +
> +static void virtio_rng_nop(void)
> +{
> +global_qtest = qtest_startf("-device virtio-rng-ccw");
> +qtest_end();
> +}
> +
> +static void virtio_scsi_nop(void)
> +{
> +global_qtest = qtest_startf("-device 

[Qemu-devel] [Bug 1783362] Re: qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0

[umarcor]

2018-08-01 8:25 GMT+01:00 Laurent Vivier:
> "Reviewed-By:", it's a tag I've sent in answer to his e-email to say
I've reviewed his patch, and it is good for me.

It's clear now. Thanks.

> I didn't update the Changelog, but the fix is now committed. It will be
released soon (07/08 or 14/08). But you should test master now to check
the commit really fixes your bug.

I tested it, and it is fixed as expected. I changed the status of this
bug accordingly. I'll change it again once it is released.

> my git repo for linux-user pull request is
git://github.com/vivier/qemu.git, and generally I prepare my pull
request on linux-user-for-3.0 branch (the release number changes).

Thanks again.

Regards,
umarcor

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1783362

Title:
  qemu-user: mmap should return failure (MAP_FAILED, -1) instead of
  success (NULL, 0) when len==0

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Committed

Bug description:
  As shown in https://github.com/beehive-
  lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns
  success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host
  executing a ELF 64-bit LSB executable, ARM aarch64 binary.

  Steps to reproduce the bug:

  - (cross-)compile the attached source file:

  $ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c
  -o mmap_qemu

  - Execute in a x86_64 host with qemu-user and qemu-user-binfmt:

  $ ./mmap_qemu
  alloc: 0
  MAP_FAILED: -1
  errno: 0
  mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  Aborted (core dumped)

  - Execute in a ARM host without any additional dependecy:

  $ ./mmap_qemu
  alloc: -1
  MAP_FAILED: -1
  errno: 22

  The bug is present in Fedora:

  $ qemu-aarch64 --version
  qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
  $ uname -r
  4.17.7-200.fc28.x86_64

  And also in Ubuntu:

  $ qemu-aarch64 --version
  qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
  $ uname -r
  4.15.0-23-generic

  Possibly related to:

  - https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html
  - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1783362/+subscriptions

[Qemu-devel] [Bug 1783362] Re: qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0

[umarcor]

** Changed in: qemu
   Status: In Progress => Fix Committed

** Changed in: qemu (Ubuntu)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1783362

Title:
  qemu-user: mmap should return failure (MAP_FAILED, -1) instead of
  success (NULL, 0) when len==0

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Committed

Bug description:
  As shown in https://github.com/beehive-
  lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns
  success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host
  executing a ELF 64-bit LSB executable, ARM aarch64 binary.

  Steps to reproduce the bug:

  - (cross-)compile the attached source file:

  $ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c
  -o mmap_qemu

  - Execute in a x86_64 host with qemu-user and qemu-user-binfmt:

  $ ./mmap_qemu
  alloc: 0
  MAP_FAILED: -1
  errno: 0
  mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  Aborted (core dumped)

  - Execute in a ARM host without any additional dependecy:

  $ ./mmap_qemu
  alloc: -1
  MAP_FAILED: -1
  errno: 22

  The bug is present in Fedora:

  $ qemu-aarch64 --version
  qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
  $ uname -r
  4.17.7-200.fc28.x86_64

  And also in Ubuntu:

  $ qemu-aarch64 --version
  qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
  $ uname -r
  4.15.0-23-generic

  Possibly related to:

  - https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html
  - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1783362/+subscriptions

Re: [Qemu-devel] [PATCH v4 0/2] s390x: Enable KVM huge page backing support

[Cornelia Huck]

On Wed,  1 Aug 2018 14:19:03 +0100
Janosch Frank  wrote:

> v4:
>   * Now using MiB
>   * Now supporting 4k memory backings
> 
> v3:
>   * Fixed Cap name
>   * Added mempath page size check and error reporting
> 
> Janosch Frank (2):
>   kvm: sync linux headers
>   s390x: Enable KVM huge page backing support
> 
>  linux-headers/linux/kvm.h |  1 +
>  target/s390x/kvm.c| 34 --
>  2 files changed, 33 insertions(+), 2 deletions(-)
> 

Looks good to me.

Same comment as for the etoken patch: I'll queue this as soon as the
kernel interface has landed (and we can do a proper headers update).
Please ping me if I forget about it :)

Re: [Qemu-devel] [PATCH] fix "Missing break in switch" coverity reports

[Paolo Bonzini]

On 01/08/2018 17:59, Peter Maydell wrote:
> 
> We could improve the somewhat cryptic comment:
> /*
>  * 0x41 is documented as setting the output sample rate,
>  * and 0x42 the input sample rate, but in fact SB16 hardware
>  * seems to have only a single sample rate under the hood,
>  * and some (buggy) guest programs such as FT2 will set the
>  * output rate using 0x42. Compare:
>  * 
> http://homepages.cae.wisc.edu/~brodskye/sb16doc/sb16doc.html#SamplingRate
>  */

I sometimes enjoy keeping little bits of "old-style QEMU" in these more
historical devices, but your improvement is just too good, so I'll
replace it.  Thanks!

Paolo

Re: [Qemu-devel] [PATCH v5 19/76] target/mips: Add emulation of nanoMIPS 16-bit arithmetic instructions

[Aleksandar Markovic]

Hi, Richard.

> > +case NM_P16_A2:
> > +switch (extract32(ctx->opcode, 3, 1)) {
> > +case NM_ADDIUR2:
> > +rd = extract32(ctx->opcode, 0, 3) << 2;
> > +gen_arith_imm(ctx, OPC_ADDIU, rt, rs, rd);
> > +break;
> > +case NM_P_ADDIURS5:
> > +rt = extract32(ctx->opcode, 5, 5);
> > +if (rt != 0) {
> > +rs = (sextract32(ctx->opcode, 4, 1) << 3) |
> > +  extract32(ctx->opcode, 0, 3);
> > +/* s = sign_extend( s[3] . s[2:0] , from_nbits = 4)*/
> > +gen_arith_imm(ctx, OPC_ADDIU, rt, rt, rs);
> > +}
> > +break;
> > +}
> 
> Now, these re-uses of RD and RS variables are misleading.
> These are immediates that you are extracting, not register numbers.
> 
> I suggest a "target_long imm;" at the top of the function to handle all such
> that will be required when this function is filled out.

gen_arith_imm() and similar functions have "int" as the type of offset/imm 
parameter (in this case the last parameter) - shouldn't "int" be more 
appropriate type for local variable than "target_long"?

Aleksandar M.

Re: [Qemu-devel] [PATCH] fix "Missing break in switch" coverity reports

[Peter Maydell]

On 1 August 2018 at 16:14, Paolo Bonzini  wrote:
> Many of these are marked as "intentional/fix required" because they
> just need adding a fall through comment.  This is exactly what this
> patch does, except for target/mips/translate.c where it is easier to
> duplicate the code, and hw/audio/sb16.c where I consulted the DOSBox
> sources and decide to just remove the LOG_UNIMP before the fallthrough.
>
> Signed-off-by: Paolo Bonzini 

> diff --git a/hw/audio/sb16.c b/hw/audio/sb16.c
> index 5a4d32364e..665a7e75c5 100644
> --- a/hw/audio/sb16.c
> +++ b/hw/audio/sb16.c
> @@ -741,10 +741,8 @@ static void complete (SB16State *s)
>  ldebug ("set time const %d\n", s->time_const);
>  break;
>
> -case 0x42:  /* FT2 sets output freq with this, go figure 
> */
> -qemu_log_mask(LOG_UNIMP, "cmd 0x42 might not do what it think it"
> -  " should\n");
>  case 0x41:
> +case 0x42:  /* FT2 sets output freq with this, go figure 
> */
>  s->freq = dsp_get_hilo (s);
>  ldebug ("set freq %d\n", s->freq);
>  break;

I agree with the outcome; see previous discussions
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02081.html
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02079.html

and this description of what the hardware does:
http://homepages.cae.wisc.edu/~brodskye/sb16doc/sb16doc.html#SamplingRate

We could improve the somewhat cryptic comment:
/*
 * 0x41 is documented as setting the output sample rate,
 * and 0x42 the input sample rate, but in fact SB16 hardware
 * seems to have only a single sample rate under the hood,
 * and some (buggy) guest programs such as FT2 will set the
 * output rate using 0x42. Compare:
 * http://homepages.cae.wisc.edu/~brodskye/sb16doc/sb16doc.html#SamplingRate
 */

thanks
-- PMM

Re: [Qemu-devel] [[PATH for 3.1] v2 12/18] check: Only test sdhci when it is compiled in

[no-reply]

Hi,

This series failed docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20180801110952.5590-13-quint...@redhat.com
Subject: [Qemu-devel] [[PATH for 3.1] v2 12/18] check: Only test sdhci when it 
is compiled in

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-quick@centos7 SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
error: Could not fetch 3c8cf5a9c21ff8782164d1def7f44bd888713384
Traceback (most recent call last):
  File "patchew-tester/src/patchew-cli", line 519, in test_one
git_clone_repo(clone, r["repo"], r["head"], logf, True)
  File "patchew-tester/src/patchew-cli", line 48, in git_clone_repo
stdout=logf, stderr=logf)
  File "/usr/lib64/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['git', 'remote', 'add', '-f', 
'--mirror=fetch', '3c8cf5a9c21ff8782164d1def7f44bd888713384', 
'https://github.com/patchew-project/qemu']' returned non-zero exit status 1.



---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] qemu NBD client behaviour when device size is not a multiple of 512

[Eric Blake]

On 07/31/2018 01:25 PM, Eric Blake wrote:

On 07/31/2018 01:00 PM, Richard W.M. Jones wrote:


Hi Eric.  Is this a bug?





Note that with qemu as server:

$ truncate --size=1023 file
$ qemu-nbd -f raw -x '' file

the client now sees:

423068@1533060754.229106:nbd_opt_go_info_block_size Block sizes are 
0x200, 0x1000, 0x200

...
423068@1533060754.229156:nbd_receive_negotiate_size_flags Size is 1024, 
export flags 0x1ed


where qemu as server is 0-padding the source file in all read requests; 
and that probably explains why I haven't noticed the problem with 
unaligned images in the client before (since qemu as NBD server doesn't 
advertise unaligned images).  What's more, a write request to the tail 
of the partial sector (when not using a read-only connection) succeeds, 
and resizes the file in the process (at least, on protocols that support 
live resizing); but I wouldn't count on it behaving sanely for all 
protocols.


What's more, with qemu as server, then 'qemu-img map' as client dies 
because the server is sending incorrect data according to protocol.


At any rate, you've given me plenty to work with for fixing things, 
although it probably won't make it into 3.0-rc3 and I don't know if 
we'll have an -rc4.


Not a regression introduce in 3.0 (it exists in 2.12), so not serious 
enough of a show-stopper to cause an -rc4 release.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH] fix "Missing break in switch" coverity reports

[Paolo Bonzini]

On 01/08/2018 17:25, Philippe Mathieu-Daudé wrote:
> 
> @@ -12277,6 +12277,7 @@ int arm_rmode_to_sf(int rmode)
>          /* FIXME: add support for TIEAWAY and ODD */
>          qemu_log_mask(LOG_UNIMP, "arm: unimplemented rounding mode:
> %d\n",
>                        rmode);
> +        /* fall through for now */
> 
> 
> This one looks weird, hidden bug?

There is already a FIXME comment.

Paolo

> For the rest:
> 
> Reviewed-by: Philippe Mathieu-Daudé  >

Re: [Qemu-devel] [PATCH] fix "Missing break in switch" coverity reports

[Philippe Mathieu-Daudé]

Le mer. 1 août 2018 12:15, Paolo Bonzini  a écrit :

> Many of these are marked as "intentional/fix required" because they
> just need adding a fall through comment.  This is exactly what this
> patch does, except for target/mips/translate.c where it is easier to
> duplicate the code, and hw/audio/sb16.c where I consulted the DOSBox
> sources and decide to just remove the LOG_UNIMP before the fallthrough.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  disas/m68k.c| 1 +
>  hw/arm/pxa2xx.c | 2 +-
>  hw/audio/cs4231a.c  | 1 +
>  hw/audio/gusemu_hal.c   | 1 +
>  hw/audio/sb16.c | 4 +---
>  hw/display/cg3.c| 1 +
>  hw/display/cirrus_vga.c | 3 ++-
>  hw/timer/sh_timer.c | 1 +
>  target/arm/helper.c | 1 +
>  target/i386/translate.c | 2 ++
>  target/mips/translate.c | 2 ++
>  11 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/disas/m68k.c b/disas/m68k.c
> index a687df437c..0dc8aa1a3c 100644
> --- a/disas/m68k.c
> +++ b/disas/m68k.c
> @@ -1623,6 +1623,7 @@ print_insn_arg (const char *d,
>
>  case 'X':
>place = '8';
> +  /* fall through */
>  case 'Y':
>  case 'Z':
>  case 'W':
> diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
> index b67b0cefb6..f598a1c053 100644
> --- a/hw/arm/pxa2xx.c
> +++ b/hw/arm/pxa2xx.c
> @@ -409,7 +409,7 @@ static uint64_t pxa2xx_mm_read(void *opaque, hwaddr
> addr,
>  case MDCNFG ... SA1110:
>  if ((addr & 3) == 0)
>  return s->mm_regs[addr >> 2];
> -
> +/* fall through */
>  default:
>  printf("%s: Bad register " REG_FMT "\n", __func__, addr);
>  break;
> diff --git a/hw/audio/cs4231a.c b/hw/audio/cs4231a.c
> index aaebec1839..9089dcb47e 100644
> --- a/hw/audio/cs4231a.c
> +++ b/hw/audio/cs4231a.c
> @@ -305,6 +305,7 @@ static void cs_reset_voices (CSState *s, uint32_t val)
>
>  case 6:
>  as.endianness = 1;
> +/* fall through */
>  case 2:
>  as.fmt = AUD_FMT_S16;
>  s->shift = as.nchannels;
> diff --git a/hw/audio/gusemu_hal.c b/hw/audio/gusemu_hal.c
> index 1150fc4426..ae40ca341c 100644
> --- a/hw/audio/gusemu_hal.c
> +++ b/hw/audio/gusemu_hal.c
> @@ -261,6 +261,7 @@ void gus_write(GUSEmuState * state, int port, int
> size, unsigned int data)
>  GUSregb(IRQStatReg2x6) = 0x10;
>  GUS_irqrequest(state, state->gusirq, 1);
>  }
> +/* fall through */
>  case 0x20D:/* SB2xCd no IRQ */
>  GUSregb(SB2xCd) = (uint8_t) data;
>  break;
> diff --git a/hw/audio/sb16.c b/hw/audio/sb16.c
> index 5a4d32364e..665a7e75c5 100644
> --- a/hw/audio/sb16.c
> +++ b/hw/audio/sb16.c
> @@ -741,10 +741,8 @@ static void complete (SB16State *s)
>  ldebug ("set time const %d\n", s->time_const);
>  break;
>
> -case 0x42:  /* FT2 sets output freq with this, go
> figure */
> -qemu_log_mask(LOG_UNIMP, "cmd 0x42 might not do what it think
> it"
> -  " should\n");
>  case 0x41:
> +case 0x42:  /* FT2 sets output freq with this, go
> figure */
>  s->freq = dsp_get_hilo (s);
>  ldebug ("set freq %d\n", s->freq);
>  break;
> diff --git a/hw/display/cg3.c b/hw/display/cg3.c
> index 6fff4852c5..1c199ab369 100644
> --- a/hw/display/cg3.c
> +++ b/hw/display/cg3.c
> @@ -232,6 +232,7 @@ static void cg3_reg_write(void *opaque, hwaddr addr,
> uint64_t val,
>  s->b[s->dac_index] = regval;
>  /* Index autoincrement */
>  s->dac_index = (s->dac_index + 1) & 0xff;
> +/* fall through */
>  default:
>  s->dac_state = 0;
>  break;
> diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
> index 7583b18c29..04c87c8e8d 100644
> --- a/hw/display/cirrus_vga.c
> +++ b/hw/display/cirrus_vga.c
> @@ -1426,7 +1426,8 @@ static void cirrus_vga_write_sr(CirrusVGAState * s,
> uint32_t val)
>  s->vga.hw_cursor_y = (val << 3) | (s->vga.sr_index >> 5);
> break;
>  case 0x07: // Extended Sequencer Mode
> -cirrus_update_memory_access(s);
> +cirrus_update_memory_access(s);
> +/* fall through */
>  case 0x08: // EEPROM Control
>  case 0x09: // Scratch Register 0
>  case 0x0a: // Scratch Register 1
> diff --git a/hw/timer/sh_timer.c b/hw/timer/sh_timer.c
> index 5f8736cf10..91b18ba312 100644
> --- a/hw/timer/sh_timer.c
> +++ b/hw/timer/sh_timer.c
> @@ -74,6 +74,7 @@ static uint32_t sh_timer_read(void *opaque, hwaddr
> offset)
>  case OFFSET_TCPR:
>  if (s->feat & TIMER_FEAT_CAPT)
>  return s->tcpr;
> +/* fall through */
>  default:
>  hw_error("sh_timer_read: Bad offset %x\n", (int)offset);
>  return 0;
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 66afb08ee0..12735ff089 

Re: [Qemu-devel] [PATCH v3] block/gluster: Handle changed glfs_ftruncate signature

[Eric Blake]

On 08/01/2018 06:47 AM, Niels de Vos wrote:

If glusterfs-5 releases in October, that may line up with 3.1 or 3.2.


Ok, I'll keep these kind of patches in my tree as work-in-progress and
when the glusterfs-5 gets tagged for alpha/beta send it again.

Even if not optimal, would you accept this as a way going forward?


It will work. But even better would be getting gluster to the point that 
it has a stable back-compat API guarantee (no future API removals or 
signature changes on existing functions - all new functionality is added 
via new API).  The more clients a library gains, the more pain you cause 
yourself and all your clients when you choose not to maintain a 
backwards-compatible stable API.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[Qemu-devel] [PATCH] fix "Missing break in switch" coverity reports

[Paolo Bonzini]

Many of these are marked as "intentional/fix required" because they
just need adding a fall through comment.  This is exactly what this
patch does, except for target/mips/translate.c where it is easier to
duplicate the code, and hw/audio/sb16.c where I consulted the DOSBox
sources and decide to just remove the LOG_UNIMP before the fallthrough.

Signed-off-by: Paolo Bonzini 
---
 disas/m68k.c| 1 +
 hw/arm/pxa2xx.c | 2 +-
 hw/audio/cs4231a.c  | 1 +
 hw/audio/gusemu_hal.c   | 1 +
 hw/audio/sb16.c | 4 +---
 hw/display/cg3.c| 1 +
 hw/display/cirrus_vga.c | 3 ++-
 hw/timer/sh_timer.c | 1 +
 target/arm/helper.c | 1 +
 target/i386/translate.c | 2 ++
 target/mips/translate.c | 2 ++
 11 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/disas/m68k.c b/disas/m68k.c
index a687df437c..0dc8aa1a3c 100644
--- a/disas/m68k.c
+++ b/disas/m68k.c
@@ -1623,6 +1623,7 @@ print_insn_arg (const char *d,
 
 case 'X':
   place = '8';
+  /* fall through */
 case 'Y':
 case 'Z':
 case 'W':
diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
index b67b0cefb6..f598a1c053 100644
--- a/hw/arm/pxa2xx.c
+++ b/hw/arm/pxa2xx.c
@@ -409,7 +409,7 @@ static uint64_t pxa2xx_mm_read(void *opaque, hwaddr addr,
 case MDCNFG ... SA1110:
 if ((addr & 3) == 0)
 return s->mm_regs[addr >> 2];
-
+/* fall through */
 default:
 printf("%s: Bad register " REG_FMT "\n", __func__, addr);
 break;
diff --git a/hw/audio/cs4231a.c b/hw/audio/cs4231a.c
index aaebec1839..9089dcb47e 100644
--- a/hw/audio/cs4231a.c
+++ b/hw/audio/cs4231a.c
@@ -305,6 +305,7 @@ static void cs_reset_voices (CSState *s, uint32_t val)
 
 case 6:
 as.endianness = 1;
+/* fall through */
 case 2:
 as.fmt = AUD_FMT_S16;
 s->shift = as.nchannels;
diff --git a/hw/audio/gusemu_hal.c b/hw/audio/gusemu_hal.c
index 1150fc4426..ae40ca341c 100644
--- a/hw/audio/gusemu_hal.c
+++ b/hw/audio/gusemu_hal.c
@@ -261,6 +261,7 @@ void gus_write(GUSEmuState * state, int port, int size, 
unsigned int data)
 GUSregb(IRQStatReg2x6) = 0x10;
 GUS_irqrequest(state, state->gusirq, 1);
 }
+/* fall through */
 case 0x20D:/* SB2xCd no IRQ */
 GUSregb(SB2xCd) = (uint8_t) data;
 break;
diff --git a/hw/audio/sb16.c b/hw/audio/sb16.c
index 5a4d32364e..665a7e75c5 100644
--- a/hw/audio/sb16.c
+++ b/hw/audio/sb16.c
@@ -741,10 +741,8 @@ static void complete (SB16State *s)
 ldebug ("set time const %d\n", s->time_const);
 break;
 
-case 0x42:  /* FT2 sets output freq with this, go figure */
-qemu_log_mask(LOG_UNIMP, "cmd 0x42 might not do what it think it"
-  " should\n");
 case 0x41:
+case 0x42:  /* FT2 sets output freq with this, go figure */
 s->freq = dsp_get_hilo (s);
 ldebug ("set freq %d\n", s->freq);
 break;
diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index 6fff4852c5..1c199ab369 100644
--- a/hw/display/cg3.c
+++ b/hw/display/cg3.c
@@ -232,6 +232,7 @@ static void cg3_reg_write(void *opaque, hwaddr addr, 
uint64_t val,
 s->b[s->dac_index] = regval;
 /* Index autoincrement */
 s->dac_index = (s->dac_index + 1) & 0xff;
+/* fall through */
 default:
 s->dac_state = 0;
 break;
diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
index 7583b18c29..04c87c8e8d 100644
--- a/hw/display/cirrus_vga.c
+++ b/hw/display/cirrus_vga.c
@@ -1426,7 +1426,8 @@ static void cirrus_vga_write_sr(CirrusVGAState * s, 
uint32_t val)
 s->vga.hw_cursor_y = (val << 3) | (s->vga.sr_index >> 5);
break;
 case 0x07: // Extended Sequencer Mode
-cirrus_update_memory_access(s);
+cirrus_update_memory_access(s);
+/* fall through */
 case 0x08: // EEPROM Control
 case 0x09: // Scratch Register 0
 case 0x0a: // Scratch Register 1
diff --git a/hw/timer/sh_timer.c b/hw/timer/sh_timer.c
index 5f8736cf10..91b18ba312 100644
--- a/hw/timer/sh_timer.c
+++ b/hw/timer/sh_timer.c
@@ -74,6 +74,7 @@ static uint32_t sh_timer_read(void *opaque, hwaddr offset)
 case OFFSET_TCPR:
 if (s->feat & TIMER_FEAT_CAPT)
 return s->tcpr;
+/* fall through */
 default:
 hw_error("sh_timer_read: Bad offset %x\n", (int)offset);
 return 0;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 66afb08ee0..12735ff089 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -12277,6 +12277,7 @@ int arm_rmode_to_sf(int rmode)
 /* FIXME: add support for TIEAWAY and ODD */
 qemu_log_mask(LOG_UNIMP, "arm: unimplemented rounding mode: %d\n",
   rmode);
+/* fall through for now */

Re: [Qemu-devel] [PATCH 0/4] target/arm sve fixes

[Alex Bennée]

Richard Henderson  writes:

> These four patches are minor, reported by Laurent this week.
>
> If there happens to be an -rc4 release, it would be nice if
> they were included.  But if not, no biggie.  I suspect that
> other minor issues will be found past these four, so I would
> hope everyone who cares about sve is just as happy working
> from a branch anyway.

All the RISU tests are still passing so:

Tested-by: Alex Bennée 

>
>
> r~
>
>
> Richard Henderson (4):
>   target/arm: Fix sign of sve_cmpeq_ppzw/sve_cmpne_ppzw
>   target/arm: Fix typo in do_sat_addsub_64
>   target/arm: Reorganize SVE WHILE
>   target/arm: Fix typo in helper_sve_movz_d
>
>  target/arm/sve_helper.c| 19 ++
>  target/arm/translate-sve.c | 51 --
>  2 files changed, 40 insertions(+), 30 deletions(-)


--
Alex Bennée

[Qemu-devel] [Bug 1776224] Re: QEMU's SPICE server not getting leds callback when sending capslock

[Bastien Orivel]

This is in fact 
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/425704
Sorry for the noise

** Changed in: qemu
   Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1776224

Title:
  QEMU's SPICE server not getting leds callback when sending capslock

Status in QEMU:
  Invalid

Bug description:
  I'm having troubles using the QEMU's SPICE server for remote views. When
  trying to sync leds from my SPICE client to QEMU, I can see that the
  caps lock keycodes are sent but the server state never gets updated
  (which leads in funny behaviours like caps lock "blinking" in the guest
  if the clients resyncs its state often).

  That behaviour doesn't happen at all with the numlock led which does the
  same thing but with different keycodes.

  Here is an example of what's happening when the client tries to resync
  with a capslock difference:

  > Spice received: 58
  > ps2_put_keycode: 88
  >
  > Spice received: 186
  > ps2_put_keycode: 240
  > ps2_put_keycode: 88
  > ps2_queue: 186

  And with numlock:

  > Spice received: 69
  > ps2_put_keycode: 119
  >
  > Spice received: 197
  > ps2_put_keycode: 240
  > ps2_put_keycode: 119
  > ps2_queue: 197
  > ps2_set_ledstate: 0
  > Spice new ledstate: 0

  
  This behaviour is consistent across SPICE clients and only appears in a linux 
TTY (it works fine if I start an X server and on windows). It still happens on 
QEMU latest commit at the time (0d2fa03dae4fbe185a082f361342b1e30aed4582)

  Spice registers a callback for leds via qemu_add_led_event_handler but
  it's never called for capslock. Is that a normal behaviour ? Is there
  any reasons for the capslock led not to be updated ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1776224/+subscriptions

Re: [Qemu-devel] [PATCH] monitor: avoid potential dead-lock when cleaning up

[Markus Armbruster]

Marc-André Lureau  writes:

> Hi
>
> On Wed, Aug 1, 2018 at 3:19 PM, Markus Armbruster  wrote:
>> Marc-André Lureau  writes:
>>
>>> When a monitor is connected to a Spice chardev, the monitor cleanup
>>> can dead-lock:
>>>
>>>  #0  0x7f43446637fd in __lll_lock_wait () at /lib64/libpthread.so.0
>>>  #1  0x7f434465ccf4 in pthread_mutex_lock () at /lib64/libpthread.so.0
>>>  #2  0x556dd79f22ba in qemu_mutex_lock_impl (mutex=0x556dd81c9220 
>>> , file=0x556dd7ae3648 "/home/elmarco/src/qq/monitor.c", 
>>> line=645) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66
>>>  #3  0x556dd7431bd5 in monitor_qapi_event_queue 
>>> (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x556dd9abc850, 
>>> errp=0x7fffb7bbddd8) at /home/elmarco/src/qq/monitor.c:645
>>>  #4  0x556dd79d476b in qapi_event_send_spice_disconnected 
>>> (server=0x556dd98ee760, client=0x556ddaaa8560, errp=0x556dd82180d0 
>>> ) at qapi/qapi-events-ui.c:149
>>>  #5  0x556dd7870fc1 in channel_event (event=3, info=0x556ddad1b590) at 
>>> /home/elmarco/src/qq/ui/spice-core.c:235
>>>  #6  0x7f434560a6bb in reds_handle_channel_event (reds=, 
>>> event=3, info=0x556ddad1b590) at reds.c:316
>>>  #7  0x7f43455f393b in main_dispatcher_self_handle_channel_event 
>>> (info=0x556ddad1b590, event=3, self=0x556dd9a7d8c0) at main-dispatcher.c:197
>>>  #8  0x7f43455f393b in main_dispatcher_channel_event 
>>> (self=0x556dd9a7d8c0, event=event@entry=3, info=0x556ddad1b590) at 
>>> main-dispatcher.c:197
>>>  #9  0x7f4345612833 in red_stream_push_channel_event 
>>> (s=s@entry=0x556ddae2ef40, event=event@entry=3) at red-stream.c:414
>>>  #10 0x7f434561286b in red_stream_free (s=0x556ddae2ef40) at 
>>> red-stream.c:388
>>>  #11 0x7f43455f9ddc in red_channel_client_finalize 
>>> (object=0x556dd9bb21a0) at red-channel-client.c:347
>>>  #12 0x7f434b5f9fb9 in g_object_unref () at /lib64/libgobject-2.0.so.0
>>>  #13 0x7f43455fc212 in red_channel_client_push (rcc=0x556dd9bb21a0) at 
>>> red-channel-client.c:1341
>>>  #14 0x556dd76081ba in spice_port_set_fe_open (chr=0x556dd9925e20, 
>>> fe_open=0) at /home/elmarco/src/qq/chardev/spice.c:241
>>>  #15 0x556dd796d74a in qemu_chr_fe_set_open (be=0x556dd9a37c00, 
>>> fe_open=0) at /home/elmarco/src/qq/chardev/char-fe.c:340
>>>  #16 0x556dd796d4d9 in qemu_chr_fe_set_handlers (b=0x556dd9a37c00, 
>>> fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, opaque=0x0, 
>>> context=0x0, set_open=true) at /home/elmarco/src/qq/chardev/char-fe.c:280
>>>  #17 0x556dd796d359 in qemu_chr_fe_deinit (b=0x556dd9a37c00, del=false) 
>>> at /home/elmarco/src/qq/chardev/char-fe.c:233
>>>  #18 0x556dd7432240 in monitor_data_destroy (mon=0x556dd9a37c00) at 
>>> /home/elmarco/src/qq/monitor.c:786
>>>  #19 0x556dd743b968 in monitor_cleanup () at 
>>> /home/elmarco/src/qq/monitor.c:4683
>>>  #20 0x556dd75ce776 in main (argc=3, argv=0x7fffb7bbe458, 
>>> envp=0x7fffb7bbe478) at /home/elmarco/src/qq/vl.c:4660
>>>
>>> Because spice code tries to emit a "disconnected" signal on the
>>> monitors. Fix this situation by tightening the monitor lock time to
>>> the monitor list removal.
>>>
>>> Signed-off-by: Marc-André Lureau 
>>
>> Do you think this should go into 3.0?
>>
>>> ---
>>>  monitor.c | 22 +++---
>>>  1 file changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/monitor.c b/monitor.c
>>> index 0fa0910a2a..a16a6c5311 100644
>>> --- a/monitor.c
>>> +++ b/monitor.c
>>> @@ -4702,8 +4702,6 @@ void monitor_init(Chardev *chr, int flags)
>>>
>>>  void monitor_cleanup(void)
>>>  {
>>> -Monitor *mon, *next;
>>> -
>>>  /*
>>>   * We need to explicitly stop the I/O thread (but not destroy it),
>>>   * clean up the monitor resources, then destroy the I/O thread since
>>> @@ -4719,14 +4717,24 @@ void monitor_cleanup(void)
>>>  monitor_qmp_bh_responder(NULL);
>>>
>>>  /* Flush output buffers and destroy monitors */
>>> -qemu_mutex_lock(_lock);
>>> -QTAILQ_FOREACH_SAFE(mon, _list, entry, next) {
>>> -QTAILQ_REMOVE(_list, mon, entry);
>>> +do {
>>
>> for (;;), please.
>>
>>> +Monitor *mon;
>>> +
>>> +qemu_mutex_lock(_lock);
>>> +mon = QTAILQ_FIRST(_list);
>>> +if (mon) {
>>> +QTAILQ_REMOVE(_list, mon, entry);
>>> +}
>>> +qemu_mutex_unlock(_lock);
>>> +
>>> +if (!mon) {
>>> +break;
>>> +}
>>> +
>>>  monitor_flush(mon);
>>>  monitor_data_destroy(mon);
>>>  g_free(mon);
>>> -}
>>> -qemu_mutex_unlock(_lock);
>>> +} while (true);
>>>
>>>  /* QEMUBHs needs to be deleted before destroying the I/O thread */
>>>  qemu_bh_delete(qmp_dispatcher_bh);
>>
>> Iterating safely over a list protected by a lock should be easier than
>> that.  Sad.
>>
>> Hmm, what about this:
>>
>> diff --git a/monitor.c b/monitor.c
>> index 77861e96af..4a23f6c7bc 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -4721,9 +4721,11 

Re: [Qemu-devel] [PATCH] throttle-groups: fix hang when group member leaves

[Alberto Garcia]

On Tue 31 Jul 2018 06:47:53 PM CEST, Alberto Garcia wrote:
> On Wed 04 Jul 2018 04:54:10 PM CEST, Stefan Hajnoczi wrote:
>> Throttle groups consist of members sharing one throttling state
>> (including bps/iops limits).  Round-robin scheduling is used to ensure
>> fairness.  If a group member already has a timer pending then other
>> groups members do not schedule their own timers.  The next group
>> member will have its turn when the existing timer expires.
>>
>> A hang may occur when a group member leaves while it had a timer
>> scheduled.
>
> Ok, I can reproduce this if I run fio with iodepth=1.

I managed to write a test case for this, but unfortunately it seems that
this patch is not enough and it's still possible to hang QEMU 3.0.0-rc2.

I expect to have a fix for tomorrow.

Berto

Re: [Qemu-devel] [PULL 1/1] slirp: fix ICMP handling on macOS hosts

[Andrew Oates via Qemu-devel]

On Wed, Aug 1, 2018 at 6:10 AM Peter Maydell 
wrote:

> On 1 August 2018 at 00:25, Andrew Oates  wrote:
> > Both CONFIG_BSD and not-CONFIG_LINUX work on macOS.  I unfortunately
> don't
> > have access to any other BSDs to test them, though.
>
> Is there an easy way to test it? The QEMU makefiles have some
> runes for setting up a BSD VM...
>

Ok, it turns out that SOCK_DGRAM+IPPROTO_ICMP isn't actually supported on
FreeBSD---tested in qemu (thanks for the tip!).

I didn't actually boot up NetBSD or OpenBSD, but poking around the kernel
source I found for them it appears they have the same restriction:
https://github.com/freebsd/freebsd/blob/master/sys/netinet/in_proto.c
https://github.com/openbsd/src/blob/master/sys/netinet/in_proto.c
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/in_proto.c?rev=1.128=text/x-cvsweb-markup

(search for SOCK_DGRAM and IPPROTO_ICMP in the above).

So I don't think ICMP via SLIRP would work at all in the other BSDs,
meaning this patch is a no-op for them either way.  If we _were_ to make
SLIRP+ICMP work in *BSD, we'd presumably want to do it with a
SOCK_RAW+IPPROTO_ICMP socket (which would require special permissions to
create), which would mean an included IP header---so I think that #ifdef
CONFIG_BSD here is defensible.

I did some poking for Solaris and Haiku and didn't find much, though it
looks like the version of ping included w/ Haiku uses SOCK_RAW rather than
SOCK_DGRAM, so it may be in the same boat as non-OSX-BSDs (
https://github.com/haiku/haiku/blob/master/src/bin/network/ping/ping.c#L205
).

~Andrew


>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH] scsi: mptsas: Mark as storage device

[Paolo Bonzini]

On 01/08/2018 00:28, Guenter Roeck wrote:
> mptsas1068 is currently listed as uncategorized device.
> Mark it as storage device.
> 
> Signed-off-by: Guenter Roeck 
> ---
>  hw/scsi/mptsas.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/scsi/mptsas.c b/hw/scsi/mptsas.c
> index 4176e87..929404f 100644
> --- a/hw/scsi/mptsas.c
> +++ b/hw/scsi/mptsas.c
> @@ -1431,6 +1431,7 @@ static void mptsas1068_class_init(ObjectClass *oc, void 
> *data)
>  dc->reset = mptsas_reset;
>  dc->vmsd = _mptsas;
>  dc->desc = "LSI SAS 1068";
> +set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
>  }
>  
>  static const TypeInfo mptsas_info = {
> 

Queued, thanks.

Paolo

Re: [Qemu-devel] [RFC] target/mips: Initial support for MIPS R5900

[Richard Henderson]

On 08/01/2018 09:39 AM, Fredrik Noring wrote:
>  Can QEMU be instructed to emulate
> the FPU only for Linux user space programs as opposed to hardware emulation?

Yes, that can be done.  I would suggest something like

/*
 * Hardware traps to the operating system for emulation.
 * For user-only, qemu is the operating system, so we
 * emulate the trap and emulate by simply emulating the
 * instruction directly.
 */
#ifdef CONFIG_USER_ONLY
# define CP0C1_FP_USER_ONLY  (1 << CP0C1_FP)
#else
# define CP0C1_FP_USER_ONLY  0
#endif

and include that in your initialization of CP0_Config1.


r~

Re: [Qemu-devel] [Qemu-arm] [PATCH 1/4] target/arm: Fix sign of sve_cmpeq_ppzw/sve_cmpne_ppzw

[Alex Bennée]

Richard Henderson  writes:

> The normal vector element is sign-extended before
> comparing with the wide vector element.
>
> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

> ---
>  target/arm/sve_helper.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 54795c9194..9bd0694d55 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -2436,13 +2436,13 @@ uint32_t HELPER(NAME)(void *vd, void *vn, void *vm, 
> void *vg, uint32_t desc) \
>  #define DO_CMP_PPZW_S(NAME, TYPE, TYPEW, OP) \
>  DO_CMP_PPZW(NAME, TYPE, TYPEW, OP, H1_4, 0xull)
>
> -DO_CMP_PPZW_B(sve_cmpeq_ppzw_b, uint8_t,  uint64_t, ==)
> -DO_CMP_PPZW_H(sve_cmpeq_ppzw_h, uint16_t, uint64_t, ==)
> -DO_CMP_PPZW_S(sve_cmpeq_ppzw_s, uint32_t, uint64_t, ==)
> +DO_CMP_PPZW_B(sve_cmpeq_ppzw_b, int8_t,  uint64_t, ==)
> +DO_CMP_PPZW_H(sve_cmpeq_ppzw_h, int16_t, uint64_t, ==)
> +DO_CMP_PPZW_S(sve_cmpeq_ppzw_s, int32_t, uint64_t, ==)
>
> -DO_CMP_PPZW_B(sve_cmpne_ppzw_b, uint8_t,  uint64_t, !=)
> -DO_CMP_PPZW_H(sve_cmpne_ppzw_h, uint16_t, uint64_t, !=)
> -DO_CMP_PPZW_S(sve_cmpne_ppzw_s, uint32_t, uint64_t, !=)
> +DO_CMP_PPZW_B(sve_cmpne_ppzw_b, int8_t,  uint64_t, !=)
> +DO_CMP_PPZW_H(sve_cmpne_ppzw_h, int16_t, uint64_t, !=)
> +DO_CMP_PPZW_S(sve_cmpne_ppzw_s, int32_t, uint64_t, !=)
>
>  DO_CMP_PPZW_B(sve_cmpgt_ppzw_b, int8_t,   int64_t, >)
>  DO_CMP_PPZW_H(sve_cmpgt_ppzw_h, int16_t,  int64_t, >)


--
Alex Bennée

Re: [Qemu-devel] [Qemu-arm] [PATCH 4/4] target/arm: Fix typo in helper_sve_movz_d

[Alex Bennée]

Richard Henderson  writes:

> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

> ---
>  target/arm/sve_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 87594a8adb..c3cbec9cf5 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1042,7 +1042,7 @@ void HELPER(sve_movz_d)(void *vd, void *vn, void *vg, 
> uint32_t desc)
>  uint64_t *d = vd, *n = vn;
>  uint8_t *pg = vg;
>  for (i = 0; i < opr_sz; i += 1) {
> -d[i] = n[1] & -(uint64_t)(pg[H1(i)] & 1);
> +d[i] = n[i] & -(uint64_t)(pg[H1(i)] & 1);
>  }
>  }


--
Alex Bennée

[Qemu-devel] [PATCH v4 3/4] pc: drop memory region alignment check for 0

[David Hildenbrand]

All applicable memory regions always have an alignment > 0. All memory
backends result in file_ram_alloc() or qemu_anon_ram_alloc() getting
called, setting the alignment to > 0.

So a PCDIMM memory region always has an alignment > 0. NVDIMM copy the
alignment of the original memory memory region into the handcrafted memory
region that will be used at this place.

So the check for 0 can be dropped and we can reduce the special
handling.

Dropping this check makes factoring out of alignment handling easier as
compat handling only has to look at pcmc->enforce_aligned_dimm and not
care about the alignment of the memory region.

Reviewed-by: David Gibson 
Reviewed-by: Igor Mammedov 
Signed-off-by: David Hildenbrand 
---
 hw/i386/pc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 96be77f0dd..b31610ca63 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1713,7 +1713,7 @@ static void pc_memory_plug(HotplugHandler *hotplug_dev,
 uint64_t align = TARGET_PAGE_SIZE;
 bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
 
-if (memory_region_get_alignment(mr) && pcmc->enforce_aligned_dimm) {
+if (pcmc->enforce_aligned_dimm) {
 align = memory_region_get_alignment(mr);
 }
 
-- 
2.17.1

[Qemu-devel] [PATCH v4 2/4] util/oslib-win32: indicate alignment for qemu_anon_ram_alloc()

[David Hildenbrand]

Let's set the alignment just like for the posix variant. This will
implicitly set the alignment of the underlying memory region and
therefore make memory_region_get_alignment(mr) return something > 0 for
all memory backends applicable to PCDIMM/NVDIMM.

The allocation granularity is ususally 64k, while the page size is 4k.
The documentation of VirtualAlloc is not really comprehensible in case
only MEM_COMMIT is specified without an address. We'll detect the actual
values and then go for the bigger one. The expection is, that it will
always be 64k aligned. (The assumption is that MEM_COMMIT does an
implicit MEM_RESERVE, so the address will always be aligned to the
allocation granularity. And the allocation granularity is always bigger
than the page size).

This will allow us to drop special handling in pc.c for
memory_region_get_alignment(mr) == 0, as we can then assume that it is
always set (and AFAICS >= getpagesize()).

For pc in pc_memory_plug(), under Windows TARGET_PAGE_SIZE == getpagesize(),
therefore alignment of DIMMs will not change, and therefore also not the
guest physical memory layout.

For spapr in spapr_memory_plug(), an alignment of 0 would have been used
until now. As QEMU_ALIGN_UP will crash with the alignment being 0, this
never worked, so we don't have to care about compatibility handling.

Reviewed-by: David Gibson 
Signed-off-by: David Hildenbrand 
---
 util/oslib-win32.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/util/oslib-win32.c b/util/oslib-win32.c
index bb5ad28bd3..25dd1595ad 100644
--- a/util/oslib-win32.c
+++ b/util/oslib-win32.c
@@ -67,15 +67,24 @@ void *qemu_memalign(size_t alignment, size_t size)
 return qemu_oom_check(qemu_try_memalign(alignment, size));
 }
 
+static int get_allocation_granularity(void)
+{
+SYSTEM_INFO system_info;
+
+GetSystemInfo(_info);
+return system_info.dwAllocationGranularity;
+}
+
 void *qemu_anon_ram_alloc(size_t size, uint64_t *align, bool shared)
 {
 void *ptr;
 
-/* FIXME: this is not exactly optimal solution since VirtualAlloc
-   has 64Kb granularity, but at least it guarantees us that the
-   memory is page aligned. */
 ptr = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);
 trace_qemu_anon_ram_alloc(size, ptr);
+
+if (ptr && align) {
+*align = MAX(get_allocation_granularity(), getpagesize());
+}
 return ptr;
 }
 
-- 
2.17.1

Re: [Qemu-devel] [RFC] target/mips: Initial support for MIPS R5900

[Fredrik Noring]

Thank you for your review, Maciej,

> > The MIPS R5900 is normally taken to be MIPS3, but it has MOVN, MOVZ and PREF
> > defined in MIPS4 which is why ISA_MIPS4 is chosen for this patch.
> 
>  It also has several instructions removed, so I don't think you can really 
> just mark it MIPS IV without special-casing those instructions, or the 
> emulation won't be accurate (and consequently programs that use them won't 
> trigger exceptions that they are supposed to).

Agreed. However, complete and perfect emulation of the R5900 will require a
substantial amount of work. What level is suitable for an initial patch?

> > Some flags in the mips_defs array are marked FIXME as I don't know the
> > proper values.
> 
>  Well, the FPU is non-standard so until you implement it I'd rather kept 
> it disabled and then all the FPU-related settings can go for now.  For the 
> rest see below.

The kernel traps FPU instructions to emulate them accurately, and unless the
FPU is enabled here the QEMU Linux user space emulator crashes with "illegal
hardware instruction" on valid programs. Can QEMU be instructed to emulate
the FPU only for Linux user space programs as opposed to hardware emulation?

> > --- a/target/mips/translate_init.inc.c
> > +++ b/target/mips/translate_init.inc.c
> > @@ -411,6 +411,26 @@ const mips_def_t mips_defs[] =
> >  .mmu_type = MMU_TYPE_R4000,
> >  },
> >  {
> > +.name = "R5900",
> > +.CP0_PRid = 0x3800,
> > +/* No L2 cache, icache size 32k, dcache size 32k, uncached 
> > coherency. */
> > +.CP0_Config0 = (1 << 17) | (0x3 << 9) | (0x3 << 6) | (0x2 << 
> > CP0C0_K0),
> > +/* Note: Config1 is only used internally, the R5900 has only 
> > Config0. */
> > +.CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU),
> 
>  So I'd clear CP0C1_FP then; also make sure accessing CP0.Config1 from 
> emulated code does what it does on actual hardware.
> 
> > +.CP0_LLAddr_rw_bitmask = 0x,   /* FIXME */
> > +.CP0_LLAddr_shift = 4, /* FIXME */
> 
>  No LL/SC in the R5900, so the LLAddr settings can go.

Again, the kernel emulates LL/SC so I suppose some kind indication is needed
for that in the QEMU Linux user space emulator?

> > +.SYNCI_Step = 16,  /* FIXME */
> 
>  SYNCI is MIPS32r2+, so this can go.
> 
> > +.CCRes = 2,/* FIXME */
> 
>  Likewise, CCRes is MIPS32r2+, so this can go.

Sure!

> > +.CP0_Status_rw_bitmask = 0x3678,   /* FIXME */
> 
>  This has to indicate which bits in CP0.Status are writable.  Check with 
> the manual and/or actual hardware.

The TX79 manual describes the writable bits on pages 4.16-4.18, and it seems
0xF4C79C1F would be those.

> > +.CP1_fcr0 = (0x38 << FCR0_PRID) | (0x0 << FCR0_REV),
> > +.CP1_fcr31 = 0,
> > +.CP1_fcr31_rw_bitmask = 0x0183,/* FIXME */
> 
>  This is all FPU stuff and it can go.
> 
> > +.SEGBITS = 40, /* FIXME */
> 
>  This is the number of virtual address bits.  Determined by the highest 
> writable CP0.EntryHi.VPN2 bit.

VPN2 is bits 31:13 and so it is 19 bits wide, according to page 4.14 of the
TX79 manual.

> > +.PABITS = 36,  /* FIXME */
> 
>  Likewise physical address bits.  Determined by the highest writable 
> CP0.EntryLo0.PFN and CP0.EntryLo1.PFN bit.

PFN is bits 25:6 and so it is 20 bits wide, according to page 4.8 of the
TX79 manual.

> > +.insn_flags = CPU_R5900,
> > +.mmu_type = MMU_TYPE_R4000,/* FIXME */
> 
>  This looks right to me.

Good. :)

>  FWIW; I don't have any authority for QEMU maintenance.

The MAINTAINERS file indicates that Aurelien Jarno and Aleksandar Markovic
have authority over the MIPS emulation (CCed to this post).

Fredrik

[Qemu-devel] [PATCH v4 1/4] pc-dimm: assign and verify the "slot" property during pre_plug

[David Hildenbrand]

We can assign and verify the slot before realizing and trying to plug.
reading/writing the slot property should never fail, so let's reduce
error handling a bit by using _abort.

To do this during pre_plug, add and use (x86, ppc) pc_dimm_pre_plug().

Reviewed-by: David Gibson 
Reviewed-by: Igor Mammedov 
Reviewed-by: Eric Auger 
Signed-off-by: David Hildenbrand 
---
 hw/i386/pc.c |  2 ++
 hw/mem/pc-dimm.c | 35 ++-
 hw/ppc/spapr.c   |  9 -
 include/hw/mem/pc-dimm.h |  1 +
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 83a72b..96be77f0dd 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1696,6 +1696,8 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
 return;
 }
+
+pc_dimm_pre_plug(dev, MACHINE(hotplug_dev), errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 65843bc52a..e56c4daef2 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -29,10 +29,27 @@
 
 static int pc_dimm_get_free_slot(const int *hint, int max_slots, Error **errp);
 
+void pc_dimm_pre_plug(DeviceState *dev, MachineState *machine, Error **errp)
+{
+Error *local_err = NULL;
+int slot;
+
+slot = object_property_get_int(OBJECT(dev), PC_DIMM_SLOT_PROP,
+   _abort);
+slot = pc_dimm_get_free_slot(slot == PC_DIMM_UNASSIGNED_SLOT ? NULL : 
,
+ machine->ram_slots, _err);
+if (local_err) {
+goto out;
+}
+object_property_set_int(OBJECT(dev), slot, PC_DIMM_SLOT_PROP, 
_abort);
+trace_mhp_pc_dimm_assigned_slot(slot);
+out:
+error_propagate(errp, local_err);
+}
+
 void pc_dimm_plug(DeviceState *dev, MachineState *machine, uint64_t align,
   Error **errp)
 {
-int slot;
 PCDIMMDevice *dimm = PC_DIMM(dev);
 PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
 MemoryRegion *vmstate_mr = ddc->get_vmstate_memory_region(dimm,
@@ -59,22 +76,6 @@ void pc_dimm_plug(DeviceState *dev, MachineState *machine, 
uint64_t align,
 }
 trace_mhp_pc_dimm_assigned_address(addr);
 
-slot = object_property_get_int(OBJECT(dev), PC_DIMM_SLOT_PROP, _err);
-if (local_err) {
-goto out;
-}
-
-slot = pc_dimm_get_free_slot(slot == PC_DIMM_UNASSIGNED_SLOT ? NULL : 
,
- machine->ram_slots, _err);
-if (local_err) {
-goto out;
-}
-object_property_set_int(OBJECT(dev), slot, PC_DIMM_SLOT_PROP, _err);
-if (local_err) {
-goto out;
-}
-trace_mhp_pc_dimm_assigned_slot(slot);
-
 memory_device_plug_region(machine, mr, addr);
 vmstate_register_ram(vmstate_mr, dev);
 
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 421b2dd09b..4b33e9a08e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3191,6 +3191,7 @@ static void spapr_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 sPAPRMachineState *spapr = SPAPR_MACHINE(hotplug_dev);
 PCDIMMDevice *dimm = PC_DIMM(dev);
 PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
+Error *local_err = NULL;
 MemoryRegion *mr;
 uint64_t size;
 Object *memdev;
@@ -3216,7 +3217,13 @@ static void spapr_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 memdev = object_property_get_link(OBJECT(dimm), PC_DIMM_MEMDEV_PROP,
   _abort);
 pagesize = host_memory_backend_pagesize(MEMORY_BACKEND(memdev));
-spapr_check_pagesize(spapr, pagesize, errp);
+spapr_check_pagesize(spapr, pagesize, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
+pc_dimm_pre_plug(dev, MACHINE(hotplug_dev), errp);
 }
 
 struct sPAPRDIMMState {
diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
index 26ebb7d5e9..7b120416d1 100644
--- a/include/hw/mem/pc-dimm.h
+++ b/include/hw/mem/pc-dimm.h
@@ -79,6 +79,7 @@ typedef struct PCDIMMDeviceClass {
Error **errp);
 } PCDIMMDeviceClass;
 
+void pc_dimm_pre_plug(DeviceState *dev, MachineState *machine, Error **errp);
 void pc_dimm_plug(DeviceState *dev, MachineState *machine, uint64_t align,
   Error **errp);
 void pc_dimm_unplug(DeviceState *dev, MachineState *machine);
-- 
2.17.1

[Qemu-devel] [PATCH v4 0/4] pc-dimm: pre_plug "slot" and "addr" assignment

[David Hildenbrand]

This is basically a resend of v3 with commit message changes.

Paolo, if there are no further comments, can you please pick this up for
3.1? Thanks!

---

As requested by Igor, assign and verify "slot" and "addr" in the
pre_plug handler. Factor out the compatibility handling/configuration
for detecting the alignment to be used when searching for an address
in guest physical memory for a memory device.

This is another part of the original series
[PATCH v4 00/14] MemoryDevice: use multi stage hotplug handlers

This refactoring is the last step before factoring out pre_plug, plug and
unplug logic of memory devices completely into memory-device.c

v3 -> v4:
- Added rb/acks
- Fixed up patch description of last patch

v2 -> v3:
- "util/oslib-win32: indicate alignment for qemu_anon_ram_alloc()"
-- take allocation granularity into account
-- drop comment
- "pc-dimm: assign and verify the "addr" property during pre_plug"
-- compat_align -> legacy_align
-- shortened align detection as proposed by Igor
-- trace address asignment in pre_plug

v1 -> v2:
- dropped "machine: factor out enforce_aligned_dimm into memory_device_align"
- dropped "pc-dimm/memory-device: detect alignment internally"
- added "util/oslib-win32: indicate alignment for qemu_anon_ram_alloc()"
-- indicate the alignment and therefor simplify compat handling for
   Windows as we can ...
- added "pc: drop memory region alignment check for 0"
-- ... drop a check for memory_region_get_alignment(mr), allowing us to
   factor out compat handling for pc DIMM/NVDIMM alignment in a clean way.
- "pc-dimm: assign and verify the "addr" property during pre_plug"
-- Default to "memory_region_get_alignment(mr)" if no compat alignment
   has been specified.

David Hildenbrand (4):
  pc-dimm: assign and verify the "slot" property during pre_plug
  util/oslib-win32: indicate alignment for qemu_anon_ram_alloc()
  pc: drop memory region alignment check for 0
  pc-dimm: assign and verify the "addr" property during pre_plug

 hw/i386/pc.c | 16 ---
 hw/mem/pc-dimm.c | 61 +---
 hw/ppc/spapr.c   | 14 ++---
 include/hw/mem/pc-dimm.h |  5 ++--
 util/oslib-win32.c   | 15 --
 5 files changed, 63 insertions(+), 48 deletions(-)

-- 
2.17.1

Re: [Qemu-devel] [PATCH for-3.1] tests/cpu-plug-test: check CPU hotplug on ppc64 with KVM

[Greg Kurz]

On Tue, 31 Jul 2018 13:27:15 +1000
David Gibson  wrote:

> On Mon, Jul 30, 2018 at 11:59:00AM +0200, Greg Kurz wrote:
> > On Mon, 30 Jul 2018 10:41:45 +0200
> > Greg Kurz  wrote:
> >   
> > > On Mon, 30 Jul 2018 15:57:15 +1000
> > > David Gibson  wrote:  
> > [...]  
> > > > > > I'm pretty sure trying to change the accelerator on a qtest test 
> > > > > > just
> > > > > > doesn't make sense.  We'd need a different approach for testing cpu
> > > > > > hotplug against kvm & tcg backends.
> > > > > >   
> > > > > 
> > > > > The test starts QEMU, triggers the CPU hotplug code with a QMP command
> > > > > and checks the command didn't fail (or QEMU didn't crash, as it would
> > > > > have before commit b585395b655a)... I really don't understand what
> > > > > is wrong with that... Please elaborate.  
> > > > 
> > > > Well, ok, let me turn that around.  A test that doesn't rely on
> > > > controlling the guest side behaviour at all probably shouldn't be a
> > > > qtest based test, since that's what qtest is all about.
> > > > 
> > > 
> > > The CPU hotplug test doesn't seem to do anything on the guest side: it
> > > just checks that 'device_add' returns a response that isn't an error.
> > > I'm not aware that the guest is expected to have a specific behavior
> > > during 'device_add', apart from not crashing or hanging. That was the
> > > initial idea behind passing '-S' to ensure the guest doesn't run.
> > > 
> > > Your remark seems to be more general though... are you meaning that
> > > doing something like qtest_start("-machine accel=kvm:tcg") is just
> > > wrong ?  
> > 
> > The purpose of this test is simply to exercise a path in QEMU that
> > is only used with KVM, but it can also be achieved the other way
> > around:
> > 
> > @@ -189,7 +190,7 @@ static void xics_system_init(MachineState *machine, int 
> > nr_irqs, Error **errp)
> >  sPAPRMachineState *spapr = SPAPR_MACHINE(machine);
> >  Error *local_err = NULL;
> >  
> > -if (kvm_enabled()) {
> > +if (kvm_enabled() || qtest_enabled()) {
> >  if (machine_kernel_irqchip_allowed(machine) &&
> >  !xics_kvm_init(spapr, _err)) {
> > 
> > This will test the setup of the in-kernel XICS when run on a book3s host,
> > and fallback to emulated XICS otherwise (eg, travis).
> > 
> > Would this be more acceptable ?  
> 
> No, I don't think that will work.  With this we call into kvm related
> code via machine_kernel_irqchip_allowed() and xics_kvm_init() even in
> the qtest case.  If they work on a host which doesn't have KVM (say
> x86) it will only be by sheer accident.
> 

It's the other way around actually. The expected behaviour would be
for machine_kernel_irqchip_allowed(machine) and/or xics_kvm_init()
to fail and to fallback to emulated XICS if run without a proper KVM.
This means no behavior change for this test when run on a x86 host.

The issue is when we run this with KVM actually, because the XICS KVM
code obviously needs... KVM to be initialized, which won't happen
with qtest :)


pgpX4s_4uO4ix.pgp
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v4 4/4] pc-dimm: assign and verify the "addr" property during pre_plug

[David Hildenbrand]

We can assign and verify the address before realizing and trying to plug.
reading/writing the address property should never fail for DIMMs, so let's
reduce error handling a bit by using _abort. Getting access to the
memory region now might however fail. So forward errors from
get_memory_region() properly.

As all memory devices should use the alignment of the underlying memory
region for guest physical address asignment, do detection of the
alignment in pc_dimm_pre_plug(), but allow pc.c to overwrite the
alignment for compatibility handling.

Reviewed-by: Eric Auger 
Reviewed-by: Igor Mammedov 
Acked-by: David Gibson 
Signed-off-by: David Hildenbrand 
---
 hw/i386/pc.c | 16 -
 hw/mem/pc-dimm.c | 50 +---
 hw/ppc/spapr.c   |  7 +++---
 include/hw/mem/pc-dimm.h |  6 ++---
 4 files changed, 37 insertions(+), 42 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index b31610ca63..03148450c8 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1679,7 +1679,9 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
Error **errp)
 {
 const PCMachineState *pcms = PC_MACHINE(hotplug_dev);
+const PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
+const uint64_t legacy_align = TARGET_PAGE_SIZE;
 
 /*
  * When -no-acpi is used with Q35 machine type, no ACPI is built,
@@ -1697,7 +1699,8 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(dev, MACHINE(hotplug_dev), errp);
+pc_dimm_pre_plug(dev, MACHINE(hotplug_dev),
+ pcmc->enforce_aligned_dimm ? NULL : _align, errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
@@ -1706,18 +1709,9 @@ static void pc_memory_plug(HotplugHandler *hotplug_dev,
 HotplugHandlerClass *hhc;
 Error *local_err = NULL;
 PCMachineState *pcms = PC_MACHINE(hotplug_dev);
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
-PCDIMMDevice *dimm = PC_DIMM(dev);
-PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-MemoryRegion *mr = ddc->get_memory_region(dimm, _abort);
-uint64_t align = TARGET_PAGE_SIZE;
 bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
 
-if (pcmc->enforce_aligned_dimm) {
-align = memory_region_get_alignment(mr);
-}
-
-pc_dimm_plug(dev, MACHINE(pcms), align, _err);
+pc_dimm_plug(dev, MACHINE(pcms), _err);
 if (local_err) {
 goto out;
 }
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index e56c4daef2..fb6bcaedc4 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -29,9 +29,14 @@
 
 static int pc_dimm_get_free_slot(const int *hint, int max_slots, Error **errp);
 
-void pc_dimm_pre_plug(DeviceState *dev, MachineState *machine, Error **errp)
+void pc_dimm_pre_plug(DeviceState *dev, MachineState *machine,
+  const uint64_t *legacy_align, Error **errp)
 {
+PCDIMMDevice *dimm = PC_DIMM(dev);
+PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
 Error *local_err = NULL;
+MemoryRegion *mr;
+uint64_t addr, align;
 int slot;
 
 slot = object_property_get_int(OBJECT(dev), PC_DIMM_SLOT_PROP,
@@ -43,44 +48,41 @@ void pc_dimm_pre_plug(DeviceState *dev, MachineState 
*machine, Error **errp)
 }
 object_property_set_int(OBJECT(dev), slot, PC_DIMM_SLOT_PROP, 
_abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
+
+mr = ddc->get_memory_region(dimm, _err);
+if (local_err) {
+goto out;
+}
+
+align = legacy_align ? *legacy_align : memory_region_get_alignment(mr);
+addr = object_property_get_uint(OBJECT(dev), PC_DIMM_ADDR_PROP,
+_abort);
+addr = memory_device_get_free_addr(machine, !addr ? NULL : , align,
+   memory_region_size(mr), _err);
+if (local_err) {
+goto out;
+}
+trace_mhp_pc_dimm_assigned_address(addr);
+object_property_set_uint(OBJECT(dev), addr, PC_DIMM_ADDR_PROP,
+ _abort);
 out:
 error_propagate(errp, local_err);
 }
 
-void pc_dimm_plug(DeviceState *dev, MachineState *machine, uint64_t align,
-  Error **errp)
+void pc_dimm_plug(DeviceState *dev, MachineState *machine, Error **errp)
 {
 PCDIMMDevice *dimm = PC_DIMM(dev);
 PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
 MemoryRegion *vmstate_mr = ddc->get_vmstate_memory_region(dimm,
   _abort);
 MemoryRegion *mr = ddc->get_memory_region(dimm, _abort);
-Error *local_err = NULL;
 uint64_t addr;
 
-addr = object_property_get_uint(OBJECT(dimm),
-PC_DIMM_ADDR_PROP, _err);
-if (local_err) {
-goto out;
-}
-
-addr = memory_device_get_free_addr(machine, 

Re: [Qemu-devel] [PATCH] monitor: avoid potential dead-lock when cleaning up

[Marc-André Lureau]

Hi

On Wed, Aug 1, 2018 at 3:19 PM, Markus Armbruster  wrote:
> Marc-André Lureau  writes:
>
>> When a monitor is connected to a Spice chardev, the monitor cleanup
>> can dead-lock:
>>
>>  #0  0x7f43446637fd in __lll_lock_wait () at /lib64/libpthread.so.0
>>  #1  0x7f434465ccf4 in pthread_mutex_lock () at /lib64/libpthread.so.0
>>  #2  0x556dd79f22ba in qemu_mutex_lock_impl (mutex=0x556dd81c9220 
>> , file=0x556dd7ae3648 "/home/elmarco/src/qq/monitor.c", 
>> line=645) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66
>>  #3  0x556dd7431bd5 in monitor_qapi_event_queue 
>> (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x556dd9abc850, 
>> errp=0x7fffb7bbddd8) at /home/elmarco/src/qq/monitor.c:645
>>  #4  0x556dd79d476b in qapi_event_send_spice_disconnected 
>> (server=0x556dd98ee760, client=0x556ddaaa8560, errp=0x556dd82180d0 
>> ) at qapi/qapi-events-ui.c:149
>>  #5  0x556dd7870fc1 in channel_event (event=3, info=0x556ddad1b590) at 
>> /home/elmarco/src/qq/ui/spice-core.c:235
>>  #6  0x7f434560a6bb in reds_handle_channel_event (reds=, 
>> event=3, info=0x556ddad1b590) at reds.c:316
>>  #7  0x7f43455f393b in main_dispatcher_self_handle_channel_event 
>> (info=0x556ddad1b590, event=3, self=0x556dd9a7d8c0) at main-dispatcher.c:197
>>  #8  0x7f43455f393b in main_dispatcher_channel_event 
>> (self=0x556dd9a7d8c0, event=event@entry=3, info=0x556ddad1b590) at 
>> main-dispatcher.c:197
>>  #9  0x7f4345612833 in red_stream_push_channel_event 
>> (s=s@entry=0x556ddae2ef40, event=event@entry=3) at red-stream.c:414
>>  #10 0x7f434561286b in red_stream_free (s=0x556ddae2ef40) at 
>> red-stream.c:388
>>  #11 0x7f43455f9ddc in red_channel_client_finalize 
>> (object=0x556dd9bb21a0) at red-channel-client.c:347
>>  #12 0x7f434b5f9fb9 in g_object_unref () at /lib64/libgobject-2.0.so.0
>>  #13 0x7f43455fc212 in red_channel_client_push (rcc=0x556dd9bb21a0) at 
>> red-channel-client.c:1341
>>  #14 0x556dd76081ba in spice_port_set_fe_open (chr=0x556dd9925e20, 
>> fe_open=0) at /home/elmarco/src/qq/chardev/spice.c:241
>>  #15 0x556dd796d74a in qemu_chr_fe_set_open (be=0x556dd9a37c00, 
>> fe_open=0) at /home/elmarco/src/qq/chardev/char-fe.c:340
>>  #16 0x556dd796d4d9 in qemu_chr_fe_set_handlers (b=0x556dd9a37c00, 
>> fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, opaque=0x0, 
>> context=0x0, set_open=true) at /home/elmarco/src/qq/chardev/char-fe.c:280
>>  #17 0x556dd796d359 in qemu_chr_fe_deinit (b=0x556dd9a37c00, del=false) 
>> at /home/elmarco/src/qq/chardev/char-fe.c:233
>>  #18 0x556dd7432240 in monitor_data_destroy (mon=0x556dd9a37c00) at 
>> /home/elmarco/src/qq/monitor.c:786
>>  #19 0x556dd743b968 in monitor_cleanup () at 
>> /home/elmarco/src/qq/monitor.c:4683
>>  #20 0x556dd75ce776 in main (argc=3, argv=0x7fffb7bbe458, 
>> envp=0x7fffb7bbe478) at /home/elmarco/src/qq/vl.c:4660
>>
>> Because spice code tries to emit a "disconnected" signal on the
>> monitors. Fix this situation by tightening the monitor lock time to
>> the monitor list removal.
>>
>> Signed-off-by: Marc-André Lureau 
>
> Do you think this should go into 3.0?
>
>> ---
>>  monitor.c | 22 +++---
>>  1 file changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/monitor.c b/monitor.c
>> index 0fa0910a2a..a16a6c5311 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -4702,8 +4702,6 @@ void monitor_init(Chardev *chr, int flags)
>>
>>  void monitor_cleanup(void)
>>  {
>> -Monitor *mon, *next;
>> -
>>  /*
>>   * We need to explicitly stop the I/O thread (but not destroy it),
>>   * clean up the monitor resources, then destroy the I/O thread since
>> @@ -4719,14 +4717,24 @@ void monitor_cleanup(void)
>>  monitor_qmp_bh_responder(NULL);
>>
>>  /* Flush output buffers and destroy monitors */
>> -qemu_mutex_lock(_lock);
>> -QTAILQ_FOREACH_SAFE(mon, _list, entry, next) {
>> -QTAILQ_REMOVE(_list, mon, entry);
>> +do {
>
> for (;;), please.
>
>> +Monitor *mon;
>> +
>> +qemu_mutex_lock(_lock);
>> +mon = QTAILQ_FIRST(_list);
>> +if (mon) {
>> +QTAILQ_REMOVE(_list, mon, entry);
>> +}
>> +qemu_mutex_unlock(_lock);
>> +
>> +if (!mon) {
>> +break;
>> +}
>> +
>>  monitor_flush(mon);
>>  monitor_data_destroy(mon);
>>  g_free(mon);
>> -}
>> -qemu_mutex_unlock(_lock);
>> +} while (true);
>>
>>  /* QEMUBHs needs to be deleted before destroying the I/O thread */
>>  qemu_bh_delete(qmp_dispatcher_bh);
>
> Iterating safely over a list protected by a lock should be easier than
> that.  Sad.
>
> Hmm, what about this:
>
> diff --git a/monitor.c b/monitor.c
> index 77861e96af..4a23f6c7bc 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -4721,9 +4721,11 @@ void monitor_cleanup(void)
>  qemu_mutex_lock(_lock);
>  QTAILQ_FOREACH_SAFE(mon, _list, entry, next) {
>  QTAILQ_REMOVE(_list, mon, 

Re: [Qemu-devel] [PATCH] tests: virtio: separate ccw tests from libqos

[Cornelia Huck]

On Wed,  1 Aug 2018 15:27:33 +0200
Paolo Bonzini  wrote:

> Because qtest does not support s390 channel I/O, s390 only performs smoke 
> tests on
> those few devices that do not have any functional tests.  Therefore, every 
> time we
> add functional tests for a virtio device, the choice is between removing
> those tests from the s390 suite (so that s390 actually _loses_ coverage)
> or sprinkling the test with architecture checks.
> 
> This patch simply creates a ccw-specific test that only performs smoke tests 
> on
> all virtio-ccw devices.  If channel I/O support is ever added to qtest and 
> libqos,
> then this file can go away.  In the meanwhile, it simplifies maintenance and
> makes sure that all virtio devices are tested.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  tests/Makefile.include  |   5 +-
>  tests/virtio-ccw-test.c | 118 
>  2 files changed, 120 insertions(+), 3 deletions(-)
>  create mode 100644 tests/virtio-ccw-test.c

I'm not that familiar with qtest/libqos, but that sounds like a
reasonable approach.

Acked-by: Cornelia Huck 

Re: [Qemu-devel] [PATCH 2/4] target/arm: Fix typo in do_sat_addsub_64

[Laurent Desnogues]

On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
 wrote:
> Used the wrong temporary in the computation of subtractive overflow.
>
> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Laurent Desnogues 
Tested-by: Laurent Desnogues 


Laurent

> ---
>  target/arm/translate-sve.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
> index 374051cd20..9dd4c38bab 100644
> --- a/target/arm/translate-sve.c
> +++ b/target/arm/translate-sve.c
> @@ -1625,7 +1625,7 @@ static void do_sat_addsub_64(TCGv_i64 reg, TCGv_i64 
> val, bool u, bool d)
>  /* Detect signed overflow for subtraction.  */
>  tcg_gen_xor_i64(t0, reg, val);
>  tcg_gen_sub_i64(t1, reg, val);
> -tcg_gen_xor_i64(reg, reg, t0);
> +tcg_gen_xor_i64(reg, reg, t1);
>  tcg_gen_and_i64(t0, t0, reg);
>
>  /* Bound the result.  */
> --
> 2.17.1
>

Re: [Qemu-devel] [PATCH 0/4] target/arm sve fixes

[Laurent Desnogues]

On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
 wrote:
> These four patches are minor, reported by Laurent this week.

This fixes the reported issues, thanks!

> If there happens to be an -rc4 release, it would be nice if
> they were included.  But if not, no biggie.  I suspect that
> other minor issues will be found past these four, so I would
> hope everyone who cares about sve is just as happy working
> from a branch anyway.

I indeed still have some things to look at.


Laurent

>
> r~
>
>
> Richard Henderson (4):
>   target/arm: Fix sign of sve_cmpeq_ppzw/sve_cmpne_ppzw
>   target/arm: Fix typo in do_sat_addsub_64
>   target/arm: Reorganize SVE WHILE
>   target/arm: Fix typo in helper_sve_movz_d
>
>  target/arm/sve_helper.c| 19 ++
>  target/arm/translate-sve.c | 51 --
>  2 files changed, 40 insertions(+), 30 deletions(-)
>
> --
> 2.17.1
>

Re: [Qemu-devel] [PATCH 3/4] target/arm: Reorganize SVE WHILE

[Laurent Desnogues]

On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
 wrote:
> The pseudocode for this operation is an increment + compare loop,
> so comparing <= the maximum integer produces an all-true predicate.
>
> Rather than bound in both the inline code and the helper, pass the
> helper the number of predicate bits to set instead of the number
> of predicate elements to set.
>
> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Laurent Desnogues 
Tested-by: Laurent Desnogues 


Laurent

> ---
>  target/arm/sve_helper.c|  5 
>  target/arm/translate-sve.c | 49 +-
>  2 files changed, 32 insertions(+), 22 deletions(-)
>
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 9bd0694d55..87594a8adb 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -2846,11 +2846,6 @@ uint32_t HELPER(sve_while)(void *vd, uint32_t count, 
> uint32_t pred_desc)
>  return flags;
>  }
>
> -/* Scale from predicate element count to bits.  */
> -count <<= esz;
> -/* Bound to the bits in the predicate.  */
> -count = MIN(count, oprsz * 8);
> -
>  /* Set all of the requested bits.  */
>  for (i = 0; i < count / 64; ++i) {
>  d->p[i] = esz_mask;
> diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
> index 9dd4c38bab..89efc80ee7 100644
> --- a/target/arm/translate-sve.c
> +++ b/target/arm/translate-sve.c
> @@ -3173,19 +3173,19 @@ static bool trans_CTERM(DisasContext *s, arg_CTERM 
> *a, uint32_t insn)
>
>  static bool trans_WHILE(DisasContext *s, arg_WHILE *a, uint32_t insn)
>  {
> -if (!sve_access_check(s)) {
> -return true;
> -}
> -
> -TCGv_i64 op0 = read_cpu_reg(s, a->rn, 1);
> -TCGv_i64 op1 = read_cpu_reg(s, a->rm, 1);
> -TCGv_i64 t0 = tcg_temp_new_i64();
> -TCGv_i64 t1 = tcg_temp_new_i64();
> +TCGv_i64 op0, op1, t0, t1, tmax;
>  TCGv_i32 t2, t3;
>  TCGv_ptr ptr;
>  unsigned desc, vsz = vec_full_reg_size(s);
>  TCGCond cond;
>
> +if (!sve_access_check(s)) {
> +return true;
> +}
> +
> +op0 = read_cpu_reg(s, a->rn, 1);
> +op1 = read_cpu_reg(s, a->rm, 1);
> +
>  if (!a->sf) {
>  if (a->u) {
>  tcg_gen_ext32u_i64(op0, op0);
> @@ -3198,32 +3198,47 @@ static bool trans_WHILE(DisasContext *s, arg_WHILE 
> *a, uint32_t insn)
>
>  /* For the helper, compress the different conditions into a computation
>   * of how many iterations for which the condition is true.
> - *
> - * This is slightly complicated by 0 <= UINT64_MAX, which is nominally
> - * 2**64 iterations, overflowing to 0.  Of course, predicate registers
> - * aren't that large, so any value >= predicate size is sufficient.
>   */
> +t0 = tcg_temp_new_i64();
> +t1 = tcg_temp_new_i64();
>  tcg_gen_sub_i64(t0, op1, op0);
>
> -/* t0 = MIN(op1 - op0, vsz).  */
> -tcg_gen_movi_i64(t1, vsz);
> -tcg_gen_umin_i64(t0, t0, t1);
> +tmax = tcg_const_i64(vsz >> a->esz);
>  if (a->eq) {
>  /* Equality means one more iteration.  */
>  tcg_gen_addi_i64(t0, t0, 1);
> +
> +/* If op1 is max (un)signed integer (and the only time the addition
> + * above could overflow), then we produce an all-true predicate by
> + * setting the count to the vector length.  This is because the
> + * pseudocode is described as an increment + compare loop, and the
> + * max integer would always compare true.
> + */
> +tcg_gen_movi_i64(t1, (a->sf
> +  ? (a->u ? UINT64_MAX : INT64_MAX)
> +  : (a->u ? UINT32_MAX : INT32_MAX)));
> +tcg_gen_movcond_i64(TCG_COND_EQ, t0, op1, t1, tmax, t0);
>  }
>
> -/* t0 = (condition true ? t0 : 0).  */
> +/* Bound to the maximum.  */
> +tcg_gen_umin_i64(t0, t0, tmax);
> +tcg_temp_free_i64(tmax);
> +
> +/* Set the count to zero if the condition is false.  */
>  cond = (a->u
>  ? (a->eq ? TCG_COND_LEU : TCG_COND_LTU)
>  : (a->eq ? TCG_COND_LE : TCG_COND_LT));
>  tcg_gen_movi_i64(t1, 0);
>  tcg_gen_movcond_i64(cond, t0, op0, op1, t0, t1);
> +tcg_temp_free_i64(t1);
>
> +/* Since we're bounded, pass as a 32-bit type.  */
>  t2 = tcg_temp_new_i32();
>  tcg_gen_extrl_i64_i32(t2, t0);
>  tcg_temp_free_i64(t0);
> -tcg_temp_free_i64(t1);
> +
> +/* Scale elements to bits.  */
> +tcg_gen_shli_i32(t2, t2, a->esz);
>
>  desc = (vsz / 8) - 2;
>  desc = deposit32(desc, SIMD_DATA_SHIFT, 2, a->esz);
> --
> 2.17.1
>

Re: [Qemu-devel] [PATCH 1/4] target/arm: Fix sign of sve_cmpeq_ppzw/sve_cmpne_ppzw

[Laurent Desnogues]

On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
 wrote:
> The normal vector element is sign-extended before
> comparing with the wide vector element.
>
> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Laurent Desnogues 
Tested-by: Laurent Desnogues 


Laurent

> ---
>  target/arm/sve_helper.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 54795c9194..9bd0694d55 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -2436,13 +2436,13 @@ uint32_t HELPER(NAME)(void *vd, void *vn, void *vm, 
> void *vg, uint32_t desc) \
>  #define DO_CMP_PPZW_S(NAME, TYPE, TYPEW, OP) \
>  DO_CMP_PPZW(NAME, TYPE, TYPEW, OP, H1_4, 0xull)
>
> -DO_CMP_PPZW_B(sve_cmpeq_ppzw_b, uint8_t,  uint64_t, ==)
> -DO_CMP_PPZW_H(sve_cmpeq_ppzw_h, uint16_t, uint64_t, ==)
> -DO_CMP_PPZW_S(sve_cmpeq_ppzw_s, uint32_t, uint64_t, ==)
> +DO_CMP_PPZW_B(sve_cmpeq_ppzw_b, int8_t,  uint64_t, ==)
> +DO_CMP_PPZW_H(sve_cmpeq_ppzw_h, int16_t, uint64_t, ==)
> +DO_CMP_PPZW_S(sve_cmpeq_ppzw_s, int32_t, uint64_t, ==)
>
> -DO_CMP_PPZW_B(sve_cmpne_ppzw_b, uint8_t,  uint64_t, !=)
> -DO_CMP_PPZW_H(sve_cmpne_ppzw_h, uint16_t, uint64_t, !=)
> -DO_CMP_PPZW_S(sve_cmpne_ppzw_s, uint32_t, uint64_t, !=)
> +DO_CMP_PPZW_B(sve_cmpne_ppzw_b, int8_t,  uint64_t, !=)
> +DO_CMP_PPZW_H(sve_cmpne_ppzw_h, int16_t, uint64_t, !=)
> +DO_CMP_PPZW_S(sve_cmpne_ppzw_s, int32_t, uint64_t, !=)
>
>  DO_CMP_PPZW_B(sve_cmpgt_ppzw_b, int8_t,   int64_t, >)
>  DO_CMP_PPZW_H(sve_cmpgt_ppzw_h, int16_t,  int64_t, >)
> --
> 2.17.1
>

Re: [Qemu-devel] [PATCH 4/4] target/arm: Fix typo in helper_sve_movz_d

[Laurent Desnogues]

On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
 wrote:
> Reported-by: Laurent Desnogues 
> Signed-off-by: Richard Henderson 

Reviewed-by: Laurent Desnogues 
Tested-by: Laurent Desnogues 


Laurent

> ---
>  target/arm/sve_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 87594a8adb..c3cbec9cf5 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1042,7 +1042,7 @@ void HELPER(sve_movz_d)(void *vd, void *vn, void *vg, 
> uint32_t desc)
>  uint64_t *d = vd, *n = vn;
>  uint8_t *pg = vg;
>  for (i = 0; i < opr_sz; i += 1) {
> -d[i] = n[1] & -(uint64_t)(pg[H1(i)] & 1);
> +d[i] = n[i] & -(uint64_t)(pg[H1(i)] & 1);
>  }
>  }
>
> --
> 2.17.1
>

[Qemu-devel] [PATCH] tests: virtio: separate ccw tests from libqos

[Paolo Bonzini]

Because qtest does not support s390 channel I/O, s390 only performs smoke tests 
on
those few devices that do not have any functional tests.  Therefore, every time 
we
add functional tests for a virtio device, the choice is between removing
those tests from the s390 suite (so that s390 actually _loses_ coverage)
or sprinkling the test with architecture checks.

This patch simply creates a ccw-specific test that only performs smoke tests on
all virtio-ccw devices.  If channel I/O support is ever added to qtest and 
libqos,
then this file can go away.  In the meanwhile, it simplifies maintenance and
makes sure that all virtio devices are tested.

Signed-off-by: Paolo Bonzini 
---
 tests/Makefile.include  |   5 +-
 tests/virtio-ccw-test.c | 118 
 2 files changed, 120 insertions(+), 3 deletions(-)
 create mode 100644 tests/virtio-ccw-test.c

diff --git a/tests/Makefile.include b/tests/Makefile.include
index a49282704e..cf835f2fd0 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -401,9 +401,7 @@ check-qtest-s390x-$(CONFIG_SLIRP) += 
tests/test-netfilter$(EXESUF)
 check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-mirror$(EXESUF)
 check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-redirector$(EXESUF)
 check-qtest-s390x-y += tests/drive_del-test$(EXESUF)
-check-qtest-s390x-y += tests/virtio-balloon-test$(EXESUF)
-check-qtest-s390x-y += tests/virtio-console-test$(EXESUF)
-check-qtest-s390x-y += tests/virtio-serial-test$(EXESUF)
+check-qtest-s390x-y += tests/virtio-ccw-test$(EXESUF)
 check-qtest-s390x-y += tests/cpu-plug-test$(EXESUF)
 
 check-qtest-generic-y += tests/machine-none-test$(EXESUF)
@@ -807,6 +805,7 @@ tests/wdt_ib700-test$(EXESUF): tests/wdt_ib700-test.o
 tests/tco-test$(EXESUF): tests/tco-test.o $(libqos-pc-obj-y)
 tests/virtio-balloon-test$(EXESUF): tests/virtio-balloon-test.o 
$(libqos-virtio-obj-y)
 tests/virtio-blk-test$(EXESUF): tests/virtio-blk-test.o $(libqos-virtio-obj-y)
+tests/virtio-ccw-test$(EXESUF): tests/virtio-ccw-test.o
 tests/virtio-net-test$(EXESUF): tests/virtio-net-test.o $(libqos-pc-obj-y) 
$(libqos-virtio-obj-y)
 tests/virtio-rng-test$(EXESUF): tests/virtio-rng-test.o $(libqos-pc-obj-y)
 tests/virtio-scsi-test$(EXESUF): tests/virtio-scsi-test.o 
$(libqos-virtio-obj-y)
diff --git a/tests/virtio-ccw-test.c b/tests/virtio-ccw-test.c
new file mode 100644
index 00..0af3a7bb31
--- /dev/null
+++ b/tests/virtio-ccw-test.c
@@ -0,0 +1,118 @@
+/*
+ * QTest testcase for VirtIO CCW
+ *
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ * Copyright (c) 2018 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+/* Until we have a full libqos implementation of virtio-ccw (which requires
+ * also to add support for I/O channels to qtest), we can only do simple
+ * tests that initialize the devices.
+ */
+
+#include "qemu/osdep.h"
+#include "libqtest.h"
+#include "libqos/virtio.h"
+
+static void virtio_balloon_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-balloon-ccw");
+qtest_end();
+}
+
+static void virtconsole_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-serial-ccw,id=vser0 "
+"-device virtconsole,bus=vser0.0");
+qtest_end();
+}
+
+static void virtserialport_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-serial-ccw,id=vser0 "
+"-device virtserialport,bus=vser0.0");
+qtest_end();
+}
+
+static void virtio_serial_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-serial-ccw");
+qtest_end();
+}
+
+static void virtio_serial_hotplug(void)
+{
+global_qtest = qtest_startf("-device virtio-serial-ccw");
+qtest_qmp_device_add("virtserialport", "hp-port", NULL);
+qtest_qmp_device_del("hp-port");
+qtest_end();
+}
+
+static void virtio_blk_nop(void)
+{
+global_qtest = qtest_startf("-drive 
if=none,id=drv0,file=null-co://,format=raw "
+"-device virtio-blk-ccw,drive=drv0");
+qtest_end();
+}
+
+static void virtio_net_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-net-ccw");
+qtest_end();
+}
+
+static void virtio_9p_nop(void)
+{
+global_qtest = qtest_startf("-fsdev synth,id=fsdev0 "
+"-device 
virtio-9p-ccw,fsdev=fsdev0,mount_tag=qtest");
+qtest_end();
+}
+
+static void virtio_rng_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-rng-ccw");
+qtest_end();
+}
+
+static void virtio_scsi_nop(void)
+{
+global_qtest = qtest_startf("-device virtio-scsi-ccw");
+qtest_end();
+}
+
+static void virtio_scsi_hotplug(void)
+{
+global_qtest = qtest_startf("-drive 
if=none,id=drv0,file=null-co://,format=raw "
+"-drive 
if=none,id=drv1,file=null-co://,format=raw "
+"-device virtio-scsi-ccw "
+   

Re: [Qemu-devel] [PATCH v4 2/2] s390x: Enable KVM huge page backing support

[David Hildenbrand]

On 01.08.2018 15:19, Janosch Frank wrote:
> QEMU has had huge page support for a longer time already, but KVM
> memory management under s390x needed some changes to work with huge
> backings.
> 
> Now that we have support, let's enable it if requested and
> available. Otherwise we now properly tell the user if there is no
> support and back out instead of failing to run the VM later on.
> 
> Signed-off-by: Janosch Frank 
> ---
>  target/s390x/kvm.c | 34 --
>  1 file changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index d923cf4240..d1c72975cf 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -34,6 +34,8 @@
>  #include "qapi/error.h"
>  #include "qemu/error-report.h"
>  #include "qemu/timer.h"
> +#include "qemu/units.h"
> +#include "qemu/mmap-alloc.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/hw_accel.h"
>  #include "hw/hw.h"
> @@ -139,6 +141,7 @@ static int cap_mem_op;
>  static int cap_s390_irq;
>  static int cap_ri;
>  static int cap_gs;
> +static int cap_hpage_1m;
>  
>  static int active_cmma;
>  
> @@ -220,9 +223,9 @@ static void kvm_s390_enable_cmma(void)
>  .attr = KVM_S390_VM_MEM_ENABLE_CMMA,
>  };
>  
> -if (mem_path) {
> +if (cap_hpage_1m) {
>  warn_report("CMM will not be enabled because it is not "
> -"compatible with hugetlbfs.");
> +"compatible with huge memory backings.");

This implies some change to certain setups (tmpfs), but as they are
absolutely not common (and never really were supported/expected to
work), I think this is fine.

Reviewed-by: David Hildenbrand 

>  return;
>  }
>  rc = kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, );
> @@ -281,10 +284,37 @@ void kvm_s390_crypto_reset(void)
>  }
>  }
>  
> +static int kvm_s390_configure_mempath_backing(KVMState *s)
> +{
> +size_t path_psize = qemu_mempath_getpagesize(mem_path);
> +
> +if (path_psize == 4 * KiB)
> +return 0;
> +
> +if (path_psize != 1 * MiB) {
> +error_report("Memory backing with 2G pages was specified, "
> + "but KVM does not support this memory backing");
> +return -EINVAL;
> +}
> +
> +if (kvm_vm_enable_cap(s, KVM_CAP_S390_HPAGE_1M, 0)) {
> +error_report("Memory backing with 1M pages was specified, "
> + "but KVM does not support this memory backing");
> +return -EINVAL;
> +}
> +
> +cap_hpage_1m = 1;
> +return 0;
> +}
> +
>  int kvm_arch_init(MachineState *ms, KVMState *s)
>  {
>  MachineClass *mc = MACHINE_GET_CLASS(ms);
>  
> +if (mem_path && kvm_s390_configure_mempath_backing(s)) {
> +return -EINVAL;
> +}
> +
>  mc->default_cpu_type = S390_CPU_TYPE_NAME("host");
>  cap_sync_regs = kvm_check_extension(s, KVM_CAP_SYNC_REGS);
>  cap_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF);
> 


-- 

Thanks,

David / dhildenb