Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level

[Laurent Vivier]

Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic 
> 
> Hello, folks!
> 
> This series is a spin-off of another larger linux-user series
> that become too large to handle, hence these patches related to
> syscall numbers are now in this, separate, series.
> 
> Now that kernel 5.5 is released few days ago, it is time to
> reflect what can be updated in linux-user for upcomming QEMU 5.0.
> 
> An obvoius kernel change we should take into account are new
> system calls, and the foirst step is updating syscall numbers
> mainteined within QEMU linux-user.
> 
> Regarding kernel syscal numbers there is good news and bad news.
> 
> The good news is that kernel developers decided to make future
> syscall numbers much more synchonized accross architectures than
> before. They already reached that state.
> 
> The bad news is that we in QEMU did not reach that state yet, since
> we lag after kernel significantly.
> 
> The good news again is that we will reach that state if we update
> syscall numbers accross the board now. This is the main intention
> and motivation of this series.
> 
> The bad news again is that in order to update syscall numebrs we
> need to be very careful at this moment. There are a number of new
> syscalls added to the kernel recently that QEMU doesn't know about
> at all. Significant number of new syscalls deal with 32/64-bit
> compatibility, traditionally a problematic area in kernel, and in
> QEMU as well. Moreover, some of the new syscalls are applicable to
> 32-bit architectures only.
> 
> This series covers updating syscall numbers defined in the following
> files:
> 
>   - linux-user/alpha/syscall_nr.h
>   - linux-user/arm/syscall_nr.h
>   - linux-user/m68k/syscall_nr.h
>   - linux-user/microblaze/syscall_nr.h
>   - linux-user/mips/cpu_loop.c
>   - linux-user/mips/syscall_nr.h
>   - linux-user/mips64/syscall_nr.h
>   - linux-user/sh4/syscall_nr.h
>   - linux-user/x86_64/syscall_nr.h
>   - linux-user/xtensa/syscall_nr.h
> 
> This series doesn't cover following files (since they use certain
> proprietary rules for mapping between kernel source and qemu source,
> I don't feel quite comfortable changing them - therefore I am asking
> corresponding target maintainers or Lauren to update them, if
> possible, before our 5.0 release):
> 
>   - linux-user/aarch64/syscall_nr.h
>   - linux-user/i386/syscall_nr.h
>   - linux-user/nios2/syscall_nr.h
>   - linux-user/ppc/syscall_nr.h
>   - linux-user/riscv/syscall_nr.h
>   - linux-user/s390x/syscall_nr.h
>   - linux-user/sparc/syscall_nr.h
>   - linux-user/sparc64/syscall_nr.h
> 
> CC: Peter Maydell 
> CC: Paolo Bonzini 
> CC: Richard Henderson 
> CC: Eduardo Habkost 
> CC: Chris Wulff 
> CC: Marek Vasut 
> CC: David Gibson 
> CC: Palmer Dabbelt 
> CC: Alistair Francis 
> CC: Sagar Karandikar 
> CC: Bastian Koppelmann 
> CC: David Hildenbrand 
> CC: Mark Cave-Ayland 
> CC: Artyom Tarasenko 
> 
> This series also doesn't cover following files (since I can't find
> corresponding kernel code - and I am also asking corresponding
> target maintainers or Lauren to update them, if possible, before
> our 5.0 release):
> 
>   - linux-user/cris/cpu_loop.c
>   - linux-user/hppa/syscall_nr.h
>   - linux-user/openrisc/syscall_nr.h
>   - linux-user/tilegx/syscall_nr.h
> 
> CC: Edgar E. Iglesias 
> CC: Richard Henderson 
> CC: Stafford Horne 
> 
> Again, I don't plan (I am really running out of time resources) to
> work in a significant way on this issue any more, and I am asking
> you guys other maintainers to help finish updating syscall numbers
> before QEMU 5.0 release.
> 
> Once we do that, updating syscall numbers in QEMU should and will
> be significantly easier.
> 

I think we should copy the syscall.tbl and syscallhdr.sh scripts from
the linux tree and update syscallhdr.sh to generate our syscall_nr.h

I think it can be done in an easy way for most of our targets, except
some like mips that mixes o32, n32, n64 and a special table inside
cpu_loop.c

I will merge your patches (please update the mips one) as the work is
already done but I will have a look to try to generate them for the next
time from the kernel tables.

Thanks,
Laurent

Re: [PATCH v3 07/17] hw/arm/allwinner: add Security Identifier device

[Niek Linnenbank]

Hi Corey,

On Thu, Feb 6, 2020 at 10:09 PM Niek Linnenbank 
wrote:

> Hi Corey,
>
> On Mon, Feb 3, 2020 at 2:10 PM Corey Minyard  wrote:
>
>> On Sun, Feb 02, 2020 at 10:27:49PM +0100, Niek Linnenbank wrote:
>> > Hi Corey,
>> >
>> > Thanks for reviewing!
>> >
>> > On Mon, Jan 20, 2020 at 6:59 PM Corey Minyard 
>> wrote:
>> >
>> > > On Sat, Jan 18, 2020 at 04:25:08PM +0100, Philippe Mathieu-Daudé
>> wrote:
>> > > > Cc'ing Corey/David for good advices about using UUID.
>> > >
>> > > Is there any reason you didn't use the built-in qemu UUID for this?
>> It
>> > > would simplify things in general.
>> > >
>> >
>> > Currently the Allwinner SID device is using the QemuUUID type from
>> > include/qemu/uuid.h.
>> > Is that the build-in UUID you are referring to or should I use something
>> > else?
>>
>> You are using the QemuUUID type, which is of course what you should do,
>> but you aren't using the UUID generated by qemu (at least that I can
>> find).
>> That in include/sysemu/sysemu.h and is named qemu_uuid.  Whether you
>> should use that or not depends on your needs.  If you just need some
>> uuid, then that's what you should probably use.  If you need something
>> the user can individually control for this device, for instance, then
>> that probably won't do.
>>
>
> Ah I did not know about the qemu_uuid variable, thanks for pointing that
> out.
> Basically the SID identifier is a number that is unique for each board
> that comes
> out of the factory. It is currently used by U-Boot to as input to generate
> a MAC address.
>
> If I understand correctly, qemu_uuid is optional and by default zero.
> However the SID value should not be zero, as otherwise U-Boot can't pick a
> MAC address
> resulting in a non-working ethernet device.
>
> Currently the hw/arm/orangepi.c machine specifies a fixed SID to be used
> for the emulated board,
> also containing a prefix (8100c002) that indicates the H3 chipset. One
> thing that I am strugling with is that
> I'm not able to override the property using '-global', if
> hw/arm/orangepi.c initializes the property with qdev_prop_set_string:
>
> $ qemu-system-arm -M orangepi-pc -kernel u-boot -nographic -nic user \
> -global allwinner-sid.identifier=8100c002-0001-0002-0003-44556688
>
> If I don't set the property in hw/arm/orangepi.c, I can set it with
> '-global'. Do you perhaps have a
> recommendation how to improve that? Basically what is needed is that the
> machine sets the default
> property including the chip prefix, and that the user can override it.
> Although it is not required for a
> working emulated board, it would be a nice-to-have that the user can set
> it.
>

FYI and possibly others who have a similar usecase, I figured out how to do
this. In the machine init function,
after creating the new SoC object, simply check if the identifier has a
value:

+if (qemu_uuid_is_null(&s->h3->sid.identifier)) {
+qdev_prop_set_string(DEVICE(s->h3), "identifier",
+ "8100c002-0001-0002-0003-44556677");
+}

That way, if the user passed -global to override it, the machine will not
overrule the user's value
and by default the machine sets an identifier containing the H3 specific
chip prefix.

Regards,
Niek


>
>> >
>> >
>> > > Also, in case no one else say, you have tabs in your code that you
>> need
>> > > to get rid of.
>> > >
>> > >
>> > If there are any tabs in the code, it was not intended. I re-checked
>> this
>> > patch and others
>> > again but found no tabs in the code.
>> > Could you please point out where you found the extra tabs?
>>
>> My apologies, I saw 1-character misalignments, and that usually means
>> that there's a tab.  But it looks like it has something to do with the
>> way it was forwarded.  I didn't get the original email.
>>
>> Ah yes that is possible indeed. I'll add you to the CC list for the next
> version of this patch series.
>
> Regards,
> Niek
>
>
>> -corey
>>
>> >
>> > Regards,
>> > Niek
>> >
>> >
>> > > -corey
>> > >
>> > > >
>> > > > On 1/8/20 9:00 PM, Niek Linnenbank wrote:
>> > > > > The Security Identifier device found in various Allwinner System
>> on
>> > > Chip
>> > > > > designs gives applications a per-board unique identifier. This
>> commit
>> > > > > adds support for the Allwinner Security Identifier using a 128-bit
>> > > > > UUID value as input.
>> > > > >
>> > > > > Signed-off-by: Niek Linnenbank 
>> > > > > ---
>> > > > >   include/hw/arm/allwinner-h3.h   |   3 +
>> > > > >   include/hw/misc/allwinner-sid.h |  61 
>> > > > >   hw/arm/allwinner-h3.c   |  11 ++-
>> > > > >   hw/arm/orangepi.c   |   4 +
>> > > > >   hw/misc/allwinner-sid.c | 170
>> > > 
>> > > > >   hw/misc/Makefile.objs   |   1 +
>> > > > >   hw/misc/trace-events|   4 +
>> > > > >   7 files changed, 253 insertions(+), 1 deletion(-)
>> > > > >   create mode 100644 include/hw/misc/allwinner-sid.h
>> > > > >   create mode 100644 hw/m

Re: [PATCH 2/9] linux-user: arm: Update syscall numbers to kernel 5.5 level

[Laurent Vivier]

Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic 
> 
> Update arm syscall numbers based on Linux kernel v5.5.
> 
> CC: Peter Maydell 
> Signed-off-by: Aleksandar Markovic 
> ---
>  linux-user/arm/syscall_nr.h | 44 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/linux-user/arm/syscall_nr.h b/linux-user/arm/syscall_nr.h
> index e7eda0d..6db9235 100644
> --- a/linux-user/arm/syscall_nr.h
> +++ b/linux-user/arm/syscall_nr.h
> @@ -399,5 +399,49 @@
>  #define TARGET_NR_userfaultfd  (388)
>  #define TARGET_NR_membarrier   (389)
>  #define TARGET_NR_mlock2   (390)
> +#define TARGET_NR_copy_file_range  (391)
> +#define TARGET_NR_preadv2  (392)
> +#define TARGET_NR_pwritev2 (393)
> +#define TARGET_NR_pkey_mprotect(394)
> +#define TARGET_NR_pkey_alloc   (395)
> +#define TARGET_NR_pkey_free(396)
> +#define TARGET_NR_statx(397)
> +#define TARGET_NR_rseq (398)
> +#define TARGET_NR_io_pgetevents(399)
> +#define TARGET_NR_migrate_pages(400)
> +#define TARGET_NR_kexec_file_load  (401)
> +/* 402 is unused */
> +#define TARGET_NR_clock_gettime64  (403)
> +#define TARGET_NR_clock_settime64  (404)
> +#define TARGET_NR_clock_adjtime64  (405)
> +#define TARGET_NR_clock_getres_time64  (406)
> +#define TARGET_NR_clock_nanosleep_time64   (407)
> +#define TARGET_NR_timer_gettime64  (408)
> +#define TARGET_NR_timer_settime64  (409)
> +#define TARGET_NR_timerfd_gettime64(410)
> +#define TARGET_NR_timerfd_settime64(411)
> +#define TARGET_NR_utimensat_time64 (412)
> +#define TARGET_NR_pselect6_time64  (413)
> +#define TARGET_NR_ppoll_time64 (414)
> +#define TARGET_NR_io_pgetevents_time64 (416)
> +#define TARGET_NR_recvmmsg_time64  (417)
> +#define TARGET_NR_mq_timedsend_time64  (418)
> +#define TARGET_NR_mq_timedreceive_time64   (419)
> +#define TARGET_NR_semtimedop_time64(420)
> +#define TARGET_NR_rt_sigtimedwait_time64   (421)
> +#define TARGET_NR_futex_time64 (422)
> +#define TARGET_NR_sched_rr_get_interval_time64 (423)
> +#define TARGET_NR_pidfd_send_signal(424)
> +#define TARGET_NR_io_uring_setup   (425)
> +#define TARGET_NR_io_uring_enter   (426)
> +#define TARGET_NR_io_uring_register(427)
> +#define TARGET_NR_open_tree(428)
> +#define TARGET_NR_move_mount   (429)
> +#define TARGET_NR_fsopen   (430)
> +#define TARGET_NR_fsconfig (431)
> +#define TARGET_NR_fsmount  (432)
> +#define TARGET_NR_fspick   (433)
> +#define TARGET_NR_pidfd_open   (434)
> +#define TARGET_NR_clone3   (435)
>  
>  #endif
> 

Reviewed-by: Laurent Vivier 

Re: Question: SiFive U SPI and SD

[Alistair Francis]

On Mon, Feb 10, 2020 at 7:51 AM Bin Meng  wrote:
>
> Hi Nikita,
>
> On Sun, Feb 9, 2020 at 10:56 PM Nikita Ermakov  wrote:
> >
> > Hello!
> >
> > I am trying to make an SD card working on the sifive_u 
> > (hw/riscv/sifive_u.c) SoC machine.
> > As far as I understand there is no way to connect an SD card to the SoC 
> > with cmdline for now. So, I started to dig in to the QEMU internals and 
> > especially sifive_u SoC implementation to try to understand how I could 
> > connect SD card to this SoC.
> >
> > From what I understood I need to:
> > 1) Implement SiFive U SPI controller.
>
> This one is definitely needed.
>
> > 2) Implement spi-sd adapter in a way like the hw/sd/ssi-sd.c
>
> I believe we can just use hw/sd/ssi-sd.c.

I had a crack at this awhile ago and you can see the patches here (I
just rebased them):
https://github.com/alistair23/qemu/tree/mainline/alistair/sifive_spi.next

Debugging failures was really hard in Linux, but now that U-Boot and
Oreboot (https://github.com/oreboot/oreboot/pull/234) have SPI support
it is probably easier to debug.

If you wanted to help you could try to debug that branch and figure
out why it isn't working.

Alistair

>
> >
> > Probably I should merge 1) and 2) into one hw/riscv/sifive_u_spi.c source 
> > file.
> >
> > Could somebody correct me please if I am wrong at some point?
> > I am newbie in the QEMU internals :)
> >
> > The purpose is why I want to implement this is to boot up the Linux kernel 
> > on '-machine sifive_u' and load rootfs from SD.
>
> Regards,
> Bin
>

Re: [PATCH 5/9] linux-user: mips: Update syscall numbers to kernel 5.5 level

[Laurent Vivier]

Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic 
> 
> Update mips syscall numbers based on Linux kernel tag v5.5.
> 
> CC: Aurelien Jarno 
> CC: Aleksandar Rikalo 
> Signed-off-by: Aleksandar Markovic 
> ---
>  linux-user/mips/cpu_loop.c | 78 
> +-
>  linux-user/mips/syscall_nr.h   | 45 
>  linux-user/mips64/syscall_nr.h | 13 +++
>  3 files changed, 135 insertions(+), 1 deletion(-)
> 
> diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c
> index 39915b3..b81479b 100644
> --- a/linux-user/mips/cpu_loop.c
> +++ b/linux-user/mips/cpu_loop.c
> @@ -25,8 +25,9 @@
>  #include "internal.h"
>  
>  # ifdef TARGET_ABI_MIPSO32
> +#  define MIPS_SYSCALL_NUMBER_UNUSED -1
>  #  define MIPS_SYS(name, args) args,
> -static const uint8_t mips_syscall_args[] = {
> +static const int8_t mips_syscall_args[] = {
>  MIPS_SYS(sys_syscall, 8)/* 4000 */
>  MIPS_SYS(sys_exit   , 1)
>  MIPS_SYS(sys_fork   , 0)
> @@ -390,6 +391,75 @@ static const uint8_t mips_syscall_args[] = {
>  MIPS_SYS(sys_copy_file_range, 6) /* 360 */
>  MIPS_SYS(sys_preadv2, 6)
>  MIPS_SYS(sys_pwritev2, 6)
> +MIPS_SYS(sys_pkey_mprotect, 4)
> +MIPS_SYS(sys_pkey_alloc, 2)
> +MIPS_SYS(sys_pkey_free, 1) /* 365 */
> +MIPS_SYS(sys_statx, 5)
> +MIPS_SYS(sys_rseq, 4)
> +MIPS_SYS(sys_io_pgetevents, 6)
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 370 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 375 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 380 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 385 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 390 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYS(sys_semget, 3)
> +MIPS_SYS(sys_semctl, 4)
> +MIPS_SYS(sys_shmget, 3)/* 395 */
> +MIPS_SYS(sys_shmctl, 3)
> +MIPS_SYS(sys_shmat, 3)
> +MIPS_SYS(sys_shmdt, 1)
> +MIPS_SYS(sys_msgget, 2)
> +MIPS_SYS(sys_msgsnd, 4)/* 400 */
> +MIPS_SYS(sys_msgrcv, 5)
> +MIPS_SYS(sys_msgctl, 3)
> +MIPS_SYS(sys_timer_gettime64, 2)
> +MIPS_SYS(sys_timer_settime64, 4)
> +MIPS_SYS(sys_timerfd_gettime64, 2) /* 410 */
> +MIPS_SYS(sys_timerfd_settime64, 4)

These have different names in the kernel:

clock_gettime64  403
clock_settime64  404
clock_adjtime64  405
clock_getres_time64  406
clock_nanosleep_time64   407

> +MIPS_SYS(sys_utimensat_time64, 4)
> +MIPS_SYS(sys_pselect6_time64, 6)
> +MIPS_SYS(sys_ppoll_time64, 5)
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 415 */
> +MIPS_SYS(sys_io_pgetevents_time64, 6)
> +MIPS_SYS(sys_recvmmsg_time64, 5)
> +MIPS_SYS(sys_mq_timedsend_time64, 5)
> +MIPS_SYS(sys_mq_timedreceive_time64, 5)
> +MIPS_SYS(sys_semtimedop_time64, 4) /* 420 */
> +MIPS_SYS(sys_rt_sigtimedwait_time64, 4)
> +MIPS_SYS(sys_futex_time64, 6)
> +MIPS_SYS(sys_sched_rr_get_interval_time64, 2)
> +MIPS_SYS(sys_pidfd_send_signal, 4)
> +MIPS_SYS(sys_io_uring_setup, 2)/* 425 */
> +MIPS_SYS(sys_io_uring_enter, 6)
> +MIPS_SYS(sys_io_uring_register, 4)
> +MIPS_SYS(sys_open_tree, 3)
> +MIPS_SYS(sys_move_mount, 5)
> +MIPS_SYS(sys_fsopen, 2)/* 430 */
> +MIPS_SYS(sys_fsconfig, 5)
> +MIPS_SYS(sys_fsmount, 3)
> +MIPS_SYS(sys_fspick, 3)
> +MIPS_SYS(sys_pidfd_open, 2)
> +MIPS_SYS(sys_clone3, 2)/* 435 */

This comes from arch/mips/kernel/syscalls/syscall_o32.tbl for the
syscall number.

Where do you find the number of the arguments in the kernel?

> +
>  };
>  #  undef MIPS_SYS
>  # endif /* O32 */
> @@ -447,8 +517,14 @@ void cpu_loop(CPUMIPSState *env)
>  # ifdef TARGET_ABI_MIPSO32
>  syscall_num = env->active_tc.gpr[2] - 4000;
>  if (syscall_num >= sizeof(mips_syscall_args)) {
> +/* syscall_num is large

[PULL 0/2] Usb 20200212 patches

[Gerd Hoffmann]

The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730:

  Merge remote-tracking branch 
'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging (2020-02-10 
18:09:14 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/usb-20200212-pull-request

for you to fetch changes up to 8ddcc43592f215a7523774704df6c60d12d9f647:

  uas: fix super speed bMaxPacketSize0 (2020-02-12 17:20:41 +0100)


usb: bugfixes



Gerd Hoffmann (2):
  usb-host: wait for cancel complete
  uas: fix super speed bMaxPacketSize0

 hw/usb/dev-uas.c |  2 +-
 hw/usb/host-libusb.c | 17 +
 2 files changed, 10 insertions(+), 9 deletions(-)

-- 
2.18.2

[PULL 2/2] uas: fix super speed bMaxPacketSize0

[Gerd Hoffmann]

For usb2 bMaxPacketSize0 is "n", for usb3 it is "1 << n",
so it must be 9 not 64 ...

rom "Universal Serial Bus 3.1 Specification":

   If the device is operating at Gen X speed, the bMaxPacketSize0
   field shall be set to 09H indicating a 512-byte maximum packet.
   An Enhanced SuperSpeed device shall not support any other maximum
   packet sizes for the default control pipe (endpoint 0) control
   endpoint.

We now announce a 512-byte maximum packet.

Fixes: 89a453d4a5c ("uas-uas: usb3 streams")
Reported-by: Benjamin David Lunt 
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20200117073716.31335-1-kra...@redhat.com
---
 hw/usb/dev-uas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/dev-uas.c b/hw/usb/dev-uas.c
index 9825ec37d09c..11a8684cc2ab 100644
--- a/hw/usb/dev-uas.c
+++ b/hw/usb/dev-uas.c
@@ -303,7 +303,7 @@ static const USBDescDevice desc_device_high = {
 
 static const USBDescDevice desc_device_super = {
 .bcdUSB= 0x0300,
-.bMaxPacketSize0   = 64,
+.bMaxPacketSize0   = 9,
 .bNumConfigurations= 1,
 .confs = (USBDescConfig[]) {
 {
-- 
2.18.2

[PULL 1/2] usb-host: wait for cancel complete

[Gerd Hoffmann]

After canceling transfers call into libvirt so it can process the
request, and wait for it to complete.  Also cancel all pending
transfers before exiting qemu.

Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1749745
Signed-off-by: Gerd Hoffmann 
Message-id: 20200203114108.23952-1-kra...@redhat.com
---
 hw/usb/host-libusb.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index 259470090102..2ac7a936fb91 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -354,9 +354,7 @@ static USBHostRequest *usb_host_req_alloc(USBHostDevice *s, 
USBPacket *p,
 
 static void usb_host_req_free(USBHostRequest *r)
 {
-if (r->host) {
-QTAILQ_REMOVE(&r->host->requests, r, next);
-}
+QTAILQ_REMOVE(&r->host->requests, r, next);
 libusb_free_transfer(r->xfer);
 g_free(r->buffer);
 g_free(r);
@@ -468,12 +466,7 @@ static void usb_host_req_abort(USBHostRequest *r)
 usb_packet_complete(USB_DEVICE(s), r->p);
 }
 r->p = NULL;
-}
 
-QTAILQ_REMOVE(&r->host->requests, r, next);
-r->host = NULL;
-
-if (inflight) {
 libusb_cancel_transfer(r->xfer);
 }
 }
@@ -962,6 +955,13 @@ static void usb_host_abort_xfers(USBHostDevice *s)
 QTAILQ_FOREACH_SAFE(r, &s->requests, next, rtmp) {
 usb_host_req_abort(r);
 }
+
+while (QTAILQ_FIRST(&s->requests) != NULL) {
+struct timeval tv;
+memset(&tv, 0, sizeof(tv));
+tv.tv_usec = 2500;
+libusb_handle_events_timeout(ctx, &tv);
+}
 }
 
 static int usb_host_close(USBHostDevice *s)
@@ -1011,6 +1011,7 @@ static void usb_host_exit_notifier(struct Notifier *n, 
void *data)
 USBHostDevice *s = container_of(n, USBHostDevice, exit);
 
 if (s->dh) {
+usb_host_abort_xfers(s);
 usb_host_release_interfaces(s);
 libusb_reset_device(s->dh);
 usb_host_attach_kernel(s);
-- 
2.18.2

Re: [PATCH v12 Kernel 1/7] vfio: KABI for migration interface for device state

[Kirti Wankhede]

On 2/10/2020 10:55 PM, Alex Williamson wrote:

On Sat, 8 Feb 2020 01:12:28 +0530
Kirti Wankhede  wrote:


- Defined MIGRATION region type and sub-type.

- Defined vfio_device_migration_info structure which will be placed at 0th
   offset of migration region to get/set VFIO device related information.
   Defined members of structure and usage on read/write access.

- Defined device states and state transition details.

- Defined sequence to be followed while saving and resuming VFIO device.

Signed-off-by: Kirti Wankhede 
Reviewed-by: Neo Jia 
---
  include/uapi/linux/vfio.h | 208 ++
  1 file changed, 208 insertions(+)

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 9e843a147ead..572242620ce9 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -305,6 +305,7 @@ struct vfio_region_info_cap_type {
  #define VFIO_REGION_TYPE_PCI_VENDOR_MASK  (0x)
  #define VFIO_REGION_TYPE_GFX(1)
  #define VFIO_REGION_TYPE_CCW  (2)
+#define VFIO_REGION_TYPE_MIGRATION  (3)
  
  /* sub-types for VFIO_REGION_TYPE_PCI_* */
  
@@ -379,6 +380,213 @@ struct vfio_region_gfx_edid {

  /* sub-types for VFIO_REGION_TYPE_CCW */
  #define VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD (1)
  
+/* sub-types for VFIO_REGION_TYPE_MIGRATION */

+#define VFIO_REGION_SUBTYPE_MIGRATION   (1)
+
+/*
+ * Structure vfio_device_migration_info is placed at 0th offset of
+ * VFIO_REGION_SUBTYPE_MIGRATION region to get/set VFIO device related 
migration
+ * information. Field accesses from this structure are only supported at their
+ * native width and alignment, otherwise the result is undefined and vendor
+ * drivers should return an error.
+ *
+ * device_state: (read/write)
+ *  - User application writes this field to inform vendor driver about the
+ *device state to be transitioned to.
+ *  - Vendor driver should take necessary actions to change device state.
+ *On successful transition to given state, vendor driver should return
+ *success on write(device_state, state) system call. If device state
+ *transition fails, vendor driver should return error, -EFAULT.


s/error, -EFAULT/an appropriate -errno for the fault condition/


+ *  - On user application side, if device state transition fails, i.e. if
+ *write(device_state, state) returns error, read device_state again to
+ *determine the current state of the device from vendor driver.
+ *  - Vendor driver should return previous state of the device unless 
vendor
+ *driver has encountered an internal error, in which case vendor driver
+ *may report the device_state VFIO_DEVICE_STATE_ERROR.
+ * - User application must use the device reset ioctl in order to recover
+ *   the device from VFIO_DEVICE_STATE_ERROR state. If the device is
+ *   indicated in a valid device state via reading device_state, the user
+ *   application may decide attempt to transition the device to any valid
+ *   state reachable from the current state or terminate itself.
+ *
+ *  device_state consists of 3 bits:
+ *  - If bit 0 set, indicates _RUNNING state. When it's clear, that
+ *   indicates _STOP state. When device is changed to _STOP, driver should
+ *   stop device before write() returns.
+ *  - If bit 1 set, indicates _SAVING state. When set, that indicates 
driver
+ *should start gathering device state information which will be 
provided
+ *to VFIO user application to save device's state.
+ *  - If bit 2 set, indicates _RESUMING state. When set, that indicates
+ *prepare to resume device, data provided through migration region
+ *should be used to resume device.
+ *  Bits 3 - 31 are reserved for future use. In order to preserve them,
+ * user application should perform read-modify-write operation on this
+ * field when modifying the specified bits.
+ *
+ *  +--- _RESUMING
+ *  |+-- _SAVING
+ *  ||+- _RUNNING
+ *  |||
+ *  000b => Device Stopped, not saving or resuming
+ *  001b => Device running state, default state
+ *  010b => Stop Device & save device state, stop-and-copy state
+ *  011b => Device running and save device state, pre-copy state
+ *  100b => Device stopped and device state is resuming
+ *  101b => Invalid state
+ *  110b => Error state
+ *  111b => Invalid state
+ *
+ * State transitions:
+ *
+ *  _RESUMING  _RUNNINGPre-copyStop-and-copy   _STOP
+ *(100b) (001b) (011b)(010b)   (000b)
+ * 0. Running or Default state
+ * |
+ *
+ * 1. Normal Shutdown (optional)
+ * |->|
+ *
+ * 2. Save state or Suspend
+ * |->|-->|
+ *
+ * 3. Save state during live migration
+ *

Re: [PATCH v12 Kernel 4/7] vfio iommu: Implementation of ioctl to for dirty pages tracking.

[Kirti Wankhede]

On 2/10/2020 10:55 PM, Alex Williamson wrote:

On Sat, 8 Feb 2020 01:12:31 +0530
Kirti Wankhede  wrote:


VFIO_IOMMU_DIRTY_PAGES ioctl performs three operations:
- Start pinned and unpinned pages tracking while migration is active
- Stop pinned and unpinned dirty pages tracking. This is also used to
   stop dirty pages tracking if migration failed or cancelled.
- Get dirty pages bitmap. This ioctl returns bitmap of dirty pages, its
   user space application responsibility to copy content of dirty pages
   from source to destination during migration.

To prevent DoS attack, memory for bitmap is allocated per vfio_dma
structure. Bitmap size is calculated considering smallest supported page
size. Bitmap is allocated when dirty logging is enabled for those
vfio_dmas whose vpfn list is not empty or whole range is mapped, in
case of pass-through device.

There could be multiple option as to when bitmap should be populated:
* Polulate bitmap for already pinned pages when bitmap is allocated for
   a vfio_dma with the smallest supported page size. Updates bitmap from
   page pinning and unpinning functions. When user application queries
   bitmap, check if requested page size is same as page size used to
   populated bitmap. If it is equal, copy bitmap. But if not equal,
   re-populated bitmap according to requested page size and then copy to
   user.
   Pros: Bitmap gets populated on the fly after dirty tracking has
 started.
   Cons: If requested page size is different than smallest supported
 page size, then bitmap has to be re-populated again, with
 additional overhead of allocating bitmap memory again for
 re-population of bitmap.


No memory needs to be allocated to re-populate the bitmap.  The bitmap
is clear-on-read and by tracking the bitmap in the smallest supported
page size we can guarantee that we can fit the user requested bitmap
size within the space occupied by that minimal page size range of the
bitmap.  Therefore we'd destructively translate the requested region of
the bitmap to a different page size, write it out to the user, and
clear it.  Also we expect userspace to use the minimum page size almost
exclusively, which is optimized by this approach as dirty bit tracking
is spread out over each page pinning operation.



* Populate bitmap when bitmap is queried by user application.
   Pros: Bitmap is populated with requested page size. This eliminates
 the need to re-populate bitmap if requested page size is
 different than smallest supported pages size.
   Cons: There is one time processing time, when bitmap is queried.


Another significant Con is that the vpfn list needs to track and manage
unpinned pages, which makes it more complex and intrusive.  The
previous option seems to have both time and complexity advantages,
especially in the case we expect to be most common of the user
accessing the bitmap with the minimum page size, ie. PAGE_SIZE.  It's
also not clear why we pre-allocate the bitmap at all with this approach.


I prefer later option with simple logic and to eliminate over-head of
bitmap repopulation in case of differnt page sizes. Later option is
implemented in this patch.


Hmm, we'll see below, but I not convinced based on the above rationale.


Signed-off-by: Kirti Wankhede 
Reviewed-by: Neo Jia 
---
  drivers/vfio/vfio_iommu_type1.c | 299 ++--
  1 file changed, 287 insertions(+), 12 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index d386461e5d11..df358dc1c85b 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -70,6 +70,7 @@ struct vfio_iommu {
unsigned intdma_avail;
boolv2;
boolnesting;
+   booldirty_page_tracking;
  };
  
  struct vfio_domain {

@@ -90,6 +91,7 @@ struct vfio_dma {
boollock_cap;   /* capable(CAP_IPC_LOCK) */
struct task_struct  *task;
struct rb_root  pfn_list;   /* Ex-user pinned pfn list */
+   unsigned long   *bitmap;
  };
  
  struct vfio_group {

@@ -125,6 +127,7 @@ struct vfio_regions {
(!list_empty(&iommu->domain_list))
  
  static int put_pfn(unsigned long pfn, int prot);

+static unsigned long vfio_pgsize_bitmap(struct vfio_iommu *iommu);
  
  /*

   * This code handles mapping and unmapping of user data buffers
@@ -174,6 +177,57 @@ static void vfio_unlink_dma(struct vfio_iommu *iommu, 
struct vfio_dma *old)
rb_erase(&old->node, &iommu->dma_list);
  }
  
+static inline unsigned long dirty_bitmap_bytes(unsigned int npages)

+{
+   if (!npages)
+   return 0;
+
+   return ALIGN(npages, BITS_PER_LONG) / sizeof(unsigned long);
+}
+
+static int vfio_dma_bitmap_alloc(struct vfio_iommu *iommu,
+struct vfio_dma *dma, unsign

Re: [PATCH v1 5/5] travis.yml: Test the s390-ccw build, too

[Philippe Mathieu-Daudé]

On 2/7/20 12:39 PM, Alex Bennée wrote:

From: Thomas Huth 

Since we can now use a s390x host on Travis, we can also build and
test the s390-ccw bios images there. For this we have to make sure
that roms/SLOF is checked out, too, and then move the generated *.img
files to the right location before running the tests.

Signed-off-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Message-Id: <20200206202543.7085-1-th...@redhat.com>
---
  .travis.yml | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 6c0ec6cf69f..c0eeff9caa9 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -508,6 +508,16 @@ matrix:
env:
  - TEST_CMD="make check check-tcg V=1"
  - CONFIG="--disable-containers 
--target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
+  script:
+- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
+- BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
+- |
+  if [ "$BUILD_RC" -eq 0 ] ; then
+  mv pc-bios/s390-ccw/*.img pc-bios/ ;
+  ${TEST_CMD} ;
+  else
+  $(exit $BUILD_RC);
+  fi
  
  # Release builds

  # The make-release script expect a QEMU version, so our tag must start 
with a 'v'.



Already reviewed/tested [*] with comment:

Maybe remove the trailing ", too" in subject...

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

[*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg677641.html

Re: [PATCH v1 3/5] tests/rcutorture: better document locking of stats

[Philippe Mathieu-Daudé]

On 2/7/20 12:39 PM, Alex Bennée wrote:

This is pure code motion with no functional effect.

Signed-off-by: Alex Bennée 
---
  tests/rcutorture.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tests/rcutorture.c b/tests/rcutorture.c
index e8b2169e7dd..256d24ed5ba 100644
--- a/tests/rcutorture.c
+++ b/tests/rcutorture.c
@@ -65,8 +65,6 @@
  #include "qemu/rcu.h"
  #include "qemu/thread.h"
  
-long long n_reads = 0LL;

-long n_updates = 0L;
  int nthreadsrunning;
  
  #define GOFLAG_INIT 0

@@ -78,11 +76,20 @@ static volatile int goflag = GOFLAG_INIT;
  #define RCU_READ_RUN 1000
  
  #define NR_THREADS 100

-static QemuMutex counts_mutex;
  static QemuThread threads[NR_THREADS];
  static struct rcu_reader_data *data[NR_THREADS];
  static int n_threads;
  
+/*

+ * Statistical counts
+ *
+ * These are the sum of local counters at the end of a run.
+ * Updates are protected by a mutex.
+ */
+static QemuMutex counts_mutex;
+long long n_reads = 0LL;
+long n_updates = 0L;
+
  static void create_thread(void *(*func)(void *))
  {
  if (n_threads >= NR_THREADS) {
@@ -230,8 +237,9 @@ struct rcu_stress {
  struct rcu_stress rcu_stress_array[RCU_STRESS_PIPE_LEN] = { { 0 } };
  struct rcu_stress *rcu_stress_current;
  int rcu_stress_idx;
-
  int n_mberror;
+
+/* Updates protected by counts_mutex */
  long long rcu_stress_count[RCU_STRESS_PIPE_LEN + 1];
  
  



Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v1 2/5] tests/rcutorture: update usage hint

[Philippe Mathieu-Daudé]

On 2/7/20 12:39 PM, Alex Bennée wrote:

Although documented in the comments we don't display all the various
invocations we can in the usage.

Signed-off-by: Alex Bennée 
---
  tests/rcutorture.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/rcutorture.c b/tests/rcutorture.c
index 49311c82ea4..e8b2169e7dd 100644
--- a/tests/rcutorture.c
+++ b/tests/rcutorture.c
@@ -413,7 +413,8 @@ static void gtest_stress_10_5(void)
  
  static void usage(int argc, char *argv[])

  {
-fprintf(stderr, "Usage: %s [nreaders [ perf | stress ] ]\n", argv[0]);
+fprintf(stderr, "Usage: %s [nreaders [ [r|u]perf | stress [duration]]\n",
+argv[0]);
  exit(-1);
  }
  



Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 6/9] linux-user: sh4: Update syscall numbers to kernel 5.5 level

[Laurent Vivier]

Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic 
> 
> Update sh4 syscall numbers based on Linux kernel v5.5.
> 
> CC: Aurelien Jarno 
> Signed-off-by: Aleksandar Markovic 
> ---
>  linux-user/sh4/syscall_nr.h | 48 
> +
>  1 file changed, 48 insertions(+)
>

Reviewed-by: Laurent Vivier 

[PATCH v2] tests/acceptance/machine_sparc_leon3: Do not run HelenOS test by default

[Philippe Mathieu-Daudé]

The www.helenos.org server is slow and downloading the Leon3 binary
takes too long [*]. Do not include this test in the default suite.

Similarly to commit 471c97a69b:

  Currently the Avocado framework does not distinct the time spent
  downloading assets vs. the time spent running a test. With big
  assets (like a full VM image) the tests likely fail.

  This is a limitation known by the Avocado team.
  Until this issue get fixed, do not run this tests automatically.

  Tests can still be run setting the AVOCADO_TIMEOUT_EXPECTED
  environment variable.

[*] https://travis-ci.org/stsquad/qemu/jobs/649599880#L4198

Reported-by: Alex Bennée 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Add missing staged hunk...
---
 tests/acceptance/machine_sparc_leon3.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/acceptance/machine_sparc_leon3.py 
b/tests/acceptance/machine_sparc_leon3.py
index f77e210ccb..27e4717a51 100644
--- a/tests/acceptance/machine_sparc_leon3.py
+++ b/tests/acceptance/machine_sparc_leon3.py
@@ -5,6 +5,9 @@
 # This work is licensed under the terms of the GNU GPL, version 2 or
 # later. See the COPYING file in the top-level directory.
 
+import os
+
+from avocado import skipUnless
 from avocado_qemu import Test
 from avocado_qemu import wait_for_console_pattern
 
@@ -13,6 +16,7 @@ class Leon3Machine(Test):
 
 timeout = 60
 
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
 def test_leon3_helenos_uimage(self):
 """
 :avocado: tags=arch:sparc
-- 
2.21.1

[PATCH v2] tests/acceptance/machine_sparc_leon3: Do not run HelenOS test by default

[Philippe Mathieu-Daudé]

The www.helenos.org server is slow and downloading the Leon3 binary
takes too long [*]. Do not include this test in the default suite.

Similarly to commit 471c97a69b:

  Currently the Avocado framework does not distinct the time spent
  downloading assets vs. the time spent running a test. With big
  assets (like a full VM image) the tests likely fail.

  This is a limitation known by the Avocado team.
  Until this issue get fixed, do not run this tests automatically.

  Tests can still be run setting the AVOCADO_TIMEOUT_EXPECTED
  environment variable.

[*] https://travis-ci.org/stsquad/qemu/jobs/649599880#L4198

Reported-by: Alex Bennée 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Add missing staged hunk...
---
 tests/acceptance/machine_sparc_leon3.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/acceptance/machine_sparc_leon3.py 
b/tests/acceptance/machine_sparc_leon3.py
index f77e210ccb..27e4717a51 100644
--- a/tests/acceptance/machine_sparc_leon3.py
+++ b/tests/acceptance/machine_sparc_leon3.py
@@ -5,6 +5,9 @@
 # This work is licensed under the terms of the GNU GPL, version 2 or
 # later. See the COPYING file in the top-level directory.
 
+import os
+
+from avocado import skipUnless
 from avocado_qemu import Test
 from avocado_qemu import wait_for_console_pattern
 
@@ -13,6 +16,7 @@ class Leon3Machine(Test):
 
 timeout = 60
 
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
 def test_leon3_helenos_uimage(self):
 """
 :avocado: tags=arch:sparc
-- 
2.21.1

[PATCH] tests/acceptance/machine_sparc_leon3: Do not run HelenOS test by default

[Philippe Mathieu-Daudé]

The www.helenos.org server is slow and downloading the Leon3 binary
takes too long [*]. Do not include this test in the default suite.

Similarly to commit 471c97a69b:

  Currently the Avocado framework does not distinct the time spent
  downloading assets vs. the time spent running a test. With big
  assets (like a full VM image) the tests likely fail.

  This is a limitation known by the Avocado team.
  Until this issue get fixed, do not run this tests automatically.

  Tests can still be run setting the AVOCADO_TIMEOUT_EXPECTED
  environment variable.

[*] https://travis-ci.org/stsquad/qemu/jobs/649599880#L4198

Reported-by: Alex Bennée 
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/machine_sparc_leon3.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/acceptance/machine_sparc_leon3.py 
b/tests/acceptance/machine_sparc_leon3.py
index f77e210ccb..8dba5998a1 100644
--- a/tests/acceptance/machine_sparc_leon3.py
+++ b/tests/acceptance/machine_sparc_leon3.py
@@ -5,6 +5,7 @@
 # This work is licensed under the terms of the GNU GPL, version 2 or
 # later. See the COPYING file in the top-level directory.
 
+from avocado import skipUnless
 from avocado_qemu import Test
 from avocado_qemu import wait_for_console_pattern
 
@@ -13,6 +14,7 @@ class Leon3Machine(Test):
 
 timeout = 60
 
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
 def test_leon3_helenos_uimage(self):
 """
 :avocado: tags=arch:sparc
-- 
2.21.1

[PATCH] tests/docker: Install tools to cross-debug and build Linux kernels

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

We often run Linux kernels to test QEMU. We sometimes need
to build them manually to use non-default features. We only
miss the tiny 'bc' tool.

The ncurses library is helpful to run 'make menuconfig'.

Finally, gdb-multiarch allow us to debug a TCG guest when its
architecture is different than the host.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/debian10.docker | 3 +++
 tests/docker/dockerfiles/debian9.docker  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/tests/docker/dockerfiles/debian10.docker 
b/tests/docker/dockerfiles/debian10.docker
index 5de79ae552..2fcdc406e8 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -17,14 +17,17 @@ RUN apt update && \
 DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
 DEBIAN_FRONTEND=noninteractive eatmydata \
 apt install -y --no-install-recommends \
+bc \
 bison \
 build-essential \
 ca-certificates \
 clang \
 dbus \
 flex \
+gdb-multiarch \
 gettext \
 git \
+libncurses5-dev \
 pkg-config \
 psmisc \
 python3 \
diff --git a/tests/docker/dockerfiles/debian9.docker 
b/tests/docker/dockerfiles/debian9.docker
index 8cbd742bb5..92edbbf0f4 100644
--- a/tests/docker/dockerfiles/debian9.docker
+++ b/tests/docker/dockerfiles/debian9.docker
@@ -17,13 +17,16 @@ RUN apt update && \
 DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
 DEBIAN_FRONTEND=noninteractive eatmydata \
 apt install -y --no-install-recommends \
+bc \
 bison \
 build-essential \
 ca-certificates \
 clang \
 flex \
+gdb-multiarch \
 gettext \
 git \
+libncurses5-dev \
 pkg-config \
 psmisc \
 python3 \
-- 
2.21.1

[PATCH 2/3] tests/docker: Remove obsolete VirGL --with-glx configure option

[Philippe Mathieu-Daudé]

The GLX configure option has been removed in 71c75f201d [*].
We missed that when updating to v0.7.0 in commit fab3220f97.

This silents:

  configure: creating ./config.status
  config.status: creating virglrenderer.pc
  ...
  configure: WARNING: unrecognized options: --with-glx

[*] https://gitlab.freedesktop.org/virgl/virglrenderer/commit/71c75f201d

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/debian-amd64.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-amd64.docker 
b/tests/docker/dockerfiles/debian-amd64.docker
index b67fad54cb..a1d40a56fa 100644
--- a/tests/docker/dockerfiles/debian-amd64.docker
+++ b/tests/docker/dockerfiles/debian-amd64.docker
@@ -29,7 +29,7 @@ RUN apt update && \
 libgbm-dev
 RUN git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git 
/usr/src/virglrenderer && \
 cd /usr/src/virglrenderer && git checkout virglrenderer-0.7.0
-RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure --with-glx 
--disable-tests && make install
+RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure --disable-tests 
&& make install
 
 # netmap
 RUN apt update && \
-- 
2.21.1

[PATCH 1/3] tests/docker: Update VirGL git repository URL

[Philippe Mathieu-Daudé]

freedesktop.org is moving to a GitLab instance,
use the new url.

- https://www.fooishbar.org/blog/gitlab-fdo-introduction/
- https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/debian-amd64.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-amd64.docker 
b/tests/docker/dockerfiles/debian-amd64.docker
index 3b860af106..b67fad54cb 100644
--- a/tests/docker/dockerfiles/debian-amd64.docker
+++ b/tests/docker/dockerfiles/debian-amd64.docker
@@ -27,7 +27,7 @@ RUN apt update && \
 libegl1-mesa-dev \
 libepoxy-dev \
 libgbm-dev
-RUN git clone https://anongit.freedesktop.org/git/virglrenderer.git 
/usr/src/virglrenderer && \
+RUN git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git 
/usr/src/virglrenderer && \
 cd /usr/src/virglrenderer && git checkout virglrenderer-0.7.0
 RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure --with-glx 
--disable-tests && make install
 
-- 
2.21.1

[PATCH 3/3] tests/docker: Update VirGL to v0.8.0

[Philippe Mathieu-Daudé]

Building the qemu:debian-amd64 fails when building VirGL:

  make[2]: Entering directory '/usr/src/virglrenderer/src/gallium/auxiliary'
CC   cso_cache/cso_cache.lo
CC   cso_cache/cso_hash.lo
CC   os/os_misc.lo
CC   util/u_debug.lo
CC   util/u_debug_describe.lo
CC   util/u_format.lo
GEN  util/u_format_table.c
  Traceback (most recent call last):
File "./util/u_format_table.py", line 168, in 
  main()
File "./util/u_format_table.py", line 164, in main
  write_format_table(formats)
File "./util/u_format_table.py", line 132, in write_format_table
  print("   %s,\t/* is_array */" % (bool_map(format.is_array()),))
File "/usr/src/virglrenderer/src/gallium/auxiliary/util/u_format_parse.py", 
line 164, in is_array
  return self.array_element() != None
File "/usr/src/virglrenderer/src/gallium/auxiliary/util/u_format_parse.py", 
line 73, in __eq__
  return self.type == other.type and self.norm == other.norm and self.pure 
== other.pure and self.size == other.size
  AttributeError: 'NoneType' object has no attribute 'type'
  make[2]: Leaving directory '/usr/src/virglrenderer/src/gallium/auxiliary'
  make[2]: *** [Makefile:906: util/u_format_table.c] Error 1
  make[1]: *** [Makefile:631: install-recursive] Error 1

VirGL commits a8962eda1..a613dcc82 fix this problem.
Update to VirGL 0.8.0 which contains them.

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/debian-amd64.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-amd64.docker 
b/tests/docker/dockerfiles/debian-amd64.docker
index a1d40a56fa..c70c916343 100644
--- a/tests/docker/dockerfiles/debian-amd64.docker
+++ b/tests/docker/dockerfiles/debian-amd64.docker
@@ -28,7 +28,7 @@ RUN apt update && \
 libepoxy-dev \
 libgbm-dev
 RUN git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git 
/usr/src/virglrenderer && \
-cd /usr/src/virglrenderer && git checkout virglrenderer-0.7.0
+cd /usr/src/virglrenderer && git checkout virglrenderer-0.8.0
 RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure --disable-tests 
&& make install
 
 # netmap
-- 
2.21.1

[PATCH 0/3] tests/docker: Fix linking with VirGL

[Philippe Mathieu-Daudé]

We link with VirGL in our debian-amd64 (cross-host) docker image.

This series includes few fixes to keep testing it.

Philippe Mathieu-Daudé (3):
  tests/docker: Update VirGL git repository URL
  tests/docker: Remove obsolete VirGL --with-glx configure option
  tests/docker: Update VirGL to v0.8.0

 tests/docker/dockerfiles/debian-amd64.docker | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.21.1

How do UEFI on Windows host

[Jerry Geis]

How do I start a UEFI install (centos 8) for UEFI with 4.2.0 on Windows
host ???
I can do a regular install just fine. I desire to do UEFI install.

Thanks,

Jerry

Re: [PATCH v2 21/35] target/riscv: Add hypvervisor trap support

[Palmer Dabbelt]

On Fri, 31 Jan 2020 17:02:30 PST (-0800), Alistair Francis wrote:

Signed-off-by: Alistair Francis 
---
 target/riscv/cpu_helper.c | 69 +--
 1 file changed, 59 insertions(+), 10 deletions(-)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 98017df33b..e7728cb0ca 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -639,6 +639,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)

 RISCVCPU *cpu = RISCV_CPU(cs);
 CPURISCVState *env = &cpu->env;
+bool force_hs_execp = riscv_cpu_force_hs_excep_enabled(env);
+target_ulong s;

 /* cs->exception is 32-bits wide unlike mcause which is XLEN-bits wide
  * so we mask off the MSB and separate into trap type and cause.
@@ -648,19 +650,14 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 target_ulong deleg = async ? env->mideleg : env->medeleg;
 target_ulong tval = 0;

-static const int ecall_cause_map[] = {
-[PRV_U] = RISCV_EXCP_U_ECALL,
-[PRV_S] = RISCV_EXCP_S_ECALL,
-[PRV_H] = RISCV_EXCP_VS_ECALL,
-[PRV_M] = RISCV_EXCP_M_ECALL
-};
-
 if (!async) {
 /* set tval to badaddr for traps with address information */
 switch (cause) {
 case RISCV_EXCP_INST_GUEST_PAGE_FAULT:
 case RISCV_EXCP_LOAD_GUEST_ACCESS_FAULT:
 case RISCV_EXCP_STORE_GUEST_AMO_ACCESS_FAULT:
+force_hs_execp = true;
+/* fallthrough */
 case RISCV_EXCP_INST_ADDR_MIS:
 case RISCV_EXCP_INST_ACCESS_FAULT:
 case RISCV_EXCP_LOAD_ADDR_MIS:
@@ -678,7 +675,16 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 /* ecall is dispatched as one cause so translate based on mode */
 if (cause == RISCV_EXCP_U_ECALL) {
 assert(env->priv <= 3);
-cause = ecall_cause_map[env->priv];
+
+if (env->priv == PRV_M) {
+cause = RISCV_EXCP_M_ECALL;
+} else if (env->priv == PRV_S && riscv_cpu_virt_enabled(env)) {
+cause = RISCV_EXCP_VS_ECALL;
+} else if (env->priv == PRV_S && !riscv_cpu_virt_enabled(env)) {
+cause = RISCV_EXCP_S_ECALL;
+} else if (env->priv == PRV_U) {
+cause = RISCV_EXCP_U_ECALL;
+}
 }
 }

@@ -688,7 +694,36 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 if (env->priv <= PRV_S &&
 cause < TARGET_LONG_BITS && ((deleg >> cause) & 1)) {
 /* handle the trap in S-mode */
-target_ulong s = env->mstatus;
+if (riscv_has_ext(env, RVH)) {
+target_ulong hdeleg = async ? env->hideleg : env->hedeleg;
+
+if (riscv_cpu_virt_enabled(env) && ((hdeleg >> cause) & 1) &&
+!force_hs_execp) {
+/* Trap to VS mode */
+} else if (riscv_cpu_virt_enabled(env)) {
+/* Trap into HS mode, from virt */
+riscv_cpu_swap_hypervisor_regs(env);
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2V,
+ get_field(env->hstatus, HSTATUS_SPV));
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2P,
+ get_field(env->mstatus, SSTATUS_SPP));
+env->hstatus = set_field(env->hstatus, HSTATUS_SPV,
+ riscv_cpu_virt_enabled(env));
+
+riscv_cpu_set_virt_enabled(env, 0);
+riscv_cpu_set_force_hs_excep(env, 0);
+} else {
+/* Trap into HS mode */
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2V,
+ get_field(env->hstatus, HSTATUS_SPV));
+env->hstatus = set_field(env->hstatus, HSTATUS_SP2P,
+ get_field(env->mstatus, SSTATUS_SPP));
+env->hstatus = set_field(env->hstatus, HSTATUS_SPV,
+ riscv_cpu_virt_enabled(env));
+}
+}
+
+s = env->mstatus;
 s = set_field(s, MSTATUS_SPIE, env->priv_ver >= PRIV_VERSION_1_10_0 ?
 get_field(s, MSTATUS_SIE) : get_field(s, MSTATUS_UIE << 
env->priv));
 s = set_field(s, MSTATUS_SPP, env->priv);
@@ -702,7 +737,21 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 riscv_cpu_set_mode(env, PRV_S);
 } else {
 /* handle the trap in M-mode */
-target_ulong s = env->mstatus;
+if (riscv_has_ext(env, RVH)) {
+if (riscv_cpu_virt_enabled(env)) {
+riscv_cpu_swap_hypervisor_regs(env);
+}
+env->mstatus = set_field(env->mstatus, MSTATUS_MPV,
+  riscv_cpu_virt_enabled(env));
+env->mstatus = set_field(env->mstatus, MSTATUS_MTL,
+  riscv_cpu_force_hs_excep_enabled(env));
+
+/* Trapping to M mode, virt is disabled 

Re: [PATCH 2/2] target/arm: Use tcg_gen_gvec_5_ptr for sve FMLA/FCMLA

[Richard Henderson]

On 2/12/20 2:50 AM, Alex Bennée wrote:
> 
> Richard Henderson  writes:
> 
>> Now that we can pass 7 parameters, do not encode register
>> operands within simd_data.
> 
> What defines the upper limit? Is it the ABI of the backend or just the
> efficiency of implementing the prologue for the call?

The current upper limit is from the lifetime tracking data.  Which gives us 14
arguments within the bits of the uint16_t.  Which gives us 7 uint64_t arguments
on a 32-bit host.


r~

Re: [PATCH v1 0/5] testing/next (rcutorture and misc tweaks)

[Alex Bennée]

Alex Bennée  writes:

> Hi,
>
> The current state of testing/next is mostly a rubber duck exercise as
> I tried to figure out what might cause the rcutorture test to fail.
> The only real practical change is asserting we are never about to
> reset and existing active RCU structure. So far I haven't seen the
> rcutorture crash occur since (although git stability seems to be a
> current problem for Travis).
>
> Alex Bennée (4):
>   tests/tcg: include a skip runner for pauth3 with plugins
>   tests/rcutorture: update usage hint
>   tests/rcutorture: better document locking of stats
>   tests/rcutorture: mild documenting refactor of update thread
>
> Thomas Huth (1):
>   travis.yml: Test the s390-ccw build, too
>
>  tests/rcutorture.c| 55 +--
>  .travis.yml   | 10 +
>  tests/tcg/aarch64/Makefile.softmmu-target |  2 +
>  3 files changed, 53 insertions(+), 14 deletions(-)

Ping?

I'm particularly interested in the rcutorture changes which so far have
not yielded any:

  ERROR:/home/travis/build/qemu/qemu/tests/rcutorture.c:384:gtest_stress: 
assertion failed (n_mberror == 0): (1 == 0)

in my various test trees.

-- 
Alex Bennée

Re: [PATCH v4 4/4] target/riscv: add vector configure instruction

[Richard Henderson]

On 2/12/20 12:09 AM, LIU Zhiwei wrote:
> 
> 
> On 2020/2/12 0:56, Richard Henderson wrote:
>> On 2/10/20 8:12 AM, LIU Zhiwei wrote:
>>>   static inline void cpu_get_tb_cpu_state(CPURISCVState *env, target_ulong 
>>> *pc,
>>> -    target_ulong *cs_base, uint32_t
>>> *flags)
>>> +    target_ulong *cs_base, uint32_t
>>> *pflags)
>>>   {
>>> +    uint32_t flags = 0;
>>> +    uint32_t vlmax;
>>> +    uint8_t vl_eq_vlmax;
>> bool.
> OK.
> 
> Is it clearer to use "bool" here? Or it's wrong to use "uint8_t "?

It is clearer.  Using uint8_t makes me wonder what else you were going to put
in that variable, but the answer from the code below is nothing.

>>> +    if (sew > cpu->cfg.elen) { /* only set vill bit. */
>>> +    env->vext.vtype = FIELD_DP64(0, VTYPE, VILL, 1);
>>> +    env->vext.vl = 0;
>>> +    env->vext.vstart = 0;
>>> +    return 0;
>>> +    }
>> You're missing checks against EDIV, VILL and the RESERVED field == 0.
> This implementation does not support "Zvediv" . So I did not check it. I'm not
> sure if I should check(ediv==0).
> 
> I missed check  "VILL" filed.  Fix up it next patch.
> 
> I'm not quite sure if I should set VILL if  the RESERVED field != 0.


The manual says

  # If the vtype setting is not supported by the implementation,
  # then the vill bit is set in vtype, the remaining bits in
  # vtype are set to zero, and the vl register is also set
  # to zero.

So yes, you most certainly have to check ediv == 0.

By extension, I believe the entire RESERVED field should be checked.
Otherwise, we don't get the same forward compatible behaviour for the next
vector extension beyond Zvediv.


r~

Re: [PATCH] target/i386: enable monitor and ucode revision with -cpu max

[Eduardo Habkost]

On Wed, Feb 12, 2020 at 04:23:29PM +0100, Paolo Bonzini wrote:
> These two features were incorrectly tied to host_cpuid_required rather than
> cpu->max_features.  As a result, -cpu max was not enabling either MONITOR
> features or ucode revision.
> 
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Eduardo Habkost 

-- 
Eduardo

[PATCH 3/3] pnv/phb3: Add missing break statement

[Greg Kurz]

We obviously don't want to print out an error message if addr points to
a valid register.

Reported-by: Coverity CID 1419391 Missing break in switch
Fixes: 9ae1329ee2fe "ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge"
Signed-off-by: Greg Kurz 
---
 hw/pci-host/pnv_phb3_pbcq.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/pci-host/pnv_phb3_pbcq.c b/hw/pci-host/pnv_phb3_pbcq.c
index f232228b0e28..7b9a121246a8 100644
--- a/hw/pci-host/pnv_phb3_pbcq.c
+++ b/hw/pci-host/pnv_phb3_pbcq.c
@@ -173,6 +173,7 @@ static void pnv_pbcq_pci_xscom_write(void *opaque, hwaddr 
addr,
 case PBCQ_PCI_BAR2:
 pbcq->pci_regs[reg] = val & 0xfc00ull;
 pnv_pbcq_update_map(pbcq);
+break;
 default:
 phb3_pbcq_error(pbcq, "%s @0x%"HWADDR_PRIx"=%"PRIx64, __func__,
 addr, val);

Re: [PATCH qemu v6 5/6] spapr: Allow changing offset for -kernel image

[Fabiano Rosas]

Alexey Kardashevskiy  writes:

> This allows moving the kernel in the guest memory. The option is useful
> for step debugging (as Linux is linked at 0x0); it also allows loading
> grub which is normally linked to run at 0x2.
>

+1, as this fixes half of the '-S' debugging issue.

> This uses the existing kernel address by default.
>
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: Fabiano Rosas 

> ---
>  include/hw/ppc/spapr.h |  1 +
>  hw/ppc/spapr.c | 38 +++---
>  2 files changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 3b50f36c338a..32e831a395ae 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -164,6 +164,7 @@ struct SpaprMachineState {
>  void *fdt_blob;
>  long kernel_size;
>  bool kernel_le;
> +uint64_t kernel_addr;
>  uint32_t initrd_base;
>  long initrd_size;
>  uint64_t rtc_offset; /* Now used only during incoming migration */
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 60153bf0b771..b59e9dc360fe 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1054,7 +1054,7 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, 
> void *fdt)
>  }
>  
>  if (spapr->kernel_size) {
> -uint64_t kprop[2] = { cpu_to_be64(KERNEL_LOAD_ADDR),
> +uint64_t kprop[2] = { cpu_to_be64(spapr->kernel_addr),
>cpu_to_be64(spapr->kernel_size) };
>  
>  _FDT(fdt_setprop(fdt, chosen, "qemu,boot-kernel",
> @@ -1242,7 +1242,8 @@ void *spapr_build_fdt(SpaprMachineState *spapr, bool 
> reset, size_t space)
>  /* Build memory reserve map */
>  if (reset) {
>  if (spapr->kernel_size) {
> -_FDT((fdt_add_mem_rsv(fdt, KERNEL_LOAD_ADDR, 
> spapr->kernel_size)));
> +_FDT((fdt_add_mem_rsv(fdt, spapr->kernel_addr,
> +  spapr->kernel_size)));
>  }
>  if (spapr->initrd_size) {
>  _FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base,
> @@ -1270,7 +1271,9 @@ void *spapr_build_fdt(SpaprMachineState *spapr, bool 
> reset, size_t space)
>  
>  static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
>  {
> -return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
> +SpaprMachineState *spapr = opaque;
> +
> +return (addr & 0x0fff) + spapr->kernel_addr;
>  }
>  
>  static void emulate_spapr_hypercall(PPCVirtualHypervisor *vhyp,
> @@ -2947,14 +2950,15 @@ static void spapr_machine_init(MachineState *machine)
>  uint64_t lowaddr = 0;
>  
>  spapr->kernel_size = load_elf(kernel_filename, NULL,
> -  translate_kernel_address, NULL,
> +  translate_kernel_address, spapr,
>NULL, &lowaddr, NULL, NULL, 1,
>PPC_ELF_MACHINE, 0, 0);
>  if (spapr->kernel_size == ELF_LOAD_WRONG_ENDIAN) {
>  spapr->kernel_size = load_elf(kernel_filename, NULL,
> -  translate_kernel_address, NULL, 
> NULL,
> +  translate_kernel_address, spapr, 
> NULL,
>&lowaddr, NULL, NULL, 0,
> -  PPC_ELF_MACHINE, 0, 0);
> +  PPC_ELF_MACHINE,
> +  0, 0);
>  spapr->kernel_le = spapr->kernel_size > 0;
>  }
>  if (spapr->kernel_size < 0) {
> @@ -2968,7 +2972,7 @@ static void spapr_machine_init(MachineState *machine)
>  /* Try to locate the initrd in the gap between the kernel
>   * and the firmware. Add a bit of space just in case
>   */
> -spapr->initrd_base = (KERNEL_LOAD_ADDR + spapr->kernel_size
> +spapr->initrd_base = (spapr->kernel_addr + spapr->kernel_size
>+ 0x1) & ~0x;
>  spapr->initrd_size = load_image_targphys(initrd_filename,
>   spapr->initrd_base,
> @@ -3214,6 +3218,18 @@ static void spapr_set_vsmt(Object *obj, Visitor *v, 
> const char *name,
>  visit_type_uint32(v, name, (uint32_t *)opaque, errp);
>  }
>  
> +static void spapr_get_kernel_addr(Object *obj, Visitor *v, const char *name,
> +  void *opaque, Error **errp)
> +{
> +visit_type_uint64(v, name, (uint64_t *)opaque, errp);
> +}
> +
> +static void spapr_set_kernel_addr(Object *obj, Visitor *v, const char *name,
> +  void *opaque, Error **errp)
> +{
> +visit_type_uint64(v, name, (uint64_t *)opaque, errp);
> +}
> +
>  static char *spapr_get_ic_mode(Object *obj, Error **errp)
>  {
>  SpaprMachineState *spapr = SPAPR_MACHINE(obj);
> @@ -3319,6 +3335,14 @@ static void spapr_instance_init(

[PATCH 1/3] pnv/phb3: Convert 1u to 1ull

[Greg Kurz]

As reported by Coverity defect CID 1419397, the 'j' variable goes up to
63 and shouldn't be used to left shift a 32-bit integer.

The result of the operation goes to a 64-bit integer : use a 64-bit
constant.

Reported-by: Coverity CID 1419397 Bad bit shift operation
Fixes: 9ae1329ee2fe "ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge"
Signed-off-by: Greg Kurz 
---
 hw/pci-host/pnv_phb3_msi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci-host/pnv_phb3_msi.c b/hw/pci-host/pnv_phb3_msi.c
index ecfc1b2c4e3d..d645468f4a6f 100644
--- a/hw/pci-host/pnv_phb3_msi.c
+++ b/hw/pci-host/pnv_phb3_msi.c
@@ -220,7 +220,7 @@ static void phb3_msi_resend(ICSState *ics)
 if ((msi->rba[i] & (1ull << j)) == 0) {
 continue;
 }
-msi->rba[i] &= ~(1u << j);
+msi->rba[i] &= ~(1ull << j);
 phb3_msi_try_send(msi, i * 64 + j, true);
 }
 }

[PATCH 2/3] pnv/phb4: Fix error path in pnv_pec_realize()

[Greg Kurz]

Obviously, we want to pass &local_err so that we can check it then
line below, not errp.

Reported-by: Coverity CID 1419395 'Constant' variable guards dead code
Fixes: 4f9924c4d4cf "ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge"
Signed-off-by: Greg Kurz 
---
 hw/pci-host/pnv_phb4_pec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
index 68e1db3eac4f..911d147ffd7d 100644
--- a/hw/pci-host/pnv_phb4_pec.c
+++ b/hw/pci-host/pnv_phb4_pec.c
@@ -391,7 +391,7 @@ static void pnv_pec_realize(DeviceState *dev, Error **errp)
 
 object_property_set_int(stk_obj, i, "stack-no", &error_abort);
 object_property_set_link(stk_obj, OBJECT(pec), "pec", &error_abort);
-object_property_set_bool(stk_obj, true, "realized", errp);
+object_property_set_bool(stk_obj, true, "realized", &local_err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;

[PATCH 0/3] pnv: Fix a couple of issues reported by Coverity

[Greg Kurz]

This fixes some issues in the PHB3 and PHB4 code that was merged
recently.

--
Greg

---

Greg Kurz (3):
  pnv/phb3: Convert 1u to 1ull
  pnv/phb4: Fix error path in pnv_pec_realize()
  pnv/phb3: Add missing break statement


 hw/pci-host/pnv_phb3_msi.c  |2 +-
 hw/pci-host/pnv_phb3_pbcq.c |1 +
 hw/pci-host/pnv_phb4_pec.c  |2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

Re: [PULL 34/35] target/ppc: Use probe_write for DCBZ

[Greg Kurz]

On Mon,  3 Feb 2020 17:11:22 +1100
David Gibson  wrote:

> From: Richard Henderson 
> 
> Using probe_write instead of tlb_vaddr_to_host means that we
> process watchpoints and notdirty pages more efficiently.
> 
> Signed-off-by: Richard Henderson 
> Message-Id: <20200129235040.24022-5-richard.hender...@linaro.org>
> Tested-by: Howard Spoelstra 
> Signed-off-by: David Gibson 
> ---
>  target/ppc/mem_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/mem_helper.c b/target/ppc/mem_helper.c
> index 0cb78777e7..98f589552b 100644
> --- a/target/ppc/mem_helper.c
> +++ b/target/ppc/mem_helper.c
> @@ -298,7 +298,7 @@ static void dcbz_common(CPUPPCState *env, target_ulong 
> addr,
>  }
>  
>  /* Try fast path translate */
> -haddr = tlb_vaddr_to_host(env, addr, MMU_DATA_STORE, mmu_idx);
> +haddr = probe_write(env, addr, dcbz_size, mmu_idx, retaddr);

Hi Richard,

This one is making coverity unhappy.


** CID 1419390:  Memory - corruptions  (OVERRUN)


__
*** CID 1419390:  Memory - corruptions  (OVERRUN)
/target/ppc/mem_helper.c: 301 in dcbz_common()
295 /* Check reservation */
296 if ((env->reserve_addr & mask) == addr)  {
297 env->reserve_addr = (target_ulong)-1ULL;
298 }
299 
300 /* Try fast path translate */
>>> CID 1419390:  Memory - corruptions  (OVERRUN)
>>> Overrunning callee's array of size 9 by passing argument "mmu_idx" 
>>> (which evaluates to 9) in call to "probe_write".  
301 haddr = probe_write(env, addr, dcbz_size, mmu_idx, retaddr);
302 if (haddr) {
303 memset(haddr, 0, dcbz_size);
304 } else {
305 /* Slow path */
306 for (i = 0; i < dcbz_size; i += 8) {


Can you have a look ?

Cheers,

--
Greg

>  if (haddr) {
>  memset(haddr, 0, dcbz_size);
>  } else {

Question about (and problem with) pflash data access

[Guenter Roeck]

Hi,

I have been playing with pflash recently. For the most part it works,
but I do have an odd problem when trying to instantiate pflash on sx1.

My data file looks as follows.

000 0001       
020        
*
0002000 0002       
0002020        
*
0004000 0003       
0004020        
...

In the sx1 machine, this becomes:

000 6001       
020        
*
0002000 6002       
0002020        
*
0004000 6003       
0004020        
*
...

pflash is instantiated with "-drive file=flash.32M.test,format=raw,if=pflash".

I don't have much success with pflash tracing - data accesses don't
show up there.

I did find a number of problems with the sx1 emulation, but I have no clue
what is going on with pflash. As far as I can see pflash works fine on
other machines. Can someone give me a hint what to look out for ?

Thanks,
Guenter

Re: [PATCH qemu v6 2/6] ppc/spapr: Move GPRs setup to one place

[Fabiano Rosas]

Alexey Kardashevskiy  writes:

> At the moment "pseries" starts in SLOF which only expects the FDT blob
> pointer in r3. As we are going to introduce a OpenFirmware support in
> QEMU, we will be booting OF clients directly and these expect a stack
> pointer in r1, the OF entry point in r5 and in addition to this, Linux
> looks at r3/r4 for the initramdisk location (although vmlinux can find
> this from the device tree but zImage from distro kernels cannot).
>
> This extends spapr_cpu_set_entry_state() to take more registers. This
> should cause no behavioral change.
>
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: Fabiano Rosas 

> ---
>  include/hw/ppc/spapr_cpu_core.h | 4 +++-
>  hw/ppc/spapr.c  | 4 ++--
>  hw/ppc/spapr_cpu_core.c | 7 ++-
>  hw/ppc/spapr_rtas.c | 2 +-
>  4 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/include/hw/ppc/spapr_cpu_core.h b/include/hw/ppc/spapr_cpu_core.h
> index 1c4cc6559c52..edd7214fafcf 100644
> --- a/include/hw/ppc/spapr_cpu_core.h
> +++ b/include/hw/ppc/spapr_cpu_core.h
> @@ -40,7 +40,9 @@ typedef struct SpaprCpuCoreClass {
>  } SpaprCpuCoreClass;
>  
>  const char *spapr_get_cpu_core_type(const char *cpu_type);
> -void spapr_cpu_set_entry_state(PowerPCCPU *cpu, target_ulong nip, 
> target_ulong r3);
> +void spapr_cpu_set_entry_state(PowerPCCPU *cpu, target_ulong nip,
> +   target_ulong r1, target_ulong r3,
> +   target_ulong r4, target_ulong r5);
>  
>  typedef struct SpaprCpuState {
>  uint64_t vpa_addr;
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index c9b2e0a5e060..660a4b60e072 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1674,8 +1674,8 @@ static void spapr_machine_reset(MachineState *machine)
>  spapr->fdt_blob = fdt;
>  
>  /* Set up the entry state */
> -spapr_cpu_set_entry_state(first_ppc_cpu, SPAPR_ENTRY_POINT, fdt_addr);
> -first_ppc_cpu->env.gpr[5] = 0;
> +spapr_cpu_set_entry_state(first_ppc_cpu, SPAPR_ENTRY_POINT,
> +  0, fdt_addr, 0, 0);
>  
>  spapr->cas_reboot = false;
>  
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index d09125d9afd4..696b76598dd7 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -84,13 +84,18 @@ static void spapr_reset_vcpu(PowerPCCPU *cpu)
>  spapr_irq_cpu_intc_reset(spapr, cpu);
>  }
>  
> -void spapr_cpu_set_entry_state(PowerPCCPU *cpu, target_ulong nip, 
> target_ulong r3)
> +void spapr_cpu_set_entry_state(PowerPCCPU *cpu, target_ulong nip,
> +   target_ulong r1, target_ulong r3,
> +   target_ulong r4, target_ulong r5)
>  {
>  PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
>  CPUPPCState *env = &cpu->env;
>  
>  env->nip = nip;
> +env->gpr[1] = r1;
>  env->gpr[3] = r3;
> +env->gpr[4] = r4;
> +env->gpr[5] = r5;
>  kvmppc_set_reg_ppc_online(cpu, 1);
>  CPU(cpu)->halted = 0;
>  /* Enable Power-saving mode Exit Cause exceptions */
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index 656fdd221665..9e3cbd70bbd9 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -190,7 +190,7 @@ static void rtas_start_cpu(PowerPCCPU *callcpu, 
> SpaprMachineState *spapr,
>   */
>  newcpu->env.tb_env->tb_offset = callcpu->env.tb_env->tb_offset;
>  
> -spapr_cpu_set_entry_state(newcpu, start, r3);
> +spapr_cpu_set_entry_state(newcpu, start, 0, r3, 0, 0);
>  
>  qemu_cpu_kick(CPU(newcpu));

Re: [PATCH] MAINTAINERS: Orphan MIPS KVM CPUs

[Philippe Mathieu-Daudé]

Cc'ing qemu-trivial@ & Paolo.

On Sat, Dec 21, 2019 at 5:42 PM James Hogan  wrote:
>
> I haven't been active for 18 months, and don't have the hardware set up
> to test KVM for MIPS, so mark it as orphaned and remove myself as
> maintainer. Hopefully somebody from MIPS can pick this up.
>
> Signed-off-by: James Hogan 
> Cc: Aleksandar Rikalo 
> Cc: Aurelien Jarno 
> Cc: Aleksandar Markovic 
> Cc: qemu-devel@nongnu.org
> ---
>  MAINTAINERS | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 740401bcbb86..a798ad2b0b8a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -363,9 +363,8 @@ S: Maintained
>  F: target/arm/kvm.c
>
>  MIPS KVM CPUs
> -M: James Hogan 
>  R: Aleksandar Rikalo 
> -S: Maintained
> +S: Orphan
>  F: target/mips/kvm.c
>
>  PPC KVM CPUs
> --
> 2.24.0
>
>

[Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.

[Laurent Vivier]

I've copied the file portage-2.3.84/build/lib.linux-
x86_64-3.7/portage/util/netlink.py from portage to my local directory
and run the following script:

cat > rtnetlink.py <
bind(3, {sa_family=AF_NETLINK, nl_pid=0, 
nl_groups=}, 12) = 0
sendto(3, {{len=38, type=0x12 /* NLMSG_??? */, 
flags=NLM_F_REQUEST, seq=1, pid=0}, 
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x06\x00\x03\x00\x6c\x6f"},
 38, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 38
...

So I need to know which version you are using (qemu, kernel host).

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

Title:
  qemu user static binary seems to lack support for network namespace.

Status in QEMU:
  New

Bug description:
  Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I
  see the following error message.

  Unable to configure loopback interface: Operation not supported

  If I disable emerge's network-sandbox which utilizes network
  namespace, the error disappears.

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

Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback

[David Hildenbrand]

On 12.02.20 18:07, Shameerali Kolothum Thodi wrote:
> 
> 
>> -Original Message-
>> From: David Hildenbrand [mailto:da...@redhat.com]
>> Sent: 10 February 2020 09:54
>> To: Shameerali Kolothum Thodi ;
>> Igor Mammedov 
>> Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
>> m...@redhat.com; shannon.zha...@gmail.com; qemu-devel@nongnu.org;
>> xuwei (O) ; Linuxarm ;
>> eric.au...@redhat.com; qemu-...@nongnu.org; ler...@redhat.com
>> Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
>>
>> On 10.02.20 10:50, Shameerali Kolothum Thodi wrote:
>>>
>>>
 -Original Message-
 From: David Hildenbrand [mailto:da...@redhat.com]
 Sent: 10 February 2020 09:29
 To: Shameerali Kolothum Thodi ;
 Igor Mammedov 
 Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
 m...@redhat.com; shannon.zha...@gmail.com; qemu-devel@nongnu.org;
 xuwei (O) ; Linuxarm ;
 eric.au...@redhat.com; qemu-...@nongnu.org; ler...@redhat.com
 Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback

>> Can you look the original value up somehow and us the resize callback
>> only as a notification that something changed? (that value would have to
>> be stored somewhere and migrated I assume - maybe that's already
>> being
>> done)
>
> Ok. I will take a look at that. But can we instead pass the
>> block->used_length
 to
> fw_cfg_add_file_callback(). That way we don’t have to change the
 qemu_ram_resize()
> as well. I think Igor has suggested this before[1] and I had a go at it 
> before
 coming up
> with the "req_length" proposal here.

 You mean, passing the old size as well? I don't see how that will solve
 the issue, but yeah, nothing speaks against simply sending the old and
 the new size.
>>>
>>> Nope. I actually meant using the block->used_length to store in the
>>> s->files->f[index].size.
>>>
>>> virt_acpi_setup()
>>>   acpi_add_rom_blob()
>>> rom_add_blob()
>>>   rom_set_mr()  --> used_length  = page aligned blob size
>>> fw_cfg_add_file_callback()  --> uses actual blob size.
>>>
>>>
>>> Right now what we do is use the actual blob size to store in FWCfgEntry.
>>> Instead pass the RAMBlock used_length to fw_cfg_add_file_callback().
>>> Of course by this, the firmware will see an aligned size, but that is fine 
>>> I think.
>>> But at the same time this means the qemu_ram_resize() can stay as it is
>>> because it will invoke the callback when the size changes beyond the aligned
>>> page size. And also during migration, there won't be any inconsistency as
>> everyone
>>> works on aligned page size.
>>>
>>> Does that make sense? Or I am again missing something here?
>>
>> Oh, you mean simply rounding up to full pages in the fw entries? If we
>> can drop the "sub-page" restriction, that would be awesome!
>>
>> Need to double check if that could be an issue for fw/migration/whatever.
> 
> Hmm..it breaks x86 + seabios boot. The issue is seabios expects RSDP in FSEG
> memory. With the above proposed change, RSDP will be aligned to PAGE_SIZE and
> seabios mem allocation for RSDP fails at,
> 
> https://github.com/coreboot/seabios/blob/master/src/fw/romfile_loader.c#L85
> 
> To get pass the above, I changed "alloc_fseg" flag to false in build_rsdp(), 
> but
> seabios seems to make the assumption that RSDP has to be placed in FSEG memory
> here,
> https://github.com/coreboot/seabios/blob/master/src/fw/biostables.c#L126
> 
> So doesn’t look like there is an easy fix for this without changing the 
> seabios code.
> 
> Between, OVMF works fine with the aligned size on x86.
> 
> One thing we can do is treat the RSDP case separately or only use the aligned
> page size for "etc/acpi/tables" as below,
> 
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index d1b78f60cd..f07f6a7a35 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -60,6 +60,7 @@
>  #include "hw/boards.h"
>  #include "qemu/cutils.h"
>  #include "sysemu/runstate.h"
> +#include "hw/acpi/aml-build.h"
>  
>  #include 
>  
> @@ -1056,6 +1057,7 @@ MemoryRegion *rom_add_blob(const char *name, const void 
> *blob, size_t len,
>  if (fw_file_name && fw_cfg) {
>  char devpath[100];
>  void *data;
> +size_t size = rom->datasize;
>  
>  if (read_only) {
>  snprintf(devpath, sizeof(devpath), "/rom@%s", fw_file_name);
> @@ -1066,13 +1068,21 @@ MemoryRegion *rom_add_blob(const char *name, const 
> void *blob, size_t len,
>  if (mc->rom_file_has_mr) {
>  data = rom_set_mr(rom, OBJECT(fw_cfg), devpath, read_only);
>  mr = rom->mr;
> +   /*
> +* Use the RAMblk used_length for acpi tables as this avoids any
> +* inconsistency with table size changes during hot add and during
> +* migration.
> +*/
> +   if (strcmp(fw_file_name, ACPI_BUILD_TABLE_FILE) == 0) {
> + 

Re: [PATCH v2 fixed 00/16] Ram blocks with resizable anonymous allocations under POSIX

[David Hildenbrand]

On 12.02.20 14:42, David Hildenbrand wrote:
> We already allow resizable ram blocks for anonymous memory, however, they
> are not actually resized. All memory is mmaped() R/W, including the memory
> exceeding the used_length, up to the max_length.
> 
> When resizing, effectively only the boundary is moved. Implement actually
> resizable anonymous allocations and make use of them in resizable ram
> blocks when possible. Memory exceeding the used_length will be
> inaccessible. Especially ram block notifiers require care.
> 
> Having actually resizable anonymous allocations (via mmap-hackery) allows
> to reserve a big region in virtual address space and grow the
> accessible/usable part on demand. Even if "/proc/sys/vm/overcommit_memory"
> is set to "never" under Linux, huge reservations will succeed. If there is
> not enough memory when resizing (to populate parts of the reserved region),
> trying to resize will fail. Only the actually used size is reserved in the
> OS.
> 
> E.g., virtio-mem [1] wants to reserve big resizable memory regions and
> grow the usable part on demand. I think this change is worth sending out
> individually. Accompanied by a bunch of minor fixes and cleanups.
> 
> Especially, memory notifiers already handle resizing by first removing
> the old region, and then re-adding the resized region. prealloc is
> currently not possible with resizable ram blocks. mlock() should continue
> to work as is. Resizing is currently rare and must only happen on the
> start of an incoming migration, or during resets. No code path (except
> HAX and SEV ram block notifiers) should access memory outside of the usable
> range - and if we ever find one, that one has to be fixed (I did not
> identify any).
> 
> v1 -> v2:
> - Add "util: vfio-helpers: Fix qemu_vfio_close()"
> - Add "util: vfio-helpers: Remove Error parameter from
>qemu_vfio_undo_mapping()"
> - Add "util: vfio-helpers: Factor out removal from
>qemu_vfio_undo_mapping()"
> - "util/mmap-alloc: ..."
>  -- Minor changes due to review feedback (e.g., assert alignment, return
> bool when resizing)
> - "util: vfio-helpers: Implement ram_block_resized()"
>  -- Reserve max_size in the IOVA address space.
>  -- On resize, undo old mapping and do new mapping. We can later implement
> a new ioctl to resize the mapping directly.
> - "numa: Teach ram block notifiers about resizable ram blocks"
>  -- Pass size/max_size to ram block notifiers, which makes things easier an
> cleaner
> - "exec: Ram blocks with resizable anonymous allocations under POSIX"
>  -- Adapt to new ram block notifiers
>  -- Shrink after notifying. Always trigger ram block notifiers on resizes
>  -- Add a safety net that all ram block notifiers registered at runtime
> support resizes.
> 
> [1] https://lore.kernel.org/kvm/20191212171137.13872-1-da...@redhat.com/
> 
> David Hildenbrand (16):
>   util: vfio-helpers: Factor out and fix processing of existing ram
> blocks
>   util: vfio-helpers: Fix qemu_vfio_close()
>   util: vfio-helpers: Remove Error parameter from
> qemu_vfio_undo_mapping()
>   util: vfio-helpers: Factor out removal from qemu_vfio_undo_mapping()
>   exec: Factor out setting ram settings (madvise ...) into
> qemu_ram_apply_settings()
>   exec: Reuse qemu_ram_apply_settings() in qemu_ram_remap()
>   exec: Drop "shared" parameter from ram_block_add()
>   util/mmap-alloc: Factor out calculation of pagesize to mmap_pagesize()
>   util/mmap-alloc: Factor out reserving of a memory region to
> mmap_reserve()
>   util/mmap-alloc: Factor out populating of memory to mmap_populate()
>   util/mmap-alloc: Prepare for resizable mmaps
>   util/mmap-alloc: Implement resizable mmaps
>   numa: Teach ram block notifiers about resizable ram blocks
>   util: vfio-helpers: Implement ram_block_resized()
>   util: oslib: Resizable anonymous allocations under POSIX
>   exec: Ram blocks with resizable anonymous allocations under POSIX
> 
>  exec.c | 104 +++
>  hw/core/numa.c |  53 +++-
>  hw/i386/xen/xen-mapcache.c |   7 +-
>  include/exec/cpu-common.h  |   3 +
>  include/exec/memory.h  |   8 ++
>  include/exec/ramlist.h |  14 +++-
>  include/qemu/mmap-alloc.h  |  21 +++--
>  include/qemu/osdep.h   |   6 +-
>  stubs/ram-block.c  |  20 -
>  target/i386/hax-mem.c  |   5 +-
>  target/i386/sev.c  |  18 ++--
>  util/mmap-alloc.c  | 165 +++--
>  util/oslib-posix.c |  37 -
>  util/oslib-win32.c |  14 
>  util/trace-events  |   9 +-
>  util/vfio-helpers.c| 145 +---
>  16 files changed, 450 insertions(+), 179 deletions(-)
> 

1. I will do resizable -> resizeable
2. I think migration might indeed need some care regarding
   max_length. We should never migrate anything beyond used_length. And
   if we receive something, it should be discarded. Will look into t

[Bug 1862986] [NEW] qemu-s390x crashes when run on aarch64

[Marco]

Public bug reported:

All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
when run on an aarch64 odroid Ubuntu.


Steps to reproduce:

root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
Segmentation fault (core dumped)
root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
qemu-s390x version 4.2.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
Segmentation fault (core dumped)
root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

qemu-arm does work on the same machine:

root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
Running 4 test cases...

*** No errors detected
root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
Running 4 test cases...

*** No errors detected


What kind of debug information would be helpful for this issue report?
GDB for the self-compiled latest release is not particularly helpful:

(gdb) run
Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fb7a2a140 (LWP 28264)]

Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
0x0096b218 in __bss_start__ ()
(gdb) bt
#0  0x0096b218 in __bss_start__ ()
#1  0x006120a8 in ?? ()
#2  0x0055579904b0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


A bit more information is available in the version shipped by Ubuntu:

(gdb) run
Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fb7a01180 (LWP 28271)]

Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
0x00738f98 in code_gen_buffer ()
(gdb) bt
#0  0x00738f98 in code_gen_buffer ()
#1  0x005e96c8 in cpu_exec ()
#2  0x005ee430 in cpu_loop ()
#3  0x005c3328 in main ()

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.
+ 
  
  Steps to reproduce:
  
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
  
- 
  qemu-arm does work on the same machine:
  
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...
  
  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...
  
  *** No errors detected
  
  
+ 
  What kind of debug information would be helpful for this issue report?
- 
- 
  GDB for the self-compiled latest release is not particularly helpful:
  
  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]
  
  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)
  
+ 
+ 
  A bit more information is available in the version shipped by Ubuntu:
  
  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-

Re: [PATCH] docs: Fix virtiofsd.1 location

[Peter Maydell]

On Wed, 12 Feb 2020 at 16:51, Philippe Mathieu-Daudé  wrote:
> We stopped testing in-tree builds 2 months ago:
>
> commit bc4486fb233573e77b6e9ad6d6379afb5e37ad8c
> Author: Paolo Bonzini 
> Date:   Wed Dec 11 15:33:49 2019 +0100
>
>  ci: build out-of-tree
>
>  Most developers are using out-of-tree builds and it was discussed
> in the past
>  to only allow those.  To prepare for the transition, use
> out-of-tree builds
>  in all continuous integration jobs.

I'd missed that. Paolo, do you have a plan for following
through and actively forbidding in-tree-builds, if that's
the route we're taking ?

thanks
-- PMM

RE: [RFC PATCH 29/66] Hexagon opcode data structures

[Taylor Simpson]

> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Tuesday, February 11, 2020 1:41 AM
> To: Taylor Simpson ; qemu-devel@nongnu.org
> Cc: richard.hender...@linaro.org; laur...@vivier.eu; riku.voi...@iki.fi;
> aleksandar.m.m...@gmail.com
> Subject: Re: [RFC PATCH 29/66] Hexagon opcode data structures
>
> > +#ifndef OPCODES_H
>
> HEXAGON_OPCODES_H
>
> I wonder if it would ease review to split this patch in 2, keep the C
> here, but provide opcodes.h in an earlier patch.

Wouldn't using scripts/git.orderfile solve this just as well?  It will put 
opcodes.h ahead of opcodes.c in this patch.

>
> > +#define OPCODES_H
> > +

[PULL 5/5] MAINTAINERS: Add maintainer entry for Goldfish RTC

[Palmer Dabbelt]

From: Anup Patel 

Add myself as Goldfish RTC maintainer until someone else is
willing to maintain it.

Signed-off-by: Anup Patel 
Reviewed-by: Alistair Francis 
Signed-off-by: Palmer Dabbelt 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ce46c0a552..43d29ea662 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,14 @@ F: include/hw/arm/digic.h
 F: hw/*/digic*
 F: include/hw/*/digic*
 
+Goldfish RTC
+M: Anup Patel 
+M: Alistair Francis 
+L: qemu-ri...@nongnu.org
+S: Maintained
+F: hw/rtc/goldfish_rtc.c
+F: include/hw/rtc/goldfish_rtc.h
+
 Gumstix
 M: Peter Maydell 
 R: Philippe Mathieu-Daudé 
-- 
2.25.0.225.g125e21ebc7-goog

[PULL 4/5] riscv: virt: Use Goldfish RTC device

[Palmer Dabbelt]

From: Anup Patel 

We extend QEMU RISC-V virt machine by adding Goldfish RTC device
to it. This will allow Guest Linux to sync it's local date/time
with Host date/time via RTC device.

Signed-off-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Reviewed-by: Alistair Francis 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/Kconfig|  1 +
 hw/riscv/virt.c | 16 
 include/hw/riscv/virt.h |  2 ++
 3 files changed, 19 insertions(+)

diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index b12660b9f8..ff9fbe958a 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -34,6 +34,7 @@ config RISCV_VIRT
 select PCI
 select HART
 select SERIAL
+select GOLDFISH_RTC
 select VIRTIO_MMIO
 select PCI_EXPRESS_GENERIC_BRIDGE
 select PFLASH_CFI01
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 6d682f8a78..7f9e1e5176 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -58,6 +58,7 @@ static const struct MemmapEntry {
 [VIRT_DEBUG] =   {0x0, 0x100 },
 [VIRT_MROM] ={ 0x1000,   0x11000 },
 [VIRT_TEST] ={   0x10,0x1000 },
+[VIRT_RTC] = {   0x101000,0x1000 },
 [VIRT_CLINT] =   {  0x200,   0x1 },
 [VIRT_PLIC] ={  0xc00, 0x400 },
 [VIRT_UART0] =   { 0x1000, 0x100 },
@@ -404,6 +405,18 @@ static void create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
 }
 g_free(nodename);
 
+nodename = g_strdup_printf("/rtc@%lx",
+(long)memmap[VIRT_RTC].base);
+qemu_fdt_add_subnode(fdt, nodename);
+qemu_fdt_setprop_string(fdt, nodename, "compatible",
+"google,goldfish-rtc");
+qemu_fdt_setprop_cells(fdt, nodename, "reg",
+0x0, memmap[VIRT_RTC].base,
+0x0, memmap[VIRT_RTC].size);
+qemu_fdt_setprop_cell(fdt, nodename, "interrupt-parent", plic_phandle);
+qemu_fdt_setprop_cell(fdt, nodename, "interrupts", RTC_IRQ);
+g_free(nodename);
+
 nodename = g_strdup_printf("/flash@%" PRIx64, flashbase);
 qemu_fdt_add_subnode(s->fdt, nodename);
 qemu_fdt_setprop_string(s->fdt, nodename, "compatible", "cfi-flash");
@@ -601,6 +614,9 @@ static void riscv_virt_board_init(MachineState *machine)
 0, qdev_get_gpio_in(DEVICE(s->plic), UART0_IRQ), 399193,
 serial_hd(0), DEVICE_LITTLE_ENDIAN);
 
+sysbus_create_simple("goldfish_rtc", memmap[VIRT_RTC].base,
+qdev_get_gpio_in(DEVICE(s->plic), RTC_IRQ));
+
 virt_flash_create(s);
 
 for (i = 0; i < ARRAY_SIZE(s->flash); i++) {
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index b17048a93a..e69355efaf 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -44,6 +44,7 @@ enum {
 VIRT_DEBUG,
 VIRT_MROM,
 VIRT_TEST,
+VIRT_RTC,
 VIRT_CLINT,
 VIRT_PLIC,
 VIRT_UART0,
@@ -57,6 +58,7 @@ enum {
 
 enum {
 UART0_IRQ = 10,
+RTC_IRQ = 11,
 VIRTIO_IRQ = 1, /* 1 to 8 */
 VIRTIO_COUNT = 8,
 PCIE_IRQ = 0x20, /* 32 to 35 */
-- 
2.25.0.225.g125e21ebc7-goog

[PULL] RISC-V Patches for the 5.0 Soft Freeze, Part 2

[Palmer Dabbelt]

The following changes since commit 81a23caf47956778c5a5056ad656d1ef92bf9659:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2020-02-10 17:08:51 +)

are available in the Git repository at:

  g...@github.com:palmer-dabbelt/qemu.git tags/riscv-for-master-5.0-sf2

for you to fetch changes up to 9c8fdcece53e05590441785ab22d91a22da36e29:

  MAINTAINERS: Add maintainer entry for Goldfish RTC (2020-02-10 12:01:39 -0800)


RISC-V Patches for the 5.0 Soft Freeze, Part 2

This is a fairly light-weight pull request, but I wanted to send it out to
avoid the Goldfish stuff getting buried as the next PR should contain the H
extension implementation.

As far as this PR goes, it contains:

* The addition of syscon device tree nodes for reboot and poweroff, which
  allows Linux to control QEMU without an additional driver.  The existing
  device was already compatible with the syscon interface.
* A fix to our GDB stub to avoid confusing XLEN and FLEN, specifically useful
  for rv32id-based systems.
* A device emulation for the Goldfish RTC device, a simple memory-mapped RTC.
* The addition of the Goldfish RTC device to the RISC-V virt board.

This passes "make check" and boots buildroot for me.



Peter: I'm sending hw/rtc code because it was suggested that the Goldfish
implementation gets handled via the RISC-V tree as our virt board is the only
user.  I'm happy to do things differently in the future (maybe send
goldfish-specific PRs?) if that's better for you.  Just LMK what makes sense, I
anticipate that this'll be a pretty low traffic device so I'm fine with pretty
much anything.


Anup Patel (4):
  riscv/virt: Add syscon reboot and poweroff DT nodes
  hw: rtc: Add Goldfish RTC device
  riscv: virt: Use Goldfish RTC device
  MAINTAINERS: Add maintainer entry for Goldfish RTC

Keith Packard (1):
  riscv: Separate FPU register size from core register size in gdbstub [v2]

 MAINTAINERS   |   8 ++
 configure |   4 +-
 hw/riscv/Kconfig  |   1 +
 hw/riscv/virt.c   |  42 ++-
 hw/rtc/Kconfig|   3 +
 hw/rtc/Makefile.objs  |   1 +
 hw/rtc/goldfish_rtc.c | 285 ++
 hw/rtc/trace-events   |   4 +
 include/hw/riscv/virt.h   |   2 +
 include/hw/rtc/goldfish_rtc.h |  46 +++
 target/riscv/gdbstub.c|  20 +--
 11 files changed, 401 insertions(+), 15 deletions(-)
 create mode 100644 hw/rtc/goldfish_rtc.c
 create mode 100644 include/hw/rtc/goldfish_rtc.h

[PULL 1/5] riscv/virt: Add syscon reboot and poweroff DT nodes

[Palmer Dabbelt]

From: Anup Patel 

The SiFive test device found on virt machine can be used by
generic syscon reboot and poweroff drivers available in Linux
kernel.

This patch updates FDT generation in virt machine so that
Linux kernel can probe and use generic syscon drivers.

Signed-off-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/virt.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index c44b865959..6d682f8a78 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -182,11 +182,10 @@ static void create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
 uint64_t mem_size, const char *cmdline)
 {
 void *fdt;
-int cpu;
+int cpu, i;
 uint32_t *cells;
 char *nodename;
-uint32_t plic_phandle, phandle = 1;
-int i;
+uint32_t plic_phandle, test_phandle, phandle = 1;
 hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
 hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
 
@@ -356,16 +355,35 @@ static void create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
 create_pcie_irq_map(fdt, nodename, plic_phandle);
 g_free(nodename);
 
+test_phandle = phandle++;
 nodename = g_strdup_printf("/test@%lx",
 (long)memmap[VIRT_TEST].base);
 qemu_fdt_add_subnode(fdt, nodename);
 {
-const char compat[] = "sifive,test1\0sifive,test0";
+const char compat[] = "sifive,test1\0sifive,test0\0syscon";
 qemu_fdt_setprop(fdt, nodename, "compatible", compat, sizeof(compat));
 }
 qemu_fdt_setprop_cells(fdt, nodename, "reg",
 0x0, memmap[VIRT_TEST].base,
 0x0, memmap[VIRT_TEST].size);
+qemu_fdt_setprop_cell(fdt, nodename, "phandle", test_phandle);
+test_phandle = qemu_fdt_get_phandle(fdt, nodename);
+g_free(nodename);
+
+nodename = g_strdup_printf("/reboot");
+qemu_fdt_add_subnode(fdt, nodename);
+qemu_fdt_setprop_string(fdt, nodename, "compatible", "syscon-reboot");
+qemu_fdt_setprop_cell(fdt, nodename, "regmap", test_phandle);
+qemu_fdt_setprop_cell(fdt, nodename, "offset", 0x0);
+qemu_fdt_setprop_cell(fdt, nodename, "value", FINISHER_RESET);
+g_free(nodename);
+
+nodename = g_strdup_printf("/poweroff");
+qemu_fdt_add_subnode(fdt, nodename);
+qemu_fdt_setprop_string(fdt, nodename, "compatible", "syscon-poweroff");
+qemu_fdt_setprop_cell(fdt, nodename, "regmap", test_phandle);
+qemu_fdt_setprop_cell(fdt, nodename, "offset", 0x0);
+qemu_fdt_setprop_cell(fdt, nodename, "value", FINISHER_PASS);
 g_free(nodename);
 
 nodename = g_strdup_printf("/uart@%lx",
-- 
2.25.0.225.g125e21ebc7-goog

[PULL 3/5] hw: rtc: Add Goldfish RTC device

[Palmer Dabbelt]

From: Anup Patel 

This patch adds model for Google Goldfish virtual platform RTC device.

We will be adding Goldfish RTC device to the QEMU RISC-V virt machine
for providing real date-time to Guest Linux. The corresponding Linux
driver for Goldfish RTC device is already available in upstream Linux.

For now, VM migration support is available but untested for Goldfish RTC
device. It will be hardened in-future when we implement VM migration for
KVM RISC-V.

Signed-off-by: Anup Patel 
Reviewed-by: Alistair Francis 
Signed-off-by: Palmer Dabbelt 
---
 hw/rtc/Kconfig|   3 +
 hw/rtc/Makefile.objs  |   1 +
 hw/rtc/goldfish_rtc.c | 285 ++
 hw/rtc/trace-events   |   4 +
 include/hw/rtc/goldfish_rtc.h |  46 ++
 5 files changed, 339 insertions(+)
 create mode 100644 hw/rtc/goldfish_rtc.c
 create mode 100644 include/hw/rtc/goldfish_rtc.h

diff --git a/hw/rtc/Kconfig b/hw/rtc/Kconfig
index 3dc2dd6888..f06e133b8a 100644
--- a/hw/rtc/Kconfig
+++ b/hw/rtc/Kconfig
@@ -22,3 +22,6 @@ config MC146818RTC
 
 config SUN4V_RTC
 bool
+
+config GOLDFISH_RTC
+bool
diff --git a/hw/rtc/Makefile.objs b/hw/rtc/Makefile.objs
index 8dc9fcd3a9..aa208d0d10 100644
--- a/hw/rtc/Makefile.objs
+++ b/hw/rtc/Makefile.objs
@@ -11,3 +11,4 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_rtc.o
 obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
 common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_rtc.o
+common-obj-$(CONFIG_GOLDFISH_RTC) += goldfish_rtc.o
diff --git a/hw/rtc/goldfish_rtc.c b/hw/rtc/goldfish_rtc.c
new file mode 100644
index 00..01e9d2b083
--- /dev/null
+++ b/hw/rtc/goldfish_rtc.c
@@ -0,0 +1,285 @@
+/*
+ * Goldfish virtual platform RTC
+ *
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * For more details on Google Goldfish virtual platform refer:
+ * 
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-2.0-release/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "hw/rtc/goldfish_rtc.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "qemu/bitops.h"
+#include "qemu/timer.h"
+#include "sysemu/sysemu.h"
+#include "qemu/cutils.h"
+#include "qemu/log.h"
+
+#include "trace.h"
+
+#define RTC_TIME_LOW0x00
+#define RTC_TIME_HIGH   0x04
+#define RTC_ALARM_LOW   0x08
+#define RTC_ALARM_HIGH  0x0c
+#define RTC_IRQ_ENABLED 0x10
+#define RTC_CLEAR_ALARM 0x14
+#define RTC_ALARM_STATUS0x18
+#define RTC_CLEAR_INTERRUPT 0x1c
+
+static void goldfish_rtc_update(GoldfishRTCState *s)
+{
+qemu_set_irq(s->irq, (s->irq_pending & s->irq_enabled) ? 1 : 0);
+}
+
+static void goldfish_rtc_interrupt(void *opaque)
+{
+GoldfishRTCState *s = (GoldfishRTCState *)opaque;
+
+s->alarm_running = 0;
+s->irq_pending = 1;
+goldfish_rtc_update(s);
+}
+
+static uint64_t goldfish_rtc_get_count(GoldfishRTCState *s)
+{
+return s->tick_offset + (uint64_t)qemu_clock_get_ns(rtc_clock);
+}
+
+static void goldfish_rtc_clear_alarm(GoldfishRTCState *s)
+{
+timer_del(s->timer);
+s->alarm_running = 0;
+}
+
+static void goldfish_rtc_set_alarm(GoldfishRTCState *s)
+{
+uint64_t ticks = goldfish_rtc_get_count(s);
+uint64_t event = s->alarm_next;
+
+if (event <= ticks) {
+goldfish_rtc_clear_alarm(s);
+goldfish_rtc_interrupt(s);
+} else {
+/*
+ * We should be setting timer expiry to:
+ * qemu_clock_get_ns(rtc_clock) + (event - ticks)
+ * but this is equivalent to:
+ * event - s->tick_offset
+ */
+timer_mod(s->timer, event - s->tick_offset);
+s->alarm_running = 1;
+}
+}
+
+static uint64_t goldfish_rtc_read(void *opaque, hwaddr offset,
+  unsigned size)
+{
+GoldfishRTCState *s = opaque;
+uint64_t r = 0;
+
+switch (offset) {
+case RTC_TIME_LOW:
+r = goldfish_rtc_get_count(s) & 0x;
+break;
+case RTC_TIME_HIGH:
+r = goldfish_rtc_get_count(s) >> 32;
+break;
+case RTC_ALARM_LOW:
+r = s->alarm_next & 0x;
+break;
+case RTC_ALARM_HIGH:
+r = s->alarm_next >> 32;
+break;
+   

[PULL 2/5] riscv: Separate FPU register size from core register size in gdbstub [v2]

[Palmer Dabbelt]

From: Keith Packard 

The size of the FPU registers is dictated by the 'f' and 'd' features,
not the core processor register size. Processors with the 'd' feature
have 64-bit FPU registers. Processors without the 'd' feature but with
the 'f' feature have 32-bit FPU registers.

Signed-off-by: Keith Packard 
[Palmer: This requires manually triggering a rebuild of
riscv32-softmmu/gdbstub-xml.c]
Signed-off-by: Palmer Dabbelt 
---
 configure  |  4 ++--
 target/riscv/gdbstub.c | 20 +++-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 115dc38085..d1b9e75676 100755
--- a/configure
+++ b/configure
@@ -7736,13 +7736,13 @@ case "$target_name" in
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
 mttcg=yes
-gdb_xml_files="riscv-32bit-cpu.xml riscv-32bit-fpu.xml riscv-32bit-csr.xml 
riscv-32bit-virtual.xml"
+gdb_xml_files="riscv-32bit-cpu.xml riscv-32bit-fpu.xml riscv-64bit-fpu.xml 
riscv-32bit-csr.xml riscv-32bit-virtual.xml"
   ;;
   riscv64)
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
 mttcg=yes
-gdb_xml_files="riscv-64bit-cpu.xml riscv-64bit-fpu.xml riscv-64bit-csr.xml 
riscv-64bit-virtual.xml"
+gdb_xml_files="riscv-64bit-cpu.xml riscv-32bit-fpu.xml riscv-64bit-fpu.xml 
riscv-64bit-csr.xml riscv-64bit-virtual.xml"
   ;;
   sh4|sh4eb)
 TARGET_ARCH=sh4
diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index 1a7947e019..1a72f7be9c 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -303,7 +303,12 @@ int riscv_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 static int riscv_gdb_get_fpu(CPURISCVState *env, uint8_t *mem_buf, int n)
 {
 if (n < 32) {
-return gdb_get_reg64(mem_buf, env->fpr[n]);
+if (env->misa & RVD) {
+return gdb_get_reg64(mem_buf, env->fpr[n]);
+}
+if (env->misa & RVF) {
+return gdb_get_reg32(mem_buf, env->fpr[n]);
+}
 /* there is hole between ft11 and fflags in fpu.xml */
 } else if (n < 36 && n > 32) {
 target_ulong val = 0;
@@ -403,23 +408,20 @@ void riscv_cpu_register_gdb_regs_for_features(CPUState 
*cs)
 {
 RISCVCPU *cpu = RISCV_CPU(cs);
 CPURISCVState *env = &cpu->env;
-#if defined(TARGET_RISCV32)
-if (env->misa & RVF) {
+if (env->misa & RVD) {
+gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,
+ 36, "riscv-64bit-fpu.xml", 0);
+} else if (env->misa & RVF) {
 gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,
  36, "riscv-32bit-fpu.xml", 0);
 }
-
+#if defined(TARGET_RISCV32)
 gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,
  240, "riscv-32bit-csr.xml", 0);
 
 gdb_register_coprocessor(cs, riscv_gdb_get_virtual, riscv_gdb_set_virtual,
  1, "riscv-32bit-virtual.xml", 0);
 #elif defined(TARGET_RISCV64)
-if (env->misa & RVF) {
-gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,
- 36, "riscv-64bit-fpu.xml", 0);
-}
-
 gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,
  240, "riscv-64bit-csr.xml", 0);
 
-- 
2.25.0.225.g125e21ebc7-goog

RE: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback

[Shameerali Kolothum Thodi]

> -Original Message-
> From: David Hildenbrand [mailto:da...@redhat.com]
> Sent: 10 February 2020 09:54
> To: Shameerali Kolothum Thodi ;
> Igor Mammedov 
> Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
> m...@redhat.com; shannon.zha...@gmail.com; qemu-devel@nongnu.org;
> xuwei (O) ; Linuxarm ;
> eric.au...@redhat.com; qemu-...@nongnu.org; ler...@redhat.com
> Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
> 
> On 10.02.20 10:50, Shameerali Kolothum Thodi wrote:
> >
> >
> >> -Original Message-
> >> From: David Hildenbrand [mailto:da...@redhat.com]
> >> Sent: 10 February 2020 09:29
> >> To: Shameerali Kolothum Thodi ;
> >> Igor Mammedov 
> >> Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
> >> m...@redhat.com; shannon.zha...@gmail.com; qemu-devel@nongnu.org;
> >> xuwei (O) ; Linuxarm ;
> >> eric.au...@redhat.com; qemu-...@nongnu.org; ler...@redhat.com
> >> Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
> >>
>  Can you look the original value up somehow and us the resize callback
>  only as a notification that something changed? (that value would have to
>  be stored somewhere and migrated I assume - maybe that's already
> being
>  done)
> >>>
> >>> Ok. I will take a look at that. But can we instead pass the
> block->used_length
> >> to
> >>> fw_cfg_add_file_callback(). That way we don’t have to change the
> >> qemu_ram_resize()
> >>> as well. I think Igor has suggested this before[1] and I had a go at it 
> >>> before
> >> coming up
> >>> with the "req_length" proposal here.
> >>
> >> You mean, passing the old size as well? I don't see how that will solve
> >> the issue, but yeah, nothing speaks against simply sending the old and
> >> the new size.
> >
> > Nope. I actually meant using the block->used_length to store in the
> > s->files->f[index].size.
> >
> > virt_acpi_setup()
> >   acpi_add_rom_blob()
> > rom_add_blob()
> >   rom_set_mr()  --> used_length  = page aligned blob size
> > fw_cfg_add_file_callback()  --> uses actual blob size.
> >
> >
> > Right now what we do is use the actual blob size to store in FWCfgEntry.
> > Instead pass the RAMBlock used_length to fw_cfg_add_file_callback().
> > Of course by this, the firmware will see an aligned size, but that is fine 
> > I think.
> > But at the same time this means the qemu_ram_resize() can stay as it is
> > because it will invoke the callback when the size changes beyond the aligned
> > page size. And also during migration, there won't be any inconsistency as
> everyone
> > works on aligned page size.
> >
> > Does that make sense? Or I am again missing something here?
> 
> Oh, you mean simply rounding up to full pages in the fw entries? If we
> can drop the "sub-page" restriction, that would be awesome!
> 
> Need to double check if that could be an issue for fw/migration/whatever.

Hmm..it breaks x86 + seabios boot. The issue is seabios expects RSDP in FSEG
memory. With the above proposed change, RSDP will be aligned to PAGE_SIZE and
seabios mem allocation for RSDP fails at,

https://github.com/coreboot/seabios/blob/master/src/fw/romfile_loader.c#L85

To get pass the above, I changed "alloc_fseg" flag to false in build_rsdp(), but
seabios seems to make the assumption that RSDP has to be placed in FSEG memory
here,
https://github.com/coreboot/seabios/blob/master/src/fw/biostables.c#L126

So doesn’t look like there is an easy fix for this without changing the seabios 
code.

Between, OVMF works fine with the aligned size on x86.

One thing we can do is treat the RSDP case separately or only use the aligned
page size for "etc/acpi/tables" as below,

diff --git a/hw/core/loader.c b/hw/core/loader.c
index d1b78f60cd..f07f6a7a35 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -60,6 +60,7 @@
 #include "hw/boards.h"
 #include "qemu/cutils.h"
 #include "sysemu/runstate.h"
+#include "hw/acpi/aml-build.h"
 
 #include 
 
@@ -1056,6 +1057,7 @@ MemoryRegion *rom_add_blob(const char *name, const void 
*blob, size_t len,
 if (fw_file_name && fw_cfg) {
 char devpath[100];
 void *data;
+size_t size = rom->datasize;
 
 if (read_only) {
 snprintf(devpath, sizeof(devpath), "/rom@%s", fw_file_name);
@@ -1066,13 +1068,21 @@ MemoryRegion *rom_add_blob(const char *name, const void 
*blob, size_t len,
 if (mc->rom_file_has_mr) {
 data = rom_set_mr(rom, OBJECT(fw_cfg), devpath, read_only);
 mr = rom->mr;
+   /*
+* Use the RAMblk used_length for acpi tables as this avoids any
+* inconsistency with table size changes during hot add and during
+* migration.
+*/
+   if (strcmp(fw_file_name, ACPI_BUILD_TABLE_FILE) == 0) {
+size = memory_region_get_used_length(mr);
+   }
 } else {
 data = rom->data;
 }
 
 fw_cfg_add_file_callback(fw_cfg, fw_file_name,
 

Re: [PATCH] docs: Fix virtiofsd.1 location

[Philippe Mathieu-Daudé]

On 2/12/20 5:02 PM, Peter Maydell wrote:

On Wed, 12 Feb 2020 at 14:28, Daniel P. Berrangé  wrote:


On Wed, Feb 12, 2020 at 02:18:19PM +, Peter Maydell wrote:

On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:


Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
page virtiofsd.1. Unfortunately, wrong file location is used as
source for install command. This cause installation of docs fail.

Fixing wrong location so installation is successful.

Signed-off-by: Miroslav Rezanina 


Reviewed-by: Peter Maydell 

I noticed this in review of v1 of the patch
https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
but missed that it hadn't been fixed in v2/v3.


How come the mistake didn't break any of our CI ?  Looks like it
should have failed due to non-existing source file


We stopped testing in-tree builds 2 months ago:

commit bc4486fb233573e77b6e9ad6d6379afb5e37ad8c
Author: Paolo Bonzini 
Date:   Wed Dec 11 15:33:49 2019 +0100

ci: build out-of-tree

Most developers are using out-of-tree builds and it was discussed 
in the past
to only allow those.  To prepare for the transition, use 
out-of-tree builds

in all continuous integration jobs.



I imagine all our CI setups use separate-build-dir and don't
test 'make install'. This only shows up if you do build-in-source-tree
and then 'make install'. (In a separate-build-dir setup, the
MANUAL_BUILDDIR is the same as the actual build dir,
which is the same as make's current working directory, so
forgetting it in the install rune doesn't matter. In a build from
the source tree, Sphinx requires the output to be to a
different directory than the source, so we have to create
a subdirectory to be the MANUAL_BUILDDIR.)

thanks
-- PMM

RE: [PATCH v3 0/4] linux-user: fix use of SIGRTMIN

[Taylor Simpson]

Tested-by: Taylor Simpson 

> -Original Message-
> From: Laurent Vivier 
> Sent: Wednesday, February 12, 2020 6:57 AM
> To: qemu-devel@nongnu.org
> Cc: Aleksandar Markovic ; Laurent Vivier
> ; Matus Kysel ;
> milos.stojano...@rt-rk.com; Riku Voipio ; Josh Kunz
> ; Taylor Simpson ; Peter Maydell
> ; Marlies Ruck 
> Subject: [PATCH v3 0/4] linux-user: fix use of SIGRTMIN
>
> This series fixes the problem of the first real-time signals already
> in use by the glibc that are not available for the target glibc.
>
> Instead of reverting the first and last real-time signals we rely on
> the value provided by the glibc (SIGRTMIN) to know the first available
> signal and we map all the signals from this value to SIGRTMAX on top
> of TARGET_SIGRTMIN. So the consequence is we have less available signals
> in the target (generally 2) but all seems fine as at least 30 signals are
> still available.
>
> This has been tested with Go (golang 1.10.1 linux/arm64, bionic) on x86_64
> fedora 31. We can avoid the failure in this case allowing the unsupported
> signals when we don't provide the "act" parameters to sigaction, only the
> "oldact" one. I have also run the LTP suite with several target and debian
> based distros.
>
> v3: use trace_event_get_state_backends()
> update comments
> Add R-b
>
> v2: tested with golang 1.12.10 linux/arm64, eoan)
> Ignore unsupported signals rather than returning an error
> replace i, j by target_sig, host_sig
>
> Laurent Vivier (4):
>   linux-user: add missing TARGET_SIGRTMIN for hppa
>   linux-user: cleanup signal.c
>   linux-user: fix TARGET_NSIG and _NSIG uses
>   linux-user: fix use of SIGRTMIN
>
>  linux-user/hppa/target_signal.h |   1 +
>  linux-user/signal.c | 134 
>  linux-user/trace-events |   3 +
>  3 files changed, 106 insertions(+), 32 deletions(-)
>
> --
> 2.24.1

Re: [PATCH v2] linux-user: implement TARGET_SO_PEERSEC

[Philippe Mathieu-Daudé]

On 2/12/20 5:43 PM, Laurent Vivier wrote:

Le 12/02/2020 à 17:08, Philippe Mathieu-Daudé a écrit :

On 2/12/20 5:03 PM, Laurent Vivier wrote:

Le 12/02/2020 à 16:56, Philippe Mathieu-Daudé a écrit :

On 2/4/20 10:19 PM, Laurent Vivier wrote:

"The purpose of this option is to allow an application to obtain the
security credentials of a Unix stream socket peer.  It is analogous to
SO_PEERCRED (which provides authentication using standard Unix
credentials
of pid, uid and gid), and extends this concept to other security
models." -- https://lwn.net/Articles/62370/

Until now it was passed to the kernel with an "int" argument and
fails when it was supported by the host because the parameter is
like a filename: it is always a \0-terminated string with no embedded
\0 characters, but is not guaranteed to be ASCII or UTF-8.

I've tested the option with the following program:

   /*
    * cc -o getpeercon getpeercon.c
    */

   #include 
   #include 
   #include 
   #include 
   #include 

   int main(void)
   {
   int fd;
   struct sockaddr_in server, addr;
   int ret;
   socklen_t len;
   char buf[256];

   fd = socket(PF_INET, SOCK_STREAM, 0);
   if (fd == -1) {
   perror("socket");
   return 1;
   }

   server.sin_family = AF_INET;
   inet_aton("127.0.0.1", &server.sin_addr);
   server.sin_port = htons(40390);

   connect(fd, (struct sockaddr*)&server, sizeof(server));

   len = sizeof(buf);
   ret = getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, &len);
   if (ret == -1) {
   perror("getsockopt");
   return 1;
   }
   printf("%d %s\n", len, buf);
   return 0;
   }

On host:

     $ ./getpeercon
     33 system_u:object_r:unlabeled_t:s0

With qemu-aarch64/bionic without the patch:

     $ ./getpeercon
     getsockopt: Numerical result out of range

With the patch:

     $ ./getpeercon
     33 system_u:object_r:unlabeled_t:s0

Bug: https://bugs.launchpad.net/qemu/+bug/1823790
Reported-by: Matthias Lüscher 
Tested-by: Matthias Lüscher 
Signed-off-by: Laurent Vivier 
---

Notes:
   v2: use correct length in unlock_user()

    linux-user/syscall.c | 22 ++
    1 file changed, 22 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d60142f0691c..c930577686da 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2344,6 +2344,28 @@ static abi_long do_getsockopt(int sockfd, int
level, int optname,
    }
    break;
    }
+    case TARGET_SO_PEERSEC: {
+    char *name;
+
+    if (get_user_u32(len, optlen)) {
+    return -TARGET_EFAULT;
+    }
+    if (len < 0) {
+    return -TARGET_EINVAL;
+    }
+    name = lock_user(VERIFY_WRITE, optval_addr, len, 0);
+    if (!name) {
+    return -TARGET_EFAULT;
+    }
+    lv = len;
+    ret = get_errno(getsockopt(sockfd, level, SO_PEERSEC,
+   name, &lv));


Can we get lv > len?


No:

getsockopt(2)

"For  getsockopt(), optlen is a value-result argument, initially
containing the size of the buffer pointed to by optval, and modified on
return to  indicate the  actual  size  of  the value returned."




+    if (put_user_u32(lv, optlen)) {
+    ret = -TARGET_EFAULT;
+    }
+    unlock_user(name, optval_addr, lv);


Maybe safer to use len instead of lv here?


No:

this is the length of the buffer we must copy back to the user. Kernel
has only modified lv length, not len.


So we can simplify the TARGET_SO_LINGER case then.


No, this case is different because lglen is sizeof(struct linger) and it
can differ from len. So lglen can be greater than len.

If you check the kernel you can see if the buffer is not big enough the
data are partially copied. This is partially done in our code because
the __put_user() can overflow the user memory but we return len to the
caller. To fix that, we should use a local target_linger to change
endianness and then copy the local copy to the user copy using len.


Ah OK I understand now, thanks for the explanation.





linux-user/qemu.h

/* Unlock an area of guest memory.  The first LEN bytes must be
     flushed back to guest memory. host_ptr = NULL is explicitly
     allowed and does nothing. */
static inline void unlock_user(void *host_ptr, abi_ulong guest_addr,
     long len)



Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 



Thank you.

Laurent

Re: [PATCH v2] linux-user: implement TARGET_SO_PEERSEC

[Laurent Vivier]

Le 12/02/2020 à 17:08, Philippe Mathieu-Daudé a écrit :
> On 2/12/20 5:03 PM, Laurent Vivier wrote:
>> Le 12/02/2020 à 16:56, Philippe Mathieu-Daudé a écrit :
>>> On 2/4/20 10:19 PM, Laurent Vivier wrote:
 "The purpose of this option is to allow an application to obtain the
 security credentials of a Unix stream socket peer.  It is analogous to
 SO_PEERCRED (which provides authentication using standard Unix
 credentials
 of pid, uid and gid), and extends this concept to other security
 models." -- https://lwn.net/Articles/62370/

 Until now it was passed to the kernel with an "int" argument and
 fails when it was supported by the host because the parameter is
 like a filename: it is always a \0-terminated string with no embedded
 \0 characters, but is not guaranteed to be ASCII or UTF-8.

 I've tested the option with the following program:

   /*
    * cc -o getpeercon getpeercon.c
    */

   #include 
   #include 
   #include 
   #include 
   #include 

   int main(void)
   {
   int fd;
   struct sockaddr_in server, addr;
   int ret;
   socklen_t len;
   char buf[256];

   fd = socket(PF_INET, SOCK_STREAM, 0);
   if (fd == -1) {
   perror("socket");
   return 1;
   }

   server.sin_family = AF_INET;
   inet_aton("127.0.0.1", &server.sin_addr);
   server.sin_port = htons(40390);

   connect(fd, (struct sockaddr*)&server, sizeof(server));

   len = sizeof(buf);
   ret = getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, &len);
   if (ret == -1) {
   perror("getsockopt");
   return 1;
   }
   printf("%d %s\n", len, buf);
   return 0;
   }

 On host:

     $ ./getpeercon
     33 system_u:object_r:unlabeled_t:s0

 With qemu-aarch64/bionic without the patch:

     $ ./getpeercon
     getsockopt: Numerical result out of range

 With the patch:

     $ ./getpeercon
     33 system_u:object_r:unlabeled_t:s0

 Bug: https://bugs.launchpad.net/qemu/+bug/1823790
 Reported-by: Matthias Lüscher 
 Tested-by: Matthias Lüscher 
 Signed-off-by: Laurent Vivier 
 ---

 Notes:
   v2: use correct length in unlock_user()

    linux-user/syscall.c | 22 ++
    1 file changed, 22 insertions(+)

 diff --git a/linux-user/syscall.c b/linux-user/syscall.c
 index d60142f0691c..c930577686da 100644
 --- a/linux-user/syscall.c
 +++ b/linux-user/syscall.c
 @@ -2344,6 +2344,28 @@ static abi_long do_getsockopt(int sockfd, int
 level, int optname,
    }
    break;
    }
 +    case TARGET_SO_PEERSEC: {
 +    char *name;
 +
 +    if (get_user_u32(len, optlen)) {
 +    return -TARGET_EFAULT;
 +    }
 +    if (len < 0) {
 +    return -TARGET_EINVAL;
 +    }
 +    name = lock_user(VERIFY_WRITE, optval_addr, len, 0);
 +    if (!name) {
 +    return -TARGET_EFAULT;
 +    }
 +    lv = len;
 +    ret = get_errno(getsockopt(sockfd, level, SO_PEERSEC,
 +   name, &lv));
>>>
>>> Can we get lv > len?
>>
>> No:
>>
>> getsockopt(2)
>>
>> "For  getsockopt(), optlen is a value-result argument, initially
>> containing the size of the buffer pointed to by optval, and modified on
>> return to  indicate the  actual  size  of  the value returned."
>>
>>>
 +    if (put_user_u32(lv, optlen)) {
 +    ret = -TARGET_EFAULT;
 +    }
 +    unlock_user(name, optval_addr, lv);
>>>
>>> Maybe safer to use len instead of lv here?
>>
>> No:
>>
>> this is the length of the buffer we must copy back to the user. Kernel
>> has only modified lv length, not len.
> 
> So we can simplify the TARGET_SO_LINGER case then.

No, this case is different because lglen is sizeof(struct linger) and it
can differ from len. So lglen can be greater than len.

If you check the kernel you can see if the buffer is not big enough the
data are partially copied. This is partially done in our code because
the __put_user() can overflow the user memory but we return len to the
caller. To fix that, we should use a local target_linger to change
endianness and then copy the local copy to the user copy using len.

>>
>> linux-user/qemu.h
>>
>> /* Unlock an area of guest memory.  The first LEN bytes must be
>>     flushed back to guest memory. host_ptr = NULL is explicitly
>>     allowed and does nothing. */
>> sta

[PULL 8/9] target/i386: check for availability of MSR_IA32_UCODE_REV as an emulated MSR

[Paolo Bonzini]

Even though MSR_IA32_UCODE_REV has been available long before Linux 5.6,
which added it to the emulated MSR list, a bug caused the microcode
version to revert to 0x1 on INIT.  As a result, processors other
than the bootstrap processor would not see the host microcode revision;
some Windows version complain loudly about this and crash with a
fairly explicit MICROCODE REVISION MISMATCH error.

[If running 5.6 prereleases, the kernel fix "KVM: x86: do not reset
 microcode version on INIT or RESET" should also be applied.]

Reported-by: Alex Williamson 
Message-id: <20200211175516.10716-1-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 target/i386/kvm.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 6ef291d580..69eb43d796 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -105,6 +105,7 @@ static bool has_msr_smi_count;
 static bool has_msr_arch_capabs;
 static bool has_msr_core_capabs;
 static bool has_msr_vmx_vmfunc;
+static bool has_msr_ucode_rev;
 
 static uint32_t has_architectural_pmu_version;
 static uint32_t num_architectural_pmu_gp_counters;
@@ -2056,6 +2057,9 @@ static int kvm_get_supported_msrs(KVMState *s)
 case MSR_IA32_VMX_VMFUNC:
 has_msr_vmx_vmfunc = true;
 break;
+case MSR_IA32_UCODE_REV:
+has_msr_ucode_rev = true;
+break;
 }
 }
 }
@@ -2696,8 +2700,7 @@ static void kvm_init_msrs(X86CPU *cpu)
   env->features[FEAT_CORE_CAPABILITY]);
 }
 
-if (kvm_arch_get_supported_msr_feature(kvm_state,
-   MSR_IA32_UCODE_REV)) {
+if (has_msr_ucode_rev) {
 kvm_msr_entry_add(cpu, MSR_IA32_UCODE_REV, cpu->ucode_rev);
 }
 
-- 
2.21.0

[PULL 9/9] target/i386: enable monitor and ucode revision with -cpu max

[Paolo Bonzini]

These two features were incorrectly tied to host_cpuid_required rather than
cpu->max_features.  As a result, -cpu max was not enabling either MONITOR
features or ucode revision.

Signed-off-by: Paolo Bonzini 
---
 target/i386/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 32efa46852..92fafa2659 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6414,7 +6414,9 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 error_setg(&local_err, "CPU model '%s' requires KVM", name);
 goto out;
 }
+}
 
+if (cpu->max_features && accel_uses_host_cpuid()) {
 if (enable_cpu_pm) {
 host_cpuid(5, 0, &cpu->mwait.eax, &cpu->mwait.ebx,
&cpu->mwait.ecx, &cpu->mwait.edx);
-- 
2.21.0

[PULL 1/9] vl: Don't mismatch g_strsplit()/g_free()

[Paolo Bonzini]

From: Pan Nengyuan 

It's a mismatch between g_strsplit and g_free, it will cause a memory leak as 
follow:

[root@localhost]# ./aarch64-softmmu/qemu-system-aarch64 -accel help
Accelerators supported in QEMU binary:
tcg
kvm
=
==1207900==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 2 object(s) allocated from:
#0 0xfffd700231cb in __interceptor_malloc (/lib64/libasan.so.4+0xd31cb)
#1 0xfffd6ec57163 in g_malloc (/lib64/libglib-2.0.so.0+0x57163)
#2 0xfffd6ec724d7 in g_strndup (/lib64/libglib-2.0.so.0+0x724d7)
#3 0xfffd6ec73d3f in g_strsplit (/lib64/libglib-2.0.so.0+0x73d3f)
#4 0xaaab66be5077 in main /mnt/sdc/qemu-master/qemu-4.2.0-rc0/vl.c:3517
#5 0xfffd6e140b9f in __libc_start_main (/lib64/libc.so.6+0x20b9f)
#6 0xaaab66bf0f53  (./build/aarch64-softmmu/qemu-system-aarch64+0x8a0f53)

Direct leak of 2 byte(s) in 2 object(s) allocated from:
#0 0xfffd700231cb in __interceptor_malloc (/lib64/libasan.so.4+0xd31cb)
#1 0xfffd6ec57163 in g_malloc (/lib64/libglib-2.0.so.0+0x57163)
#2 0xfffd6ec7243b in g_strdup (/lib64/libglib-2.0.so.0+0x7243b)
#3 0xfffd6ec73e6f in g_strsplit (/lib64/libglib-2.0.so.0+0x73e6f)
#4 0xaaab66be5077 in main /mnt/sdc/qemu-master/qemu-4.2.0-rc0/vl.c:3517
#5 0xfffd6e140b9f in __libc_start_main (/lib64/libc.so.6+0x20b9f)
#6 0xaaab66bf0f53  (./build/aarch64-softmmu/qemu-system-aarch64+0x8a0f53)

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
Message-Id: <20200110091710.53424-2-pannengy...@huawei.com>
Signed-off-by: Paolo Bonzini 
---
 vl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vl.c b/vl.c
index 7dcb0879c4..c5beda7d48 100644
--- a/vl.c
+++ b/vl.c
@@ -3501,7 +3501,7 @@ int main(int argc, char **argv, char **envp)
 gchar **optname = g_strsplit(typename,
  ACCEL_CLASS_SUFFIX, 
0);
 printf("%s\n", optname[0]);
-g_free(optname);
+g_strfreev(optname);
 }
 g_free(typename);
 }
-- 
2.21.0

[PULL 4/9] minikconf: accept alnum identifiers

[Paolo Bonzini]

From: Marc-André Lureau 

Signed-off-by: Marc-André Lureau 
Signed-off-by: Paolo Bonzini 
---
 scripts/minikconf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/minikconf.py b/scripts/minikconf.py
index 40ae1989e1..febd9a479f 100644
--- a/scripts/minikconf.py
+++ b/scripts/minikconf.py
@@ -645,7 +645,7 @@ class KconfigParser:
 self.cursor = self.src.find('\n', self.cursor)
 self.val = self.src[start:self.cursor]
 return TOK_SOURCE
-elif self.tok.isalpha():
+elif self.tok.isalnum():
 # identifier
 while self.src[self.cursor].isalnum() or self.src[self.cursor] == 
'_':
 self.cursor += 1
-- 
2.21.0

[PULL 7/9] target/i386: fix TCG UCODE_REV access

[Paolo Bonzini]

This was a very interesting semantic conflict that caused git to move
the MSR_IA32_UCODE_REV read to helper_wrmsr.  Not a big deal, but
still should be fixed...

Fixes: 4e45aff398 ("target/i386: add a ucode-rev property", 2020-01-24)
Message-id: <20200206171022.9289-1-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 target/i386/misc_helper.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/i386/misc_helper.c b/target/i386/misc_helper.c
index aed16fe3f0..7d61221024 100644
--- a/target/i386/misc_helper.c
+++ b/target/i386/misc_helper.c
@@ -229,7 +229,6 @@ void helper_rdmsr(CPUX86State *env)
 #else
 void helper_wrmsr(CPUX86State *env)
 {
-X86CPU *x86_cpu = env_archcpu(env);
 uint64_t val;
 
 cpu_svm_check_intercept_param(env, SVM_EXIT_MSR, 1, GETPC());
@@ -372,9 +371,6 @@ void helper_wrmsr(CPUX86State *env)
 env->msr_bndcfgs = val;
 cpu_sync_bndcs_hflags(env);
 break;
- case MSR_IA32_UCODE_REV:
-val = x86_cpu->ucode_rev;
-break;
 default:
 if ((uint32_t)env->regs[R_ECX] >= MSR_MC0_CTL
 && (uint32_t)env->regs[R_ECX] < MSR_MC0_CTL +
@@ -393,6 +389,7 @@ void helper_wrmsr(CPUX86State *env)
 
 void helper_rdmsr(CPUX86State *env)
 {
+X86CPU *x86_cpu = env_archcpu(env);
 uint64_t val;
 
 cpu_svm_check_intercept_param(env, SVM_EXIT_MSR, 0, GETPC());
@@ -526,6 +523,9 @@ void helper_rdmsr(CPUX86State *env)
 case MSR_IA32_BNDCFGS:
 val = env->msr_bndcfgs;
 break;
+ case MSR_IA32_UCODE_REV:
+val = x86_cpu->ucode_rev;
+break;
 default:
 if ((uint32_t)env->regs[R_ECX] >= MSR_MC0_CTL
 && (uint32_t)env->regs[R_ECX] < MSR_MC0_CTL +
-- 
2.21.0

[PULL 6/9] build: move TARGET_GPROF to config-host.mak

[Paolo Bonzini]

TARGET_GPROF is the same for all targets, write it to
config-host.mak instead.

Reviewed-by: Alex Bennée 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: <20200204161104.21077-1-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 bsd-user/syscall.c   | 6 +++---
 configure| 4 +++-
 linux-user/exit.c| 4 ++--
 linux-user/signal.c  | 2 +-
 tests/check-block.sh | 2 +-
 5 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index 0d45b654bb..d38ec7a162 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -330,7 +330,7 @@ abi_long do_freebsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 
 switch(num) {
 case TARGET_FREEBSD_NR_exit:
-#ifdef TARGET_GPROF
+#ifdef CONFIG_GPROF
 _mcleanup();
 #endif
 gdb_exit(cpu_env, arg1);
@@ -432,7 +432,7 @@ abi_long do_netbsd_syscall(void *cpu_env, int num, abi_long 
arg1,
 
 switch(num) {
 case TARGET_NETBSD_NR_exit:
-#ifdef TARGET_GPROF
+#ifdef CONFIG_GPROF
 _mcleanup();
 #endif
 gdb_exit(cpu_env, arg1);
@@ -511,7 +511,7 @@ abi_long do_openbsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 
 switch(num) {
 case TARGET_OPENBSD_NR_exit:
-#ifdef TARGET_GPROF
+#ifdef CONFIG_GPROF
 _mcleanup();
 #endif
 gdb_exit(cpu_env, arg1);
diff --git a/configure b/configure
index 115dc38085..16f94cd96b 100755
--- a/configure
+++ b/configure
@@ -6771,6 +6771,9 @@ fi
 if test "$l2tpv3" = "yes" ; then
   echo "CONFIG_L2TPV3=y" >> $config_host_mak
 fi
+if test "$gprof" = "yes" ; then
+  echo "CONFIG_GPROF=y" >> $config_host_mak
+fi
 if test "$cap_ng" = "yes" ; then
   echo "CONFIG_LIBCAP_NG=y" >> $config_host_mak
 fi
@@ -7951,7 +7954,6 @@ alpha)
 esac
 
 if test "$gprof" = "yes" ; then
-  echo "TARGET_GPROF=y" >> $config_target_mak
   if test "$target_linux_user" = "yes" ; then
 cflags="-p $cflags"
 ldflags="-p $ldflags"
diff --git a/linux-user/exit.c b/linux-user/exit.c
index a362ef67d2..1594015444 100644
--- a/linux-user/exit.c
+++ b/linux-user/exit.c
@@ -18,7 +18,7 @@
  */
 #include "qemu/osdep.h"
 #include "qemu.h"
-#ifdef TARGET_GPROF
+#ifdef CONFIG_GPROF
 #include 
 #endif
 
@@ -28,7 +28,7 @@ extern void __gcov_dump(void);
 
 void preexit_cleanup(CPUArchState *env, int code)
 {
-#ifdef TARGET_GPROF
+#ifdef CONFIG_GPROF
 _mcleanup();
 #endif
 #ifdef CONFIG_GCOV
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 5ca6d62b15..02f860ecb9 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -509,7 +509,7 @@ void signal_init(void)
 act.sa_flags = SA_SIGINFO;
 act.sa_sigaction = host_signal_handler;
 for(i = 1; i <= TARGET_NSIG; i++) {
-#ifdef TARGET_GPROF
+#ifdef CONFIG_GPROF
 if (i == SIGPROF) {
 continue;
 }
diff --git a/tests/check-block.sh b/tests/check-block.sh
index 679aedec50..ad320c21ba 100755
--- a/tests/check-block.sh
+++ b/tests/check-block.sh
@@ -16,7 +16,7 @@ if [ "$#" -ne 0 ]; then
 format_list="$@"
 fi
 
-if grep -q "TARGET_GPROF=y" *-softmmu/config-target.mak 2>/dev/null ; then
+if grep -q "CONFIG_GPROF=y" config-host.mak 2>/dev/null ; then
 echo "GPROF is enabled ==> Not running the qemu-iotests."
 exit 0
 fi
-- 
2.21.0

[PULL 3/9] Remove support for CLOCK_MONOTONIC not being defined

[Paolo Bonzini]

From: Peter Maydell 

Some older parts of QEMU's codebase assume that CLOCK_MONOTONIC
might not be defined by the host OS, and have workarounds to
deal with this. However, more recently (notably in commit
50290c002c045280f8d for qemu-img in mid-2019, but also much
earlier in 2011 in commit 22795174a37e0 for ui/spice-display.c)
we've written code that assumes CLOCK_MONOTONIC is always
defined. The only host OS anybody's ever noticed this on
is OSX 10.11 and earlier, which we don't support.

So we can assume that all our host OSes have the #define,
and we can remove some now-unnecessary ifdefs.

Signed-off-by: Peter Maydell 
Message-Id: <20200201172252.6605-1-peter.mayd...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 include/qemu/timer.h |  5 +
 util/qemu-timer-common.c | 11 ---
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 85bc6eb00b..6a8b48b5a9 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -838,14 +838,11 @@ extern int use_rt_clock;
 
 static inline int64_t get_clock(void)
 {
-#ifdef CLOCK_MONOTONIC
 if (use_rt_clock) {
 struct timespec ts;
 clock_gettime(CLOCK_MONOTONIC, &ts);
 return ts.tv_sec * 10LL + ts.tv_nsec;
-} else
-#endif
-{
+} else {
 /* XXX: using gettimeofday leads to problems if the date
changes, so it should be avoided. */
 return get_clock_realtime();
diff --git a/util/qemu-timer-common.c b/util/qemu-timer-common.c
index 06d084d364..baf3317f74 100644
--- a/util/qemu-timer-common.c
+++ b/util/qemu-timer-common.c
@@ -49,14 +49,11 @@ int use_rt_clock;
 
 static void __attribute__((constructor)) init_get_clock(void)
 {
+struct timespec ts;
+
 use_rt_clock = 0;
-#ifdef CLOCK_MONOTONIC
-{
-struct timespec ts;
-if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
-use_rt_clock = 1;
-}
+if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
+use_rt_clock = 1;
 }
-#endif
 }
 #endif
-- 
2.21.0

[PULL 5/9] exec: do not define use_icount for user-mode emulation

[Paolo Bonzini]

use_icount is also defined by stubs/cpu-get-icount.c, we do not need
to have a useless definition in exec.c.

Signed-off-by: Paolo Bonzini 
Message-id: <20200204161036.20889-1-pbonz...@redhat.com>
Reviewed-by: Alex Bennée 
---
 exec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/exec.c b/exec.c
index 67e520d18e..5fc3746053 100644
--- a/exec.c
+++ b/exec.c
@@ -98,15 +98,15 @@ CPUTailQ cpus = QTAILQ_HEAD_INITIALIZER(cpus);
 /* current CPU in the current thread. It is only valid inside
cpu_exec() */
 __thread CPUState *current_cpu;
-/* 0 = Do not count executed instructions.
-   1 = Precise instruction counting.
-   2 = Adaptive rate instruction counting.  */
-int use_icount;
 
 uintptr_t qemu_host_page_size;
 intptr_t qemu_host_page_mask;
 
 #if !defined(CONFIG_USER_ONLY)
+/* 0 = Do not count executed instructions.
+   1 = Precise instruction counting.
+   2 = Adaptive rate instruction counting.  */
+int use_icount;
 
 typedef struct PhysPageEntry PhysPageEntry;
 
-- 
2.21.0

[PULL 0/9] Mini misc patches queue for 2020-02-12

[Paolo Bonzini]

The following changes since commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158:

  Merge remote-tracking branch 
'remotes/huth-gitlab/tags/pull-request-2020-02-04' into staging (2020-02-04 
16:12:31 +)

are available in the Git repository at:

  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to be02cda3afde60d219786e23c3f8edb53aec8e17:

  target/i386: enable monitor and ucode revision with -cpu max (2020-02-12 
16:29:51 +0100)


* various small fixes and cleanups
* fixes for the ucode revision patch from the previous pull request


Luc Michel (1):
  seqlock: fix seqlock_write_unlock_impl function

Marc-André Lureau (1):
  minikconf: accept alnum identifiers

Pan Nengyuan (1):
  vl: Don't mismatch g_strsplit()/g_free()

Paolo Bonzini (5):
  exec: do not define use_icount for user-mode emulation
  build: move TARGET_GPROF to config-host.mak
  target/i386: fix TCG UCODE_REV access
  target/i386: check for availability of MSR_IA32_UCODE_REV as an emulated 
MSR
  target/i386: enable monitor and ucode revision with -cpu max

Peter Maydell (1):
  Remove support for CLOCK_MONOTONIC not being defined

 bsd-user/syscall.c|  6 +++---
 configure |  4 +++-
 exec.c|  8 
 include/qemu/seqlock.h|  4 ++--
 include/qemu/timer.h  |  5 +
 linux-user/exit.c |  4 ++--
 linux-user/signal.c   |  2 +-
 scripts/minikconf.py  |  2 +-
 target/i386/cpu.c |  2 ++
 target/i386/kvm.c |  7 +--
 target/i386/misc_helper.c |  8 
 tests/check-block.sh  |  2 +-
 util/qemu-timer-common.c  | 11 ---
 vl.c  |  2 +-
 14 files changed, 34 insertions(+), 33 deletions(-)
-- 
2.21.0

[PULL 2/9] seqlock: fix seqlock_write_unlock_impl function

[Paolo Bonzini]

From: Luc Michel 

The seqlock write unlock function was incorrectly calling
seqlock_write_begin() instead of seqlock_write_end(), and was releasing
the lock before incrementing the sequence. This could lead to a race
condition and a corrupted sequence number becoming odd even though the
lock is not held.

Signed-off-by: Luc Michel 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20200129144948.2161551-1-luc.mic...@greensocs.com>
Fixes: 988fcafc73 ("seqlock: add QemuLockable support", 2018-08-23)
Signed-off-by: Paolo Bonzini 
---
 include/qemu/seqlock.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/qemu/seqlock.h b/include/qemu/seqlock.h
index fd408b7ec5..8b6b4ee4bb 100644
--- a/include/qemu/seqlock.h
+++ b/include/qemu/seqlock.h
@@ -55,11 +55,11 @@ static inline void seqlock_write_lock_impl(QemuSeqLock *sl, 
QemuLockable *lock)
 #define seqlock_write_lock(sl, lock) \
 seqlock_write_lock_impl(sl, QEMU_MAKE_LOCKABLE(lock))
 
-/* Lock out other writers and update the count.  */
+/* Update the count and release the lock.  */
 static inline void seqlock_write_unlock_impl(QemuSeqLock *sl, QemuLockable 
*lock)
 {
+seqlock_write_end(sl);
 qemu_lockable_unlock(lock);
-seqlock_write_begin(sl);
 }
 #define seqlock_write_unlock(sl, lock) \
 seqlock_write_unlock_impl(sl, QEMU_MAKE_LOCKABLE(lock))
-- 
2.21.0

[Bug 1862979] [NEW] Cannot Create Socket Networking in Windows Host using Multicast

[Faisal Al-Humaimidi]

Public bug reported:

Hello QEMU devs,

I am trying to create a simulated VLAN using socket networking, and the
only way to connect multiple networks in QEMU using socket networking is
by using the multicast `mcast` option of the `socket` network backend.

However, when I try use the following arguments in QEMU to create a
multicast socket network:

`-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234`

it fails with:

`can't bind ip address=230.0.0.1: unknown error` in my Windows host.

I would like to know if this is a bug, or if I am missing a prerequisite
before running the QEMU command.

By the way, I am using Windows 10, and running a cross-compiled QEMU
4.2.0.

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

  Hello QEMU devs,
  
  I am trying to create a simulated VLAN using socket networking, and the
  only way to connect multiple networks in QEMU using socket networking is
  by using the multicast `mcast` option of the `socket` network backend.
  
  However, when I try use the following arguments in QEMU to create a
  multicast socket network:
  
  `-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234`
  
  it fails with:
  
  `can't bind ip address=230.0.0.1: unknown error` in my Windows host.
  
  I would like to know if this is a bug, or if I am missing a prerequisite
  before running the QEMU command.
+ 
+ By the way, I am using Windows 10.

** Description changed:

  Hello QEMU devs,
  
  I am trying to create a simulated VLAN using socket networking, and the
  only way to connect multiple networks in QEMU using socket networking is
  by using the multicast `mcast` option of the `socket` network backend.
  
  However, when I try use the following arguments in QEMU to create a
  multicast socket network:
  
  `-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234`
  
  it fails with:
  
  `can't bind ip address=230.0.0.1: unknown error` in my Windows host.
  
  I would like to know if this is a bug, or if I am missing a prerequisite
  before running the QEMU command.
  
- By the way, I am using Windows 10.
+ By the way, I am using Windows 10, and running a cross-compiled QEMU
+ 4.2.0.

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

Title:
  Cannot Create Socket Networking in Windows Host using Multicast

Status in QEMU:
  New

Bug description:
  Hello QEMU devs,

  I am trying to create a simulated VLAN using socket networking, and
  the only way to connect multiple networks in QEMU using socket
  networking is by using the multicast `mcast` option of the `socket`
  network backend.

  However, when I try use the following arguments in QEMU to create a
  multicast socket network:

  `-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234`

  it fails with:

  `can't bind ip address=230.0.0.1: unknown error` in my Windows host.

  I would like to know if this is a bug, or if I am missing a
  prerequisite before running the QEMU command.

  By the way, I am using Windows 10, and running a cross-compiled QEMU
  4.2.0.

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

RE: [PATCH 1/2] tcg: Add tcg_gen_gvec_5_ptr

[Taylor Simpson]

Reviewed-by: Taylor Simpson 


> -Original Message-
> From: Richard Henderson 
> Sent: Tuesday, February 11, 2020 8:52 PM
> To: qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; alex.ben...@linaro.org; Taylor Simpson
> 
> Subject: [PATCH 1/2] tcg: Add tcg_gen_gvec_5_ptr
>
> Extend the vector generator infrastructure to handle
> 5 vector arguments.
>
> Signed-off-by: Richard Henderson 
> ---
>  include/tcg/tcg-op-gvec.h |  7 +++
>  tcg/tcg-op-gvec.c | 32 
>  2 files changed, 39 insertions(+)
>
> diff --git a/include/tcg/tcg-op-gvec.h b/include/tcg/tcg-op-gvec.h
> index 830d68f697..74534e2480 100644
> --- a/include/tcg/tcg-op-gvec.h
> +++ b/include/tcg/tcg-op-gvec.h
> @@ -83,6 +83,13 @@ void tcg_gen_gvec_4_ptr(uint32_t dofs, uint32_t aofs,
> uint32_t bofs,
>  uint32_t maxsz, int32_t data,
>  gen_helper_gvec_4_ptr *fn);
>
> +typedef void gen_helper_gvec_5_ptr(TCGv_ptr, TCGv_ptr, TCGv_ptr,
> TCGv_ptr,
> +   TCGv_ptr, TCGv_ptr, TCGv_i32);
> +void tcg_gen_gvec_5_ptr(uint32_t dofs, uint32_t aofs, uint32_t bofs,
> +uint32_t cofs, uint32_t eofs, TCGv_ptr ptr,
> +uint32_t oprsz, uint32_t maxsz, int32_t data,
> +gen_helper_gvec_5_ptr *fn);
> +
>  /* Expand a gvec operation.  Either inline or out-of-line depending on
> the actual vector size and the operations supported by the host.  */
>  typedef struct {
> diff --git a/tcg/tcg-op-gvec.c b/tcg/tcg-op-gvec.c
> index 41b4a3c661..327d9588e0 100644
> --- a/tcg/tcg-op-gvec.c
> +++ b/tcg/tcg-op-gvec.c
> @@ -290,6 +290,38 @@ void tcg_gen_gvec_4_ptr(uint32_t dofs, uint32_t
> aofs, uint32_t bofs,
>  tcg_temp_free_i32(desc);
>  }
>
> +/* Generate a call to a gvec-style helper with five vector operands
> +   and an extra pointer operand.  */
> +void tcg_gen_gvec_5_ptr(uint32_t dofs, uint32_t aofs, uint32_t bofs,
> +uint32_t cofs, uint32_t eofs, TCGv_ptr ptr,
> +uint32_t oprsz, uint32_t maxsz, int32_t data,
> +gen_helper_gvec_5_ptr *fn)
> +{
> +TCGv_ptr a0, a1, a2, a3, a4;
> +TCGv_i32 desc = tcg_const_i32(simd_desc(oprsz, maxsz, data));
> +
> +a0 = tcg_temp_new_ptr();
> +a1 = tcg_temp_new_ptr();
> +a2 = tcg_temp_new_ptr();
> +a3 = tcg_temp_new_ptr();
> +a4 = tcg_temp_new_ptr();
> +
> +tcg_gen_addi_ptr(a0, cpu_env, dofs);
> +tcg_gen_addi_ptr(a1, cpu_env, aofs);
> +tcg_gen_addi_ptr(a2, cpu_env, bofs);
> +tcg_gen_addi_ptr(a3, cpu_env, cofs);
> +tcg_gen_addi_ptr(a4, cpu_env, eofs);
> +
> +fn(a0, a1, a2, a3, a4, ptr, desc);
> +
> +tcg_temp_free_ptr(a0);
> +tcg_temp_free_ptr(a1);
> +tcg_temp_free_ptr(a2);
> +tcg_temp_free_ptr(a3);
> +tcg_temp_free_ptr(a4);
> +tcg_temp_free_i32(desc);
> +}
> +
>  /* Return true if we want to implement something of OPRSZ bytes
> in units of LNSZ.  This limits the expansion of inline code.  */
>  static inline bool check_size_impl(uint32_t oprsz, uint32_t lnsz)
> --
> 2.20.1
>

RE: [PATCH 2/2] target/arm: Use tcg_gen_gvec_5_ptr for sve FMLA/FCMLA

[Taylor Simpson]

Reviewed-by: Taylor Simpson 

> -Original Message-
> From: Richard Henderson 
> Sent: Tuesday, February 11, 2020 8:52 PM
> To: qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; alex.ben...@linaro.org; Taylor Simpson
> 
> Subject: [PATCH 2/2] target/arm: Use tcg_gen_gvec_5_ptr for sve
> FMLA/FCMLA
>
> Now that we can pass 7 parameters, do not encode register
> operands within simd_data.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper-sve.h|  45 +++
>  target/arm/sve_helper.c| 157 ++---
>  target/arm/translate-sve.c |  68 ++--
>  3 files changed, 114 insertions(+), 156 deletions(-)
>
> diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
> index 9e79182ab4..bd8b91bdb6 100644
> --- a/target/arm/helper-sve.h
> +++ b/target/arm/helper-sve.h
> @@ -1099,25 +1099,40 @@ DEF_HELPER_FLAGS_6(sve_fcadd_s,
> TCG_CALL_NO_RWG,
>  DEF_HELPER_FLAGS_6(sve_fcadd_d, TCG_CALL_NO_RWG,
> void, ptr, ptr, ptr, ptr, ptr, i32)
>
> -DEF_HELPER_FLAGS_3(sve_fmla_zpzzz_h, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fmla_zpzzz_s, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fmla_zpzzz_d, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fmla_zpzzz_h, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fmla_zpzzz_s, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fmla_zpzzz_d, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
>
> -DEF_HELPER_FLAGS_3(sve_fmls_zpzzz_h, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fmls_zpzzz_s, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fmls_zpzzz_d, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fmls_zpzzz_h, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fmls_zpzzz_s, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fmls_zpzzz_d, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
>
> -DEF_HELPER_FLAGS_3(sve_fnmla_zpzzz_h, TCG_CALL_NO_RWG, void,
> env, ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fnmla_zpzzz_s, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fnmla_zpzzz_d, TCG_CALL_NO_RWG, void,
> env, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fnmla_zpzzz_h, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fnmla_zpzzz_s, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fnmla_zpzzz_d, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
>
> -DEF_HELPER_FLAGS_3(sve_fnmls_zpzzz_h, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fnmls_zpzzz_s, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fnmls_zpzzz_d, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fnmls_zpzzz_h, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fnmls_zpzzz_s, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fnmls_zpzzz_d, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
>
> -DEF_HELPER_FLAGS_3(sve_fcmla_zpzzz_h, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fcmla_zpzzz_s, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> -DEF_HELPER_FLAGS_3(sve_fcmla_zpzzz_d, TCG_CALL_NO_RWG, void, env,
> ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fcmla_zpzzz_h, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fcmla_zpzzz_s, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
> +DEF_HELPER_FLAGS_7(sve_fcmla_zpzzz_d, TCG_CALL_NO_RWG,
> +   void, ptr, ptr, ptr, ptr, ptr, ptr, i32)
>
>  DEF_HELPER_FLAGS_5(sve_ftmad_h, TCG_CALL_NO_RWG, void, ptr, ptr,
> ptr, ptr, i32)
>  DEF_HELPER_FLAGS_5(sve_ftmad_s, TCG_CALL_NO_RWG, void, ptr, ptr,
> ptr, ptr, i32)
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index fdfa652094..33b5a54a47 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -3372,23 +3372,11 @@ DO_ZPZ_FP(sve_ucvt_dd, uint64_t, ,
> uint64_to_float64)
>
>  #undef DO_ZPZ_FP
>
> -/* 4-operand predicated multiply-add.  This requires 7 operands to pass
> - * "properly", so we need to encode some of the registers into DESC.
> - */
> -QEMU_BUILD_BUG_ON(SIMD_DATA_SHIFT + 20 > 32);
> -
> -static void do_fmla_zpzzz_h(CPUARMState *env, void *vg, uint32_t desc,
> +static void do_fmla_zpzzz_h(void *vd, void *vn, void *vm, void *va, void
> *vg,
> +float_status *status, uint32_t desc,
>  uint16_t neg1, uint16_t neg

Re: [PATCH] hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init

[Eduardo Habkost]

On Wed, Feb 12, 2020 at 08:39:55AM +0100, Philippe Mathieu-Daudé wrote:
> Cc'ing Eduardo & Markus.
> 
> On 2/12/20 7:44 AM, Chenqun (kuhn) wrote:
> > > -Original Message-
> > > From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> > > Sent: Wednesday, February 12, 2020 2:16 PM
> > > To: Chenqun (kuhn) ; qemu-
> > > de...@nongnu.org; i.mitsya...@gmail.com; peter.mayd...@linaro.org
> > > Cc: qemu-triv...@nongnu.org; Zhanghailiang
> > > 
> > > Subject: Re: [PATCH] hw/char/exynos4210_uart: Fix memleaks in
> > > exynos4210_uart_init
> > > 
> > > On 2/12/20 4:36 AM, kuhn.chen...@huawei.com wrote:
> > > > From: Chen Qun 
> > > > 
> > > > It's easy to reproduce as follow:
> > > > virsh qemu-monitor-command vm1 --pretty '{"execute":
> > > > "device-list-properties", "arguments":{"typename":"exynos4210.uart"}}'
> > > > 
> > > > ASAN shows memory leak stack:
> > > > #1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
> > > > #2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530
> > > > #3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551
> > > > #4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569
> > > > #5 0xaaad270beee3 in exynos4210_uart_init
> > > /qemu/hw/char/exynos4210_uart.c:677
> > > > #6 0xaaad275c8f4f in object_initialize_with_type 
> > > > /qemu/qom/object.c:516
> > > > #7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684
> > > > #8 0xaaad2755df2f in qmp_device_list_properties
> > > > /qemu/qom/qom-qmp-cmds.c:152
> > > > 
> > > > Reported-by: Euler Robot 
> > > > Signed-off-by: Chen Qun 
> > > > ---
> > > >hw/char/exynos4210_uart.c | 8 
> > > >1 file changed, 4 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/hw/char/exynos4210_uart.c b/hw/char/exynos4210_uart.c
> > > > index 25d6588e41..5048db5410 100644
> > > > --- a/hw/char/exynos4210_uart.c
> > > > +++ b/hw/char/exynos4210_uart.c
> > > > @@ -674,10 +674,6 @@ static void exynos4210_uart_init(Object *obj)
> > > >SysBusDevice *dev = SYS_BUS_DEVICE(obj);
> > > >Exynos4210UartState *s = EXYNOS4210_UART(dev);
> > > > 
> > > > -s->fifo_timeout_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
> > > > - exynos4210_uart_timeout_int, 
> > > > s);
> > > > -s->wordtime = NANOSECONDS_PER_SECOND * 10 / 9600;
> > > 
> > > Why are you moving s->wordtime from init() to realize()?
> > > 
> > Hi  Philippe,  thanks for your reply!
> > 
> > Because I found the variable wordtime is usually used with 
> > fifo_timeout_timer.
> > Eg, they are used together in the exynos4210_uart_rx_timeout_set function.
> > 
> > I didn't find anything wrong with wordtime in the realize().
> > Does it have any other effects?
> 
> IIUC when we use both init() and realize(), realize() should only contains
> on code that consumes the object properties... But maybe the design is not
> clear. Then why not move all the init() code to realize()?

Normally I would recommend the opposite: delay as much as
possible to realize(), to avoid unwanted side effects when (e.g.)
running qom-list-properties.

But as s->wordtime is a simple struct field (that we could even
decide to expose to the outside as a read-only QOM property), it
doesn't really matter.  Personally, I would keep it where it is
just to avoid churn.

-- 
Eduardo

[PULL 09/10] ui: deprecate legacy -show-cursor option

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ján Tomko 
---
 vl.c | 2 ++
 qemu-deprecated.texi | 5 +
 2 files changed, 7 insertions(+)

diff --git a/vl.c b/vl.c
index 62efcd15c0bf..001be469c2e9 100644
--- a/vl.c
+++ b/vl.c
@@ -3562,6 +3562,8 @@ int main(int argc, char **argv, char **envp)
 no_shutdown = 1;
 break;
 case QEMU_OPTION_show_cursor:
+warn_report("The -show-cursor option is deprecated, "
+"use -display {sdl,gtk},show-cursor=on instead");
 dpy.has_show_cursor = true;
 dpy.show_cursor = true;
 break;
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 017b750ca8e2..0671c26c806e 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -148,6 +148,11 @@ QEMU 5.0 introduced an alternative syntax to specify the 
size of the translation
 block cache, @option{-accel tcg,tb-size=}.  The new syntax deprecates the
 previously available @option{-tb-size} option.
 
+@subsection -show-cursor option (since 5.0)
+
+Use @option{-display sdl,show-cursor=on} or
+ @option{-display gtk,show-cursor=on} instead.
+
 @section QEMU Machine Protocol (QMP) commands
 
 @subsection change (since 2.5.0)
-- 
2.18.2

[PULL 10/10] ui/cocoa: Drop workarounds for pre-10.12 OSX

[Gerd Hoffmann]

From: Peter Maydell 

Our official OSX support policy covers the last two released versions.
Currently that is 10.14 and 10.15.  We also may work on older versions, but
don't guarantee it.

In commit 50290c002c045280f8d in mid-2019 we introduced some uses of
CLOCK_MONOTONIC which incidentally broke compilation for pre-10.12 OSX
versions (see LP:1861551). We don't intend to fix that, so we might
as well drop the code in ui/cocoa.m which caters for pre-10.12
versions as well. (For reference, 10.11 fell out of Apple extended
security support in September 2018.)

Signed-off-by: Peter Maydell 
Message-Id: <20200201170534.22123-1-peter.mayd...@linaro.org>
Signed-off-by: Gerd Hoffmann 
---
 ui/cocoa.m | 59 --
 1 file changed, 59 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index f7b323044582..747a70839af8 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -42,60 +42,10 @@
 #include 
 #include "hw/core/cpu.h"
 
-#ifndef MAC_OS_X_VERSION_10_5
-#define MAC_OS_X_VERSION_10_5 1050
-#endif
-#ifndef MAC_OS_X_VERSION_10_6
-#define MAC_OS_X_VERSION_10_6 1060
-#endif
-#ifndef MAC_OS_X_VERSION_10_9
-#define MAC_OS_X_VERSION_10_9 1090
-#endif
-#ifndef MAC_OS_X_VERSION_10_10
-#define MAC_OS_X_VERSION_10_10 101000
-#endif
-#ifndef MAC_OS_X_VERSION_10_12
-#define MAC_OS_X_VERSION_10_12 101200
-#endif
 #ifndef MAC_OS_X_VERSION_10_13
 #define MAC_OS_X_VERSION_10_13 101300
 #endif
 
-/* macOS 10.12 deprecated many constants, #define the new names for older SDKs 
*/
-#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_12
-#define NSEventMaskAny  NSAnyEventMask
-#define NSEventModifierFlagCapsLock NSAlphaShiftKeyMask
-#define NSEventModifierFlagShiftNSShiftKeyMask
-#define NSEventModifierFlagCommand  NSCommandKeyMask
-#define NSEventModifierFlagControl  NSControlKeyMask
-#define NSEventModifierFlagOption   NSAlternateKeyMask
-#define NSEventTypeFlagsChanged NSFlagsChanged
-#define NSEventTypeKeyUpNSKeyUp
-#define NSEventTypeKeyDown  NSKeyDown
-#define NSEventTypeMouseMoved   NSMouseMoved
-#define NSEventTypeLeftMouseDownNSLeftMouseDown
-#define NSEventTypeRightMouseDown   NSRightMouseDown
-#define NSEventTypeOtherMouseDown   NSOtherMouseDown
-#define NSEventTypeLeftMouseDragged NSLeftMouseDragged
-#define NSEventTypeRightMouseDraggedNSRightMouseDragged
-#define NSEventTypeOtherMouseDraggedNSOtherMouseDragged
-#define NSEventTypeLeftMouseUp  NSLeftMouseUp
-#define NSEventTypeRightMouseUp NSRightMouseUp
-#define NSEventTypeOtherMouseUp NSOtherMouseUp
-#define NSEventTypeScrollWheel  NSScrollWheel
-#define NSTextAlignmentCenter   NSCenterTextAlignment
-#define NSWindowStyleMaskBorderless NSBorderlessWindowMask
-#define NSWindowStyleMaskClosable   NSClosableWindowMask
-#define NSWindowStyleMaskMiniaturizable NSMiniaturizableWindowMask
-#define NSWindowStyleMaskTitled NSTitledWindowMask
-#endif
-/* 10.13 deprecates NSFileHandlingPanelOKButton in favour of
- * NSModalResponseOK, which was introduced in 10.9. Define
- * it for older versions.
- */
-#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_9
-#define NSModalResponseOK NSFileHandlingPanelOKButton
-#endif
 /* 10.14 deprecates NSOnState and NSOffState in favor of
  * NSControlStateValueOn/Off, which were introduced in 10.13.
  * Define for older versions
@@ -466,11 +416,7 @@ QemuCocoaView *cocoaView;
 COCOA_DEBUG("QemuCocoaView: drawRect\n");
 
 // get CoreGraphic context
-#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_10
-CGContextRef viewContextRef = [[NSGraphicsContext currentContext] 
graphicsPort];
-#else
 CGContextRef viewContextRef = [[NSGraphicsContext currentContext] 
CGContext];
-#endif
 
 CGContextSetInterpolationQuality (viewContextRef, kCGInterpolationNone);
 CGContextSetShouldAntialias (viewContextRef, NO);
@@ -1076,9 +1022,7 @@ QemuCocoaView *cocoaView;
  --
 */
 @interface QemuCocoaAppController : NSObject
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)

-#endif
 {
 }
 - (void)doToggleFullScreen:(id)sender;
@@ -1127,9 +1071,6 @@ QemuCocoaView *cocoaView;
 [normalWindow setAcceptsMouseMovedEvents:YES];
 [normalWindow setTitle:@"QEMU"];
 [normalWindow setContentView:cocoaView];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_10)
-[normalWindow useOptimizedDrawing:YES];
-#endif
 [normalWindow makeKeyAndOrderFront:self];
 [normalWindow center];
 [normalWindow setDelegate: self];
-- 
2.18.2

[PULL 07/10] ui/gtk: implement show-cursor option

[Gerd Hoffmann]

When specified just set null_cursor to NULL so we get the default
pointer instead of a blank pointer.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ján Tomko 
---
 ui/gtk.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 850c49bee02a..f3f0af8921d9 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2246,8 +2246,12 @@ static void gtk_display_init(DisplayState *ds, 
DisplayOptions *opts)
 textdomain("qemu");
 
 window_display = gtk_widget_get_display(s->window);
-s->null_cursor = gdk_cursor_new_for_display(window_display,
-GDK_BLANK_CURSOR);
+if (s->opts->has_show_cursor && s->opts->show_cursor) {
+s->null_cursor = NULL; /* default pointer */
+} else {
+s->null_cursor = gdk_cursor_new_for_display(window_display,
+GDK_BLANK_CURSOR);
+}
 
 s->mouse_mode_notifier.notify = gd_mouse_mode_change;
 qemu_add_mouse_mode_change_notifier(&s->mouse_mode_notifier);
-- 
2.18.2

[PULL 03/10] ui: add show-cursor option

[Gerd Hoffmann]

When enabled, this forces showing the mouse cursor,
i.e. do not hide the pointer on mouse grabs.
Defaults to off.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Markus Armbruster 
Reviewed-by: Ján Tomko 
---
 qapi/ui.json | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/qapi/ui.json b/qapi/ui.json
index e04525d8b44b..f8c803fe4328 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1144,6 +1144,8 @@
 # @type:  Which DisplayType qemu should use.
 # @full-screen:   Start user interface in fullscreen mode (default: off).
 # @window-close:  Allow to quit qemu with window close button (default: on).
+# @show-cursor:   Force showing the mouse cursor (default: off).
+# (since: 5.0)
 # @gl:Enable OpenGL support (default: off).
 #
 # Since: 2.12
@@ -1153,6 +1155,7 @@
   'base': { 'type'   : 'DisplayType',
 '*full-screen'   : 'bool',
 '*window-close'  : 'bool',
+'*show-cursor'   : 'bool',
 '*gl': 'DisplayGLMode' },
   'discriminator' : 'type',
   'data': { 'gtk': 'DisplayGTK',
-- 
2.18.2

[PULL 06/10] ui/cocoa: switch to new show-cursor option

[Gerd Hoffmann]

Use DisplayOpts settings to set the new file-global cursor_hide
variable, stop using the qemu-global cursor_hide variable.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ján Tomko 
---
 ui/cocoa.m | 4 
 1 file changed, 4 insertions(+)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index fbb5b1b45f81..f7b323044582 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -125,6 +125,7 @@ typedef struct {
 NSWindow *normalWindow, *about_window;
 static DisplayChangeListener *dcl;
 static int last_buttons;
+static int cursor_hide = 1;
 
 int gArgc;
 char **gArgv;
@@ -1918,6 +1919,9 @@ static void cocoa_display_init(DisplayState *ds, 
DisplayOptions *opts)
 [(QemuCocoaAppController *)[[NSApplication sharedApplication] 
delegate] toggleFullScreen: nil];
 });
 }
+if (opts->has_show_cursor && opts->show_cursor) {
+cursor_hide = 0;
+}
 
 dcl = g_malloc0(sizeof(DisplayChangeListener));
 
-- 
2.18.2

[PULL 02/10] ui/gtk: Fix gd_refresh_rate_millihz() when widget window is not realized

[Gerd Hoffmann]

From: Philippe Mathieu-Daudé 

gtk_widget_get_window() returns NULL if the widget's window is not
realized, and QEMU crashes. Example under gtk 3.22.30 (mate 1.20.1):

  qemu-system-x86_64: Gdk: gdk_window_get_origin: assertion 'GDK_IS_WINDOW 
(window)' failed
  (gdb) bt
  #0  0x7496cf70 in gdk_window_get_origin () from 
/usr/lib64/libgdk-3.so.0
  #1  0x749582a0 in gdk_display_get_monitor_at_window () from 
/usr/lib64/libgdk-3.so.0
  #2  0x55bb73e2 in gd_refresh_rate_millihz (window=0x579d6280) at 
ui/gtk.c:1973
  #3  gd_vc_gfx_init (view_menu=0x579f0590, group=0x0, idx=0, 
con=, vc=0x579d4a90, s=0x579d49f0) at ui/gtk.c:2048
  #4  gd_create_menu_view (s=0x579d49f0) at ui/gtk.c:2149
  #5  gd_create_menus (s=0x579d49f0) at ui/gtk.c:2188
  #6  gtk_display_init (ds=, opts=0x5661ed80 ) at 
ui/gtk.c:2256
  #7  0x5583d5a0 in main (argc=, argv=, 
envp=) at vl.c:4358

Fixes: c4c00922cc and 28b58f19d2 (display/gtk: get proper refreshrate)
Reported-by: Jan Kiszka 
Signed-off-by: Philippe Mathieu-Daudé 
Tested-by: Jan Kiszka 
Message-id: 20200208161048.11311-3-f4...@amsat.org
Signed-off-by: Gerd Hoffmann 
---
 ui/gtk.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index c59297ff4d2e..850c49bee02a 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1968,14 +1968,16 @@ static GtkWidget 
*gd_create_menu_machine(GtkDisplayState *s)
 static int gd_refresh_rate_millihz(GtkWidget *window)
 {
 #ifdef GDK_VERSION_3_22
-GdkDisplay *dpy = gtk_widget_get_display(window);
 GdkWindow *win = gtk_widget_get_window(window);
-GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
 
-return gdk_monitor_get_refresh_rate(monitor);
-#else
+if (win) {
+GdkDisplay *dpy = gtk_widget_get_display(window);
+GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
+
+return gdk_monitor_get_refresh_rate(monitor);
+}
+#endif
 return 0;
-#endif
 }
 
 static GSList *gd_vc_gfx_init(GtkDisplayState *s, VirtualConsole *vc,
-- 
2.18.2

[PULL 00/10] Ui 20200212 patches

[Gerd Hoffmann]

The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730:

  Merge remote-tracking branch 
'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging (2020-02-10 
18:09:14 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/ui-20200212-pull-request

for you to fetch changes up to 483644c25b932360018d15818d8bcd8c85ba70b8:

  ui/cocoa: Drop workarounds for pre-10.12 OSX (2020-02-12 13:27:08 +0100)


gtk: refresh rate fix.
cocoa: drop pre-10.12 support.
ui: rework show-cursor option.



Gerd Hoffmann (7):
  ui: add show-cursor option
  ui: wire up legacy -show-cursor option
  ui/sdl: switch to new show-cursor option
  ui/cocoa: switch to new show-cursor option
  ui/gtk: implement show-cursor option
  ui: drop curor_hide global variable.
  ui: deprecate legacy -show-cursor option

Peter Maydell (1):
  ui/cocoa: Drop workarounds for pre-10.12 OSX

Philippe Mathieu-Daudé (2):
  ui/gtk: Update gd_refresh_rate_millihz() to handle VirtualConsole
  ui/gtk: Fix gd_refresh_rate_millihz() when widget window is not
realized

 include/sysemu/sysemu.h |  1 -
 ui/gtk.c| 27 +++---
 ui/sdl2.c   | 16 +--
 vl.c| 16 +--
 qapi/ui.json|  3 ++
 qemu-deprecated.texi|  5 
 ui/cocoa.m  | 63 +++--
 7 files changed, 51 insertions(+), 80 deletions(-)

-- 
2.18.2

[PULL 04/10] ui: wire up legacy -show-cursor option

[Gerd Hoffmann]

Set new show-cursor display option when legacy -show-cursor
is specified on the command line.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ján Tomko 
---
 vl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/vl.c b/vl.c
index 7dcb0879c497..5419b3d68200 100644
--- a/vl.c
+++ b/vl.c
@@ -3554,6 +3554,8 @@ int main(int argc, char **argv, char **envp)
 break;
 case QEMU_OPTION_show_cursor:
 cursor_hide = 0;
+dpy.has_show_cursor = true;
+dpy.show_cursor = true;
 break;
 case QEMU_OPTION_uuid:
 if (qemu_uuid_parse(optarg, &qemu_uuid) < 0) {
-- 
2.18.2

[PULL 05/10] ui/sdl: switch to new show-cursor option

[Gerd Hoffmann]

Use DisplayOpts settings instead of cursor_hide global variable.
Also make "-display sdl,show-cursor=on" work.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ján Tomko 
---
 ui/sdl2.c | 16 
 vl.c  | 10 ++
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/ui/sdl2.c b/ui/sdl2.c
index 9030f1c42efb..3c9424eb42c3 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -161,9 +161,9 @@ static void sdl_update_caption(struct sdl2_console *scon)
 }
 }
 
-static void sdl_hide_cursor(void)
+static void sdl_hide_cursor(struct sdl2_console *scon)
 {
-if (!cursor_hide) {
+if (scon->opts->has_show_cursor && scon->opts->show_cursor) {
 return;
 }
 
@@ -175,9 +175,9 @@ static void sdl_hide_cursor(void)
 }
 }
 
-static void sdl_show_cursor(void)
+static void sdl_show_cursor(struct sdl2_console *scon)
 {
-if (!cursor_hide) {
+if (scon->opts->has_show_cursor && scon->opts->show_cursor) {
 return;
 }
 
@@ -216,7 +216,7 @@ static void sdl_grab_start(struct sdl2_console *scon)
 SDL_WarpMouseInWindow(scon->real_window, guest_x, guest_y);
 }
 } else {
-sdl_hide_cursor();
+sdl_hide_cursor(scon);
 }
 SDL_SetWindowGrab(scon->real_window, SDL_TRUE);
 gui_grab = 1;
@@ -227,7 +227,7 @@ static void sdl_grab_end(struct sdl2_console *scon)
 {
 SDL_SetWindowGrab(scon->real_window, SDL_FALSE);
 gui_grab = 0;
-sdl_show_cursor();
+sdl_show_cursor(scon);
 sdl_update_caption(scon);
 }
 
@@ -658,7 +658,7 @@ static void sdl_mouse_warp(DisplayChangeListener *dcl,
 
 if (on) {
 if (!guest_cursor) {
-sdl_show_cursor();
+sdl_show_cursor(scon);
 }
 if (gui_grab || qemu_input_is_absolute() || absolute_enabled) {
 SDL_SetCursor(guest_sprite);
@@ -667,7 +667,7 @@ static void sdl_mouse_warp(DisplayChangeListener *dcl,
 }
 }
 } else if (gui_grab) {
-sdl_hide_cursor();
+sdl_hide_cursor(scon);
 }
 guest_cursor = on;
 guest_x = x, guest_y = y;
diff --git a/vl.c b/vl.c
index 5419b3d68200..0a13cf2b1724 100644
--- a/vl.c
+++ b/vl.c
@@ -1931,6 +1931,16 @@ static void parse_display(const char *p)
 } else {
 goto invalid_sdl_args;
 }
+} else if (strstart(opts, ",show-cursor=", &nextopt)) {
+opts = nextopt;
+dpy.has_show_cursor = true;
+if (strstart(opts, "on", &nextopt)) {
+dpy.show_cursor = true;
+} else if (strstart(opts, "off", &nextopt)) {
+dpy.show_cursor = false;
+} else {
+goto invalid_sdl_args;
+}
 } else if (strstart(opts, ",gl=", &nextopt)) {
 opts = nextopt;
 dpy.has_gl = true;
-- 
2.18.2

[PULL 08/10] ui: drop curor_hide global variable.

[Gerd Hoffmann]

No users left.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ján Tomko 
---
 include/sysemu/sysemu.h | 1 -
 vl.c| 2 --
 2 files changed, 3 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 6358a324a711..7956e9054ade 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -41,7 +41,6 @@ extern const char *keyboard_layout;
 extern int win2k_install_hack;
 extern int alt_grab;
 extern int ctrl_grab;
-extern int cursor_hide;
 extern int graphic_rotate;
 extern int no_shutdown;
 extern int old_param;
diff --git a/vl.c b/vl.c
index 0a13cf2b1724..62efcd15c0bf 100644
--- a/vl.c
+++ b/vl.c
@@ -168,7 +168,6 @@ int no_hpet = 0;
 int fd_bootchk = 1;
 static int no_reboot;
 int no_shutdown = 0;
-int cursor_hide = 1;
 int graphic_rotate = 0;
 const char *watchdog;
 QEMUOptionRom option_rom[MAX_OPTION_ROMS];
@@ -3563,7 +3562,6 @@ int main(int argc, char **argv, char **envp)
 no_shutdown = 1;
 break;
 case QEMU_OPTION_show_cursor:
-cursor_hide = 0;
 dpy.has_show_cursor = true;
 dpy.show_cursor = true;
 break;
-- 
2.18.2

[PULL 01/10] ui/gtk: Update gd_refresh_rate_millihz() to handle VirtualConsole

[Gerd Hoffmann]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Tested-by: Jan Kiszka 
Message-id: 20200208161048.11311-2-f4...@amsat.org
Signed-off-by: Gerd Hoffmann 
---
 ui/gtk.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index d18892d1de61..c59297ff4d2e 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1965,11 +1965,11 @@ static GtkWidget 
*gd_create_menu_machine(GtkDisplayState *s)
  * If available, return the refresh rate of the display in milli-Hertz,
  * else return 0.
  */
-static int gd_refresh_rate_millihz(GtkDisplayState *s)
+static int gd_refresh_rate_millihz(GtkWidget *window)
 {
 #ifdef GDK_VERSION_3_22
-GdkDisplay *dpy = gtk_widget_get_display(s->window);
-GdkWindow *win = gtk_widget_get_window(s->window);
+GdkDisplay *dpy = gtk_widget_get_display(window);
+GdkWindow *win = gtk_widget_get_window(window);
 GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
 
 return gdk_monitor_get_refresh_rate(monitor);
@@ -2045,7 +2045,8 @@ static GSList *gd_vc_gfx_init(GtkDisplayState *s, 
VirtualConsole *vc,
 vc->gfx.kbd = qkbd_state_init(con);
 vc->gfx.dcl.con = con;
 
-refresh_rate_millihz = gd_refresh_rate_millihz(s);
+refresh_rate_millihz = gd_refresh_rate_millihz(vc->window ?
+   vc->window : s->window);
 if (refresh_rate_millihz) {
 vc->gfx.dcl.update_interval = MILLISEC_PER_SEC / refresh_rate_millihz;
 }
-- 
2.18.2

Re: [PATCH v2] linux-user: implement TARGET_SO_PEERSEC

[Philippe Mathieu-Daudé]

On 2/12/20 5:03 PM, Laurent Vivier wrote:

Le 12/02/2020 à 16:56, Philippe Mathieu-Daudé a écrit :

On 2/4/20 10:19 PM, Laurent Vivier wrote:

"The purpose of this option is to allow an application to obtain the
security credentials of a Unix stream socket peer.  It is analogous to
SO_PEERCRED (which provides authentication using standard Unix
credentials
of pid, uid and gid), and extends this concept to other security
models." -- https://lwn.net/Articles/62370/

Until now it was passed to the kernel with an "int" argument and
fails when it was supported by the host because the parameter is
like a filename: it is always a \0-terminated string with no embedded
\0 characters, but is not guaranteed to be ASCII or UTF-8.

I've tested the option with the following program:

  /*
   * cc -o getpeercon getpeercon.c
   */

  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void)
  {
  int fd;
  struct sockaddr_in server, addr;
  int ret;
  socklen_t len;
  char buf[256];

  fd = socket(PF_INET, SOCK_STREAM, 0);
  if (fd == -1) {
  perror("socket");
  return 1;
  }

  server.sin_family = AF_INET;
  inet_aton("127.0.0.1", &server.sin_addr);
  server.sin_port = htons(40390);

  connect(fd, (struct sockaddr*)&server, sizeof(server));

  len = sizeof(buf);
  ret = getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, &len);
  if (ret == -1) {
  perror("getsockopt");
  return 1;
  }
  printf("%d %s\n", len, buf);
  return 0;
  }

On host:

    $ ./getpeercon
    33 system_u:object_r:unlabeled_t:s0

With qemu-aarch64/bionic without the patch:

    $ ./getpeercon
    getsockopt: Numerical result out of range

With the patch:

    $ ./getpeercon
    33 system_u:object_r:unlabeled_t:s0

Bug: https://bugs.launchpad.net/qemu/+bug/1823790
Reported-by: Matthias Lüscher 
Tested-by: Matthias Lüscher 
Signed-off-by: Laurent Vivier 
---

Notes:
  v2: use correct length in unlock_user()

   linux-user/syscall.c | 22 ++
   1 file changed, 22 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d60142f0691c..c930577686da 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2344,6 +2344,28 @@ static abi_long do_getsockopt(int sockfd, int
level, int optname,
   }
   break;
   }
+    case TARGET_SO_PEERSEC: {
+    char *name;
+
+    if (get_user_u32(len, optlen)) {
+    return -TARGET_EFAULT;
+    }
+    if (len < 0) {
+    return -TARGET_EINVAL;
+    }
+    name = lock_user(VERIFY_WRITE, optval_addr, len, 0);
+    if (!name) {
+    return -TARGET_EFAULT;
+    }
+    lv = len;
+    ret = get_errno(getsockopt(sockfd, level, SO_PEERSEC,
+   name, &lv));


Can we get lv > len?


No:

getsockopt(2)

"For  getsockopt(), optlen is a value-result argument, initially
containing the size of the buffer pointed to by optval, and modified on
return to  indicate the  actual  size  of  the value returned."




+    if (put_user_u32(lv, optlen)) {
+    ret = -TARGET_EFAULT;
+    }
+    unlock_user(name, optval_addr, lv);


Maybe safer to use len instead of lv here?


No:

this is the length of the buffer we must copy back to the user. Kernel
has only modified lv length, not len.


So we can simplify the TARGET_SO_LINGER case then.



linux-user/qemu.h

/* Unlock an area of guest memory.  The first LEN bytes must be
flushed back to guest memory. host_ptr = NULL is explicitly
allowed and does nothing. */
static inline void unlock_user(void *host_ptr, abi_ulong guest_addr,
long len)



Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

Re: [RFC v3 13/25] intel_iommu: modify x-scalable-mode to be string option

[Peter Xu]

On Wed, Feb 12, 2020 at 07:28:24AM +, Liu, Yi L wrote:
> > From: Peter Xu 
> > Sent: Wednesday, February 12, 2020 3:44 AM
> > To: Liu, Yi L 
> > Subject: Re: [RFC v3 13/25] intel_iommu: modify x-scalable-mode to be string
> > option
> > 
> > On Wed, Jan 29, 2020 at 04:16:44AM -0800, Liu, Yi L wrote:
> > > From: Liu Yi L 
> > >
> > > Intel VT-d 3.0 introduces scalable mode, and it has a bunch of
> > > capabilities related to scalable mode translation, thus there are multiple
> > combinations.
> > > While this vIOMMU implementation wants simplify it for user by
> > > providing typical combinations. User could config it by
> > > "x-scalable-mode" option. The usage is as below:
> > >
> > > "-device intel-iommu,x-scalable-mode=["legacy"|"modern"]"
> > 
> > Maybe also "off" when someone wants to explicitly disable it?
> 
> emmm, I  think x-scalable-mode should be disabled by default. It is enabled
> only when "legacy" or "modern" is configured. I'm fine to add "off" as an
> explicit way to turn it off if you think it is necessary. :-)

It's not necessary.  It'll be necessary when we remove "x-" and change
the default value.  However it'll always be good to provide all
options explicitly in the parameter starting from when we design it,
imho.  It's still experimental, so... Your call. :)

-- 
Peter Xu

Re: [PATCH v2] linux-user: implement TARGET_SO_PEERSEC

[Laurent Vivier]

Le 12/02/2020 à 16:56, Philippe Mathieu-Daudé a écrit :
> On 2/4/20 10:19 PM, Laurent Vivier wrote:
>> "The purpose of this option is to allow an application to obtain the
>> security credentials of a Unix stream socket peer.  It is analogous to
>> SO_PEERCRED (which provides authentication using standard Unix
>> credentials
>> of pid, uid and gid), and extends this concept to other security
>> models." -- https://lwn.net/Articles/62370/
>>
>> Until now it was passed to the kernel with an "int" argument and
>> fails when it was supported by the host because the parameter is
>> like a filename: it is always a \0-terminated string with no embedded
>> \0 characters, but is not guaranteed to be ASCII or UTF-8.
>>
>> I've tested the option with the following program:
>>
>>  /*
>>   * cc -o getpeercon getpeercon.c
>>   */
>>
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>
>>  int main(void)
>>  {
>>  int fd;
>>  struct sockaddr_in server, addr;
>>  int ret;
>>  socklen_t len;
>>  char buf[256];
>>
>>  fd = socket(PF_INET, SOCK_STREAM, 0);
>>  if (fd == -1) {
>>  perror("socket");
>>  return 1;
>>  }
>>
>>  server.sin_family = AF_INET;
>>  inet_aton("127.0.0.1", &server.sin_addr);
>>  server.sin_port = htons(40390);
>>
>>  connect(fd, (struct sockaddr*)&server, sizeof(server));
>>
>>  len = sizeof(buf);
>>  ret = getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, &len);
>>  if (ret == -1) {
>>  perror("getsockopt");
>>  return 1;
>>  }
>>  printf("%d %s\n", len, buf);
>>  return 0;
>>  }
>>
>> On host:
>>
>>    $ ./getpeercon
>>    33 system_u:object_r:unlabeled_t:s0
>>
>> With qemu-aarch64/bionic without the patch:
>>
>>    $ ./getpeercon
>>    getsockopt: Numerical result out of range
>>
>> With the patch:
>>
>>    $ ./getpeercon
>>    33 system_u:object_r:unlabeled_t:s0
>>
>> Bug: https://bugs.launchpad.net/qemu/+bug/1823790
>> Reported-by: Matthias Lüscher 
>> Tested-by: Matthias Lüscher 
>> Signed-off-by: Laurent Vivier 
>> ---
>>
>> Notes:
>>  v2: use correct length in unlock_user()
>>
>>   linux-user/syscall.c | 22 ++
>>   1 file changed, 22 insertions(+)
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index d60142f0691c..c930577686da 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -2344,6 +2344,28 @@ static abi_long do_getsockopt(int sockfd, int
>> level, int optname,
>>   }
>>   break;
>>   }
>> +    case TARGET_SO_PEERSEC: {
>> +    char *name;
>> +
>> +    if (get_user_u32(len, optlen)) {
>> +    return -TARGET_EFAULT;
>> +    }
>> +    if (len < 0) {
>> +    return -TARGET_EINVAL;
>> +    }
>> +    name = lock_user(VERIFY_WRITE, optval_addr, len, 0);
>> +    if (!name) {
>> +    return -TARGET_EFAULT;
>> +    }
>> +    lv = len;
>> +    ret = get_errno(getsockopt(sockfd, level, SO_PEERSEC,
>> +   name, &lv));
> 
> Can we get lv > len?

No:

getsockopt(2)

"For  getsockopt(), optlen is a value-result argument, initially
containing the size of the buffer pointed to by optval, and modified on
return to  indicate the  actual  size  of  the value returned."

> 
>> +    if (put_user_u32(lv, optlen)) {
>> +    ret = -TARGET_EFAULT;
>> +    }
>> +    unlock_user(name, optval_addr, lv);
> 
> Maybe safer to use len instead of lv here?

No:

this is the length of the buffer we must copy back to the user. Kernel
has only modified lv length, not len.

linux-user/qemu.h

/* Unlock an area of guest memory.  The first LEN bytes must be
   flushed back to guest memory. host_ptr = NULL is explicitly
   allowed and does nothing. */
static inline void unlock_user(void *host_ptr, abi_ulong guest_addr,
   long len)


Thanks,
Laurent

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200212130311.127515-1-ys...@users.sourceforge.jp 
-> patchew/20200212130311.127515-1-ys...@users.sourceforge.jp
Switched to a new branch 'test'
babc84a qemu-doc.texi: Add RX section.
02671a3 BootLinuxConsoleTest: Test the RX-Virt machine
a7b171f Add rx-softmmu
157d061 hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
6dd9e29 hw/rx: Honor -accel qtest
531f2e7 hw/rx: RX Target hardware definition
2f84384 hw/char: RX62N serial communication interface (SCI)
efb672d hw/timer: RX62N internal timer modules
2ecc8e8 hw/intc: RX62N interrupt controller (ICUa)
c48b1e3 target/rx: Dump bytes for each insn during disassembly
cf6bd23 target/rx: Collect all bytes during disassembly
0630f57 target/rx: Emit all disassembly in one prt()
c68232e target/rx: Use prt_ldmi for XCHG_mr disassembly
0c715cf target/rx: Replace operand with prt_ldmi in disassembler
56823e8 target/rx: Disassemble rx_index_addr into a string
bec88c6 target/rx: RX disassembler
e087756 target/rx: CPU definition
76fbf4b target/rx: TCG helper
077b749 target/rx: TCG translation
077083d hw/registerfields.h: Add 8bit and 16bit register macros
0e0b064 qemu/bitops.h: Add extract8 and extract16
e057d0d MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit e057d0d1eaa7 (MAINTAINERS: Add RX)
2/22 Checking commit 0e0b0640e7e8 (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 077083db9152 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit 077b74916e86 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit 76fbf4b71e73 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit e087756e80bc (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit bec88c65c6d9 (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit 56823e81616e (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit 0c715cfcaf50 (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit c68232e9cbaa (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit 0630f571ce7f (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit cf6bd23f5f99 (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit 

Re: [PATCH] docs: Fix virtiofsd.1 location

[Peter Maydell]

On Wed, 12 Feb 2020 at 14:28, Daniel P. Berrangé  wrote:
>
> On Wed, Feb 12, 2020 at 02:18:19PM +, Peter Maydell wrote:
> > On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:
> > >
> > > Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
> > > page virtiofsd.1. Unfortunately, wrong file location is used as
> > > source for install command. This cause installation of docs fail.
> > >
> > > Fixing wrong location so installation is successful.
> > >
> > > Signed-off-by: Miroslav Rezanina 
> >
> > Reviewed-by: Peter Maydell 
> >
> > I noticed this in review of v1 of the patch
> > https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
> > but missed that it hadn't been fixed in v2/v3.
>
> How come the mistake didn't break any of our CI ?  Looks like it
> should have failed due to non-existing source file

I imagine all our CI setups use separate-build-dir and don't
test 'make install'. This only shows up if you do build-in-source-tree
and then 'make install'. (In a separate-build-dir setup, the
MANUAL_BUILDDIR is the same as the actual build dir,
which is the same as make's current working directory, so
forgetting it in the install rune doesn't matter. In a build from
the source tree, Sphinx requires the output to be to a
different directory than the source, so we have to create
a subdirectory to be the MANUAL_BUILDDIR.)

thanks
-- PMM

Re: [RFC v3 03/25] hw/iommu: introduce IOMMUContext

[Peter Xu]

On Wed, Feb 12, 2020 at 07:15:13AM +, Liu, Yi L wrote:

[...]

> While considering your suggestion on dropping one of the two abstract
> layers. I came up a new proposal as below:
> 
> We may drop the IOMMUContext in this series, and rename DualStageIOMMUObject
> to HostIOMMUContext, which is per-vfio-container. Add an interface in PCI
> layer(e.g. an callback in  PCIDevice) to let vIOMMU get HostIOMMUContext.
> I think this could cover the requirement of providing explicit method for
> vIOMMU to call into VFIO and then program host IOMMU.
> 
> While for the requirement of VFIO to vIOMMU callings (e.g. PRQ), I think it
> could be done via PCI layer by adding an operation in PCIIOMMUOps. Thoughts?

Hmm sounds good. :)

The thing is for the calls to the other direction (e.g. VFIO injecting
faults to vIOMMU), that's neither per-container nor per-device, but
per-vIOMMU.  PCIIOMMUOps suites for that job I'd say, which is per-vIOMMU.

Let's see how it goes.

-- 
Peter Xu

Re: [PATCH v2] linux-user: implement TARGET_SO_PEERSEC

[Philippe Mathieu-Daudé]

On 2/4/20 10:19 PM, Laurent Vivier wrote:

"The purpose of this option is to allow an application to obtain the
security credentials of a Unix stream socket peer.  It is analogous to
SO_PEERCRED (which provides authentication using standard Unix credentials
of pid, uid and gid), and extends this concept to other security
models." -- https://lwn.net/Articles/62370/

Until now it was passed to the kernel with an "int" argument and
fails when it was supported by the host because the parameter is
like a filename: it is always a \0-terminated string with no embedded
\0 characters, but is not guaranteed to be ASCII or UTF-8.

I've tested the option with the following program:

 /*
  * cc -o getpeercon getpeercon.c
  */

 #include 
 #include 
 #include 
 #include 
 #include 

 int main(void)
 {
 int fd;
 struct sockaddr_in server, addr;
 int ret;
 socklen_t len;
 char buf[256];

 fd = socket(PF_INET, SOCK_STREAM, 0);
 if (fd == -1) {
 perror("socket");
 return 1;
 }

 server.sin_family = AF_INET;
 inet_aton("127.0.0.1", &server.sin_addr);
 server.sin_port = htons(40390);

 connect(fd, (struct sockaddr*)&server, sizeof(server));

 len = sizeof(buf);
 ret = getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, &len);
 if (ret == -1) {
 perror("getsockopt");
 return 1;
 }
 printf("%d %s\n", len, buf);
 return 0;
 }

On host:

   $ ./getpeercon
   33 system_u:object_r:unlabeled_t:s0

With qemu-aarch64/bionic without the patch:

   $ ./getpeercon
   getsockopt: Numerical result out of range

With the patch:

   $ ./getpeercon
   33 system_u:object_r:unlabeled_t:s0

Bug: https://bugs.launchpad.net/qemu/+bug/1823790
Reported-by: Matthias Lüscher 
Tested-by: Matthias Lüscher 
Signed-off-by: Laurent Vivier 
---

Notes:
 v2: use correct length in unlock_user()

  linux-user/syscall.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d60142f0691c..c930577686da 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2344,6 +2344,28 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
  }
  break;
  }
+case TARGET_SO_PEERSEC: {
+char *name;
+
+if (get_user_u32(len, optlen)) {
+return -TARGET_EFAULT;
+}
+if (len < 0) {
+return -TARGET_EINVAL;
+}
+name = lock_user(VERIFY_WRITE, optval_addr, len, 0);
+if (!name) {
+return -TARGET_EFAULT;
+}
+lv = len;
+ret = get_errno(getsockopt(sockfd, level, SO_PEERSEC,
+   name, &lv));


Can we get lv > len?


+if (put_user_u32(lv, optlen)) {
+ret = -TARGET_EFAULT;
+}
+unlock_user(name, optval_addr, lv);


Maybe safer to use len instead of lv here?


+break;
+}
  case TARGET_SO_LINGER:
  {
  struct linger lg;

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200211140758.11627-1-dplotni...@virtuozzo.com -> 
patchew/20200211140758.11627-1-dplotni...@virtuozzo.com
Switched to a new branch 'test'
01f0378 qemu-doc.texi: Add RX section.
756b686 BootLinuxConsoleTest: Test the RX-Virt machine
837ab5e Add rx-softmmu
a54c4a7 hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
8f05d87 hw/rx: Honor -accel qtest
17b5d48 hw/rx: RX Target hardware definition
15aaf04 hw/char: RX62N serial communication interface (SCI)
863466a hw/timer: RX62N internal timer modules
8e2ddf8 hw/intc: RX62N interrupt controller (ICUa)
c2b722c target/rx: Dump bytes for each insn during disassembly
abe5c93 target/rx: Collect all bytes during disassembly
2856668 target/rx: Emit all disassembly in one prt()
fbb8022 target/rx: Use prt_ldmi for XCHG_mr disassembly
e02a968 target/rx: Replace operand with prt_ldmi in disassembler
ebe47d5 target/rx: Disassemble rx_index_addr into a string
2123e83 target/rx: RX disassembler
62b81b7 target/rx: CPU definition
d4da3eb target/rx: TCG helper
c6645faa target/rx: TCG translation
97f0ecf hw/registerfields.h: Add 8bit and 16bit register macros
4d682d8 qemu/bitops.h: Add extract8 and extract16
6e4e0c1 MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit 6e4e0c17243b (MAINTAINERS: Add RX)
2/22 Checking commit 4d682d871146 (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 97f0ecffe465 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit c6645faa5ab8 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit d4da3eb54e32 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit 62b81b7701c5 (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit 2123e834292a (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit ebe47d55bde6 (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit e02a9686860e (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit fbb8022a3edc (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit 2856668a7c4a (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit abe5c9380941 (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit c2b72

Re: [PATCH v2] virtio: increase virtuqueue size for virtio-scsi and virtio-blk

[Stefan Hajnoczi]

On Tue, Feb 11, 2020 at 05:14:14PM +0300, Denis Plotnikov wrote:
> The goal is to reduce the amount of requests issued by a guest on
> 1M reads/writes. This rises the performance up to 4% on that kind of
> disk access pattern.
> 
> The maximum chunk size to be used for the guest disk accessing is
> limited with seg_max parameter, which represents the max amount of
> pices in the scatter-geather list in one guest disk request.
> 
> Since seg_max is virqueue_size dependent, increasing the virtqueue
> size increases seg_max, which, in turn, increases the maximum size
> of data to be read/write from a guest disk.
> 
> More details in the original problem statment:
> https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html
> 
> Suggested-by: Denis V. Lunev 
> Signed-off-by: Denis Plotnikov 
> ---
>  hw/block/virtio-blk.c | 4 ++--
>  hw/core/machine.c | 2 ++
>  hw/scsi/virtio-scsi.c | 4 ++--
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 09f46ed85f..6df3a7a6df 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -914,7 +914,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
> uint8_t *config)
>  memset(&blkcfg, 0, sizeof(blkcfg));
>  virtio_stq_p(vdev, &blkcfg.capacity, capacity);
>  virtio_stl_p(vdev, &blkcfg.seg_max,
> - s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 128 - 2);
> + s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 256 - 2);

This value must not change on older machine types.  So does this patch
need to turn seg-max-adjust *on* in hw_compat_4_2 so that old machine
types get 126 instead of 254?

>  virtio_stw_p(vdev, &blkcfg.geometry.cylinders, conf->cyls);
>  virtio_stl_p(vdev, &blkcfg.blk_size, blk_size);
>  virtio_stw_p(vdev, &blkcfg.min_io_size, conf->min_io_size / blk_size);
> @@ -1272,7 +1272,7 @@ static Property virtio_blk_properties[] = {
>  DEFINE_PROP_BIT("request-merging", VirtIOBlock, conf.request_merging, 0,
>  true),
>  DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues, 1),
> -DEFINE_PROP_UINT16("queue-size", VirtIOBlock, conf.queue_size, 128),
> +DEFINE_PROP_UINT16("queue-size", VirtIOBlock, conf.queue_size, 256),
>  DEFINE_PROP_BOOL("seg-max-adjust", VirtIOBlock, conf.seg_max_adjust, 
> true),
>  DEFINE_PROP_LINK("iothread", VirtIOBlock, conf.iothread, TYPE_IOTHREAD,
>   IOThread *),
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 2501b540ec..3427d6cf4c 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -28,6 +28,8 @@
>  #include "hw/mem/nvdimm.h"
>  
>  GlobalProperty hw_compat_4_2[] = {
> +{ "virtio-blk-device", "queue-size", "128"},
> +{ "virtio-scsi-device", "virtqueue_size", "128"},
>  { "virtio-blk-device", "x-enable-wce-if-config-wce", "off" },
>  { "virtio-blk-device", "seg-max-adjust", "off"},
>  { "virtio-scsi-device", "seg_max_adjust", "off"},
> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> index 3b61563609..b38f50a429 100644
> --- a/hw/scsi/virtio-scsi.c
> +++ b/hw/scsi/virtio-scsi.c
> @@ -660,7 +660,7 @@ static void virtio_scsi_get_config(VirtIODevice *vdev,
>  
>  virtio_stl_p(vdev, &scsiconf->num_queues, s->conf.num_queues);
>  virtio_stl_p(vdev, &scsiconf->seg_max,
> - s->conf.seg_max_adjust ? s->conf.virtqueue_size - 2 : 128 - 
> 2);
> + s->conf.seg_max_adjust ? s->conf.virtqueue_size - 2 : 256 - 
> 2);
>  virtio_stl_p(vdev, &scsiconf->max_sectors, s->conf.max_sectors);
>  virtio_stl_p(vdev, &scsiconf->cmd_per_lun, s->conf.cmd_per_lun);
>  virtio_stl_p(vdev, &scsiconf->event_info_size, sizeof(VirtIOSCSIEvent));
> @@ -965,7 +965,7 @@ static void virtio_scsi_device_unrealize(DeviceState 
> *dev, Error **errp)
>  static Property virtio_scsi_properties[] = {
>  DEFINE_PROP_UINT32("num_queues", VirtIOSCSI, parent_obj.conf.num_queues, 
> 1),
>  DEFINE_PROP_UINT32("virtqueue_size", VirtIOSCSI,
> - parent_obj.conf.virtqueue_size, 
> 128),
> + parent_obj.conf.virtqueue_size, 
> 256),
>  DEFINE_PROP_BOOL("seg_max_adjust", VirtIOSCSI,
>parent_obj.conf.seg_max_adjust, true),
>  DEFINE_PROP_UINT32("max_sectors", VirtIOSCSI, 
> parent_obj.conf.max_sectors,
> -- 
> 2.17.0
> 
> 


signature.asc
Description: PGP signature

Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation

[Cornelia Huck]

On Tue, 28 Jan 2020 19:01:42 +0100
Cornelia Huck  wrote:

> Move to system/, as this is mostly about configuring vfio-ap.
> 
> Signed-off-by: Cornelia Huck 
> ---
>  MAINTAINERS  |   2 +-
>  docs/system/index.rst|   1 +
>  docs/{vfio-ap.txt => system/vfio-ap.rst} | 755 ---
>  3 files changed, 387 insertions(+), 371 deletions(-)
>  rename docs/{vfio-ap.txt => system/vfio-ap.rst} (56%)
> 

> -Example: Configure AP Matrixes for Three Linux Guests:
> -=
> +Example: Configure AP Matrices for Three Linux Guests
> +-
>  Let's now provide an example to illustrate how KVM guests may be given
>  access to AP facilities. For this example, we will show how to configure
>  three guests such that executing the lszcrypt command on the guests would
> -look like this:
> -
> -Guest1
> ---
> -CARD.DOMAIN TYPE  MODE
> ---
> -05  CEX5C CCA-Coproc
> -05.0004 CEX5C CCA-Coproc
> -05.00ab CEX5C CCA-Coproc
> -06  CEX5A Accelerator
> -06.0004 CEX5A Accelerator
> -06.00ab CEX5C CCA-Coproc
> -
> -Guest2
> ---
> -CARD.DOMAIN TYPE  MODE
> ---
> -05  CEX5A Accelerator
> -05.0047 CEX5A Accelerator
> -05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),
> -
> -Guest3
> ---
> -CARD.DOMAIN TYPE  MODE
> ---
> -06  CEX5A Accelerator
> -06.0047 CEX5A Accelerator
> -06.00ff CEX5A Accelerator
> +look like this::
> +
> +  Guest1
> +  --
> +  CARD.DOMAIN TYPE  MODE
> +  --
> +  05  CEX5C CCA-Coproc
> +  05.0004 CEX5C CCA-Coproc
> +  05.00ab CEX5C CCA-Coproc
> +  06  CEX5A Accelerator
> +  06.0004 CEX5A Accelerator
> +  06.00ab CEX5C CCA-Coproc
> +
> +  Guest2
> +  --
> +  CARD.DOMAIN TYPE  MODE
> +  --
> +  05  CEX5A Accelerator
> +  05.0047 CEX5A Accelerator
> +  05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),

Just noticed this trailing stuff (had already been in the original
file). Looks like a stray paste, will remove.

> +
> +  Guest3
> +  --
> +  CARD.DOMAIN TYPE  MODE
> +  --
> +  06  CEX5A Accelerator
> +  06.0047 CEX5A Accelerator
> +  06.00ff CEX5A Accelerator

Re: [PATCH] pc: remove erroneous seg_max_adjust setting for vhost-blk-device

[Stefan Hajnoczi]

On Tue, Feb 11, 2020 at 05:07:58PM +0300, Denis Plotnikov wrote:
> vhost-blk-device isn't a part of qemu.git
> 
> Signed-off-by: Denis Plotnikov 
> ---
>  hw/core/machine.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH] tracing: only allow -trace to override -D if set

[Stefan Hajnoczi]

On Tue, Feb 11, 2020 at 11:10:54AM +, Alex Bennée wrote:
> Otherwise any -D settings the user may have made get ignored.
> 
> Signed-off-by: Alex Bennée 
> ---
>  trace/control.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

Thanks, applied to my tracing tree:
https://github.com/stefanha/qemu/commits/tracing

Stefan


signature.asc
Description: PGP signature

Re: [RFC v3 16/25] intel_iommu: add PASID cache management infrastructure

[Peter Xu]

On Wed, Feb 12, 2020 at 08:37:30AM +, Liu, Yi L wrote:
> > From: Peter Xu 
> > Sent: Wednesday, February 12, 2020 7:36 AM
> > To: Liu, Yi L 
> > Subject: Re: [RFC v3 16/25] intel_iommu: add PASID cache management
> > infrastructure
> > 
> > On Wed, Jan 29, 2020 at 04:16:47AM -0800, Liu, Yi L wrote:
> > > From: Liu Yi L 
> > >
> > > This patch adds a PASID cache management infrastructure based on
> > > new added structure VTDPASIDAddressSpace, which is used to track
> > > the PASID usage and future PASID tagged DMA address translation
> > > support in vIOMMU.
> > >
> > > struct VTDPASIDAddressSpace {
> > > VTDBus *vtd_bus;
> > > uint8_t devfn;
> > > AddressSpace as;
> > > uint32_t pasid;
> > > IntelIOMMUState *iommu_state;
> > > VTDContextCacheEntry context_cache_entry;
> > > QLIST_ENTRY(VTDPASIDAddressSpace) next;
> > > VTDPASIDCacheEntry pasid_cache_entry;
> > > };
> > >
> > > Ideally, a VTDPASIDAddressSpace instance is created when a PASID
> > > is bound with a DMA AddressSpace. Intel VT-d spec requires guest
> > > software to issue pasid cache invalidation when bind or unbind a
> > > pasid with an address space under caching-mode. However, as
> > > VTDPASIDAddressSpace instances also act as pasid cache in this
> > > implementation, its creation also happens during vIOMMU PASID
> > > tagged DMA translation. The creation in this path will not be
> > > added in this patch since no PASID-capable emulated devices for
> > > now.
> > >
> > > The implementation in this patch manages VTDPASIDAddressSpace
> > > instances per PASID+BDF (lookup and insert will use PASID and
> > > BDF) since Intel VT-d spec allows per-BDF PASID Table. When a
> > > guest bind a PASID with an AddressSpace, QEMU will capture the
> > > guest pasid selective pasid cache invalidation, and allocate
> > > remove a VTDPASIDAddressSpace instance per the invalidation
> > > reasons:
> > >
> > > *) a present pasid entry moved to non-present
> > > *) a present pasid entry to be a present entry
> > > *) a non-present pasid entry moved to present
> > >
> > > vIOMMU emulator could figure out the reason by fetching latest
> > > guest pasid entry.
> > >
> > > Cc: Kevin Tian 
> > > Cc: Jacob Pan 
> > > Cc: Peter Xu 
> > > Cc: Yi Sun 
> > > Cc: Paolo Bonzini 
> > > Cc: Richard Henderson 
> > > Cc: Eduardo Habkost 
> > > Signed-off-by: Liu Yi L 
> > > ---
> > >  hw/i386/intel_iommu.c  | 367
> > +
> > >  hw/i386/intel_iommu_internal.h |  14 ++
> > >  hw/i386/trace-events   |   1 +
> > >  include/hw/i386/intel_iommu.h  |  36 +++-
> > >  4 files changed, 417 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index 58e7213..c75cb7b 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -40,6 +40,7 @@
> > >  #include "kvm_i386.h"
> > >  #include "migration/vmstate.h"
> > >  #include "trace.h"
> > > +#include "qemu/jhash.h"
> > >
> > >  /* context entry operations */
> > >  #define VTD_CE_GET_RID2PASID(ce) \
> > > @@ -65,6 +66,8 @@
> > >  static void vtd_address_space_refresh_all(IntelIOMMUState *s);
> > >  static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier
> > *n);
> > >
> > > +static void vtd_pasid_cache_reset(IntelIOMMUState *s);
> > > +
> > >  static void vtd_panic_require_caching_mode(void)
> > >  {
> > >  error_report("We need to set caching-mode=on for intel-iommu to 
> > > enable "
> > > @@ -276,6 +279,7 @@ static void vtd_reset_caches(IntelIOMMUState *s)
> > >  vtd_iommu_lock(s);
> > >  vtd_reset_iotlb_locked(s);
> > >  vtd_reset_context_cache_locked(s);
> > > +vtd_pasid_cache_reset(s);
> > >  vtd_iommu_unlock(s);
> > >  }
> > >
> > > @@ -686,6 +690,11 @@ static inline bool vtd_pe_type_check(X86IOMMUState
> > *x86_iommu,
> > >  return true;
> > >  }
> > >
> > > +static inline uint16_t vtd_pe_get_domain_id(VTDPASIDEntry *pe)
> > > +{
> > > +return VTD_SM_PASID_ENTRY_DID((pe)->val[1]);
> > > +}
> > > +
> > >  static inline bool vtd_pdire_present(VTDPASIDDirEntry *pdire)
> > >  {
> > >  return pdire->val & 1;
> > > @@ -2393,19 +2402,370 @@ static bool
> > vtd_process_iotlb_desc(IntelIOMMUState *s, VTDInvDesc *inv_desc)
> > >  return true;
> > >  }
> > >
> > > +static inline void vtd_init_pasid_key(uint32_t pasid,
> > > + uint16_t sid,
> > > + struct pasid_key *key)
> > > +{
> > > +key->pasid = pasid;
> > > +key->sid = sid;
> > > +}
> > > +
> > > +static guint vtd_pasid_as_key_hash(gconstpointer v)
> > > +{
> > > +struct pasid_key *key = (struct pasid_key *)v;
> > > +uint32_t a, b, c;
> > > +
> > > +/* Jenkins hash */
> > > +a = b = c = JHASH_INITVAL + sizeof(*key);
> > > +a += key->sid;
> > > +b += extract32(key->pasid, 0, 16);
> > > +c += extract32(key->pasid, 16, 

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200212130311.127515-1-ys...@users.sourceforge.jp 
-> patchew/20200212130311.127515-1-ys...@users.sourceforge.jp
Switched to a new branch 'test'
96043cc qemu-doc.texi: Add RX section.
b7f311f BootLinuxConsoleTest: Test the RX-Virt machine
d928a96 Add rx-softmmu
46a5463 hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
3602010 hw/rx: Honor -accel qtest
0ab77aa hw/rx: RX Target hardware definition
6d8c7a0 hw/char: RX62N serial communication interface (SCI)
b5b1aca hw/timer: RX62N internal timer modules
ad8af53 hw/intc: RX62N interrupt controller (ICUa)
b32635d target/rx: Dump bytes for each insn during disassembly
4363ee1 target/rx: Collect all bytes during disassembly
410e6f4 target/rx: Emit all disassembly in one prt()
ed23672 target/rx: Use prt_ldmi for XCHG_mr disassembly
5701623 target/rx: Replace operand with prt_ldmi in disassembler
fd886bb target/rx: Disassemble rx_index_addr into a string
1560408 target/rx: RX disassembler
0d304ec target/rx: CPU definition
57ca20a target/rx: TCG helper
003ca8c target/rx: TCG translation
79f2eaa hw/registerfields.h: Add 8bit and 16bit register macros
3148170 qemu/bitops.h: Add extract8 and extract16
79b00a8 MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit 79b00a820d7c (MAINTAINERS: Add RX)
2/22 Checking commit 3148170e9de8 (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 79f2eaaec033 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit 003ca8c0eb26 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit 57ca20a306f9 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit 0d304ec0ddd3 (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit 15604085897f (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit fd886bbd1449 (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit 5701623d0c7b (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit ed236724afd5 (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit 410e6f481e97 (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit 4363ee1bdef4 (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit b32635d70232 (target/rx: Dump bytes for each insn 

[PATCH] target/i386: enable monitor and ucode revision with -cpu max

[Paolo Bonzini]

These two features were incorrectly tied to host_cpuid_required rather than
cpu->max_features.  As a result, -cpu max was not enabling either MONITOR
features or ucode revision.

Signed-off-by: Paolo Bonzini 
---
 target/i386/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 32efa46..92fafa2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6414,7 +6414,9 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 error_setg(&local_err, "CPU model '%s' requires KVM", name);
 goto out;
 }
+}
 
+if (cpu->max_features && accel_uses_host_cpuid()) {
 if (enable_cpu_pm) {
 host_cpuid(5, 0, &cpu->mwait.eax, &cpu->mwait.ebx,
&cpu->mwait.ecx, &cpu->mwait.edx);
-- 
1.8.3.1

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200212130311.127515-1-ys...@users.sourceforge.jp 
-> patchew/20200212130311.127515-1-ys...@users.sourceforge.jp
Switched to a new branch 'test'
c07b5e4 qemu-doc.texi: Add RX section.
d9e3115 BootLinuxConsoleTest: Test the RX-Virt machine
b1722b2 Add rx-softmmu
f88aff7 hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
ce78c96 hw/rx: Honor -accel qtest
8097b53 hw/rx: RX Target hardware definition
dbc2b8b hw/char: RX62N serial communication interface (SCI)
979446e hw/timer: RX62N internal timer modules
5a15247 hw/intc: RX62N interrupt controller (ICUa)
f94a445 target/rx: Dump bytes for each insn during disassembly
ca644b3 target/rx: Collect all bytes during disassembly
9d474c3 target/rx: Emit all disassembly in one prt()
95020f2 target/rx: Use prt_ldmi for XCHG_mr disassembly
5b536a9 target/rx: Replace operand with prt_ldmi in disassembler
7c95e62 target/rx: Disassemble rx_index_addr into a string
196b5bd target/rx: RX disassembler
9312a61 target/rx: CPU definition
4b9939c target/rx: TCG helper
3b8d86a target/rx: TCG translation
84337e2 hw/registerfields.h: Add 8bit and 16bit register macros
203f17b qemu/bitops.h: Add extract8 and extract16
08aca69 MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit 08aca69fecc7 (MAINTAINERS: Add RX)
2/22 Checking commit 203f17b55f7c (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 84337e272083 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit 3b8d86a82898 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit 4b9939cf24c9 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit 9312a613ec1a (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit 196b5bd702fc (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit 7c95e627ab42 (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit 5b536a9efbaa (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit 95020f2f8f2a (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit 9d474c351686 (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit ca644b362f6f (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit 

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200212130311.127515-1-ys...@users.sourceforge.jp 
-> patchew/20200212130311.127515-1-ys...@users.sourceforge.jp
Switched to a new branch 'test'
742aed2 qemu-doc.texi: Add RX section.
f8dc41e BootLinuxConsoleTest: Test the RX-Virt machine
37414e6 Add rx-softmmu
6bad46f hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
b6f9774 hw/rx: Honor -accel qtest
38bc73d hw/rx: RX Target hardware definition
f224df0 hw/char: RX62N serial communication interface (SCI)
ccd39c6 hw/timer: RX62N internal timer modules
3999489 hw/intc: RX62N interrupt controller (ICUa)
aa8d683 target/rx: Dump bytes for each insn during disassembly
8215d23 target/rx: Collect all bytes during disassembly
595382d target/rx: Emit all disassembly in one prt()
c722e15 target/rx: Use prt_ldmi for XCHG_mr disassembly
be31b82 target/rx: Replace operand with prt_ldmi in disassembler
90b054c target/rx: Disassemble rx_index_addr into a string
f2802e4 target/rx: RX disassembler
cb4c947 target/rx: CPU definition
5782455 target/rx: TCG helper
5435b95 target/rx: TCG translation
92c8a93 hw/registerfields.h: Add 8bit and 16bit register macros
ca806d1 qemu/bitops.h: Add extract8 and extract16
5239516 MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit 5239516cc8f1 (MAINTAINERS: Add RX)
2/22 Checking commit ca806d1ba65e (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 92c8a93e24b2 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit 5435b951d5f6 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit 5782455eda42 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit cb4c94748de8 (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit f2802e4c7970 (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit 90b054c90463 (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit be31b8271561 (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit c722e1591484 (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit 595382d7f38d (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit 8215d23159cd (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit 

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200212130311.127515-1-ys...@users.sourceforge.jp 
-> patchew/20200212130311.127515-1-ys...@users.sourceforge.jp
Switched to a new branch 'test'
4470895 qemu-doc.texi: Add RX section.
f0b23ed BootLinuxConsoleTest: Test the RX-Virt machine
92a7207 Add rx-softmmu
e3ec889 hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
b62a7e2 hw/rx: Honor -accel qtest
ecdf913 hw/rx: RX Target hardware definition
a7637c5 hw/char: RX62N serial communication interface (SCI)
3f8b83c hw/timer: RX62N internal timer modules
f2c5f71 hw/intc: RX62N interrupt controller (ICUa)
66902a4 target/rx: Dump bytes for each insn during disassembly
691260f target/rx: Collect all bytes during disassembly
7b77f1a target/rx: Emit all disassembly in one prt()
ced96c7 target/rx: Use prt_ldmi for XCHG_mr disassembly
e24ee8d target/rx: Replace operand with prt_ldmi in disassembler
cc5ad57 target/rx: Disassemble rx_index_addr into a string
db3bdeb target/rx: RX disassembler
b3d7bf4 target/rx: CPU definition
936ddc4 target/rx: TCG helper
2e5e44d target/rx: TCG translation
303744a hw/registerfields.h: Add 8bit and 16bit register macros
767e9e6 qemu/bitops.h: Add extract8 and extract16
c576bd7 MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit c576bd79d68d (MAINTAINERS: Add RX)
2/22 Checking commit 767e9e6adb78 (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 303744a62af8 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit 2e5e44dcfc69 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit 936ddc4f1b14 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit b3d7bf4ef6ae (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit db3bdeb0a4bf (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit cc5ad57c2c56 (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit e24ee8d89615 (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit ced96c73a4f4 (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit 7b77f1ab7077 (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit 691260ffe7fa (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit 66902a40736b (target/rx: Dump bytes for each insn 

Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation

[Cornelia Huck]

On Fri, 7 Feb 2020 16:32:18 +0100
Cornelia Huck  wrote:

> On Fri, 7 Feb 2020 12:43:03 +
> Peter Maydell  wrote:
> 
> > On Tue, 28 Jan 2020 at 19:39, Cornelia Huck  wrote:  
> > >
> > > Move to system/, as this is mostly about configuring vfio-ap.
> > >
> > > Signed-off-by: Cornelia Huck 

> > > -   Example 1: Valid configuration:
> > > -   --
> > > -   Guest1: adapters 1,2  domains 5,6
> > > -   Guest2: adapter  1,2  domain 7
> > > +Example 1: Valid configuration
> > > +~~
> > > +Guest1: adapters 1,2  domains 5,6
> > > +Guest2: adapter  1,2  domain 7
> > 
> > These don't render correctly -- rST thinks the "Example 1..." line
> > is a subsection heading because of the underlining, and then renders
> > the next two lines as runon-text:
> > "Guest1: adapters 1,2 domains 5,6 Guest2: adapter 1,2 domain 7"
> > 
> > Depending on what you want, you could try one of:
> >  * use a literal block (which gets you fixed-width font, preserved
> >whitespace and linebreaks)
> >  * use a bulleted list
> >  * use one of rST's table formats  
> 
> Hm... I think this is supposed to be:
> - header ("Example 1: ...")
> - config
> - explanation why this is a valid config
> 
> Maybe a table? Tony, any preferences?
> 
> > 
> > (is it deliberate that line 1 is "adapters" and line 2 is "adapter" ?)  
> 
> I don't think so.
> 
> >   
> > > -   This is valid because both guests have a unique set of APQNs: Guest1 
> > > has
> > > -   APQNs (1,5), (1,6), (2,5) and (2,6); Guest2 has APQNs (1,7) and (2,7).
> > > +This is valid because both guests have a unique set of APQNs: Guest1 has
> > > +APQNs (1,5), (1,6), (2,5) and (2,6); Guest2 has APQNs (1,7) and (2,7).

This section now looks like this:

Example 1: Valid configuration  
~~  

+--+++  
|  | Guest1 | Guest2 |  
+==+++  
| adapters |  1, 2  |  1, 2  |  
+--+++  
| domains  |  5, 6  |  7 |  
+--+++  

This is valid because both guests have a unique set of APQNs:   

* Guest1 has APQNs (1,5), (1,6), (2,5) and (2,6);   
* Guest2 has APQNs (1,7) and (2,7).

Seems more readable to me, also in the rendered html. (Not sure if
switching rows/columns would be better.)

Re: [PATCH v30 00/22] Add RX archtecture support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200212130311.127515-1-ys...@users.sourceforge.jp/



Hi,

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

Subject: [PATCH v30 00/22] Add RX archtecture support
Message-id: 20200212130311.127515-1-ys...@users.sourceforge.jp
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
fb4922a qemu-doc.texi: Add RX section.
edd4d76 BootLinuxConsoleTest: Test the RX-Virt machine
1f0e65e Add rx-softmmu
edf3f49 hw/rx: Restrict the RX62N microcontroller to the RX62N CPU core
7e8b2d2 hw/rx: Honor -accel qtest
b45a90b hw/rx: RX Target hardware definition
393a9ff hw/char: RX62N serial communication interface (SCI)
fb03e33 hw/timer: RX62N internal timer modules
14af849 hw/intc: RX62N interrupt controller (ICUa)
097db5cd target/rx: Dump bytes for each insn during disassembly
d6b49d1 target/rx: Collect all bytes during disassembly
ee0e458 target/rx: Emit all disassembly in one prt()
c06d978 target/rx: Use prt_ldmi for XCHG_mr disassembly
67ecb36 target/rx: Replace operand with prt_ldmi in disassembler
0be1ef5 target/rx: Disassemble rx_index_addr into a string
ea7685e target/rx: RX disassembler
46e3e2b target/rx: CPU definition
5bc4129 target/rx: TCG helper
c18ded8 target/rx: TCG translation
0356712 hw/registerfields.h: Add 8bit and 16bit register macros
bb1b91d qemu/bitops.h: Add extract8 and extract16
3cbeee6 MAINTAINERS: Add RX

=== OUTPUT BEGIN ===
1/22 Checking commit 3cbeee611724 (MAINTAINERS: Add RX)
2/22 Checking commit bb1b91d61176 (qemu/bitops.h: Add extract8 and extract16)
3/22 Checking commit 0356712846d1 (hw/registerfields.h: Add 8bit and 16bit 
register macros)
Use of uninitialized value in concatenation (.) or string at 
./scripts/checkpatch.pl line 2490.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#27: FILE: include/hw/registerfields.h:25:
+#define REG8(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) };

ERROR: Macros with multiple statements should be enclosed in a do - while loop
#31: FILE: include/hw/registerfields.h:29:
+#define REG16(reg, addr)  \
+enum { A_ ## reg = (addr) };  \
+enum { R_ ## reg = (addr) / 2 };

total: 2 errors, 0 warnings, 56 lines checked

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

4/22 Checking commit c18ded8e7e08 (target/rx: TCG translation)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 3065 lines checked

Patch 4/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/22 Checking commit 5bc412974455 (target/rx: TCG helper)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 650 lines checked

Patch 5/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/22 Checking commit 46e3e2b13e31 (target/rx: CPU definition)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
new file mode 100644

total: 0 errors, 1 warnings, 659 lines checked

Patch 6/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/22 Checking commit ea7685ec72cc (target/rx: RX disassembler)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 1497 lines checked

Patch 7/22 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/22 Checking commit 0be1ef5d641a (target/rx: Disassemble rx_index_addr into a 
string)
9/22 Checking commit 67ecb36d6ff1 (target/rx: Replace operand with prt_ldmi in 
disassembler)
10/22 Checking commit c06d978520ce (target/rx: Use prt_ldmi for XCHG_mr 
disassembly)
11/22 Checking commit ee0e45884b35 (target/rx: Emit all disassembly in one 
prt())
12/22 Checking commit d6b49d1fd490 (target/rx: Collect all bytes during 
disassembly)
13/22 Checking commit 097db5cdc306 (target/rx: Dump bytes for each insn during 
disassembly)
14/22 Checking commit 14af8493f5f8 (hw/intc: RX62N interrupt controller (ICUa))
WARNING: added, moved or deleted fil

Re: [PATCH] docs: Fix virtiofsd.1 location

[Daniel P . Berrangé]

On Wed, Feb 12, 2020 at 02:18:19PM +, Peter Maydell wrote:
> On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:
> >
> > Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
> > page virtiofsd.1. Unfortunately, wrong file location is used as
> > source for install command. This cause installation of docs fail.
> >
> > Fixing wrong location so installation is successful.
> >
> > Signed-off-by: Miroslav Rezanina 
> 
> Reviewed-by: Peter Maydell 
> 
> I noticed this in review of v1 of the patch
> https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
> but missed that it hadn't been fixed in v2/v3.

How come the mistake didn't break any of our CI ?  Looks like it
should have failed due to non-existing source file


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