[Qemu-devel] [Bug 1289788] Re: MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x

Status in QEMU:
  Expired

Bug description:
  Windows NT 4.0 and 2000 (including the latest git release), when enabling 
adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on 
QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like 
canyon.mid, etc). I have already tried bisecting but seems that this bug has 
been introduced sometime in 1.7.0's development time.
  Screenshot attached: http://goput.it/ig2l.png

  OS Used: Windows 7 x64 Ultimate SP1
  command-line used: qemu-system-i386w.exe -L pc-bios -m 64 -cpu pentium -drive 
file=vbent40.img,if=floppy,id=fda -drive 
file=vhd.vhd,if=ide,media=disk,bus=0,unit=0,id=harddisk0 -drive 
file=E:,if=ide,media=cdrom,bus=1,unit=0,id=cdrom -net nic,model=pcnet -net user 
-vga std -device ES1370 -boot menu=on -monitor 
telnet:127.0.0.1:,server,nowait

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

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

[Gonglei (Arei)]

>
> From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com]
> Sent: Friday, May 05, 2017 10:33 PM
> 
> On 05/05/2017 07:56 AM, Gonglei (Arei) wrote:
> >>
> >>
> >> On 05/04/2017 03:53 PM, Gonglei (Arei) wrote:
> >>> Sorry, I missed one comment in the previous reply.
> >>>
> 
> > +\end{itemize*}
> > +
> 
>  What about extensibility regarding "detailed algorithms"? Is the driver
>  required ignore algorithms
>  it does not "know about"? Should we reserve the not (yet) defined bits?
> 
> >>> I mean the device MUST set the algorithms mask bits based on supported
> >>> algorithms by the device, and the driver read them to get the capacity.
> >>> I don't think we should care about the not defined bits.
> >>
> >> Let us assume that the driver fails if it encounters an unknown bit
> >> (i.e. bit 13 set in hash_algo). I do not think there is anything in
> >> this document that prohibits the driver doing so -- if there is please
> >> do tell. Now at some point we want to support a new hash algorithm.
> >> If we can't be sure that existing drivers are going to play along with
> >> defining new bits (which are 'not defined bits' using your words for
> >> the existing drivers) we have a small problem.
> >>
> >> Was I clear about my concern?
> >>
> > Sorry, I'm confused. For the device, it just set the bit mask based on
> > supported algorithms. Please see cryptodev_builtin_init()
> > in cryptodev-builtin.c, the current device only support AES_CBC algorithm,
> > so we just need set:
> >  backend->conf.cipher_algo_l = 1u << VIRTIO_CRYPTO_CIPHER_AES_CBC;
> >  backend->conf.hash_algo = 1u << VIRTIO_CRYPTO_HASH_SHA1;
> >
> > Then the driver can only register AES CBC algorithm to the LKCF. Other
> > algorithms are not supported no matter the driver if register them or not.
> >
> > Thanks,
> > -Gonglei
> >
> 
> Now I'm confused too. So let's try to clear things up with two simple
> question:
> 
> 1) Is a device allowed to so set not defined bits ( garbage values or
> even worse an implementation specific usage) way (e.g. bit 13 for
> hash_algo)?
> 
No.

> 2) Is a driver allowed to rejects unknown algorithm bits (e.g. give up on
> the device because it considers it broken)?
> 
No. The driver doesn't need to rejects, it just need care about the known 
algorithms.

> If the answer is 'no' please point me to the appropriate conformance
> statements.
> 
OK, let's add the conformance statements in the next version.

> Question 1) is about why should we reserve the remaining
> bits for future use.
> 
> Question 2) is about the interaction with feature bits -- if the answer
> is 'yes' then we have to guard new algorithms with feature bits.
> 
Thanks for explanation, I get your point until now :)
 
Thanks,
-Gonglei

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

[Gonglei (Arei)]

>
> From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com]
> Sent: Friday, May 05, 2017 9:52 PM
> 
> On 05/05/2017 05:39 AM, Gonglei (Arei) wrote:
> >>
> >>
> >> On 05/04/2017 04:13 PM, Gonglei (Arei) wrote:
> 
> 
>  On 05/04/2017 03:33 PM, Gonglei (Arei) wrote:
> >>> +\begin{description}
> >>> +\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires
> >> VIRTIO_CRYPTO_F_STATELESS_MODE.
> >>> +\end{description}
> >>
> >> I find feature bit 0 redundant and bit confusing. We had a discussion
> >> in v15 and v16.
> >>
> >> Could you answer:
> >>
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg03214.html
> >> (Message-ID:
>  <1fbe30cc-87ec-32bc-4c57-85f9b03b3...@linux.vnet.ibm.com>)
> >>
> >>
> > Please see my reply:
> > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03186.html
> >
> > The main reason is we should keep compatibility to pre-existing driver
> and
> > support some function that different services have different modes.
> > We have only one unique crypto request named structure
>  virtio_crypto_op_data_req_mux.
> > Please continue to see the sepc, you'll find the truth.
> >
> 
>  Sorry, I still do not understand why can't we drop
>  VIRTIO_CRYPTO_F_STATELESS_MODE
>  and just keep the four service specific modes.
> 
>  Can you point me to the (published) code where
>  VIRTIO_CRYPTO_F_STATELESS_MODE is
>  used (that's what I'm missing -- preferably state the repository, the
> commit
>  a file and a line using VIRTIO_CRYPTO_F_STATELESS_MODE)?
> 
> >>> No no no, there isn't existing code use
> VIRTIO_CRYPTO_F_STATELESS_MODE
> >> yet,
> >>> It's just for future use.
> >>>
> >>
> >> Thanks, that's a crucial piece of information. In the thread I referenced
> >> this was not cleared (at least for me). It would be really nice to have
> >> some working code before doing the spec, because I find it very easy to 
> >> miss
> >> a detail which renders the whole thing useless if one works solely on
> >> theoretical level and does not try to create at least a working prototype.
> >>
> > I see.
> >
> >>> Please the blow description:
> >>> """
> >>> \drivernormative{\paragraph}{HASH Service Operation}{Device Types /
> Crypto
> >> Device / Device Operation / HASH Service Operation}
> >>>
> >>> \begin{itemize*}
> >>> \item If the driver uses the session mode, then the driver MUST set
> >> \field{session_id} in struct virtio_crypto_op_header
> >>>   to a valid value assigned by the device when the session was
> created.
> >>> \item If the VIRTIO_CRYPTO_F_STATELESS_MODE feature bit is
> negotiated,
> >> the driver MUST use struct virtio_crypto_op_data_req_mux to wrap crypto
> >> requests. Otherwise, the driver MUST use struct
> virtio_crypto_op_data_req.
> >>> \item If the VIRTIO_CRYPTO_F_HASH_STATELESS_MODE feature bit is
> >> negotiated, 1) if the driver uses the stateless mode, then the driver MUST
> set
> >> the \field{flag} field in struct virtio_crypto_op_header
> >>>   to VIRTIO_CRYPTO_FLAG_STATELESS_MODE and MUST set the
> fields
> >> in struct virtio_crypto_hash_para_statelession.sess_para, 2) if the driver
> uses
> >> the session mode, then the driver MUST set the \field{flag} field in struct
> >> virtio_crypto_op_header to VIRTIO_CRYPTO_FLAG_STATE_MODE.
> >>> \item The driver MUST set \field{opcode} in struct virtio_crypto_op_header
> to
> >> VIRTIO_CRYPTO_HASH.
> >>> \end{itemize*}
> >>> """
> >>>
> >>> If we drop the VIRTIO_CRYPTO_F_STATELESS_MODE feature bit, and the
> >>> VIRTIO_CRYPTO_F_HASH_STATELESS_MODE feature bit is not negotiated,
> >>> then the driver doesn't to know use which structure to store the crypto
> >> request:
> >>> is struct virtio_crypto_op_data_req_mux ? or struct
> >> virtio_crypto_op_data_req.
> >>
> >> Thanks for the detailed explanation.
> >>
> >> Let's clarify some things first:
> >> 1) struct virtio_crypto_op_data_req_mux IS NOT a C language struct but
> >> a somewhat informal desciption using C-like syntax. If you don't follow
> >> try to reason about the size of struct virtio_crypto_op_data_req_mux.
> >> For instance look at:
> >> +struct virtio_crypto_cipher_data_req_stateless {
> >> +/* Device-readable part */
> >> +struct virtio_crypto_cipher_para_stateless para;
> >> +/* The cipher key */
> >> +u8 cipher_key[keylen];
> >> +
> >> +/* Initialization Vector or Counter data. */
> >> +u8 iv[iv_len];
> >> +/* Source data */
> >> +u8 src_data[src_data_len];   <==
> >>
> >> The  isrc_data_len is not a compile time constant!!
> >>
> >> +
> >> +/* Device-writable part 

Re: [Qemu-devel] dns server not working in QEMU using usermode networking (SLIRP)

[Samuel Thibault]

FONNEMANN Mark, on sam. 06 mai 2017 01:06:31 +, wrote:
> root@qemu:~# /initrd/bin/nslookup www.google.com 10.0.2.3
> Server:10.0.2.3
> Address 1: 10.0.2.3
> 
> nslookup: can't resolve 'www.google.com'

That's so weird there's no packet log. Does your guest perhaps have the
strace tool? Or perhaps you can manage to copy it over from another VM,
since it only depends on libc.

> >Do you get output when pinging 10.0.2.3?
> >(you won't get ping answers, but that's fine, qemu should still be able to 
> >see the requests coming in)
> 
> root@qemu:~# ping 10.0.2.3
> PING 10.0.2.3 (10.0.2.3): 56 data bytes
> 
> --- 10.0.2.3 ping statistics ---
> 9 packets transmitted, 0 packets received, 100% packet 
> loss
> 
> [mfonnemann@localhost qemu]$ cat logfile
> ip input a00020f -> a000203 1

Ok, so at least something gets through, even if not UDP 53.

Samuel

Re: [Qemu-devel] dns server not working in QEMU using usermode networking (SLIRP)

[FONNEMANN Mark]

>So it's supposed to be using 10.0.2.3 I guess. Just to make sure, you could try
>/initrd/bin/nslookup www.google.com 10.0.2.3

root@qemu:~# /initrd/bin/nslookup www.google.com 10.0.2.3
Server:10.0.2.3
Address 1: 10.0.2.3

nslookup: can't resolve 'www.google.com'

>Do you get output when pinging 10.0.2.3?
>(you won't get ping answers, but that's fine, qemu should still be able to see 
>the requests coming in)

root@qemu:~# ping 10.0.2.3
PING 10.0.2.3 (10.0.2.3): 56 data bytes

--- 10.0.2.3 ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss

[mfonnemann@localhost qemu]$ cat logfile
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1
ip input a00020f -> a000203 1

>Also, just to make sure: you don't have firewalling rules, do you?

How can I verify this? (iptables is not installed on this guest Linux) 

Re: [Qemu-devel] dns server not working in QEMU using usermode networking (SLIRP)

[Samuel Thibault]

FONNEMANN Mark, on sam. 06 mai 2017 00:33:40 +, wrote:
> >The attached patch should be dumping the same kind of information.
> 
> Nslookup does not produce any output in curses or in logfile (-D logfile.txt).

Uh.  So qemu can't be the culprit since it doesn't receive anything :)

> root@qemu:~# /initrd/bin/nslookup www.google.com
> Server:10.0.2.3
> Address 1: 10.0.2.3
> 
> nslookup: can't resolve 'www.google.com'

So it's supposed to be using 10.0.2.3 I guess. Just to make sure, you
could try

/initrd/bin/nslookup www.google.com 10.0.2.3

> I know the patch was applied because when I ping 10.0.2.2 I get the following:
> 
> root@qemu:~# ping 10.0.2.2
> PING 10.0.2.2 (10.0.2.2): 56 data bytes
> 64 bytes from 10.0.2.2: icmp_seq=0 ttl=255 time=0.5 ms
> [mfonnemann@localhost qemu]$ cat logfile
> ip input a00020f -> a000202 1
> ip input a00020f -> a000202 1

Do you get output when pinging 10.0.2.3?
(you won't get ping answers, but that's fine, qemu should still be able
to see the requests coming in)

Also, just to make sure: you don't have firewalling rules, do you?

Samuel

[Qemu-devel] [PATCH] syscall: fix compiler warnings (clang 5)

[Philippe Mathieu-Daudé]

static code analyzer complain:

linux-user/syscall.c:5575:9: warning: Dereference of undefined pointer value
if (*host_rt_dev_ptr != 0) {
^~~~

Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé 
---
 linux-user/syscall.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index cec8428589..c541e22693 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5526,7 +5526,7 @@ static abi_long do_ioctl_rt(const IOCTLEntry *ie, uint8_t 
*buf_temp,
 int target_size;
 void *argptr;
 abi_ulong *target_rt_dev_ptr;
-unsigned long *host_rt_dev_ptr;
+unsigned long *host_rt_dev_ptr = NULL;
 abi_long ret;
 int i;
 
@@ -5572,7 +5572,7 @@ static abi_long do_ioctl_rt(const IOCTLEntry *ie, uint8_t 
*buf_temp,
 unlock_user(argptr, arg, 0);
 
 ret = get_errno(safe_ioctl(fd, ie->host_cmd, buf_temp));
-if (*host_rt_dev_ptr != 0) {
+if (host_rt_dev_ptr != NULL && *host_rt_dev_ptr != 0) {
 unlock_user((void *)*host_rt_dev_ptr,
 *target_rt_dev_ptr, 0);
 }
-- 
2.11.0

Re: [Qemu-devel] dns server not working in QEMU using usermode networking (SLIRP)

[FONNEMANN Mark]

>The attached patch should be dumping the same kind of information.

Nslookup does not produce any output in curses or in logfile (-D logfile.txt). 
I tried it using the version installed on the root system (Busybox 1.0):

root@qemu:~# nslookup
BusyBox v1.00 (2010.04.14-20:01+) multi-call binary

Usage: nslookup [HOST] [SERVER]
root@qemu:~# nslookup www.google.com
*** Unknown host

nslookup: www.google.com: Unknown host

 as well as the newer version installed in initrd image which is version 1.25.1:

root@qemu:~# /initrd/bin/nslookup
BusyBox v1.25.1 (2017-05-01 19:00:24 EDT) multi-call binary.

Usage: nslookup [HOST] [SERVER]

Query the nameserver for the IP address of the given HOST
optionally using a specified DNS server
root@qemu:~# /initrd/bin/nslookup www.google.com
Server:10.0.2.3
Address 1: 10.0.2.3

nslookup: can't resolve 'www.google.com'

I know the patch was applied because when I ping 10.0.2.2 I get the following:

root@qemu:~# ping 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: icmp_seq=0 ttl=255 time=0.5 ms
64 bytes from 10.0.2.2: icmp_seq=1 ttl=255 time=0.1 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=255 time=0.1 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=255 time=0.1 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=255 time=0.2 ms

--- 10.0.2.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.2/0.5 ms

[mfonnemann@localhost qemu]$ cat logfile
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1
ip input a00020f -> a000202 1

mark.

Re: [Qemu-devel] [PATCH v5 4/5] slirp: fix leak

[Samuel Thibault]

Applied to my tree, thanks!

Re: [Qemu-devel] [Qemu-devel RFC v3 4/5] msf2: Add Smartfusion2 SoC.

[Alistair Francis]

On Fri, May 5, 2017 at 9:14 AM, sundeep subbaraya
 wrote:
> Hi Alistair,
>
> On Fri, May 5, 2017 at 3:51 AM, Alistair Francis  wrote:
>> On Fri, Apr 28, 2017 at 9:51 AM, Subbaraya Sundeep
>>  wrote:
>>> Smartfusion2 SoC has hardened Microcontroller subsystem
>>> and flash based FPGA fabric. This patch adds support for
>>> Microcontroller subsystem in the SoC.
>>>
>>> Signed-off-by: Subbaraya Sundeep 
>>> ---
>>>  default-configs/arm-softmmu.mak |   1 +
>>>  hw/arm/Makefile.objs|   2 +-
>>>  hw/arm/msf2_soc.c   | 194 
>>> 
>>>  include/hw/arm/msf2_soc.h   |  62 +
>>>  4 files changed, 258 insertions(+), 1 deletion(-)
>>>  create mode 100644 hw/arm/msf2_soc.c
>>>  create mode 100644 include/hw/arm/msf2_soc.h
>>>
>>> diff --git a/default-configs/arm-softmmu.mak 
>>> b/default-configs/arm-softmmu.mak
>>> index 78d7af0..7062512 100644
>>> --- a/default-configs/arm-softmmu.mak
>>> +++ b/default-configs/arm-softmmu.mak
>>> @@ -122,3 +122,4 @@ CONFIG_ACPI=y
>>>  CONFIG_SMBIOS=y
>>>  CONFIG_ASPEED_SOC=y
>>>  CONFIG_GPIO_KEY=y
>>> +CONFIG_MSF2=y
>>> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
>>> index 4c5c4ee..cce2759 100644
>>> --- a/hw/arm/Makefile.objs
>>> +++ b/hw/arm/Makefile.objs
>>> @@ -1,7 +1,7 @@
>>>  obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
>>>  obj-$(CONFIG_DIGIC) += digic_boards.o
>>>  obj-y += integratorcp.o mainstone.o musicpal.o nseries.o
>>> -obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
>>> +obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o msf2_soc.o
>>>  obj-y += tosa.o versatilepb.o vexpress.o virt.o xilinx_zynq.o z2.o
>>>  obj-$(CONFIG_ACPI) += virt-acpi-build.o
>>>  obj-y += netduino2.o
>>> diff --git a/hw/arm/msf2_soc.c b/hw/arm/msf2_soc.c
>>> new file mode 100644
>>> index 000..a470872
>>> --- /dev/null
>>> +++ b/hw/arm/msf2_soc.c
>>> @@ -0,0 +1,194 @@
>>> +/*
>>> + * SmartFusion2 SoC emulation.
>>> + *
>>> + * Copyright (c) 2017 Subbaraya Sundeep 
>>> + *
>>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>>> copy
>>> + * of this software and associated documentation files (the "Software"), 
>>> to deal
>>> + * in the Software without restriction, including without limitation the 
>>> rights
>>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
>>> sell
>>> + * copies of the Software, and to permit persons to whom the Software is
>>> + * furnished to do so, subject to the following conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be included 
>>> in
>>> + * all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>>> OR
>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>>> OTHER
>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
>>> FROM,
>>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
>>> IN
>>> + * THE SOFTWARE.
>>> + */
>>> +
>>> +#include "qemu/osdep.h"
>>> +#include "qapi/error.h"
>>> +#include "qemu-common.h"
>>> +#include "hw/arm/arm.h"
>>> +#include "exec/address-spaces.h"
>>> +#include "hw/char/serial.h"
>>> +#include "hw/boards.h"
>>> +#include "sysemu/block-backend.h"
>>> +#include "hw/arm/msf2_soc.h"
>>> +
>>> +#define MSF2_TIMER_BASE   0x40004000
>>> +#define MSF2_SYSREG_BASE  0x40038000
>>> +
>>> +#define MSF2_TIMER_IRQ0   14
>>> +#define MSF2_TIMER_IRQ1   15
>>> +
>>> +static const uint32_t spi_addr[MSF2_NUM_SPIS] = { 0x40001000 , 0x40011000 
>>> };
>>
>> Hey Sundeep,
>>
>> From your other patch it sounds like this should just be a single SPI
>> device with to busses, so this will have to be re-worked.
>>
> I may be entirely wrong please correct me. I assumed this SoC and Board file
> are analogous to dtsi and dts in linux. So SoC file will instantiate
> all the controllers
> like SPI0 and SPI1 present in SoC whereas board file will attach slaves 
> present
> on board (like EEPROM, SPI flashes etc.,).  Hence in board file I
> attached flash to
> SPI0. I was expecting one bus for each controller eg:
> SPI0:
> bus: spi0
>  device: flash (Chip select 0)
>  device: other device (Chip select 1)
> SPI1:
> bus: spi1
>  device: other device (Chip select 0) (if attached in board file)

That's pretty much each. The SoC should create everything that is on
the SoC. So the SoC should create the SPI controller (which will
create the SPI buses) but not connect anything to them.

Then it's up to the board/machine to connect the SPI devices to the SPI 

Re: [Qemu-devel] [PATCH v6 1/5] shutdown: Simplify shutdown_signal

[Alistair Francis]

On Fri, May 5, 2017 at 12:38 PM, Eric Blake  wrote:
> There is no signal 0 (kill(pid, 0) has special semantics to probe whether
> a process is alive), rather than actually sending a signal 0).  So we
> can use the simpler 0, instead of -1, for our sentinel of whether a
> shutdown request due to a signal has happened.
>
> Suggested-by: Markus Armbruster 
> Signed-off-by: Eric Blake 
> Reviewed-by: Markus Armbruster 

Reviewed-by: Alistair Francis 

Thanks,

Alistair

>
> ---
> v4-v6: no change
> v3: new patch
> ---
>  vl.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 42d4bce..f22a3ac 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1598,7 +1598,7 @@ void vm_state_notify(int running, RunState state)
>  }
>
>  static int reset_requested;
> -static int shutdown_requested, shutdown_signal = -1;
> +static int shutdown_requested, shutdown_signal;
>  static pid_t shutdown_pid;
>  static int powerdown_requested;
>  static int debug_requested;
> @@ -1629,7 +1629,7 @@ static int qemu_shutdown_requested(void)
>
>  static void qemu_kill_report(void)
>  {
> -if (!qtest_driver() && shutdown_signal != -1) {
> +if (!qtest_driver() && shutdown_signal) {
>  if (shutdown_pid == 0) {
>  /* This happens for eg ^C at the terminal, so it's worth
>   * avoiding printing an odd message in that case.
> @@ -1643,7 +1643,7 @@ static void qemu_kill_report(void)
>   shutdown_cmd ? shutdown_cmd : "");
>  g_free(shutdown_cmd);
>  }
> -shutdown_signal = -1;
> +shutdown_signal = 0;
>  }
>  }
>
> --
> 2.9.3
>
>

Re: [Qemu-devel] [PATCH v4 1/1] slirp: add SOCKS5 support

[Samuel Thibault]

Hello,

Laurent Vivier, on sam. 06 mai 2017 00:48:33 +0200, wrote:
> @@ -617,6 +622,10 @@ void slirp_pollfds_poll(GArray *pollfds, int 
> select_error)
>   * Check sockets for reading
>   */
>  else if (revents & (G_IO_IN | G_IO_HUP | G_IO_ERR)) {
> +if (so->so_state & SS_ISFCONNECTING) {
> +socks5_recv(so->s, >so_proxy_state);
> +continue;
> +}

Again, I don't see how this can work with both socks5 case and
non-socks5 case.  Don't we need to somehow check for the type of socket
before calling socks5_recv?

> @@ -645,11 +654,19 @@ void slirp_pollfds_poll(GArray *pollfds, int 
> select_error)
>  /*
>   * Check for non-blocking, still-connecting sockets
>   */
> -if (so->so_state & SS_ISFCONNECTING) {
> -/* Connected */
> -so->so_state &= ~SS_ISFCONNECTING;
>  
> -ret = send(so->s, (const void *) , 0, 0);
> +if (so->so_state & SS_ISFCONNECTING) {
> +ret = socks5_send(so->s, slirp->proxy_user,

Ditto.

> diff --git a/slirp/socks5.c b/slirp/socks5.c
> new file mode 100644
> index 000..2bba045
> --- /dev/null
> +++ b/slirp/socks5.c
> @@ -0,0 +1,371 @@

In v2 of the patch, this was said to have "some parts from nmap/ncat
GPLv2".  Is that really not true any more?  If any part of the file is
not original, it *has* to wear proper copyright notices, otherwise it's
copyright infrigement.

Also, see the bot build error report:  doesn't exist on
windows,

#include 
#include 
#include 

should be used instead.

Samuel

Re: [Qemu-devel] [PATCH v4 0/1] slirp: add SOCKS5 support

[no-reply]

Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH v4 0/1] slirp: add SOCKS5 support
Message-id: 20170505224833.17769-1-laur...@vivier.eu

=== 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

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'
b98eabf slirp: add SOCKS5 support

=== OUTPUT BEGIN ===
Checking PATCH 1/1: slirp: add SOCKS5 support...
ERROR: suspect code indent for conditional statements (4, 6)
#786: FILE: slirp/tcp_subr.c:428:
+if (so->so_proxy_state) {
+  ret = socks5_connect(s, slirp->proxy_server, slirp->proxy_port,

total: 1 errors, 0 warnings, 732 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...@freelists.org

Re: [Qemu-devel] [PATCH v4 0/1] slirp: add SOCKS5 support

[no-reply]

Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH v4 0/1] slirp: add SOCKS5 support
Message-id: 20170505224833.17769-1-laur...@vivier.eu

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-mingw@fedora
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20170505224833.17769-1-laur...@vivier.eu -> 
patchew/20170505224833.17769-1-laur...@vivier.eu
Switched to a new branch 'test'
b98eabf slirp: add SOCKS5 support

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-pwp92vc7/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-pwp92vc7/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=ef86e561d89b
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs 

Re: [Qemu-devel] dns server not working in QEMU using usermode networking (SLIRP)

[Samuel Thibault]

FONNEMANN Mark, on ven. 05 mai 2017 22:38:20 +, wrote:
> >Could you run tcpdump inside the guest so we are sure what the nslookup call 
> >emits?
> 
> Is there another way to determine this info? My guest OS is an embedded 
> system with BusyBox 1.25 and not much else.

The attached patch should be dumping the same kind of information.

Samuel
diff --git a/slirp/ip_input.c b/slirp/ip_input.c
index 348e1dca5a..ada6f0d059 100644
--- a/slirp/ip_input.c
+++ b/slirp/ip_input.c
@@ -41,6 +41,7 @@
 #include "qemu/osdep.h"
 #include "slirp.h"
 #include "ip_icmp.h"
+#include "qemu/log.h"
 
 static struct ip *ip_reass(Slirp *slirp, struct ip *ip, struct ipq *fp);
 static void ip_freef(Slirp *slirp, struct ipq *fp);
@@ -93,6 +94,8 @@ ip_input(struct mbuf *m)
 
ip = mtod(m, struct ip *);
 
+qemu_log("ip input %x -> %x %x\n", ntohl(ip->ip_src.s_addr), 
ntohl(ip->ip_dst.s_addr), ip->ip_p);
+
if (ip->ip_v != IPVERSION) {
goto bad;
}
diff --git a/slirp/udp.c b/slirp/udp.c
index 227d779022..521c3a5a57 100644
--- a/slirp/udp.c
+++ b/slirp/udp.c
@@ -41,6 +41,7 @@
 #include "qemu/osdep.h"
 #include "slirp.h"
 #include "ip_icmp.h"
+#include "qemu/log.h"
 
 static uint8_t udp_tos(struct socket *so);
 
@@ -95,6 +96,7 @@ udp_input(register struct mbuf *m, int iphlen)
ip = mtod(m, struct ip *);
uh = (struct udphdr *)((caddr_t)ip + iphlen);
 
+qemu_log("udp input %u -> %u\n", (unsigned) ntohs(uh->uh_sport), 
(unsigned) ntohs(uh->uh_dport));
/*
 * Make mbuf data length reflect UDP length.
 * If not enough data to reflect UDP length, drop.

Re: [Qemu-devel] [PATCH v11 9/9] tests: Add coverage for recent block geometry fixes

[Eric Blake]

On 05/05/2017 05:34 PM, Max Reitz wrote:
> On 29.04.2017 21:14, Eric Blake wrote:
>> Use blkdebug's new geometry constraints to emulate setups that
>> have needed past regression fixes: write zeroes asserting
>> when running through a loopback block device with max-transfer
>> smaller than cluster size, and discard rounding away portions
>> of requests not aligned to preferred boundaries.  Also, add
>> coverage that the block layer is honoring max transfer limits.
>>

>> +function verify_io()
>> +{
>> +if ($QEMU_IMG info -f "$IMGFMT" "$TEST_IMG" |

>> +
>> +verify_io | $QEMU_IO "$TEST_IMG" | _filter_qemu_io
> 
> This conflicts with Fam's image locking series that has been introduced
> in the meantime (and unfortunately I'm the one who has to base his block
> queue on Kevin's...). I suppose it's because the qemu_io process is
> launched before the qemu_img info process.

Indeed. My test was heavily modeled after 046; there, our solution
(currently commit 64ace79 on Kevin's tree) was to add -U, not -r.

> 
> Simply adding an -r to the qemu_io command fixes this, however. I'll do
> so in my branch, assuming you're OK with that. :-)

I'd lean towards -U, but yes, I'm fine if you make whatever one-line
tweak is needed to obey the rules.

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v4 0/1] slirp: add SOCKS5 support

[Laurent Vivier]

This patch implements the SOCKS5 client part for "-net user" backend.

It allows to route all internet traffic of the virtual machine
to a SOCKS5 server.

But all the local traffic (to the host) is sent to the host.
It is needed because this SOCKS5 client doesn't route UDP traffic,
and this allows to use the host DNS server.

I've tested this using public SOCKS5 proxy list found on the WEB, and
using TOR server on my host.

Used with TOR, all the TCP connections are sent to the TOR network and
this allows to insert a virtual machine directly in the TOR network
without needing more configuration in the virtual machine.

But be aware that all DNS requests will be sent to the host that can
forward them to internet with its own IP address. So confidentiality
will not be as good as with the TOR browser which hides in the TOR
network all the DNS requests.

If you want to test this:

- with a public SOCKS5 server, ask google for "socks5 proxy address"
  and start QEMU with, for instance:

  qemu-system-x86_64 -net nic,model=e1000 -net 
user,proxy-server=46.105.121.37:63066 ...

  if needed, you can provide user/password using secret objects framework:
  "-object secret,id=sec0,data=password,format=raw \
   -net user,...,proxy-user=user,proxy-secretid=sec0"

- with a local TOR proxy:

  sudo systemctl start tor
  qemu-system-x86_64 -net nic,model=e1000 -net user,proxy-server=localhost:9050 
...

You can check your IP address is the one of the proxy by connecting
to http://check.torproject.org with a browser inside the VM.

v4:
  - rebase
  - define some macros to use instead of meaningless values
  - better management of error cases
  - add some error logs

v3:
  - rewrite SOCKS5 functions from scratch and drop code from nmap/ncat
  - don't drop the IPv6 UDP local traffic
  - don't pass to the proxy the IPv6 TCP local traffic
  - add some comments...

v2:
  - use secret objects framework to provide password
  - add documentation for new parameters in qapi-schema.json
  - s/passwd/password/g
  - I didn't move proxy paramaters to a substruct as I didn't
find a way to set them from the command line :(

Laurent Vivier (1):
  slirp: add SOCKS5 support

 net/slirp.c |  39 +-
 qapi-schema.json|   9 ++
 qemu-options.hx |  11 ++
 slirp/Makefile.objs |   2 +-
 slirp/ip_icmp.c |   2 +-
 slirp/libslirp.h|   3 +
 slirp/slirp.c   |  69 +-
 slirp/slirp.h   |   6 +
 slirp/socket.h  |   4 +
 slirp/socks5.c  | 371 
 slirp/socks5.h  |  25 
 slirp/tcp_subr.c|  22 +++-
 slirp/udp.c |   9 ++
 slirp/udp6.c|   8 ++
 14 files changed, 569 insertions(+), 11 deletions(-)
 create mode 100644 slirp/socks5.c
 create mode 100644 slirp/socks5.h

-- 
2.9.3

[Qemu-devel] [PATCH v4 1/1] slirp: add SOCKS5 support

[Laurent Vivier]

When the VM is used behind a firewall, This allows
the use of a SOCKS5 proxy server to connect the VM IP stack
directly to the Internet.

This implementation doesn't manage UDP packets, so they
are simply dropped (as with restrict=on), except for
the localhost as we need it for DNS.

Signed-off-by: Laurent Vivier 
---
 net/slirp.c |  39 +-
 qapi-schema.json|   9 ++
 qemu-options.hx |  11 ++
 slirp/Makefile.objs |   2 +-
 slirp/ip_icmp.c |   2 +-
 slirp/libslirp.h|   3 +
 slirp/slirp.c   |  69 +-
 slirp/slirp.h   |   6 +
 slirp/socket.h  |   4 +
 slirp/socks5.c  | 371 
 slirp/socks5.h  |  25 
 slirp/tcp_subr.c|  22 +++-
 slirp/udp.c |   9 ++
 slirp/udp6.c|   8 ++
 14 files changed, 569 insertions(+), 11 deletions(-)
 create mode 100644 slirp/socks5.c
 create mode 100644 slirp/socks5.h

diff --git a/net/slirp.c b/net/slirp.c
index c705a60..06a32f7 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -41,6 +41,7 @@
 #include "sysemu/sysemu.h"
 #include "qemu/cutils.h"
 #include "qapi/error.h"
+#include "crypto/secret.h"
 
 static int get_str_sep(char *buf, int buf_size, const char **pp, int sep)
 {
@@ -139,6 +140,33 @@ static void net_slirp_cleanup(NetClientState *nc)
 QTAILQ_REMOVE(_stacks, s, entry);
 }
 
+static int net_slirp_add_proxy(SlirpState *s, const char *proxy_server,
+   const char *proxy_user,
+   const char *proxy_secretid)
+{
+InetSocketAddress *addr;
+char *password = NULL;
+int ret;
+
+if (proxy_server == NULL) {
+return 0;
+}
+
+if (proxy_secretid) {
+password = qcrypto_secret_lookup_as_utf8(proxy_secretid, _fatal);
+}
+
+addr = inet_parse(proxy_server, _fatal);
+
+ret = slirp_add_proxy(s->slirp, addr->host, atoi(addr->port),
+  proxy_user, password);
+
+qapi_free_InetSocketAddress(addr);
+g_free(password);
+
+return ret;
+}
+
 static NetClientInfo net_slirp_info = {
 .type = NET_CLIENT_DRIVER_USER,
 .size = sizeof(SlirpState),
@@ -155,7 +183,8 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
   const char *bootfile, const char *vdhcp_start,
   const char *vnameserver, const char *vnameserver6,
   const char *smb_export, const char *vsmbserver,
-  const char **dnssearch)
+  const char **dnssearch, const char *proxy_server,
+  const char *proxy_user, const char *proxy_secretid)
 {
 /* default settings according to historic slirp */
 struct in_addr net  = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
@@ -361,6 +390,11 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
 }
 #endif
 
+if (net_slirp_add_proxy(s, proxy_server,
+proxy_user, proxy_secretid) < 0) {
+goto error;
+}
+
 s->exit_notifier.notify = slirp_smb_exit;
 qemu_add_exit_notifier(>exit_notifier);
 return 0;
@@ -882,7 +916,8 @@ int net_init_slirp(const Netdev *netdev, const char *name,
  user->ipv6_host, user->hostname, user->tftp,
  user->bootfile, user->dhcpstart,
  user->dns, user->ipv6_dns, user->smb,
- user->smbserver, dnssearch);
+ user->smbserver, dnssearch, user->proxy_server,
+ user->proxy_user, user->proxy_secretid);
 
 while (slirp_configs) {
 config = slirp_configs;
diff --git a/qapi-schema.json b/qapi-schema.json
index 01b087f..bcaf85b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3661,6 +3661,12 @@
 #
 # @guestfwd: forward guest TCP connections
 #
+# @proxy-server: address of the SOCKS5 proxy server to use (since 2.10)
+#
+# @proxy-user: username to use with the proxy server (since 2.10)
+#
+# @proxy-secretid: secret id to use for the proxy server password (since 2.10)
+#
 # Since: 1.2
 ##
 { 'struct': 'NetdevUserOptions',
@@ -3683,6 +3689,9 @@
 '*ipv6-dns': 'str',
 '*smb':   'str',
 '*smbserver': 'str',
+'*proxy-server': 'str',
+'*proxy-user':   'str',
+'*proxy-secretid': 'str',
 '*hostfwd':   ['String'],
 '*guestfwd':  ['String'] } }
 
diff --git a/qemu-options.hx b/qemu-options.hx
index f68829f..0a26a62 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1682,6 +1682,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
 #ifndef _WIN32
  "[,smb=dir[,smbserver=addr]]\n"
 #endif
+" [,proxy-server=addr:port[,proxy-user=user,proxy-secretid=id]]\n"
 "configure a user mode network backend with ID 'str',\n"
 "its DHCP server and optional services\n"
 #endif
@@ -1920,6 +1921,16 @@ 

Re: [Qemu-devel] [PATCH v12 00/10] qcow2 zero-cluster tweaks [was add blkdebug tests]

[Eric Blake]

On 05/05/2017 05:18 PM, Max Reitz wrote:
> On 04.05.2017 05:07, Eric Blake wrote:
>> I've collected several improvements for qcow2 zero-cluster handling.
>>
>> Available as a tag at:
>> git fetch git://repo.or.cz/qemu/ericb.git nbd-blkdebug-v12
>>
>> Marked as v12 for "hysterical raisins", since it it the half of
>> v10 [1] that was not resubmitted as v11 [2].
>>
>> Depends on Max's block tree:
>> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00641.html
>> and on Max's qcow2 cleanups:
>> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00689.html
>>
>> [1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05227.html
>> [2] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05896.html
>>

> I have given an R-b for every patch, so I could apply the series as-is
> (with the really minor fixes we have talked about, and the thing in
> patch 8), and I would be more or less OK with that. But I did have my
> fair share of nit picks and before I discard all of them, I'd like to
> know for sure that you don't intend to address them, or address them in
> a follow-up.
> 
> I'm saying this because some of the issues I had do not really lend
> themselves nicely to a follow-up; for instance the
> s/Data cluster/Cluster allocation/ for patch 4.
> 
> From my perspective, it's not much more difficult to review a respin of
> this series which just these minor points changed and maybe some very
> small patches (the follow-up, basically) added to it.

v13 coming soon to a list near you (but maybe not until Monday) - let's
see if it's the lucky one!

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 08/10] qcow2: Optimize write zero of unaligned tail cluster

[Eric Blake]

On 05/05/2017 05:06 PM, Max Reitz wrote:
> On 04.05.2017 05:07, Eric Blake wrote:
>> We've already improved discards to operate efficiently on the tail
>> of an unaligned qcow2 image; it's time to make a similar improvement
>> to write zeroes.  The special case is only valid at the tail
>> cluster of a file, where we must recognize that any sectors beyond
>> the image end would implicitly read as zero, and therefore should
>> not penalize our logic for widening a partial cluster into writing
>> the whole cluster as zero.
>>

>>  $QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
>>
>> +echo
>> +echo == unaligned image tail cluster, no allocation needed ==
> 
> [...]
> 
>> +# A preallocated cluster maintains its allocation, whether it stays as
>> +# data due to a partial write:
>> +# Convert 128m... | XX XX => ... | XX 00
>> +_make_test_img $((size + 1024))
>> +$QEMU_IO -c "write -P 1 $((size)) 1024" "$TEST_IMG" | _filter_qemu_io
>> +$QEMU_IO -c "write -z $((size + 512)) 512" "$TEST_IMG.base" | 
>> _filter_qemu_io
> 
> s/\.base//, I suppose?

D'oh. Serves me right for renaming which file I was working on.

> 
> (You should read your reference output. "Pattern verification failed" is
> never good. ;-))

Looks like I get to spin a v13 then.

> 
> With that (and the reference output) fixed:
> 
> Reviewed-by: Max Reitz 
> 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] dns server not working in QEMU using usermode networking (SLIRP)

[FONNEMANN Mark]

>Could you run tcpdump inside the guest so we are sure what the nslookup call 
>emits?

Is there another way to determine this info? My guest OS is an embedded system 
with BusyBox 1.25 and not much else.

Mark.

Re: [Qemu-devel] [PATCH v11 9/9] tests: Add coverage for recent block geometry fixes

[Max Reitz]

On 29.04.2017 21:14, Eric Blake wrote:
> Use blkdebug's new geometry constraints to emulate setups that
> have needed past regression fixes: write zeroes asserting
> when running through a loopback block device with max-transfer
> smaller than cluster size, and discard rounding away portions
> of requests not aligned to preferred boundaries.  Also, add
> coverage that the block layer is honoring max transfer limits.
> 
> For now, a single iotest performs all actions, with the idea
> that we can add future blkdebug constraint test cases in the
> same file; but it can be split into multiple iotests if we find
> reason to run one portion of the test in more setups than what
> are possible in the other.
> 
> For reference, the final portion of the test (checking whether
> discard passes as much as possible to the lowest layers of the
> stack) works as follows:
> 
> qemu-io: discard 30M at 8001, passed to blkdebug
>   blkdebug: discard 511 bytes at 8001, -ENOTSUP (smaller than
> blkdebug's 512 align)
>   blkdebug: discard 14371328 bytes at 8512, passed to qcow2
> qcow2: discard 739840 bytes at 8512, -ENOTSUP (smaller than
> qcow2's 1M align)
> qcow2: discard 13M bytes at 77M, succeeds
>   blkdebug: discard 15M bytes at 90M, passed to qcow2
> qcow2: discard 15M bytes at 90M, succeeds
>   blkdebug: discard 1356800 bytes at 105M, passed to qcow2
> qcow2: discard 1M at 105M, succeeds
> qcow2: discard 308224 bytes at 106M, -ENOTSUP (smaller than qcow2's
> 1M align)
>   blkdebug: discard 1 byte at 111457280, -ENOTSUP (smaller than
> blkdebug's 512 align)
> 
> Signed-off-by: Eric Blake 
> Reviewed-by: Max Reitz 
> 
> ---
> v11: rebase to context
> v10: no change, rebase to context
> v9: no change
> v7-v8: not submitted (earlier half of series sent for 2.9)
> v6: rebase to master by renumbering s/175/177/
> v5: rebase to master by renumbering s/173/175/
> v4: clean up some comments, nicer backing file creation, more commit message
> v3: make comments tied more to test at hand, rather than the
> particular hardware that led to the earlier patches being tested
> v2: new patch
> ---
>  tests/qemu-iotests/177 | 114 
> +
>  tests/qemu-iotests/177.out |  49 +++
>  tests/qemu-iotests/group   |   1 +
>  3 files changed, 164 insertions(+)
>  create mode 100755 tests/qemu-iotests/177
>  create mode 100644 tests/qemu-iotests/177.out
> 
> diff --git a/tests/qemu-iotests/177 b/tests/qemu-iotests/177
> new file mode 100755
> index 000..e4ddec7
> --- /dev/null
> +++ b/tests/qemu-iotests/177

[...]

> +echo
> +echo "== verify image content =="
> +
> +function verify_io()
> +{
> +if ($QEMU_IMG info -f "$IMGFMT" "$TEST_IMG" |
> + grep "compat: 0.10" > /dev/null); then
> +# For v2 images, discarded clusters are read from the backing file
> +discarded=11
> +else
> +# Discarded clusters are zeroed for v3 or later
> +discarded=0
> +fi
> +
> +echo read -P 22 0 1000
> +echo read -P 33 1000 128k
> +echo read -P 22 132072 7871512
> +echo read -P 0 8003584 2093056
> +echo read -P 22 10096640 23457792
> +echo read -P 0 32M 32M
> +echo read -P 22 64M 13M
> +echo read -P $discarded 77M 29M
> +echo read -P 22 106M 22M
> +}
> +
> +verify_io | $QEMU_IO "$TEST_IMG" | _filter_qemu_io

This conflicts with Fam's image locking series that has been introduced
in the meantime (and unfortunately I'm the one who has to base his block
queue on Kevin's...). I suppose it's because the qemu_io process is
launched before the qemu_img info process.

Simply adding an -r to the qemu_io command fixes this, however. I'll do
so in my branch, assuming you're OK with that. :-)

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 07/10] iotests: Add test 179 to cover write zeroes with unmap

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> No tests were covering write zeroes with unmap.  Additionally,
> I needed to prove that my previous patches for correct status
> reporting and write zeroes optimizations actually had an impact.
> 
> The test works for cluster_size between 8k and 2M (for smaller
> sizes, it fails because our allocation patterns are not contiguous
> with small clusters - in part, the largest consecutive allocation
> we tend to get is often bounded by the size covered by one L2
> table).
> 
> Note that testing for zero clusters is tricky: 'qemu-io map'
> reports whether data comes from the current layer of the image
> (useful for sniffing out which regions of the file have
> QCOW_OFLAG_ZERO) - but doesn't show which clusters have mappings;
> while 'qemu-img map' sees "zero":true for both unallocated and
> zero clusters for any qcow2 with no backing layer (so less useful
> at detecting true zero clusters), but reliably shows mappings.
> So we have to rely on both queries side-by-side at each point of
> the test.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: probe the map in more places, to make test easier to follow
> v11: reserved for blkdebug half of v10
> v10: drop any changes to v2 files, rewrite test to work with updates
> earlier in the series, add a blkdebug probe
> v9: new patch
> ---
>  tests/qemu-iotests/179 | 132 +
>  tests/qemu-iotests/179.out | 160 
> +
>  tests/qemu-iotests/group   |   1 +
>  3 files changed, 293 insertions(+)
>  create mode 100755 tests/qemu-iotests/179
>  create mode 100644 tests/qemu-iotests/179.out

[...]

> +wrote 2097152/2097152 bytes at offset 20971520
> +2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +wrote 2097152/2097152 bytes at offset 20971520
> +2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +wrote 2097152/2097152 bytes at offset 29360128
> +2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +Failed to flush the L2 table cache: Input/output error
> +Failed to flush the refcount block cache: Input/output error
> +wrote 2097152/2097152 bytes at offset 0
> +2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)

Maybe we should drop this last test that blkdebug works. It fails (for
me) on tmpfs (because the write itself fails there), and with -c unsafe
(because it doesn't flush the refcount cache). I'd be fine with just
believing blkdebug that it does its job...

Max

> +*** done



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v10 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

[Michael S. Tsirkin]

On Thu, May 04, 2017 at 04:50:12PM +0800, Wei Wang wrote:
> Add a new feature, VIRTIO_BALLOON_F_PAGE_CHUNKS, which enables
> the transfer of the ballooned (i.e. inflated/deflated) pages in
> chunks to the host.
> 
> The implementation of the previous virtio-balloon is not very
> efficient, because the ballooned pages are transferred to the
> host one by one. Here is the breakdown of the time in percentage
> spent on each step of the balloon inflating process (inflating
> 7GB of an 8GB idle guest).
> 
> 1) allocating pages (6.5%)
> 2) sending PFNs to host (68.3%)
> 3) address translation (6.1%)
> 4) madvise (19%)
> 
> It takes about 4126ms for the inflating process to complete.
> The above profiling shows that the bottlenecks are stage 2)
> and stage 4).
> 
> This patch optimizes step 2) by transferring pages to the host in
> chunks. A chunk consists of guest physically continuous pages.
> When the pages are packed into a chunk, they are converted into
> balloon page size (4KB) pages. A chunk is offered to the host
> via a base PFN (i.e. the start PFN of those physically continuous
> pages) and the size (i.e. the total number of the 4KB balloon size
> pages). A chunk is formatted as below:
> 
> | Base (52 bit)| Rsvd (12 bit) |
> 
> 
> | Size (52 bit)| Rsvd (12 bit) |
> 
> 
> By doing so, step 4) can also be optimized by doing address
> translation and madvise() in chunks rather than page by page.
> 
> With this new feature, the above ballooning process takes ~590ms
> resulting in an improvement of ~85%.
> 
> TODO: optimize stage 1) by allocating/freeing a chunk of pages
> instead of a single page each time.
> 
> Signed-off-by: Wei Wang 
> Signed-off-by: Liang Li 
> Suggested-by: Michael S. Tsirkin 


This is much cleaner, thanks. It might be even better to
have wrappers that put array and its size in a struct
and manage that struct, but I won't require this for
submission.



> ---
>  drivers/virtio/virtio_balloon.c | 407 
> +---
>  include/uapi/linux/virtio_balloon.h |  14 ++
>  2 files changed, 396 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index ecb64e9..df16912 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -43,6 +43,20 @@
>  #define OOM_VBALLOON_DEFAULT_PAGES 256
>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
>  
> +/* The size of one page_bmap used to record inflated/deflated pages. */
> +#define VIRTIO_BALLOON_PAGE_BMAP_SIZE(8 * PAGE_SIZE)
> +/*
> + * Callulates how many pfns can a page_bmap record. A bit corresponds to a
> + * page of PAGE_SIZE.
> + */
> +#define VIRTIO_BALLOON_PFNS_PER_PAGE_BMAP \
> + (VIRTIO_BALLOON_PAGE_BMAP_SIZE * BITS_PER_BYTE)
> +
> +/* The number of page_bmap to allocate by default. */
> +#define VIRTIO_BALLOON_PAGE_BMAP_DEFAULT_NUM 1
> +/* The maximum number of page_bmap that can be allocated. */
> +#define VIRTIO_BALLOON_PAGE_BMAP_MAX_NUM 32
> +
>  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
>  module_param(oom_pages, int, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
> @@ -51,6 +65,11 @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
>  static struct vfsmount *balloon_mnt;
>  #endif
>  
> +/* Maximum number of page chunks */
> +#define VIRTIO_BALLOON_MAX_PAGE_CHUNKS ((8 * PAGE_SIZE - \
> + sizeof(struct virtio_balloon_page_chunk)) / \
> + sizeof(struct virtio_balloon_page_chunk_entry))
> +
>  struct virtio_balloon {
>   struct virtio_device *vdev;
>   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> @@ -79,6 +98,12 @@ struct virtio_balloon {
>   /* Synchronize access/update to this struct virtio_balloon elements */
>   struct mutex balloon_lock;
>  
> + /* Buffer for chunks of ballooned pages. */
> + struct virtio_balloon_page_chunk *balloon_page_chunk;
> +
> + /* Bitmap used to record pages. */
> + unsigned long *page_bmap[VIRTIO_BALLOON_PAGE_BMAP_MAX_NUM];
> +
>   /* The array of pfns we tell the Host about. */
>   unsigned int num_pfns;
>   __virtio32 pfns[VIRTIO_BALLOON_ARRAY_PFNS_MAX];
> @@ -111,6 +136,136 @@ static void balloon_ack(struct virtqueue *vq)
>   wake_up(>acked);
>  }
>  
> +/* Update pfn_max and pfn_min according to the pfn of page */
> +static inline void update_pfn_range(struct virtio_balloon *vb,
> + struct page *page,
> + unsigned long *pfn_min,
> + unsigned long *pfn_max)
> +{
> + unsigned long pfn = page_to_pfn(page);
> +

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v9 2/5] virtio-balloon: VIRTIO_BALLOON_F_BALLOON_CHUNKS

[Michael S. Tsirkin]

On Thu, Apr 27, 2017 at 02:31:49PM +0800, Wei Wang wrote:
> On 04/27/2017 07:20 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 26, 2017 at 11:03:34AM +, Wang, Wei W wrote:
> > > Hi Michael, could you please give some feedback?
> > I'm sorry, I'm not sure feedback on what you are requesting.
> Oh, just some trivial things (e.g. use a field in the
> header, hdr->chunks to indicate the number of chunks
> in the payload) that wasn't confirmed.
> 
> I will prepare the new version with fixing the agreed issues,
> and we can continue to discuss those parts if you still find
> them improper.
> 
> 
> > 
> > The interface looks reasonable now, even though there's
> > a way to make it even simpler if we can limit chunk size
> > to 2G (in fact 4G - 1). Do you think we can live with this
> > limitation?
> Yes, I think we can. So, is it good to change to use the
> previous 64-bit chunk format (52-bit base + 12-bit size)?

This isn't what I meant. virtio ring has descriptors with
a 64 bit address and 32 bit size.

If size < 4g is not a significant limitation, why not just
use that to pass address/size in a standard s/g list,
possibly using INDIRECT?

> 
> > 
> > But the code still needs some cleanup.
> > 
> 
> OK. We'll also still to discuss your comments in the patch 05.
> 
> Best,
> Wei

Re: [Qemu-devel] [PATCH v9 5/5] virtio-balloon: VIRTIO_BALLOON_F_MISC_VQ

[Michael S. Tsirkin]

On Thu, Apr 27, 2017 at 02:33:44PM +0800, Wei Wang wrote:
> On 04/14/2017 01:08 AM, Michael S. Tsirkin wrote:
> > On Thu, Apr 13, 2017 at 05:35:08PM +0800, Wei Wang wrote:
> > > Add a new vq, miscq, to handle miscellaneous requests between the device
> > > and the driver.
> > > 
> > > This patch implemnts the VIRTIO_BALLOON_MISCQ_INQUIRE_UNUSED_PAGES
> > implements
> > 
> > > request sent from the device.
> > Commands are sent from host and handled on guest.
> > In fact how is this so different from stats?
> > How about reusing the stats vq then? You can use one buffer
> > for stats and one buffer for commands.
> > 
> 
> The meaning of the two vqs is a little different. statq is used for
> reporting statistics, while miscq is intended to be used to handle
> miscellaneous requests from the guest or host

misc just means "anything goes". If you want it to mean
"commands" name it so.

> (I think it can
> also be used the other way around in the future when other
> new features are added which need the guest to send requests
> and the host to provide responses).
> 
> I would prefer to have them separate, because:
> If we plan to combine them, we need to put the previous statq
> related implementation under miscq with a new command (I think
> we can't combine them without using commands to distinguish
> the two features).

Right.

> In this way, an old driver won't work with a new QEMU or a new
> driver won't work with an old QEMU. Would this be considered
> as an issue here?

Compatibility is and should always be handled using
feature flags.  There's a feature flag for this, isn't it?

> 
> 
> > 
> > > + miscq_out_hdr->flags = 0;
> > > +
> > > + for_each_populated_zone(zone) {
> > > + for (order = MAX_ORDER - 1; order > 0; order--) {
> > > + for (migratetype = 0; migratetype < MIGRATE_TYPES;
> > > +  migratetype++) {
> > > + do {
> > > + ret = inquire_unused_page_block(zone,
> > > + order, migratetype, );
> > > + if (!ret) {
> > > + pfn = (u64)page_to_pfn(page);
> > > + add_one_chunk(vb, vq,
> > > + PAGE_CHUNK_TYPE_UNUSED,
> > > + pfn,
> > > + (u64)(1 << order));
> > > + }
> > > + } while (!ret);
> > > + }
> > > + }
> > > + }
> > > + miscq_out_hdr->flags |= VIRTIO_BALLOON_MISCQ_F_COMPLETE;
> > And where is miscq_out_hdr used? I see no add_outbuf anywhere.
> > 
> > Things like this should be passed through function parameters
> > and not stuffed into device structure, fields should be
> > initialized before use and not where we happen to
> > have the data handy.
> > 
> 
> miscq_out_hdr is linear with the payload (i.e. kmalloc(hdr+payload) ).
> It is the same as the use of statq - one request in-flight each time.
> 
> 
> > 
> > Also, _F_ is normally a bit number, you use it as a value here.
> > 
> It intends to be a bit number. Bit 0 of flags to indicate the completion
> of handling the request.

Re: [Qemu-devel] [PATCH v12 00/10] qcow2 zero-cluster tweaks [was add blkdebug tests]

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> I've collected several improvements for qcow2 zero-cluster handling.
> 
> Available as a tag at:
> git fetch git://repo.or.cz/qemu/ericb.git nbd-blkdebug-v12
> 
> Marked as v12 for "hysterical raisins", since it it the half of
> v10 [1] that was not resubmitted as v11 [2].
> 
> Depends on Max's block tree:
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00641.html
> and on Max's qcow2 cleanups:
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00689.html
> 
> [1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05227.html
> [2] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05896.html
> 
> Changes since last posting:
> - lots of tweaks to resolve Max's review findings, including
> rewriting my additions to test 154
> - a new patch splitting QCOW2_CLUSTER_ZERO that fell out from
> my review of Max's work
> - defer any optimizations of a backing file with different length
> until later (I will still post an RFC patch to explore what
> optimizations a BDRV_BLOCK_EOF would allow, but didn't want to
> hold up this series any further)

I have given an R-b for every patch, so I could apply the series as-is
(with the really minor fixes we have talked about, and the thing in
patch 8), and I would be more or less OK with that. But I did have my
fair share of nit picks and before I discard all of them, I'd like to
know for sure that you don't intend to address them, or address them in
a follow-up.

I'm saying this because some of the issues I had do not really lend
themselves nicely to a follow-up; for instance the
s/Data cluster/Cluster allocation/ for patch 4.

From my perspective, it's not much more difficult to review a respin of
this series which just these minor points changed and maybe some very
small patches (the follow-up, basically) added to it.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v10 4/6] mm: function to offer a page block on the free list

[Michael S. Tsirkin]

On Fri, May 05, 2017 at 08:21:34AM +0800, kbuild test robot wrote:
> Hi Wei,
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.11 next-20170504]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Wei-Wang/Extend-virtio-balloon-for-fast-de-inflating-fast-live-migration/20170505-052958
> reproduce: make htmldocs
> 
> All warnings (new ones prefixed by >>):
> 
>WARNING: convert(1) not found, for SVG to PDF conversion install 
> ImageMagick (https://www.imagemagick.org)
>arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
> >> mm/page_alloc.c:4663: warning: No description found for parameter 'zone'
> >> mm/page_alloc.c:4663: warning: No description found for parameter 'order'
> >> mm/page_alloc.c:4663: warning: No description found for parameter 
> >> 'migratetype'
> >> mm/page_alloc.c:4663: warning: No description found for parameter 'page'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No description found for parameter 
> 'report_results'
>include/net/cfg80211.h:1738: warning: Excess struct/union/enum/typedef 
> member 'results_wk' description in 'cfg80211_sched_scan_request'
>include/net/cfg80211.h:1738: warning: No descriptio

Re: [Qemu-devel] [virtio-dev] Re: virtio-net: configurable TX queue size

[Michael S. Tsirkin]

On Fri, May 05, 2017 at 05:20:07PM +0800, Jason Wang wrote:
> 
> 
> On 2017年05月05日 13:53, Wei Wang wrote:
> > On 05/05/2017 10:27 AM, Jason Wang wrote:
> > > 
> > > 
> > > On 2017年05月04日 18:58, Wang, Wei W wrote:
> > > > Hi,
> > > > 
> > > > I want to re-open the discussion left long time ago:
> > > > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06194.html
> > > > , and discuss the possibility of changing the hardcoded (256) TX  queue
> > > > size to be configurable between 256 and 1024.
> > > 
> > > Yes, I think we probably need this.
> > 
> > That's great, thanks.
> > 
> > > 
> > > > 
> > > > The reason to propose this request is that a severe issue of
> > > > packet drops in
> > > > TX direction was observed with the existing hardcoded 256 queue size,
> > > > which causes performance issues for packet drop sensitive guest
> > > > applications that cannot use indirect descriptor tables. The
> > > > issue goes away
> > > > with 1K queue size.
> > > 
> > > Do we need even more, what if we find 1K is even not sufficient in
> > > the future? Modern nics has size up to ~8192.
> > 
> > Yes. Probably, we can also set the RX queue size to 8192 (currently it's
> > 1K) as well.
> > 
> > > 
> > > > 
> > > > The concern mentioned in the previous discussion (please check the link
> > > > above) is that the number of chained descriptors would exceed
> > > > UIO_MAXIOV (1024) supported by the Linux.
> > > 
> > > We could try to address this limitation but probably need a new
> > > feature bit to allow more than UIO_MAXIOV sgs.
> > 
> > I think we should first discuss whether it would be an issue below.
> > 
> > > 
> > > > 
> > > >  From the code,  I think the number of the chained descriptors
> > > > is limited to
> > > > MAX_SKB_FRAGS + 2 (~18), which is much less than UIO_MAXIOV.
> > > 
> > > This is the limitation of #page frags for skb, not the iov limitation.
> > 
> > I think the number of page frags are filled into the same number of
> > descriptors
> > in the virtio-net driver (e.g. use 10 descriptors for 10 page frags). On
> > the other
> > side, the virtio-net backend uses the same number of iov for the
> > descriptors.
> > 
> > Since the number of page frags is limited to 18, I think there wouldn't
> > be more
> > than 18 iovs to be passed to writev, right?
> 
> Looks not, see skb_copy_datagram_from_iter().
> 
> Thanks

Besides, guests don't all use linux drivers. Some use e.g.
dpdk pmd ones. It's best not to make assumptions outside
the spec - if you need to make an assumption, it's
best to add a flag to specify it.

> > 
> > Best,
> > Wei
> > 
> > -
> > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
> > 

Re: [Qemu-devel] [PATCH v12 08/10] qcow2: Optimize write zero of unaligned tail cluster

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> We've already improved discards to operate efficiently on the tail
> of an unaligned qcow2 image; it's time to make a similar improvement
> to write zeroes.  The special case is only valid at the tail
> cluster of a file, where we must recognize that any sectors beyond
> the image end would implicitly read as zero, and therefore should
> not penalize our logic for widening a partial cluster into writing
> the whole cluster as zero.
> 
> However, note that for now, the special case of end-of-file is only
> recognized if there is no backing file, or if the backing file has
> the same length; that's because when the backing file is shorter
> than the active layer, we don't have code in place to recognize
> that reads of a sector unallocated at the top and beyond the backing
> end-of-file are implicitly zero.  It's not much of a real loss,
> because most people don't use images that aren't cluster-aligned,
> or where the active layer is a different size than the backing
> layer (especially where the difference falls within a single cluster).
> 
> Update test 154 to cover the new scenarios, using two images of
> intentionally differing length.
> 
> While at it, fix the test to gracefully skip when run as
> ./check -qcow2 -o compat=0.10 154
> since the older format lacks zero clusters already required earlier
> in the test.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: fix testsuite problems, document shortcoming of differing
> v11: reserved for blkdebug half of v10
> size of backing file
> 
> v10: rebase to better reporting of preallocated zero clusters
> v9: new patch
> ---
>  block/qcow2.c  |   7 ++
>  tests/qemu-iotests/154 | 160 
> -
>  tests/qemu-iotests/154.out | 129 
>  3 files changed, 294 insertions(+), 2 deletions(-)

[...]

> diff --git a/tests/qemu-iotests/154 b/tests/qemu-iotests/154
> index 7ca7219..687b8f3 100755
> --- a/tests/qemu-iotests/154
> +++ b/tests/qemu-iotests/154

[...]

> @@ -299,6 +302,159 @@ $QEMU_IO -c "read -P 0 75k 1k" "$TEST_IMG" | 
> _filter_qemu_io
> 
>  $QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
> 
> +echo
> +echo == unaligned image tail cluster, no allocation needed ==

[...]

> +# A preallocated cluster maintains its allocation, whether it stays as
> +# data due to a partial write:
> +# Convert 128m... | XX XX => ... | XX 00
> +_make_test_img $((size + 1024))
> +$QEMU_IO -c "write -P 1 $((size)) 1024" "$TEST_IMG" | _filter_qemu_io
> +$QEMU_IO -c "write -z $((size + 512)) 512" "$TEST_IMG.base" | _filter_qemu_io

s/\.base//, I suppose?

(You should read your reference output. "Pattern verification failed" is
never good. ;-))

With that (and the reference output) fixed:

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 07/10] iotests: Add test 179 to cover write zeroes with unmap

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> No tests were covering write zeroes with unmap.  Additionally,
> I needed to prove that my previous patches for correct status
> reporting and write zeroes optimizations actually had an impact.
> 
> The test works for cluster_size between 8k and 2M (for smaller
> sizes, it fails because our allocation patterns are not contiguous
> with small clusters - in part, the largest consecutive allocation
> we tend to get is often bounded by the size covered by one L2
> table).
> 
> Note that testing for zero clusters is tricky: 'qemu-io map'
> reports whether data comes from the current layer of the image
> (useful for sniffing out which regions of the file have
> QCOW_OFLAG_ZERO) - but doesn't show which clusters have mappings;
> while 'qemu-img map' sees "zero":true for both unallocated and
> zero clusters for any qcow2 with no backing layer (so less useful
> at detecting true zero clusters), but reliably shows mappings.
> So we have to rely on both queries side-by-side at each point of
> the test.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: probe the map in more places, to make test easier to follow
> v11: reserved for blkdebug half of v10
> v10: drop any changes to v2 files, rewrite test to work with updates
> earlier in the series, add a blkdebug probe
> v9: new patch
> ---
>  tests/qemu-iotests/179 | 132 +
>  tests/qemu-iotests/179.out | 160 
> +
>  tests/qemu-iotests/group   |   1 +
>  3 files changed, 293 insertions(+)
>  create mode 100755 tests/qemu-iotests/179
>  create mode 100644 tests/qemu-iotests/179.out

Reviewed-by: Max Reitz 

TIL qemu-io -c w.



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 3/3] string-input-visitor: Support alternate types

[Eduardo Habkost]

On Fri, May 05, 2017 at 03:53:40PM -0500, Eric Blake wrote:
> On 05/05/2017 03:11 PM, Eduardo Habkost wrote:
> > When parsing alternates from a string, there are some limitations in
> > what we can do, but it is a valid use case in some situations. We can
> > support booleans, integer types, and enums.
> 
> Stale comment, given...
> 
> > 
> > This will be used to support 'feature=force' in -cpu options, while
> > keeping 'feature=on|off|true|false' represented as boolean values.
> > 
> > Signed-off-by: Eduardo Habkost 
> > ---
> > Changes v1 -> v2:
> > * Updated string_input_visitor_new() documentation
> >   to mention alternate support (Markus Armbruster)
> > * Detect ambiguous alternates at runtime. Test case included.
> > * Removed support for integers. We don't need it yet, and
> 
> ...this.

Oops.

> 
> >   it would require sorting out the parse_str() mess.
> > * Change supported_qtypes to uint32_t (Eric Blake)
> > * Update tests/qapi-schema/qapi-schema-test.out to match
> >   qapi-schema-test.json updates
> >   (Eric Blake)
> > * Code indentation fix (Markus Armbruster)
> > * Use _abort on test cases instead of g_assert(!err)
> >   (Markus Armbruster)
> > ---
> 
> >  
> > +/*
> > + * Check if alternate type string representation is ambiguous and
> > + * can't be parsed by StringInputVisitor
> > + */
> > +static bool ambiguous_alternate(uint32_t qtypes, const char *const 
> > enum_table[])
> > +{
> > +uint32_t non_str_qtypes = qtypes & ~(1U << QTYPE_QSTRING);
> > +
> > +if ((qtypes & (1U << QTYPE_QSTRING)) && !enum_table && non_str_qtypes) 
> > {
> > +return true;
> > +}
> > +
> > +if (qtypes & (1U << QTYPE_QBOOL)) {
> > +const char *const *e;
> > +/*
> > + * If the string representation of enum members can be parsed as
> > + * booleans, the alternate string representation is ambiguous.
> > + */
> > +for (e = enum_table; e && *e; e++) {
> > +if (try_parse_bool(*e, NULL) == 0) {
> > +return true;
> > +}
> > +}
> > +}
> > +
> > +return false;
> > +}
> 
> Seems okay for detecting ambiguity, but it is a runtime cost (one that
> you will run every single time you parse, even though the answer will be
> the same every single time you run it); I still think doing it at QAPI
> compile time will be more efficient in the long run.  And as this is the
> only use of enum_table added in 2/3, I'm still not sold on needing that
> patch.

I'm OK with deleting this part. That's the main reason I moved it
to a separate function.

> 
> > +
> > +static void start_alternate(Visitor *v, const char *name,
> > +GenericAlternate **obj, size_t size,
> > +uint32_t qtypes, const char *const 
> > enum_table[],
> > +Error **errp)
> > +{
> > +/*
> > + * Enum types are represented as QTYPE_QSTRING, so this is
> > + * the default. Actual parsing of the string as an enum is
> > + * done by visit_type_(), which is called just
> > + * after visit_start_alternate().
> > + */
> > +QType qtype = QTYPE_QSTRING;
> > +uint32_t unsupported_qtypes = qtypes & ~((1U << QTYPE_QSTRING) |
> > + (1U << QTYPE_QBOOL));
> > +StringInputVisitor *siv = to_siv(v);
> > +
> > +if (ambiguous_alternate(qtypes, enum_table)) {
> > +error_setg(errp, "Can't parse ambiguous alternate type");
> > +return;
> > +}
> > +
> > +if (unsupported_qtypes) {
> > +error_setg(errp, "Can't parse %s' alternate member",
> > +   QType_lookup[ctz32(unsupported_qtypes)]);
> > +return;
> > +}
> > +
> > +if ((qtypes & (1U << QTYPE_QBOOL)) &&
> > +try_parse_bool(siv->string, NULL) == 0) {
> > +qtype = QTYPE_QBOOL;
> > +}
> > +
> > +*obj = g_malloc0(size);
> > +(*obj)->type = qtype;
> 
> Slightly simpler for ignoring int for now, while still something we
> could add in later.  I've been wanting to have an alternate for
> 'int'/'str' for InetAddress port, since we want to support named ports
> but most often use just integers.  On the command line, port=1 is fine,
> but in QMP, we currently have to spell it port="1".  That's a case where
> we'd allow a pairing of any string with an integer, rather than just an
> enum.

Does that mean we already have an use case where we will have to
relax the restrictions on ambiguous enums? :)

I won't mind at all if we remove the runtime detection of
ambiguous enums. It will make the code much simpler.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v12 06/10] iotests: Improve _filter_qemu_img_map

[Max Reitz]

On 05.05.2017 23:06, Eric Blake wrote:
> On 05/05/2017 03:58 PM, Max Reitz wrote:
>> On 04.05.2017 05:07, Eric Blake wrote:
>>> Although _filter_qemu_img_map documents that it scrubs offsets, it
>>> was only doing so for human mode.  Of the existing tests using the
>>> filter (97, 122, 150, 154, 176), two of them are affected, but it
>>> does not hurt the validity of the tests to not require particular
>>> mappings (another test, 66, uses offsets but intentionally does not
>>> pass through _filter_qemu_img_map, because it checks that offsets
>>> are unchanged before and after an operation).
>>>
> 
>>>  _filter_qemu_img_map()
>>>  {
>>>  sed -e 's/\([0-9a-fx]* *[0-9a-fx]* *\)[0-9a-fx]* */\1/g' \
>>> +   -e 's/"offset": [0-9]\+/"offset": OFFSET/g' \>  -e 's/Mapped to 
>>> *//' | _filter_testdir | _filter_imgfmt
> 
> Whoa - mail corruption.
> 
>>
>> This makes my OCD very sad.
> 
> The real culprit? TAB damage.  I guess this is one of the files that
> emacs thinks should be indented with TAB instead of space, because the

>emacs

Found the issue right there.

O:-)

Max

> file itself looks aligned, only the patch is botched.
> 
>>
>> With the alignment fixed:
>>
>> Reviewed-by: Max Reitz 
>>
>> (Without this fixed: Will-change-when-applying-and-then-add-the-R-b)
> 
> Much appreciated, and I await the final verdict on whether I have to
> respin (you've pointed out several cleanups I can make), or whether you
> take the fixed version of these patches and let me write a few more
> followups.



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 06/10] iotests: Improve _filter_qemu_img_map

[Eric Blake]

On 05/05/2017 03:58 PM, Max Reitz wrote:
> On 04.05.2017 05:07, Eric Blake wrote:
>> Although _filter_qemu_img_map documents that it scrubs offsets, it
>> was only doing so for human mode.  Of the existing tests using the
>> filter (97, 122, 150, 154, 176), two of them are affected, but it
>> does not hurt the validity of the tests to not require particular
>> mappings (another test, 66, uses offsets but intentionally does not
>> pass through _filter_qemu_img_map, because it checks that offsets
>> are unchanged before and after an operation).
>>

>>  _filter_qemu_img_map()
>>  {
>>  sed -e 's/\([0-9a-fx]* *[0-9a-fx]* *\)[0-9a-fx]* */\1/g' \
>> +-e 's/"offset": [0-9]\+/"offset": OFFSET/g' \>  -e 's/Mapped to 
>> *//' | _filter_testdir | _filter_imgfmt

Whoa - mail corruption.

> 
> This makes my OCD very sad.

The real culprit? TAB damage.  I guess this is one of the files that
emacs thinks should be indented with TAB instead of space, because the
file itself looks aligned, only the patch is botched.

> 
> With the alignment fixed:
> 
> Reviewed-by: Max Reitz 
> 
> (Without this fixed: Will-change-when-applying-and-then-add-the-R-b)

Much appreciated, and I await the final verdict on whether I have to
respin (you've pointed out several cleanups I can make), or whether you
take the fixed version of these patches and let me write a few more
followups.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 06/10] iotests: Improve _filter_qemu_img_map

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> Although _filter_qemu_img_map documents that it scrubs offsets, it
> was only doing so for human mode.  Of the existing tests using the
> filter (97, 122, 150, 154, 176), two of them are affected, but it
> does not hurt the validity of the tests to not require particular
> mappings (another test, 66, uses offsets but intentionally does not
> pass through _filter_qemu_img_map, because it checks that offsets
> are unchanged before and after an operation).
> 
> Another justification for this patch is that it will allow a future
> patch to utilize 'qemu-img map --output=json' to check the status of
> preallocated zero clusters without regards to the mapping (since
> the qcow2 mapping can be very sensitive to the chosen cluster size,
> when preallocation is not in use).
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: new patch
> ---
>  tests/qemu-iotests/common.filter |  4 +++-
>  tests/qemu-iotests/122.out   | 16 
>  tests/qemu-iotests/154.out   | 30 +++---
>  3 files changed, 26 insertions(+), 24 deletions(-)
> 
> diff --git a/tests/qemu-iotests/common.filter 
> b/tests/qemu-iotests/common.filter
> index f58548d..2c14f15 100644
> --- a/tests/qemu-iotests/common.filter
> +++ b/tests/qemu-iotests/common.filter
> @@ -152,10 +152,12 @@ _filter_img_info()
>  -e "/log_size: [0-9]\\+/d"
>  }
> 
> -# filter out offsets and file names from qemu-img map
> +# filter out offsets and file names from qemu-img map; good for both
> +# human and json output
>  _filter_qemu_img_map()
>  {
>  sed -e 's/\([0-9a-fx]* *[0-9a-fx]* *\)[0-9a-fx]* */\1/g' \
> + -e 's/"offset": [0-9]\+/"offset": OFFSET/g' \>  -e 's/Mapped to 
> *//' | _filter_testdir | _filter_imgfmt

This makes my OCD very sad.

With the alignment fixed:

Reviewed-by: Max Reitz 

(Without this fixed: Will-change-when-applying-and-then-add-the-R-b)

>  }



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 05/10] qcow2: Optimize zero_single_l2() to minimize L2 churn

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> Similar to discard_single_l2(), we should try to avoid dirtying
> the L2 cache when the cluster we are changing already has the
> right characteristics.
> 
> Note that by the time we get to zero_single_l2(), BDRV_REQ_MAY_UNMAP
> is a requirement to unallocate a cluster (this is because the block
> layer clears that flag if discard.* flags during open requested that
> we never punch holes - see the conversation around commit 170f4b2e,
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07306.html).
> Therefore, this patch can only reuse a zero cluster as-is if either
> unmapping is not requested, or if the zero cluster was not associated
> with an allocation.
> 
> Technically, there are some cases where an unallocated cluster
> already reads as all zeroes (namely, when there is no backing file
> [easy: check bs->backing], or when the backing file also reads as
> zeroes [harder: we can't check bdrv_get_block_status since we are
> already holding the lock]), where the guest would not immediately see
> a difference if we left that cluster unallocated.  But if the user
> did not request unmapping, leaving an unallocated cluster is wrong;
> and even if the user DID request unmapping, keeping a cluster
> unallocated risks a subtle semantic change of guest-visible contents
> if a backing file is later added, and it is not worth auditing
> whether all internal uses such as mirror properly avoid an unmap
> request.  Thus, this patch is intentionally limited to just clusters
> that are already marked as zero.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: store cluster type in temporary
> v11: reserved for blkdebug half of v10
> v10: new patch, replacing earlier attempt to use unallocated clusters,
> and ditching any optimization of v2 files
> ---
>  block/qcow2-cluster.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)

Reviewed-by: Max Reitz 

> 
> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index 14e2086..78fbe34 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c
> @@ -1599,6 +1599,7 @@ static int zero_single_l2(BlockDriverState *bs, 
> uint64_t offset,
>  int l2_index;
>  int ret;
>  int i;
> +bool unmap = !!(flags & BDRV_REQ_MAY_UNMAP);
> 
>  ret = get_cluster_table(bs, offset, _table, _index);
>  if (ret < 0) {
> @@ -1611,12 +1612,22 @@ static int zero_single_l2(BlockDriverState *bs, 
> uint64_t offset,
> 
>  for (i = 0; i < nb_clusters; i++) {
>  uint64_t old_offset;
> +int cluster_type;

Hm, why doesn't this enum have a name yet... Well, if only *someone*
could address that. */me ducks*

Max

> 
>  old_offset = be64_to_cpu(l2_table[l2_index + i]);
> 
> -/* Update L2 entries */
> +/*
> + * Minimize L2 changes if the cluster already reads back as
> + * zeroes with correct allocation.
> + */
> +cluster_type = qcow2_get_cluster_type(old_offset);
> +if (cluster_type == QCOW2_CLUSTER_ZERO_PLAIN ||
> +(cluster_type == QCOW2_CLUSTER_ZERO_ALLOC && !unmap)) {
> +continue;
> +}
> +
>  qcow2_cache_entry_mark_dirty(bs, s->l2_table_cache, l2_table);
> -if (old_offset & QCOW_OFLAG_COMPRESSED || flags & 
> BDRV_REQ_MAY_UNMAP) {
> +if (cluster_type == QCOW2_CLUSTER_COMPRESSED || unmap) {
>  l2_table[l2_index + i] = cpu_to_be64(QCOW_OFLAG_ZERO);
>  qcow2_free_any_clusters(bs, old_offset, 1, 
> QCOW2_DISCARD_REQUEST);
>  } else {
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 04/10] qcow2: Make distinction between zero cluster types obvious

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> Treat plain zero clusters differently from allocated ones, so that
> we can simplify the logic of checking whether an offset is present.
> Do this by splitting QCOW2_CLUSTER_ZERO into two new enums,
> QCOW2_CLUSTER_ZERO_PLAIN and QCOW2_CLUSTER_ZERO_ALLOC.
> 
> I tried to arrange the enum so that we could use
> 'ret <= QCOW2_CLUSTER_ZERO_PLAIN' for all unallocated types, and
> 'ret >= QCOW2_CLUSTER_ZERO_ALLOC' for allocated types, although
> I didn't actually end up taking advantage of the layout.
> 
> In many cases, this leads to simpler code, by properly combining
> cases (sometimes, both zero types pair together, other times,
> plain zero is more like unallocated while allocated zero is more
> like normal).
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: new patch
> ---
>  block/qcow2.h  |  8 +--
>  block/qcow2-cluster.c  | 65 
> ++
>  block/qcow2-refcount.c | 40 +--
>  block/qcow2.c  |  9 ---
>  4 files changed, 51 insertions(+), 71 deletions(-)

I have to admit I was rather skeptic of this idea at first (because I
thought we would have more places which treat both ZERO types the same
than those that separate it), but you have comprehensively proven me wrong.

Some nit picks below, I'll leave it completely up to you whether you
want to address them:

Reviewed-by: Max Reitz 

[...]

> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index f3bfce6..14e2086 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c

[...]

> @@ -558,52 +557,32 @@ int qcow2_get_cluster_offset(BlockDriverState *bs, 
> uint64_t offset,
>  assert(nb_clusters <= INT_MAX);
> 
>  ret = qcow2_get_cluster_type(*cluster_offset);
> +if (s->qcow_version < 3 && (ret == QCOW2_CLUSTER_ZERO_PLAIN ||
> +ret == QCOW2_CLUSTER_ZERO_ALLOC)) {
> +qcow2_signal_corruption(bs, true, -1, -1, "Zero cluster entry found"
> +" in pre-v3 image (L2 offset: %#" PRIx64
> +", L2 index: %#x)", l2_offset, l2_index);
> +ret = -EIO;
> +goto fail;
> +}
>  switch (ret) {
>  case QCOW2_CLUSTER_COMPRESSED:
>  /* Compressed clusters can only be processed one by one */
>  c = 1;
>  *cluster_offset &= L2E_COMPRESSED_OFFSET_SIZE_MASK;
>  break;
> -case QCOW2_CLUSTER_ZERO:
> -if (s->qcow_version < 3) {
> -qcow2_signal_corruption(bs, true, -1, -1, "Zero cluster entry 
> found"
> -" in pre-v3 image (L2 offset: %#" PRIx64
> -", L2 index: %#x)", l2_offset, l2_index);
> -ret = -EIO;
> -goto fail;
> -}
> -/* Distinguish between pure zero clusters and pre-allocated ones */
> -if (*cluster_offset & L2E_OFFSET_MASK) {
> -c = count_contiguous_clusters(nb_clusters, s->cluster_size,
> -  _table[l2_index], 
> QCOW_OFLAG_ZERO);
> -*cluster_offset &= L2E_OFFSET_MASK;
> -if (offset_into_cluster(s, *cluster_offset)) {
> -qcow2_signal_corruption(bs, true, -1, -1,
> -"Preallocated zero cluster offset %#"
> -PRIx64 " unaligned (L2 offset: %#"
> -PRIx64 ", L2 index: %#x)",
> -*cluster_offset, l2_offset, 
> l2_index);
> -ret = -EIO;
> -goto fail;
> -}
> -} else {
> -c = count_contiguous_clusters_unallocated(nb_clusters,
> -  _table[l2_index],
> -  QCOW2_CLUSTER_ZERO);
> -*cluster_offset = 0;
> -}
> -break;
> +case QCOW2_CLUSTER_ZERO_PLAIN:
>  case QCOW2_CLUSTER_UNALLOCATED:
>  /* how many empty clusters ? */
>  c = count_contiguous_clusters_unallocated(nb_clusters,
> -  _table[l2_index],
> -  QCOW2_CLUSTER_UNALLOCATED);
> +  _table[l2_index], ret);

Nit pick: Using ret here is a bit weird (because it's such a meaningless
name). It would be good if we had a separate cluster_type variable.

>  *cluster_offset = 0;
>  break;
> +case QCOW2_CLUSTER_ZERO_ALLOC:
>  case QCOW2_CLUSTER_NORMAL:
>  /* how many allocated clusters ? */
>  c = count_contiguous_clusters(nb_clusters, s->cluster_size,
> -_table[l2_index], QCOW_OFLAG_ZERO);
> +  _table[l2_index], QCOW_OFLAG_ZERO);
>  

[Qemu-devel] [PATCH v9 6/6] migration: spapr: migrate pending_events of spapr state

[Daniel Henrique Barboza]

From: Jianjun Duan 

In racing situations between hotplug events and migration operation,
a rtas hotplug event could have not yet be delivered to the source
guest when migration is started. In this case the pending_events of
spapr state need be transmitted to the target so that the hotplug
event can be finished on the target.

All the different fields of the events are encoded as defined by
PAPR. We can migrate them as uint8_t binary stream without any
concerns about data padding or endianess.

pending_events is put in a subsection in the spapr state VMSD to make
sure migration across different versions is not broken.

Signed-off-by: Jianjun Duan 
Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr.c | 33 +
 hw/ppc/spapr_events.c  | 24 +---
 include/hw/ppc/spapr.h |  3 ++-
 3 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index bc56249..e924fd4 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1498,6 +1498,38 @@ static const VMStateDescription vmstate_spapr_ccs_list = 
{
 },
 };
 
+static bool spapr_pending_events_needed(void *opaque)
+{
+sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
+return !QTAILQ_EMPTY(>pending_events);
+}
+
+static const VMStateDescription vmstate_spapr_event_entry = {
+.name = "spapr_event_log_entry",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT32(log_type, sPAPREventLogEntry),
+VMSTATE_BOOL(exception, sPAPREventLogEntry),
+VMSTATE_UINT32(data_size, sPAPREventLogEntry),
+VMSTATE_VARRAY_UINT32_ALLOC(data, sPAPREventLogEntry, data_size,
+0, vmstate_info_uint8, uint8_t),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static const VMStateDescription vmstate_spapr_pending_events = {
+.name = "spapr_pending_events",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spapr_pending_events_needed,
+.fields = (VMStateField[]) {
+VMSTATE_QTAILQ_V(pending_events, sPAPRMachineState, 1,
+ vmstate_spapr_event_entry, sPAPREventLogEntry, next),
+VMSTATE_END_OF_LIST()
+},
+};
+
 static bool spapr_ov5_cas_needed(void *opaque)
 {
 sPAPRMachineState *spapr = opaque;
@@ -1598,6 +1630,7 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_patb_entry,
 _spapr_pending_dimm_unplugs,
 _spapr_ccs_list,
+_spapr_pending_events,
 NULL
 }
 };
diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
index f0b28d8..70c7cfc 100644
--- a/hw/ppc/spapr_events.c
+++ b/hw/ppc/spapr_events.c
@@ -342,7 +342,8 @@ static int rtas_event_log_to_irq(sPAPRMachineState *spapr, 
int log_type)
 return source->irq;
 }
 
-static void rtas_event_log_queue(int log_type, void *data, bool exception)
+static void rtas_event_log_queue(int log_type, void *data, bool exception,
+ int data_size)
 {
 sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
 sPAPREventLogEntry *entry = g_new(sPAPREventLogEntry, 1);
@@ -351,6 +352,7 @@ static void rtas_event_log_queue(int log_type, void *data, 
bool exception)
 entry->log_type = log_type;
 entry->exception = exception;
 entry->data = data;
+entry->data_size = data_size;
 QTAILQ_INSERT_TAIL(>pending_events, entry, next);
 }
 
@@ -445,6 +447,7 @@ static void spapr_powerdown_req(Notifier *n, void *opaque)
 struct rtas_event_log_v6_mainb *mainb;
 struct rtas_event_log_v6_epow *epow;
 struct epow_log_full *new_epow;
+uint32_t data_size;
 
 new_epow = g_malloc0(sizeof(*new_epow));
 hdr = _epow->hdr;
@@ -453,14 +456,13 @@ static void spapr_powerdown_req(Notifier *n, void *opaque)
 mainb = _epow->mainb;
 epow = _epow->epow;
 
+data_size = sizeof(*new_epow);
 hdr->summary = cpu_to_be32(RTAS_LOG_VERSION_6
| RTAS_LOG_SEVERITY_EVENT
| RTAS_LOG_DISPOSITION_NOT_RECOVERED
| RTAS_LOG_OPTIONAL_PART_PRESENT
| RTAS_LOG_TYPE_EPOW);
-hdr->extended_length = cpu_to_be32(sizeof(*new_epow)
-   - sizeof(new_epow->hdr));
-
+hdr->extended_length = cpu_to_be32(data_size - sizeof(new_epow->hdr));
 spapr_init_v6hdr(v6hdr);
 spapr_init_maina(maina, 3 /* Main-A, Main-B and EPOW */);
 
@@ -479,7 +481,7 @@ static void spapr_powerdown_req(Notifier *n, void *opaque)
 epow->event_modifier = RTAS_LOG_V6_EPOW_MODIFIER_NORMAL;
 epow->extended_modifier = RTAS_LOG_V6_EPOW_XMODIFIER_PARTITION_SPECIFIC;
 
-rtas_event_log_queue(RTAS_LOG_TYPE_EPOW, new_epow, true);
+rtas_event_log_queue(RTAS_LOG_TYPE_EPOW, new_epow, true, data_size);
 
 

Re: [Qemu-devel] [PATCH v2 3/3] string-input-visitor: Support alternate types

[Eric Blake]

On 05/05/2017 03:11 PM, Eduardo Habkost wrote:
> When parsing alternates from a string, there are some limitations in
> what we can do, but it is a valid use case in some situations. We can
> support booleans, integer types, and enums.

Stale comment, given...

> 
> This will be used to support 'feature=force' in -cpu options, while
> keeping 'feature=on|off|true|false' represented as boolean values.
> 
> Signed-off-by: Eduardo Habkost 
> ---
> Changes v1 -> v2:
> * Updated string_input_visitor_new() documentation
>   to mention alternate support (Markus Armbruster)
> * Detect ambiguous alternates at runtime. Test case included.
> * Removed support for integers. We don't need it yet, and

...this.

>   it would require sorting out the parse_str() mess.
> * Change supported_qtypes to uint32_t (Eric Blake)
> * Update tests/qapi-schema/qapi-schema-test.out to match
>   qapi-schema-test.json updates
>   (Eric Blake)
> * Code indentation fix (Markus Armbruster)
> * Use _abort on test cases instead of g_assert(!err)
>   (Markus Armbruster)
> ---

>  
> +/*
> + * Check if alternate type string representation is ambiguous and
> + * can't be parsed by StringInputVisitor
> + */
> +static bool ambiguous_alternate(uint32_t qtypes, const char *const 
> enum_table[])
> +{
> +uint32_t non_str_qtypes = qtypes & ~(1U << QTYPE_QSTRING);
> +
> +if ((qtypes & (1U << QTYPE_QSTRING)) && !enum_table && non_str_qtypes) {
> +return true;
> +}
> +
> +if (qtypes & (1U << QTYPE_QBOOL)) {
> +const char *const *e;
> +/*
> + * If the string representation of enum members can be parsed as
> + * booleans, the alternate string representation is ambiguous.
> + */
> +for (e = enum_table; e && *e; e++) {
> +if (try_parse_bool(*e, NULL) == 0) {
> +return true;
> +}
> +}
> +}
> +
> +return false;
> +}

Seems okay for detecting ambiguity, but it is a runtime cost (one that
you will run every single time you parse, even though the answer will be
the same every single time you run it); I still think doing it at QAPI
compile time will be more efficient in the long run.  And as this is the
only use of enum_table added in 2/3, I'm still not sold on needing that
patch.

> +
> +static void start_alternate(Visitor *v, const char *name,
> +GenericAlternate **obj, size_t size,
> +uint32_t qtypes, const char *const enum_table[],
> +Error **errp)
> +{
> +/*
> + * Enum types are represented as QTYPE_QSTRING, so this is
> + * the default. Actual parsing of the string as an enum is
> + * done by visit_type_(), which is called just
> + * after visit_start_alternate().
> + */
> +QType qtype = QTYPE_QSTRING;
> +uint32_t unsupported_qtypes = qtypes & ~((1U << QTYPE_QSTRING) |
> + (1U << QTYPE_QBOOL));
> +StringInputVisitor *siv = to_siv(v);
> +
> +if (ambiguous_alternate(qtypes, enum_table)) {
> +error_setg(errp, "Can't parse ambiguous alternate type");
> +return;
> +}
> +
> +if (unsupported_qtypes) {
> +error_setg(errp, "Can't parse %s' alternate member",
> +   QType_lookup[ctz32(unsupported_qtypes)]);
> +return;
> +}
> +
> +if ((qtypes & (1U << QTYPE_QBOOL)) &&
> +try_parse_bool(siv->string, NULL) == 0) {
> +qtype = QTYPE_QBOOL;
> +}
> +
> +*obj = g_malloc0(size);
> +(*obj)->type = qtype;

Slightly simpler for ignoring int for now, while still something we
could add in later.  I've been wanting to have an alternate for
'int'/'str' for InetAddress port, since we want to support named ports
but most often use just integers.  On the command line, port=1 is fine,
but in QMP, we currently have to spell it port="1".  That's a case where
we'd allow a pairing of any string with an integer, rather than just an
enum.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 2/3] qapi: Add enum_table[] parameter to start_alternate

[Eduardo Habkost]

On Fri, May 05, 2017 at 03:45:01PM -0500, Eric Blake wrote:
> On 05/05/2017 03:11 PM, Eduardo Habkost wrote:
> > The new parameter will be used by the string input visitor to detect
> > alternate types that can't be parsed unambiguously.
> > 
> > Signed-off-by: Eduardo Habkost 
> > ---
> > Changes v1 -> v2:
> > * (new patch added to series)
> > ---
> 
> > +++ b/include/qapi/visitor.h
> > @@ -411,13 +411,21 @@ void visit_end_list(Visitor *v, void **list);
> >   * @supported_qtypes is a bit mask indicating which QTypes are supported
> >   * by the alternate.
> >   *
> > + * @enum_table contains the enum value lookup table, in case
> > + * strings in the input are going to be parsed as enums. Visitors
> > + * aren't required to validate string input according to
> > + * enum_table, as visit_type_enum() will be called automatically
> > + * if (*obj)->type is QTYPE_QSTRING.
> 
> Presumably, enum_table will be NULL if the alternate type does not
> include an enum?  [reads ahead] yes. Should be documented.
> 
> I'm less convinced we need this patch, if we can instead guarantee at
> QAPI-generation time that alternates are not possible if they would
> cause an ambiguity.

I am not 100% sure either. I just have the feeling that we are
likely to break the rules and allow ambiguous enums in
exceptional cases in the future, and then this code will be
useful.

That doesn't mean we need to maintain it in the source tree. We
can leave it on the git history, or just on the qemu-devel
archives.

-- 
Eduardo

[Qemu-devel] [PATCH v9 4/6] hw/ppc/spapr.c: migrate pending_dimm_unplugs of spapr state

[Daniel Henrique Barboza]

To allow for a DIMM unplug event to resume its work if a migration
occurs in the middle of it, this patch migrates the non-empty
pending_dimm_unplugs QTAILQ that stores the DIMM information
that the spapr_lmb_release() callback uses.

It was considered an apprach where the DIMM states would be restored
on the post-_load after a migration. The problem is that there is
no way of knowing, from the sPAPRMachineState, if a given DIMM is going
through an unplug process and the callback needs the updated DIMM State.

We could migrate a flag indicating that there is an unplug event going
on for a certain DIMM, fetching this information from the start of the
spapr_del_lmbs call. But this would also require a scan on post_load to
figure out how many nr_lmbs are left. At this point we can just
migrate the nr_lmbs information as well, given that it is being calculated
at spapr_del_lmbs already, and spare a scanning/discovery in the
post-load. All that we need is inside the sPAPRDIMMState structure
that is added to the pending_dimm_unplugs queue at the start of the
spapr_del_lmbs, so it's convenient to just migrated this queue it if it's
not empty.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index e190eb9..30f0b7b 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1437,6 +1437,36 @@ static bool version_before_3(void *opaque, int 
version_id)
 return version_id < 3;
 }
 
+static bool spapr_pending_dimm_unplugs_needed(void *opaque)
+{
+sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
+return !QTAILQ_EMPTY(>pending_dimm_unplugs);
+}
+
+static const VMStateDescription vmstate_spapr_dimmstate = {
+.name = "spapr_dimm_state",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(addr, sPAPRDIMMState),
+VMSTATE_UINT32(nr_lmbs, sPAPRDIMMState),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static const VMStateDescription vmstate_spapr_pending_dimm_unplugs = {
+.name = "spapr_pending_dimm_unplugs",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spapr_pending_dimm_unplugs_needed,
+.fields = (VMStateField[]) {
+VMSTATE_QTAILQ_V(pending_dimm_unplugs, sPAPRMachineState, 1,
+ vmstate_spapr_dimmstate, sPAPRDIMMState,
+ next),
+VMSTATE_END_OF_LIST()
+},
+};
+
 static bool spapr_ov5_cas_needed(void *opaque)
 {
 sPAPRMachineState *spapr = opaque;
@@ -1535,6 +1565,7 @@ static const VMStateDescription vmstate_spapr = {
 .subsections = (const VMStateDescription*[]) {
 _spapr_ov5_cas,
 _spapr_patb_entry,
+_spapr_pending_dimm_unplugs,
 NULL
 }
 };
-- 
2.9.3

[Qemu-devel] [PATCH v9 3/6] hw/ppc: migrating the DRC state of hotplugged devices

[Daniel Henrique Barboza]

In pseries, a firmware abstraction called Dynamic Reconfiguration
Connector (DRC) is used to assign a particular dynamic resource
to the guest and provide an interface to manage configuration/removal
of the resource associated with it. In other words, DRC is the
'plugged state' of a device.

Before this patch, DRC wasn't being migrated. This causes
post-migration problems due to DRC state mismatch between source and
target. The DRC state of a device X in the source might
change, while in the target the DRC state of X is still fresh. When
migrating the guest, X will not have the same hotplugged state as it
did in the source. This means that we can't hot unplug X in the
target after migration is completed because its DRC state is not consistent.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1677552 is one
bug that is caused by this DRC state mismatch between source and
target.

To migrate the DRC state, we defined the VMStateDescription struct for
spapr_drc to enable the transmission of spapr_drc state in migration.
Not all the elements in the DRC state are migrated - only those
that can be modified by guest actions or device add/remove
operations:

- 'isolation_state', 'allocation_state' and 'indicator_state'
are involved in the DR state transition diagram from
PAPR+ 2.7, 13.4;

- 'configured', 'signalled', 'awaiting_release' and 'awaiting_allocation'
are needed in attaching and detaching devices;

- 'indicator_state' provides users with hardware state information.

These are the DRC elements that are migrated.

In this patch the DRC state is migrated for PCI, LMB and CPU
connector types. At this moment there is no support to migrate
DRC for the PHB (PCI Host Bridge) type.

In the 'realize' function the DRC is registered using vmstate_register,
similar to what hw/ppc/spapr_iommu.c does in 'spapr_tce_table_realize'.
This approach works because  DRCs are bus-less and do not sit
on a BusClass that implements bc->get_dev_path, so as a fallback the
VMSD gets identified via "spapr_drc"/get_index(drc).

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr_drc.c | 61 ++
 1 file changed, 61 insertions(+)

diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 1c72160..926b945 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -519,6 +519,65 @@ static void reset(DeviceState *d)
 }
 }
 
+static bool spapr_drc_needed(void *opaque)
+{
+sPAPRDRConnector *drc = (sPAPRDRConnector *)opaque;
+sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
+bool rc = false;
+sPAPRDREntitySense value;
+drck->entity_sense(drc, );
+/* If no dev is plugged in there is no need to migrate the DRC state */
+if (value != SPAPR_DR_ENTITY_SENSE_PRESENT) {
+return false;
+}
+
+/*
+ * If there is dev plugged in, we need to migrate the DRC state when
+ * it is different from cold-plugged state
+ */
+switch (drc->type) {
+
+case SPAPR_DR_CONNECTOR_TYPE_PCI:
+rc = !((drc->isolation_state == SPAPR_DR_ISOLATION_STATE_UNISOLATED) &&
+   (drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_USABLE) &&
+   drc->configured && drc->signalled && !drc->awaiting_release);
+break;
+
+case SPAPR_DR_CONNECTOR_TYPE_LMB:
+rc = !((drc->isolation_state == SPAPR_DR_ISOLATION_STATE_ISOLATED) &&
+   (drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_UNUSABLE) &&
+   drc->configured && drc->signalled && !drc->awaiting_release);
+break;
+
+case SPAPR_DR_CONNECTOR_TYPE_CPU:
+rc = !((drc->isolation_state == SPAPR_DR_ISOLATION_STATE_ISOLATED) &&
+   (drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_UNUSABLE) &&
+drc->configured && drc->signalled && !drc->awaiting_release);
+break;
+
+default:
+;
+}
+return rc;
+}
+
+static const VMStateDescription vmstate_spapr_drc = {
+.name = "spapr_drc",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spapr_drc_needed,
+.fields  = (VMStateField []) {
+VMSTATE_UINT32(isolation_state, sPAPRDRConnector),
+VMSTATE_UINT32(allocation_state, sPAPRDRConnector),
+VMSTATE_UINT32(indicator_state, sPAPRDRConnector),
+VMSTATE_BOOL(configured, sPAPRDRConnector),
+VMSTATE_BOOL(awaiting_release, sPAPRDRConnector),
+VMSTATE_BOOL(awaiting_allocation, sPAPRDRConnector),
+VMSTATE_BOOL(signalled, sPAPRDRConnector),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static void realize(DeviceState *d, Error **errp)
 {
 sPAPRDRConnector *drc = SPAPR_DR_CONNECTOR(d);
@@ -547,6 +606,8 @@ static void realize(DeviceState *d, Error **errp)
 object_unref(OBJECT(drc));
 }
 g_free(child_name);
+vmstate_register(DEVICE(drc), drck->get_index(drc), _spapr_drc,
+ drc);
 

[Qemu-devel] [PATCH v9 5/6] migration: spapr: migrate ccs_list in spapr state

[Daniel Henrique Barboza]

From: Jianjun Duan 

ccs_list in spapr state maintains the device tree related
information on the rtas side for hotplugged devices. In racing
situations between hotplug events and migration operation, a rtas
hotplug event could be migrated from the source guest to target
guest, or the source guest could have not yet finished fetching
the device tree when migration is started, the target will try
to finish fetching the device tree. By migrating ccs_list, the
target can fetch the device tree properly.

In theory there would be other alternatives besides migrating the
css_list to fix this. For example, we could add a flag that indicates
whether a device is in the middle of the configure_connector during the
migration process, in the post_load we can detect if this flag
is active and then return an error informing the guest to restart the
hotplug process. However, the DRC state can still be modified outside of
hotplug. Using:

   drmgr -c pci -s  -r
   drmgr -c pci -s  -a

it is possible to return a device to firmware and then later take it
back and reconfigure it. This is not a common case but it's not prohibited,
and performing a migration between these 2 operations would fail because
the default coldplug state on target assumes a configured state in
the source*. Migrating ccs_list is one solution that cover this
case as well.

ccs_list is put in a subsection in the spapr state VMSD to make
sure migration across different versions is not broken.

* see http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg01763.html
for more information on this discussion.

Signed-off-by: Jianjun Duan 
Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 30f0b7b..bc56249 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1467,6 +1467,37 @@ static const VMStateDescription 
vmstate_spapr_pending_dimm_unplugs = {
 },
 };
 
+static bool spapr_ccs_list_needed(void *opaque)
+{
+sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
+return !QTAILQ_EMPTY(>ccs_list);
+}
+
+static const VMStateDescription vmstate_spapr_ccs = {
+.name = "spapr_configure_connector_state",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(drc_index, sPAPRConfigureConnectorState),
+VMSTATE_INT32(fdt_offset, sPAPRConfigureConnectorState),
+VMSTATE_INT32(fdt_depth, sPAPRConfigureConnectorState),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static const VMStateDescription vmstate_spapr_ccs_list = {
+.name = "spapr_ccs_list",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spapr_ccs_list_needed,
+.fields = (VMStateField[]) {
+VMSTATE_QTAILQ_V(ccs_list, sPAPRMachineState, 1,
+ vmstate_spapr_ccs, sPAPRConfigureConnectorState,
+ next),
+VMSTATE_END_OF_LIST()
+},
+};
+
 static bool spapr_ov5_cas_needed(void *opaque)
 {
 sPAPRMachineState *spapr = opaque;
@@ -1566,6 +1597,7 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_ov5_cas,
 _spapr_patb_entry,
 _spapr_pending_dimm_unplugs,
+_spapr_ccs_list,
 NULL
 }
 };
-- 
2.9.3

[Qemu-devel] [PATCH v9 2/6] hw/ppc: removing drc->detach_cb and drc->detach_cb_opaque

[Daniel Henrique Barboza]

The pointer drc->detach_cb is being used as a way of informing
the detach() function inside spapr_drc.c which cb to execute. This
information can also be retrieved simply by checking drc->type and
choosing the right callback based on it. In this context, detach_cb
is redundant information that must be managed.

After the previous spapr_lmb_release change, no detach_cb_opaques
are being used by any of the three callbacks functions. This is
yet another information that is now unused and, on top of that, can't
be migrated either.

This patch makes the following changes:

- removal of detach_cb_opaque. the 'opaque' argument was removed from
the callbacks and from the detach() function of sPAPRConnectorClass. The
attribute detach_cb_opaque of sPAPRConnector was removed.

- removal of detach_cb from the detach() call. The function pointer
detach_cb of sPAPRConnector was removed. detach() now uses a
switch(drc->type) to execute the apropriate callback. To achieve this,
spapr_core_release, spapr_lmb_release and spapr_phb_remove_pci_device_cb
callbacks were made public to be visible inside detach().

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr.c  | 10 ++
 hw/ppc/spapr_drc.c  | 36 
 hw/ppc/spapr_pci.c  |  5 +++--
 include/hw/pci-host/spapr.h |  3 +++
 include/hw/ppc/spapr.h  |  4 
 include/hw/ppc/spapr_drc.h  |  8 +---
 6 files changed, 37 insertions(+), 29 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 346c827..e190eb9 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2610,7 +2610,8 @@ static uint64_t spapr_dimm_get_address(PCDIMMDevice *dimm)
 return addr;
 }
 
-static void spapr_lmb_release(DeviceState *dev, void *opaque)
+/* Callback to be called during DRC release. */
+void spapr_lmb_release(DeviceState *dev)
 {
 HotplugHandler *hotplug_ctrl;
 
@@ -2652,7 +2653,7 @@ static void spapr_del_lmbs(DeviceState *dev, uint64_t 
addr_start, uint64_t size,
 g_assert(drc);
 
 drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
-drck->detach(drc, dev, spapr_lmb_release, NULL, errp);
+drck->detach(drc, dev, errp);
 addr += SPAPR_MEMORY_BLOCK_SIZE;
 }
 
@@ -2728,7 +2729,8 @@ static void spapr_core_unplug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 object_unparent(OBJECT(dev));
 }
 
-static void spapr_core_release(DeviceState *dev, void *opaque)
+/* Callback to be called during DRC release. */
+void spapr_core_release(DeviceState *dev)
 {
 HotplugHandler *hotplug_ctrl;
 
@@ -2761,7 +2763,7 @@ void spapr_core_unplug_request(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 g_assert(drc);
 
 drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
-drck->detach(drc, dev, spapr_core_release, NULL, _err);
+drck->detach(drc, dev, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index a1cdc87..1c72160 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -20,6 +20,7 @@
 #include "qapi/visitor.h"
 #include "qemu/error-report.h"
 #include "hw/ppc/spapr.h" /* for RTAS return codes */
+#include "hw/pci-host/spapr.h" /* spapr_phb_remove_pci_device_cb callback */
 #include "trace.h"
 
 #define DRC_CONTAINER_PATH "/dr-connector"
@@ -99,8 +100,7 @@ static uint32_t set_isolation_state(sPAPRDRConnector *drc,
 if (drc->awaiting_release) {
 if (drc->configured) {
 trace_spapr_drc_set_isolation_state_finalizing(get_index(drc));
-drck->detach(drc, DEVICE(drc->dev), drc->detach_cb,
- drc->detach_cb_opaque, NULL);
+drck->detach(drc, DEVICE(drc->dev), NULL);
 } else {
 trace_spapr_drc_set_isolation_state_deferring(get_index(drc));
 }
@@ -153,8 +153,7 @@ static uint32_t set_allocation_state(sPAPRDRConnector *drc,
 if (drc->awaiting_release &&
 drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_UNUSABLE) {
 trace_spapr_drc_set_allocation_state_finalizing(get_index(drc));
-drck->detach(drc, DEVICE(drc->dev), drc->detach_cb,
- drc->detach_cb_opaque, NULL);
+drck->detach(drc, DEVICE(drc->dev), NULL);
 } else if (drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_USABLE) {
 drc->awaiting_allocation = false;
 }
@@ -404,15 +403,10 @@ static void attach(sPAPRDRConnector *drc, DeviceState *d, 
void *fdt,
  NULL, 0, NULL);
 }
 
-static void detach(sPAPRDRConnector *drc, DeviceState *d,
-   spapr_drc_detach_cb *detach_cb,
-   void *detach_cb_opaque, Error **errp)
+static void detach(sPAPRDRConnector *drc, DeviceState *d, Error **errp)
 {
 trace_spapr_drc_detach(get_index(drc));
 
-drc->detach_cb = detach_cb;
-drc->detach_cb_opaque = detach_cb_opaque;
-
 

[Qemu-devel] [PATCH v9 1/6] hw/ppc/spapr.c: adding pending_dimm_unplugs to sPAPRMachineState

[Daniel Henrique Barboza]

The LMB DRC release callback, spapr_lmb_release(), uses an opaque
parameter, a sPAPRDIMMState struct that stores the current LMBs that
are allocated to a DIMM (nr_lmbs). After each call to this callback,
the nr_lmbs is decremented by one and, when it reaches zero, the callback
proceeds with the qdev calls to hot unplug the LMB.

Using drc->detach_cb_opaque is problematic because it can't be migrated in
the future DRC migration work. This patch makes the following changes to
eliminate the usage of this opaque callback inside spapr_lmb_release:

- sPAPRDIMMState was moved from spapr.c and added to spapr.h. A new
attribute called 'addr' was added to it. This is used as an unique
identifier to associate a sPAPRDIMMState to a PCDIMM element.

- sPAPRMachineState now hosts a new QTAILQ called 'pending_dimm_unplugs'.
This queue of sPAPRDIMMState elements will store the DIMM state of DIMMs
that are currently going under an unplug process.

- spapr_lmb_release() will now retrieve the nr_lmbs value by getting the
correspondent sPAPRDIMMState. A helper function called spapr_dimm_get_address
was created to fetch the address of a PCDIMM device inside spapr_lmb_release.
When nr_lmbs reaches zero and the callback proceeds with the qdev hot unplug
calls, the sPAPRDIMMState struct is removed from spapr->pending_dimm_unplugs.

After these changes, the opaque argument for spapr_lmb_release is now
unused and is passed as NULL inside spapr_del_lmbs. This and the other
opaque arguments can now be safely removed from the code.

Signed-off-by: Daniel Henrique Barboza 
---
 hw/ppc/spapr.c | 54 --
 include/hw/ppc/spapr.h | 17 
 2 files changed, 65 insertions(+), 6 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 80d12d0..346c827 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2043,6 +2043,7 @@ static void ppc_spapr_init(MachineState *machine)
 msi_nonbroken = true;
 
 QLIST_INIT(>phbs);
+QTAILQ_INIT(>pending_dimm_unplugs);
 
 /* Allocate RMA if necessary */
 rma_alloc_size = kvmppc_alloc_rma();
@@ -2596,20 +2597,32 @@ out:
 error_propagate(errp, local_err);
 }
 
-typedef struct sPAPRDIMMState {
-uint32_t nr_lmbs;
-} sPAPRDIMMState;
+static uint64_t spapr_dimm_get_address(PCDIMMDevice *dimm)
+{
+Error *local_err = NULL;
+uint64_t addr;
+addr = object_property_get_int(OBJECT(dimm), PC_DIMM_ADDR_PROP,
+   _err);
+if (local_err) {
+error_propagate(_abort, local_err);
+return 0;
+}
+return addr;
+}
 
 static void spapr_lmb_release(DeviceState *dev, void *opaque)
 {
-sPAPRDIMMState *ds = (sPAPRDIMMState *)opaque;
 HotplugHandler *hotplug_ctrl;
 
+uint64_t addr = spapr_dimm_get_address(PC_DIMM(dev));
+sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
+sPAPRDIMMState *ds = spapr_pending_dimm_unplugs_find(spapr, addr);
+
 if (--ds->nr_lmbs) {
 return;
 }
 
-g_free(ds);
+spapr_pending_dimm_unplugs_remove(spapr, ds);
 
 /*
  * Now that all the LMBs have been removed by the guest, call the
@@ -2626,17 +2639,20 @@ static void spapr_del_lmbs(DeviceState *dev, uint64_t 
addr_start, uint64_t size,
 sPAPRDRConnectorClass *drck;
 uint32_t nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
 int i;
+sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
 sPAPRDIMMState *ds = g_malloc0(sizeof(sPAPRDIMMState));
 uint64_t addr = addr_start;
 
 ds->nr_lmbs = nr_lmbs;
+ds->addr = addr_start;
+spapr_pending_dimm_unplugs_add(spapr, ds);
 for (i = 0; i < nr_lmbs; i++) {
 drc = spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_LMB,
 addr / SPAPR_MEMORY_BLOCK_SIZE);
 g_assert(drc);
 
 drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
-drck->detach(drc, dev, spapr_lmb_release, ds, errp);
+drck->detach(drc, dev, spapr_lmb_release, NULL, errp);
 addr += SPAPR_MEMORY_BLOCK_SIZE;
 }
 
@@ -3515,3 +3531,29 @@ static void spapr_machine_register_types(void)
 }
 
 type_init(spapr_machine_register_types)
+
+sPAPRDIMMState *spapr_pending_dimm_unplugs_find(sPAPRMachineState *spapr,
+uint64_t addr)
+{
+sPAPRDIMMState *dimm_state = NULL;
+QTAILQ_FOREACH(dimm_state, >pending_dimm_unplugs, next) {
+if (dimm_state->addr == addr) {
+break;
+}
+}
+return dimm_state;
+}
+
+void spapr_pending_dimm_unplugs_add(sPAPRMachineState *spapr,
+   sPAPRDIMMState *dimm_state)
+{
+g_assert(!spapr_pending_dimm_unplugs_find(spapr, dimm_state->addr));
+QTAILQ_INSERT_HEAD(>pending_dimm_unplugs, dimm_state, next);
+}
+
+void spapr_pending_dimm_unplugs_remove(sPAPRMachineState *spapr,
+  sPAPRDIMMState *dimm_state)
+{
+

[Qemu-devel] [PATCH v9 0/6] migration/ppc: migrating DRC, ccs_list and pending_events

[Daniel Henrique Barboza]

v9:
- patch 1 (*new*): added a qtail in sPAPRMachineState called 
pending_dimm_unplugs
that stores the DIMM LMB state during the unplug process.
- patch 2 (*new*): merged v8-patch1 and v8-patch2: removing detach_cb and
detach_cb_opaque.
- patch 3:
* removed dk->vmsd entry. We're using vmstate_register instead
* added 'awaiting_allocation' flag in the DRC migration
- patch 4 (*new*): migrating spapr->pending_dimm_unplugs qtailq to allow
for an ongoing PCDIMM unplug to continue after a migration.

v8:
- new patch added: 'removing spapr_drc_detach_cb opaques'. This new patch 
removes
the need for the detach_cb_opaques inside the removal callback functions. See
the commit message of the patch for more info.

v7:
- removed the first patch. DRC registration is now done by vmstate_register
in patch 2.
- added a new patch that changes spapr_dr_connector_new to receive as argument
the detach_cb.
- removed the callback logic of patch 2 since there is no need to restore the
detach_cb on post-load due to the detach_cb on spapr_dr_connector_new change.
- added word separators in the VMSD names of patch 3 and 4.

v6: - Rebased with QEMU master after 6+ months.
- Simplified the logic in patch 1.
- Reworked patch 2: added CPU DRC migration, removed a function pointer 
from DRC
class and minor improvements.
- Added clarifications from the previous v5 discussions in the commit 
messages.

v5: - Rebased to David's ppc-for-2.8.

v4: - Introduce a way to set customized instance_id in SaveStateEntry. Use it
  to set instance_id for DRC using its unique index to address David 
  Gibson's concern.
- Rename VMS_CSTM to VMS_LINKED based on Paolo Bonzini's suggestions.
- Clean up qjson stuff in put_qtailq. 
- Add trace for put_qtailq and get_qtailq based on David Gilbert's 
  suggestion.

- Based on David's ppc-for-2.7. 

v3: - Simplify overall design followng discussion with Paolo. No longer need
  metadata to migrate QTAILQ.
- Extend VMStateInfo instead of adding similar fields to VMStateField.
- Clean up macros in qemu/queue.h.
(link: https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg05695.html)

v2: - Introduce a general approach to migrate QTAILQ in qemu/queue.h.
- Migrate signalled field in the DRC state.
- Put the newly added migrating fields in subsections so that backward 
  migration is not broken.  
- Set detach_cb field right after migration so that a migrated hot-unplug
  event could finish its course.
(link: https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg04188.html)

v1: - Inital version.
(link: https://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg02601.html)


To make guest devices (PCI, CPU and memory) hotplug work together 
with guest migration, spapr drc state needs be transmitted in
migration. This patch defines the VMStateDescription struct for
spapr drc state to enable it.

To fix the potential racing between hotplug events on guest and 
guest migration, ccs_list and pending_events of spapr state need be 
transmitted in migration. This patch set also takes care of it.



Daniel Henrique Barboza (4):
  hw/ppc/spapr.c: adding pending_dimm_unplugs to sPAPRMachineState
  hw/ppc: removing drc->detach_cb and drc->detach_cb_opaque
  hw/ppc: migrating the DRC state of hotplugged devices
  hw/ppc/spapr.c: migrate pending_dimm_unplugs of spapr state

Jianjun Duan (2):
  migration: spapr: migrate ccs_list in spapr state
  migration: spapr: migrate pending_events of spapr state

 hw/ppc/spapr.c  | 158 +---
 hw/ppc/spapr_drc.c  |  97 ++-
 hw/ppc/spapr_events.c   |  24 ---
 hw/ppc/spapr_pci.c  |   5 +-
 include/hw/pci-host/spapr.h |   3 +
 include/hw/ppc/spapr.h  |  24 ++-
 include/hw/ppc/spapr_drc.h  |   8 +--
 7 files changed, 273 insertions(+), 46 deletions(-)

-- 
2.9.3

Re: [Qemu-devel] [PATCH v2 2/3] qapi: Add enum_table[] parameter to start_alternate

[Eric Blake]

On 05/05/2017 03:11 PM, Eduardo Habkost wrote:
> The new parameter will be used by the string input visitor to detect
> alternate types that can't be parsed unambiguously.
> 
> Signed-off-by: Eduardo Habkost 
> ---
> Changes v1 -> v2:
> * (new patch added to series)
> ---

> +++ b/include/qapi/visitor.h
> @@ -411,13 +411,21 @@ void visit_end_list(Visitor *v, void **list);
>   * @supported_qtypes is a bit mask indicating which QTypes are supported
>   * by the alternate.
>   *
> + * @enum_table contains the enum value lookup table, in case
> + * strings in the input are going to be parsed as enums. Visitors
> + * aren't required to validate string input according to
> + * enum_table, as visit_type_enum() will be called automatically
> + * if (*obj)->type is QTYPE_QSTRING.

Presumably, enum_table will be NULL if the alternate type does not
include an enum?  [reads ahead] yes. Should be documented.

I'm less convinced we need this patch, if we can instead guarantee at
QAPI-generation time that alternates are not possible if they would
cause an ambiguity.


> +++ b/scripts/qapi-visit.py
> @@ -166,6 +166,12 @@ def gen_visit_alternate(name, variants):
>  supported_qtypes = ' | '.join(qtypes)
>  ret = ''
>  
> +enum_table = 'NULL'
> +for var in variants.variants:
> +if isinstance(var.type, QAPISchemaEnumType):
> +enum_table = '%s_lookup' % (var.type.c_name())
> +break
> +
>  ret += mcgen('''
>  
>  void visit_type_%(c_name)s(Visitor *v, const char *name, %(c_name)s **obj, 
> Error **errp)
> @@ -174,7 +180,7 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
> %(c_name)s **obj, Error
>  uint32_t supported_qtypes = %(supported_qtypes)s;
>  
>  visit_start_alternate(v, name, (GenericAlternate **)obj, sizeof(**obj),
> -  supported_qtypes, );
> +  supported_qtypes, %(enum_table)s, );

So there's where you populate the enum through.

I'll have to see where 3/3 goes before deciding if this is worth having.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 0/3] string-input-visitor: Support enum/bool alternate types

[no-reply]

Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH v2 0/3] string-input-visitor: Support enum/bool 
alternate types
Message-id: 20170505201128.12099-1-ehabk...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-mingw@fedora
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
b91a529 string-input-visitor: Support alternate types
d757553 qapi: Add enum_table[] parameter to start_alternate
f0b0e5a visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-3z3n0lbm/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-3z3n0lbm/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=84864fe0c458
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support 

[Qemu-devel] [PATCH] fixup! sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Eduardo Habkost]

On Fri, May 05, 2017 at 01:54:19PM -0300, Eduardo Habkost wrote:
> On Fri, May 05, 2017 at 09:36:22AM +0200, Cornelia Huck wrote:
> [...]
> > > diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> > > index c0f560b289..6a2eec8dd0 100644
> > > --- a/hw/core/sysbus.c
> > > +++ b/hw/core/sysbus.c
> > > @@ -326,6 +326,17 @@ static void sysbus_device_class_init(ObjectClass 
> > > *klass, void *data)
> > >  DeviceClass *k = DEVICE_CLASS(klass);
> > >  k->init = sysbus_device_init;
> > >  k->bus_type = TYPE_SYSTEM_BUS;
> > > +/*
> > > + * device_add plugs devices into suitable bus.  For "real" buses,
> > 
> > s/suitable/a suitable/
> 
> Thanks, I will fix it.
> 
> > 
> > > + * that actually connects the device.  For sysbus, the connections
> > > + * need to be made separately, and device_add can't do that.  The
> > > + * device would be left unconnected, and will probably not work
> > > + *
> > > + * However, a few machines and a few devices can handle a few sysbus
> > > + * devices. In this case, the device subclass needs to override
> > 
> > Should that rather be "a few machines can handle a few specific sysbus
> > devices"?
> 
> I will extend it to "a few machines can handle device_add for a
> few specific sysbus devices". Thanks for spotting it.

Fixup will be included in v3, or can be applied by maintainer:

Signed-off-by: Eduardo Habkost 
---
 hw/core/sysbus.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 6a2eec8dd0..5d0887f499 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -327,14 +327,14 @@ static void sysbus_device_class_init(ObjectClass *klass, 
void *data)
 k->init = sysbus_device_init;
 k->bus_type = TYPE_SYSTEM_BUS;
 /*
- * device_add plugs devices into suitable bus.  For "real" buses,
+ * device_add plugs devices into a suitable bus.  For "real" buses,
  * that actually connects the device.  For sysbus, the connections
  * need to be made separately, and device_add can't do that.  The
  * device would be left unconnected, and will probably not work
  *
- * However, a few machines and a few devices can handle a few sysbus
- * devices. In this case, the device subclass needs to override
- * it and set user_creatable=true.
+ * However, a few machines can handle device_add/-device with
+ * a few specific sysbus devices. In those cases, the device
+ * subclass needs to override it and set user_creatable=true.
  */
 k->user_creatable = false;
 }
-- 
2.11.0.259.g40922b1

Re: [Qemu-devel] [PATCH v2] hw/virtio: fix vhost user fails to startup when MQ

[Michael S. Tsirkin]

On Fri, May 05, 2017 at 09:34:14AM +0200, Maxime Coquelin wrote:
> Hi,
> 
> On 05/04/2017 06:25 PM, Zhiyong Yang wrote:
> >   Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together
> > to cause failures of new connection when negotiating to set MQ.
> > (one queue pair works well).
> > Because there exist some bugs in qemu code when introducing
> > VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. When vhost_user_set_mem_table
> > is invoked to deal with the vhost message VHOST_USER_SET_MEM_TABLE
> > for the second time, qemu indeed doesn't send the messge (The message
> > needs to be sent only once)but still will be waiting for dpdk's reply
> > ack, then, qemu is always freezing, while DPDK is always waiting for
> > next vhost message from qemu.
> >The patch aims to fix the bug, MQ can work well.
> >The same bug is found in function vhost_user_net_set_mtu, it is fixed
> > at the same time.
> >DPDK related patch is as following:
> >http://www.dpdk.org/dev/patchwork/patch/23955/
> > 
> > Signed-off-by: Zhiyong Yang 
> > ---
> > 
> > Changes in V2:
> > Thanks for Maxime's suggestion, if one-time request, clear the
> > VHOST_USER_NEED_REPLY flag in function vhost_user_write,
> > in process_message_reply(), return early, if this flag isn't set.
> > 
> >   hw/virtio/vhost-user.c | 21 +
> >   1 file changed, 13 insertions(+), 8 deletions(-)
> > 
> 
> Thanks for the quick fix, it looks good to me.
> I forgot to ask you to cc qemu-stable, and reference the faulty commit:
> 
> Cc: qemu-sta...@nongnu.org
> Fixes: ca525ce5618b ("vhost-user: Introduce a new protocol feature
> REPLY_ACK.")
> 
> Maybe this can be amended when applied. Michael?

Sure. np.

> Other than that, feel free to add my:
> Reviewed-by: Maxime Coquelin 
> 
> Thanks,
> Maxime

Re: [Qemu-devel] virtio-net: configurable TX queue size

[Michael S. Tsirkin]

On Fri, May 05, 2017 at 10:27:13AM +0800, Jason Wang wrote:
> 
> 
> On 2017年05月04日 18:58, Wang, Wei W wrote:
> > Hi,
> > 
> > I want to re-open the discussion left long time ago:
> > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06194.html
> > , and discuss the possibility of changing the hardcoded (256) TX  queue
> > size to be configurable between 256 and 1024.
> 
> Yes, I think we probably need this.
> 
> > 
> > The reason to propose this request is that a severe issue of packet drops in
> > TX direction was observed with the existing hardcoded 256 queue size,
> > which causes performance issues for packet drop sensitive guest
> > applications that cannot use indirect descriptor tables. The issue goes away
> > with 1K queue size.
> 
> Do we need even more, what if we find 1K is even not sufficient in the
> future? Modern nics has size up to ~8192.
> 
> > 
> > The concern mentioned in the previous discussion (please check the link
> > above) is that the number of chained descriptors would exceed
> > UIO_MAXIOV (1024) supported by the Linux.
> 
> We could try to address this limitation but probably need a new feature bit
> to allow more than UIO_MAXIOV sgs.

I'd say we should split the queue size and the sg size.

> > 
> >  From the code,  I think the number of the chained descriptors is limited to
> > MAX_SKB_FRAGS + 2 (~18), which is much less than UIO_MAXIOV.
> 
> This is the limitation of #page frags for skb, not the iov limitation.
> 
> Thanks
> 
> > Please point out if I missed anything. Thanks.
> > 
> > Best,
> > Wei
> > 
> > 

Re: [Qemu-devel] [PATCH v2 07/24] pc: add node-id property to CPU

[Eduardo Habkost]

On Wed, May 03, 2017 at 02:57:01PM +0200, Igor Mammedov wrote:
> it will allow switching from cpu_index to property based
> numa mapping in follow up patches.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  hw/i386/pc.c  | 17 +
>  target/i386/cpu.c |  1 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 9cec0c1..4a4fb1c 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1893,6 +1893,7 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
>  DeviceState *dev, Error **errp)
>  {
>  int idx;
> +int node_id;
>  CPUState *cs;
>  CPUArchId *cpu_slot;
>  X86CPUTopoInfo topo;
> @@ -1982,6 +1983,22 @@ static void pc_cpu_pre_plug(HotplugHandler 
> *hotplug_dev,
>  
>  cs = CPU(cpu);
>  cs->cpu_index = idx;
> +
> +node_id = numa_get_node_for_cpu(cs->cpu_index);
> +if (node_id == nb_numa_nodes) {
> +/* by default CPUState::numa_node was 0 if it's not set via CLI
> + * keep it this way for now but in future we probably should
> + * refuse to start up with incomplete numa mapping */
> +node_id = 0;
> +}
> +if (cs->numa_node == CPU_UNSET_NUMA_NODE_ID) {
> +cs->numa_node = node_id;

I suggest moving the above lines to cpu_common_realizefn(), and
deleting the code in numa_post_machine_init().

If you want to do this in v3 of this series, or as a follow-up
patch, it's up to you.


> +} else if (cs->numa_node != node_id) {
> +error_setg(errp, "node-id %d must match numa node specified"
> +"with -numa option for cpu-index %d",
> +cs->numa_node, cs->cpu_index);
> +return;
> +}
>  }
>  
>  static void pc_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev,
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 13c0985..007a5bd 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -3982,6 +3982,7 @@ static Property x86_cpu_properties[] = {
>  DEFINE_PROP_INT32("core-id", X86CPU, core_id, -1),
>  DEFINE_PROP_INT32("socket-id", X86CPU, socket_id, -1),
>  #endif
> +DEFINE_PROP_INT32("node-id", CPUState, numa_node, 
> CPU_UNSET_NUMA_NODE_ID),

This changes the default from 0 to CPU_UNSET_NUMA_NODE_ID, but it
looks like there's no existing i386 or PC code that ever looks at
CPUState::numa_node. Maybe worth mentioning in the commit
message.

>  DEFINE_PROP_BOOL("pmu", X86CPU, enable_pmu, false),
>  { .name  = "hv-spinlocks", .info  = _prop_spinlocks },
>  DEFINE_PROP_BOOL("hv-relaxed", X86CPU, hyperv_relaxed_timing, false),
> -- 
> 2.7.4
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 1/3] visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

[Eric Blake]

On 05/05/2017 03:11 PM, Eduardo Habkost wrote:
> This will allow visitors to make decisions based on the supported qtypes
> of a given alternate type. The new parameter can replace the old
> 'promote_int' argument, as qobject-input-visitor can simply check if
> QTYPE_QINT is set in supported_qtypes.
> 
> Signed-off-by: Eduardo Habkost 
> ---
> Changes v1 -> v2:
> * Change supported_qtypes to uint32_t (Eric Blake)
> * Replace assert() on all generated visitor functions with a
>   single QEMU_BUILD_BUG_ON() on visit_start_alternate()
> * Extra spaces around "|" on generated visitor code
>   (Eric Blake)
> * Don't use bitops.h and just use (1U << QTYPE_FOO)
>   (Markus Armbruster)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 03/10] qcow2: Correctly report status of preallocated zero clusters

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> We were throwing away the preallocation information associated with
> zero clusters.  But we should be matching the well-defined semantics
> in bdrv_get_block_status(), where (BDRV_BLOCK_ZERO |
> BDRV_BLOCK_OFFSET_VALID) informs the user which offset is reserved,
> while still reminding the user that reading from that offset is
> likely to read garbage.
> 
> count_contiguous_clusters_by_type() is now used only for unallocated
> cluster runs, hence it gets renamed and tightened.
> 
> Making this change lets us see which portions of an image are zero
> but preallocated, when using qemu-img map --output=json.  The
> --output=human side intentionally ignores all zero clusters, whether
> or not they are preallocated.
> 
> The fact that there is no change to qemu-iotests './check -qcow2'
> merely means that we aren't yet testing this aspect of qemu-img;
> a later patch will add a test.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: rename helper function
> v11: reserved for blkdebug half of v10
> v10: new patch
> ---
>  block/qcow2-cluster.c | 45 +++--
>  1 file changed, 35 insertions(+), 10 deletions(-)

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 02/10] block: Update comments on BDRV_BLOCK_* meanings

[Max Reitz]

On 05.05.2017 22:13, Eric Blake wrote:
> On 05/05/2017 03:06 PM, Max Reitz wrote:
>> On 04.05.2017 05:07, Eric Blake wrote:
>>> We had some conflicting documentation: a nice 8-way table that
>>> described all possible combinations of DATA, ZERO, and
>>> OFFSET_VALID, contrasted with text that implied that OFFSET_VALID
>>> always meant raw data could be read directly.  Furthermore, the
>>> text refers a lot to bs->file, even though the interface was
>>> updated back in 67a0fd2a to let the driver pass back which BDS (not
>>> necessarily bs->file).
>>
>> Not sure about my English skills here, but is this missing a verb? ("to
>> pass back which BDS...")
> 
> maybe s/which/a specific/

Or that, yes. :-)

> 
>>
>>> As the 8-way table is the intended
>>> semantics, simplify the rest of the text to get rid of the
>>> confusion.
>>>
>>> ALLOCATED is always set by the block layer for convenience (drivers
>>> do not have to worry about it). RAW is used only internally, but
>>
>> Just one space after the period? How inconsistent! :-)
> 
> But do commit messages really count?  :)

It's a critical bug, I'm telling you!!!

>>> + * Internal flag:
>>> + * BDRV_BLOCK_RAW: used internally to indicate that the request was
>>> + * answered by a passthrough driver such as raw and that 
>>> the
>>
>> s/passthrough/filter/? But I'm not even sure myself. Well, "passthrough"
>> is a safe bet, so let's just go with it.
> 
> Calling 'raw' a filter driver is a bit weird - but in one sense, it is a
> no-op filter (filter the protocol layer into the format layer by doing
> nothing).  Meanwhile 'commit' certainly sounds like more of a filter
> than a passthrough.  I could go either way, and filter is slightly
> shorter.  If there's a real reason to respin the series, 'filter' seems
> reasonable if we're worried about line length, otherwise I'm just as
> inclined to leave it alone.

raw certainly is a filter driver; the thing I wasn't sure about is that
I'm not sure whether filter drivers are required to set this flag. But
neither the comment nor the code require it necessarily, so using
"filter" instead of "passthrough" should be OK.

The main reason for using "filter" over "passthrough" is that "filter"
is a "real" class of block drivers (just "real" in the sense that we
actually only have child-less protocol drivers and non-protocol drivers
that do have children; further dividing into "format" and "filter" is
just a convention).

But it should be clear anyway, so I don't mind either way. Leaving it as
it is certainly is simpler.

Max

> 
>>
>> With the commit message fixed or a “no it's fine”:
>>
>> Reviewed-by: Max Reitz 
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v12 02/10] block: Update comments on BDRV_BLOCK_* meanings

[Eric Blake]

On 05/05/2017 03:06 PM, Max Reitz wrote:
> On 04.05.2017 05:07, Eric Blake wrote:
>> We had some conflicting documentation: a nice 8-way table that
>> described all possible combinations of DATA, ZERO, and
>> OFFSET_VALID, contrasted with text that implied that OFFSET_VALID
>> always meant raw data could be read directly.  Furthermore, the
>> text refers a lot to bs->file, even though the interface was
>> updated back in 67a0fd2a to let the driver pass back which BDS (not
>> necessarily bs->file).
> 
> Not sure about my English skills here, but is this missing a verb? ("to
> pass back which BDS...")

maybe s/which/a specific/

> 
>> As the 8-way table is the intended
>> semantics, simplify the rest of the text to get rid of the
>> confusion.
>>
>> ALLOCATED is always set by the block layer for convenience (drivers
>> do not have to worry about it). RAW is used only internally, but
> 
> Just one space after the period? How inconsistent! :-)

But do commit messages really count?  :)


>> + * Internal flag:
>> + * BDRV_BLOCK_RAW: used internally to indicate that the request was
>> + * answered by a passthrough driver such as raw and that the
> 
> s/passthrough/filter/? But I'm not even sure myself. Well, "passthrough"
> is a safe bet, so let's just go with it.

Calling 'raw' a filter driver is a bit weird - but in one sense, it is a
no-op filter (filter the protocol layer into the format layer by doing
nothing).  Meanwhile 'commit' certainly sounds like more of a filter
than a passthrough.  I could go either way, and filter is slightly
shorter.  If there's a real reason to respin the series, 'filter' seems
reasonable if we're worried about line length, otherwise I'm just as
inclined to leave it alone.

> 
> With the commit message fixed or a “no it's fine”:
> 
> Reviewed-by: Max Reitz 
> 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v2 1/3] visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

[Eduardo Habkost]

This will allow visitors to make decisions based on the supported qtypes
of a given alternate type. The new parameter can replace the old
'promote_int' argument, as qobject-input-visitor can simply check if
QTYPE_QINT is set in supported_qtypes.

Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* Change supported_qtypes to uint32_t (Eric Blake)
* Replace assert() on all generated visitor functions with a
  single QEMU_BUILD_BUG_ON() on visit_start_alternate()
* Extra spaces around "|" on generated visitor code
  (Eric Blake)
* Don't use bitops.h and just use (1U << QTYPE_FOO)
  (Markus Armbruster)
---
 include/qapi/visitor.h   |  5 +++--
 include/qapi/visitor-impl.h  |  2 +-
 scripts/qapi-visit.py| 12 ++--
 qapi/qapi-visit-core.c   |  9 ++---
 qapi/qapi-clone-visitor.c|  3 ++-
 qapi/qapi-dealloc-visitor.c  |  3 ++-
 qapi/qobject-input-visitor.c |  6 --
 qapi/trace-events|  2 +-
 8 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
index 1a1b62012b..8f5a223714 100644
--- a/include/qapi/visitor.h
+++ b/include/qapi/visitor.h
@@ -408,7 +408,8 @@ void visit_end_list(Visitor *v, void **list);
  * the qtype of the next thing to be visited, stored in (*@obj)->type.
  * Other visitors will leave @obj unchanged.
  *
- * If @promote_int, treat integers as QTYPE_FLOAT.
+ * @supported_qtypes is a bit mask indicating which QTypes are supported
+ * by the alternate.
  *
  * If successful, this must be paired with visit_end_alternate() with
  * the same @obj to clean up, even if visiting the contents of the
@@ -416,7 +417,7 @@ void visit_end_list(Visitor *v, void **list);
  */
 void visit_start_alternate(Visitor *v, const char *name,
GenericAlternate **obj, size_t size,
-   bool promote_int, Error **errp);
+   uint32_t supported_qtypes, Error **errp);
 
 /*
  * Finish visiting an alternate type.
diff --git a/include/qapi/visitor-impl.h b/include/qapi/visitor-impl.h
index e87709db5c..8afcde0f5d 100644
--- a/include/qapi/visitor-impl.h
+++ b/include/qapi/visitor-impl.h
@@ -71,7 +71,7 @@ struct Visitor
  * optional for output visitors. */
 void (*start_alternate)(Visitor *v, const char *name,
 GenericAlternate **obj, size_t size,
-bool promote_int, Error **errp);
+uint32_t supported_qtypes, Error **errp);
 
 /* Optional, needed for dealloc visitor */
 void (*end_alternate)(Visitor *v, void **obj);
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 5737aefa05..41c54982e2 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -161,20 +161,20 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
%(c_name)s *obj, Error
 
 
 def gen_visit_alternate(name, variants):
-promote_int = 'true'
+qtypes = ['(1U << %s)' % (var.type.alternate_qtype())
+  for var in variants.variants]
+supported_qtypes = ' | '.join(qtypes)
 ret = ''
-for var in variants.variants:
-if var.type.alternate_qtype() == 'QTYPE_QINT':
-promote_int = 'false'
 
 ret += mcgen('''
 
 void visit_type_%(c_name)s(Visitor *v, const char *name, %(c_name)s **obj, 
Error **errp)
 {
 Error *err = NULL;
+uint32_t supported_qtypes = %(supported_qtypes)s;
 
 visit_start_alternate(v, name, (GenericAlternate **)obj, sizeof(**obj),
-  %(promote_int)s, );
+  supported_qtypes, );
 if (err) {
 goto out;
 }
@@ -183,7 +183,7 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
%(c_name)s **obj, Error
 }
 switch ((*obj)->type) {
 ''',
- c_name=c_name(name), promote_int=promote_int)
+ c_name=c_name(name), supported_qtypes=supported_qtypes)
 
 for var in variants.variants:
 ret += mcgen('''
diff --git a/qapi/qapi-visit-core.c b/qapi/qapi-visit-core.c
index 43a09d147d..8d62914393 100644
--- a/qapi/qapi-visit-core.c
+++ b/qapi/qapi-visit-core.c
@@ -106,15 +106,18 @@ void visit_end_list(Visitor *v, void **obj)
 
 void visit_start_alternate(Visitor *v, const char *name,
GenericAlternate **obj, size_t size,
-   bool promote_int, Error **errp)
+   uint32_t supported_qtypes,
+   Error **errp)
 {
 Error *err = NULL;
 
+QEMU_BUILD_BUG_ON(QTYPE__MAX > 32);
+
 assert(obj && size >= sizeof(GenericAlternate));
 assert(!(v->type & VISITOR_OUTPUT) || *obj);
-trace_visit_start_alternate(v, name, obj, size, promote_int);
+trace_visit_start_alternate(v, name, obj, size, supported_qtypes);
 if (v->start_alternate) {
-v->start_alternate(v, name, obj, size, promote_int, );
+v->start_alternate(v, name, obj, size, supported_qtypes, );
 }
 

[Qemu-devel] [PATCH v2 2/3] qapi: Add enum_table[] parameter to start_alternate

[Eduardo Habkost]

The new parameter will be used by the string input visitor to detect
alternate types that can't be parsed unambiguously.

Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* (new patch added to series)
---
 include/qapi/visitor.h   | 10 +-
 include/qapi/visitor-impl.h  |  4 +++-
 scripts/qapi-visit.py| 11 +--
 qapi/qapi-visit-core.c   |  7 +--
 qapi/qapi-clone-visitor.c|  1 +
 qapi/qapi-dealloc-visitor.c  |  1 +
 qapi/qobject-input-visitor.c |  1 +
 qapi/trace-events|  2 +-
 8 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
index 8f5a223714..05e5ca0eb2 100644
--- a/include/qapi/visitor.h
+++ b/include/qapi/visitor.h
@@ -411,13 +411,21 @@ void visit_end_list(Visitor *v, void **list);
  * @supported_qtypes is a bit mask indicating which QTypes are supported
  * by the alternate.
  *
+ * @enum_table contains the enum value lookup table, in case
+ * strings in the input are going to be parsed as enums. Visitors
+ * aren't required to validate string input according to
+ * enum_table, as visit_type_enum() will be called automatically
+ * if (*obj)->type is QTYPE_QSTRING.
+ *
  * If successful, this must be paired with visit_end_alternate() with
  * the same @obj to clean up, even if visiting the contents of the
  * alternate fails.
  */
 void visit_start_alternate(Visitor *v, const char *name,
GenericAlternate **obj, size_t size,
-   uint32_t supported_qtypes, Error **errp);
+   uint32_t supported_qtypes,
+   const char *const enum_table[],
+   Error **errp);
 
 /*
  * Finish visiting an alternate type.
diff --git a/include/qapi/visitor-impl.h b/include/qapi/visitor-impl.h
index 8afcde0f5d..b98370fabb 100644
--- a/include/qapi/visitor-impl.h
+++ b/include/qapi/visitor-impl.h
@@ -71,7 +71,9 @@ struct Visitor
  * optional for output visitors. */
 void (*start_alternate)(Visitor *v, const char *name,
 GenericAlternate **obj, size_t size,
-uint32_t supported_qtypes, Error **errp);
+uint32_t supported_qtypes,
+const char *const enum_table[],
+Error **errp);
 
 /* Optional, needed for dealloc visitor */
 void (*end_alternate)(Visitor *v, void **obj);
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 41c54982e2..2f4dc56918 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -166,6 +166,12 @@ def gen_visit_alternate(name, variants):
 supported_qtypes = ' | '.join(qtypes)
 ret = ''
 
+enum_table = 'NULL'
+for var in variants.variants:
+if isinstance(var.type, QAPISchemaEnumType):
+enum_table = '%s_lookup' % (var.type.c_name())
+break
+
 ret += mcgen('''
 
 void visit_type_%(c_name)s(Visitor *v, const char *name, %(c_name)s **obj, 
Error **errp)
@@ -174,7 +180,7 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
%(c_name)s **obj, Error
 uint32_t supported_qtypes = %(supported_qtypes)s;
 
 visit_start_alternate(v, name, (GenericAlternate **)obj, sizeof(**obj),
-  supported_qtypes, );
+  supported_qtypes, %(enum_table)s, );
 if (err) {
 goto out;
 }
@@ -183,7 +189,8 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
%(c_name)s **obj, Error
 }
 switch ((*obj)->type) {
 ''',
- c_name=c_name(name), supported_qtypes=supported_qtypes)
+ c_name=c_name(name), supported_qtypes=supported_qtypes,
+ enum_table=enum_table)
 
 for var in variants.variants:
 ret += mcgen('''
diff --git a/qapi/qapi-visit-core.c b/qapi/qapi-visit-core.c
index 8d62914393..479aa763c8 100644
--- a/qapi/qapi-visit-core.c
+++ b/qapi/qapi-visit-core.c
@@ -107,6 +107,7 @@ void visit_end_list(Visitor *v, void **obj)
 void visit_start_alternate(Visitor *v, const char *name,
GenericAlternate **obj, size_t size,
uint32_t supported_qtypes,
+   const char *const enum_table[],
Error **errp)
 {
 Error *err = NULL;
@@ -115,9 +116,11 @@ void visit_start_alternate(Visitor *v, const char *name,
 
 assert(obj && size >= sizeof(GenericAlternate));
 assert(!(v->type & VISITOR_OUTPUT) || *obj);
-trace_visit_start_alternate(v, name, obj, size, supported_qtypes);
+trace_visit_start_alternate(v, name, obj, size, supported_qtypes,
+(void *)enum_table);
 if (v->start_alternate) {
-v->start_alternate(v, name, obj, size, supported_qtypes, );
+v->start_alternate(v, name, obj, size, supported_qtypes,
+   enum_table, );
 }
 if 

[Qemu-devel] [PATCH v2 3/3] string-input-visitor: Support alternate types

[Eduardo Habkost]

When parsing alternates from a string, there are some limitations in
what we can do, but it is a valid use case in some situations. We can
support booleans, integer types, and enums.

This will be used to support 'feature=force' in -cpu options, while
keeping 'feature=on|off|true|false' represented as boolean values.

Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* Updated string_input_visitor_new() documentation
  to mention alternate support (Markus Armbruster)
* Detect ambiguous alternates at runtime. Test case included.
* Removed support for integers. We don't need it yet, and
  it would require sorting out the parse_str() mess.
* Change supported_qtypes to uint32_t (Eric Blake)
* Update tests/qapi-schema/qapi-schema-test.out to match
  qapi-schema-test.json updates
  (Eric Blake)
* Code indentation fix (Markus Armbruster)
* Use _abort on test cases instead of g_assert(!err)
  (Markus Armbruster)
---
 include/qapi/string-input-visitor.h |  6 +-
 qapi/string-input-visitor.c | 99 +
 tests/test-string-input-visitor.c   | 76 +
 tests/qapi-schema/qapi-schema-test.json |  8 +++
 tests/qapi-schema/qapi-schema-test.out  |  9 +++
 5 files changed, 187 insertions(+), 11 deletions(-)

diff --git a/include/qapi/string-input-visitor.h 
b/include/qapi/string-input-visitor.h
index 33551340e3..e7f359f225 100644
--- a/include/qapi/string-input-visitor.h
+++ b/include/qapi/string-input-visitor.h
@@ -19,8 +19,12 @@ typedef struct StringInputVisitor StringInputVisitor;
 
 /*
  * The string input visitor does not implement support for visiting
- * QAPI structs, alternates, null, or arbitrary QTypes.  It also
+ * QAPI structs, null, or arbitrary QTypes.  It also
  * requires a non-null list argument to visit_start_list().
+ *
+ * Support for alternates is very limited: only bool and enum
+ * members are supported, and only when the enum members'
+ * representations can't be confused with a bool value.
  */
 Visitor *string_input_visitor_new(const char *str);
 
diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
index c089491c24..e339b88192 100644
--- a/qapi/string-input-visitor.c
+++ b/qapi/string-input-visitor.c
@@ -19,6 +19,7 @@
 #include "qemu/option.h"
 #include "qemu/queue.h"
 #include "qemu/range.h"
+#include "qemu/host-utils.h"
 
 
 struct StringInputVisitor
@@ -278,21 +279,34 @@ static void parse_type_size(Visitor *v, const char *name, 
uint64_t *obj,
 *obj = val;
 }
 
+static int try_parse_bool(const char *s, bool *result)
+{
+if (!strcasecmp(s, "on") ||
+!strcasecmp(s, "yes") ||
+!strcasecmp(s, "true")) {
+if (result) {
+*result = true;
+}
+return 0;
+}
+if (!strcasecmp(s, "off") ||
+!strcasecmp(s, "no") ||
+!strcasecmp(s, "false")) {
+if (result) {
+*result = false;
+}
+return 0;
+}
+
+return -1;
+}
+
 static void parse_type_bool(Visitor *v, const char *name, bool *obj,
 Error **errp)
 {
 StringInputVisitor *siv = to_siv(v);
 
-if (!strcasecmp(siv->string, "on") ||
-!strcasecmp(siv->string, "yes") ||
-!strcasecmp(siv->string, "true")) {
-*obj = true;
-return;
-}
-if (!strcasecmp(siv->string, "off") ||
-!strcasecmp(siv->string, "no") ||
-!strcasecmp(siv->string, "false")) {
-*obj = false;
+if (try_parse_bool(siv->string, obj) == 0) {
 return;
 }
 
@@ -326,6 +340,70 @@ static void parse_type_number(Visitor *v, const char 
*name, double *obj,
 *obj = val;
 }
 
+/*
+ * Check if alternate type string representation is ambiguous and
+ * can't be parsed by StringInputVisitor
+ */
+static bool ambiguous_alternate(uint32_t qtypes, const char *const 
enum_table[])
+{
+uint32_t non_str_qtypes = qtypes & ~(1U << QTYPE_QSTRING);
+
+if ((qtypes & (1U << QTYPE_QSTRING)) && !enum_table && non_str_qtypes) {
+return true;
+}
+
+if (qtypes & (1U << QTYPE_QBOOL)) {
+const char *const *e;
+/*
+ * If the string representation of enum members can be parsed as
+ * booleans, the alternate string representation is ambiguous.
+ */
+for (e = enum_table; e && *e; e++) {
+if (try_parse_bool(*e, NULL) == 0) {
+return true;
+}
+}
+}
+
+return false;
+}
+
+static void start_alternate(Visitor *v, const char *name,
+GenericAlternate **obj, size_t size,
+uint32_t qtypes, const char *const enum_table[],
+Error **errp)
+{
+/*
+ * Enum types are represented as QTYPE_QSTRING, so this is
+ * the default. Actual parsing of the string as an enum is
+ * done by visit_type_(), which is called just
+ * after visit_start_alternate().
+ */
+QType qtype = 

[Qemu-devel] [PATCH v2 0/3] string-input-visitor: Support enum/bool alternate types

[Eduardo Habkost]

v1 was originally part of the following series:

  [PATCH 0/4] x86: Support "-cpu feature=force"

But as I am not sure yet "feature=force" is the right way to go,
I decided to send only the string-input-visitor alternate
support, in case the QAPI maintainers want to merge it anyway.

Changes v1 -> v2:
* Updated string_input_visitor_new() documentation
  to mention alternate support (Markus Armbruster)
* Detect ambiguous alternates at runtime. Test case included.
* Removed support for integers. We don't need it yet, and
  it would require sorting out the parse_str() mess.
* Change supported_qtypes to uint32_t (Eric Blake)
* Replace assert() on all generated visitor functions with a
  single QEMU_BUILD_BUG_ON() on visit_start_alternate()
  (Eric Blake)
* Extra spaces around "|" on generated visitor code
  (Eric Blake)
* Don't use bitops.h and just use (1U << QTYPE_FOO)
  (Markus Armbruster)
* Update tests/qapi-schema/qapi-schema-test.out to match
  qapi-schema-test.json updates
* New patch: qapi: Add enum_table[] parameter to start_alternate
  (needed to detect ambiguous alternates)
* Code indentation fix (Markus Armbruster)

Eduardo Habkost (3):
  visitor: Add 'supported_qtypes' parameter to visit_start_alternate()
  qapi: Add enum_table[] parameter to start_alternate
  string-input-visitor: Support alternate types

 include/qapi/visitor.h  | 13 -
 include/qapi/visitor-impl.h |  4 +-
 scripts/qapi-visit.py   | 17 --
 include/qapi/string-input-visitor.h |  6 +-
 qapi/qapi-visit-core.c  | 12 +++-
 qapi/qapi-clone-visitor.c   |  4 +-
 qapi/qapi-dealloc-visitor.c |  4 +-
 qapi/qobject-input-visitor.c|  7 ++-
 qapi/string-input-visitor.c | 99 +
 tests/test-string-input-visitor.c   | 76 +
 qapi/trace-events   |  2 +-
 tests/qapi-schema/qapi-schema-test.json |  8 +++
 tests/qapi-schema/qapi-schema-test.out  |  9 +++
 13 files changed, 234 insertions(+), 27 deletions(-)

-- 
2.11.0.259.g40922b1

Re: [Qemu-devel] [PATCH] virtio-net: consolidate guest announcement with qemu_announce_self

[Vlad Yasevich]

On 05/02/2017 06:41 AM, Dr. David Alan Gilbert wrote:
> * Vlad Yasevich (vyase...@redhat.com) wrote:
>> On 03/30/2017 11:26 AM, Dr. David Alan Gilbert wrote:
>>> * Vlad Yasevich (vyase...@redhat.com) wrote:
 On 03/30/2017 10:53 AM, Dr. David Alan Gilbert wrote:
> * Vlad Yasevich (vyase...@redhat.com) wrote:
>> On 03/30/2017 04:24 AM, Dr. David Alan Gilbert wrote:
>>> * Vladislav Yasevich (vyase...@redhat.com) wrote:
 virtio announcements seem to run on its own timer with it's own
 repetition loop and are invoked separately from qemu_announce_self.
 This patch consolidates announcements into a single location and
 allows other nics to provide it's own announcement capabilities, if
 necessary.

 This is also usefull in support of exposing qemu_announce_self through
 qmp/hmp.

 Signed-off-by: Vladislav Yasevich 
 ---
  hw/net/virtio-net.c| 30 --
  include/hw/virtio/virtio-net.h |  2 --
  include/net/net.h  |  2 ++
  migration/savevm.c |  6 ++
  4 files changed, 16 insertions(+), 24 deletions(-)

 diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
 index c321680..6e9ce4f 100644
 --- a/hw/net/virtio-net.c
 +++ b/hw/net/virtio-net.c
 @@ -110,14 +110,16 @@ static bool virtio_net_started(VirtIONet *n, 
 uint8_t status)
  (n->status & VIRTIO_NET_S_LINK_UP) && vdev->vm_running;
  }
  
 -static void virtio_net_announce_timer(void *opaque)
 +static void virtio_net_announce(NetClientState *nc)
  {
 -VirtIONet *n = opaque;
 +VirtIONet *n = qemu_get_nic_opaque(nc);
  VirtIODevice *vdev = VIRTIO_DEVICE(n);
  
 -n->announce_counter--;
 -n->status |= VIRTIO_NET_S_ANNOUNCE;
 -virtio_notify_config(vdev);
 +if (virtio_vdev_has_feature(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE) &&
 +virtio_vdev_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) {
 +n->status |= VIRTIO_NET_S_ANNOUNCE;
 +virtio_notify_config(vdev);
 +}
  }
  
  static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
 @@ -427,8 +429,6 @@ static void virtio_net_reset(VirtIODevice *vdev)
  n->nobcast = 0;
  /* multiqueue is disabled by default */
  n->curr_queues = 1;
 -timer_del(n->announce_timer);
 -n->announce_counter = 0;
  n->status &= ~VIRTIO_NET_S_ANNOUNCE;
  
  /* Flush any MAC and VLAN filter table state */
 @@ -868,11 +868,6 @@ static int virtio_net_handle_announce(VirtIONet 
 *n, uint8_t cmd,
  if (cmd == VIRTIO_NET_CTRL_ANNOUNCE_ACK &&
  n->status & VIRTIO_NET_S_ANNOUNCE) {
  n->status &= ~VIRTIO_NET_S_ANNOUNCE;
 -if (n->announce_counter) {
 -timer_mod(n->announce_timer,
 -  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
 -  self_announce_delay(n->announce_counter));
 -}
  return VIRTIO_NET_OK;
  } else {
  return VIRTIO_NET_ERR;
 @@ -1609,12 +1604,6 @@ static int virtio_net_post_load_device(void 
 *opaque, int version_id)
  qemu_get_subqueue(n->nic, i)->link_down = link_down;
  }
  
 -if (virtio_vdev_has_feature(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE) &&
 -virtio_vdev_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) {
 -n->announce_counter = SELF_ANNOUNCE_ROUNDS;
 -timer_mod(n->announce_timer, 
 qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL));
 -}
 -
  return 0;
  }
  
 @@ -1829,6 +1818,7 @@ static NetClientInfo net_virtio_info = {
  .receive = virtio_net_receive,
  .link_status_changed = virtio_net_set_link_status,
  .query_rx_filter = virtio_net_query_rxfilter,
 +.announce = virtio_net_announce,
  };
  
  static bool virtio_net_guest_notifier_pending(VirtIODevice *vdev, int 
 idx)
 @@ -1934,8 +1924,6 @@ static void 
 virtio_net_device_realize(DeviceState *dev, Error **errp)
  qemu_macaddr_default_if_unset(>nic_conf.macaddr);
  memcpy(>mac[0], >nic_conf.macaddr, sizeof(n->mac));
  n->status = VIRTIO_NET_S_LINK_UP;
 -n->announce_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL,
 - virtio_net_announce_timer, n);
  
  if (n->netclient_type) {
  /*
 @@ -1997,8 +1985,6 @@ 

Re: [Qemu-devel] [PATCH v12 02/10] block: Update comments on BDRV_BLOCK_* meanings

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> We had some conflicting documentation: a nice 8-way table that
> described all possible combinations of DATA, ZERO, and
> OFFSET_VALID, contrasted with text that implied that OFFSET_VALID
> always meant raw data could be read directly.  Furthermore, the
> text refers a lot to bs->file, even though the interface was
> updated back in 67a0fd2a to let the driver pass back which BDS (not
> necessarily bs->file).

Not sure about my English skills here, but is this missing a verb? ("to
pass back which BDS...")

> As the 8-way table is the intended
> semantics, simplify the rest of the text to get rid of the
> confusion.
> 
> ALLOCATED is always set by the block layer for convenience (drivers
> do not have to worry about it). RAW is used only internally, but

Just one space after the period? How inconsistent! :-)

> by more than the raw driver.  Document these additional items on
> the driver callback.
> 
> Suggested-by: Max Reitz 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: even more wording tweaks
> v11: reserved for blkdebug half of v10
> v10: new patch
> ---
>  include/block/block.h | 35 +++
>  include/block/block_int.h |  7 +++
>  2 files changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/include/block/block.h b/include/block/block.h
> index 862eb56..c8bec7d 100644
> --- a/include/block/block.h
> +++ b/include/block/block.h
> @@ -120,29 +120,32 @@ typedef struct HDGeometry {
>  #define BDRV_REQUEST_MAX_BYTES (BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS)
> 
>  /*
> - * Allocation status flags
> - * BDRV_BLOCK_DATA: data is read from a file returned by 
> bdrv_get_block_status.
> - * BDRV_BLOCK_ZERO: sectors read as zero
> - * BDRV_BLOCK_OFFSET_VALID: sector stored as raw data in a file returned by
> - *  bdrv_get_block_status.
> + * Allocation status flags for bdrv_get_block_status() and friends.
> + *
> + * Public flags:
> + * BDRV_BLOCK_DATA: allocation for data at offset is tied to this layer
> + * BDRV_BLOCK_ZERO: offset reads as zero
> + * BDRV_BLOCK_OFFSET_VALID: an associated offset exists for accessing raw 
> data
>   * BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
> - *   layer (as opposed to the backing file)
> - * BDRV_BLOCK_RAW: used internally to indicate that the request
> - * was answered by the raw driver and that one
> - * should look in bs->file directly.
> + *   layer (short for DATA || ZERO), set by block layer
>   *
> - * If BDRV_BLOCK_OFFSET_VALID is set, bits 9-62 represent the offset in
> - * bs->file where sector data can be read from as raw data.
> + * Internal flag:
> + * BDRV_BLOCK_RAW: used internally to indicate that the request was
> + * answered by a passthrough driver such as raw and that the

s/passthrough/filter/? But I'm not even sure myself. Well, "passthrough"
is a safe bet, so let's just go with it.

With the commit message fixed or a “no it's fine”:

Reviewed-by: Max Reitz 

> + * block layer should recompute the answer from bs->file.
>   *
> - * DATA == 0 && ZERO == 0 means that data is read from backing_hd if present.
> + * If BDRV_BLOCK_OFFSET_VALID is set, bits 9-62 (BDRV_BLOCK_OFFSET_MASK)
> + * represent the offset in the returned BDS that is allocated for the
> + * corresponding raw data; however, whether that offset actually contains
> + * data also depends on BDRV_BLOCK_DATA and BDRV_BLOCK_ZERO, as follows:
>   *
>   * DATA ZERO OFFSET_VALID
> - *  ttt   sectors read as zero, bs->file is zero at offset
> - *  tft   sectors read as valid from bs->file at offset
> - *  ftt   sectors preallocated, read as zero, bs->file not
> + *  ttt   sectors read as zero, returned file is zero at 
> offset
> + *  tft   sectors read as valid from file at offset
> + *  ftt   sectors preallocated, read as zero, returned file 
> not
>   *necessarily zero at offset
>   *  fft   sectors preallocated but read from backing_hd,
> - *bs->file contains garbage at offset
> + *returned file contains garbage at offset
>   *  ttf   sectors preallocated, read as zero, unknown offset
>   *  tff   sectors read from unknown file or offset
>   *  ftf   not allocated or unknown offset, read as zero
> diff --git a/include/block/block_int.h b/include/block/block_int.h
> index 8773940..1fdfff7 100644
> --- a/include/block/block_int.h
> +++ b/include/block/block_int.h
> @@ -165,6 +165,13 @@ struct BlockDriver {
>  int64_t offset, int count, BdrvRequestFlags flags);
>  int coroutine_fn (*bdrv_co_pdiscard)(BlockDriverState *bs,
>  

Re: [Qemu-devel] [PATCH v2 12/24] numa: add numa_[has_]node_id() wrappers

[Igor Mammedov]

On Fri, 5 May 2017 14:12:26 -0300
Eduardo Habkost  wrote:

> On Fri, May 05, 2017 at 11:06:02AM +0200, Andrew Jones wrote:
> > On Fri, May 05, 2017 at 10:09:18AM +0200, Igor Mammedov wrote:
> > > On Fri, 5 May 2017 11:45:22 +1000
> > > David Gibson  wrote:
> > > 
> > > > On Wed, May 03, 2017 at 02:57:06PM +0200, Igor Mammedov wrote:
> > > > > wrappers should make access to [has]node_id fields more readable
> > > > > 
> > > > > Signed-off-by: Igor Mammedov   
> > > > 
> > > > Reviewed-by: David Gibson 
> > > > 
> > > > Correct, though I'm not sure it actually simplifies things that much.
> > > > Maybe more in future patches, though.
> > > that's what Drew insisted on, and even though I prefer other way around
> > > I won't stall series arguing about styling issues,
> > > so here this patch goes.
> > 
> > My argument in the last review of this series was that references like
> > 
> >  machine->possible_cpus->cpus[cs->cpu_index].props.has_node_id
> > and
> >  machine->possible_cpus->cpus[cs->cpu_index].props.node_id
> > 
> > are quite long, and only differ by 'has_', making it tough to
> > easily recognize.
> 
> If expression length is a problem, we can just use an extra
> variable:
> 
>  CPUArchId *slot = >possible_cpus->cpus[cs->cpu_index];
>  if (slot->props.has_node_id && slot->props.node_id == FOO) ...
> 
> 
> >   But, if nobody, but me, sees value in changing
> > them to
> > 
> >  numa_has_node_id(machine->possible_cpus, cs->cpu_index)
> > and
> >  numa_node_id(machine->possible_cpus, cs->cpu_index)
> > 
> > then I won't insist.
> 
> I don't mind that much, but I still prefer the version without
> the wrappers.
considering 3vs1 for wrapper less variant, I'll return it back.
but respin will have to wait till Tuesday due to holiday over here.

Re: [Qemu-devel] [PATCH v2 10/24] numa: mirror cpu to node mapping in MachineState::possible_cpus

[Igor Mammedov]

On Fri, 5 May 2017 14:04:15 -0300
Eduardo Habkost  wrote:

> On Fri, May 05, 2017 at 02:16:48PM +0200, Igor Mammedov wrote:
> > On Wed, 3 May 2017 12:20:22 -0300
> > Eduardo Habkost  wrote:
> > 
> > > On Wed, May 03, 2017 at 02:57:04PM +0200, Igor Mammedov wrote:
> > > > Introduce machine_set_cpu_numa_node() helper that stores
> > > > node mapping for CPU in MachineState::possible_cpus.
> > > > CPU and node it belongs to is specified by 'props' argument.
> > > > 
> > > > Patch doesn't remove old way of storing mapping in
> > > > numa_info[X].node_cpu as removing it at the same time
> > > > makes patch rather big. Instead it just mirrors mapping
> > > > in possible_cpus and follow up per target patches will
> > > > switch to possible_cpus and numa_info[X].node_cpu will
> > > > be removed once there isn't any users left.
> > > > 
> > > > Signed-off-by: Igor Mammedov 
> > > > Reviewed-by: David Gibson 
> > > > ---
> > > >  include/hw/boards.h |  2 ++
> > > >  hw/core/machine.c   | 68 
> > > > +
> > > >  numa.c  |  8 +++
> > > >  3 files changed, 78 insertions(+)
> > > > 
> > > > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > > > index 5d6af21..1f518a1 100644
> > > > --- a/include/hw/boards.h
> > > > +++ b/include/hw/boards.h
> > > > @@ -42,6 +42,8 @@ bool machine_dump_guest_core(MachineState *machine);
> > > >  bool machine_mem_merge(MachineState *machine);
> > > >  void machine_register_compat_props(MachineState *machine);
> > > >  HotpluggableCPUList *machine_query_hotpluggable_cpus(MachineState 
> > > > *machine);
> > > > +void machine_set_cpu_numa_node(MachineState *machine,
> > > > +   CpuInstanceProperties *props, Error 
> > > > **errp);
> > > >  
> > > >  /**
> > > >   * CPUArchId:
> > > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > > index ada9eea..a63f17b 100644
> > > > --- a/hw/core/machine.c
> > > > +++ b/hw/core/machine.c
> > > > @@ -388,6 +388,74 @@ HotpluggableCPUList 
> > > > *machine_query_hotpluggable_cpus(MachineState *machine)
> > > >  return head;
> > > >  }
> > > >  
> > > > +void machine_set_cpu_numa_node(MachineState *machine,
> > > > +   CpuInstanceProperties *props, Error 
> > > > **errp)  
> > > 
> > > As the semantics of this function aren't trivial, it would be
> > > nice to have a comment explaining what exactly this function do.
> > > 
> > > e.g.:
> > > * make it clear that it could affect multiple CPU slots;
> > > * make it clear what does it mean to have props->has_node_id=false as
> > >   argument (is it really valid?);
> > > * make it clear that it will refuse to change an existing mapping.
> > Will be following comment sufficient?
> > 
> > +/**
> > + * machine_set_cpu_numa_node:
> > + * @machine: machine object to modify
> > + * @props: specifies which cpu objects to assign to
> > + * numa node specified by @props.node_id
> > + * @errp: if an error occurs, a pointer to an area to store the error
> > + *
> > + * Associate NUMA node specified by @props.node_id with cpu slots that
> > + * match socket/core/thread-ids specified by @props. It's recommended to 
> > use
> > + * query-hotpluggable-cpus.props values to specify affected cpu slots,
> > + * which would lead to exact 1:1 mapping of cpu slots to NUMA node.
> > + *
> > + * However for CLI convenience it's possible to pass in subset of 
> > properties,
> > + * which would affect all cpu slots that match it.
> > + * Ex for pc machine:
> > + *-smp 4,cores=2,sockets=2 -numa node,nodeid=0 -numa node,nodeid=1 \
> > + *-numa cpu,node-id=0,socket_id=0 \
> > + *-numa cpu,node-id=1,socket_id=1
> > + * will assign all child cores of socket 0 to node 0 and
> > + * of socket 1 to node 1.
> > + *
> > + * Empty subset is disallowed and function will return with error in this 
> > case.
> > + */
> >  void machine_set_cpu_numa_node(MachineState *machine,
> > CpuInstanceProperties *props, Error **errp)
> 
> Sounds good to me.
> 
> While at it, we could make 'props' const, as it's not going to be
> touched by the function.
sure

Re: [Qemu-devel] [PATCH v12 01/10] qcow2: Use consistent switch indentation

[Max Reitz]

On 04.05.2017 05:07, Eric Blake wrote:
> Fix a couple of inconsistent indentations, before an upcoming
> patch further tweaks the switch statements.  While at it, make
> some tweaks for shorter lines to keep checkpatch happy (best
> viewed with 'git diff -b').
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v12: new patch
> ---
>  block/qcow2-cluster.c  | 32 -
>  block/qcow2-refcount.c | 96 
> ++
>  2 files changed, 65 insertions(+), 63 deletions(-)

[...]

> diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
> index 4efca7e..a5a0076 100644
> --- a/block/qcow2-refcount.c
> +++ b/block/qcow2-refcount.c
> @@ -1117,70 +1117,72 @@ int qcow2_update_snapshot_refcount(BlockDriverState 
> *bs,
>  goto fail;
>  }
> 
> -for(j = 0; j < s->l2_size; j++) {
> +for (j = 0; j < s->l2_size; j++) {
>  uint64_t cluster_index;
> +uint64_t offset_masked;
> 
>  offset = be64_to_cpu(l2_table[j]);
>  old_offset = offset;
> +offset_masked = offset & L2E_OFFSET_MASK;

I'd rather rename "offset" to "entry" (or "l2_entry") and name this just
"offset". Much less confusing.

Also, I really wouldn't mind splitting the non-indentation changes off
into their own patch.

Tentative

Reviewed-by: Max Reitz 

>  offset &= ~QCOW_OFLAG_COPIED;
> 
>  switch (qcow2_get_cluster_type(offset)) {
> -case QCOW2_CLUSTER_COMPRESSED:
> -nb_csectors = ((offset >> s->csize_shift) &
> -   s->csize_mask) + 1;
> -if (addend != 0) {
> -ret = update_refcount(bs,
> -(offset & s->cluster_offset_mask) & ~511,
> -nb_csectors * 512, abs(addend), addend < 0,
> -QCOW2_DISCARD_SNAPSHOT);
> -if (ret < 0) {
> -goto fail;
> -}
> -}
> -/* compressed clusters are never modified */
> -refcount = 2;
> -break;
> -
> -case QCOW2_CLUSTER_NORMAL:
> -case QCOW2_CLUSTER_ZERO:
> -if (offset_into_cluster(s, offset & 
> L2E_OFFSET_MASK)) {
> -qcow2_signal_corruption(bs, true, -1, -1, "Data "
> -"cluster offset %#llx "
> -"unaligned (L2 offset: 
> %#"
> -PRIx64 ", L2 index: 
> %#x)",
> -offset & L2E_OFFSET_MASK,
> -l2_offset, j);
> -ret = -EIO;
> +case QCOW2_CLUSTER_COMPRESSED:
> +nb_csectors = ((offset >> s->csize_shift) &
> +   s->csize_mask) + 1;
> +if (addend != 0) {
> +ret = update_refcount(bs,
> +(offset & s->cluster_offset_mask) & ~511,
> +nb_csectors * 512, abs(addend), addend < 0,
> +QCOW2_DISCARD_SNAPSHOT);
> +if (ret < 0) {
>  goto fail;
>  }
> +}
> +/* compressed clusters are never modified */
> +refcount = 2;
> +break;
> 
> -cluster_index = (offset & L2E_OFFSET_MASK) >> 
> s->cluster_bits;
> -if (!cluster_index) {
> -/* unallocated */
> -refcount = 0;
> -break;
> -}
> -if (addend != 0) {
> -ret = qcow2_update_cluster_refcount(bs,
> +case QCOW2_CLUSTER_NORMAL:
> +case QCOW2_CLUSTER_ZERO:
> +if (offset_into_cluster(s, offset_masked)) {
> +qcow2_signal_corruption(bs, true, -1, -1, "Data "
> +"cluster offset %#" PRIx64
> +" unaligned (L2 offset: %#"
> +PRIx64 ", L2 index: %#x)",
> +offset_masked,
> +l2_offset, j);
> +ret = -EIO;
> +goto fail;
> +}
> +
> +cluster_index = offset_masked >> 

[Qemu-devel] [PATCH v6 4/5] shutdown: Preserve shutdown cause through replay

[Eric Blake]

With the recent addition of ShutdownCause, we want to be able to pass
a cause through any shutdown request, and then faithfully replay that
cause when later replaying the same sequence.  The easiest way is to
expand the reply event mechanism to track a series of values for
EVENT_SHUTDOWN, one corresponding to each value of ShutdownCause.

We are free to change the replay stream as needed, since there are
already no guarantees about being able to use a replay stream by
any other version of qemu than the one that generated it.

Signed-off-by: Eric Blake 

---
v6: new patch
---
 include/sysemu/replay.h  |  3 ++-
 include/sysemu/sysemu.h  |  1 +
 replay/replay-internal.h |  3 ++-
 vl.c |  3 +--
 replay/replay.c  | 10 +-
 5 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index f1c0712..fa14d0e 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -13,6 +13,7 @@
  */

 #include "qapi-types.h"
+#include "sysemu.h"

 /* replay clock kinds */
 enum ReplayClockKind {
@@ -98,7 +99,7 @@ int64_t replay_read_clock(ReplayClockKind kind);
 /* Events */

 /*! Called when qemu shutdown is requested. */
-void replay_shutdown_request(void);
+void replay_shutdown_request(ShutdownCause cause);
 /*! Should be called at check points in the execution.
 These check points are skipped, if they were not met.
 Saves checkpoint in the SAVE mode and validates in the PLAY mode.
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 89d0e3e..e6d5e5f 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -50,6 +50,7 @@ enum ShutdownCause {
  turns that into a shutdown */
 SHUTDOWN_CAUSE_GUEST_PANIC,   /* Guest panicked, and command line turns
  that into a shutdown */
+SHUTDOWN_CAUSE__MAX,
 };

 void vm_start(void);
diff --git a/replay/replay-internal.h b/replay/replay-internal.h
index ed66ed8..3ebb199 100644
--- a/replay/replay-internal.h
+++ b/replay/replay-internal.h
@@ -22,8 +22,9 @@ enum ReplayEvents {
 EVENT_EXCEPTION,
 /* for async events */
 EVENT_ASYNC,
-/* for shutdown request */
+/* for shutdown requests, range allows recovery of ShutdownCause */
 EVENT_SHUTDOWN,
+EVENT_SHUTDOWN_LAST = EVENT_SHUTDOWN + SHUTDOWN_CAUSE__MAX,
 /* for character device write event */
 EVENT_CHAR_WRITE,
 /* for character device read all event */
diff --git a/vl.c b/vl.c
index 9579d5f..0b73437 100644
--- a/vl.c
+++ b/vl.c
@@ -1821,8 +1821,7 @@ void qemu_system_killed(int signal, pid_t pid)
 void qemu_system_shutdown_request(ShutdownCause reason)
 {
 trace_qemu_system_shutdown_request(reason);
-/* FIXME - add a parameter to let replay preserve reason */
-replay_shutdown_request();
+replay_shutdown_request(reason);
 shutdown_requested = reason;
 qemu_notify_event();
 }
diff --git a/replay/replay.c b/replay/replay.c
index 604fa4f..ff58a5a 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -49,10 +49,10 @@ bool replay_next_event_is(int event)
 res = true;
 }
 switch (replay_state.data_kind) {
-case EVENT_SHUTDOWN:
+case EVENT_SHUTDOWN ... EVENT_SHUTDOWN_LAST:
 replay_finish_event();
-/* FIXME - store actual reason */
-qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_ERROR);
+qemu_system_shutdown_request(replay_state.data_kind -
+ EVENT_SHUTDOWN);
 break;
 default:
 /* clock, time_t, checkpoint and other events */
@@ -171,11 +171,11 @@ bool replay_has_interrupt(void)
 return res;
 }

-void replay_shutdown_request(void)
+void replay_shutdown_request(ShutdownCause cause)
 {
 if (replay_mode == REPLAY_MODE_RECORD) {
 replay_mutex_lock();
-replay_put_event(EVENT_SHUTDOWN);
+replay_put_event(EVENT_SHUTDOWN + cause);
 replay_mutex_unlock();
 }
 }
-- 
2.9.3

[Qemu-devel] [PATCH v6 5/5] shutdown: Expose bool cause in SHUTDOWN and RESET events

[Eric Blake]

Libvirt would like to be able to distinguish between a SHUTDOWN
event triggered solely by guest request and one triggered by a
SIGTERM or other action on the host.  While qemu_kill_report() was
already able to give different output to stderr based on whether a
shutdown was triggered by a host signal (but NOT by a host UI event,
such as clicking the X on the window), that information was then
lost to management.  The previous patches improved things to use an
enum throughout all callsites, so now we have something ready to
expose through QMP.

Note that for now, the decision was to expose ONLY a boolean,
rather than promoting ShutdownCause to a QAPI enum; this is because
libvirt has not expressed an interest in anything finer-grained.
We can still add additional details, in a backwards-compatible
manner, if a need later arises (if the addition happens before 2.10,
we can replace the bool with an enum; otherwise, the enum will have
to be in addition to the bool).

Update expected iotest outputs to match the new data (complete
coverage of the affected tests is obtained by -raw, -qcow2, and -nbd).

Here is output from 'virsh qemu-monitor-event --loop' with the
patch installed:

event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
event STOP at 1492639680.732116 for domain fedora_13: 
event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}

Note that libvirt runs qemu with -no-quit: the first SHUTDOWN event
was triggered by an action I took directly in the guest (shutdown -h),
at which point qemu stops the vcpus and waits for libvirt to do any
final cleanups; the second SHUTDOWN event is the result of libvirt
sending SIGTERM now that it has completed cleanup.

See also https://bugzilla.redhat.com/1384007

Signed-off-by: Eric Blake 

---
v6: split out from 'shutdown: Add source information to SHUTDOWN and RESET'
---
 qapi/event.json| 17 +
 vl.c   |  6 --
 tests/qemu-iotests/071.out |  4 ++--
 tests/qemu-iotests/081.out |  2 +-
 tests/qemu-iotests/087.out | 12 ++--
 tests/qemu-iotests/094.out |  2 +-
 tests/qemu-iotests/117.out |  2 +-
 tests/qemu-iotests/119.out |  2 +-
 tests/qemu-iotests/120.out |  2 +-
 tests/qemu-iotests/140.out |  2 +-
 tests/qemu-iotests/143.out |  2 +-
 tests/qemu-iotests/156.out |  2 +-
 12 files changed, 33 insertions(+), 22 deletions(-)

diff --git a/qapi/event.json b/qapi/event.json
index e80f3f4..6d22b02 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -10,6 +10,10 @@
 # Emitted when the virtual machine has shut down, indicating that qemu is
 # about to exit.
 #
+# @guest: If true, the shutdown was triggered by a guest request (such as
+# a guest-initiated ACPI shutdown request or other hardware-specific action)
+# rather than a host request (such as sending qemu a SIGINT). (since 2.10)
+#
 # Note: If the command-line option "-no-shutdown" has been specified, qemu will
 # not exit, and a STOP event will eventually follow the SHUTDOWN event
 #
@@ -17,11 +21,11 @@
 #
 # Example:
 #
-# <- { "event": "SHUTDOWN",
+# <- { "event": "SHUTDOWN", "data": { "guest": true },
 #  "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
 #
 ##
-{ 'event': 'SHUTDOWN' }
+{ 'event': 'SHUTDOWN', 'data': { 'guest': 'bool' } }

 ##
 # @POWERDOWN:
@@ -44,15 +48,20 @@
 #
 # Emitted when the virtual machine is reset
 #
+# @guest: If true, the reset was triggered by a guest request (such as
+# a guest-initiated ACPI reboot request or other hardware-specific action)
+# rather than a host request (such as the QMP command system_reset).
+# (since 2.10)
+#
 # Since: 0.12.0
 #
 # Example:
 #
-# <- { "event": "RESET",
+# <- { "event": "RESET", "data": { "guest": false },
 #  "timestamp": { "seconds": 1267041653, "microseconds": 9518 } }
 #
 ##
-{ 'event': 'RESET' }
+{ 'event': 'RESET', 'data': { 'guest': 'bool' } }

 ##
 # @STOP:
diff --git a/vl.c b/vl.c
index 0b73437..60a8526 100644
--- a/vl.c
+++ b/vl.c
@@ -1707,7 +1707,8 @@ void qemu_system_reset(bool report, ShutdownCause reason)
 }
 if (report) {
 assert(reason);
-qapi_event_send_reset(_abort);
+qapi_event_send_reset(reason >= SHUTDOWN_CAUSE_GUEST_SHUTDOWN,
+  _abort);
 }
 cpu_synchronize_all_post_reset();
 }
@@ -1864,7 +1865,8 @@ static bool main_loop_should_exit(void)
 request = qemu_shutdown_requested();
 if (request) {
 qemu_kill_report();
-qapi_event_send_shutdown(_abort);
+qapi_event_send_shutdown(request >= SHUTDOWN_CAUSE_GUEST_SHUTDOWN,
+ _abort);
 if (no_shutdown) {
 vm_stop(RUN_STATE_SHUTDOWN);
 } else {
diff --git a/tests/qemu-iotests/071.out b/tests/qemu-iotests/071.out
index dd879f1..1d5e28d 100644
--- a/tests/qemu-iotests/071.out
+++ b/tests/qemu-iotests/071.out
@@ -46,7 +46,7 @@ QMP_VERSION
 read failed: Input/output error
 {"return": ""}
 {"return": 

[Qemu-devel] [PATCH v6 1/5] shutdown: Simplify shutdown_signal

[Eric Blake]

There is no signal 0 (kill(pid, 0) has special semantics to probe whether
a process is alive), rather than actually sending a signal 0).  So we
can use the simpler 0, instead of -1, for our sentinel of whether a
shutdown request due to a signal has happened.

Suggested-by: Markus Armbruster 
Signed-off-by: Eric Blake 
Reviewed-by: Markus Armbruster 

---
v4-v6: no change
v3: new patch
---
 vl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/vl.c b/vl.c
index 42d4bce..f22a3ac 100644
--- a/vl.c
+++ b/vl.c
@@ -1598,7 +1598,7 @@ void vm_state_notify(int running, RunState state)
 }

 static int reset_requested;
-static int shutdown_requested, shutdown_signal = -1;
+static int shutdown_requested, shutdown_signal;
 static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
@@ -1629,7 +1629,7 @@ static int qemu_shutdown_requested(void)

 static void qemu_kill_report(void)
 {
-if (!qtest_driver() && shutdown_signal != -1) {
+if (!qtest_driver() && shutdown_signal) {
 if (shutdown_pid == 0) {
 /* This happens for eg ^C at the terminal, so it's worth
  * avoiding printing an odd message in that case.
@@ -1643,7 +1643,7 @@ static void qemu_kill_report(void)
  shutdown_cmd ? shutdown_cmd : "");
 g_free(shutdown_cmd);
 }
-shutdown_signal = -1;
+shutdown_signal = 0;
 }
 }

-- 
2.9.3

[Qemu-devel] [PATCH v6 3/5] shutdown: Add source information to SHUTDOWN and RESET

[Eric Blake]

Time to wire up all the call sites that request a shutdown or
reset to use the enum added in the previous patch.

It would have been less churn to keep the common case with no
arguments as meaning guest-triggered, and only modified the
host-triggered code paths, via a wrapper function, but then we'd
still have to audit that I didn't miss any host-triggered spots;
changing the signature forces us to double-check that I correctly
categorized all callers.

Since command line options can change whether a guest reset request
causes an actual reset vs. a shutdown, it's easy to also add the
information to reset requests.

Replay adds a FIXME to preserve the cause across the replay stream,
that will be tackled in the next patch.

Signed-off-by: Eric Blake 
Acked-by: David Gibson  [ppc parts]
Reviewed-by: Mark Cave-Ayland  [SPARC part]

---
v6: defer event additions to later, add reviews of unchanged portions
v5: drop accidental addition of unrelated files
v4: s/ShutdownType/ShutdownCause/, no thanks to mingw header pollution
v3: retitle again, fix qemu-iotests, use enum rather than raw bool
in all callers
v2: retitle (was "event: Add signal information to SHUTDOWN"),
completely rework to post bool based on whether it is guest-initiated
v1: initial submission, exposing just Unix signals from host
---
 include/sysemu/sysemu.h |  4 ++--
 vl.c| 17 -
 hw/acpi/core.c  |  4 ++--
 hw/arm/highbank.c   |  4 ++--
 hw/arm/integratorcp.c   |  2 +-
 hw/arm/musicpal.c   |  2 +-
 hw/arm/omap1.c  | 10 ++
 hw/arm/omap2.c  |  2 +-
 hw/arm/spitz.c  |  2 +-
 hw/arm/stellaris.c  |  2 +-
 hw/arm/tosa.c   |  2 +-
 hw/i386/pc.c|  2 +-
 hw/i386/xen/xen-hvm.c   |  2 +-
 hw/input/pckbd.c|  4 ++--
 hw/ipmi/ipmi.c  |  4 ++--
 hw/isa/lpc_ich9.c   |  2 +-
 hw/mips/boston.c|  2 +-
 hw/mips/mips_malta.c|  2 +-
 hw/mips/mips_r4k.c  |  4 ++--
 hw/misc/arm_sysctl.c|  8 
 hw/misc/cbus.c  |  2 +-
 hw/misc/macio/cuda.c|  4 ++--
 hw/misc/slavio_misc.c   |  4 ++--
 hw/misc/zynq_slcr.c |  2 +-
 hw/pci-host/apb.c   |  4 ++--
 hw/pci-host/bonito.c|  2 +-
 hw/pci-host/piix.c  |  2 +-
 hw/ppc/e500.c   |  2 +-
 hw/ppc/mpc8544_guts.c   |  2 +-
 hw/ppc/ppc.c|  2 +-
 hw/ppc/ppc405_uc.c  |  2 +-
 hw/ppc/spapr_hcall.c|  2 +-
 hw/ppc/spapr_rtas.c |  4 ++--
 hw/s390x/ipl.c  |  2 +-
 hw/sh4/r2d.c|  2 +-
 hw/timer/etraxfs_timer.c|  2 +-
 hw/timer/m48t59.c   |  4 ++--
 hw/timer/milkymist-sysctl.c |  4 ++--
 hw/timer/pxa2xx_timer.c |  2 +-
 hw/watchdog/watchdog.c  |  2 +-
 hw/xenpv/xen_domainbuild.c  |  2 +-
 hw/xtensa/xtfpga.c  |  2 +-
 kvm-all.c   |  6 +++---
 os-win32.c  |  2 +-
 qmp.c   |  4 ++--
 replay/replay.c |  3 ++-
 target/alpha/sys_helper.c   |  4 ++--
 target/arm/psci.c   |  4 ++--
 target/i386/excp_helper.c   |  2 +-
 target/i386/hax-all.c   |  6 +++---
 target/i386/helper.c|  2 +-
 target/i386/kvm.c   |  2 +-
 target/s390x/helper.c   |  2 +-
 target/s390x/kvm.c  |  4 ++--
 target/s390x/misc_helper.c  |  4 ++--
 target/sparc/int32_helper.c |  2 +-
 ui/sdl.c|  2 +-
 ui/sdl2.c   |  4 ++--
 trace-events|  2 +-
 ui/cocoa.m  |  2 +-
 60 files changed, 98 insertions(+), 96 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index e4da9d4..89d0e3e 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -65,13 +65,13 @@ typedef enum WakeupReason {
 QEMU_WAKEUP_REASON_OTHER,
 } WakeupReason;

-void qemu_system_reset_request(void);
+void qemu_system_reset_request(ShutdownCause reason);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
 void qemu_system_wakeup_request(WakeupReason reason);
 void qemu_system_wakeup_enable(WakeupReason reason, bool enabled);
 void qemu_register_wakeup_notifier(Notifier *notifier);
-void qemu_system_shutdown_request(void);
+void qemu_system_shutdown_request(ShutdownCause reason);
 void qemu_system_powerdown_request(void);
 void qemu_register_powerdown_notifier(Notifier *notifier);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index 6069fb2..9579d5f 100644
--- a/vl.c
+++ b/vl.c
@@ -1725,7 +1725,7 @@ void qemu_system_guest_panicked(GuestPanicInformation 
*info)
 if (!no_shutdown) {
 qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_POWEROFF,
!!info, info, _abort);
-qemu_system_shutdown_request();
+

[Qemu-devel] [PATCH v6 0/5] event: Add source information to SHUTDOWN

[Eric Blake]

v2 was here:
https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg03185.html
v3 and v4 were dead on arrival
v5 was here:
https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05564.html

Since then:
- rework the enum to be internal only
- add a 'none' slot to the enum, so that we are back to comparison
to 0 rather than -1 as the no-request-yet state
- drop the RFC patch that would expose the reasons through QAPI (Dan's
take, at least on IRC, is that even with finer-grained reasons from
qemu, the most libvirt would do is log the reason and then still just
expose a boolean higher up).  We can revive that patch if desired, but
doing so also implies adding a 'query-shutdown' command, and I didn't
think it was worth it for now (no need to over-engineer until we know
we have a client that wants it)
- fix replay to preserve status
- split the patches slightly differently, so that internal wiring and
event additions are separated

Eric Blake (5):
  shutdown: Simplify shutdown_signal
  shutdown: Prepare for use of an enum in reset/shutdown_request
  shutdown: Add source information to SHUTDOWN and RESET
  shutdown: Preserve shutdown cause through replay
  shutdown: Expose bool cause in SHUTDOWN and RESET events

 qapi/event.json | 17 ---
 include/sysemu/replay.h |  3 +-
 include/sysemu/sysemu.h | 27 ++
 replay/replay-internal.h|  3 +-
 vl.c| 69 +++--
 hw/acpi/core.c  |  4 +--
 hw/arm/highbank.c   |  4 +--
 hw/arm/integratorcp.c   |  2 +-
 hw/arm/musicpal.c   |  2 +-
 hw/arm/omap1.c  | 10 ---
 hw/arm/omap2.c  |  2 +-
 hw/arm/spitz.c  |  2 +-
 hw/arm/stellaris.c  |  2 +-
 hw/arm/tosa.c   |  2 +-
 hw/i386/pc.c|  2 +-
 hw/i386/xen/xen-hvm.c   |  9 --
 hw/input/pckbd.c|  4 +--
 hw/ipmi/ipmi.c  |  4 +--
 hw/isa/lpc_ich9.c   |  2 +-
 hw/mips/boston.c|  2 +-
 hw/mips/mips_malta.c|  2 +-
 hw/mips/mips_r4k.c  |  4 +--
 hw/misc/arm_sysctl.c|  8 +++---
 hw/misc/cbus.c  |  2 +-
 hw/misc/macio/cuda.c|  4 +--
 hw/misc/slavio_misc.c   |  4 +--
 hw/misc/zynq_slcr.c |  2 +-
 hw/pci-host/apb.c   |  4 +--
 hw/pci-host/bonito.c|  2 +-
 hw/pci-host/piix.c  |  2 +-
 hw/ppc/e500.c   |  2 +-
 hw/ppc/mpc8544_guts.c   |  2 +-
 hw/ppc/ppc.c|  2 +-
 hw/ppc/ppc405_uc.c  |  2 +-
 hw/ppc/spapr_hcall.c|  2 +-
 hw/ppc/spapr_rtas.c |  4 +--
 hw/s390x/ipl.c  |  2 +-
 hw/sh4/r2d.c|  2 +-
 hw/timer/etraxfs_timer.c|  2 +-
 hw/timer/m48t59.c   |  4 +--
 hw/timer/milkymist-sysctl.c |  4 +--
 hw/timer/pxa2xx_timer.c |  2 +-
 hw/watchdog/watchdog.c  |  2 +-
 hw/xenpv/xen_domainbuild.c  |  2 +-
 hw/xtensa/xtfpga.c  |  2 +-
 kvm-all.c   |  6 ++--
 migration/colo.c|  2 +-
 migration/savevm.c  |  2 +-
 os-win32.c  |  2 +-
 qmp.c   |  4 +--
 replay/replay.c |  9 +++---
 target/alpha/sys_helper.c   |  4 +--
 target/arm/psci.c   |  4 +--
 target/i386/excp_helper.c   |  2 +-
 target/i386/hax-all.c   |  6 ++--
 target/i386/helper.c|  2 +-
 target/i386/kvm.c   |  2 +-
 target/s390x/helper.c   |  2 +-
 target/s390x/kvm.c  |  4 +--
 target/s390x/misc_helper.c  |  4 +--
 target/sparc/int32_helper.c |  2 +-
 ui/sdl.c|  2 +-
 ui/sdl2.c   |  4 +--
 tests/qemu-iotests/071.out  |  4 +--
 tests/qemu-iotests/081.out  |  2 +-
 tests/qemu-iotests/087.out  | 12 
 tests/qemu-iotests/094.out  |  2 +-
 tests/qemu-iotests/117.out  |  2 +-
 tests/qemu-iotests/119.out  |  2 +-
 tests/qemu-iotests/120.out  |  2 +-
 tests/qemu-iotests/140.out  |  2 +-
 tests/qemu-iotests/143.out  |  2 +-
 tests/qemu-iotests/156.out  |  2 +-
 trace-events|  2 +-
 ui/cocoa.m  |  2 +-
 75 files changed, 194 insertions(+), 147 deletions(-)

-- 
2.9.3

[Qemu-devel] [PATCH v6 2/5] shutdown: Prepare for use of an enum in reset/shutdown_request

[Eric Blake]

We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is to make that value track the reason,
rather than its current 0/1 contents.

Since command-line options control whether a reset request is turned
into a shutdown request instead, the same treatment is given to
reset_requested.

This patch adds an internal enum ShutdownCause that describes reasons
that a shutdown can be requested, and changes qemu_system_reset() to
pass the reason through, although for now it is not reported.  The
enum could be exported via QAPI at a later date, if deemed necessary,
but for now, there has not been a request to expose that much detail
to end clients.

For now, we only populate the reason with HOST_ERROR, along with FIXME
comments that describe our plans for how to pass an actual correct
reason.  The next patches will then actually wire things up to modify
events to report data based on the reason, and to pass the correct enum
value in from various call-sites that can trigger a reset/shutdown (big
enough that it was worth splitting from this patch).

Signed-off-by: Eric Blake 

---
v6: make ShutdownCause internal-only, add SHUTDOWN_CAUSE_NONE so that
comparison to 0 still works, tweak initial FIXME values
v5: no change
v4: s/ShutdownType/ShutdownCause/, no thanks to mingw header pollution
v3: new patch
---
 include/sysemu/sysemu.h | 22 ++---
 vl.c| 51 +++--
 hw/i386/xen/xen-hvm.c   |  7 +--
 migration/colo.c|  2 +-
 migration/savevm.c  |  2 +-
 5 files changed, 58 insertions(+), 26 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 16175f7..e4da9d4 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -36,6 +36,22 @@ void vm_state_notify(int running, RunState state);
 #define VMRESET_SILENT   false
 #define VMRESET_REPORT   true

+/* Enumeration of various causes for shutdown. */
+typedef enum ShutdownCause ShutdownCause;
+enum ShutdownCause {
+SHUTDOWN_CAUSE_NONE,  /* No shutdown requested yet */
+SHUTDOWN_CAUSE_HOST_QMP,  /* Reaction to a QMP command, like 'quit' */
+SHUTDOWN_CAUSE_HOST_SIGNAL,   /* Reaction to a signal, such as SIGINT */
+SHUTDOWN_CAUSE_HOST_UI,   /* Reaction to UI event, like window close */
+SHUTDOWN_CAUSE_HOST_ERROR,/* An error prevents further use of guest */
+SHUTDOWN_CAUSE_GUEST_SHUTDOWN,/* Guest requested shutdown, such as via
+ ACPI or other hardware-specific means */
+SHUTDOWN_CAUSE_GUEST_RESET,   /* Guest requested reset, and command line
+ turns that into a shutdown */
+SHUTDOWN_CAUSE_GUEST_PANIC,   /* Guest panicked, and command line turns
+ that into a shutdown */
+};
+
 void vm_start(void);
 int vm_prepare_start(void);
 int vm_stop(RunState state);
@@ -62,10 +78,10 @@ void qemu_system_debug_request(void);
 void qemu_system_vmstop_request(RunState reason);
 void qemu_system_vmstop_request_prepare(void);
 bool qemu_vmstop_requested(RunState *r);
-int qemu_shutdown_requested_get(void);
-int qemu_reset_requested_get(void);
+ShutdownCause qemu_shutdown_requested_get(void);
+ShutdownCause qemu_reset_requested_get(void);
 void qemu_system_killed(int signal, pid_t pid);
-void qemu_system_reset(bool report);
+void qemu_system_reset(bool report, ShutdownCause reason);
 void qemu_system_guest_panicked(GuestPanicInformation *info);
 size_t qemu_target_page_size(void);

diff --git a/vl.c b/vl.c
index f22a3ac..6069fb2 100644
--- a/vl.c
+++ b/vl.c
@@ -1597,8 +1597,9 @@ void vm_state_notify(int running, RunState state)
 }
 }

-static int reset_requested;
-static int shutdown_requested, shutdown_signal;
+static ShutdownCause reset_requested;
+static ShutdownCause shutdown_requested;
+static int shutdown_signal;
 static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
@@ -1612,19 +1613,19 @@ static NotifierList wakeup_notifiers =
 NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
 static uint32_t wakeup_reason_mask = ~(1 << QEMU_WAKEUP_REASON_NONE);

-int qemu_shutdown_requested_get(void)
+ShutdownCause qemu_shutdown_requested_get(void)
 {
 return shutdown_requested;
 }

-int qemu_reset_requested_get(void)
+ShutdownCause qemu_reset_requested_get(void)
 {
 return reset_requested;
 }

 static int qemu_shutdown_requested(void)
 {
-return atomic_xchg(_requested, 0);
+return atomic_xchg(_requested, SHUTDOWN_CAUSE_NONE);
 }

 static void qemu_kill_report(void)
@@ -1647,14 +1648,14 @@ static void qemu_kill_report(void)
 }
 }

-static int qemu_reset_requested(void)
+static ShutdownCause 

Re: [Qemu-devel] [PATCH] Revert "Change net/socket.c to use socket_*() functions" again

[no-reply]

Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH] Revert "Change net/socket.c to use socket_*() 
functions" again
Message-id: 20170505162305.15763-1-berra...@redhat.com

=== 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

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
 - [tag update]  patchew/20170504173745.27414-1-ebl...@redhat.com -> 
patchew/20170504173745.27414-1-ebl...@redhat.com
Switched to a new branch 'test'
89f6b9d Revert "Change net/socket.c to use socket_*() functions" again

=== OUTPUT BEGIN ===
Checking PATCH 1/1: Revert "Change net/socket.c to use socket_*() functions" 
again...
ERROR: braces {} are necessary for all arms of this statement
#56: FILE: net/socket.c:495:
+if (parse_host_port(, host_str) < 0)
[...]

ERROR: braces {} are necessary for all arms of this statement
#159: FILE: net/socket.c:540:
+if (parse_host_port(, host_str) < 0)
[...]

ERROR: space required before the open parenthesis '('
#172: FILE: net/socket.c:551:
+for(;;) {

ERROR: braces {} are necessary for all arms of this statement
#192: FILE: net/socket.c:571:
+if (!s)
[...]

total: 4 errors, 0 warnings, 162 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...@freelists.org

Re: [Qemu-devel] [PATCH] block: Simplify BDRV_BLOCK_RAW recursion

[Max Reitz]

On 04.05.2017 19:37, Eric Blake wrote:
> Since we are already in coroutine context during the body of
> bdrv_co_get_block_status(), we can shave off a few layers of
> wrappers when recursing to query the protocol when a format driver
> returned BDRV_BLOCK_RAW.
> 
> Note that we are already using the correct recursion later on in
> the same function, when probing whether the protocol layer is sparse
> in order to find out if we can add BDRV_BLOCK_ZERO to an existing
> BDRV_BLOCK_DATA|BDRV_BLOCK_OFFSET_VALID.
> 
> Signed-off-by: Eric Blake 
> ---
>  block/io.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 4/4] x86: Support feature=force on the command-line

[Eduardo Habkost]

On Thu, May 04, 2017 at 12:16:38PM +0200, Kashyap Chamarthy wrote:
> On Tue, May 02, 2017 at 05:31:15PM -0300, Eduardo Habkost wrote:
> 
> Hi,
> 
> Yet to try this series, a small question in-line.
> 
> > Introduce a new CPUFeatureSetting QAPI data type, and use it to support
> > feature=force on -cpu.
> > 
> > Signed-off-by: Eduardo Habkost 
[...]
> > @@ -336,5 +340,13 @@ int main(int argc, char **argv)
> >   "-machine accel=kvm:tcg -cpu max,mmx=off",
> >   1, 0, "EDX", 23, false);
> >  
> > +{
> > +FeatureTestArgs *a;
> > +a = add_feature_test("x86/cpuid/features/monitor-force",
> > + "-machine accel=kvm:tcg -cpu 486,monitor=force",
> 
> Following your above test example, should the 'force' boolean also work
> (understood: only for testing / debugging) as below, for a recognized
> CPUID flag, taking the example of 'INVPCID'?
> 
>   $ qemu-system-x86_64 [...] -cpu Haswell-noTSX,invpcid=force [...]

This would be valid syntax and would enable invpcid on CPUID,
yes. But on most cases this means you will get a broken VCPU
because the host won't virtualize the feature properly (if it
did, the feature would be reported as available in
GET_SUPPORTED_CPUID and "feature=on" would already work).

-- 
Eduardo

[Qemu-devel] [PATCH 08/10] s390x/css: add ORB to SubchDev

[Halil Pasic]

Since we are going to need a migration compatibility breaking change to
activate ChannelSubSys migration let us use the opportunity to introduce
ORB to the SubchDev before that (otherwise we would need separate
handling e.g. a compat property).

The ORB will be useful for implementing IDA, or async handling of
subchannel work.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 hw/s390x/css.c | 35 +++
 include/hw/s390x/css.h |  1 +
 2 files changed, 36 insertions(+)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 94338b2..d9a0fb9 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -163,6 +163,36 @@ static const VMStateDescription vmstate_sense_id = {
 }
 };
 
+static const VMStateDescription vmstate_orb = {
+.name = "s390_orb",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(intparm, ORB),
+VMSTATE_UINT16(ctrl0, ORB),
+VMSTATE_UINT8(lpm, ORB),
+VMSTATE_UINT8(ctrl1, ORB),
+VMSTATE_UINT32(cpa, ORB),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static bool vmstate_schdev_orb_needed(void *opaque)
+{
+return css_migration_enabled();
+}
+
+static const VMStateDescription vmstate_schdev_orb = {
+.name = "s390_subch_dev/orb",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = vmstate_schdev_orb_needed,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT(orb, SubchDev, 1, vmstate_orb, ORB),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static int subch_dev_post_load(void *opaque, int version_id);
 static void subch_dev_pre_save(void *opaque);
 
@@ -187,6 +217,10 @@ const VMStateDescription vmstate_subch_dev = {
 VMSTATE_BOOL(ccw_fmt_1, SubchDev),
 VMSTATE_UINT8(ccw_no_data_cnt, SubchDev),
 VMSTATE_END_OF_LIST()
+},
+.subsections = (const VMStateDescription * []) {
+_schdev_orb,
+NULL
 }
 };
 
@@ -1234,6 +1268,7 @@ int css_do_ssch(SubchDev *sch, ORB *orb)
 if (channel_subsys.chnmon_active) {
 css_update_chnmon(sch);
 }
+sch->orb = *orb;
 sch->channel_prog = orb->cpa;
 /* Trigger the start function. */
 s->ctrl |= (SCSW_FCTL_START_FUNC | SCSW_ACTL_START_PEND);
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index e67ac5c..dbe093e 100644
--- a/include/hw/s390x/css.h
+++ b/include/hw/s390x/css.h
@@ -88,6 +88,7 @@ struct SubchDev {
 bool thinint_active;
 uint8_t ccw_no_data_cnt;
 uint16_t migrated_schid; /* used for missmatch detection */
+ORB orb;
 /* transport-provided data: */
 int (*ccw_cb) (SubchDev *, CCW1);
 void (*disable_cb)(SubchDev *);
-- 
2.10.2

[Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration

[Halil Pasic]

Let us use the freshly introduced vmstate migration helpers instead of
saving/loading the config manually.

To achieve this we need to hack the config_vector which is a common
VirtIO state in the middle of the VirtioCcwDevice state representation.
This somewhat ugly but we have no choice because the stream format needs
to be preserved.

Still no changes in behavior, but the dead code we added previously is
finally awakening to life.

Signed-off-by: Halil Pasic 
---
---
 hw/s390x/virtio-ccw.c | 116 +++---
 1 file changed, 44 insertions(+), 72 deletions(-)

diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index c2badfe..8ab655c 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -57,6 +57,32 @@ static int virtio_ccw_dev_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
+static int get_config_vector(QEMUFile *f, void *pv, size_t size,
+ VMStateField *field)
+{
+VirtioCcwDevice *dev = pv;
+VirtIODevice *vdev = virtio_bus_get_device(>bus);
+
+qemu_get_be16s(f, >config_vector);
+return 0;
+}
+
+static int put_config_vector(QEMUFile *f, void *pv, size_t size,
+ VMStateField *field, QJSON *vmdesc)
+{
+VirtioCcwDevice *dev = pv;
+VirtIODevice *vdev = virtio_bus_get_device(>bus);
+
+qemu_put_be16(f, vdev->config_vector);
+return 0;
+}
+
+const VMStateInfo vmstate_info_config_vector = {
+.name = "config_vector",
+.get = get_config_vector,
+.put = put_config_vector,
+};
+
 const VMStateDescription vmstate_virtio_ccw_dev = {
 .name = "s390_virtio_ccw_dev",
 .version_id = 1,
@@ -67,6 +93,14 @@ const VMStateDescription vmstate_virtio_ccw_dev = {
 VMSTATE_PTR_TO_IND_ADDR(indicators, VirtioCcwDevice),
 VMSTATE_PTR_TO_IND_ADDR(indicators2, VirtioCcwDevice),
 VMSTATE_PTR_TO_IND_ADDR(summary_indicator, VirtioCcwDevice),
+{
+/*
+ * Ugly hack because VirtIODevice does not migrate itself.
+ * This also makes legacy via vmstate_save_state possible.
+ */
+.name = "virtio/config_vector",
+.info = _info_config_vector,
+},
 VMSTATE_STRUCT(routes, VirtioCcwDevice, 1, vmstate_adapter_routes, \
AdapterRoutes),
 VMSTATE_UINT8(thinint_isc, VirtioCcwDevice),
@@ -1272,85 +1306,23 @@ static int virtio_ccw_load_queue(DeviceState *d, int n, 
QEMUFile *f)
 static void virtio_ccw_save_config(DeviceState *d, QEMUFile *f)
 {
 VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
-CcwDevice *ccw_dev = CCW_DEVICE(d);
-SubchDev *s = ccw_dev->sch;
-VirtIODevice *vdev = virtio_ccw_get_vdev(s);
 
-subch_device_save(s, f);
-if (dev->indicators != NULL) {
-qemu_put_be32(f, dev->indicators->len);
-qemu_put_be64(f, dev->indicators->addr);
-} else {
-qemu_put_be32(f, 0);
-qemu_put_be64(f, 0UL);
-}
-if (dev->indicators2 != NULL) {
-qemu_put_be32(f, dev->indicators2->len);
-qemu_put_be64(f, dev->indicators2->addr);
-} else {
-qemu_put_be32(f, 0);
-qemu_put_be64(f, 0UL);
-}
-if (dev->summary_indicator != NULL) {
-qemu_put_be32(f, dev->summary_indicator->len);
-qemu_put_be64(f, dev->summary_indicator->addr);
-} else {
-qemu_put_be32(f, 0);
-qemu_put_be64(f, 0UL);
-}
-qemu_put_be16(f, vdev->config_vector);
-qemu_put_be64(f, dev->routes.adapter.ind_offset);
-qemu_put_byte(f, dev->thinint_isc);
-qemu_put_be32(f, dev->revision);
+/*
+ * We save in legacy mode. The components take care of their own
+ * compat. representation (based on css_migration_enabled).
+ */
+vmstate_save_state(f, _virtio_ccw_dev, dev, NULL);
 }
 
 static int virtio_ccw_load_config(DeviceState *d, QEMUFile *f)
 {
 VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
-CcwDevice *ccw_dev = CCW_DEVICE(d);
-CCWDeviceClass *ck = CCW_DEVICE_GET_CLASS(ccw_dev);
-SubchDev *s = ccw_dev->sch;
-VirtIODevice *vdev = virtio_ccw_get_vdev(s);
-int len;
-
-s->driver_data = dev;
-subch_device_load(s, f);
-/* Re-fill subch_id after loading the subchannel states.*/
-if (ck->refill_ids) {
-ck->refill_ids(ccw_dev);
-}
-len = qemu_get_be32(f);
-if (len != 0) {
-dev->indicators = get_indicator(qemu_get_be64(f), len);
-} else {
-qemu_get_be64(f);
-dev->indicators = NULL;
-}
-len = qemu_get_be32(f);
-if (len != 0) {
-dev->indicators2 = get_indicator(qemu_get_be64(f), len);
-} else {
-qemu_get_be64(f);
-dev->indicators2 = NULL;
-}
-len = qemu_get_be32(f);
-if (len != 0) {
-dev->summary_indicator = get_indicator(qemu_get_be64(f), len);
-} else {
-qemu_get_be64(f);
-dev->summary_indicator = NULL;
-}
-qemu_get_be16s(f, 

Re: [Qemu-devel] [PATCH v2 1/2] i386: rewrite way CPUID index is validated

[Eduardo Habkost]

On Fri, May 05, 2017 at 03:27:42PM +0100, Daniel P. Berrange wrote:
> Change the nested if statements into a flat switch, to make
> it clearer what validation / capping is being performed on
> different CPUID index values.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  target/i386/cpu.c | 43 +--
>  1 file changed, 25 insertions(+), 18 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 13c0985..3d5903c 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2628,26 +2628,33 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  uint32_t pkg_offset;
>  
>  /* test if maximum index reached */
> -if (index & 0x8000) {
> +switch (index & 0xF000) {
> +case 0:
> +/* Intel documentation states that invalid EAX input will
> + * return the same information as EAX=cpuid_level
> + * (Intel SDM Vol. 2A - Instruction Set Reference - CPUID)
> + */
> +if (index > env->cpuid_level) {
> +index = env->cpuid_level;
> +}
> +break;

It looks like we can just move this code to the default branch,
and remove the "case 0:" branch.

> +case 0x8000:
>  if (index > env->cpuid_xlevel) {
> -if (env->cpuid_xlevel2 > 0) {
> -/* Handle the Centaur's CPUID instruction. */
> -if (index > env->cpuid_xlevel2) {
> -index = env->cpuid_xlevel2;
^^^ [1]

> -} else if (index < 0xC000) {
> -index = env->cpuid_xlevel;
^^^ [2]
> -}
> -} else {
> -/* Intel documentation states that invalid EAX input will
> - * return the same information as EAX=cpuid_level
> - * (Intel SDM Vol. 2A - Instruction Set Reference - CPUID)
> - */
> -index =  env->cpuid_level;
 ^^^ [3]

> -}
> +index = env->cpuid_xlevel;
^^^ [4]

Actually, CPUs do return the max _basic_ leaf (cpuid_level) even
when input EAX is larger than 0x8000. (See [3])

...except for the existing code at [2], but:

* TCG doesn't support any of the Centaur features.
* KVM is not affected by [2] because CPUID
  limits are handled inside the KVM kernel code (and KVM returns
  CPUID[env->cpuid_level] on that case, see
  linux/arch/x86/kvm/cpuid.c:check_cpuid_limit())

In other words, [2] was dead code, and we only need to reproduce
behavior implemented by [3].

>  }
> -} else {
> -if (index > env->cpuid_level)
> -index = env->cpuid_level;
> +break;
> +case 0xC000:
> +if (index > env->cpuid_xlevel2) {
> +index = env->cpuid_xlevel2;

This line reimplements [1], but (like [2]) [1] was dead code too.
But I suggest setting index=env->cpuid_level for consistency with
KVM code.

> +}
> +break;
> +default:
> +/* Intel documentation states that invalid EAX input will
> + * return the same information as EAX=cpuid_level
> + * (Intel SDM Vol. 2A - Instruction Set Reference - CPUID)
> + */
> +index =  env->cpuid_level;
> +break;
>  }

What about simplifying this even further:

if (index > 0xC000) {
limit = env->cpuid_xlevel2;
} else if (index > 0x8000) {
limit = env->cpuid_xlevel;
} else {
limit = env->cpuid_level;
}

if (index > limit) {
/* Intel documentation states that invalid EAX input will
 * return the same information as EAX=cpuid_level
 * (Intel SDM Vol. 2A - Instruction Set Reference - CPUID)
 */
index = env->cpuid_level;
}

>  
>  switch(index) {
> -- 
> 2.9.3
> 

-- 
Eduardo

[Qemu-devel] [PATCH 05/10] virtio-ccw: add vmstate entities for VirtioCcwDevice

[Halil Pasic]

As a preparation for a transition to a vmstate based migration let us
introduce vmstate entities for VirtioCcwDevice and its members. This
patch does not take care of config_vector which is common VirtIO state
but not migrated by common VirtiIO code.

No changes in behavior, we just added some dead code -- which  should
rise to life soon.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---

Note: In this patch series the config_vector issue is handled by the
patch "virtio-ccw: use vmstate way for config migration". Further
details there.
---
 hw/intc/s390_flic.c  | 48 
 hw/s390x/virtio-ccw.c| 38 +++
 include/hw/s390x/s390_flic.h |  5 +
 3 files changed, 91 insertions(+)

diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
index 711c114..b889e74 100644
--- a/hw/intc/s390_flic.c
+++ b/hw/intc/s390_flic.c
@@ -18,6 +18,7 @@
 #include "trace.h"
 #include "hw/qdev.h"
 #include "qapi/error.h"
+#include "hw/s390x/s390-virtio-ccw.h"
 
 S390FLICState *s390_get_flic(void)
 {
@@ -137,3 +138,50 @@ static void qemu_s390_flic_register_types(void)
 }
 
 type_init(qemu_s390_flic_register_types)
+
+static bool adapter_info_so_needed(void *opaque)
+{
+return css_migration_enabled();
+}
+
+const VMStateDescription vmstate_adapter_info_so = {
+.name = "s390_adapter_info/summary_offset",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = adapter_info_so_needed,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(summary_offset, AdapterInfo),
+VMSTATE_END_OF_LIST()
+}
+};
+
+const VMStateDescription vmstate_adapter_info = {
+.name = "s390_adapter_info",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(ind_offset, AdapterInfo),
+/*
+ * We do not have to migrate neither the id nor the addresses.
+ * The id is set by css_register_io_adapter and the addresses
+ * are set based on the IndAddr objects after those get mapped.
+ */
+VMSTATE_END_OF_LIST()
+},
+.subsections = (const VMStateDescription * []) {
+_adapter_info_so,
+NULL
+}
+};
+
+const VMStateDescription vmstate_adapter_routes = {
+
+.name = "s390_adapter_routes",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT(adapter, AdapterRoutes, 1, vmstate_adapter_info, \
+   AdapterInfo),
+VMSTATE_END_OF_LIST()
+}
+};
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index e7167e3..c2badfe 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -34,9 +34,47 @@
 #include "virtio-ccw.h"
 #include "trace.h"
 #include "hw/s390x/css-bridge.h"
+#include "hw/s390x/s390-virtio-ccw.h"
 
 #define NR_CLASSIC_INDICATOR_BITS 64
 
+static int virtio_ccw_dev_post_load(void *opaque, int version_id)
+{
+VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(opaque);
+CcwDevice *ccw_dev = CCW_DEVICE(dev);
+CCWDeviceClass *ck = CCW_DEVICE_GET_CLASS(ccw_dev);
+
+ccw_dev->sch->driver_data = dev;
+if (CCW_DEVICE(dev)->sch->thinint_active) {
+dev->routes.adapter.adapter_id = css_get_adapter_id(
+ CSS_IO_ADAPTER_VIRTIO,
+ dev->thinint_isc);
+}
+/* Re-fill subch_id after loading the subchannel states.*/
+if (ck->refill_ids) {
+ck->refill_ids(ccw_dev);
+}
+return 0;
+}
+
+const VMStateDescription vmstate_virtio_ccw_dev = {
+.name = "s390_virtio_ccw_dev",
+.version_id = 1,
+.minimum_version_id = 1,
+.post_load = virtio_ccw_dev_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_CCW_DEVICE(parent_obj, VirtioCcwDevice),
+VMSTATE_PTR_TO_IND_ADDR(indicators, VirtioCcwDevice),
+VMSTATE_PTR_TO_IND_ADDR(indicators2, VirtioCcwDevice),
+VMSTATE_PTR_TO_IND_ADDR(summary_indicator, VirtioCcwDevice),
+VMSTATE_STRUCT(routes, VirtioCcwDevice, 1, vmstate_adapter_routes, \
+   AdapterRoutes),
+VMSTATE_UINT8(thinint_isc, VirtioCcwDevice),
+VMSTATE_INT32(revision, VirtioCcwDevice),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static void virtio_ccw_bus_new(VirtioBusState *bus, size_t bus_size,
VirtioCcwDevice *dev);
 
diff --git a/include/hw/s390x/s390_flic.h b/include/hw/s390x/s390_flic.h
index f9e6890..caa6fc6 100644
--- a/include/hw/s390x/s390_flic.h
+++ b/include/hw/s390x/s390_flic.h
@@ -31,6 +31,11 @@ typedef struct AdapterRoutes {
 int gsi[ADAPTER_ROUTES_MAX_GSI];
 } AdapterRoutes;
 
+extern const VMStateDescription vmstate_adapter_routes;
+
+#define VMSTATE_ADAPTER_ROUTES(_f, _s) \
+VMSTATE_STRUCT(_f, _s, 1, vmstate_adapter_routes, AdapterRoutes)
+
 #define TYPE_S390_FLIC_COMMON "s390-flic"
 #define 

[Qemu-devel] [PATCH 09/10] s390x/css: turn on channel subsystem migration

[Halil Pasic]

Turn on migration for the channel subsystem and the new scheme for
migrating virtio-ccw proxy devices (instead of letting the transport
independent child device migrate it's proxy, use the usual
DeviceClass.vmsd mechanism) for future machine versions.

The vmstate based migration of the channel subsystem is not migration
stream compatible with the method for handling migration of legacy
machines.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 hw/s390x/ccw-device.c  |  1 +
 hw/s390x/css.c |  5 +
 hw/s390x/s390-virtio-ccw.c |  9 -
 hw/s390x/virtio-ccw.c  | 14 ++
 include/hw/s390x/css.h |  4 
 5 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c
index f9bfa15..3b5df03 100644
--- a/hw/s390x/ccw-device.c
+++ b/hw/s390x/ccw-device.c
@@ -48,6 +48,7 @@ static void ccw_device_class_init(ObjectClass *klass, void 
*data)
 k->realize = ccw_device_realize;
 k->refill_ids = ccw_device_refill_ids;
 dc->props = ccw_device_properties;
+dc->vmsd = _ccw_dev;
 }
 
 const VMStateDescription vmstate_ccw_dev = {
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index d9a0fb9..b58832a 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -385,6 +385,11 @@ static int subch_dev_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
+void css_register_vmstate(void)
+{
+vmstate_register(NULL, 0, _css, _subsys);
+}
+
 IndAddr *get_indicator(hwaddr ind_addr, int len)
 {
 IndAddr *indicator;
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 698e8fc..5307f59 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -196,7 +196,7 @@ static void ccw_machine_class_init(ObjectClass *oc, void 
*data)
 
 s390mc->ri_allowed = true;
 s390mc->cpu_model_allowed = true;
-s390mc->css_migration_enabled = false; /* TODO: set to true */
+s390mc->css_migration_enabled = true;
 mc->init = ccw_init;
 mc->reset = s390_machine_reset;
 mc->hot_add_cpu = s390_hot_add_cpu;
@@ -414,10 +414,9 @@ bool css_migration_enabled(void)
 
 static void ccw_machine_2_10_instance_options(MachineState *machine)
 {
-/*
- * TODO Once preparations are done register vmstate for the css if
- * css_migration_enabled().
- */
+if (css_migration_enabled()) {
+css_register_vmstate();
+}
 }
 
 static void ccw_machine_2_10_class_options(MachineClass *mc)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 8ab655c..c611b6f 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -1307,6 +1307,10 @@ static void virtio_ccw_save_config(DeviceState *d, 
QEMUFile *f)
 {
 VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
 
+if (css_migration_enabled()) {
+/* we migrate via DeviceClass.vmsd */
+return;
+}
 /*
  * We save in legacy mode. The components take care of their own
  * compat. representation (based on css_migration_enabled).
@@ -1318,6 +1322,10 @@ static int virtio_ccw_load_config(DeviceState *d, 
QEMUFile *f)
 {
 VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
 
+if (css_migration_enabled()) {
+/* we migrate via DeviceClass.vmsd */
+return 0;
+}
 /*
  * We load in legacy mode. The components take take care to read
  * only stuff which is actually there (based on css_migration_enabled).
@@ -1365,6 +1373,11 @@ static void virtio_ccw_device_plugged(DeviceState *d, 
Error **errp)
 sch->id.cu_model = virtio_bus_get_vdev_id(>bus);
 
 
+/* Avoid generating unknown section for legacy migration target. */
+if (!css_migration_enabled()) {
+DEVICE_GET_CLASS(ccw_dev)->vmsd = NULL;
+}
+
 css_generate_sch_crws(sch->cssid, sch->ssid, sch->schid,
   d->hotplugged, 1);
 }
@@ -1657,6 +1670,7 @@ static void virtio_ccw_device_class_init(ObjectClass 
*klass, void *data)
 dc->realize = virtio_ccw_busdev_realize;
 dc->exit = virtio_ccw_busdev_exit;
 dc->bus_type = TYPE_VIRTUAL_CSS_BUS;
+dc->vmsd = _virtio_ccw_dev;
 }
 
 static const TypeInfo virtio_ccw_device_info = {
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index dbe093e..be5eb81 100644
--- a/include/hw/s390x/css.h
+++ b/include/hw/s390x/css.h
@@ -207,4 +207,8 @@ extern PropertyInfo css_devid_ro_propinfo;
  * is responsible for unregistering and freeing it.
  */
 SubchDev *css_create_virtual_sch(CssDevId bus_id, Error **errp);
+
+/** Turn on css migration */
+void css_register_vmstate(void);
+
 #endif
-- 
2.10.2

[Qemu-devel] [PATCH 02/10] s390x: add css_migration_enabled to machine class

[Halil Pasic]

Currently the migration of the channel subsystem (css) is only partial
and is done by the virtio ccw proxies -- the only css devices existing
at the moment. With the current efforts towards emulated and passthrough
devices we need to improve on the migration of the css. This however
will necessarily break the migration compatibility. So let us introduce
a switch (at the machine class) and put it in off state for now. We will
turn the switch on for future machines once all preparations are met.

Signed-off-by: Halil Pasic 
---
 hw/s390x/s390-virtio-ccw.c | 13 +
 include/hw/s390x/s390-virtio-ccw.h |  7 +++
 2 files changed, 20 insertions(+)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 7a053a4..698e8fc 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -196,6 +196,7 @@ static void ccw_machine_class_init(ObjectClass *oc, void 
*data)
 
 s390mc->ri_allowed = true;
 s390mc->cpu_model_allowed = true;
+s390mc->css_migration_enabled = false; /* TODO: set to true */
 mc->init = ccw_init;
 mc->reset = s390_machine_reset;
 mc->hot_add_cpu = s390_hot_add_cpu;
@@ -307,6 +308,11 @@ static const TypeInfo ccw_machine_info = {
 },
 };
 
+bool css_migration_enabled(void)
+{
+return get_machine_class()->css_migration_enabled;
+}
+
 #define DEFINE_CCW_MACHINE(suffix, verstr, latest)\
 static void ccw_machine_##suffix##_class_init(ObjectClass *oc,\
   void *data) \
@@ -408,6 +414,10 @@ static const TypeInfo ccw_machine_info = {
 
 static void ccw_machine_2_10_instance_options(MachineState *machine)
 {
+/*
+ * TODO Once preparations are done register vmstate for the css if
+ * css_migration_enabled().
+ */
 }
 
 static void ccw_machine_2_10_class_options(MachineClass *mc)
@@ -422,8 +432,11 @@ static void ccw_machine_2_9_instance_options(MachineState 
*machine)
 
 static void ccw_machine_2_9_class_options(MachineClass *mc)
 {
+S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
+
 ccw_machine_2_10_class_options(mc);
 SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_9);
+s390mc->css_migration_enabled = false;
 }
 DEFINE_CCW_MACHINE(2_9, "2.9", false);
 
diff --git a/include/hw/s390x/s390-virtio-ccw.h 
b/include/hw/s390x/s390-virtio-ccw.h
index 6ecae00..b043550 100644
--- a/include/hw/s390x/s390-virtio-ccw.h
+++ b/include/hw/s390x/s390-virtio-ccw.h
@@ -37,6 +37,7 @@ typedef struct S390CcwMachineClass {
 /*< public >*/
 bool ri_allowed;
 bool cpu_model_allowed;
+bool css_migration_enabled;
 } S390CcwMachineClass;
 
 /* runtime-instrumentation allowed by the machine */
@@ -44,4 +45,10 @@ bool ri_allowed(void);
 /* cpu model allowed by the machine */
 bool cpu_model_allowed(void);
 
+/**
+ * Returns true if (vmstate based) migration of the channel subsystem
+ * is enabled, false if it is disabled.
+ */
+bool css_migration_enabled(void);
+
 #endif
-- 
2.10.2

[Qemu-devel] [PATCH 01/10] s390x: add helper get_machine_class

[Halil Pasic]

We will need the machine class at machine initialization time, so the
usual way via qdev won't do. Let's cache the machine class and also use
the default values of the base machine for capability discovery.

Signed-off-by: Halil Pasic 
---
 hw/s390x/s390-virtio-ccw.c | 46 +++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 04bd0eb..7a053a4 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -242,36 +242,35 @@ static inline void machine_set_dea_key_wrap(Object *obj, 
bool value,
 ms->dea_key_wrap = value;
 }
 
-bool ri_allowed(void)
-{
-if (kvm_enabled()) {
-MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
-if (object_class_dynamic_cast(OBJECT_CLASS(mc),
-  TYPE_S390_CCW_MACHINE)) {
-S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
+static S390CcwMachineClass *current_mc;
 
-return s390mc->ri_allowed;
-}
+static S390CcwMachineClass *get_machine_class(void)
+{
+if (unlikely(!current_mc)) {
 /*
- * Make sure the "none" machine can have ri, otherwise it won't * be
- * unlocked in KVM and therefore the host CPU model might be wrong.
- */
-return true;
+* No s390 ccw machine was instantiated, we are likely to
+* be called for the 'none' machine. The properties will
+* have their after-initialization values.
+*/
+current_mc = S390_MACHINE_CLASS(
+ object_class_by_name(TYPE_S390_CCW_MACHINE));
 }
-return 0;
+return current_mc;
 }
 
-bool cpu_model_allowed(void)
+bool ri_allowed(void)
 {
-MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
-if (object_class_dynamic_cast(OBJECT_CLASS(mc),
-  TYPE_S390_CCW_MACHINE)) {
-S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
-
-return s390mc->cpu_model_allowed;
+if (!kvm_enabled()) {
+return false;
 }
-/* allow CPU model qmp queries with the "none" machine */
-return true;
+/* for "none" machine this results in true */
+return get_machine_class()->ri_allowed;
+}
+
+bool cpu_model_allowed(void)
+{
+/* for "none" machine this results in true */
+return get_machine_class()->cpu_model_allowed;
 }
 
 static inline void s390_machine_initfn(Object *obj)
@@ -323,6 +322,7 @@ static const TypeInfo ccw_machine_info = {
 static void ccw_machine_##suffix##_instance_init(Object *obj) \
 { \
 MachineState *machine = MACHINE(obj); \
+current_mc = S390_MACHINE_CLASS(MACHINE_GET_CLASS(machine));  \
 ccw_machine_##suffix##_instance_options(machine); \
 } \
 static const TypeInfo ccw_machine_##suffix##_info = { \
-- 
2.10.2

[Qemu-devel] [PATCH 03/10] s390x/css: add vmstate entities for css

[Halil Pasic]

As a preparation for switching to a vmstate based migration let us
introduce vmstate entities (e.g. VMStateDescription) for the css entities
to be migrated. Alongside some comments explaining or indicating the not
migration of certain members are introduced too.

No changes in behavior, we just added some dead code -- which should
rise to life soon.

Signed-off-by: Halil Pasic 
---
 hw/s390x/css.c | 276 +
 include/hw/s390x/css.h |  10 +-
 2 files changed, 285 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index c03bb20..2bda7d0 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -20,29 +20,231 @@
 #include "hw/s390x/css.h"
 #include "trace.h"
 #include "hw/s390x/s390_flic.h"
+#include "hw/s390x/s390-virtio-ccw.h"
 
 typedef struct CrwContainer {
 CRW crw;
 QTAILQ_ENTRY(CrwContainer) sibling;
 } CrwContainer;
 
+static const VMStateDescription vmstate_crw = {
+.name = "s390_crw",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT16(flags, CRW),
+VMSTATE_UINT16(rsid, CRW),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static const VMStateDescription vmstate_crw_container = {
+.name = "s390_crw_container",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT(crw, CrwContainer, 0, vmstate_crw, CRW),
+VMSTATE_END_OF_LIST()
+},
+};
+
 typedef struct ChpInfo {
 uint8_t in_use;
 uint8_t type;
 uint8_t is_virtual;
 } ChpInfo;
 
+static const VMStateDescription vmstate_chp_info = {
+.name = "s390_chp_info",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(in_use, ChpInfo),
+VMSTATE_UINT8(type, ChpInfo),
+VMSTATE_UINT8(is_virtual, ChpInfo),
+VMSTATE_END_OF_LIST()
+}
+};
+
 typedef struct SubchSet {
 SubchDev *sch[MAX_SCHID + 1];
 unsigned long schids_used[BITS_TO_LONGS(MAX_SCHID + 1)];
 unsigned long devnos_used[BITS_TO_LONGS(MAX_SCHID + 1)];
 } SubchSet;
 
+static const VMStateDescription vmstate_scsw = {
+.name = "s390_scsw",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT16(flags, SCSW),
+VMSTATE_UINT16(ctrl, SCSW),
+VMSTATE_UINT32(cpa, SCSW),
+VMSTATE_UINT8(dstat, SCSW),
+VMSTATE_UINT8(cstat, SCSW),
+VMSTATE_UINT16(count, SCSW),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_pmcw = {
+.name = "s390_pmcw",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(intparm, PMCW),
+VMSTATE_UINT16(flags, PMCW),
+VMSTATE_UINT16(devno, PMCW),
+VMSTATE_UINT8(lpm, PMCW),
+VMSTATE_UINT8(pnom, PMCW),
+VMSTATE_UINT8(lpum, PMCW),
+VMSTATE_UINT8(pim, PMCW),
+VMSTATE_UINT16(mbi, PMCW),
+VMSTATE_UINT8(pom, PMCW),
+VMSTATE_UINT8(pam, PMCW),
+VMSTATE_UINT8_ARRAY(chpid, PMCW, 8),
+VMSTATE_UINT32(chars, PMCW),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_schib = {
+.name = "s390_schib",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT(pmcw, SCHIB, 0, vmstate_pmcw, PMCW),
+VMSTATE_STRUCT(scsw, SCHIB, 0, vmstate_scsw, SCSW),
+VMSTATE_UINT64(mba, SCHIB),
+VMSTATE_UINT8_ARRAY(mda, SCHIB, 4),
+VMSTATE_END_OF_LIST()
+}
+};
+
+
+static const VMStateDescription vmstate_ccw1 = {
+.name = "s390_ccw1",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(cmd_code, CCW1),
+VMSTATE_UINT8(flags, CCW1),
+VMSTATE_UINT16(count, CCW1),
+VMSTATE_UINT32(cda, CCW1),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_ciw = {
+.name = "s390_ciw",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(type, CIW),
+VMSTATE_UINT8(command, CIW),
+VMSTATE_UINT16(count, CIW),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_sense_id = {
+.name = "s390_sense_id",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(reserved, SenseId),
+VMSTATE_UINT16(cu_type, SenseId),
+VMSTATE_UINT8(cu_model, SenseId),
+VMSTATE_UINT16(dev_type, SenseId),
+VMSTATE_UINT8(dev_model, SenseId),
+VMSTATE_UINT8(unused, SenseId),
+VMSTATE_STRUCT_ARRAY(ciw, SenseId, MAX_CIWS, 0, vmstate_ciw, CIW),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static int subch_dev_post_load(void *opaque, int version_id);
+static void subch_dev_pre_save(void *opaque);
+
+const 

[Qemu-devel] [PATCH 10/10] s390x/css: use SubchDev.orb

[Halil Pasic]

Instead of passing around a pointer to ORB let us simplify some
functions signatures by using the previously introduced ORB saved at the
subchannel (SubchDev).

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 hw/s390x/css.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index b58832a..694365b 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -838,7 +838,7 @@ static int css_interpret_ccw(SubchDev *sch, hwaddr ccw_addr,
 return ret;
 }
 
-static void sch_handle_start_func(SubchDev *sch, ORB *orb)
+static void sch_handle_start_func(SubchDev *sch)
 {
 
 PMCW *p = >curr_status.pmcw;
@@ -852,10 +852,10 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
 
 if (!(s->ctrl & SCSW_ACTL_SUSP)) {
 /* Start Function triggered via ssch, i.e. we have an ORB */
+ORB *orb = >orb;
 s->cstat = 0;
 s->dstat = 0;
 /* Look at the orb and try to execute the channel program. */
-assert(orb != NULL); /* resume does not pass an orb */
 p->intparm = orb->intparm;
 if (!(orb->lpm & path)) {
 /* Generate a deferred cc 3 condition. */
@@ -869,8 +869,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
 sch->ccw_no_data_cnt = 0;
 suspend_allowed = !!(orb->ctrl0 & ORB_CTRL0_MASK_SPND);
 } else {
-/* Start Function resumed via rsch, i.e. we don't have an
- * ORB */
+/* Start Function resumed via rsch */
 s->ctrl &= ~(SCSW_ACTL_SUSP | SCSW_ACTL_RESUME_PEND);
 /* The channel program had been suspended before. */
 suspend_allowed = true;
@@ -943,7 +942,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
  * read/writes) asynchronous later on if we start supporting more than
  * our current very simple devices.
  */
-static void do_subchannel_work(SubchDev *sch, ORB *orb)
+static void do_subchannel_work(SubchDev *sch)
 {
 
 SCSW *s = >curr_status.scsw;
@@ -954,7 +953,7 @@ static void do_subchannel_work(SubchDev *sch, ORB *orb)
 sch_handle_halt_func(sch);
 } else if (s->ctrl & SCSW_FCTL_START_FUNC) {
 /* Triggered by both ssch and rsch. */
-sch_handle_start_func(sch, orb);
+sch_handle_start_func(sch);
 } else {
 /* Cannot happen. */
 return;
@@ -1163,7 +1162,7 @@ int css_do_csch(SubchDev *sch)
 s->ctrl &= ~(SCSW_CTRL_MASK_FCTL | SCSW_CTRL_MASK_ACTL);
 s->ctrl |= SCSW_FCTL_CLEAR_FUNC | SCSW_ACTL_CLEAR_PEND;
 
-do_subchannel_work(sch, NULL);
+do_subchannel_work(sch);
 ret = 0;
 
 out:
@@ -1204,7 +1203,7 @@ int css_do_hsch(SubchDev *sch)
 }
 s->ctrl |= SCSW_ACTL_HALT_PEND;
 
-do_subchannel_work(sch, NULL);
+do_subchannel_work(sch);
 ret = 0;
 
 out:
@@ -1279,7 +1278,7 @@ int css_do_ssch(SubchDev *sch, ORB *orb)
 s->ctrl |= (SCSW_FCTL_START_FUNC | SCSW_ACTL_START_PEND);
 s->flags &= ~SCSW_FLAGS_MASK_PNO;
 
-do_subchannel_work(sch, orb);
+do_subchannel_work(sch);
 ret = 0;
 
 out:
@@ -1559,7 +1558,7 @@ int css_do_rsch(SubchDev *sch)
 }
 
 s->ctrl |= SCSW_ACTL_RESUME_PEND;
-do_subchannel_work(sch, NULL);
+do_subchannel_work(sch);
 ret = 0;
 
 out:
-- 
2.10.2

[Qemu-devel] [PATCH 00/10] migration: s390x css migration

[Halil Pasic]

This patch set has a dual purpose: introduce proper migration for the
channel subsystem (css) and convert the migration of ccw devices to
vmstate. The state of the css was only partially migrated by the
virtio-ccw devices (was the only device type until recent), which was
good enough for a while.

Since the new vmstate infrastructure is used also for handling the
migration stream for legacy machines some bits are a bit convoluted:
that is, if you see something convoluted there is a good chance the
reason why is compatibility.

Halil Pasic (10):
  s390x: add helper get_machine_class
  s390x: add css_migration_enabled to machine class
  s390x/css: add vmstate entities for css
  s390x/css: add vmstate macro for CcwDevice
  virtio-ccw: add vmstate entities for VirtioCcwDevice
  virtio-ccw: use vmstate way for config migration
  s390x/css: remove unused subch_dev_(load|save)
  s390x/css: add ORB to SubchDev
  s390x/css: turn on channel subsystem migration
  s390x/css: use SubchDev.orb

 hw/intc/s390_flic.c|  48 
 hw/s390x/ccw-device.c  |  11 +
 hw/s390x/ccw-device.h  |   4 +
 hw/s390x/css.c | 478 +
 hw/s390x/s390-virtio-ccw.c |  58 +++--
 hw/s390x/virtio-ccw.c  | 164 +++--
 include/hw/s390x/css.h |  17 +-
 include/hw/s390x/s390-virtio-ccw.h |   7 +
 include/hw/s390x/s390_flic.h   |   5 +
 9 files changed, 543 insertions(+), 249 deletions(-)

-- 
2.10.2

[Qemu-devel] [PATCH 07/10] s390x/css: remove unused subch_dev_(load|save)

[Halil Pasic]

Since the functions subch_dev_load and subch_dev save are not used
any more let's remove them.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 hw/s390x/css.c | 143 -
 include/hw/s390x/css.h |   2 -
 2 files changed, 145 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 2bda7d0..94338b2 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1914,149 +1914,6 @@ int css_enable_mss(void)
 return 0;
 }
 
-void subch_device_save(SubchDev *s, QEMUFile *f)
-{
-int i;
-
-qemu_put_byte(f, s->cssid);
-qemu_put_byte(f, s->ssid);
-qemu_put_be16(f, s->schid);
-qemu_put_be16(f, s->devno);
-qemu_put_byte(f, s->thinint_active);
-/* SCHIB */
-/* PMCW */
-qemu_put_be32(f, s->curr_status.pmcw.intparm);
-qemu_put_be16(f, s->curr_status.pmcw.flags);
-qemu_put_be16(f, s->curr_status.pmcw.devno);
-qemu_put_byte(f, s->curr_status.pmcw.lpm);
-qemu_put_byte(f, s->curr_status.pmcw.pnom);
-qemu_put_byte(f, s->curr_status.pmcw.lpum);
-qemu_put_byte(f, s->curr_status.pmcw.pim);
-qemu_put_be16(f, s->curr_status.pmcw.mbi);
-qemu_put_byte(f, s->curr_status.pmcw.pom);
-qemu_put_byte(f, s->curr_status.pmcw.pam);
-qemu_put_buffer(f, s->curr_status.pmcw.chpid, 8);
-qemu_put_be32(f, s->curr_status.pmcw.chars);
-/* SCSW */
-qemu_put_be16(f, s->curr_status.scsw.flags);
-qemu_put_be16(f, s->curr_status.scsw.ctrl);
-qemu_put_be32(f, s->curr_status.scsw.cpa);
-qemu_put_byte(f, s->curr_status.scsw.dstat);
-qemu_put_byte(f, s->curr_status.scsw.cstat);
-qemu_put_be16(f, s->curr_status.scsw.count);
-qemu_put_be64(f, s->curr_status.mba);
-qemu_put_buffer(f, s->curr_status.mda, 4);
-/* end SCHIB */
-qemu_put_buffer(f, s->sense_data, 32);
-qemu_put_be64(f, s->channel_prog);
-/* last cmd */
-qemu_put_byte(f, s->last_cmd.cmd_code);
-qemu_put_byte(f, s->last_cmd.flags);
-qemu_put_be16(f, s->last_cmd.count);
-qemu_put_be32(f, s->last_cmd.cda);
-qemu_put_byte(f, s->last_cmd_valid);
-qemu_put_byte(f, s->id.reserved);
-qemu_put_be16(f, s->id.cu_type);
-qemu_put_byte(f, s->id.cu_model);
-qemu_put_be16(f, s->id.dev_type);
-qemu_put_byte(f, s->id.dev_model);
-qemu_put_byte(f, s->id.unused);
-for (i = 0; i < ARRAY_SIZE(s->id.ciw); i++) {
-qemu_put_byte(f, s->id.ciw[i].type);
-qemu_put_byte(f, s->id.ciw[i].command);
-qemu_put_be16(f, s->id.ciw[i].count);
-}
-qemu_put_byte(f, s->ccw_fmt_1);
-qemu_put_byte(f, s->ccw_no_data_cnt);
-}
-
-int subch_device_load(SubchDev *s, QEMUFile *f)
-{
-SubchDev *old_s;
-uint16_t old_schid = s->schid;
-int i;
-
-s->cssid = qemu_get_byte(f);
-s->ssid = qemu_get_byte(f);
-s->schid = qemu_get_be16(f);
-s->devno = qemu_get_be16(f);
-/* Re-assign subch. */
-if (old_schid != s->schid) {
-old_s = channel_subsys.css[s->cssid]->sch_set[s->ssid]->sch[old_schid];
-/*
- * (old_s != s) means that some other device has its correct
- * subchannel already assigned (in load).
- */
-if (old_s == s) {
-css_subch_assign(s->cssid, s->ssid, old_schid, s->devno, NULL);
-}
-/* It's OK to re-assign without a prior de-assign. */
-css_subch_assign(s->cssid, s->ssid, s->schid, s->devno, s);
-}
-s->thinint_active = qemu_get_byte(f);
-/* SCHIB */
-/* PMCW */
-s->curr_status.pmcw.intparm = qemu_get_be32(f);
-s->curr_status.pmcw.flags = qemu_get_be16(f);
-s->curr_status.pmcw.devno = qemu_get_be16(f);
-s->curr_status.pmcw.lpm = qemu_get_byte(f);
-s->curr_status.pmcw.pnom  = qemu_get_byte(f);
-s->curr_status.pmcw.lpum = qemu_get_byte(f);
-s->curr_status.pmcw.pim = qemu_get_byte(f);
-s->curr_status.pmcw.mbi = qemu_get_be16(f);
-s->curr_status.pmcw.pom = qemu_get_byte(f);
-s->curr_status.pmcw.pam = qemu_get_byte(f);
-qemu_get_buffer(f, s->curr_status.pmcw.chpid, 8);
-s->curr_status.pmcw.chars = qemu_get_be32(f);
-/* SCSW */
-s->curr_status.scsw.flags = qemu_get_be16(f);
-s->curr_status.scsw.ctrl = qemu_get_be16(f);
-s->curr_status.scsw.cpa = qemu_get_be32(f);
-s->curr_status.scsw.dstat = qemu_get_byte(f);
-s->curr_status.scsw.cstat = qemu_get_byte(f);
-s->curr_status.scsw.count = qemu_get_be16(f);
-s->curr_status.mba = qemu_get_be64(f);
-qemu_get_buffer(f, s->curr_status.mda, 4);
-/* end SCHIB */
-qemu_get_buffer(f, s->sense_data, 32);
-s->channel_prog = qemu_get_be64(f);
-/* last cmd */
-s->last_cmd.cmd_code = qemu_get_byte(f);
-s->last_cmd.flags = qemu_get_byte(f);
-s->last_cmd.count = qemu_get_be16(f);
-s->last_cmd.cda = qemu_get_be32(f);
-s->last_cmd_valid = qemu_get_byte(f);
-s->id.reserved = qemu_get_byte(f);
-s->id.cu_type = 

[Qemu-devel] [PATCH 04/10] s390x/css: add vmstate macro for CcwDevice

[Halil Pasic]

As a preparation for switching to a vmstate based migration let us
introduce a vmstate macro for CcwDevice.

No changes in behavior, we just added some dead code -- which should
rise to life soon.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 hw/s390x/ccw-device.c | 10 ++
 hw/s390x/ccw-device.h |  4 
 2 files changed, 14 insertions(+)

diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c
index fb8d640..f9bfa15 100644
--- a/hw/s390x/ccw-device.c
+++ b/hw/s390x/ccw-device.c
@@ -50,6 +50,16 @@ static void ccw_device_class_init(ObjectClass *klass, void 
*data)
 dc->props = ccw_device_properties;
 }
 
+const VMStateDescription vmstate_ccw_dev = {
+.name = "s390_ccw_dev",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT_POINTER(sch, CcwDevice, vmstate_subch_dev, SubchDev),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static const TypeInfo ccw_device_info = {
 .name = TYPE_CCW_DEVICE,
 .parent = TYPE_DEVICE,
diff --git a/hw/s390x/ccw-device.h b/hw/s390x/ccw-device.h
index 89c8e5d..4e6af28 100644
--- a/hw/s390x/ccw-device.h
+++ b/hw/s390x/ccw-device.h
@@ -27,6 +27,10 @@ typedef struct CcwDevice {
 CssDevId subch_id;
 } CcwDevice;
 
+extern const VMStateDescription vmstate_ccw_dev;
+#define VMSTATE_CCW_DEVICE(_field, _state) \
+VMSTATE_STRUCT(_field, _state, 1, vmstate_ccw_dev, CcwDevice)
+
 typedef struct CCWDeviceClass {
 DeviceClass parent_class;
 void (*unplug)(HotplugHandler *, DeviceState *, Error **);
-- 
2.10.2

Re: [Qemu-devel] [PATCH 1/5] 9pfs: check return value of v9fs_co_name_to_path()

[Greg Kurz]

On Fri, 5 May 2017 11:55:43 -0500
Eric Blake  wrote:

> On 05/05/2017 09:37 AM, Greg Kurz wrote:
> > These v9fs_co_name_to_path() call sites have always been around. I guess
> > no care was taken to check the return value because the name_to_path
> > operation could never fail at the time. This is no longer true: the
> > handle and synth backends can already fail this operation, and so will the
> > local backend soon.
> > 
> > Signed-off-by: Greg Kurz 
> > ---
> >  hw/9pfs/9p.c |   36 +---
> >  1 file changed, 25 insertions(+), 11 deletions(-)
> >   
> 
> > @@ -2588,8 +2591,11 @@ static int coroutine_fn v9fs_complete_rename(V9fsPDU 
> > *pdu, V9fsFidState *fidp,
> >  new_name = g_malloc0(end - old_name + name->size + 1);
> >  strncat(new_name, old_name, end - old_name);
> >  strncat(new_name + (end - old_name), name->data, name->size);  
> 
> Ad long as you're here, you could replace this strncat mess with the
> shorter:
> 
> new_name = g_strdup_printf("%.*s%.*s", end - old_name, old_name,
>name->size, name->data);
> 
> (or with further simplifications if you have NUL-terminated data).  But
> that can be a separate cleanup.
> 

Yes you're right, this definitely looks better than the strncat() logic.
I guess I'll do this in a separate patch.

Thanks for the suggestion.

> Reviewed-by: Eric Blake 
> 



pgpE23toocmkD.pgp
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 4/4] x86: Support feature=force on the command-line

[Eduardo Habkost]

On Thu, May 04, 2017 at 11:49:38AM +0200, Igor Mammedov wrote:
> On Tue,  2 May 2017 17:31:15 -0300
> Eduardo Habkost  wrote:
> 
> > Introduce a new CPUFeatureSetting QAPI data type, and use it to support
> > feature=force on -cpu.
> commit message lacks rationale why it's needed.
> I suspect that it's to enable forced mwait.
> It would be nice to put here answer to what
> motivated to write this patch and reference commit ids
> of kernel patches if there are/needed any to make it work.

In this case I need to ask Alex for help writing the rationale,
as he is sent the original mwait CPUID override patch.

It's not clear to me yet why KVM doesn't return MONITOR on
GET_SUPPORTED_CPUID today, making this patch unnecessary.

-- 
Eduardo

Re: [Qemu-devel] [PATCH 5/5] 9pfs: local: forbid client access to metadata

[Eric Blake]

On 05/05/2017 09:37 AM, Greg Kurz wrote:
> When using the mapped-file security mode, we shouldn't let the client
> mess with the metadata. The current code already hides it but the
> client can still access the metadata through several operations.
> 
> This patch fixes the issue by:
> - preventing the creation of fids pointing to the metadata (name_to_path)
> - failing various operations taking a dirpath and a name arguments if
>   name is a metadata reserved name
> 
> Signed-off-by: Greg Kurz 
> ---
>  hw/9pfs/9p-local.c |   41 +
>  1 file changed, 41 insertions(+)
> 
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index b427d2928800..93cadac302c9 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -588,6 +588,11 @@ static int local_mknod(FsContext *fs_ctx, V9fsPath 
> *dir_path,
>  int err = -1;
>  int dirfd;
>  
> +if (local_must_skip_metadata(fs_ctx, name)) {
> +errno = EINVAL;
> +return -1;
> +}
> +

I don't know if EINVAL is the best error, but it seems reasonable enough.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 12/24] numa: add numa_[has_]node_id() wrappers

[Eduardo Habkost]

On Fri, May 05, 2017 at 11:06:02AM +0200, Andrew Jones wrote:
> On Fri, May 05, 2017 at 10:09:18AM +0200, Igor Mammedov wrote:
> > On Fri, 5 May 2017 11:45:22 +1000
> > David Gibson  wrote:
> > 
> > > On Wed, May 03, 2017 at 02:57:06PM +0200, Igor Mammedov wrote:
> > > > wrappers should make access to [has]node_id fields more readable
> > > > 
> > > > Signed-off-by: Igor Mammedov   
> > > 
> > > Reviewed-by: David Gibson 
> > > 
> > > Correct, though I'm not sure it actually simplifies things that much.
> > > Maybe more in future patches, though.
> > that's what Drew insisted on, and even though I prefer other way around
> > I won't stall series arguing about styling issues,
> > so here this patch goes.
> 
> My argument in the last review of this series was that references like
> 
>  machine->possible_cpus->cpus[cs->cpu_index].props.has_node_id
> and
>  machine->possible_cpus->cpus[cs->cpu_index].props.node_id
> 
> are quite long, and only differ by 'has_', making it tough to
> easily recognize.

If expression length is a problem, we can just use an extra
variable:

 CPUArchId *slot = >possible_cpus->cpus[cs->cpu_index];
 if (slot->props.has_node_id && slot->props.node_id == FOO) ...


>   But, if nobody, but me, sees value in changing
> them to
> 
>  numa_has_node_id(machine->possible_cpus, cs->cpu_index)
> and
>  numa_node_id(machine->possible_cpus, cs->cpu_index)
> 
> then I won't insist.

I don't mind that much, but I still prefer the version without
the wrappers.

-- 
Eduardo

Re: [Qemu-devel] [PATCH 4/5] 9pfs: local: metadata file for the VirtFS root

[Eric Blake]

On 05/05/2017 09:37 AM, Greg Kurz wrote:
> When using the mapped-file security, credentials are stored in a metadata
> directory located in the parent directory. This is okay for all paths with
> the notable exception of the root path, since we don't want and probably
> can't create a metadata directory above the virtfs directory on the host.
> 
> This patch introduces a dedicated metadata file, sitting in the virtfs root
> for this purpose. It relies on the fact that the "." name necessarily refer

s/refer/refers/

> to the virtfs root.
> 
> As for the metadata directory, we don't want the client to see this file.
> The current code only cares for readdir() but there are many other places
> to fix actually. The filtering logic is hence put in a separate function.
> 
> Before:
> 
> # ls -ld
> drwxr-xr-x. 3 greg greg 4096 May  5 12:49 .
> # chown root.root .
> chown: changing ownership of '.': Is a directory
> # ls -ld
> drwxr-xr-x. 3 greg greg 4096 May  5 12:49 .
> 
> After:
> 
> # ls -ld
> drwxr-xr-x. 3 greg greg 4096 May  5 12:49 .
> # chown bin.bin .
> # ls -ld
> drwxr-xr-x. 3 root root 4096 May  5 12:50 .

Huh? How does chown bin.bin result in root.root? Copy-and-paste error?

> 
> and from the host:
> 
> ls -al .virtfs_metadata_root
> -rwx--. 1 greg greg 26 May  5 12:50 .virtfs_metadata_root
> $ cat .virtfs_metadata_root
> virtfs.uid=0
> virtfs.gid=0

So what happens if the guest tries to manipulate
./.virtfs_metadata_root? I know you are filtering it so that readdir()
and such can't see it, but do you have sane errors for the guest's
attempt to circumvent those hidden names?

> 
> Reported-by: Léo Gaspard 
> Signed-off-by: Greg Kurz 
> ---
>  hw/9pfs/9p-local.c |   88 
> 
>  1 file changed, 61 insertions(+), 27 deletions(-)
> 
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 10/24] numa: mirror cpu to node mapping in MachineState::possible_cpus

[Eduardo Habkost]

On Fri, May 05, 2017 at 02:16:48PM +0200, Igor Mammedov wrote:
> On Wed, 3 May 2017 12:20:22 -0300
> Eduardo Habkost  wrote:
> 
> > On Wed, May 03, 2017 at 02:57:04PM +0200, Igor Mammedov wrote:
> > > Introduce machine_set_cpu_numa_node() helper that stores
> > > node mapping for CPU in MachineState::possible_cpus.
> > > CPU and node it belongs to is specified by 'props' argument.
> > > 
> > > Patch doesn't remove old way of storing mapping in
> > > numa_info[X].node_cpu as removing it at the same time
> > > makes patch rather big. Instead it just mirrors mapping
> > > in possible_cpus and follow up per target patches will
> > > switch to possible_cpus and numa_info[X].node_cpu will
> > > be removed once there isn't any users left.
> > > 
> > > Signed-off-by: Igor Mammedov 
> > > Reviewed-by: David Gibson 
> > > ---
> > >  include/hw/boards.h |  2 ++
> > >  hw/core/machine.c   | 68 
> > > +
> > >  numa.c  |  8 +++
> > >  3 files changed, 78 insertions(+)
> > > 
> > > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > > index 5d6af21..1f518a1 100644
> > > --- a/include/hw/boards.h
> > > +++ b/include/hw/boards.h
> > > @@ -42,6 +42,8 @@ bool machine_dump_guest_core(MachineState *machine);
> > >  bool machine_mem_merge(MachineState *machine);
> > >  void machine_register_compat_props(MachineState *machine);
> > >  HotpluggableCPUList *machine_query_hotpluggable_cpus(MachineState 
> > > *machine);
> > > +void machine_set_cpu_numa_node(MachineState *machine,
> > > +   CpuInstanceProperties *props, Error 
> > > **errp);
> > >  
> > >  /**
> > >   * CPUArchId:
> > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > index ada9eea..a63f17b 100644
> > > --- a/hw/core/machine.c
> > > +++ b/hw/core/machine.c
> > > @@ -388,6 +388,74 @@ HotpluggableCPUList 
> > > *machine_query_hotpluggable_cpus(MachineState *machine)
> > >  return head;
> > >  }
> > >  
> > > +void machine_set_cpu_numa_node(MachineState *machine,
> > > +   CpuInstanceProperties *props, Error 
> > > **errp)  
> > 
> > As the semantics of this function aren't trivial, it would be
> > nice to have a comment explaining what exactly this function do.
> > 
> > e.g.:
> > * make it clear that it could affect multiple CPU slots;
> > * make it clear what does it mean to have props->has_node_id=false as
> >   argument (is it really valid?);
> > * make it clear that it will refuse to change an existing mapping.
> Will be following comment sufficient?
> 
> +/**
> + * machine_set_cpu_numa_node:
> + * @machine: machine object to modify
> + * @props: specifies which cpu objects to assign to
> + * numa node specified by @props.node_id
> + * @errp: if an error occurs, a pointer to an area to store the error
> + *
> + * Associate NUMA node specified by @props.node_id with cpu slots that
> + * match socket/core/thread-ids specified by @props. It's recommended to use
> + * query-hotpluggable-cpus.props values to specify affected cpu slots,
> + * which would lead to exact 1:1 mapping of cpu slots to NUMA node.
> + *
> + * However for CLI convenience it's possible to pass in subset of properties,
> + * which would affect all cpu slots that match it.
> + * Ex for pc machine:
> + *-smp 4,cores=2,sockets=2 -numa node,nodeid=0 -numa node,nodeid=1 \
> + *-numa cpu,node-id=0,socket_id=0 \
> + *-numa cpu,node-id=1,socket_id=1
> + * will assign all child cores of socket 0 to node 0 and
> + * of socket 1 to node 1.
> + *
> + * Empty subset is disallowed and function will return with error in this 
> case.
> + */
>  void machine_set_cpu_numa_node(MachineState *machine,
> CpuInstanceProperties *props, Error **errp)

Sounds good to me.

While at it, we could make 'props' const, as it's not going to be
touched by the function.

-- 
Eduardo

Re: [Qemu-devel] [PATCH 3/5] 9pfs: local: simplify file opening

[Eric Blake]

On 05/05/2017 09:37 AM, Greg Kurz wrote:
> All paths in the virtfs directory now start with "./" (except the virtfs
> root itself which is exactly ".").
> 
> We hence don't need to skip leading '/' characters anymore, nor to handle
> the empty path case. Also, since virtfs will only ever be supported on
> linux+glibc hosts, we can use strchrnul() and come up with a much simplier
> code to walk through the path elements. And we don't need to dup() the
> passed directory fd.
> 
> Signed-off-by: Greg Kurz 
> ---
>  hw/9pfs/9p-local.c |5 -
>  hw/9pfs/9p-util.c  |   26 ++
>  2 files changed, 10 insertions(+), 21 deletions(-)
> 
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index 92262f3c3e37..bb6e296df317 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -54,11 +54,6 @@ int local_open_nofollow(FsContext *fs_ctx, const char 
> *path, int flags,
>  {
>  LocalData *data = fs_ctx->private;
>  
> -/* All paths are relative to the path data->mountfd points to */
> -while (*path == '/') {
> -path++;
> -}

Is it worth adding any assert()s in place of the deleted code?

Otherwise looks okay.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH qemu v6] memory/iommu: QOM'fy IOMMU MemoryRegion

[no-reply]

Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH qemu v6] memory/iommu: QOM'fy IOMMU MemoryRegion
Message-id: 20170505101930.45837-1-...@ozlabs.ru

=== 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

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'
ce1d447 memory/iommu: QOM'fy IOMMU MemoryRegion

=== OUTPUT BEGIN ===
Checking PATCH 1/1: memory/iommu: QOM'fy IOMMU MemoryRegion...
ERROR: spaces required around that '*' (ctx:WxO)
#157: FILE: hw/dma/rc4030.c:720:
+DeviceState *rc4030_init(rc4030_dma **dmas, IOMMUMemoryRegion **dma_mr)
 ^

total: 1 errors, 0 warnings, 844 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...@freelists.org

Re: [Qemu-devel] [PATCH 2/5] 9pfs: local: resolve special directories in paths

[Eric Blake]

On 05/05/2017 09:37 AM, Greg Kurz wrote:
> When using the mapped-file security mode, the creds of a path /foo/bar
> are stored in the /foo/.virtfs_metadata/bar file. This is okay for all
> paths unless they end with '.' or '..', because we cannot create the
> corresponding file in the metadata directory.
> 
> This patch ensures that '.' and '..' are resolved in all paths.
> 
> The core code only passes path elements (no '/') to the backend, with
> the notable exception of the '/' path, which refers to the virtfs root.
> This patch preserve the current behavior of converting it to '.' so

s/preserve/preserves/

> that it can be passed to "*at()" syscalls ('/' would mean the host root).
> 
> Signed-off-by: Greg Kurz 
> ---
>  hw/9pfs/9p-local.c |   30 +++---
>  1 file changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index f3ebca4f7a56..92262f3c3e37 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -1097,14 +1097,30 @@ static int local_name_to_path(FsContext *ctx, 
> V9fsPath *dir_path,
>const char *name, V9fsPath *target)
>  {
>  if (dir_path) {
> -v9fs_path_sprintf(target, "%s/%s", dir_path->data, name);
> -} else if (strcmp(name, "/")) {
> -v9fs_path_sprintf(target, "%s", name);
> +if (!strcmp(name, ".")) {
> +/* "." relative to "foo/bar" is "foo/bar" */
> +v9fs_path_copy(target, dir_path);
> +} else if (!strcmp(name, "..")) {
> +if (!strcmp(dir_path->data, ".")) {
> +/* ".." relative to the root is "." */
> +v9fs_path_sprintf(target, ".");
> +} else {
> +char *tmp = g_path_get_dirname(dir_path->data);
> +/* ".." relative to "foo/bar" is equivalent to "foo" */

True only if bar is not a symlink to some other directory.  What
guarantees do you have that you are not going to be inadvertently
skipping a traversal through symlinks and thereby picking the wrong
location for '..'?

> +v9fs_path_sprintf(target, "%s", tmp);
> +g_free(tmp);
> +}
> +} else {
> +assert(!strchr(name, '/'));
> +v9fs_path_sprintf(target, "%s/%s", dir_path->data, name);
> +}
> +} else if (!strcmp(name, "/") || !strcmp(name, ".") ||
> +   !strcmp(name, "..")) {
> +/* This is the root fid */
> +v9fs_path_sprintf(target, ".");
>  } else {
> -/* We want the path of the export root to be relative, otherwise
> - * "*at()" syscalls would treat it as "/" in the host.
> - */
> -v9fs_path_sprintf(target, "%s", ".");
> +assert(!strchr(name, '/'));
> +v9fs_path_sprintf(target, "./%s", name);
>  }
>  return 0;
>  }
> 
> 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 1/5] 9pfs: check return value of v9fs_co_name_to_path()

[Eric Blake]

On 05/05/2017 09:37 AM, Greg Kurz wrote:
> These v9fs_co_name_to_path() call sites have always been around. I guess
> no care was taken to check the return value because the name_to_path
> operation could never fail at the time. This is no longer true: the
> handle and synth backends can already fail this operation, and so will the
> local backend soon.
> 
> Signed-off-by: Greg Kurz 
> ---
>  hw/9pfs/9p.c |   36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 

> @@ -2588,8 +2591,11 @@ static int coroutine_fn v9fs_complete_rename(V9fsPDU 
> *pdu, V9fsFidState *fidp,
>  new_name = g_malloc0(end - old_name + name->size + 1);
>  strncat(new_name, old_name, end - old_name);
>  strncat(new_name + (end - old_name), name->data, name->size);

Ad long as you're here, you could replace this strncat mess with the
shorter:

new_name = g_strdup_printf("%.*s%.*s", end - old_name, old_name,
   name->size, name->data);

(or with further simplifications if you have NUL-terminated data).  But
that can be a separate cleanup.

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH RESEND v2 02/21] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Eduardo Habkost]

On Fri, May 05, 2017 at 09:36:22AM +0200, Cornelia Huck wrote:
[...]
> > diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> > index c0f560b289..6a2eec8dd0 100644
> > --- a/hw/core/sysbus.c
> > +++ b/hw/core/sysbus.c
> > @@ -326,6 +326,17 @@ static void sysbus_device_class_init(ObjectClass 
> > *klass, void *data)
> >  DeviceClass *k = DEVICE_CLASS(klass);
> >  k->init = sysbus_device_init;
> >  k->bus_type = TYPE_SYSTEM_BUS;
> > +/*
> > + * device_add plugs devices into suitable bus.  For "real" buses,
> 
> s/suitable/a suitable/

Thanks, I will fix it.

> 
> > + * that actually connects the device.  For sysbus, the connections
> > + * need to be made separately, and device_add can't do that.  The
> > + * device would be left unconnected, and will probably not work
> > + *
> > + * However, a few machines and a few devices can handle a few sysbus
> > + * devices. In this case, the device subclass needs to override
> 
> Should that rather be "a few machines can handle a few specific sysbus
> devices"?

I will extend it to "a few machines can handle device_add for a
few specific sysbus devices". Thanks for spotting it.

> 
> > + * it and set user_creatable=true.
> > + */
> > +k->user_creatable = false;
> >  }
> > 
> >  static const TypeInfo sysbus_device_type_info = {
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH RFC] i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf

[Eduardo Habkost]

On Fri, May 05, 2017 at 12:46:21PM +0100, Daniel P. Berrange wrote:
> On Thu, May 04, 2017 at 03:42:41PM -0300, Eduardo Habkost wrote:
> > On Thu, May 04, 2017 at 03:56:58PM +0100, Daniel P. Berrange wrote:
> > > Currently when running KVM, we expose "KVMKVMKVM\0\0\0" in
> > > the 0x4000 CPUID leaf. Other hypervisors (VMWare,
> > > HyperV, Xen, BHyve) all do the same thing, which leaves
> > > TCG as the odd one out.
> > > 
> > > The CPUID is used by software to detect when running in a
> > > virtual environment and change behaviour in certain ways.
> > > For example, systemd supports a ConditionVirtualization=
> > > setting in unit files. Currently they have to resort to
> > > custom hacks like looking for 'fw-cfg' entry in the
> > > /proc/device-tree file. The virt-what command has the
> > > same hacks & needs.
> > > 
> > > This change thus proposes a signature TCGTCGTCGTCG to be
> > > reported when running under TCG.
> > > 
> > > NB1, for reasons I don't undersatnd 'cpu_x86_cpuid' function
> > > clamps the requested CPUID leaf based on env->cpuid_level.
> 
> [snip]
> 
> > > NB2, for KVM, we added a flag for '-cpu kvm=off' to let you
> > > hide the KVMKVMKVM signature from guests. Presumably we should
> > > add a 'tcg=off' flag for the same reason ?
> > 
> > I don't like "kvm=off" because it sounds like it disables KVM
> > completely. "tcg=off" would be misleading as well.
> > 
> > What about a generic "hypervisor-cpuid=off" property?
> 
> Assuming that is intended to obsolete the existing 'kvm' parameter too,
> I'm not seeing a way to introduce that in a backwards compatible safe
> manner.
> 
> eg we add
> 
> DEFINE_PROP_BOOL("hypervisor-cpuid", X86CPU, expose_hypervisor, true),
> 
> and in legacy machine types we need to set
> 
> {\
> .driver   = TYPE_X86_CPU,\
> .property = "hypervisor-cpuid",\
> .value= "off",\
> },\
> 
> to prevent TCGTCGTCGTCG appearing.
> 
> 
> Now in current KVM code we have
> 
> if (cpu->expose_kvm) {
> memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> 
> }
> 
> if we add 'expose_hypervisor' as a generic variable and thus change
> existing KVM code to
> 
> if (cpu->expose_kvm || cpu->expose_hypervisor)
> 
> then to disable the KVMKVMKVMKVM signature, we now need to set *two*
> flags - kvm=off, and hypervisor-cpuid=off and this will break existing
> apps that are only setting kvm=off to disable it.
> 
> Conversely if we do
> 
> if (cpu->expose_kvm && cpu->expose_hypervisor)
> 
> we're going to break KVMKVMKVM signature reporting by default, since
> we need to set hypervisor-cpuid=off in back compat machine types
> to prevent TCGTCGTCGTCG being exposed.
> 
> So it seems we're doomed either way, as we can't distinguish between
> a boolean value that is at its default, vs a boolean value that has
> been explicitly set to a value that matches the default.

That's true, even if we add a hypervisor-cpuid property, we need
a way to represent the behavior of QEMU 2.9 (disabling hypervisor
CPUID only for TCG).

> 
> Having a separate variable just for TCG seems the only viable option
> to me - eg
> 
> DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),

Sounds good to me.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 0/4] Convert non-blocking connect and fix its error reporting

[Daniel P. Berrange]

On Wed, Apr 26, 2017 at 04:04:14PM +0800, Mao Zhongyi wrote:
> v2:
> * PATCH 02 reworking of patch 2 following Markus's suggestion that convert 
> error_report()
>   in the function called by net_socket_*_init() to Error. Also add many error 
> handling
>   information.
> * PATCH 03 net_socket_mcast_create(), net_socket_fd_init_dgram() and 
> net_socket_fd_init() 
>   use the function such as fprintf, perror to report an error message. 
> Convert it to Error.
> * PATCH 04 parse_host_port() may fail without reporting an error. Now, fix it 
> to set an
>   error when it fails.

FYI, I discovered that previous change

  commit 883e4f7624e10b98d16d9adaffb8b1795664d899
  Author: Marc-André Lureau 
  Date:   Sat Jun 18 13:24:02 2016 +0530

Change net/socket.c to use socket_*() functions

has seriously broken the current code because net_socket_fd_init()
was not called from the right place. Fixing the current code is
somewhat painful, so I've sent a revert of that broken patch.

To demo the problem first run:

  $ ./x86_64-softmmu/qemu-system-x86_64  \
  -device e1000,id=e0,netdev=user.0,mac=DE:AD:BE:EF:AF:04 \
  -netdev socket,id=user.0,listen=:1234 

and then run:

   $ ./x86_64-softmmu/qemu-system-x86_64 \
   -device e1000,id=e0,netdev=hn0,mac=DE:AD:BE:EF:AF:05 \
   -netdev socket,id=hn0,connect=localhost:1234

currently the second command fails with

  qemu-system-x86_64: -device e1000,id=e0,netdev=hn0,mac=DE:AD:BE:EF:AF:05: 
Property 'e1000.netdev' can't find value 'hn0'

and my revert fixes that. Just something for you to test with your
new patch series...

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v3] ui: input-linux: Add absolute event support

[no-reply]

Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH v3] ui: input-linux: Add absolute event support
Message-id: 20170505134231.30210-1-philippevoi...@gmail.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-mingw@fedora
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20170504094053.2329-1-quint...@redhat.com -> 
patchew/20170504094053.2329-1-quint...@redhat.com
 - [tag update]  patchew/20170504104806.8120-1-cornelia.h...@de.ibm.com -> 
patchew/20170504104806.8120-1-cornelia.h...@de.ibm.com
Switched to a new branch 'test'
e94ff8b ui: input-linux: Add absolute event support

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-vnz0gdct/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-vnz0gdct/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=da5127cf5c64
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi support