[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

[Gerd Hoffmann]

any change with the attached patch?

** Patch added: "0001-pulseaudio-process-audio-data-in-smaller-chunks.patch"
   
https://bugs.launchpad.net/qemu/+bug/1795527/+attachment/5210653/+files/0001-pulseaudio-process-audio-data-in-smaller-chunks.patch

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

Title:
  Malformed audio and video output stuttering after upgrade to QEMU 3.0

Status in QEMU:
  New

Bug description:
  My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened
  kernel, running a few KVM guests with varying OSes and configurations
  managed through a Libvirt stack.

  Among these guests I have two Windows 10 VMs with VGA passthrough and
  PulseAudio-backed virtual audio devices.

  After upgrading to QEMU 3.0.0, both of the Win10 guests started
  showing corrupted audio output in the form of unnatural reproduction
  speed and occasional but consistently misplaced audio fragments
  originating from what seems to be a circular buffer wrapping over
  itself (misbehaviour detected by starting some games with known OSTs
  and dialogues: soundtracks sound accelerated and past dialogue lines
  start replaying middle-sentence until the next line starts playing).

  In addition, the video output of the malfunctioning VMs regularly
  stutters roughly twice a second for a fraction of a second (sync'ed
  with the suspected buffer wrapping and especially pronounced during
  not-pre-rendered cutscenes), toghether with mouse freezes that look
  like actual input misses more than simple lack of screen refreshes.

  
  The issue was succesfully reproduced without the managing stack, directly 
with the following command line, on the most capable Windows guest:

   QEMU_AUDIO_DRV=pa
   QEMU_PA_SERVER=127.0.0.1
   /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \
   -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \

   
   -cpu 
host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off
 \  
   -drive 
file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ 
  
   -drive 
file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \
   -m 5120 \
  
   -realtime mlock=off \
   -smp 3,sockets=1,cores=3,threads=1 \
   -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \
   -display none \ 
   -no-user-config \
   -nodefaults \
   -rtc base=localtime,driftfix=slew \  

   
   -global kvm-pit.lost_tick_policy=delay \ 
 
   -no-hpet \  
   -no-shutdown \
   -global PIIX4_PM.disable_s3=1 \
   -global PIIX4_PM.disable_s4=1 \
   -boot strict=on \  
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \  
   
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \
   -device ahci,id=sata0,bus=pci.0,addr=0x9 \ 
   -drive 
file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
 \
   -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
 \
   -drive 
file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \   
 
   -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \  
   
   -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \ 

   
   -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ 

   -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \
   -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \  
   -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \
   -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \   
   -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
   -msg timestamp=on

  
  By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" 
with "pc-i440fx-2.11" (basically reverting the config changes I needed to do in 
order to update the domain definitions), the 

[Qemu-devel] GTK: default display refresh rate at 60Hz

[Chen Zhang via Qemu-devel]

Hi,

It’s observed that GTK display performs poorly compared with native 
environment. The display refresh timer fires at a interval of 
GUI_REFRESH_INTERVAL_DEFAULT milliseconds which is defined as 30 in 
include/ui/console.h. This throttles refresh rate to 33Hz.

Changing its value to 16 (i.e. 60Hz) seems reasonable and may actually improve 
performance.

Best regards 

Re: [Qemu-devel] [PATCH 0/2] target/riscv: Bugfixes found in decodetree conversion

[Richard Henderson]

On 11/8/18 8:12 PM, Palmer Dabbelt wrote:
> * We don't take advantage of the ordering bits on fences, which could allow us
>  to emit less conservative fences.  This would presumably increase  
> performance.

Yes.

> * We treat fences as NOPs under "#ifndef CONFIG_USER_ONLY", which is a bug.

Ah yes, I'd forgotten this one.  This is a bug, in that multi-threaded user
programs do not get the memory ordering that they requested.

Hard to see, obviously, since the emulator has its own memory operations,
barriers, and locks.  But once we have a lot of the hot path of the user
program compiled, there's a lot less of that.


>     case OPC_RISC_FENCE:
> -#ifndef CONFIG_USER_ONLY
>     if (ctx->opcode & 0x1000) {
>     /* FENCE_I is a no-op in QEMU,
>  * however we need to end the translation block */
> @@ -1777,7 +1776,6 @@ static void decode_RV32_64G(CPURISCVState *env,
> DisasContext *ctx)
>     /* FENCE is a full memory barrier. */
>     tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
>     }
> -#endif
>     break;

Yes, this is minimally correct.


r~

Re: [Qemu-devel] [RFC/PoC PATCH 2/3] change size type from int to int64_t on load_image()

[Li Zhijian]

On 11/08/2018 07:04 PM, Peter Maydell wrote:

On 8 November 2018 at 10:59, Li Zhijian  wrote:

allow load_image to load >= 2G file

CC: Philip Li 
Signed-off-by: Li Zhijian 
---
  hw/core/loader.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/core/loader.c b/hw/core/loader.c
index aa0b3fc..8fbc4bd 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -77,7 +77,8 @@ int64_t get_image_size(const char *filename)
  /* deprecated, because caller does not specify buffer size! */
  int load_image(const char *filename, uint8_t *addr)
  {
-int fd, size;
+int fd;
+int64_t size;
  fd = open(filename, O_RDONLY | O_BINARY);
  if (fd < 0)
  return -1;

This function returns "size", so changing the type of "size"
without also changing its return type looks wrong.

load_image_size() uses ssize_t here, which may be what we want.


will change to ssize_t at next version

Thanks
Zhijian



thanks
-- PMM

Re: [Qemu-devel] [RFC 0/2] vhost-vfio: introduce mdev based HW vhost backend

[Jason Wang]

On 2018/11/9 上午12:48, Liang, Cunming wrote:

-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, November 8, 2018 2:16 AM
To: Liang, Cunming; Wang, Xiao W
;m...@redhat.com;alex.william...@redhat.com
Cc:qemu-devel@nongnu.org; Bie, Tiwei; Ye, Xiaolong
; Wang, Zhihong; Daly, Dan

Subject: Re: [RFC 0/2] vhost-vfio: introduce mdev based HW vhost backend


On 2018/11/7 下午11:08, Liang, Cunming wrote:

believe.

[LC] Agreed, so it reuses CMD defined by vhost-kernel ioctl. But
VFIO provides

device specific things (e.g. DMAR, INTR and etc.) which is the extra
APIs being introduced by this transport.


I'm not quite sure I understand here. I think having vhost-kernel
compatible ioctl does not conflict of using VFIO ioctl like DMA or INTR?

Btw, VFIO DMA ioctl is even not a must from my point of view,
vhost-mdev can forward the mem table information to device driver and
let it call DMA API to map/umap pages.

[LC] If not regarding vhost-mdev as a device, then forward mem table won't be a

concern.

If introducing a new mdev bus driver (vhost-mdev) which allows mdev instance to

be a new type of provider for vhost-kernel. It becomes a pretty good 
alternative to
fully leverage vhost-kernel ioctl.

I'm not sure it's the same view as yours when you says reusing vhost-kernel 
ioctl.


Yes it is.

[LC] It sounds a pretty good idea to me. Let us spend some time to figure out 
the next level detail, and sync-up further plan in community call.:)



Cool, thanks.

Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd

[Li Zhijian]

On 11/08/2018 07:06 PM, Peter Maydell wrote:

On 8 November 2018 at 10:59, Li Zhijian  wrote:

x86/x86_64 has alredy supported 4G initrd.

linux/arch/x86/boot/header.S:
  # (Header version 0x0203 or later) the highest safe address for the contents
  # of an initrd. The current kernel allows up to 4 GB, but leave it at 2 GB to
  # avoid possible bootloader bugs.

CC: Philip Li 
Signed-off-by: Li Zhijian 
---
  hw/i386/pc.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index cd5029c..e1b910f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -913,6 +913,12 @@ static void load_linux(PCMachineState *pcms,
  /* highest address for loading the initrd */
  if (protocol >= 0x203) {
  initrd_max = ldl_p(header+0x22c);
+if (initrd_max == 0x7fff) {
+/* for some reasons, initrd_max is hard code with 0x7fff
+ * hard code to 4G - 1 to allow 4G initrd
+ */
+initrd_max = UINT32_MAX - 1;
+}

I don't understand this. If the header of the file we're using
says "this is the maximum", then we should trust the header to
in fact not be lying to us, shouldn't we ?

If the kernel initrd creation process creates an initrd which
is larger than 2GB and also claims that it can't be placed
with any part of it above 2GB, then that sounds like a bug
in the initrd creation process...


Exactly, it's a real problem.

Add x86 maintainers and LKML:

The background is that QEMU want to support up to 4G initrd. but linux header (
initrd_addr_max field) only allow 2G-1.
Is one of the below approaches reasonable:
1) change initrd_addr_max to 4G-1 directly simply(arch/x86/boot/header.S)?
2) lie QEMU bootloader the initrd_addr_max is 4G-1 even though header said 2G-1
3) any else









  } else {
  initrd_max = 0x37ff;
  }

This patch should come last in the series: only after we have fixed all
of QEMU's internal plumbing to handle larger initrd sizes should we
enable it.


Got it.

Thanks
Zhijian



thanks
-- PMM

Re: [Qemu-devel] [PATCH 1/1 V2] Add vhost-pci-blk driver

[Dongli Zhang]

On 11/09/2018 12:47 AM, Michael S. Tsirkin wrote:
> On Thu, Nov 08, 2018 at 10:09:00PM +0800, Dongli Zhang wrote:
>> It looks the kernel space vhost-blk can only process raw image.
>>
>> How about to verify that only raw image is used in the drive command line 
>> when
>> vhost-blk-pci is paired with it?
>>
>> Otherwise, vhost-blk-pci might be working with qcow2 image without any 
>> warning
>> on qemu side.
>>
>> Dongli Zhang
> 
> raw being raw can you really verify that?
> 

I meant to verify the property 'format=' of '-drive', e.g., to check if
BlockBackend->root->bs->drv->format_name is raw?

We allow the user to erroneously give a qcow2 file with 'format=raw'. However,
if 'format=qcow2' is set explicitly, vhots-blk-pci would exit with error as only
raw is supported in kernel space.

Dongli Zhang

Re: [Qemu-devel] [Qemu-block] [PATCH] tests: Fix Python 3 detection on older GNU make versions

[Cleber Rosa]

On 11/8/18 1:26 PM, Eduardo Habkost wrote:
> On Thu, Nov 08, 2018 at 12:36:37PM -0500, Cleber Rosa wrote:
>>
>>
>> On 11/8/18 11:51 AM, Eduardo Habkost wrote:
>>
>>> I'm not sure I agree with the "is an important thing to keep
>>> track of" part.  I don't think we'll have any need to keep track
>>> of the Python version in shell script or makefiles after we start
>>> requiring Python 3.
>>>
>>
>> Well, "Python 3" is not a uniform thing.  There are many changes across
>> the 3.x spectrum that can bite you.  I'm speaking out of the experience
>> with Avocado, that supports Python 3.4, 3.5 and 3.6 (and that reminds me
>> we should add tests for 3.7).
> 
> Do you expect us to need to keep track of the exact Python
> version before running the Python interpreter?  Code written in
> Python doesn't count, because it can simply use sys.version_info.
> 
> 

You're right, Python code can do that.  My proposal is really to
facilitate other parts of the test automation, and as described later,
the debugging on remote systems.

>>
>>> Extra cleanups (like moving version checks to ./configure) are
>>> still welcome, but keep in mind that this will probably be thrown
>>> away once we drop Python 2 support.
>>>
>>
>> I don't think it should.  Let me give the example of a "Python 3.0" job
>> on Travis, related to the following snippet:
>>
>> # Python builds
>> - env: CONFIG="--target-list=x86_64-softmmu"
>>   python:
>> - "3.0"
>>
>> If you look at https://travis-ci.org/clebergnu/qemu/jobs/452033247#L983
>> you'll see that the intended goal was missed.  That has to do with how
>> Travis makes the requested Python version available, and it was only
>> obvious because this branch prints the Python version used.
>>
>> Developers writing Python code, for instance tests, may assume a given
>> API that doesn't exist or behave like they expect, and not knowing the
>> Python version used on a remote environment makes debugging extra hard.
> 
> I'm not sure I get your point.  We can surely add diagnostic
> messages to show the Python version, and we can make ./configure
> fail if Python 3 is unavailable.  I'm talking about adding code
> to ./configure to save Python version info for makefile rules and
> shell scripts.  I expect the extra code to be unnecessary in the
> future.
> 

I'm definitely happy if you agree with printing the Python version,
that's where most of the value is indeed.  Then, if we need to keep the
version in the generate Makefile is something to be seen.

- Cleber.

Re: [Qemu-devel] [PATCH v4 00/13] arm: nRF51 Devices and Microbit Support

[no-reply]

Hi,

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

Type: series
Message-id: 20181102170730.12432-1-cont...@steffen-goertz.de
Subject: [Qemu-devel] [PATCH v4 00/13] arm: nRF51 Devices and Microbit Support

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
fd66eaffcd arm: Add Clock peripheral stub to NRF51 SOC
8866216fc9 arm: Instantiate NRF51 Timers
65924d9977 hw/timer/nrf51_timer: Add nRF51 Timer peripheral
563bb0b5f6 tests/microbit-test: Add Tests for nRF51 GPIO
ee4d8fbeca arm: Instantiate NRF51 general purpose I/O
112ccf165c hw/gpio/nrf51_gpio: Add nRF51 GPIO peripheral
7518a546be tests: Add bbc:microbit / nRF51 test suite
6fbf570315 arm: Instantiate NRF51 special NVM's and NVMC
ddcf5df56c hw/nvram/nrf51_nvm: Add nRF51 non-volatile memories
a81717e841 arm: Instantiate NRF51 random number generator
38ba17f090 hw/misc/nrf51_rng: Add NRF51 random number generator peripheral
d75e17f351 arm: Add header to host common definition for nRF51 SOC peripherals
efafdca695 qtest: Add set_irq_in command to set IRQ/GPIO level

=== OUTPUT BEGIN ===
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-u7f_igdd/src'
  GEN 
/var/tmp/patchew-tester-tmp-u7f_igdd/src/docker-src.2018-11-08-17.17.28.4457/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-u7f_igdd/src/docker-src.2018-11-08-17.17.28.4457/qemu.tar.vroot'...
done.
Checking out files:  45% (2935/6455)   
Checking out files:  46% (2970/6455)   
Checking out files:  47% (3034/6455)   
Checking out files:  48% (3099/6455)   
Checking out files:  49% (3163/6455)   
Checking out files:  50% (3228/6455)   
Checking out files:  51% (3293/6455)   
Checking out files:  52% (3357/6455)   
Checking out files:  53% (3422/6455)   
Checking out files:  54% (3486/6455)   
Checking out files:  55% (3551/6455)   
Checking out files:  56% (3615/6455)   
Checking out files:  57% (3680/6455)   
Checking out files:  58% (3744/6455)   
Checking out files:  59% (3809/6455)   
Checking out files:  60% (3873/6455)   
Checking out files:  61% (3938/6455)   
Checking out files:  62% (4003/6455)   
Checking out files:  63% (4067/6455)   
Checking out files:  64% (4132/6455)   
Checking out files:  65% (4196/6455)   
Checking out files:  66% (4261/6455)   
Checking out files:  67% (4325/6455)   
Checking out files:  68% (4390/6455)   
Checking out files:  69% (4454/6455)   
Checking out files:  70% (4519/6455)   
Checking out files:  71% (4584/6455)   
Checking out files:  72% (4648/6455)   
Checking out files:  73% (4713/6455)   
Checking out files:  74% (4777/6455)   
Checking out files:  75% (4842/6455)   
Checking out files:  76% (4906/6455)   
Checking out files:  77% (4971/6455)   
Checking out files:  78% (5035/6455)   
Checking out files:  79% (5100/6455)   
Checking out files:  80% (5164/6455)   
Checking out files:  81% (5229/6455)   
Checking out files:  82% (5294/6455)   
Checking out files:  82% (5339/6455)   
Checking out files:  83% (5358/6455)   
Checking out files:  84% (5423/6455)   
Checking out files:  85% (5487/6455)   
Checking out files:  86% (5552/6455)   
Checking out files:  87% (5616/6455)   
Checking out files:  88% (5681/6455)   
Checking out files:  89% (5745/6455)   
Checking out files:  90% (5810/6455)   
Checking out files:  91% (5875/6455)   
Checking out files:  92% (5939/6455)   
Checking out files:  93% (6004/6455)   
Checking out files:  94% (6068/6455)   
Checking out files:  95% (6133/6455)   
Checking out files:  96% (6197/6455)   
Checking out files:  97% (6262/6455)   
Checking out files:  98% (6326/6455)   
Checking out files:  99% (6391/6455)   
Checking out files: 100% (6455/6455)   
Checking out files: 100% (6455/6455), done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-u7f_igdd/src/docker-src.2018-11-08-17.17.28.4457/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-u7f_igdd/src/docker-src.2018-11-08-17.17.28.4457/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-mingw in qemu:fedora 
Packages installed:
SDL2-devel-2.0.8-5.fc28.x86_64
bc-1.07.1-5.fc28.x86_64
bison-3.0.4-9.fc28.x86_64
bluez-libs-devel-5.50-1.fc28.x86_64
brlapi-devel-0.6.7-19.fc28.x86_64
bzip2-1.0.6-26.fc28.x86_64
bzip2-devel-1.0.6-26.fc28.x86_64
ccache-3.4.2-2.fc28.x86_64
clang-6.0.1-1.fc28.x86_64
device-mapper-multipath-devel-0.7.4-3.git07e7bd5.fc28.x86_64

Re: [Qemu-devel] [PATCH 0/2] ipmi: Allow UUID to be set for a BMC

[David Gibson]

On Thu, Nov 08, 2018 at 08:19:42AM -0600, miny...@acm.org wrote:
> The code was using the qemu UUID for the BMC.  But that's really
> not a good method.  In general, you don't want the GUID to change
> when you migrate, and you want the GUID to be the same between
> invocations of qemu (if you have a GUID).

Hrm.  Generally the qemu UUID should remain the same across a
migration too, and I think that will be the case if using libvirt.
Maybe not if running qemu by hand and not specifying the uuid on the
command line.

I don't really have an objection to allowing the BMC's id to be
explicitly controlled, but the rationale above seems a bit
disingenuous.

> Plus, if you have multiple BMCs, they need to have different
> GUIDs or the host code cannot tell them apart.  I'm not sure
> anyone really uses multiple BMCs, but I do a lot of testing
> with that scenario.
> 
> This change lets the user set the GUID on the command line, and
> if the GUID is not set return an error for the GUID fetch command.
> This maps better to how IPMI should work.
> 
> This change relies on the UUID being set to all zeros to know that
> it is not set.  This is not optimal, perhaps, but an all zero
> UUID isn't valid (it's the Nil UUID), so it should be ok.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v15 00/10] Add ARMv8 RAS virtualization support in QEMU

[no-reply]

Hi,

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

Type: series
Message-id: 1541672153-15529-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH v15 00/10] Add ARMv8 RAS virtualization support in 
QEMU

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
ea6f559ebb target-arm: kvm64: handle SIGBUS signal from kernel or KVM
f7559fdd5e hw/arm/virt: Add RAS platform version for migration
5d5ce7694f target-arm: kvm64: inject synchronous External Abort
5d4a5f1e8e KVM: Move related hwpoison page functions to accel/kvm/ folder
cfe8041c05 docs: APEI GHES generation and CPER record description
9cbe3a1625 ACPI: Add APEI GHES table generation and CPER record support
f50bae0c92 acpi: add build_append_ghes_generic_status() helper for Generic 
Error Status Block
5202c7810c acpi: add build_append_ghes_generic_data() helper for Generic Error 
Data Entry
d56660774b acpi: add build_append_ghes_notify() helper for Hardware Error 
Notification
f62584522a ACPI: add some GHES structures and macros definition

=== OUTPUT BEGIN ===
  BUILD   centos7
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-o0v_u04j/src'
  GEN 
/var/tmp/patchew-tester-tmp-o0v_u04j/src/docker-src.2018-11-08-17.37.09.13041/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-o0v_u04j/src/docker-src.2018-11-08-17.37.09.13041/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-o0v_u04j/src/docker-src.2018-11-08-17.37.09.13041/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-o0v_u04j/src/docker-src.2018-11-08-17.37.09.13041/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-quick in qemu:centos7 
Packages installed:
SDL-devel-1.2.15-14.el7.x86_64
bison-3.0.4-1.el7.x86_64
bzip2-1.0.6-13.el7.x86_64
bzip2-devel-1.0.6-13.el7.x86_64
ccache-3.3.4-1.el7.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el7.x86_64
flex-2.5.37-3.el7.x86_64
gcc-4.8.5-28.el7_5.1.x86_64
gettext-0.19.8.1-2.el7.x86_64
git-1.8.3.1-14.el7_5.x86_64
glib2-devel-2.54.2-2.el7.x86_64
libaio-devel-0.3.109-13.el7.x86_64
libepoxy-devel-1.3.1-2.el7_5.x86_64
libfdt-devel-1.4.6-1.el7.x86_64
lzo-devel-2.06-8.el7.x86_64
make-3.82-23.el7.x86_64
mesa-libEGL-devel-17.2.3-8.20171019.el7.x86_64
mesa-libgbm-devel-17.2.3-8.20171019.el7.x86_64
nettle-devel-2.7.1-8.el7.x86_64
package g++ is not installed
package librdmacm-devel is not installed
pixman-devel-0.34.0-1.el7.x86_64
spice-glib-devel-0.34-3.el7_5.1.x86_64
spice-server-devel-0.14.0-2.el7_5.4.x86_64
tar-1.26-34.el7.x86_64
vte-devel-0.28.2-10.el7.x86_64
xen-devel-4.6.6-12.el7.x86_64
zlib-devel-1.2.7-17.el7.x86_64

Environment variables:
PACKAGES=bison bzip2 bzip2-devel ccache csnappy-devel flex  
   g++ gcc gettext git glib2-devel libaio-devel 
libepoxy-devel libfdt-devel librdmacm-devel lzo-devel make 
mesa-libEGL-devel mesa-libgbm-devel nettle-devel pixman-devel 
SDL-devel spice-glib-devel spice-server-devel tar vte-devel 
xen-devel zlib-devel
HOSTNAME=f4d1f67e0bad
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
SHLVL=1
HOME=/home/patchew
TEST_DIR=/tmp/qemu-test
FEATURES= dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/install
BIOS directory/tmp/qemu-test/install/share/qemu
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory  /tmp/qemu-test/install/bin
library directory /tmp/qemu-test/install/lib
module directory  /tmp/qemu-test/install/lib/qemu
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory  /tmp/qemu-test/install/etc
local state directory   /tmp/qemu-test/install/var
Manual directory  /tmp/qemu-test/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
GIT binarygit
GIT submodules
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE 

Re: [Qemu-devel] [PATCH RESEND v15 00/10] Add ARMv8 RAS virtualization support in QEMU

[no-reply]

Hi,

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

Type: series
Message-id: 1541672989-15967-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH RESEND v15 00/10] Add ARMv8 RAS virtualization 
support in QEMU

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
a8cb7527de target-arm: kvm64: handle SIGBUS signal from kernel or KVM
a09df9f86c hw/arm/virt: Add RAS platform version for migration
a7b73559b9 target-arm: kvm64: inject synchronous External Abort
7384b8 KVM: Move related hwpoison page functions to accel/kvm/ folder
bf8853a0aa docs: APEI GHES generation and CPER record description
d0d850cc13 ACPI: Add APEI GHES table generation and CPER record support
4dc5021697 acpi: add build_append_ghes_generic_status() helper for Generic 
Error Status Block
2be8ee4f11 acpi: add build_append_ghes_generic_data() helper for Generic Error 
Data Entry
5509af96ba acpi: add build_append_ghes_notify() helper for Hardware Error 
Notification
ac64a81aed ACPI: add some GHES structures and macros definition

=== OUTPUT BEGIN ===
  BUILD   centos7
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-bt40wlf7/src'
  GEN 
/var/tmp/patchew-tester-tmp-bt40wlf7/src/docker-src.2018-11-08-17.50.11.11855/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-bt40wlf7/src/docker-src.2018-11-08-17.50.11.11855/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-bt40wlf7/src/docker-src.2018-11-08-17.50.11.11855/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-bt40wlf7/src/docker-src.2018-11-08-17.50.11.11855/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-quick in qemu:centos7 
Packages installed:
SDL-devel-1.2.15-14.el7.x86_64
bison-3.0.4-1.el7.x86_64
bzip2-1.0.6-13.el7.x86_64
bzip2-devel-1.0.6-13.el7.x86_64
ccache-3.3.4-1.el7.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el7.x86_64
flex-2.5.37-3.el7.x86_64
gcc-4.8.5-28.el7_5.1.x86_64
gettext-0.19.8.1-2.el7.x86_64
git-1.8.3.1-14.el7_5.x86_64
glib2-devel-2.54.2-2.el7.x86_64
libaio-devel-0.3.109-13.el7.x86_64
libepoxy-devel-1.3.1-2.el7_5.x86_64
libfdt-devel-1.4.6-1.el7.x86_64
lzo-devel-2.06-8.el7.x86_64
make-3.82-23.el7.x86_64
mesa-libEGL-devel-17.2.3-8.20171019.el7.x86_64
mesa-libgbm-devel-17.2.3-8.20171019.el7.x86_64
nettle-devel-2.7.1-8.el7.x86_64
package g++ is not installed
package librdmacm-devel is not installed
pixman-devel-0.34.0-1.el7.x86_64
spice-glib-devel-0.34-3.el7_5.1.x86_64
spice-server-devel-0.14.0-2.el7_5.4.x86_64
tar-1.26-34.el7.x86_64
vte-devel-0.28.2-10.el7.x86_64
xen-devel-4.6.6-12.el7.x86_64
zlib-devel-1.2.7-17.el7.x86_64

Environment variables:
PACKAGES=bison bzip2 bzip2-devel ccache csnappy-devel flex  
   g++ gcc gettext git glib2-devel libaio-devel 
libepoxy-devel libfdt-devel librdmacm-devel lzo-devel make 
mesa-libEGL-devel mesa-libgbm-devel nettle-devel pixman-devel 
SDL-devel spice-glib-devel spice-server-devel tar vte-devel 
xen-devel zlib-devel
HOSTNAME=89ecf82ccf75
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
SHLVL=1
HOME=/home/patchew
TEST_DIR=/tmp/qemu-test
FEATURES= dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/install
BIOS directory/tmp/qemu-test/install/share/qemu
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory  /tmp/qemu-test/install/bin
library directory /tmp/qemu-test/install/lib
module directory  /tmp/qemu-test/install/lib/qemu
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory  /tmp/qemu-test/install/etc
local state directory   /tmp/qemu-test/install/var
Manual directory  /tmp/qemu-test/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
GIT binarygit
GIT submodules
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE 

Re: [Qemu-devel] [PATCH RESEND v15 00/10] Add ARMv8 RAS virtualization support in QEMU

[no-reply]

Hi,

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

Type: series
Message-id: 1541672989-15967-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH RESEND v15 00/10] Add ARMv8 RAS virtualization 
support in QEMU

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

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

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

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
a8cb7527de target-arm: kvm64: handle SIGBUS signal from kernel or KVM
a09df9f86c hw/arm/virt: Add RAS platform version for migration
a7b73559b9 target-arm: kvm64: inject synchronous External Abort
7384b8 KVM: Move related hwpoison page functions to accel/kvm/ folder
bf8853a0aa docs: APEI GHES generation and CPER record description
d0d850cc13 ACPI: Add APEI GHES table generation and CPER record support
4dc5021697 acpi: add build_append_ghes_generic_status() helper for Generic 
Error Status Block
2be8ee4f11 acpi: add build_append_ghes_generic_data() helper for Generic Error 
Data Entry
5509af96ba acpi: add build_append_ghes_notify() helper for Hardware Error 
Notification
ac64a81aed ACPI: add some GHES structures and macros definition

=== OUTPUT BEGIN ===
Checking PATCH 1/10: ACPI: add some GHES structures and macros definition...
Checking PATCH 2/10: acpi: add build_append_ghes_notify() helper for Hardware 
Error Notification...
Checking PATCH 3/10: acpi: add build_append_ghes_generic_data() helper for 
Generic Error Data Entry...
Checking PATCH 4/10: acpi: add build_append_ghes_generic_status() helper for 
Generic Error Status Block...
Checking PATCH 5/10: ACPI: Add APEI GHES table generation and CPER record 
support...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#43: 
new file mode 100644

WARNING: line over 80 characters
#103: FILE: hw/acpi/acpi_ghes.c:56:
+build_append_int_noprefix((void *)hardware_errors, 1, 
GHES_ADDRESS_SIZE);

WARNING: line over 80 characters
#131: FILE: hw/acpi/acpi_ghes.c:84:
+build_append_int_noprefix(table_data, cpu_to_le16(i), 2); /* source id 
*/

WARNING: line over 80 characters
#132: FILE: hw/acpi/acpi_ghes.c:85:
+build_append_int_noprefix(table_data, 0x, 2); /* related source id 
*/

WARNING: line over 80 characters
#145: FILE: hw/acpi/acpi_ghes.c:98:
+build_append_gas(table_data, AML_SYSTEM_MEMORY, 0x40, 0, 4 /* QWord 
access */, 0);

WARNING: line over 80 characters
#169: FILE: hw/acpi/acpi_ghes.c:122:
+build_append_gas(table_data, AML_SYSTEM_MEMORY, 0x40, 0, 4 /* QWord 
access */, 0);

ERROR: line over 90 characters
#306: FILE: include/hw/acpi/acpi_ghes.h:29:
+/* The size of Address field in Generic Address Structure, ACPI 2.0/3.0: 
5.2.3.1 Generic Address

total: 1 errors, 6 warnings, 311 lines checked

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

Checking PATCH 6/10: docs: APEI GHES generation and CPER record description...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#12: 
new file mode 100644

total: 0 errors, 1 warnings, 97 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 7/10: KVM: Move related hwpoison page functions to accel/kvm/ 
folder...
Checking PATCH 8/10: target-arm: kvm64: inject synchronous External Abort...
Checking PATCH 9/10: hw/arm/virt: Add RAS platform version for migration...
Checking PATCH 10/10: target-arm: kvm64: handle SIGBUS signal from kernel or 
KVM...
WARNING: line over 80 characters
#72: FILE: hw/acpi/acpi_ghes.c:68:
+current_block_length = sizeof(AcpiGenericErrorStatus) + 
le32_to_cpu(data_length);

WARNING: line over 80 characters
#81: FILE: hw/acpi/acpi_ghes.c:77:
+if ((data_length + sizeof(AcpiGenericErrorStatus)) > 
GHES_MAX_RAW_DATA_LENGTH) {

WARNING: line over 80 characters
#86: FILE: hw/acpi/acpi_ghes.c:82:
+build_append_ghes_generic_status(block, 
cpu_to_le32(ACPI_GEBS_UNCORRECTABLE), 0, 0,

WARNING: line over 80 characters
#98: FILE: hw/acpi/acpi_ghes.c:94:
+cpu_to_le32(ACPI_CPER_SEV_RECOVERABLE), 
cpu_to_le32(0x300), 0, 0,

WARNING: line over 80 characters
#99: FILE: hw/acpi/acpi_ghes.c:95:
+cpu_to_le32(80)/* the total size of Memory Error Record 
*/, fru_id,

total: 0 errors, 5 warnings, 256 lines checked

Your patch has style problems, please 

Re: [Qemu-devel] [PATCH v4 00/13] arm: nRF51 Devices and Microbit Support

[no-reply]

Hi,

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

Type: series
Message-id: 20181102170730.12432-1-cont...@steffen-goertz.de
Subject: [Qemu-devel] [PATCH v4 00/13] arm: nRF51 Devices and Microbit Support

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
fd66eaffcd arm: Add Clock peripheral stub to NRF51 SOC
8866216fc9 arm: Instantiate NRF51 Timers
65924d9977 hw/timer/nrf51_timer: Add nRF51 Timer peripheral
563bb0b5f6 tests/microbit-test: Add Tests for nRF51 GPIO
ee4d8fbeca arm: Instantiate NRF51 general purpose I/O
112ccf165c hw/gpio/nrf51_gpio: Add nRF51 GPIO peripheral
7518a546be tests: Add bbc:microbit / nRF51 test suite
6fbf570315 arm: Instantiate NRF51 special NVM's and NVMC
ddcf5df56c hw/nvram/nrf51_nvm: Add nRF51 non-volatile memories
a81717e841 arm: Instantiate NRF51 random number generator
38ba17f090 hw/misc/nrf51_rng: Add NRF51 random number generator peripheral
d75e17f351 arm: Add header to host common definition for nRF51 SOC peripherals
efafdca695 qtest: Add set_irq_in command to set IRQ/GPIO level

=== OUTPUT BEGIN ===
  BUILD   centos7
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-war7yhb3/src'
  GEN 
/var/tmp/patchew-tester-tmp-war7yhb3/src/docker-src.2018-11-08-17.18.34.5123/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-war7yhb3/src/docker-src.2018-11-08-17.18.34.5123/qemu.tar.vroot'...
done.
Checking out files:  50% (3255/6455)   
Checking out files:  51% (3293/6455)   
Checking out files:  52% (3357/6455)   
Checking out files:  53% (3422/6455)   
Checking out files:  54% (3486/6455)   
Checking out files:  55% (3551/6455)   
Checking out files:  56% (3615/6455)   
Checking out files:  57% (3680/6455)   
Checking out files:  58% (3744/6455)   
Checking out files:  59% (3809/6455)   
Checking out files:  60% (3873/6455)   
Checking out files:  61% (3938/6455)   
Checking out files:  62% (4003/6455)   
Checking out files:  63% (4067/6455)   
Checking out files:  64% (4132/6455)   
Checking out files:  65% (4196/6455)   
Checking out files:  66% (4261/6455)   
Checking out files:  67% (4325/6455)   
Checking out files:  68% (4390/6455)   
Checking out files:  69% (4454/6455)   
Checking out files:  70% (4519/6455)   
Checking out files:  71% (4584/6455)   
Checking out files:  72% (4648/6455)   
Checking out files:  73% (4713/6455)   
Checking out files:  74% (4777/6455)   
Checking out files:  75% (4842/6455)   
Checking out files:  76% (4906/6455)   
Checking out files:  77% (4971/6455)   
Checking out files:  78% (5035/6455)   
Checking out files:  79% (5100/6455)   
Checking out files:  80% (5164/6455)   
Checking out files:  81% (5229/6455)   
Checking out files:  82% (5294/6455)   
Checking out files:  83% (5358/6455)   
Checking out files:  84% (5423/6455)   
Checking out files:  85% (5487/6455)   
Checking out files:  86% (5552/6455)   
Checking out files:  87% (5616/6455)   
Checking out files:  88% (5681/6455)   
Checking out files:  89% (5745/6455)   
Checking out files:  90% (5810/6455)   
Checking out files:  91% (5875/6455)   
Checking out files:  92% (5939/6455)   
Checking out files:  93% (6004/6455)   
Checking out files:  94% (6068/6455)   
Checking out files:  95% (6133/6455)   
Checking out files:  96% (6197/6455)   
Checking out files:  97% (6262/6455)   
Checking out files:  98% (6326/6455)   
Checking out files:  99% (6391/6455)   
Checking out files: 100% (6455/6455)   
Checking out files: 100% (6455/6455), done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-war7yhb3/src/docker-src.2018-11-08-17.18.34.5123/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-war7yhb3/src/docker-src.2018-11-08-17.18.34.5123/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-quick in qemu:centos7 
Packages installed:
SDL-devel-1.2.15-14.el7.x86_64
bison-3.0.4-1.el7.x86_64
bzip2-1.0.6-13.el7.x86_64
bzip2-devel-1.0.6-13.el7.x86_64
ccache-3.3.4-1.el7.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el7.x86_64
flex-2.5.37-3.el7.x86_64
gcc-4.8.5-28.el7_5.1.x86_64
gettext-0.19.8.1-2.el7.x86_64
git-1.8.3.1-14.el7_5.x86_64
glib2-devel-2.54.2-2.el7.x86_64
libaio-devel-0.3.109-13.el7.x86_64
libepoxy-devel-1.3.1-2.el7_5.x86_64
libfdt-devel-1.4.6-1.el7.x86_64
lzo-devel-2.06-8.el7.x86_64
make-3.82-23.el7.x86_64
mesa-libEGL-devel-17.2.3-8.20171019.el7.x86_64

Re: [Qemu-devel] [PATCH v15 00/10] Add ARMv8 RAS virtualization support in QEMU

[no-reply]

Hi,

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

Type: series
Message-id: 1541672153-15529-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH v15 00/10] Add ARMv8 RAS virtualization support in 
QEMU

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

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

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

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
ea6f559ebb target-arm: kvm64: handle SIGBUS signal from kernel or KVM
f7559fdd5e hw/arm/virt: Add RAS platform version for migration
5d5ce7694f target-arm: kvm64: inject synchronous External Abort
5d4a5f1e8e KVM: Move related hwpoison page functions to accel/kvm/ folder
cfe8041c05 docs: APEI GHES generation and CPER record description
9cbe3a1625 ACPI: Add APEI GHES table generation and CPER record support
f50bae0c92 acpi: add build_append_ghes_generic_status() helper for Generic 
Error Status Block
5202c7810c acpi: add build_append_ghes_generic_data() helper for Generic Error 
Data Entry
d56660774b acpi: add build_append_ghes_notify() helper for Hardware Error 
Notification
f62584522a ACPI: add some GHES structures and macros definition

=== OUTPUT BEGIN ===
Checking PATCH 1/10: ACPI: add some GHES structures and macros definition...
Checking PATCH 2/10: acpi: add build_append_ghes_notify() helper for Hardware 
Error Notification...
Checking PATCH 3/10: acpi: add build_append_ghes_generic_data() helper for 
Generic Error Data Entry...
Checking PATCH 4/10: acpi: add build_append_ghes_generic_status() helper for 
Generic Error Status Block...
Checking PATCH 5/10: ACPI: Add APEI GHES table generation and CPER record 
support...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#46: 
new file mode 100644

WARNING: line over 80 characters
#106: FILE: hw/acpi/acpi_ghes.c:56:
+build_append_int_noprefix((void *)hardware_errors, 1, 
GHES_ADDRESS_SIZE);

WARNING: line over 80 characters
#134: FILE: hw/acpi/acpi_ghes.c:84:
+build_append_int_noprefix(table_data, cpu_to_le16(i), 2); /* source id 
*/

WARNING: line over 80 characters
#135: FILE: hw/acpi/acpi_ghes.c:85:
+build_append_int_noprefix(table_data, 0x, 2); /* related source id 
*/

WARNING: line over 80 characters
#148: FILE: hw/acpi/acpi_ghes.c:98:
+build_append_gas(table_data, AML_SYSTEM_MEMORY, 0x40, 0, 4 /* QWord 
access */, 0);

WARNING: line over 80 characters
#172: FILE: hw/acpi/acpi_ghes.c:122:
+build_append_gas(table_data, AML_SYSTEM_MEMORY, 0x40, 0, 4 /* QWord 
access */, 0);

ERROR: line over 90 characters
#309: FILE: include/hw/acpi/acpi_ghes.h:29:
+/* The size of Address field in Generic Address Structure, ACPI 2.0/3.0: 
5.2.3.1 Generic Address

total: 1 errors, 6 warnings, 311 lines checked

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

Checking PATCH 6/10: docs: APEI GHES generation and CPER record description...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#14: 
new file mode 100644

total: 0 errors, 1 warnings, 97 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 7/10: KVM: Move related hwpoison page functions to accel/kvm/ 
folder...
Checking PATCH 8/10: target-arm: kvm64: inject synchronous External Abort...
Checking PATCH 9/10: hw/arm/virt: Add RAS platform version for migration...
Checking PATCH 10/10: target-arm: kvm64: handle SIGBUS signal from kernel or 
KVM...
WARNING: line over 80 characters
#80: FILE: hw/acpi/acpi_ghes.c:68:
+current_block_length = sizeof(AcpiGenericErrorStatus) + 
le32_to_cpu(data_length);

WARNING: line over 80 characters
#89: FILE: hw/acpi/acpi_ghes.c:77:
+if ((data_length + sizeof(AcpiGenericErrorStatus)) > 
GHES_MAX_RAW_DATA_LENGTH) {

WARNING: line over 80 characters
#94: FILE: hw/acpi/acpi_ghes.c:82:
+build_append_ghes_generic_status(block, 
cpu_to_le32(ACPI_GEBS_UNCORRECTABLE), 0, 0,

WARNING: line over 80 characters
#106: FILE: hw/acpi/acpi_ghes.c:94:
+cpu_to_le32(ACPI_CPER_SEV_RECOVERABLE), 
cpu_to_le32(0x300), 0, 0,

WARNING: line over 80 characters
#107: FILE: hw/acpi/acpi_ghes.c:95:
+cpu_to_le32(80)/* the total size of Memory Error Record 
*/, fru_id,

total: 0 errors, 5 warnings, 256 lines checked

Your patch has style problems, please review. 

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

[Maciej W. Rozycki]

On Thu, 8 Nov 2018, Fredrik Noring wrote:

> > Fredrik, do you know by any chance if a document exists that would justify
> > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by
> > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both?
> > 
> > I think gcc folks must have had a good reason for that, some kind of
> > design - it can't be 'I really like/miss this instruction, let's include
> > it...'
> 
> The R5900 reports itself as MIPS III and DMULT, DMULTU, DDIV and DDIVU
> are part of the MIPS III ISA. They are emulated in user mode to support
> generic MIPS III programs.

 FAOD, GCC does not emit these instructions if the R5900 architecture has 
been selected for compilation, e.g.:

/* ISA supports instructions DMULT and DMULTU. */
#define ISA_HAS_DMULT   (TARGET_64BIT   \
 && !TARGET_MIPS5900\
 && mips_isa_rev <= 5)

however they are a part of the base 64-bit MIPS Linux user psABI, which is 
the whole of the MIPS III ISA, so the runtime has to support them one way 
or another (just like LL, SC and SYNC are a part of the 32-bit MIPS Linux 
user psABI even though they are not supported by MIPS I hardware).

  Maciej

Re: [Qemu-devel] QEMU and Kconfig

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 09:28:06PM +0100, Paolo Bonzini wrote:
> Oops. :)
> 
> On 08/11/2018 19:42, Eduardo Habkost wrote:
> >>> Keeping in mind that I might be talking about extra challenges we
> >>> won't address right now (no cart before the horse), I have new
> >>> questions:
> >>>
> >>> Why you say backends are not a target configuration and
> >>> accelerators are?  What's the definition of "target
> >>> configuration"?
> 
> Something that affects the hardware seen by the guest is target
> configuration.
> 
> Backends do not affect what hardware the guest sees.  Boards and devices
> do; accelerators do, but that's more of a side-effect than something
> intended.

Understood.  My interpretation of "target" was just "a QEMU
binary".  In other words, I thought we were talking about
anything that could be compiled in/out from a specific QEMU
binary.

Do you have a specific reason to restrict the scope to only
guest-visible effects?  Is this just a way to reduce the effort
required for the task, or there are other caveats I'm missing?

-- 
Eduardo

Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state

[Paolo Bonzini]

On 08/11/2018 19:41, Liran Alon wrote:
> So what I plan to do is indeed to define first 4K of data as vmcs12 and next 
> 4K as shadow_vmcs12.
> I will also define each of them in a separate VMState subsection that each 
> will have it’s own .needed()
> method that will decide if it’s relevant to send it based on kvm_state.size.
> vmcs12 and shadow_vmcs12 will be put in a struct which is unioned with a 
> struct
> of 2 pages buffer to clearly indicate that one well-defined struct is used 
> for VMX and the other for SVM.
> (based on kvm_state.format)

And SVM will use other subsections.

> In addition, I will change KVM_{GET,SET}_NESTED_STATE documentation to 
> indicate that
> future nested state fields should be added at the end of struct and weather 
> they are valid should
> be determined by a flag in kvm_state.flags.
> QEMU will handle these new states in the future by adding more VMState 
> subsections that have
> .needed() method based on appropriate flag in kvm_state.flags.
> The struct itself that userspace use against it’s local kernel will be 
> determined based on KVM_CAPs.
> 
> If there are no objections, I will write the needed patches for QEMU (and the 
> documentation patch for KVM).

Sure.  You can also place the flags and format in yet another subsection.

Paolo

[Qemu-devel] [PULL 1/1] 9p: write lock path in v9fs_co_open2()

[Greg Kurz]

The assumption that the fid cannot be used by any other operation is
wrong. At least, nothing prevents a misbehaving client to create a
file with a given fid, and to pass this fid to some other operation
at the same time (ie, without waiting for the response to the creation
request). The call to v9fs_path_copy() performed by the worker thread
after the file was created can race with any access to the fid path
performed by some other thread. This causes use-after-free issues that
can be detected by ASAN with a custom 9p client.

Unlike other operations that only read the fid path, v9fs_co_open2()
does modify it. It should hence take the write lock.

Cc: P J P 
Reported-by: zhibin hu 
Signed-off-by: Greg Kurz 
---
 hw/9pfs/cofile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
index 88791bc327ac..9c22837cda32 100644
--- a/hw/9pfs/cofile.c
+++ b/hw/9pfs/cofile.c
@@ -140,10 +140,10 @@ int coroutine_fn v9fs_co_open2(V9fsPDU *pdu, V9fsFidState 
*fidp,
 cred.fc_gid = gid;
 /*
  * Hold the directory fid lock so that directory path name
- * don't change. Read lock is fine because this fid cannot
- * be used by any other operation.
+ * don't change. Take the write lock to be sure this fid
+ * cannot be used by another operation.
  */
-v9fs_path_read_lock(s);
+v9fs_path_write_lock(s);
 v9fs_co_run_in_worker(
 {
 err = s->ops->open2(>ctx, >path,
-- 
2.17.2

[Qemu-devel] [PULL 0/1] 9p fixes for v3.1.0-rc1

[Greg Kurz]

The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:

  tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)

are available in the Git repository at:

  https://github.com/gkurz/qemu.git tags/for-upstream

for you to fetch changes up to 5b76ef50f62079a2389ba28cacaf6cce68b1a0ed:

  9p: write lock path in v9fs_co_open2() (2018-11-08 21:19:05 +0100)


Fixes a potential use-after-free issue that could be triggered by a
misbehaving guest.


Greg Kurz (1):
  9p: write lock path in v9fs_co_open2()

 hw/9pfs/cofile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
-- 
2.17.2

Re: [Qemu-devel] [PATCH v2 19/22] vl: Introduce shutdown_notifiers

[Yuval Shaia]

On Thu, Nov 08, 2018 at 05:26:06PM +0100, Cornelia Huck wrote:
> On Thu,  8 Nov 2018 18:08:15 +0200
> Yuval Shaia  wrote:
> 
> > Notifier will be used for signaling shutdown event to inform system is
> > shutdown. This will allow devices and other component to run some
> > cleanup code needed before VM is shutdown.
> > 
> > Signed-off-by: Yuval Shaia 
> > ---
> >  include/sysemu/sysemu.h |  1 +
> >  vl.c| 15 ++-
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> > 
> 
> > @@ -1809,6 +1811,12 @@ static void qemu_system_powerdown(void)
> >  notifier_list_notify(_notifiers, NULL);
> >  }
> >  
> > +static void qemu_system_shutdown(bool by_guest)
> 
> I would pass the shutdown reason here directly (instead of only whether
> this was triggered by the guest or not)...
> 
> > +{
> > +qapi_event_send_shutdown(by_guest);
> > +notifier_list_notify(_notifiers, NULL);
> 
> ...and also pass it to the notifiers here. If we have the info anyway,
> why not simply pass it along.

Agree, make sense.

> 
> > +}
> > +
> >  void qemu_system_powerdown_request(void)
> >  {
> >  trace_qemu_system_powerdown_request();
> > @@ -1821,6 +1829,11 @@ void qemu_register_powerdown_notifier(Notifier 
> > *notifier)
> >  notifier_list_add(_notifiers, notifier);
> >  }
> >  
> > +void qemu_register_shutdown_notifier(Notifier *notifier)
> > +{
> > +notifier_list_add(_notifiers, notifier);
> > +}
> > +
> >  void qemu_system_debug_request(void)
> >  {
> >  debug_requested = 1;
> > @@ -1848,7 +1861,7 @@ static bool main_loop_should_exit(void)
> >  request = qemu_shutdown_requested();
> >  if (request) {
> >  qemu_kill_report();
> > -qapi_event_send_shutdown(shutdown_caused_by_guest(request));
> > +qemu_system_shutdown(shutdown_caused_by_guest(request));
> >  if (no_shutdown) {
> >  vm_stop(RUN_STATE_SHUTDOWN);
> >  } else {
> 

Re: [Qemu-devel] QEMU and Kconfig

[Paolo Bonzini]

Oops. :)

On 08/11/2018 19:42, Eduardo Habkost wrote:
>>> Keeping in mind that I might be talking about extra challenges we
>>> won't address right now (no cart before the horse), I have new
>>> questions:
>>>
>>> Why you say backends are not a target configuration and
>>> accelerators are?  What's the definition of "target
>>> configuration"?

Something that affects the hardware seen by the guest is target
configuration.

Backends do not affect what hardware the guest sees.  Boards and devices
do; accelerators do, but that's more of a side-effect than something
intended.

Paolo

Re: [Qemu-devel] [RFC/PoC PATCH 0/3] support initrd size up to 4G

[Wainer dos Santos Moschetta]

Under review, the following patch adds acceptance tests for the initrd 
option:


https://www.mail-archive.com/qemu-devel@nongnu.org/msg567776.html

The test should be updated in case this series get merged. Maybe the 
best would be to include those tests along with this series actually.


- Wainer


On 11/08/2018 08:59 AM, Li Zhijian wrote:

Long long ago, linux kernel have supported up to 4G initrd, but it's header 
still
hard code to allow 2G - 1 only.
  # (Header version 0x0203 or later) the highest safe address for the contents
  # of an initrd. The current kernel allows up to 4 GB, but leave it at 2 GB to
  # avoid possible bootloader bugs.

kexec is one of the known scenario which has supported up to 4G initrd.

This patches is to enable up to 4G initrd, Seabios + optionrom(linuxboot_dma)
works as expected so far.

3/3 has a huge change of address/memory APIs.
I replace 'int len' in a stupid way, but it looks not safety.
$ sed -i 's/int len/uint32_t len/' exec.c
$ make # and check compiling errors
$ sed -i 's/int len/uint32_t len/' cpu-all.h
$ make -i 's/int len/uint32_t len/' include/exec/cpu-common.h
$ make -i 's/int len/uint32_t len/' include/exec/memory.h
$ make # all errors gone

CC: Paolo Bonzini 
CC: Peter Crosthwaite 
CC: Richard Henderson 

Li Zhijian (3):
   i386: set initrd_max to 4G - 1 to allow up to 4G initrd
   change size type from int to int64_t on load_image()
   change int len to uin32_t len

  exec.c| 42 +-
  hw/core/loader.c  |  3 ++-
  hw/i386/pc.c  |  6 ++
  include/exec/cpu-all.h|  2 +-
  include/exec/cpu-common.h | 10 +-
  include/exec/memory.h | 20 ++--
  6 files changed, 45 insertions(+), 38 deletions(-)

Re: [Qemu-devel] [PATCH 0/2] target/riscv: Bugfixes found in decodetree conversion

[Palmer Dabbelt]

On Thu, 08 Nov 2018 09:29:26 PST (-0800), Bastian Koppelmann wrote:


On 11/8/18 4:53 PM, Richard Henderson wrote:

On 11/8/18 1:06 PM, Bastian Koppelmann wrote:

while going through the reviews of the riscv-decodetree patches, two bugs came
up that I fix here. There is one more problem [1] mentioned by Richard but
I don't have the time to investigate it further.

[1] https://patchwork.kernel.org/patch/10650293/

That one's not a bug, but an optimization.

The other bug mentioned is shrw and shaw not sign-extending the result.



That was a bug I introduced during the conversion to decodetree.


My understand of that patch feedback is that there are two issues:

* We don't take advantage of the ordering bits on fences, which could allow us 
 to emit less conservative fences.  This would presumably increase 
 performance.

* We treat fences as NOPs under "#ifndef CONFIG_USER_ONLY", which is a bug.

Am I wrong about that second one?  I think the fix should look something like 
this, which I haven't even tried to compile


diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 18d7b6d1471d..624d1c679a84 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -1766,7 +1766,6 @@ static void decode_RV32_64G(CPURISCVState *env, 
DisasContext *ctx)
 GET_RM(ctx->opcode));
break;
case OPC_RISC_FENCE:
-#ifndef CONFIG_USER_ONLY
if (ctx->opcode & 0x1000) {
/* FENCE_I is a no-op in QEMU,
 * however we need to end the translation block */
@@ -1777,7 +1776,6 @@ static void decode_RV32_64G(CPURISCVState *env, 
DisasContext *ctx)
/* FENCE is a full memory barrier. */
tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
}
-#endif
break;
case OPC_RISC_SYSTEM:
gen_system(env, ctx, MASK_OP_SYSTEM(ctx->opcode), rd, rs1,

Re: [Qemu-devel] [PATCH for 3.1 v1 1/1] hw/riscv/virt: Free the test device tree node name

[Palmer Dabbelt]

On Wed, Nov 7, 2018 at 1:52 PM Alistair Francis  
wrote:

> Signed-off-by: Alistair Francis 
> ---
>  hw/riscv/virt.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 4a137a503c..2b38f89070 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -240,6 +240,7 @@ static void *create_fdt(RISCVVirtState *s, const 
> struct MemmapEntry *memmap,
>  qemu_fdt_setprop_cells(fdt, nodename, "reg",
>  0x0, memmap[VIRT_TEST].base,
>  0x0, memmap[VIRT_TEST].size);
> +g_free(nodename);
>
>  nodename = g_strdup_printf("/uart@%lx",
>  (long)memmap[VIRT_UART0].base);
> -- 
> 2.19.1
>

Reviewed-by: Palmer Dabbelt  

Re: [Qemu-devel] [PULL] A Single RISC-V Patch for 3.1-rc1

[Palmer Dabbelt]

On Thu, 08 Nov 2018 10:38:51 PST (-0800), alistai...@gmail.com wrote:

On Thu, Nov 8, 2018 at 10:35 AM Palmer Dabbelt  wrote:


The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:

  tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)

are available in the Git repository at:

  git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-rc1

for you to fetch changes up to 00a014ac01feac875468d38c376f7e06f050f992:

  riscv: spike: Fix memory leak in the board init (2018-11-08 08:41:06 -0800)


A Single RISC-V Patch for 3.1-rc1

This tag contains a single patch that I'd like to target for rc1: a fix
for a memory leak that was detected by static code analysis.

There are still three patch sets that I'd like to try to get up for 3.1:

* The patch set Basian just published that contains fixes for a pair of
  issues he found when converting our port to decodetree.
* An as-of-yet-unwritten fix to the third issue that Basian pointed out.
* A fix to our fflags bug, which is currently coupled to some CSR
  refactoring that I don't think is OK for 3.1.


There is one more patch fixing a memory leak in the virt board as well.


Oh, sorry about that -- I thought they were the same patch!

Peter: let me know if you want me to submit a new copy of this PR with both 
patches or a follow-on PR.  Sorry for the noise!



I'm at Plumbers next week (and I think Alistair is there too?), but I'll
try to find a way to squeeze in as much as possible.


Yep! I'll be there.

Alistair




Alistair Francis (1):
  riscv: spike: Fix memory leak in the board init

 hw/riscv/spike.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

[Fredrik Noring]

Hi Aleksandar,

> Fredrik, do you know by any chance if a document exists that would justify
> inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by
> gcc for R5900? Is it included by cross-gcc or by native gcc, or by both?
> 
> I think gcc folks must have had a good reason for that, some kind of
> design - it can't be 'I really like/miss this instruction, let's include
> it...'

The R5900 reports itself as MIPS III and DMULT, DMULTU, DDIV and DDIVU
are part of the MIPS III ISA. They are emulated in user mode to support
generic MIPS III programs.

I have now obtained an R5900 n32 ABI toolchain. R5900 n32 ABI emulation
support is recognised with

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01609.html

and a test of DMULT emulation is available with

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01610.html

Fredrik

Re: [Qemu-devel] [PATCH for 3.1 v1 1/1] hw/riscv/virt: Free the test device tree node name

[Palmer Dabbelt]

On Thu, 08 Nov 2018 10:37:28 PST (-0800), alistai...@gmail.com wrote:

On Wed, Nov 7, 2018 at 6:38 PM Palmer Dabbelt  wrote:


On Wed, 07 Nov 2018 13:51:45 PST (-0800), Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> ---
>  hw/riscv/virt.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 4a137a503c..2b38f89070 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -240,6 +240,7 @@ static void *create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
>  qemu_fdt_setprop_cells(fdt, nodename, "reg",
>  0x0, memmap[VIRT_TEST].base,
>  0x0, memmap[VIRT_TEST].size);
> +g_free(nodename);
>
>  nodename = g_strdup_printf("/uart@%lx",
>  (long)memmap[VIRT_UART0].base);
> --
> 2.19.1

Thanks.  I got a bit behind this week so I didn't send the pre-PR, but I indent
to send a PR tomorrow.  That PR currently only contains this patch.


There should be two patches. One for spike and one for the virt machine.


Oh, sorry about that -- I thought they were the same patch!

Peter: let me know if you want me to submit a new copy of this PR with both 
patches or a follow-on PR.  Sorry for the noise!

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Philippe Mathieu-Daudé]

On Thu, Nov 8, 2018 at 7:43 PM Markus Armbruster  wrote:
> Peter Maydell  writes:
> > On 8 November 2018 at 18:08, Philippe Mathieu-Daudé  
> > wrote:
> >> Anyway there are no information about merge window in the wiki.
> >> When I started it was not easy to understand it and why patches sent when
> >> 'merge window is close' fall under the crap and are unnoticed, thus it is
> >> better to wait before to send, or resend them.
> >
> > The intention (not always something we succeed at) is that
> > maintainers should respond to patches, do review, etc, at
> > any point in our release cycle. During a release they might
> > reply to say "I won't get to reviewing this for a little while"
> > or "I'll take this patch once the trunk reopens for releases",
>
> In both cases, the maintainer remains responsible for tracking the
> patches.
>
> I believe the sane thing to do is to review patches as usual, and to
> queue the ones that are ready to go into the next release on a separate
> branch.
>
> > but they shouldn't just leave patch submitters with no response
> > at all...
>
> Yes, that's rude.

Thanks both to clarify your maintainer view.
I added this thread to my TODO and if nobody write about this in the
wiki I'll, but later.

Phil.

[Qemu-devel] [PATCH 2/2] tests/tcg/mips: Test user mode DMULT for the R5900

[Fredrik Noring]

The R5900 reports itself as MIPS III but does not implement DMULT.
Verify that DMULT is emulated properly in user mode by multiplying
two 64-bit numbers to produce a 128-bit number.

Signed-off-by: Fredrik Noring 
---
 tests/tcg/mips/mipsn32r5900/Makefile | 25 +
 tests/tcg/mips/mipsn32r5900/dmult.c  | 40 
 2 files changed, 65 insertions(+)
 create mode 100644 tests/tcg/mips/mipsn32r5900/Makefile
 create mode 100644 tests/tcg/mips/mipsn32r5900/dmult.c

diff --git a/tests/tcg/mips/mipsn32r5900/Makefile 
b/tests/tcg/mips/mipsn32r5900/Makefile
new file mode 100644
index 00..7dd16723fe
--- /dev/null
+++ b/tests/tcg/mips/mipsn32r5900/Makefile
@@ -0,0 +1,25 @@
+-include ../../config-host.mak
+
+CROSS=mips64r5900el-unknown-linux-gnu-
+
+SIM=qemu-mipsn32el
+SIM_FLAGS=-cpu R5900
+
+CC  = $(CROSS)gcc
+CFLAGS  = -Wall -mabi=n32 -march=r5900 -static
+
+TESTCASES = dmult.tst
+
+all: $(TESTCASES)
+
+%.tst: %.c
+   $(CC) $(CFLAGS) $< -o $@
+
+check: $(TESTCASES)
+   @for case in $(TESTCASES); do \
+echo $(SIM) $(SIM_FLAGS) ./$$case;\
+$(SIM) $(SIM_FLAGS) ./$$case; \
+   done
+
+clean:
+   $(RM) -rf $(TESTCASES)
diff --git a/tests/tcg/mips/mipsn32r5900/dmult.c 
b/tests/tcg/mips/mipsn32r5900/dmult.c
new file mode 100644
index 00..2827ab5358
--- /dev/null
+++ b/tests/tcg/mips/mipsn32r5900/dmult.c
@@ -0,0 +1,40 @@
+/*
+ * Test DMULT.
+ */
+
+#include 
+#include 
+#include 
+
+struct hi_lo { int64_t hi; uint64_t lo; };
+
+static struct hi_lo dmult(int64_t rs, int64_t rt)
+{
+int64_t hi;
+uint64_t lo;
+
+/*
+ * The R5900 reports itself as MIPS III but does not implement DMULT.
+ * Verify that DMULT is emulated properly in user mode.
+ */
+__asm__ __volatile__ (
+".set  mips3\n"
+"dmult %2, %3\n"
+"mfhi  %0\n"
+"mflo  %1\n"
+: "=r" (hi), "=r" (lo)
+: "r" (rs), "r" (rt));
+
+return (struct hi_lo) { .hi = hi, .lo = lo };
+}
+
+int main()
+{
+/* Verify that multiplying two 64-bit numbers yields a 128-bit number. */
+struct hi_lo r = dmult(2760727302517, 5665449960167);
+
+assert(r.hi == 847887);
+assert(r.lo == 7893651516417804947);
+
+return 0;
+}
-- 
2.18.1

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Markus Armbruster]

Peter Maydell  writes:

> On 8 November 2018 at 18:08, Philippe Mathieu-Daudé  wrote:
>> Anyway there are no information about merge window in the wiki.
>> When I started it was not easy to understand it and why patches sent when
>> 'merge window is close' fall under the crap and are unnoticed, thus it is
>> better to wait before to send, or resend them.
>
> The intention (not always something we succeed at) is that
> maintainers should respond to patches, do review, etc, at
> any point in our release cycle. During a release they might
> reply to say "I won't get to reviewing this for a little while"
> or "I'll take this patch once the trunk reopens for releases",

In both cases, the maintainer remains responsible for tracking the
patches.

I believe the sane thing to do is to review patches as usual, and to
queue the ones that are ready to go into the next release on a separate
branch.

> but they shouldn't just leave patch submitters with no response
> at all...

Yes, that's rude.

[...]

[Qemu-devel] [PATCH 1/2] linux-user/mips: Support the n32 ABI for the R5900

[Fredrik Noring]

Recognise the R5900, which reports itself as MIPS III, as a 64-bit CPU
supporting the n32 ABI.

Signed-off-by: Fredrik Noring 
---
 linux-user/mips64/target_elf.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/linux-user/mips64/target_elf.h b/linux-user/mips64/target_elf.h
index ec55d8542a..5f2f2df29f 100644
--- a/linux-user/mips64/target_elf.h
+++ b/linux-user/mips64/target_elf.h
@@ -12,6 +12,9 @@ static inline const char *cpu_get_model(uint32_t eflags)
 if ((eflags & EF_MIPS_ARCH) == EF_MIPS_ARCH_64R6) {
 return "I6400";
 }
+if ((eflags & EF_MIPS_MACH) == EF_MIPS_MACH_5900) {
+return "R5900";
+}
 return "5KEf";
 }
 #endif
-- 
2.18.1

Re: [Qemu-devel] QEMU and Kconfig

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 06:58:11PM +0100, Paolo Bonzini wrote:
> On 08/11/2018 18:14, Eduardo Habkost wrote:
> > Keeping in mind that I might be talking about extra challenges we
> > won't address right now (no cart before the horse), I have new
> > questions:
> > 
> > Why you say backends are not a target configuration and
> > accelerators are?  What's the definition of "target
> > configuration"?
> 
> Something that affects the way

?

> 
> > Are we explicitly restricting the scope of this work to
> > enabling/disabling device emulation code right now?  Why?  Why
> > wouldn't we use kconfig to enable/disable simple backends with no
> > host dependency like SLIRP?
> 
> I think it would be more confusing if some backends were to use kconfig
> and some wouldn't.  We could certainly add something like
> 
> config VHOST_NET
> depends on HOST_LINUX
> default y
> 
> config SPICE
> depends on HAVE_SPICE_SERVER
> default Y
> 
> etc. but I think we agree it's more of a long term idea.

Agreed.

> 
> > Don't we want to make backends configurable per binary, too?
> > e.g.: I would expect the default configuration for a NEMU-like
> > binary to disable many backends.
> 
> Sure, we could do that.  However, right now you cannot have multiple
> binaries for a single target, so you couldn't have one single build
> include both a "full-blown" and a "reduced" x86 target.  Therefore,
> including e.g. SLIRP in qemu-system-arm but not in qemu-system-x86_64
> does not seem too interesting to me.  It would be different if you could
> build qemu-system-arm, qemu-system-x86_64, qemu-system-x86_64-lite, etc.

Understood.  I assumed this would be one of the short-term goals.
We can work on that later, then.


> 
> Paolo
> 
> > 
> >> It would surely be possible for configure to call into minikconf to
> >> parse a configuration file and apply dependencies (do we actually have
> >> dependencies across configure options?) or something like that, but
> >> let's not put the cart before the horse...
> > 
> > Agreed.
> > 
> 

-- 
Eduardo

[Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

[Fredrik Noring]

Recognise the R5900, which reports itself as MIPS III, as a 64-bit CPU
supporting the n32 ABI. Test that DMULT is emulated in user mode.

This series has been successfully built with the 10 different build
configurations

{gcc,clang} x -m64 x mips{,64}el-{linux-user,softmmu}
{gcc,clang} x -m64 x mipsn32el-linux-user

in addition successfully completing the R5900 test suite

cd tests/tcg/mips/mipsr5900 && make check
cd tests/tcg/mips/mipsn32r5900 && make check

Fredrik Noring (2):
  linux-user/mips: Support the n32 ABI for the R5900
  tests/tcg/mips: Test user mode DMULT for the R5900

 linux-user/mips64/target_elf.h   |  3 +++
 tests/tcg/mips/mipsn32r5900/Makefile | 25 +
 tests/tcg/mips/mipsn32r5900/dmult.c  | 40 
 3 files changed, 68 insertions(+)
 create mode 100644 tests/tcg/mips/mipsn32r5900/Makefile
 create mode 100644 tests/tcg/mips/mipsn32r5900/dmult.c

-- 
2.18.1

Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state

[Liran Alon]

> On 8 Nov 2018, at 19:02, Paolo Bonzini  wrote:
> 
> On 08/11/2018 10:57, Liran Alon wrote:
>> 
>> 
>>> On 8 Nov 2018, at 11:50, Paolo Bonzini  wrote:
>>> 
>>> On 08/11/2018 01:45, Jim Mattson wrote:
 I have no attachments to the current design. I had used a data[] blob,
 because I didn't think userspace would have any need to know what was
 in there. However, I am now seeing the error of my ways. For example,
 the userspace instruction emulator needs to know the contents of the
 vmcs12 to emulate instructions when in guest mode.
>>> 
>>> Yeah, we're probably going to have to document the KVM vmcs12 structure,
>>> possibly moving it to uapi.  But that's a different thing from
>>> save/restore state, which can use the 4K or 8K data[] blob.
>>> 
>>> Paolo
>> 
>> But regardless of if we document vmcs12 or not, the current blob we
>> have today should be separated to well-defined blobs/structs (cached_vmcs12
>> and cached_shadow_vmcs12) and each blob should have a relevant flag that 
>> specifies
>> it is valid (saved by kernel or requested to be restored by userspace).
>> Additional future nested-state should be added as additional
>> well-defined blobs/structs with appropriate flags.
> 
> We are somewhat limited by the ABI of the released kernel versions, and
> it's unlikely that the structure will change in the short term.  So I
> think it's okay if we just define that the first 4K of data are the VMCS
> and the second 8K are the shadow VMCS, whenever format=0 in the
> kvm_nested_state struct.
> 
> Paolo

So what I plan to do is indeed to define first 4K of data as vmcs12 and next 4K 
as shadow_vmcs12.
I will also define each of them in a separate VMState subsection that each will 
have it’s own .needed()
method that will decide if it’s relevant to send it based on kvm_state.size.
vmcs12 and shadow_vmcs12 will be put in a struct which is unioned with a struct
of 2 pages buffer to clearly indicate that one well-defined struct is used for 
VMX and the other for SVM.
(based on kvm_state.format)

In addition, I will change KVM_{GET,SET}_NESTED_STATE documentation to indicate 
that
future nested state fields should be added at the end of struct and weather 
they are valid should
be determined by a flag in kvm_state.flags.
QEMU will handle these new states in the future by adding more VMState 
subsections that have
.needed() method based on appropriate flag in kvm_state.flags.
The struct itself that userspace use against it’s local kernel will be 
determined based on KVM_CAPs.

If there are no objections, I will write the needed patches for QEMU (and the 
documentation patch for KVM).
(And throw away the current VMState technique I used in this version of the 
patch :P)

-Liran

> 
>> Then, in QEMU, each such well-defined blob/struct should have it’s own 
>> subsection with a relevant .needed() method.
>> This will allow us to preserve required backwards compatibility.
>> 
>> Agreed?
>> 
>> -Liran
>> 
> 

Re: [Qemu-devel] [PULL] A Single RISC-V Patch for 3.1-rc1

[Alistair Francis]

On Thu, Nov 8, 2018 at 10:35 AM Palmer Dabbelt  wrote:
>
> The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:
>
>   tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)
>
> are available in the Git repository at:
>
>   git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-rc1
>
> for you to fetch changes up to 00a014ac01feac875468d38c376f7e06f050f992:
>
>   riscv: spike: Fix memory leak in the board init (2018-11-08 08:41:06 -0800)
>
> 
> A Single RISC-V Patch for 3.1-rc1
>
> This tag contains a single patch that I'd like to target for rc1: a fix
> for a memory leak that was detected by static code analysis.
>
> There are still three patch sets that I'd like to try to get up for 3.1:
>
> * The patch set Basian just published that contains fixes for a pair of
>   issues he found when converting our port to decodetree.
> * An as-of-yet-unwritten fix to the third issue that Basian pointed out.
> * A fix to our fflags bug, which is currently coupled to some CSR
>   refactoring that I don't think is OK for 3.1.

There is one more patch fixing a memory leak in the virt board as well.

>
> I'm at Plumbers next week (and I think Alistair is there too?), but I'll
> try to find a way to squeeze in as much as possible.

Yep! I'll be there.

Alistair

>
> 
> Alistair Francis (1):
>   riscv: spike: Fix memory leak in the board init
>
>  hw/riscv/spike.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
>

Re: [Qemu-devel] [PATCH for 3.1 v1 1/1] hw/riscv/virt: Free the test device tree node name

[Alistair Francis]

On Wed, Nov 7, 2018 at 6:38 PM Palmer Dabbelt  wrote:
>
> On Wed, 07 Nov 2018 13:51:45 PST (-0800), Alistair Francis wrote:
> > Signed-off-by: Alistair Francis 
> > ---
> >  hw/riscv/virt.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index 4a137a503c..2b38f89070 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -240,6 +240,7 @@ static void *create_fdt(RISCVVirtState *s, const struct 
> > MemmapEntry *memmap,
> >  qemu_fdt_setprop_cells(fdt, nodename, "reg",
> >  0x0, memmap[VIRT_TEST].base,
> >  0x0, memmap[VIRT_TEST].size);
> > +g_free(nodename);
> >
> >  nodename = g_strdup_printf("/uart@%lx",
> >  (long)memmap[VIRT_UART0].base);
> > --
> > 2.19.1
>
> Thanks.  I got a bit behind this week so I didn't send the pre-PR, but I 
> indent
> to send a PR tomorrow.  That PR currently only contains this patch.

There should be two patches. One for spike and one for the virt machine.

Alistair

[Qemu-devel] [PULL] A Single RISC-V Patch for 3.1-rc1

[Palmer Dabbelt]

The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:

  tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)

are available in the Git repository at:

  git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-rc1

for you to fetch changes up to 00a014ac01feac875468d38c376f7e06f050f992:

  riscv: spike: Fix memory leak in the board init (2018-11-08 08:41:06 -0800)


A Single RISC-V Patch for 3.1-rc1

This tag contains a single patch that I'd like to target for rc1: a fix
for a memory leak that was detected by static code analysis.

There are still three patch sets that I'd like to try to get up for 3.1:

* The patch set Basian just published that contains fixes for a pair of
  issues he found when converting our port to decodetree.
* An as-of-yet-unwritten fix to the third issue that Basian pointed out.
* A fix to our fflags bug, which is currently coupled to some CSR
  refactoring that I don't think is OK for 3.1.

I'm at Plumbers next week (and I think Alistair is there too?), but I'll
try to find a way to squeeze in as much as possible.


Alistair Francis (1):
  riscv: spike: Fix memory leak in the board init

 hw/riscv/spike.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

[Qemu-devel] [PULL] riscv: spike: Fix memory leak in the board init

[Palmer Dabbelt]

From: Alistair Francis 

Coverity caught a malloc() call that was never freed. This patch ensures
that we free the memory but also updates the allocation to use
g_strdup_printf() instead of malloc().

Signed-off-by: Alistair Francis 
Suggested-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Reviewed-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/spike.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 8a712ed49026..268df04c3c7d 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -316,9 +316,7 @@ static void spike_v1_09_1_board_init(MachineState *machine)
 
 /* build config string with supplied memory size */
 char *isa = riscv_isa_string(>soc.harts[0]);
-size_t config_string_size = strlen(config_string_tmpl) + 48;
-char *config_string = malloc(config_string_size);
-snprintf(config_string, config_string_size, config_string_tmpl,
+char *config_string = g_strdup_printf(config_string_tmpl,
 (uint64_t)memmap[SPIKE_CLINT].base + SIFIVE_TIME_BASE,
 (uint64_t)memmap[SPIKE_DRAM].base,
 (uint64_t)ram_size, isa,
@@ -345,6 +343,8 @@ static void spike_v1_09_1_board_init(MachineState *machine)
 /* Core Local Interruptor (timer and IPI) */
 sifive_clint_create(memmap[SPIKE_CLINT].base, memmap[SPIKE_CLINT].size,
 smp_cpus, SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE);
+
+g_free(config_string);
 }
 
 static void spike_v1_09_1_machine_init(MachineClass *mc)
-- 
2.18.1

Re: [Qemu-devel] [Qemu-block] [PATCH] tests: Fix Python 3 detection on older GNU make versions

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 12:36:37PM -0500, Cleber Rosa wrote:
> 
> 
> On 11/8/18 11:51 AM, Eduardo Habkost wrote:
> 
> > I'm not sure I agree with the "is an important thing to keep
> > track of" part.  I don't think we'll have any need to keep track
> > of the Python version in shell script or makefiles after we start
> > requiring Python 3.
> > 
> 
> Well, "Python 3" is not a uniform thing.  There are many changes across
> the 3.x spectrum that can bite you.  I'm speaking out of the experience
> with Avocado, that supports Python 3.4, 3.5 and 3.6 (and that reminds me
> we should add tests for 3.7).

Do you expect us to need to keep track of the exact Python
version before running the Python interpreter?  Code written in
Python doesn't count, because it can simply use sys.version_info.


> 
> > Extra cleanups (like moving version checks to ./configure) are
> > still welcome, but keep in mind that this will probably be thrown
> > away once we drop Python 2 support.
> > 
> 
> I don't think it should.  Let me give the example of a "Python 3.0" job
> on Travis, related to the following snippet:
> 
> # Python builds
> - env: CONFIG="--target-list=x86_64-softmmu"
>   python:
> - "3.0"
> 
> If you look at https://travis-ci.org/clebergnu/qemu/jobs/452033247#L983
> you'll see that the intended goal was missed.  That has to do with how
> Travis makes the requested Python version available, and it was only
> obvious because this branch prints the Python version used.
> 
> Developers writing Python code, for instance tests, may assume a given
> API that doesn't exist or behave like they expect, and not knowing the
> Python version used on a remote environment makes debugging extra hard.

I'm not sure I get your point.  We can surely add diagnostic
messages to show the Python version, and we can make ./configure
fail if Python 3 is unavailable.  I'm talking about adding code
to ./configure to save Python version info for makefile rules and
shell scripts.  I expect the extra code to be unnecessary in the
future.

-- 
Eduardo

[Qemu-devel] [PATCH] Added support for ASLR and PIE for target user mode binaries

[Harrington, Sean M]

Hello,

I recently had to extend QEMU user mode to support PIE enabled binaries 
compiled for non-native architectures. It was also important to emulate ASLR 
for the target binary if ASLR was enabled on the host machine. I would like to 
introduce this as a feature into QEMU mainstream as it seems like a feature 
others could use as well.

With the patch implementation, ASLR will be enabled if 
/proc/sys/kernel/randomize_va_space is non-zero on the host machine. An 
alternative implementation could be passing an argument during runtime to 
enable or disable ASLR. PIE is automatically enabled as well if the binary has 
been compiled with this flag.

Best regards,
Sean Harrington

Signed-off-by: Sean Harrington 
---
 linux-user/Makefile.objs  |  3 +-
 linux-user/elfload.c  |  3 +-
 linux-user/main.c |  7 +++
 linux-user/randomize_va.c | 95 +++
 linux-user/randomize_va.h | 23 ++
 5 files changed, 129 insertions(+), 2 deletions(-)
 create mode 100644 linux-user/randomize_va.c
 create mode 100644 linux-user/randomize_va.h

diff --git a/linux-user/Makefile.objs b/linux-user/Makefile.objs
index 769b8d8336..384944a76d 100644
--- a/linux-user/Makefile.objs
+++ b/linux-user/Makefile.objs
@@ -1,7 +1,8 @@
 obj-y = main.o syscall.o strace.o mmap.o signal.o \
 elfload.o linuxload.o uaccess.o uname.o \
 safe-syscall.o $(TARGET_ABI_DIR)/signal.o \
-$(TARGET_ABI_DIR)/cpu_loop.o exit.o fd-trans.o
+$(TARGET_ABI_DIR)/cpu_loop.o exit.o fd-trans.o \
+randomize_va.o

 obj-$(TARGET_HAS_BFLT) += flatload.o
 obj-$(TARGET_I386) += vm86.o
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 5bccd2e243..5add383815 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -7,6 +7,7 @@
 #include "qemu.h"
 #include "disas/disas.h"
 #include "qemu/path.h"
+#include "randomize_va.h"

 #ifdef _ARCH_PPC64
 #undef ARCH_DLINFO
@@ -2258,7 +2259,7 @@ static void load_elf_image(const char *image_name, int 
image_fd,
image is pre-linked, LOADDR will be non-zero.  Since we do
not supply MAP_FIXED here we'll use that address if and
only if it remains available.  */
-load_addr = target_mmap(loaddr, hiaddr - loaddr, PROT_NONE,
+load_addr = get_pie_addr(loaddr, hiaddr - loaddr, PROT_NONE,
 MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
 -1, 0);
 if (load_addr == -1) {
diff --git a/linux-user/main.c b/linux-user/main.c
index 923cbb753a..3b789001dd 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -37,6 +37,7 @@
 #include "trace/control.h"
 #include "target_elf.h"
 #include "cpu_loop-common.h"
+#include "randomize_va.h"

 char *exec_path;

@@ -694,6 +695,12 @@ int main(int argc, char **argv, char **envp)
 target_environ = envlist_to_environ(envlist, NULL);
 envlist_free(envlist);

+/*
+ * If host has randomized_va_space enabled, emulate the same for the
+ * target.
+ */
+reserved_va = handle_randomized_va(reserved_va, MAX_RESERVED_VA);
+
 /*
  * Now that page sizes are configured in tcg_exec_init() we can do
  * proper page alignment for guest_base.
diff --git a/linux-user/randomize_va.c b/linux-user/randomize_va.c
new file mode 100644
index 00..792212a2b8
--- /dev/null
+++ b/linux-user/randomize_va.c
@@ -0,0 +1,95 @@
+/*
+ *  QEMU user ASLR + PIE emulation
+ *
+ *  Copyright (c) 2018 Sean Harrington (harring...@battelle.org)
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that 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/bitops.h"
+
+#include "qemu.h"
+#include "qemu-common.h"
+#include "randomize_va.h"
+
+#define PIE_MMAP_ATTEMPTS   10
+#define RANDOMIZATION_RANGE 0x0010
+
+unsigned long handle_randomized_va(unsigned long va, unsigned long 
max_va_space) {
+
+int randomize_va_fd = open("/proc/sys/kernel/randomize_va_space", 
O_RDONLY);
+srand(time(NULL));
+
+if (randomize_va_fd >= 0) {
+int aslr;
+if (read(randomize_va_fd, , sizeof(aslr)) < 0) {
+return va;
+}
+
+if (aslr) {
+/* At start, mmap_next_state is equal to TASK_UNMAPPED_BASE in
+ * mmap.c. Randomly choose a new random value within range
+ * [mmap_next_start - (TASK_UNMAPPED_BASE / 2),
+ * 

[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

[tlloss]

Ran through the commits included in the audio code merge, with the
following results:

[commit 280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d]
audio/hda: create millisecond timers that handle IO

Audio stream gets progressively more and more corrupted, breaking completely 
between 30'' and 1' after continuous sound start.
No problems playing short sounds.

--

[commit 0a373bb310c1533e24aa5e3edbf206507fb342ea]
audio/hda: turn some dprintfs into trace points

No changes from the previous commit, of course.

--

[commit 8ced0669237b2bbedac3e4ce6fcf7faae663]
audio/hda: tweak timer adjust logic

First time audio looks really good on this guest; the new code is
working, by the look of things.

--

[commit 4501ee16c76e89e0a2b2beb95f3b93f965997391]
audio/hda: detect output buffer overruns

First time issue presents itself.

--

So, I assume that commit 4501ee16c76e89e0a2b2beb95f3b93f965997391 introduced 
some kind of overrun control which mishandles the buffer, at least in my setup.
>From a quick and ignorant git diff between this and the previous commit, I can 
>see that the new detector could drop the buffer too early, or maybe it 
>misconfigures the st->buft_start property.

These last tests were performed by manually toggling the use-timer
property on from inside the source code; I hope this doesn't invalidate
their outcome, though.

As of now I have no clue on how to patch this thing, since I do not
understand the interactions between the various emulator's components.

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

Title:
  Malformed audio and video output stuttering after upgrade to QEMU 3.0

Status in QEMU:
  New

Bug description:
  My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened
  kernel, running a few KVM guests with varying OSes and configurations
  managed through a Libvirt stack.

  Among these guests I have two Windows 10 VMs with VGA passthrough and
  PulseAudio-backed virtual audio devices.

  After upgrading to QEMU 3.0.0, both of the Win10 guests started
  showing corrupted audio output in the form of unnatural reproduction
  speed and occasional but consistently misplaced audio fragments
  originating from what seems to be a circular buffer wrapping over
  itself (misbehaviour detected by starting some games with known OSTs
  and dialogues: soundtracks sound accelerated and past dialogue lines
  start replaying middle-sentence until the next line starts playing).

  In addition, the video output of the malfunctioning VMs regularly
  stutters roughly twice a second for a fraction of a second (sync'ed
  with the suspected buffer wrapping and especially pronounced during
  not-pre-rendered cutscenes), toghether with mouse freezes that look
  like actual input misses more than simple lack of screen refreshes.

  
  The issue was succesfully reproduced without the managing stack, directly 
with the following command line, on the most capable Windows guest:

   QEMU_AUDIO_DRV=pa
   QEMU_PA_SERVER=127.0.0.1
   /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \
   -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \

   
   -cpu 
host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off
 \  
   -drive 
file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ 
  
   -drive 
file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \
   -m 5120 \
  
   -realtime mlock=off \
   -smp 3,sockets=1,cores=3,threads=1 \
   -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \
   -display none \ 
   -no-user-config \
   -nodefaults \
   -rtc base=localtime,driftfix=slew \  

   
   -global kvm-pit.lost_tick_policy=delay \ 
 
   -no-hpet \  
   -no-shutdown \
   -global PIIX4_PM.disable_s3=1 \
   -global PIIX4_PM.disable_s4=1 \
   -boot strict=on \  
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \  
   
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \
   -device ahci,id=sata0,bus=pci.0,addr=0x9 \ 
   -drive 
file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
 \
   -device 

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Peter Maydell]

On 8 November 2018 at 18:08, Philippe Mathieu-Daudé  wrote:
> Anyway there are no information about merge window in the wiki.
> When I started it was not easy to understand it and why patches sent when
> 'merge window is close' fall under the crap and are unnoticed, thus it is
> better to wait before to send, or resend them.

The intention (not always something we succeed at) is that
maintainers should respond to patches, do review, etc, at
any point in our release cycle. During a release they might
reply to say "I won't get to reviewing this for a little while"
or "I'll take this patch once the trunk reopens for releases",
but they shouldn't just leave patch submitters with no response
at all...

> Also you could add the expected dates for the next releases there.

We only work out dates for the next release when we've got the
previous one out. They're roughly April/August/December, though.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v6] lsi: Reselection needed to remove pending commands from queue

[Paolo Bonzini]

On 07/11/2018 23:04, George Kennedy wrote:
> Your latest suggestion was the "missing link". Calling lsi_wait_reselect()
> after a WAIT DISCONNECT Script instruction when there are commands on 
> the pending queue is all the is needed. The patch has been greatly
> reduced in size and complexity.

Yeah, it's mixing initiator and target in slightly unhealthy ways, but
it's not something that you introduced.

(Can you also send, perhaps offlist, the other patch you were working on
which tried to introduce the right sequence of disconnect/reselect
before disk accesses and DMA respectively?  I'd like to keep it for
reference).

>  hw/scsi/lsi53c895a.c | 43 ---
>  1 file changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
> index d1e6534..7f9ed2f 100644
> --- a/hw/scsi/lsi53c895a.c
> +++ b/hw/scsi/lsi53c895a.c
> @@ -219,6 +219,7 @@ typedef struct {
>  int command_complete;
>  QTAILQ_HEAD(, lsi_request) queue;
>  lsi_request *current;
> +bool handle_pending;/* handle queued pending commands */
>  
>  uint32_t dsa;
>  uint32_t temp;
> @@ -298,6 +299,18 @@ static inline int lsi_irq_on_rsl(LSIState *s)
>  return (s->sien0 & LSI_SIST0_RSL) && (s->scid & LSI_SCID_RRE);
>  }
>  
> +static lsi_request *get_pending_req(LSIState *s)
> +{
> +lsi_request *p;
> +
> +QTAILQ_FOREACH(p, >queue, next) {
> +if (p->pending) {
> +return p;
> +}
> +}
> +return NULL;
> +}
> +
>  static void lsi_soft_reset(LSIState *s)
>  {
>  trace_lsi_reset();
> @@ -446,7 +459,6 @@ static void lsi_update_irq(LSIState *s)
>  {
>  int level;
>  static int last_level;
> -lsi_request *p;
>  
>  /* It's unclear whether the DIP/SIP bits should be cleared when the
> Interrupt Status Registers are cleared or when istat0 is read.
> @@ -477,12 +489,12 @@ static void lsi_update_irq(LSIState *s)
>  lsi_set_irq(s, level);
>  
>  if (!level && lsi_irq_on_rsl(s) && !(s->scntl1 & LSI_SCNTL1_CON)) {
> +lsi_request *p;
> +
>  trace_lsi_update_irq_disconnected();
> -QTAILQ_FOREACH(p, >queue, next) {
> -if (p->pending) {
> -lsi_reselect(s, p);
> -break;
> -}
> +p = get_pending_req(s);
> +if (p) {
> +lsi_reselect(s, p);
>  }
>  }
>  }
> @@ -759,6 +771,8 @@ static void lsi_command_complete(SCSIRequest *req, 
> uint32_t status, size_t resid
>  lsi_request_free(s, s->current);
>  scsi_req_unref(req);
>  }
> +s->handle_pending = get_pending_req(s) ? true : false;
> +
>  lsi_resume_script(s);
>  }
>  
> @@ -1064,11 +1078,15 @@ static void lsi_wait_reselect(LSIState *s)
>  
>  trace_lsi_wait_reselect();
>  
> -QTAILQ_FOREACH(p, >queue, next) {
> -if (p->pending) {
> -lsi_reselect(s, p);
> -break;
> -}
> +s->handle_pending = false;
> +
> +if (s->current) {
> +return;
> +}
> +
> +p = get_pending_req(s);
> +if (p) {
> +lsi_reselect(s, p);
>  }
>  if (s->current == NULL) {
>  s->waiting = 1;
> @@ -1258,6 +1276,9 @@ again:
>  case 1: /* Disconnect */
>  trace_lsi_execute_script_io_disconnect();
>  s->scntl1 &= ~LSI_SCNTL1_CON;
> +if (s->handle_pending) {

Can you explain the if?  Is it to avoid that "s->waiting = 1" assignment?

Also, could the disconnect case check get_pending_req directly, and call
lsi_reselect?  That is, replacing this "if" with

if (!s->current) {
p = get_pending_req(s);
if (p) {
lsi_reselect(s, p);
}
}

instead of calling lsi_wait_reselect?

Thanks,

Paolo

> +lsi_wait_reselect(s);
> +}
>  break;
>  case 2: /* Wait Reselect */
>  if (!lsi_irq_on_rsl(s)) {
> 

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Philippe Mathieu-Daudé]

On 8/11/18 19:00, Peter Maydell wrote:

On 8 November 2018 at 17:41, Philippe Mathieu-Daudé  wrote:

On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell  wrote:

On 8 November 2018 at 17:17, Eduardo Habkost  wrote:

On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:

Reported-by: LGTM code review
Signed-off-by: Philippe Mathieu-Daudé 


Queueing for 3.2, thanks.


Next release after 3.1 will be 4.0, by the way -- we're moving
to "bump major version every year".


So major versions help to remember the 12th anniversary of QEMU?

Why not start at 19.0?


We had this discussion when we agreed on the new version policy;
I don't want to reopen it.


Sorry I missed it, I'll look in the archives.

Anyway there are no information about merge window in the wiki.
When I started it was not easy to understand it and why patches sent 
when 'merge window is close' fall under the crap and are unnoticed, thus 
it is better to wait before to send, or resend them.
I'd appreciate if someone add this (Contribute/SubmitAPatch is probably 
the page to modify), also describing than some maintainers agree to take 
patches in their -next queue, even when merge window is closed

Also you could add the expected dates for the next releases there.

Regards,

Phil.

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Peter Maydell]

On 8 November 2018 at 17:41, Philippe Mathieu-Daudé  wrote:
> On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell  wrote:
>> On 8 November 2018 at 17:17, Eduardo Habkost  wrote:
>> > On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>> >> Reported-by: LGTM code review
>> >> Signed-off-by: Philippe Mathieu-Daudé 
>> >
>> > Queueing for 3.2, thanks.
>>
>> Next release after 3.1 will be 4.0, by the way -- we're moving
>> to "bump major version every year".
>
> So major versions help to remember the 12th anniversary of QEMU?
>
> Why not start at 19.0?

We had this discussion when we agreed on the new version policy;
I don't want to reopen it.

thanks
-- PMM

Re: [Qemu-devel] QEMU and Kconfig

[Paolo Bonzini]

On 08/11/2018 18:14, Eduardo Habkost wrote:
> Keeping in mind that I might be talking about extra challenges we
> won't address right now (no cart before the horse), I have new
> questions:
> 
> Why you say backends are not a target configuration and
> accelerators are?  What's the definition of "target
> configuration"?

Something that affects the way

> Are we explicitly restricting the scope of this work to
> enabling/disabling device emulation code right now?  Why?  Why
> wouldn't we use kconfig to enable/disable simple backends with no
> host dependency like SLIRP?

I think it would be more confusing if some backends were to use kconfig
and some wouldn't.  We could certainly add something like

config VHOST_NET
depends on HOST_LINUX
default y

config SPICE
depends on HAVE_SPICE_SERVER
default Y

etc. but I think we agree it's more of a long term idea.

> Don't we want to make backends configurable per binary, too?
> e.g.: I would expect the default configuration for a NEMU-like
> binary to disable many backends.

Sure, we could do that.  However, right now you cannot have multiple
binaries for a single target, so you couldn't have one single build
include both a "full-blown" and a "reduced" x86 target.  Therefore,
including e.g. SLIRP in qemu-system-arm but not in qemu-system-x86_64
does not seem too interesting to me.  It would be different if you could
build qemu-system-arm, qemu-system-x86_64, qemu-system-x86_64-lite, etc.

Paolo

> 
>> It would surely be possible for configure to call into minikconf to
>> parse a configuration file and apply dependencies (do we actually have
>> dependencies across configure options?) or something like that, but
>> let's not put the cart before the horse...
> 
> Agreed.
> 

Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom

[Peter Maydell]

On 8 November 2018 at 17:58, Corey Minyard  wrote:
> On 11/8/18 8:08 AM, Peter Maydell wrote:
>> This doesn't do anything for migration of the actual data contents.
>> The current users of this device (hw/arm/aspeed.c and the
>> smbus_eeprom_init() function) doesn't do anything
>> to migrate the contents. For that matter, "user of the device
>> passes a pointer to a random lump of memory via a device property"
>> is a bit funky as an interface. The device should allocate its
>> own memory and migrate it, and the user should just pass the
>> initial required contents (default being "zero-initialize",
>> which is what everybody except the mips_fulong2e, mips_malta
>> and sam460ex want).

> I debated on this, and it depends on what the eeprom is used for.  If
> it's a DRAM eeprom, it shouldn't need to be transferred.

It's guest-visible data; the guest can write it and read it back.
So it needs to be migrated. Otherwise behaviour after migration
will not be the same as if the guest had never migrated.

>> Does this also break migration from an old QEMU to a new one?
>> (For Aspeed that's probably ok, but we should flag it up in the
>> commit message if so. x86 uses need care...)
>>
> There is no transfer before, so I don't see why it would break anything.
> Am I missing something?

I forget what the behaviour is where the source QEMU didn't
have a vmstate at all but the destination QEMU does expect
one. David can remind me...

thanks
- PMM

[Qemu-devel] [PATCH v3 5/5] target/arm: Convert t32ee from feature bit to isar3 test

[Richard Henderson]

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h | 6 +-
 linux-user/elfload.c | 2 +-
 target/arm/cpu.c | 4 
 target/arm/helper.c  | 2 +-
 target/arm/kvm32.c   | 3 ---
 target/arm/machine.c | 3 +--
 6 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index b5eff79f73..5c2c77c31d 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1575,7 +1575,6 @@ enum arm_features {
 ARM_FEATURE_NEON,
 ARM_FEATURE_M, /* Microcontroller profile.  */
 ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling.  */
-ARM_FEATURE_THUMB2EE,
 ARM_FEATURE_V7MP,/* v7 Multiprocessing Extensions */
 ARM_FEATURE_V7VE, /* v7 Virtualization Extensions (non-EL2 parts) */
 ARM_FEATURE_V4T,
@@ -3172,6 +3171,11 @@ static inline bool isar_feature_jazelle(const 
ARMISARegisters *id)
 return FIELD_EX32(id->id_isar1, ID_ISAR1, JAZELLE) != 0;
 }
 
+static inline bool isar_feature_t32ee(const ARMISARegisters *id)
+{
+return FIELD_EX32(id->id_isar3, ID_ISAR3, T32EE) != 0;
+}
+
 static inline bool isar_feature_aa32_aes(const ARMISARegisters *id)
 {
 return FIELD_EX32(id->id_isar5, ID_ISAR5, AES) != 0;
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 5bccd2e243..a3503c83c9 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -466,7 +466,7 @@ static uint32_t get_elf_hwcap(void)
 GET_FEATURE(ARM_FEATURE_V5, ARM_HWCAP_ARM_EDSP);
 GET_FEATURE(ARM_FEATURE_VFP, ARM_HWCAP_ARM_VFP);
 GET_FEATURE(ARM_FEATURE_IWMMXT, ARM_HWCAP_ARM_IWMMXT);
-GET_FEATURE(ARM_FEATURE_THUMB2EE, ARM_HWCAP_ARM_THUMBEE);
+GET_FEATURE_ID(t32ee, ARM_HWCAP_ARM_THUMBEE);
 GET_FEATURE(ARM_FEATURE_NEON, ARM_HWCAP_ARM_NEON);
 GET_FEATURE(ARM_FEATURE_VFP3, ARM_HWCAP_ARM_VFPv3);
 GET_FEATURE(ARM_FEATURE_V6K, ARM_HWCAP_ARM_TLS);
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 784a4c2dfc..d4dc0bc225 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1451,7 +1451,6 @@ static void cortex_a8_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V7);
 set_feature(>env, ARM_FEATURE_VFP3);
 set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
 set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
 set_feature(>env, ARM_FEATURE_EL3);
 cpu->midr = 0x410fc080;
@@ -1520,7 +1519,6 @@ static void cortex_a9_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_VFP3);
 set_feature(>env, ARM_FEATURE_VFP_FP16);
 set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
 set_feature(>env, ARM_FEATURE_EL3);
 /* Note that A9 supports the MP extensions even for
  * A9UP and single-core A9MP (which are both different
@@ -1583,7 +1581,6 @@ static void cortex_a7_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V7VE);
 set_feature(>env, ARM_FEATURE_VFP4);
 set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
 set_feature(>env, ARM_FEATURE_GENERIC_TIMER);
 set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
 set_feature(>env, ARM_FEATURE_CBAR_RO);
@@ -1629,7 +1626,6 @@ static void cortex_a15_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V7VE);
 set_feature(>env, ARM_FEATURE_VFP4);
 set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
 set_feature(>env, ARM_FEATURE_GENERIC_TIMER);
 set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
 set_feature(>env, ARM_FEATURE_CBAR_RO);
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 96301930cc..e28770833a 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -5457,7 +5457,7 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 define_arm_cp_regs(cpu, vmsa_pmsa_cp_reginfo);
 define_arm_cp_regs(cpu, vmsa_cp_reginfo);
 }
-if (arm_feature(env, ARM_FEATURE_THUMB2EE)) {
+if (cpu_isar_feature(t32ee, cpu)) {
 define_arm_cp_regs(cpu, t2ee_cp_reginfo);
 }
 if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index 9ededa3c73..8b2c9b3075 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -115,9 +115,6 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
 set_feature(, ARM_FEATURE_VFP3);
 set_feature(, ARM_FEATURE_GENERIC_TIMER);
 
-if (extract32(id_pfr0, 12, 4) == 1) {
-set_feature(, ARM_FEATURE_THUMB2EE);
-}
 if (extract32(ahcf->isar.mvfr1, 20, 4) == 1) {
 set_feature(, ARM_FEATURE_VFP_FP16);
 }
diff --git a/target/arm/machine.c b/target/arm/machine.c
index 239fe4e84d..07f904709a 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -321,9 +321,8 @@ static const VMStateDescription vmstate_m = {
 static bool thumb2ee_needed(void *opaque)
 {
 ARMCPU *cpu = opaque;
-CPUARMState *env = >env;
 
-return arm_feature(env, ARM_FEATURE_THUMB2EE);
+return cpu_isar_feature(t32ee, cpu);
 }
 
 static const 

[Qemu-devel] [PATCH v3 2/5] target/arm: Fill in ARMISARegisters for kvm64

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/kvm64.c | 90 --
 1 file changed, 88 insertions(+), 2 deletions(-)

diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 5de8ff0ac5..e1128b94b2 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -443,17 +443,40 @@ static inline void unset_feature(uint64_t *features, int 
feature)
 *features &= ~(1ULL << feature);
 }
 
+static int read_sys_reg32(int fd, uint32_t *pret, uint64_t id)
+{
+uint64_t ret;
+struct kvm_one_reg idreg = { .id = id, .addr = (uintptr_t) };
+int err;
+
+assert((id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U64);
+err = ioctl(fd, KVM_GET_ONE_REG, );
+if (err < 0) {
+return -1;
+}
+*pret = ret;
+return 0;
+}
+
+static int read_sys_reg64(int fd, uint64_t *pret, uint64_t id)
+{
+struct kvm_one_reg idreg = { .id = id, .addr = (uintptr_t)pret };
+
+assert((id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U64);
+return ioctl(fd, KVM_GET_ONE_REG, );
+}
+
 bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
 {
 /* Identify the feature bits corresponding to the host CPU, and
  * fill out the ARMHostCPUClass fields accordingly. To do this
  * we have to create a scratch VM, create a single CPU inside it,
  * and then query that CPU for the relevant ID registers.
- * For AArch64 we currently don't care about ID registers at
- * all; we just want to know the CPU type.
  */
 int fdarray[3];
 uint64_t features = 0;
+int err;
+
 /* Old kernels may not know about the PREFERRED_TARGET ioctl: however
  * we know these will only support creating one kind of guest CPU,
  * which is its preferred CPU type. Fortunately these old kernels
@@ -474,8 +497,71 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures 
*ahcf)
 ahcf->target = init.target;
 ahcf->dtb_compatible = "arm,arm-v8";
 
+err = read_sys_reg64(fdarray[2], >isar.id_aa64pfr0,
+ ARM64_SYS_REG(3, 0, 0, 4, 0));
+if (unlikely(err < 0)) {
+/*
+ * Before v4.15, the kernel only exposed a limited number of system
+ * registers, not including any of the interesting AArch64 ID regs.
+ * For the most part we could leave these fields as zero with minimal
+ * effect, since this does not affect the values seen by the guest.
+ *
+ * However, it could cause problems down the line for QEMU,
+ * so provide a minimal v8.0 default.
+ *
+ * ??? Could read MIDR and use knowledge from cpu64.c.
+ * ??? Could map a page of memory into our temp guest and
+ * run the tiniest of hand-crafted kernels to extract
+ * the values seen by the guest.
+ * ??? Either of these sounds like too much effort just
+ * to work around running a modern host kernel.
+ */
+ahcf->isar.id_aa64pfr0 = 0x0011; /* EL1&0, AArch64 only */
+err = 0;
+} else {
+err |= read_sys_reg64(fdarray[2], >isar.id_aa64pfr1,
+  ARM64_SYS_REG(3, 0, 0, 4, 1));
+err |= read_sys_reg64(fdarray[2], >isar.id_aa64isar0,
+  ARM64_SYS_REG(3, 0, 0, 6, 0));
+err |= read_sys_reg64(fdarray[2], >isar.id_aa64isar1,
+  ARM64_SYS_REG(3, 0, 0, 6, 1));
+
+/*
+ * Note that if AArch32 support is not present in the host,
+ * the AArch32 sysregs are present to be read, but will
+ * return UNKNOWN values.  This is neither better nor worse
+ * than skipping the reads and leaving 0, as we must avoid
+ * considering the values in every case.
+ */
+err |= read_sys_reg32(fdarray[2], >isar.id_isar0,
+  ARM64_SYS_REG(3, 0, 0, 2, 0));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar1,
+  ARM64_SYS_REG(3, 0, 0, 2, 1));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar2,
+  ARM64_SYS_REG(3, 0, 0, 2, 2));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar3,
+  ARM64_SYS_REG(3, 0, 0, 2, 3));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar4,
+  ARM64_SYS_REG(3, 0, 0, 2, 4));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar5,
+  ARM64_SYS_REG(3, 0, 0, 2, 5));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar6,
+  ARM64_SYS_REG(3, 0, 0, 2, 7));
+
+err |= read_sys_reg32(fdarray[2], >isar.mvfr0,
+  ARM64_SYS_REG(3, 0, 0, 3, 0));
+err |= read_sys_reg32(fdarray[2], >isar.mvfr1,
+  ARM64_SYS_REG(3, 0, 0, 3, 1));
+err |= read_sys_reg32(fdarray[2], >isar.mvfr2,
+  ARM64_SYS_REG(3, 0, 0, 3, 2));
+}
+
 

Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom

[Corey Minyard]

On 11/8/18 8:08 AM, Peter Maydell wrote:

On 7 November 2018 at 15:54,   wrote:

From: Corey Minyard 

This was if the eeprom is accessed during a state transfer, the
transfer will be reliable.

Signed-off-by: Corey Minyard 
Cc: Paolo Bonzini 
Cc: Michael S. Tsirkin 
Cc: Dr. David Alan Gilbert 
---
  hw/i2c/smbus_eeprom.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
index f18aa3de35..d4430b0c5d 100644
--- a/hw/i2c/smbus_eeprom.c
+++ b/hw/i2c/smbus_eeprom.c
@@ -29,6 +29,8 @@

  //#define DEBUG

+#define TYPE_SMBUS_EEPROM_DEVICE "smbus-eeprom"

The part of this patch which is adding the usual QOM
macros is good, but we should provide also the
cast-macro (the one that's an OBJECT_CHECK(...)).
And this should be separate from adding the vmstate.


+
  typedef struct SMBusEEPROMDevice {
  SMBusDevice smbusdev;
  void *data;
@@ -97,6 +99,17 @@ static uint8_t eeprom_read_data(SMBusDevice *dev, uint8_t 
cmd, int n)
  return eeprom_receive_byte(dev);
  }

+static const VMStateDescription vmstate_smbus_eeprom = {
+.name = TYPE_SMBUS_EEPROM_DEVICE,

Generally we don't use the TYPE_FOO constant for the vmstate
name, because we can usually freely change the TYPE_FOO string without
breaking back-compat, but we can't change the vmstate name.
So we decouple them to make it more obvious when a change might
be changing the migration on-the-wire format.



Ok, I've updated the code to use the standard type name and cast method
(in a separate patch) and I fixed the vmstate name.  It is better, you are
right.



+.version_id = 1,
+.minimum_version_id = 1,
+.fields  = (VMStateField[]) {
+VMSTATE_SMBUS_DEVICE(smbusdev, SMBusEEPROMDevice),
+VMSTATE_UINT8(offset, SMBusEEPROMDevice),
+VMSTATE_END_OF_LIST()
+}
+};

This doesn't do anything for migration of the actual data contents.
The current users of this device (hw/arm/aspeed.c and the
smbus_eeprom_init() function) doesn't do anything
to migrate the contents. For that matter, "user of the device
passes a pointer to a random lump of memory via a device property"
is a bit funky as an interface. The device should allocate its
own memory and migrate it, and the user should just pass the
initial required contents (default being "zero-initialize",
which is what everybody except the mips_fulong2e, mips_malta
and sam460ex want).



I debated on this, and it depends on what the eeprom is used for.  If
it's a DRAM eeprom, it shouldn't need to be transferred.
If it's something where the host stores data for later use, you do.
Since it wasn't being cloned before, it probably won't matter now.

But even in the DRAM eeprom case, it shouldn't matter if it gets
transferred.  So it's probably safe to just transfer it.  Easy enough
to add.




Does this also break migration from an old QEMU to a new one?
(For Aspeed that's probably ok, but we should flag it up in the
commit message if so. x86 uses need care...)


There is no transfer before, so I don't see why it would break anything.
Am I missing something?

-corey


+
  static void smbus_eeprom_realize(DeviceState *dev, Error **errp)
  {
  SMBusEEPROMDevice *eeprom = (SMBusEEPROMDevice *)dev;
@@ -121,12 +134,13 @@ static void smbus_eeprom_class_initfn(ObjectClass *klass, 
void *data)
  sc->write_data = eeprom_write_data;
  sc->read_data = eeprom_read_data;
  dc->props = smbus_eeprom_properties;
+dc->vmsd = _smbus_eeprom;
  /* Reason: pointer property "data" */
  dc->user_creatable = false;
  }

  static const TypeInfo smbus_eeprom_info = {
-.name  = "smbus-eeprom",
+.name  = TYPE_SMBUS_EEPROM_DEVICE,
  .parent= TYPE_SMBUS_DEVICE,
  .instance_size = sizeof(SMBusEEPROMDevice),
  .class_init= smbus_eeprom_class_initfn,
--
2.17.1

thanks
-- PMM

[Qemu-devel] [PATCH v3 3/5] target/arm: Introduce read_sys_reg32 for kvm32

[Richard Henderson]

Assert that the value to be written is the correct size.
No change in functionality here, just mirroring the same
function from kvm64.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/kvm32.c | 41 -
 1 file changed, 16 insertions(+), 25 deletions(-)

diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index 0f1e94c7b5..de573f9aa8 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -28,6 +28,14 @@ static inline void set_feature(uint64_t *features, int 
feature)
 *features |= 1ULL << feature;
 }
 
+static int read_sys_reg32(int fd, uint32_t *pret, uint64_t id)
+{
+struct kvm_one_reg idreg = { .id = id, .addr = (uintptr_t)pret };
+
+assert((id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U32);
+return ioctl(fd, KVM_GET_ONE_REG, );
+}
+
 bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
 {
 /* Identify the feature bits corresponding to the host CPU, and
@@ -35,9 +43,10 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
  * we have to create a scratch VM, create a single CPU inside it,
  * and then query that CPU for the relevant ID registers.
  */
-int i, ret, fdarray[3];
+int err = 0, fdarray[3];
 uint32_t midr, id_pfr0, mvfr1;
 uint64_t features = 0;
+
 /* Old kernels may not know about the PREFERRED_TARGET ioctl: however
  * we know these will only support creating one kind of guest CPU,
  * which is its preferred CPU type.
@@ -47,23 +56,6 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
 QEMU_KVM_ARM_TARGET_NONE
 };
 struct kvm_vcpu_init init;
-struct kvm_one_reg idregs[] = {
-{
-.id = KVM_REG_ARM | KVM_REG_SIZE_U32
-| ENCODE_CP_REG(15, 0, 0, 0, 0, 0, 0),
-.addr = (uintptr_t),
-},
-{
-.id = KVM_REG_ARM | KVM_REG_SIZE_U32
-| ENCODE_CP_REG(15, 0, 0, 0, 1, 0, 0),
-.addr = (uintptr_t)_pfr0,
-},
-{
-.id = KVM_REG_ARM | KVM_REG_SIZE_U32
-| KVM_REG_ARM_VFP | KVM_REG_ARM_VFP_MVFR1,
-.addr = (uintptr_t),
-},
-};
 
 if (!kvm_arm_create_scratch_host_vcpu(cpus_to_try, fdarray, )) {
 return false;
@@ -77,16 +69,15 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
  */
 ahcf->dtb_compatible = "arm,arm-v7";
 
-for (i = 0; i < ARRAY_SIZE(idregs); i++) {
-ret = ioctl(fdarray[2], KVM_GET_ONE_REG, [i]);
-if (ret) {
-break;
-}
-}
+err |= read_sys_reg32(fdarray[2], , ARM_CP15_REG32(0, 0, 0, 0));
+err |= read_sys_reg32(fdarray[2], _pfr0, ARM_CP15_REG32(0, 0, 1, 0));
+err |= read_sys_reg32(fdarray[2], ,
+  KVM_REG_ARM | KVM_REG_SIZE_U32 |
+  KVM_REG_ARM_VFP | KVM_REG_ARM_VFP_MVFR1);
 
 kvm_arm_destroy_scratch_host_vcpu(fdarray);
 
-if (ret) {
+if (err < 0) {
 return false;
 }
 
-- 
2.17.2

[Qemu-devel] [PATCH v3 1/5] target/arm: Install ARMISARegisters from kvm host

[Richard Henderson]

The ID registers are replacing (some of) the feature bits.
We need (some of) these values to determine the set of data
to be handled during migration.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/kvm_arm.h | 1 +
 target/arm/kvm.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
index 21c0129da2..6393455b1d 100644
--- a/target/arm/kvm_arm.h
+++ b/target/arm/kvm_arm.h
@@ -183,6 +183,7 @@ void kvm_arm_destroy_scratch_host_vcpu(int *fdarray);
  * by asking the host kernel)
  */
 typedef struct ARMHostCPUFeatures {
+ARMISARegisters isar;
 uint64_t features;
 uint32_t target;
 const char *dtb_compatible;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 09a86e2820..44dd0ce6ce 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -158,6 +158,7 @@ void kvm_arm_set_cpu_features_from_host(ARMCPU *cpu)
 
 cpu->kvm_target = arm_host_cpu_features.target;
 cpu->dtb_compatible = arm_host_cpu_features.dtb_compatible;
+cpu->isar = arm_host_cpu_features.isar;
 env->features = arm_host_cpu_features.features;
 }
 
-- 
2.17.2

[Qemu-devel] [PATCH v3 0/5] target/arm: KVM vs ARMISARegisters

[Richard Henderson]

My previous patch set for replacing feature bits with id registers
failed to consider that these id registers are beginning to control
migration, and thus we must fill them in for KVM as well.

Thus, we want to initialize these values within CPU from the host.

Finally, re-send the T32EE conversion patch, fixing the build
failure on an arm32 host in kvm32.c.

Changes, v2->v3:
  * Work around sysreg read failures from old host kernels.

Changes, v1->v2:
  * Remove assert that AArch32 sysreg <= UINT32_MAX.
  * Remove unused local variable.
  * Add commentary for AArch32 sysregs vs missing AArch32 support.


r~


Richard Henderson (5):
  target/arm: Install ARMISARegisters from kvm host
  target/arm: Fill in ARMISARegisters for kvm64
  target/arm: Introduce read_sys_reg32 for kvm32
  target/arm: Fill in ARMISARegisters for kvm32
  target/arm: Convert t32ee from feature bit to isar3 test

 target/arm/cpu.h |  6 ++-
 target/arm/kvm_arm.h |  1 +
 linux-user/elfload.c |  2 +-
 target/arm/cpu.c |  4 --
 target/arm/helper.c  |  2 +-
 target/arm/kvm.c |  1 +
 target/arm/kvm32.c   | 75 
 target/arm/kvm64.c   | 90 +++-
 target/arm/machine.c |  3 +-
 9 files changed, 141 insertions(+), 43 deletions(-)

-- 
2.17.2

[Qemu-devel] [PATCH v3 4/5] target/arm: Fill in ARMISARegisters for kvm32

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/kvm32.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index de573f9aa8..9ededa3c73 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -44,7 +44,7 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
  * and then query that CPU for the relevant ID registers.
  */
 int err = 0, fdarray[3];
-uint32_t midr, id_pfr0, mvfr1;
+uint32_t midr, id_pfr0;
 uint64_t features = 0;
 
 /* Old kernels may not know about the PREFERRED_TARGET ioctl: however
@@ -71,9 +71,32 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
 
 err |= read_sys_reg32(fdarray[2], , ARM_CP15_REG32(0, 0, 0, 0));
 err |= read_sys_reg32(fdarray[2], _pfr0, ARM_CP15_REG32(0, 0, 1, 0));
-err |= read_sys_reg32(fdarray[2], ,
+
+err |= read_sys_reg32(fdarray[2], >isar.id_isar0,
+  ARM_CP15_REG32(0, 0, 2, 0));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar1,
+  ARM_CP15_REG32(0, 0, 2, 1));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar2,
+  ARM_CP15_REG32(0, 0, 2, 2));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar3,
+  ARM_CP15_REG32(0, 0, 2, 3));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar4,
+  ARM_CP15_REG32(0, 0, 2, 4));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar5,
+  ARM_CP15_REG32(0, 0, 2, 5));
+err |= read_sys_reg32(fdarray[2], >isar.id_isar6,
+  ARM_CP15_REG32(0, 0, 2, 7));
+
+err |= read_sys_reg32(fdarray[2], >isar.mvfr0,
+  KVM_REG_ARM | KVM_REG_SIZE_U32 |
+  KVM_REG_ARM_VFP | KVM_REG_ARM_VFP_MVFR0);
+err |= read_sys_reg32(fdarray[2], >isar.mvfr1,
   KVM_REG_ARM | KVM_REG_SIZE_U32 |
   KVM_REG_ARM_VFP | KVM_REG_ARM_VFP_MVFR1);
+/*
+ * FIXME: There is not yet a way to read MVFR2.
+ * Fortunately there is not yet anything in there that affects migration.
+ */
 
 kvm_arm_destroy_scratch_host_vcpu(fdarray);
 
@@ -95,13 +118,13 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures 
*ahcf)
 if (extract32(id_pfr0, 12, 4) == 1) {
 set_feature(, ARM_FEATURE_THUMB2EE);
 }
-if (extract32(mvfr1, 20, 4) == 1) {
+if (extract32(ahcf->isar.mvfr1, 20, 4) == 1) {
 set_feature(, ARM_FEATURE_VFP_FP16);
 }
-if (extract32(mvfr1, 12, 4) == 1) {
+if (extract32(ahcf->isar.mvfr1, 12, 4) == 1) {
 set_feature(, ARM_FEATURE_NEON);
 }
-if (extract32(mvfr1, 28, 4) == 1) {
+if (extract32(ahcf->isar.mvfr1, 28, 4) == 1) {
 /* FMAC support implies VFPv4 */
 set_feature(, ARM_FEATURE_VFP4);
 }
-- 
2.17.2

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Philippe Mathieu-Daudé]

On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell  wrote:
> On 8 November 2018 at 17:17, Eduardo Habkost  wrote:
> > On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
> >> Reported-by: LGTM code review
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >
> > Queueing for 3.2, thanks.
>
> Next release after 3.1 will be 4.0, by the way -- we're moving
> to "bump major version every year".

So major versions help to remember the 12th anniversary of QEMU?

Why not start at 19.0?

Re: [Qemu-devel] [Qemu-block] [PATCH] tests: Fix Python 3 detection on older GNU make versions

[Cleber Rosa]

On 11/8/18 11:51 AM, Eduardo Habkost wrote:

> I'm not sure I agree with the "is an important thing to keep
> track of" part.  I don't think we'll have any need to keep track
> of the Python version in shell script or makefiles after we start
> requiring Python 3.
> 

Well, "Python 3" is not a uniform thing.  There are many changes across
the 3.x spectrum that can bite you.  I'm speaking out of the experience
with Avocado, that supports Python 3.4, 3.5 and 3.6 (and that reminds me
we should add tests for 3.7).

> Extra cleanups (like moving version checks to ./configure) are
> still welcome, but keep in mind that this will probably be thrown
> away once we drop Python 2 support.
> 

I don't think it should.  Let me give the example of a "Python 3.0" job
on Travis, related to the following snippet:

# Python builds
- env: CONFIG="--target-list=x86_64-softmmu"
  python:
- "3.0"

If you look at https://travis-ci.org/clebergnu/qemu/jobs/452033247#L983
you'll see that the intended goal was missed.  That has to do with how
Travis makes the requested Python version available, and it was only
obvious because this branch prints the Python version used.

Developers writing Python code, for instance tests, may assume a given
API that doesn't exist or behave like they expect, and not knowing the
Python version used on a remote environment makes debugging extra hard.

- Cleber.

Re: [Qemu-devel] [PATCH v2 1/6] target/arm64: properly handle DBGVR RESS bits

[Alex Bennée]

Richard Henderson  writes:

> On 11/8/18 5:33 PM, Alex Bennée wrote:
>> -.bvr = addr
>> +.bvr = sextract64(addr, 52, 53)
>
> I think you meant sextract64(addr, 0, 53).
> What you wrote *should* have asserted, since 52+53 > 64.

Dam, I did fix that. I must have failed to propagate the fix from where
I was hacking :-/

>
>
> r~


--
Alex Bennée

Re: [Qemu-devel] [PATCH 0/2] target/riscv: Bugfixes found in decodetree conversion

[Bastian Koppelmann]

On 11/8/18 4:53 PM, Richard Henderson wrote:

On 11/8/18 1:06 PM, Bastian Koppelmann wrote:

while going through the reviews of the riscv-decodetree patches, two bugs came
up that I fix here. There is one more problem [1] mentioned by Richard but
I don't have the time to investigate it further.

[1] https://patchwork.kernel.org/patch/10650293/

That one's not a bug, but an optimization.

The other bug mentioned is shrw and shaw not sign-extending the result.



That was a bug I introduced during the conversion to decodetree.


Cheers,

Bastian

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Peter Maydell]

On 8 November 2018 at 17:17, Eduardo Habkost  wrote:
> On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>> Reported-by: LGTM code review
>> Signed-off-by: Philippe Mathieu-Daudé 
>
> Queueing for 3.2, thanks.

Next release after 3.1 will be 4.0, by the way -- we're moving
to "bump major version every year".

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 6/6] arm: fix aa64_generate_debug_exceptions to work with EL2

[Richard Henderson]

On 11/8/18 5:33 PM, Alex Bennée wrote:
> The test was incomplete and incorrectly caused debug exceptions to be
> generated when returning to EL2 after a failed attempt to single-step
> an EL1 instruction. Fix this while cleaning up the function a little.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/cpu.h | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 1efff21a18..a6d8eb14f6 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2764,23 +2764,33 @@ static inline bool arm_v7m_csselr_razwi(ARMCPU *cpu)
>  return (cpu->clidr & R_V7M_CLIDR_CTYPE_ALL_MASK) != 0;
>  }
>  
> +/* See AArch64.GenerateDebugExceptionsFrom() in ARM ARM pseudocode */
>  static inline bool aa64_generate_debug_exceptions(CPUARMState *env)
>  {
> +int cur_el = arm_current_el(env);
> +int debug_el;
> +
>  if (arm_is_secure(env)) {
>  /* MDCR_EL3.SDD disables debug events from Secure state */
>  if (extract32(env->cp15.mdcr_el3, 16, 1) != 0
> -|| arm_current_el(env) == 3) {
> +|| cur_el == 3) {

Hmm.  Perhaps better as

if (cur_el == 3) {
return false;
}
/* MDCR_EL3.SDD disables... */
if (arm_is_secure_below_el3(env)
&& extract32(env->cp15.mdcr_el3, 16, 1)) {
return false;
}

and of course more symbols would be nice, but it's not wrong as-is.


r~

Re: [Qemu-devel] [PATCH] scripts: Remove unused python imports

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
> Reported-by: LGTM code review
> Signed-off-by: Philippe Mathieu-Daudé 

Queueing for 3.2, thanks.

-- 
Eduardo

Re: [Qemu-devel] QEMU and Kconfig

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 02:42:19PM +0100, Paolo Bonzini wrote:
> On 08/11/2018 14:06, Eduardo Habkost wrote:
> > On Thu, Nov 08, 2018 at 10:55:21AM +0100, Paolo Bonzini wrote:
> >> On 07/11/2018 20:30, Thomas Huth wrote:
> >>> On 2018-11-07 20:24, Eduardo Habkost wrote:
>  On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote:
> > On 07/11/2018 16:41, Samuel Ortiz wrote:
> >> - The Kconfig parser would be used to generate the equivalent of what 
> >> we
> >>   currently have under default-configs/
> >>>
> >>> I think we would still have something like default-configs - but there
> >>> would only be the bare minimum config switches in there, the rest would
> >>> be pulled in by dependencies.
> >>
> >> Yes, in theory default-configs would end up empty, except for possibly
> >> some commented lines to show the "default y" symbols for the target.
> >>
> >>> We could then also even have multiple config directories:
> >>>
> >>> ./configs
> >>>  +---/default-softmmu
> >>>  +---/default-linux-user
> >>>  +---/nemu (or lean-kvm or something similar)
> >>>  +...
> >>>
> >>> ... just my 0.02 €, feel free to ignore that idea ;-)
> >>
> >> Yup, one can also think of a configure option like "./configure
> >> --with-device-config=configs/nemu/" to pick up the alternative
> >> configurations.
> >>
>  Also, I would like to eventually replace many ./configure options
>  with options read from a build configuration file.
> 
>  Distributions often have huge ./configure command lines in their
>  QEMU packages, and they could be replaced by simple build
>  configuration files.
> 
>  Having a mode that requires all build options to be specified
>  explicitly (instead of silently picking a default) would be
>  useful for distributions, too.
> >>>
> >>> I think we should maybe not mix host configuration (via ./configure) and
> >>> the target configuration (via kconfig), should we?
> >>
> >> Yeah, the configure command line is a different story.  If there are
> >> suggestion on how to improve it, great, but let's not conflate it with
> >> Kconfig.
> > 
> > I believe we have many ./configure options that are supposed to
> > be target configuration.  e.g.: --enable-slirp, --eanble-kvm,
> > --enable-xen, etc.
> 
> SLIRP is not a target configuration, it's a backend like most other
> configure command line options.  The accelerators are but (except for
> TCG of course) they also depend on the host OS and architecture, which
> makes them a bit more complicated than default-configs/ symbols.  There
> are also things like --enable-vhost-user which affect the creation of
> both devices (e.g. vhost-user-scsi-pci) and backends (e.g. the
> vhost-user-net backend, which uses a "regular" virtio-net-pci device).
> 

Keeping in mind that I might be talking about extra challenges we
won't address right now (no cart before the horse), I have new
questions:

Why you say backends are not a target configuration and
accelerators are?  What's the definition of "target
configuration"?

Are we explicitly restricting the scope of this work to
enabling/disabling device emulation code right now?  Why?  Why
wouldn't we use kconfig to enable/disable simple backends with no
host dependency like SLIRP?

Don't we want to make backends configurable per binary, too?
e.g.: I would expect the default configuration for a NEMU-like
binary to disable many backends.


> It would surely be possible for configure to call into minikconf to
> parse a configuration file and apply dependencies (do we actually have
> dependencies across configure options?) or something like that, but
> let's not put the cart before the horse...

Agreed.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 5/6] arm: use symbolic MDCR_TDE in arm_debug_target_el

[Richard Henderson]

On 11/8/18 5:33 PM, Alex Bennée wrote:
> We already have this symbol defined so lets use it.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/cpu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 4/6] tests/guest-debug: fix scoping of failcount

[Richard Henderson]

On 11/8/18 5:33 PM, Alex Bennée wrote:
> @@ -16,6 +16,7 @@ def report(cond, msg):
>  print ("PASS: %s" % (msg))
>  else:
>  print ("FAIL: %s" % (msg))
> +global failcount
>  failcount += 1

Do we usually prefer such declarations at the start of the function?
Anyway,

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 3/6] target/arm64: kvm debug set target_el when passing exception to guest

[Richard Henderson]

On 11/8/18 5:33 PM, Alex Bennée wrote:
> When we are debugging the guest all exceptions come our way but might
> be for the guest's own debug exceptions. We use the ->do_interrupt()
> infrastructure to inject the exception into the guest. However, we are
> missing a full setup of the exception structure, causing an assert
> later down the line.
> 
> Signed-off-by: Alex Bennée 
> Reviewed-by: Peter Maydell 

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 2/6] target/arm64: hold BQL when calling do_interrupt()

[Richard Henderson]

On 11/8/18 5:33 PM, Alex Bennée wrote:
> Fix the assertion failure when running interrupts.
> 
> Signed-off-by: Alex Bennée 
> Reviewed-by: Peter Maydell 
> ---
>  target/arm/kvm64.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 1/6] target/arm64: properly handle DBGVR RESS bits

[Richard Henderson]

On 11/8/18 5:33 PM, Alex Bennée wrote:
> -.bvr = addr
> +.bvr = sextract64(addr, 52, 53)

I think you meant sextract64(addr, 0, 53).
What you wrote *should* have asserted, since 52+53 > 64.


r~

[Qemu-devel] [Bug 1734810] Re: Windows guest virtual PC running abnormally slow

[Thomas Huth]

Jeb, if you open a bug against QEMU here, we expect some information how
QEMU is run. If you only interact with Gnome Boxes, then please only
open a bug against Boxes - best in their Bug tracker here:
https://bugzilla.gnome.org/ ... I guess nobody of the Boxes project is
checking Launchpad, so reporting Boxes bugs here in Launchpad does not
make much sense.

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

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

Title:
  Windows guest virtual PC running abnormally slow

Status in Boxes:
  New
Status in KVM:
  New
Status in libvirt:
  New
Status in QEMU:
  Invalid
Status in spice related packages:
  Confirmed
Status in gnome-boxes package in Ubuntu:
  Confirmed

Bug description:
  Guest systems running Windows 10 in a virtualized environment run
  unacceptably slow, with no option in Boxes to offer the virtual
  machine more (or less) cores from my physical CPU.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-boxes 3.26.1-1
  ProcVersionSignature: Ubuntu 4.13.0-17.20-lowlatency 4.13.8
  Uname: Linux 4.13.0-17-lowlatency x86_64
  ApportVersion: 2.20.7-0ubuntu3.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Nov 28 00:37:11 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-boxes
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-boxes/+bug/1734810/+subscriptions

[Qemu-devel] [Bug 1734810] Re: Windows guest virtual PC running abnormally slow

[Thomas Huth]

And for the CLI parameters, you could run this in a console window for
example, after starting your guest:

ps aux | grep qemu

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

Title:
  Windows guest virtual PC running abnormally slow

Status in Boxes:
  New
Status in KVM:
  New
Status in libvirt:
  New
Status in QEMU:
  Invalid
Status in spice related packages:
  Confirmed
Status in gnome-boxes package in Ubuntu:
  Confirmed

Bug description:
  Guest systems running Windows 10 in a virtualized environment run
  unacceptably slow, with no option in Boxes to offer the virtual
  machine more (or less) cores from my physical CPU.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-boxes 3.26.1-1
  ProcVersionSignature: Ubuntu 4.13.0-17.20-lowlatency 4.13.8
  Uname: Linux 4.13.0-17-lowlatency x86_64
  ApportVersion: 2.20.7-0ubuntu3.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Nov 28 00:37:11 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-boxes
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-boxes/+bug/1734810/+subscriptions

[Qemu-devel] [Bug 1734810] Re: Windows guest virtual PC running abnormally slow

[Thomas Huth]

At least please try to answer my questions in comment #3: Is
virtualization enabled in your BIOS? Is KVM enabled on your system (i.e.
are the kvm.ko and kvm_intel.ko or kvm_amd.ko modules loaded)?

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

Title:
  Windows guest virtual PC running abnormally slow

Status in Boxes:
  New
Status in KVM:
  New
Status in libvirt:
  New
Status in QEMU:
  Invalid
Status in spice related packages:
  Confirmed
Status in gnome-boxes package in Ubuntu:
  Confirmed

Bug description:
  Guest systems running Windows 10 in a virtualized environment run
  unacceptably slow, with no option in Boxes to offer the virtual
  machine more (or less) cores from my physical CPU.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-boxes 3.26.1-1
  ProcVersionSignature: Ubuntu 4.13.0-17.20-lowlatency 4.13.8
  Uname: Linux 4.13.0-17-lowlatency x86_64
  ApportVersion: 2.20.7-0ubuntu3.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Nov 28 00:37:11 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-boxes
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-boxes/+bug/1734810/+subscriptions

Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state

[Paolo Bonzini]

On 08/11/2018 10:57, Liran Alon wrote:
> 
> 
>> On 8 Nov 2018, at 11:50, Paolo Bonzini  wrote:
>>
>> On 08/11/2018 01:45, Jim Mattson wrote:
>>> I have no attachments to the current design. I had used a data[] blob,
>>> because I didn't think userspace would have any need to know what was
>>> in there. However, I am now seeing the error of my ways. For example,
>>> the userspace instruction emulator needs to know the contents of the
>>> vmcs12 to emulate instructions when in guest mode.
>>
>> Yeah, we're probably going to have to document the KVM vmcs12 structure,
>> possibly moving it to uapi.  But that's a different thing from
>> save/restore state, which can use the 4K or 8K data[] blob.
>>
>> Paolo
> 
> But regardless of if we document vmcs12 or not, the current blob we
> have today should be separated to well-defined blobs/structs (cached_vmcs12
> and cached_shadow_vmcs12) and each blob should have a relevant flag that 
> specifies
> it is valid (saved by kernel or requested to be restored by userspace).
> Additional future nested-state should be added as additional
> well-defined blobs/structs with appropriate flags.

We are somewhat limited by the ABI of the released kernel versions, and
it's unlikely that the structure will change in the short term.  So I
think it's okay if we just define that the first 4K of data are the VMCS
and the second 8K are the shadow VMCS, whenever format=0 in the
kvm_nested_state struct.

Paolo

> Then, in QEMU, each such well-defined blob/struct should have it’s own 
> subsection with a relevant .needed() method.
> This will allow us to preserve required backwards compatibility.
> 
> Agreed?
> 
> -Liran
> 

Re: [Qemu-devel] xen_disk qdevification

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 08 November 2018 15:44
> To: 'Kevin Wolf' 
> Cc: Stefano Stabellini ; qemu-bl...@nongnu.org;
> Tim Smith ; qemu-devel@nongnu.org; 'Markus
> Armbruster' ; Anthony Perard
> ; xen-de...@lists.xenproject.org; Max Reitz
> 
> Subject: Re: [Xen-devel] [Qemu-devel] xen_disk qdevification
> 
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 08 November 2018 15:21
> > To: Paul Durrant 
> > Cc: 'Markus Armbruster' ; Anthony Perard
> > ; Tim Smith ; Stefano
> > Stabellini ; qemu-bl...@nongnu.org; qemu-
> > de...@nongnu.org; Max Reitz ; xen-
> > de...@lists.xenproject.org
> > Subject: Re: [Qemu-devel] xen_disk qdevification
> >
> > Am 08.11.2018 um 15:00 hat Paul Durrant geschrieben:
> > > > -Original Message-
> > > > From: Markus Armbruster [mailto:arm...@redhat.com]
> > > > Sent: 05 November 2018 15:58
> > > > To: Paul Durrant 
> > > > Cc: 'Kevin Wolf' ; Tim Smith
> ;
> > > > Stefano Stabellini ; qemu-bl...@nongnu.org;
> > qemu-
> > > > de...@nongnu.org; Max Reitz ; Anthony Perard
> > > > ; xen-de...@lists.xenproject.org
> > > > Subject: Re: [Qemu-devel] xen_disk qdevification
> > > >
> > > > Paul Durrant  writes:
> > > >
> > > > >> -Original Message-
> > > > >> From: Kevin Wolf [mailto:kw...@redhat.com]
> > > > >> Sent: 02 November 2018 11:04
> > > > >> To: Tim Smith 
> > > > >> Cc: xen-de...@lists.xenproject.org; qemu-devel@nongnu.org; qemu-
> > > > >> bl...@nongnu.org; Anthony Perard ;
> Paul
> > > > Durrant
> > > > >> ; Stefano Stabellini
> > ;
> > > > >> Max Reitz ; arm...@redhat.com
> > > > >> Subject: xen_disk qdevification (was: [PATCH 0/3] Performance
> > > > improvements
> > > > >> for xen_disk v2)
> > > > >>
> > > > >> Am 02.11.2018 um 11:00 hat Tim Smith geschrieben:
> > > > >> > A series of performance improvements for disks using the Xen PV
> > ring.
> > > > >> >
> > > > >> > These have had fairly extensive testing.
> > > > >> >
> > > > >> > The batching and latency improvements together boost the
> > throughput
> > > > >> > of small reads and writes by two to six percent (measured using
> > fio
> > > > >> > in the guest)
> > > > >> >
> > > > >> > Avoiding repeated calls to posix_memalign() reduced the dirty
> > heap
> > > > >> > from 25MB to 5MB in the case of a single datapath process while
> > also
> > > > >> > improving performance.
> > > > >> >
> > > > >> > v2 removes some checkpatch complaints and fixes the CCs
> > > > >>
> > > > >> Completely unrelated, but since you're the first person touching
> > > > >> xen_disk in a while, you're my victim:
> > > > >>
> > > > >> At KVM Forum we discussed sending a patch to deprecate xen_disk
> > because
> > > > >> after all those years, it still hasn't been converted to qdev.
> > Markus
> > > > is
> > > > >> currently fixing some other not yet qdevified block device, but
> > after
> > > > >> that xen_disk will be the only one left.
> > > > >>
> > > > >> A while ago, a downstream patch review found out that there are
> > some
> > > > QMP
> > > > >> commands that would immediately crash if a xen_disk device were
> > present
> > > > >> because of the lacking qdevification. This is not the code
> quality
> > > > >> standard I envision for QEMU. It's time for non-qdev devices to
> go.
> > > > >>
> > > > >> So if you guys are still interested in the device, could someone
> > please
> > > > >> finally look into converting it?
> > > > >>
> > > > >
> > > > > I have a patch series to do exactly this. It's somewhat involved
> as
> > I
> > > > > need to convert the whole PV backend infrastructure. I will try to
> > > > > rebase and clean up my series a.s.a.p.
> > > >
> > > > Awesome!  Please coordinate with Anthony Prerard to avoid
> duplicating
> > > > work if you haven't done so already.
> > >
> > > I've come across a bit of a problem that I'm not sure how best to deal
> > > with and so am looking for some advice.
> > >
> > > I now have a qdevified PV disk backend but I can't bring it up because
> > > it fails to acquire a write lock on the qcow2 it is pointing at. This
> > > is because there is also an emulated IDE drive using the same qcow2.
> > > This does not appear to be a problem for the non-qdev xen-disk,
> > > presumably because it is not opening the qcow2 until the emulated
> > > device is unplugged and I don't really want to introduce similar
> > > hackery in my new backend (i.e. I want it to attach to its drive, and
> > > hence open the qcow2, during realize).
> > >
> > > So, I'm not sure what to do... It is not a problem that both a PV
> > > backend and an emulated device are using the same qcow2 because they
> > > will never actually operate simultaneously so is there any way I can
> > > bypass the qcow2 lock check when I create the drive for my PV backend?
> > > (BTW I tried re-using the drive created for the emulated device, but
> > > that doesn't work because there is a 

[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

[tlloss]

Oh and yeah, I just kind of realized that the original issue simply appears 
after the new timers are being activated by default.
Well, that should have been pretty obvious.
I'll try to actuvate them at compile time and see where this path leads to.

And sorry for misclicking on the information type settings.

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

Title:
  Malformed audio and video output stuttering after upgrade to QEMU 3.0

Status in QEMU:
  New

Bug description:
  My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened
  kernel, running a few KVM guests with varying OSes and configurations
  managed through a Libvirt stack.

  Among these guests I have two Windows 10 VMs with VGA passthrough and
  PulseAudio-backed virtual audio devices.

  After upgrading to QEMU 3.0.0, both of the Win10 guests started
  showing corrupted audio output in the form of unnatural reproduction
  speed and occasional but consistently misplaced audio fragments
  originating from what seems to be a circular buffer wrapping over
  itself (misbehaviour detected by starting some games with known OSTs
  and dialogues: soundtracks sound accelerated and past dialogue lines
  start replaying middle-sentence until the next line starts playing).

  In addition, the video output of the malfunctioning VMs regularly
  stutters roughly twice a second for a fraction of a second (sync'ed
  with the suspected buffer wrapping and especially pronounced during
  not-pre-rendered cutscenes), toghether with mouse freezes that look
  like actual input misses more than simple lack of screen refreshes.

  
  The issue was succesfully reproduced without the managing stack, directly 
with the following command line, on the most capable Windows guest:

   QEMU_AUDIO_DRV=pa
   QEMU_PA_SERVER=127.0.0.1
   /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \
   -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \

   
   -cpu 
host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off
 \  
   -drive 
file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ 
  
   -drive 
file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \
   -m 5120 \
  
   -realtime mlock=off \
   -smp 3,sockets=1,cores=3,threads=1 \
   -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \
   -display none \ 
   -no-user-config \
   -nodefaults \
   -rtc base=localtime,driftfix=slew \  

   
   -global kvm-pit.lost_tick_policy=delay \ 
 
   -no-hpet \  
   -no-shutdown \
   -global PIIX4_PM.disable_s3=1 \
   -global PIIX4_PM.disable_s4=1 \
   -boot strict=on \  
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \  
   
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \
   -device ahci,id=sata0,bus=pci.0,addr=0x9 \ 
   -drive 
file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
 \
   -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
 \
   -drive 
file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \   
 
   -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \  
   
   -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \ 

   
   -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ 

   -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \
   -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \  
   -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \
   -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \   
   -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
   -msg timestamp=on

  
  By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" 
with "pc-i440fx-2.11" (basically reverting the config changes I 

Re: [Qemu-devel] [PATCH v4 01/16] hw/cpu: introduce CPU clusters

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 05:23:14PM +0100, Philippe Mathieu-Daudé wrote:
> On Thu, Nov 8, 2018 at 5:17 PM Philippe Mathieu-Daudé  
> wrote:
> > On 6/11/18 12:05, Luc Michel wrote:
> > > This commit adds the cpu-cluster type. It aims at gathering CPUs from
> > > the same cluster in a machine.
> > >
> > > For now it only has a `cluster-id` property.
> > >
> > > Signed-off-by: Luc Michel 
> > > Reviewed-by: Alistair Francis 
> > > ---
> > >   include/hw/cpu/cluster.h | 38 ++
> > >   hw/cpu/cluster.c | 59 
> 
> Eduardo are you OK to cover these files in your "Machine core"
> MAINTAINER's section?

Yes, no problem.

-- 
Eduardo

Re: [Qemu-devel] [Qemu-block] [PATCH] tests: Fix Python 3 detection on older GNU make versions

[Eduardo Habkost]

On Thu, Nov 08, 2018 at 11:06:45AM -0500, Cleber Rosa wrote:
> 
> 
> On 11/8/18 3:45 AM, Markus Armbruster wrote:
> > Cleber Rosa  writes:
> > 
> >> On 11/7/18 1:05 AM, Markus Armbruster wrote:
> >>> Eduardo Habkost  writes:
> >>>
>  The $(SHELLSTATUS) variable requires GNU make >= 4.2, but Travis
>  seems to provide an older version.  Change the existing rules to
>  use command output instead of exit code, to make it compatible
>  with older GNU make versions.
> 
>  Signed-off-by: Eduardo Habkost 
>  ---
>  I think that's the cause of the Travis failures.  I have
>  submitted a test job right now, at:
>    https://travis-ci.org/ehabkost/qemu-hacks/jobs/451387962
>  Let's see if it fixes the issue.
>  ---
>   tests/Makefile.include | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
>  diff --git a/tests/Makefile.include b/tests/Makefile.include
>  index d2e577eabb..074eece558 100644
>  --- a/tests/Makefile.include
>  +++ b/tests/Makefile.include
>  @@ -913,8 +913,8 @@ TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results
>   # information please refer to "avocado --help".
>   AVOCADO_SHOW=none
>   
>  -$(shell $(PYTHON) -c 'import sys; assert sys.version_info >= (3,0)' 
>  >/dev/null 2>&1)
>  -ifeq ($(.SHELLSTATUS),0)
>  +PYTHON3 = $(shell $(PYTHON) -c 'import sys; print(1 if sys.version_info 
>  >= (3, 0) else 0)')
>  +ifeq ($(PYTHON3), 1)
>   $(TESTS_VENV_DIR): $(TESTS_VENV_REQ)
>   $(call quiet-command, \
>   $(PYTHON) -m venv --system-site-packages $@, \
> >>>
> >>> PEP 394 recommends software distributions install Python 3 into the
> >>> default path as python3, and users use that instead of python, except
> >>> for programs that are source compatible with both 2 and 3.  So, is
> >>> finding out whether python is a Python 3 really appropriate?  Why can't
> >>> we just use python3 and be done with it?
> >>>
> >>
> >> I mentioned that before, when you pointed out the issue you fix here,
> >> that configure may be the best place to get the Python version (not only
> >> the major version) and make it available elsewhere.  Even if not used
> >> for other purposes, it is IMO important information to show on the
> >> resulting "configure" output.
> >>
> >> I'm sending patches to do that in a few.
> >>
> >>> If we can't: isn't this a configure problem?
> >>>
> >>
> >> I believe adhering to PEP394 is a good thing, but even that document
> >> recognizes that the real world is not a perfect place: "however, end
> >> users should be aware that python refers to python3 on at least Arch
> >> Linux".  And it only covers *nix systems, so if we hope to care for
> >> non-*nix systems, we have to check the Python version manually.
> >>
> >> So, I guess the safest approach from QEMU's side is to check for the
> >> version indeed.
> > 
> > If somebody can point to a system people still use where python3 doesn't
> > get you a Python 3, but python does, catering for such (crappy) systems
> > in configure makes sense.  Until then, it's a waste of brain waves and
> > configure run time.
> > 
> > PEP 394 mentions Arch Linux.  It's been seven years.  What's the most
> > recent version of Arch Linux that's still crappy in this regard?
> > 
> 
> I'm not taking the mission of looking for those odd distros, I agree
> it's not productive.  My point is that the Python version is an
> important thing to keep track of, specially with the advent of running
> Python dependent tests on environments we don't fully control.
> 
> Supposing the Python version is captured and tracked by configure, then
> the "python" binary name becomes a non-issue.

I'm not sure I agree with the "is an important thing to keep
track of" part.  I don't think we'll have any need to keep track
of the Python version in shell script or makefiles after we start
requiring Python 3.

Extra cleanups (like moving version checks to ./configure) are
still welcome, but keep in mind that this will probably be thrown
away once we drop Python 2 support.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2] ppc/pnv: check size before data buffer access

[Cédric Le Goater]

Hello Laurent,

On 11/8/18 10:10 AM, Laurent Vivier wrote:
> On 26/10/2018 14:33, P J P wrote:
>> From: Prasad J Pandit 
>>
>> While performing PowerNV memory r/w operations, the access length
>> 'sz' could exceed the data[4] buffer size. Add check to avoid OOB
>> access.
>>
>> Reported-by: Moguofang 
>> Signed-off-by: Prasad J Pandit 
>> ---
>>  hw/ppc/pnv_lpc.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> Update v2: add error log message
>>   -> https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg05750.html
>>
>> diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
>> index d7721320a2..172a915cfc 100644
>> --- a/hw/ppc/pnv_lpc.c
>> +++ b/hw/ppc/pnv_lpc.c
>> @@ -155,9 +155,15 @@ static void pnv_lpc_do_eccb(PnvLpcController *lpc, 
>> uint64_t cmd)
>>  /* XXX Check for magic bits at the top, addr size etc... */
>>  unsigned int sz = (cmd & ECCB_CTL_SZ_MASK) >> ECCB_CTL_SZ_LSH;
>>  uint32_t opb_addr = cmd & ECCB_CTL_ADDR_MASK;
>> -uint8_t data[4];
>> +uint8_t data[8];
>>  bool success;
> 
> I'm not sure 8 is enough.
> 
> ECCB_CTL_SZ_MASK is PPC_BITMASK(4, 7), and ECCB_CTL_SZ_LSH is (63 - 7).
> So the bitmask is 4 bits wide, and thus sz can be 0 to 15.
> I think data[] size should be 16.

The bitmask allows more that 8 but the specs says that 1, 2, 4, 8 are the 
possible value size. So We should be fine.

C.  

> 
> Thanks,
> Laurent
> 

Re: [Qemu-devel] [RFC 0/2] vhost-vfio: introduce mdev based HW vhost backend

[Liang, Cunming]

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Thursday, November 8, 2018 2:16 AM
> To: Liang, Cunming ; Wang, Xiao W
> ; m...@redhat.com; alex.william...@redhat.com
> Cc: qemu-devel@nongnu.org; Bie, Tiwei ; Ye, Xiaolong
> ; Wang, Zhihong ; Daly, Dan
> 
> Subject: Re: [RFC 0/2] vhost-vfio: introduce mdev based HW vhost backend
> 
> 
> On 2018/11/7 下午11:08, Liang, Cunming wrote:
>  believe.
> >>> [LC] Agreed, so it reuses CMD defined by vhost-kernel ioctl. But
> >>> VFIO provides
> >> device specific things (e.g. DMAR, INTR and etc.) which is the extra
> >> APIs being introduced by this transport.
> >>
> >>
> >> I'm not quite sure I understand here. I think having vhost-kernel
> >> compatible ioctl does not conflict of using VFIO ioctl like DMA or INTR?
> >>
> >> Btw, VFIO DMA ioctl is even not a must from my point of view,
> >> vhost-mdev can forward the mem table information to device driver and
> >> let it call DMA API to map/umap pages.
> > [LC] If not regarding vhost-mdev as a device, then forward mem table won't 
> > be a
> concern.
> > If introducing a new mdev bus driver (vhost-mdev) which allows mdev 
> > instance to
> be a new type of provider for vhost-kernel. It becomes a pretty good 
> alternative to
> fully leverage vhost-kernel ioctl.
> > I'm not sure it's the same view as yours when you says reusing vhost-kernel 
> > ioctl.
> >
> 
> Yes it is.
[LC] It sounds a pretty good idea to me. Let us spend some time to figure out 
the next level detail, and sync-up further plan in community call. :)

> 
> Thanks

Re: [Qemu-devel] [PATCH 1/1 V2] Add vhost-pci-blk driver

[Michael S. Tsirkin]

On Thu, Nov 08, 2018 at 10:09:00PM +0800, Dongli Zhang wrote:
> It looks the kernel space vhost-blk can only process raw image.
> 
> How about to verify that only raw image is used in the drive command line when
> vhost-blk-pci is paired with it?
> 
> Otherwise, vhost-blk-pci might be working with qcow2 image without any warning
> on qemu side.
> 
> Dongli Zhang

raw being raw can you really verify that?

[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

[tlloss]

** Attachment added: "[ORIGINAL ISSUE LOG]"
   
https://bugs.launchpad.net/qemu/+bug/1795527/+attachment/5210397/+files/qemu_bisect_original_issue.txt

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

Title:
  Malformed audio and video output stuttering after upgrade to QEMU 3.0

Status in QEMU:
  New

Bug description:
  My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened
  kernel, running a few KVM guests with varying OSes and configurations
  managed through a Libvirt stack.

  Among these guests I have two Windows 10 VMs with VGA passthrough and
  PulseAudio-backed virtual audio devices.

  After upgrading to QEMU 3.0.0, both of the Win10 guests started
  showing corrupted audio output in the form of unnatural reproduction
  speed and occasional but consistently misplaced audio fragments
  originating from what seems to be a circular buffer wrapping over
  itself (misbehaviour detected by starting some games with known OSTs
  and dialogues: soundtracks sound accelerated and past dialogue lines
  start replaying middle-sentence until the next line starts playing).

  In addition, the video output of the malfunctioning VMs regularly
  stutters roughly twice a second for a fraction of a second (sync'ed
  with the suspected buffer wrapping and especially pronounced during
  not-pre-rendered cutscenes), toghether with mouse freezes that look
  like actual input misses more than simple lack of screen refreshes.

  
  The issue was succesfully reproduced without the managing stack, directly 
with the following command line, on the most capable Windows guest:

   QEMU_AUDIO_DRV=pa
   QEMU_PA_SERVER=127.0.0.1
   /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \
   -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \

   
   -cpu 
host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off
 \  
   -drive 
file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ 
  
   -drive 
file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \
   -m 5120 \
  
   -realtime mlock=off \
   -smp 3,sockets=1,cores=3,threads=1 \
   -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \
   -display none \ 
   -no-user-config \
   -nodefaults \
   -rtc base=localtime,driftfix=slew \  

   
   -global kvm-pit.lost_tick_policy=delay \ 
 
   -no-hpet \  
   -no-shutdown \
   -global PIIX4_PM.disable_s3=1 \
   -global PIIX4_PM.disable_s4=1 \
   -boot strict=on \  
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \  
   
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \
   -device ahci,id=sata0,bus=pci.0,addr=0x9 \ 
   -drive 
file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
 \
   -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
 \
   -drive 
file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \   
 
   -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \  
   
   -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \ 

   
   -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ 

   -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \
   -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \  
   -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \
   -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \   
   -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
   -msg timestamp=on

  
  By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" 
with "pc-i440fx-2.11" (basically reverting the config changes I needed to do in 
order to update the domain definitions), the stuttering seems to disappear (or 
at least becomes negligible) and the audio output, despite 

[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

[tlloss]

GIT BISECT RESULTS

So, I managed to run the git bisection and ended up having to do it
twice: once looking for the first commit that broke audio (turns out a
major total breakage occurs before the original diagnosed issue
appeared), then to spot the origin of the main issue (I ignored the
other form of malfunctioning, marking it as 'good').

---AUDIO BREAKAGE BISECT LOG---

git bisect start
# bad: [53a19a9a5f9811a911e9b69ef36afb0d66b5d85c] s390x/tcg: always enable AFP 
for linux-user
git bisect bad 53a19a9a5f9811a911e9b69ef36afb0d66b5d85c
# good: [4743c23509a51bd4ee85cc272287a41917d1be35] Update version for v2.12.0 
release
git bisect good 4743c23509a51bd4ee85cc272287a41917d1be35
# bad: [7f9ddf64d5fe5bfaa91ae0ec52217d86f4d86452] target/arm: Implement SVE 
Floating Point Accumulating Reduction Group
git bisect bad 7f9ddf64d5fe5bfaa91ae0ec52217d86f4d86452
# good: [cc9743c236cce8a35449e3ef67140287b68bb705] iscsi: Query and save device 
designator when opening
git bisect good cc9743c236cce8a35449e3ef67140287b68bb705
# good: [1e05197f24c49d52f339de9053bb1d17082f1be3] translate-all: iterate over 
TBs in a page with PAGE_FOR_EACH_TB
git bisect good 1e05197f24c49d52f339de9053bb1d17082f1be3
# good: [2aeba0d007d33efa12a6339bb140aa634e0d52eb] target/arm: Strict alignment 
for ARMv6-M and ARMv8-M Baseline
git bisect good 2aeba0d007d33efa12a6339bb140aa634e0d52eb
# bad: [00928a421d47f49691cace1207481b7aad31b1f1] Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20180626' into staging
git bisect bad 00928a421d47f49691cace1207481b7aad31b1f1
# bad: [35e238c9330669882487f9929e0aa97900431853] Merge remote-tracking branch 
'remotes/kraxel/tags/audio-20180625-pull-request' into staging
git bisect bad 35e238c9330669882487f9929e0aa97900431853
# good: [c52e53f429aa562539f5da2e7c21c66c6f9a8a16] Merge remote-tracking branch 
'remotes/dgibson/tags/ppc-for-3.0-20180622' into staging
git bisect good c52e53f429aa562539f5da2e7c21c66c6f9a8a16
# good: [be25fcc4d2faeb3ffa8db813272963bae659c4c2] MAINTAINERS: Update QAPI 
stanza for commit fb0bc835e56
git bisect good be25fcc4d2faeb3ffa8db813272963bae659c4c2
# good: [518d23a976b7dad77cfef3e41c3531ac89229b00] Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
git bisect good 518d23a976b7dad77cfef3e41c3531ac89229b00
# bad: [8ced0669237b2bbedac3e4ce6fcf7faae663] audio/hda: tweak timer adjust 
logic
git bisect bad 8ced0669237b2bbedac3e4ce6fcf7faae663
# bad: [0a373bb310c1533e24aa5e3edbf206507fb342ea] audio/hda: turn some dprintfs 
into trace points
git bisect bad 0a373bb310c1533e24aa5e3edbf206507fb342ea
# bad: [280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] audio/hda: create millisecond 
timers that handle IO
git bisect bad 280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d
# first bad commit: [280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] audio/hda: 
create millisecond timers that handle IO

---END---


---ORIGINAL ISSUE BISECT LOG---

git bisect start
# bad: [35e238c9330669882487f9929e0aa97900431853] Merge remote-tracking branch 
'remotes/kraxel/tags/audio-20180625-pull-request' into staging
git bisect bad 35e238c9330669882487f9929e0aa97900431853
# good: [c52e53f429aa562539f5da2e7c21c66c6f9a8a16] Merge remote-tracking branch 
'remotes/dgibson/tags/ppc-for-3.0-20180622' into staging
git bisect good c52e53f429aa562539f5da2e7c21c66c6f9a8a16
# good: [cc2ae7c9de14efd72c6205825eb7cd980ac09c11] target/arm: Introduce 
ARM_FEATURE_M_MAIN
git bisect good cc2ae7c9de14efd72c6205825eb7cd980ac09c11
# good: [be25fcc4d2faeb3ffa8db813272963bae659c4c2] MAINTAINERS: Update QAPI 
stanza for commit fb0bc835e56
git bisect good be25fcc4d2faeb3ffa8db813272963bae659c4c2
# good: [518d23a976b7dad77cfef3e41c3531ac89229b00] Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
git bisect good 518d23a976b7dad77cfef3e41c3531ac89229b00
# good: [8ced0669237b2bbedac3e4ce6fcf7faae663] audio/hda: tweak timer 
adjust logic
git bisect good 8ced0669237b2bbedac3e4ce6fcf7faae663
# bad: [bc753dc09ff33d99bc9004d7286c50de1d5bece6] audio/hda: enable new timer 
code by default.
git bisect bad bc753dc09ff33d99bc9004d7286c50de1d5bece6
# good: [4501ee16c76e89e0a2b2beb95f3b93f965997391] audio/hda: detect output 
buffer overruns
git bisect good 4501ee16c76e89e0a2b2beb95f3b93f965997391
# first bad commit: [bc753dc09ff33d99bc9004d7286c50de1d5bece6] audio/hda: 
enable new timer code by default.

---END---


I'm attaching both of them, just in case someone wants to replay them.

One thing that I'd like to point out is that the thing I called "total 
breakage" looks extremely similar to what happens when I set a 2.12 machine on 
a 3.0 QEMU: complete distortion.
Do I have to study it more in order to see if it really produces the same 
effect?


Anyway, I'm sorry if such a simple matter took this long but, during one of the 
initial bisections, an accidental misconfiguration in the testing environment 
completely wasted the guest I was using (permanent 

Re: [Qemu-devel] [Spice-devel] [RFC PATCH spice v3 1/3] QXL interface: add a function to identify monitors in the guest

[Jonathon Jongsma]

On Thu, 2018-11-08 at 11:05 +0100, Lukáš Hrázký wrote:
> Hello,
> 
> On Thu, 2018-11-08 at 07:49 +0100, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > + * The device_display_id_{start,count} denotes the sequence of
> > > device display
> > > + * IDs that map to the zero-based sequence of monitor IDs
> > > provided by monitors
> > > + * config on this interface. For example with
> > > device_display_id_start = 2 and
> > > + * device_display_id_count = 3 you get the following mapping:
> > > + * monitor_id  ->  device_display_id
> > > + *  0  ->  2
> > > + *  1  ->  3
> > > + *  2  ->  4
> > > + *
> > > + * Note this example is unsupported in practice. The only
> > > supported cases are
> > > + * either a single device display ID (count = 1) or multiple
> > > device display IDs
> > > + * in a sequence starting from 0.
> > 
> > This is confusing.  The usage of this api in the qemu counterpart
> > looks
> > sane though.
> 
> Not sure what you find confusing in particular... The example? Using
> an
> example and then saying it's not supported? (I wated to use a
> nontrivial example that will show the concept...) Suggestions for
> improvement?

It is funny that you chose an unsupported example for demonstration,
but I can't think of a better option. The supported scenarios don't
demonstrate the full behavior very well...


> 
> Thanks,
> Lukas
> 
> > cheers,
> >   Gerd
> > 
> 
> ___
> Spice-devel mailing list
> spice-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Qemu-devel] [PATCH v2 5/6] arm: use symbolic MDCR_TDE in arm_debug_target_el

[Alex Bennée]

We already have this symbol defined so lets use it.

Signed-off-by: Alex Bennée 
---
 target/arm/cpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index b5eff79f73..1efff21a18 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2743,7 +2743,7 @@ static inline int arm_debug_target_el(CPUARMState *env)
 
 if (arm_feature(env, ARM_FEATURE_EL2) && !secure) {
 route_to_el2 = env->cp15.hcr_el2 & HCR_TGE ||
-   env->cp15.mdcr_el2 & (1 << 8);
+   env->cp15.mdcr_el2 & MDCR_TDE;
 }
 
 if (route_to_el2) {
-- 
2.17.1

[Qemu-devel] [PATCH v2 6/6] arm: fix aa64_generate_debug_exceptions to work with EL2

[Alex Bennée]

The test was incomplete and incorrectly caused debug exceptions to be
generated when returning to EL2 after a failed attempt to single-step
an EL1 instruction. Fix this while cleaning up the function a little.

Signed-off-by: Alex Bennée 
---
 target/arm/cpu.h | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 1efff21a18..a6d8eb14f6 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2764,23 +2764,33 @@ static inline bool arm_v7m_csselr_razwi(ARMCPU *cpu)
 return (cpu->clidr & R_V7M_CLIDR_CTYPE_ALL_MASK) != 0;
 }
 
+/* See AArch64.GenerateDebugExceptionsFrom() in ARM ARM pseudocode */
 static inline bool aa64_generate_debug_exceptions(CPUARMState *env)
 {
+int cur_el = arm_current_el(env);
+int debug_el;
+
 if (arm_is_secure(env)) {
 /* MDCR_EL3.SDD disables debug events from Secure state */
 if (extract32(env->cp15.mdcr_el3, 16, 1) != 0
-|| arm_current_el(env) == 3) {
+|| cur_el == 3) {
 return false;
 }
 }
 
-if (arm_current_el(env) == arm_debug_target_el(env)) {
-if ((extract32(env->cp15.mdscr_el1, 13, 1) == 0)
-|| (env->daif & PSTATE_D)) {
-return false;
-}
+/*
+ * Same EL to same EL debug exceptions need MDSCR_KDE enabled
+ * while not masking the (D)ebug bit in DAIF.
+ */
+debug_el = arm_debug_target_el(env);
+
+if (cur_el == debug_el) {
+return extract32(env->cp15.mdscr_el1, 13, 1)
+&& !(env->daif & PSTATE_D);
 }
-return true;
+
+/* Otherwise the debug target needs to be a higher EL */
+return debug_el > cur_el;
 }
 
 static inline bool aa32_generate_debug_exceptions(CPUARMState *env)
@@ -2833,9 +2843,6 @@ static inline bool 
aa32_generate_debug_exceptions(CPUARMState *env)
  * since the pseudocode has it at all callsites except for the one in
  * CheckSoftwareStep(), where it is elided because both branches would
  * always return the same value.
- *
- * Parts of the pseudocode relating to EL2 and EL3 are omitted because we
- * don't yet implement those exception levels or their associated trap bits.
  */
 static inline bool arm_generate_debug_exceptions(CPUARMState *env)
 {
-- 
2.17.1

[Qemu-devel] [PATCH v2 1/6] target/arm64: properly handle DBGVR RESS bits

[Alex Bennée]

This only fails with some (broken) versions of gdb but we should
treat the top bits of DBGBVR as RESS. Properly sign extend QEMU's
reference copy of dbgbvr and also update the register descriptions in
the comment.

Signed-off-by: Alex Bennée 

---
v2
  - sanitise register on insertion
  - update reference description
---
 target/arm/kvm64.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 5de8ff0ac5..b92ce3437f 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -103,7 +103,7 @@ static void kvm_arm_init_debug(CPUState *cs)
  * capable of fancier matching but that will require exposing that
  * fanciness to GDB's interface
  *
- * D7.3.2 DBGBCR_EL1, Debug Breakpoint Control Registers
+ * DBGBCR_EL1, Debug Breakpoint Control Registers
  *
  *  31  24 23  20 19   16 15 14  13  12   9 8   5 43 2   1  0
  * +--+--+---+-++--+-+--+-+---+
@@ -115,12 +115,25 @@ static void kvm_arm_init_debug(CPUState *cs)
  * SSC/HMC/PMC: Security, Higher and Priv access control (Table D-12)
  * BAS: Byte Address Select (RES1 for AArch64)
  * E: Enable bit
+ *
+ * DBGBVR_EL1, Debug Breakpoint Value Registers
+ *
+ *  63  53 52   49 48   2  1 0
+ * +--+---+--+-+
+ * | RESS | VA[52:49] | VA[48:2] | 0 0 |
+ * +--+---+--+-+
+ *
+ * Depending on the addressing mode bits the top bits of the register
+ * are a sign extension of the highest applicable VA bit. Some
+ * versions of GDB don't do it correctly so we ensure they are correct
+ * here so future PC comparisons will work properly.
  */
+
 static int insert_hw_breakpoint(target_ulong addr)
 {
 HWBreakpoint brk = {
 .bcr = 0x1, /* BCR E=1, enable */
-.bvr = addr
+.bvr = sextract64(addr, 52, 53)
 };
 
 if (cur_hw_bps >= max_hw_bps) {
-- 
2.17.1

[Qemu-devel] [PATCH v2 2/6] target/arm64: hold BQL when calling do_interrupt()

[Alex Bennée]

Fix the assertion failure when running interrupts.

Signed-off-by: Alex Bennée 
Reviewed-by: Peter Maydell 
---
 target/arm/kvm64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index b92ce3437f..03b0f78831 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -1000,7 +1000,9 @@ bool kvm_arm_handle_debug(CPUState *cs, struct 
kvm_debug_exit_arch *debug_exit)
 cs->exception_index = EXCP_BKPT;
 env->exception.syndrome = debug_exit->hsr;
 env->exception.vaddress = debug_exit->far;
+qemu_mutex_lock_iothread();
 cc->do_interrupt(cs);
+qemu_mutex_unlock_iothread();
 
 return false;
 }
-- 
2.17.1

[Qemu-devel] [PATCH v2 0/6] KVM Guest Debug fixes (plus TCG EL2 debug tweaks)

[Alex Bennée]

Hi,

These are fixes for guest debug when running under KVM. While
re-spinning these I came across an anomaly which pointed to a kernel
bug that caused the 1st single-step to fail. This is being discussed
on the kvm-arm list:

  Subject: [RFC PATCH] KVM: arm64: don't single-step for non-emulated faults
  Date: Wed, 7 Nov 2018 17:10:31 +
  Message-Id: <20181107171031.22573-1-alex.ben...@linaro.org>

As debugging HYP mode code is next to impossible on real hardware I
tried re-creating the single-step bug under TCG. As a result I ran into
some debug and EL2 cases that failed. The final two patches are some
fixes but I'm still seeing some weird behaviour although it is currently
obscured by timer interrupts constantly firing as I enter the to be
single-stepped guest EL1 instruction so they can probably be skipped for
3.1.

Alex Bennée (6):
  target/arm64: properly handle DBGVR RESS bits
  target/arm64: hold BQL when calling do_interrupt()
  target/arm64: kvm debug set target_el when passing exception to guest
  tests/guest-debug: fix scoping of failcount
  arm: use symbolic MDCR_TDE in arm_debug_target_el
  arm: fix aa64_generate_debug_exceptions to work with EL2

 target/arm/cpu.h  | 29 ++---
 target/arm/kvm64.c| 20 ++--
 tests/guest-debug/test-gdbstub.py |  1 +
 3 files changed, 37 insertions(+), 13 deletions(-)

-- 
2.17.1

[Qemu-devel] [PATCH v2 4/6] tests/guest-debug: fix scoping of failcount

[Alex Bennée]

You should declare you are using a global version of a variable before
you attempt to modify it in a function.

Signed-off-by: Alex Bennée 
Reviewed-by: Peter Maydell 
---
 tests/guest-debug/test-gdbstub.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/guest-debug/test-gdbstub.py 
b/tests/guest-debug/test-gdbstub.py
index 0e4ac01426..c7e3986a24 100644
--- a/tests/guest-debug/test-gdbstub.py
+++ b/tests/guest-debug/test-gdbstub.py
@@ -16,6 +16,7 @@ def report(cond, msg):
 print ("PASS: %s" % (msg))
 else:
 print ("FAIL: %s" % (msg))
+global failcount
 failcount += 1
 
 
-- 
2.17.1

[Qemu-devel] [PATCH v2 3/6] target/arm64: kvm debug set target_el when passing exception to guest

[Alex Bennée]

When we are debugging the guest all exceptions come our way but might
be for the guest's own debug exceptions. We use the ->do_interrupt()
infrastructure to inject the exception into the guest. However, we are
missing a full setup of the exception structure, causing an assert
later down the line.

Signed-off-by: Alex Bennée 
Reviewed-by: Peter Maydell 

---
v2
  - tweak commit msg for grammar
---
 target/arm/kvm64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 03b0f78831..bf7824d862 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -1000,6 +1000,7 @@ bool kvm_arm_handle_debug(CPUState *cs, struct 
kvm_debug_exit_arch *debug_exit)
 cs->exception_index = EXCP_BKPT;
 env->exception.syndrome = debug_exit->hsr;
 env->exception.vaddress = debug_exit->far;
+env->exception.target_el = 1;
 qemu_mutex_lock_iothread();
 cc->do_interrupt(cs);
 qemu_mutex_unlock_iothread();
-- 
2.17.1

Re: [Qemu-devel] [PATCH v4 01/16] hw/cpu: introduce CPU clusters

[Philippe Mathieu-Daudé]

On 6/11/18 12:05, Luc Michel wrote:

This commit adds the cpu-cluster type. It aims at gathering CPUs from
the same cluster in a machine.

For now it only has a `cluster-id` property.

Signed-off-by: Luc Michel 
Reviewed-by: Alistair Francis 
---
  include/hw/cpu/cluster.h | 38 ++
  hw/cpu/cluster.c | 59 
  hw/cpu/Makefile.objs |  2 +-
  3 files changed, 98 insertions(+), 1 deletion(-)
  create mode 100644 include/hw/cpu/cluster.h
  create mode 100644 hw/cpu/cluster.c

diff --git a/include/hw/cpu/cluster.h b/include/hw/cpu/cluster.h
new file mode 100644
index 00..0e5f121ec2
--- /dev/null
+++ b/include/hw/cpu/cluster.h
@@ -0,0 +1,38 @@
+/*
+ * QEMU CPU cluster
+ *
+ * Copyright (c) 2018 GreenSocs SAS
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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
+ * 
+ */
+#ifndef HW_CPU_CLUSTER_H
+#define HW_CPU_CLUSTER_H
+
+#include "qemu/osdep.h"
+#include "hw/qdev.h"
+
+#define TYPE_CPU_CLUSTER "cpu-cluster"
+#define CPU_CLUSTER(obj) \
+OBJECT_CHECK(CPUClusterState, (obj), TYPE_CPU_CLUSTER)
+
+typedef struct CPUClusterState {
+/*< private >*/
+DeviceState parent_obj;
+
+/*< public >*/
+uint64_t cluster_id;


As it or reducing this type:
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 


+} CPUClusterState;
+
+#endif
diff --git a/hw/cpu/cluster.c b/hw/cpu/cluster.c
new file mode 100644
index 00..a23d55054a
--- /dev/null
+++ b/hw/cpu/cluster.c
@@ -0,0 +1,59 @@
+/*
+ * QEMU CPU cluster
+ *
+ * Copyright (c) 2018 GreenSocs SAS
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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 "hw/cpu/cluster.h"
+#include "qapi/error.h"
+#include "qemu/module.h"
+
+static void cpu_cluster_init(Object *obj)
+{
+static uint64_t cluster_id_auto_increment = 0;
+CPUClusterState *cluster = CPU_CLUSTER(obj);
+
+cluster->cluster_id = cluster_id_auto_increment++;
+}
+
+static Property cpu_cluster_properties[] = {
+DEFINE_PROP_UINT64("cluster-id", CPUClusterState, cluster_id, 0),
+DEFINE_PROP_END_OF_LIST()
+};
+
+static void cpu_cluster_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->props = cpu_cluster_properties;
+}
+
+static const TypeInfo cpu_cluster_type_info = {
+.name = TYPE_CPU_CLUSTER,
+.parent = TYPE_DEVICE,
+.instance_size = sizeof(CPUClusterState),
+.instance_init = cpu_cluster_init,
+.class_init = cpu_cluster_class_init,
+};
+
+static void cpu_cluster_register_types(void)
+{
+type_register_static(_cluster_type_info);
+}
+
+type_init(cpu_cluster_register_types)
diff --git a/hw/cpu/Makefile.objs b/hw/cpu/Makefile.objs
index cd52d20b65..8db9e8a7b3 100644
--- a/hw/cpu/Makefile.objs
+++ b/hw/cpu/Makefile.objs
@@ -1,5 +1,5 @@
  obj-$(CONFIG_ARM11MPCORE) += arm11mpcore.o
  obj-$(CONFIG_REALVIEW) += realview_mpcore.o
  obj-$(CONFIG_A9MPCORE) += a9mpcore.o
  obj-$(CONFIG_A15MPCORE) += a15mpcore.o
-common-obj-y += core.o
+common-obj-y += core.o cluster.o

Re: [Qemu-devel] [PATCH v2 19/22] vl: Introduce shutdown_notifiers

[Cornelia Huck]

On Thu,  8 Nov 2018 18:08:15 +0200
Yuval Shaia  wrote:

> Notifier will be used for signaling shutdown event to inform system is
> shutdown. This will allow devices and other component to run some
> cleanup code needed before VM is shutdown.
> 
> Signed-off-by: Yuval Shaia 
> ---
>  include/sysemu/sysemu.h |  1 +
>  vl.c| 15 ++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 

> @@ -1809,6 +1811,12 @@ static void qemu_system_powerdown(void)
>  notifier_list_notify(_notifiers, NULL);
>  }
>  
> +static void qemu_system_shutdown(bool by_guest)

I would pass the shutdown reason here directly (instead of only whether
this was triggered by the guest or not)...

> +{
> +qapi_event_send_shutdown(by_guest);
> +notifier_list_notify(_notifiers, NULL);

...and also pass it to the notifiers here. If we have the info anyway,
why not simply pass it along.

> +}
> +
>  void qemu_system_powerdown_request(void)
>  {
>  trace_qemu_system_powerdown_request();
> @@ -1821,6 +1829,11 @@ void qemu_register_powerdown_notifier(Notifier 
> *notifier)
>  notifier_list_add(_notifiers, notifier);
>  }
>  
> +void qemu_register_shutdown_notifier(Notifier *notifier)
> +{
> +notifier_list_add(_notifiers, notifier);
> +}
> +
>  void qemu_system_debug_request(void)
>  {
>  debug_requested = 1;
> @@ -1848,7 +1861,7 @@ static bool main_loop_should_exit(void)
>  request = qemu_shutdown_requested();
>  if (request) {
>  qemu_kill_report();
> -qapi_event_send_shutdown(shutdown_caused_by_guest(request));
> +qemu_system_shutdown(shutdown_caused_by_guest(request));
>  if (no_shutdown) {
>  vm_stop(RUN_STATE_SHUTDOWN);
>  } else {

[Qemu-devel] [PATCH v2 22/22] rdma: Do not call rdma_backend_del_gid on an empty gid

[Yuval Shaia]

Signed-off-by: Yuval Shaia 
---
 hw/rdma/rdma_rm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 35a96d9a64..e3f6b2f6ea 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -555,6 +555,10 @@ int rdma_rm_del_gid(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
 {
 int rc;
 
+if (!dev_res->port.gid_tbl[gid_idx].gid.global.interface_id) {
+return 0;
+}
+
 rc = rdma_backend_del_gid(backend_dev, ifname,
   _res->port.gid_tbl[gid_idx].gid);
 if (rc < 0) {
-- 
2.17.2

Re: [Qemu-devel] [PATCH v4 01/16] hw/cpu: introduce CPU clusters

[Philippe Mathieu-Daudé]

On Thu, Nov 8, 2018 at 5:17 PM Philippe Mathieu-Daudé  wrote:
> On 6/11/18 12:05, Luc Michel wrote:
> > This commit adds the cpu-cluster type. It aims at gathering CPUs from
> > the same cluster in a machine.
> >
> > For now it only has a `cluster-id` property.
> >
> > Signed-off-by: Luc Michel 
> > Reviewed-by: Alistair Francis 
> > ---
> >   include/hw/cpu/cluster.h | 38 ++
> >   hw/cpu/cluster.c | 59 

Eduardo are you OK to cover these files in your "Machine core"
MAINTAINER's section?

> >   hw/cpu/Makefile.objs |  2 +-
> >   3 files changed, 98 insertions(+), 1 deletion(-)
> >   create mode 100644 include/hw/cpu/cluster.h
> >   create mode 100644 hw/cpu/cluster.c
> >
> > diff --git a/include/hw/cpu/cluster.h b/include/hw/cpu/cluster.h
> > new file mode 100644
> > index 00..0e5f121ec2
> > --- /dev/null
> > +++ b/include/hw/cpu/cluster.h
> > @@ -0,0 +1,38 @@
> > +/*
> > + * QEMU CPU cluster
> > + *
> > + * Copyright (c) 2018 GreenSocs SAS
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that 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
> > + * 
> > + */
> > +#ifndef HW_CPU_CLUSTER_H
> > +#define HW_CPU_CLUSTER_H
> > +
> > +#include "qemu/osdep.h"
> > +#include "hw/qdev.h"
> > +
> > +#define TYPE_CPU_CLUSTER "cpu-cluster"
> > +#define CPU_CLUSTER(obj) \
> > +OBJECT_CHECK(CPUClusterState, (obj), TYPE_CPU_CLUSTER)
> > +
> > +typedef struct CPUClusterState {
> > +/*< private >*/
> > +DeviceState parent_obj;
> > +
> > +/*< public >*/
> > +uint64_t cluster_id;
>
> As it or reducing this type:
> Reviewed-by: Philippe Mathieu-Daudé 
> Tested-by: Philippe Mathieu-Daudé 
>
> > +} CPUClusterState;
> > +
> > +#endif
> > diff --git a/hw/cpu/cluster.c b/hw/cpu/cluster.c
> > new file mode 100644
> > index 00..a23d55054a
> > --- /dev/null
> > +++ b/hw/cpu/cluster.c
> > @@ -0,0 +1,59 @@
> > +/*
> > + * QEMU CPU cluster
> > + *
> > + * Copyright (c) 2018 GreenSocs SAS
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that 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 "hw/cpu/cluster.h"
> > +#include "qapi/error.h"
> > +#include "qemu/module.h"
> > +
> > +static void cpu_cluster_init(Object *obj)
> > +{
> > +static uint64_t cluster_id_auto_increment = 0;
> > +CPUClusterState *cluster = CPU_CLUSTER(obj);
> > +
> > +cluster->cluster_id = cluster_id_auto_increment++;
> > +}
> > +
> > +static Property cpu_cluster_properties[] = {
> > +DEFINE_PROP_UINT64("cluster-id", CPUClusterState, cluster_id, 0),
> > +DEFINE_PROP_END_OF_LIST()
> > +};
> > +
> > +static void cpu_cluster_class_init(ObjectClass *klass, void *data)
> > +{
> > +DeviceClass *dc = DEVICE_CLASS(klass);
> > +
> > +dc->props = cpu_cluster_properties;
> > +}
> > +
> > +static const TypeInfo cpu_cluster_type_info = {
> > +.name = TYPE_CPU_CLUSTER,
> > +.parent = TYPE_DEVICE,
> > +.instance_size = sizeof(CPUClusterState),
> > +.instance_init = cpu_cluster_init,
> > +.class_init = cpu_cluster_class_init,
> > +};
> > +
> > +static void cpu_cluster_register_types(void)
> > +{
> > +type_register_static(_cluster_type_info);
> > +}
> > +
> > +type_init(cpu_cluster_register_types)
> > diff --git a/hw/cpu/Makefile.objs b/hw/cpu/Makefile.objs
> > index cd52d20b65..8db9e8a7b3 100644
> > --- a/hw/cpu/Makefile.objs
> > +++ b/hw/cpu/Makefile.objs
> > @@ -1,5 +1,5 @@
> >   obj-$(CONFIG_ARM11MPCORE) += arm11mpcore.o
> >   obj-$(CONFIG_REALVIEW) += realview_mpcore.o
> >   obj-$(CONFIG_A9MPCORE) += a9mpcore.o
> >   obj-$(CONFIG_A15MPCORE) += a15mpcore.o
> > -common-obj-y += core.o
> > +common-obj-y += core.o cluster.o
> >

Re: [Qemu-devel] [PATCH v4 00/16] gdbstub: support for the multiprocess extension

[Philippe Mathieu-Daudé]

On 6/11/18 12:05, Luc Michel wrote:

changes since v3:
   - patch 1cpu_cluster.h: remove QEMU_ from the multiple includes
guard #ifdef/#define [Alistair]

   - patch 1cpu_cluster.c: include osdep.h first [Alistair]

   - patch 1use uint64_t for cluster ID for prosperity :) [Philippe]


Actually my comment about 32-bit had the opposite meaning, I suppose 
having 256 kind of cpu cores in the same SoC is probably enough for a 
long time IMHO.




   - patch 1auto-assign a cluster ID to newly created clusters [Philippe]

   - patch 2fix mid-code variable declaration [Alistair]

   - patch 3add a comment in gdb_get_cpu_pid() when retrieving CPU
parent canonical path [Alistair]

   - patch 14   fix a typo in the commit message [Alistair]

changes since v2:
   - patch 1introducing the cpu-cluster type. I didn't opt for an
Interface, but I can add one if you think it's necessary.
For now this class inherits from Device and has a
cluster-id property, used by the GDB stub to compute a
PID.

   - patch 2removed GDB group related code as it has been replaced
with CPU clusters

   - patch 2/8  moved GDBProcess target_xml field introduction into patch
8 [Philippe]

   - patch 3gdb_get_cpu_pid() now search for CPU being a child of a
cpu-cluster object. Use the cluster-id to compute the PID.

   - patch 4gdb_get_process() does not rely on s->processes array
indices anymore as PIDs can now be sparse. Instead, iterate
over the array to find the process.

   - patch 3/4  removed Reviewed-by tags because of substantial changes.

   - patch 4/7  read_thread_id() hardening [Philippe]

   - patch 12   safer vAttach packet parsing [Phillipe]

   - patch 16   put APUs and RPUs in different clusters instead of GDB
groups

changes since v1:
   - rename qemu_get_thread_id() to gdb_fmt_thread_id() [Philippe]
   - check qemu_strtoul() return value for 'D' packets [Philippe]


This series adds support for the multiprocess extension of the GDB
remote protocol in the QEMU GDB stub.

This extension is useful to split QEMU emulated CPUs in different
processes from the point of view of the GDB client. It adds the
possibility to debug different kind of processors (e.g. an AArch64 and
an ARMv7 CPU) at the same time (it is not possible otherwise since GDB
expects an SMP view at the thread granularity.

CPUs are grouped using specially named QOM containers. CPUs that are
children of such a container are grouped under the same GDB process.

The last patch groups the CPUs of different model in the zynqmp machines
into separate processes.

To test this patchset, you can use the following commands:

(Note that this requires a recent enough GDB, I think GDB 7.2 is OK.
Also, it must be compiled to support both ARM and AArch64 architectures)

Run QEMU: (-smp 6 in xlnx-zcu102 enables both cortex-a53 and cortex-r5
CPUs)

qemu-system-aarch64 -M xlnx-zcu102 -gdb tcp::1234 -S -smp 6

Run the following commands in GDB:

target extended :1234
add-inferior
inferior 2
attach 2
info threads

I want to thanks the Xilinx's QEMU team who sponsored this work for
their collaboration and their prototype implementation.

Luc Michel (16):
   hw/cpu: introduce CPU clusters
   gdbstub: introduce GDB processes
   gdbstub: add multiprocess support to '?' packets
   gdbstub: add multiprocess support to 'H' and 'T' packets
   gdbstub: add multiprocess support to vCont packets
   gdbstub: add multiprocess support to 'sC' packets
   gdbstub: add multiprocess support to (f|s)ThreadInfo and
 ThreadExtraInfo
   gdbstub: add multiprocess support to Xfer:features:read:
   gdbstub: add multiprocess support to gdb_vm_state_change()
   gdbstub: add multiprocess support to 'D' packets
   gdbstub: add support for extended mode packet
   gdbstub: add support for vAttach packets
   gdbstub: processes initialization on new peer connection
   gdbstub: gdb_set_stop_cpu: ignore request when process is not attached
   gdbstub: add multiprocess extension support
   arm/xlnx-zynqmp: put APUs and RPUs in separate CPU clusters

  include/hw/arm/xlnx-zynqmp.h |   3 +
  include/hw/cpu/cluster.h |  38 +++
  gdbstub.c| 632 ++-
  hw/arm/xlnx-zynqmp.c |  21 +-
  hw/cpu/cluster.c |  59 
  hw/cpu/Makefile.objs |   2 +-
  6 files changed, 674 insertions(+), 81 deletions(-)
  create mode 100644 include/hw/cpu/cluster.h
  create mode 100644 hw/cpu/cluster.c

[Qemu-devel] [PATCH v2 09/22] hw/pvrdma: Set the correct opcode for send completion

[Yuval Shaia]

opcode for WC should be set by the device and not taken from work
element.

Signed-off-by: Yuval Shaia 
---
 hw/rdma/vmw/pvrdma_qp_ops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/rdma/vmw/pvrdma_qp_ops.c b/hw/rdma/vmw/pvrdma_qp_ops.c
index 7b0f440fda..3388be1926 100644
--- a/hw/rdma/vmw/pvrdma_qp_ops.c
+++ b/hw/rdma/vmw/pvrdma_qp_ops.c
@@ -154,7 +154,7 @@ int pvrdma_qp_send(PVRDMADev *dev, uint32_t qp_handle)
 comp_ctx->cq_handle = qp->send_cq_handle;
 comp_ctx->cqe.wr_id = wqe->hdr.wr_id;
 comp_ctx->cqe.qp = qp_handle;
-comp_ctx->cqe.opcode = wqe->hdr.opcode;
+comp_ctx->cqe.opcode = IBV_WC_SEND;
 
 rdma_backend_post_send(>backend_dev, >backend_qp, qp->qp_type,
(struct ibv_sge *)>sge[0], 
wqe->hdr.num_sge,
-- 
2.17.2

[Qemu-devel] [PATCH v2 18/22] hw/rdma: Remove unneeded code that handles more that one port

[Yuval Shaia]

Device supports only one port, let's remove a dead code that handles
more than one port.

Signed-off-by: Yuval Shaia 
---
 hw/rdma/rdma_rm.c  | 34 --
 hw/rdma/rdma_rm.h  |  2 +-
 hw/rdma/rdma_rm_defs.h |  4 ++--
 3 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index fe0979415d..0a5ab8935a 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -545,7 +545,7 @@ int rdma_rm_add_gid(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
 return -EINVAL;
 }
 
-memcpy(_res->ports[0].gid_tbl[gid_idx].gid, gid, sizeof(*gid));
+memcpy(_res->port.gid_tbl[gid_idx].gid, gid, sizeof(*gid));
 
 return 0;
 }
@@ -556,15 +556,15 @@ int rdma_rm_del_gid(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
 int rc;
 
 rc = rdma_backend_del_gid(backend_dev, ifname,
-  _res->ports[0].gid_tbl[gid_idx].gid);
+  _res->port.gid_tbl[gid_idx].gid);
 if (rc < 0) {
 pr_dbg("Fail to delete gid\n");
 return -EINVAL;
 }
 
-memset(dev_res->ports[0].gid_tbl[gid_idx].gid.raw, 0,
-   sizeof(dev_res->ports[0].gid_tbl[gid_idx].gid));
-dev_res->ports[0].gid_tbl[gid_idx].backend_gid_index = -1;
+memset(dev_res->port.gid_tbl[gid_idx].gid.raw, 0,
+   sizeof(dev_res->port.gid_tbl[gid_idx].gid));
+dev_res->port.gid_tbl[gid_idx].backend_gid_index = -1;
 
 return 0;
 }
@@ -577,16 +577,16 @@ int rdma_rm_get_backend_gid_index(RdmaDeviceResources 
*dev_res,
 return -EINVAL;
 }
 
-if (unlikely(dev_res->ports[0].gid_tbl[sgid_idx].backend_gid_index == -1)) 
{
-dev_res->ports[0].gid_tbl[sgid_idx].backend_gid_index =
+if (unlikely(dev_res->port.gid_tbl[sgid_idx].backend_gid_index == -1)) {
+dev_res->port.gid_tbl[sgid_idx].backend_gid_index =
 rdma_backend_get_gid_index(backend_dev,
-   
_res->ports[0].gid_tbl[sgid_idx].gid);
+   _res->port.gid_tbl[sgid_idx].gid);
 }
 
 pr_dbg("backend_gid_index=%d\n",
-   dev_res->ports[0].gid_tbl[sgid_idx].backend_gid_index);
+   dev_res->port.gid_tbl[sgid_idx].backend_gid_index);
 
-return dev_res->ports[0].gid_tbl[sgid_idx].backend_gid_index;
+return dev_res->port.gid_tbl[sgid_idx].backend_gid_index;
 }
 
 static void destroy_qp_hash_key(gpointer data)
@@ -596,15 +596,13 @@ static void destroy_qp_hash_key(gpointer data)
 
 static void init_ports(RdmaDeviceResources *dev_res)
 {
-int i, j;
+int i;
 
-memset(dev_res->ports, 0, sizeof(dev_res->ports));
+memset(_res->port, 0, sizeof(dev_res->port));
 
-for (i = 0; i < MAX_PORTS; i++) {
-dev_res->ports[i].state = IBV_PORT_DOWN;
-for (j = 0; j < MAX_PORT_GIDS; j++) {
-dev_res->ports[i].gid_tbl[j].backend_gid_index = -1;
-}
+dev_res->port.state = IBV_PORT_DOWN;
+for (i = 0; i < MAX_PORT_GIDS; i++) {
+dev_res->port.gid_tbl[i].backend_gid_index = -1;
 }
 }
 
@@ -613,7 +611,7 @@ static void fini_ports(RdmaDeviceResources *dev_res,
 {
 int i;
 
-dev_res->ports[0].state = IBV_PORT_DOWN;
+dev_res->port.state = IBV_PORT_DOWN;
 for (i = 0; i < MAX_PORT_GIDS; i++) {
 rdma_rm_del_gid(dev_res, backend_dev, ifname, i);
 }
diff --git a/hw/rdma/rdma_rm.h b/hw/rdma/rdma_rm.h
index a7169b4e89..3c602c04c0 100644
--- a/hw/rdma/rdma_rm.h
+++ b/hw/rdma/rdma_rm.h
@@ -79,7 +79,7 @@ int rdma_rm_get_backend_gid_index(RdmaDeviceResources 
*dev_res,
 static inline union ibv_gid *rdma_rm_get_gid(RdmaDeviceResources *dev_res,
  int sgid_idx)
 {
-return _res->ports[0].gid_tbl[sgid_idx].gid;
+return _res->port.gid_tbl[sgid_idx].gid;
 }
 
 #endif
diff --git a/hw/rdma/rdma_rm_defs.h b/hw/rdma/rdma_rm_defs.h
index 7b3435f991..0ba61d1838 100644
--- a/hw/rdma/rdma_rm_defs.h
+++ b/hw/rdma/rdma_rm_defs.h
@@ -18,7 +18,7 @@
 
 #include "rdma_backend_defs.h"
 
-#define MAX_PORTS 1
+#define MAX_PORTS 1 /* Do not change - we support only one port */
 #define MAX_PORT_GIDS 255
 #define MAX_GIDS  MAX_PORT_GIDS
 #define MAX_PORT_PKEYS1
@@ -97,7 +97,7 @@ typedef struct RdmaRmPort {
 } RdmaRmPort;
 
 typedef struct RdmaDeviceResources {
-RdmaRmPort ports[MAX_PORTS];
+RdmaRmPort port;
 RdmaRmResTbl pd_tbl;
 RdmaRmResTbl mr_tbl;
 RdmaRmResTbl uc_tbl;
-- 
2.17.2

[Qemu-devel] [PATCH v2 21/22] rdma: Do not use bitmap_zero_extend to fee bitmap

[Yuval Shaia]

Signed-off-by: Yuval Shaia 
---
 hw/rdma/rdma_rm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 0a5ab8935a..35a96d9a64 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -43,7 +43,7 @@ static inline void res_tbl_free(RdmaRmResTbl *tbl)
 {
 qemu_mutex_destroy(>lock);
 g_free(tbl->tbl);
-bitmap_zero_extend(tbl->bitmap, tbl->tbl_sz, 0);
+g_free(tbl->bitmap);
 }
 
 static inline void *res_tbl_get(RdmaRmResTbl *tbl, uint32_t handle)
-- 
2.17.2

[Qemu-devel] [PATCH v2 10/22] json: Define new QMP message for pvrdma

[Yuval Shaia]

pvrdma requires that the same GID attached to it will be attached to the
backend device in the host.

A new QMP messages is defined so pvrdma device can broadcast any change
made to its GID table. This event is captured by libvirt which in turn
will update the GID table in the backend device.

Signed-off-by: Yuval Shaia 
---
 MAINTAINERS   |  1 +
 Makefile  |  3 ++-
 Makefile.objs |  4 
 qapi/qapi-schema.json |  1 +
 qapi/rdma.json| 38 ++
 5 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 qapi/rdma.json

diff --git a/MAINTAINERS b/MAINTAINERS
index e087d58ac6..a149f68a8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2232,6 +2232,7 @@ F: hw/rdma/*
 F: hw/rdma/vmw/*
 F: docs/pvrdma.txt
 F: contrib/rdmacm-mux/*
+F: qapi/rdma.json
 
 Build and test automation
 -
diff --git a/Makefile b/Makefile
index 94072776ff..db4ce60ee5 100644
--- a/Makefile
+++ b/Makefile
@@ -599,7 +599,8 @@ qapi-modules = $(SRC_PATH)/qapi/qapi-schema.json 
$(SRC_PATH)/qapi/common.json \
$(SRC_PATH)/qapi/tpm.json \
$(SRC_PATH)/qapi/trace.json \
$(SRC_PATH)/qapi/transaction.json \
-   $(SRC_PATH)/qapi/ui.json
+   $(SRC_PATH)/qapi/ui.json \
+   $(SRC_PATH)/qapi/rdma.json
 
 qapi/qapi-builtin-types.c qapi/qapi-builtin-types.h \
 qapi/qapi-types.c qapi/qapi-types.h \
diff --git a/Makefile.objs b/Makefile.objs
index cc7df3ad80..76d8028f2f 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -21,6 +21,7 @@ util-obj-y += qapi/qapi-types-tpm.o
 util-obj-y += qapi/qapi-types-trace.o
 util-obj-y += qapi/qapi-types-transaction.o
 util-obj-y += qapi/qapi-types-ui.o
+util-obj-y += qapi/qapi-types-rdma.o
 util-obj-y += qapi/qapi-builtin-visit.o
 util-obj-y += qapi/qapi-visit.o
 util-obj-y += qapi/qapi-visit-block-core.o
@@ -40,6 +41,7 @@ util-obj-y += qapi/qapi-visit-tpm.o
 util-obj-y += qapi/qapi-visit-trace.o
 util-obj-y += qapi/qapi-visit-transaction.o
 util-obj-y += qapi/qapi-visit-ui.o
+util-obj-y += qapi/qapi-visit-rdma.o
 util-obj-y += qapi/qapi-events.o
 util-obj-y += qapi/qapi-events-block-core.o
 util-obj-y += qapi/qapi-events-block.o
@@ -58,6 +60,7 @@ util-obj-y += qapi/qapi-events-tpm.o
 util-obj-y += qapi/qapi-events-trace.o
 util-obj-y += qapi/qapi-events-transaction.o
 util-obj-y += qapi/qapi-events-ui.o
+util-obj-y += qapi/qapi-events-rdma.o
 util-obj-y += qapi/qapi-introspect.o
 
 chardev-obj-y = chardev/
@@ -155,6 +158,7 @@ common-obj-y += qapi/qapi-commands-tpm.o
 common-obj-y += qapi/qapi-commands-trace.o
 common-obj-y += qapi/qapi-commands-transaction.o
 common-obj-y += qapi/qapi-commands-ui.o
+common-obj-y += qapi/qapi-commands-rdma.o
 common-obj-y += qapi/qapi-introspect.o
 common-obj-y += qmp.o hmp.o
 endif
diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
index 65b6dc2f6f..a650d80f83 100644
--- a/qapi/qapi-schema.json
+++ b/qapi/qapi-schema.json
@@ -94,3 +94,4 @@
 { 'include': 'trace.json' }
 { 'include': 'introspect.json' }
 { 'include': 'misc.json' }
+{ 'include': 'rdma.json' }
diff --git a/qapi/rdma.json b/qapi/rdma.json
new file mode 100644
index 00..804c68ab36
--- /dev/null
+++ b/qapi/rdma.json
@@ -0,0 +1,38 @@
+# -*- Mode: Python -*-
+#
+
+##
+# = RDMA device
+##
+
+##
+# @RDMA_GID_STATUS_CHANGED:
+#
+# Emitted when guest driver adds/deletes GID to/from device
+#
+# @netdev: RoCE Network Device name - char *
+#
+# @gid-status: Add or delete indication - bool
+#
+# @subnet-prefix: Subnet Prefix - uint64
+#
+# @interface-id : Interface ID - uint64
+#
+# Since: 3.2
+#
+# Example:
+#
+# <- {"timestamp": {"seconds": 1541579657, "microseconds": 986760},
+# "event": "RDMA_GID_STATUS_CHANGED",
+# "data":
+# {"netdev": "bridge0",
+# "interface-id": 15880512517475447892,
+# "gid-status": true,
+# "subnet-prefix": 33022}}
+#
+##
+{ 'event': 'RDMA_GID_STATUS_CHANGED',
+  'data': { 'netdev': 'str',
+'gid-status': 'bool',
+'subnet-prefix' : 'uint64',
+'interface-id'  : 'uint64' } }
-- 
2.17.2

[Qemu-devel] [PATCH v2 12/22] vmxnet3: Move some definitions to header file

[Yuval Shaia]

pvrdma setup requires vmxnet3 device on PCI function 0 and PVRDMA device
on PCI function 1.
pvrdma device needs to access vmxnet3 device object for several reasons:
1. Make sure PCI function 0 is vmxnet3.
2. To monitor vmxnet3 device state.
3. To configure node_guid accoring to vmxnet3 device's MAC address.

To be able to access vmxnet3 device the definition of VMXNET3State is
moved to a new header file.

Signed-off-by: Yuval Shaia 
---
 hw/net/vmxnet3.c  | 116 +---
 hw/net/vmxnet3_defs.h | 133 ++
 2 files changed, 134 insertions(+), 115 deletions(-)
 create mode 100644 hw/net/vmxnet3_defs.h

diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 3648630386..54746a4030 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -18,7 +18,6 @@
 #include "qemu/osdep.h"
 #include "hw/hw.h"
 #include "hw/pci/pci.h"
-#include "net/net.h"
 #include "net/tap.h"
 #include "net/checksum.h"
 #include "sysemu/sysemu.h"
@@ -29,6 +28,7 @@
 #include "migration/register.h"
 
 #include "vmxnet3.h"
+#include "vmxnet3_defs.h"
 #include "vmxnet_debug.h"
 #include "vmware_utils.h"
 #include "net_tx_pkt.h"
@@ -131,23 +131,11 @@ typedef struct VMXNET3Class {
 DeviceRealize parent_dc_realize;
 } VMXNET3Class;
 
-#define TYPE_VMXNET3 "vmxnet3"
-#define VMXNET3(obj) OBJECT_CHECK(VMXNET3State, (obj), TYPE_VMXNET3)
-
 #define VMXNET3_DEVICE_CLASS(klass) \
 OBJECT_CLASS_CHECK(VMXNET3Class, (klass), TYPE_VMXNET3)
 #define VMXNET3_DEVICE_GET_CLASS(obj) \
 OBJECT_GET_CLASS(VMXNET3Class, (obj), TYPE_VMXNET3)
 
-/* Cyclic ring abstraction */
-typedef struct {
-hwaddr pa;
-uint32_t size;
-uint32_t cell_size;
-uint32_t next;
-uint8_t gen;
-} Vmxnet3Ring;
-
 static inline void vmxnet3_ring_init(PCIDevice *d,
 Vmxnet3Ring *ring,
  hwaddr pa,
@@ -245,108 +233,6 @@ vmxnet3_dump_rx_descr(struct Vmxnet3_RxDesc *descr)
   descr->rsvd, descr->dtype, descr->ext1, descr->btype);
 }
 
-/* Device state and helper functions */
-#define VMXNET3_RX_RINGS_PER_QUEUE (2)
-
-typedef struct {
-Vmxnet3Ring tx_ring;
-Vmxnet3Ring comp_ring;
-
-uint8_t intr_idx;
-hwaddr tx_stats_pa;
-struct UPT1_TxStats txq_stats;
-} Vmxnet3TxqDescr;
-
-typedef struct {
-Vmxnet3Ring rx_ring[VMXNET3_RX_RINGS_PER_QUEUE];
-Vmxnet3Ring comp_ring;
-uint8_t intr_idx;
-hwaddr rx_stats_pa;
-struct UPT1_RxStats rxq_stats;
-} Vmxnet3RxqDescr;
-
-typedef struct {
-bool is_masked;
-bool is_pending;
-bool is_asserted;
-} Vmxnet3IntState;
-
-typedef struct {
-PCIDevice parent_obj;
-NICState *nic;
-NICConf conf;
-MemoryRegion bar0;
-MemoryRegion bar1;
-MemoryRegion msix_bar;
-
-Vmxnet3RxqDescr rxq_descr[VMXNET3_DEVICE_MAX_RX_QUEUES];
-Vmxnet3TxqDescr txq_descr[VMXNET3_DEVICE_MAX_TX_QUEUES];
-
-/* Whether MSI-X support was installed successfully */
-bool msix_used;
-hwaddr drv_shmem;
-hwaddr temp_shared_guest_driver_memory;
-
-uint8_t txq_num;
-
-/* This boolean tells whether RX packet being indicated has to */
-/* be split into head and body chunks from different RX rings  */
-bool rx_packets_compound;
-
-bool rx_vlan_stripping;
-bool lro_supported;
-
-uint8_t rxq_num;
-
-/* Network MTU */
-uint32_t mtu;
-
-/* Maximum number of fragments for indicated TX packets */
-uint32_t max_tx_frags;
-
-/* Maximum number of fragments for indicated RX packets */
-uint16_t max_rx_frags;
-
-/* Index for events interrupt */
-uint8_t event_int_idx;
-
-/* Whether automatic interrupts masking enabled */
-bool auto_int_masking;
-
-bool peer_has_vhdr;
-
-/* TX packets to QEMU interface */
-struct NetTxPkt *tx_pkt;
-uint32_t offload_mode;
-uint32_t cso_or_gso_size;
-uint16_t tci;
-bool needs_vlan;
-
-struct NetRxPkt *rx_pkt;
-
-bool tx_sop;
-bool skip_current_tx_pkt;
-
-uint32_t device_active;
-uint32_t last_command;
-
-uint32_t link_status_and_speed;
-
-Vmxnet3IntState interrupt_states[VMXNET3_MAX_INTRS];
-
-uint32_t temp_mac;   /* To store the low part first */
-
-MACAddr perm_mac;
-uint32_t vlan_table[VMXNET3_VFT_SIZE];
-uint32_t rx_mode;
-MACAddr *mcast_list;
-uint32_t mcast_list_len;
-uint32_t mcast_list_buff_size; /* needed for live migration. */
-
-/* Compatibility flags for migration */
-uint32_t compat_flags;
-} VMXNET3State;
-
 /* Interrupt management */
 
 /*
diff --git a/hw/net/vmxnet3_defs.h b/hw/net/vmxnet3_defs.h
new file mode 100644
index 00..6c19d29b12
--- /dev/null
+++ b/hw/net/vmxnet3_defs.h
@@ -0,0 +1,133 @@
+/*
+ * QEMU VMWARE VMXNET3 

[Qemu-devel] [PATCH v2 14/22] hw/rdma: Initialize node_guid from vmxnet3 mac address

[Yuval Shaia]

node_guid should be set once device is load.
Make node_guid be GID format (32 bit) of PCI function 0 vmxnet3 device's
MAC.

A new function was added to do the conversion.
So for example the MAC 56:b6:44:e9:62:dc will be converted to GID
54b6:44ff:fee9:62dc.

Signed-off-by: Yuval Shaia 
---
 hw/rdma/rdma_utils.h  |  9 +
 hw/rdma/vmw/pvrdma_cmd.c  | 10 --
 hw/rdma/vmw/pvrdma_main.c |  5 -
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/hw/rdma/rdma_utils.h b/hw/rdma/rdma_utils.h
index 989db249ef..202abb3366 100644
--- a/hw/rdma/rdma_utils.h
+++ b/hw/rdma/rdma_utils.h
@@ -63,4 +63,13 @@ extern unsigned long pr_dbg_cnt;
 void *rdma_pci_dma_map(PCIDevice *dev, dma_addr_t addr, dma_addr_t plen);
 void rdma_pci_dma_unmap(PCIDevice *dev, void *buffer, dma_addr_t len);
 
+static inline void addrconf_addr_eui48(uint8_t *eui, const char *addr)
+{
+memcpy(eui, addr, 3);
+eui[3] = 0xFF;
+eui[4] = 0xFE;
+memcpy(eui + 5, addr + 3, 3);
+eui[0] ^= 2;
+}
+
 #endif
diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma/vmw/pvrdma_cmd.c
index a334f6205e..2979582fac 100644
--- a/hw/rdma/vmw/pvrdma_cmd.c
+++ b/hw/rdma/vmw/pvrdma_cmd.c
@@ -592,16 +592,6 @@ static int create_bind(PVRDMADev *dev, union 
pvrdma_cmd_req *req,
 return -EINVAL;
 }
 
-/* TODO: Since drivers stores node_guid at load_dsr phase then this
- * assignment is not relevant, i need to figure out a way how to
- * retrieve MAC of our netdev */
-if (!cmd->index) {
-dev->node_guid =
-dev->rdma_dev_res.ports[0].gid_tbl[0].gid.global.interface_id;
-pr_dbg("dev->node_guid=0x%llx\n",
-   (long long unsigned int)be64_to_cpu(dev->node_guid));
-}
-
 return 0;
 }
 
diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c
index fa6468d221..95e9322b7c 100644
--- a/hw/rdma/vmw/pvrdma_main.c
+++ b/hw/rdma/vmw/pvrdma_main.c
@@ -264,7 +264,7 @@ static void init_dsr_dev_caps(PVRDMADev *dev)
 dsr->caps.sys_image_guid = 0;
 pr_dbg("sys_image_guid=%" PRIx64 "\n", dsr->caps.sys_image_guid);
 
-dsr->caps.node_guid = cpu_to_be64(dev->node_guid);
+dsr->caps.node_guid = dev->node_guid;
 pr_dbg("node_guid=%" PRIx64 "\n", be64_to_cpu(dsr->caps.node_guid));
 
 dsr->caps.phys_port_cnt = MAX_PORTS;
@@ -579,6 +579,9 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp)
 /* Break if not vmxnet3 device in slot 0 */
 dev->func0 = VMXNET3(pci_get_function_0(pdev));
 
+addrconf_addr_eui48((unsigned char *)>node_guid,
+(const char *)>func0->conf.macaddr.a);
+
 memdev_root = object_resolve_path("/objects", NULL);
 if (memdev_root) {
 object_child_foreach(memdev_root, pvrdma_check_ram_shared, 
_shared);
-- 
2.17.2