Re: [Qemu-devel] [PATCH v2] cirrus.yml: Add macOS continuous integration task

2019-03-07 Thread Paolo Bonzini
On 08/03/19 08:20, Thomas Huth wrote:
> cirrus-ci.com also has the possibility to run CI tasks on macOS.
> Since most of the QEMU developers do not have access to macOS yet,
> let's add a CI pipeline for this operating system here, too.
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> Acked-by: Ed Maste 
> Signed-off-by: Thomas Huth 

Acked-by: Paolo Bonzini 

> ---
>  v2:
>  - Move CIRRUS_CLONE_DEPTH to generic part
>  - Use python from brew
>  - Use mojave-base instead of high-sierra-base
> 
>  .cirrus.yml | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 303fe72..47ef5bc 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -1,10 +1,11 @@
> +env:
> +  CIRRUS_CLONE_DEPTH: 1
> +
>  freebsd_12_task:
>freebsd_instance:
>  image: freebsd-12-0-release-amd64
>  cpu: 8
>  memory: 8G
> -  env:
> -CIRRUS_CLONE_DEPTH: 1
>install_script: pkg install -y
>  bison curl cyrus-sasl git glib gmake gnutls
>  nettle perl5 pixman pkgconf png usbredir
> @@ -14,3 +15,13 @@ freebsd_12_task:
>  - ../configure || { cat config.log; exit 1; }
>  - gmake -j8
>  - gmake -j8 V=1 check
> +
> +macos_task:
> +  osx_instance:
> +image: mojave-base
> +  install_script:
> +- brew install pkg-config python glib pixman make sdl2
> +  script:
> +- ./configure --python=/usr/local/bin/python3 || { cat config.log; exit 
> 1; }
> +- gmake -j$(sysctl -n hw.ncpu)
> +- gmake check -j$(sysctl -n hw.ncpu)
> 




Re: [Qemu-devel] [PATCH v5-resend 2/2] mips_fulong2e: Add on-board graphics chip

2019-03-07 Thread Gerd Hoffmann
On Thu, Mar 07, 2019 at 01:32:41AM +0100, Philippe Mathieu-Daudé wrote:
> On 3/6/19 9:05 PM, BALATON Zoltan wrote:
> > Add (partial) emulation of the on-board GPU of the machine. This
> > allows the PMON2000 firmware to run and should also work with Linux
> > console but probably not with X yet.
> > 
> > Signed-off-by: BALATON Zoltan 
> > Reviewed-by: Philippe Mathieu-Daudé 
> > Tested-by: Philippe Mathieu-Daudé 
> 
> Mojibaked again :(

Mail was sent without Content-Type: header.  Both mutt and "git am" on
my machine assume utf-8 and everything looks fine.  I guess your mail
client assumes something else ...

"git send-email" should send the patches with correct headers, it even
asks for the charset it should use in case it finds non-ascii
characters.  So BALATON, could you check your mail client config, or
switch over to "git send-email" for submitting patches?

cheers,
  Gerd




Re: [Qemu-devel] [PATCH v3 07/14] ppc405_boards: Don't size flash memory to match backing image

2019-03-07 Thread Markus Armbruster
David Gibson  writes:

> On Thu, Mar 07, 2019 at 02:03:16PM +0100, Markus Armbruster wrote:
>> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
>> Image size is rounded up to the next multiple of 64KiB.  Useless,
>> because pflash_cfi02_realize() fails with "failed to read the initial
>> flash content" unless the rounding is a no-op.
>> 
>> If the image size exceeds 0x8 Bytes, we overlap first SRAM, then
>> other stuff.  No idea how that would play out, but useful outcomes
>> seem unlikely.
>> 
>> Map the flash memory at fixed address 0xFFF8 with size 512KiB,
>> regardless of image size, to match the physical hardware.
>> 
>> Machine "taihu" maps its boot flash memory similarly.  The code even
>> has a comment /* XXX: should check that size is 2MB */, followed by
>> disabled code to adjust the size to 2MiB regardless of image size.
>> 
>> Its code to map its application flash memory looks the same, except
>> there the XXX comment asks for 32MiB, and the code to adjust the size
>> isn't disabled.  Note that pflash_cfi02_realize() fails with "failed
>> to read the initial flash content" for images smaller than 32MiB.
>> 
>> Map the boot flash memory at fixed address 0xFFE0 with size 2MiB,
>> to match the physical hardware.  Delete dead code from application
>> flash mapping, and simplify some.
>> 
>> Cc: David Gibson 
>> Signed-off-by: Markus Armbruster 
>> Acked-by: David Gibson 
>> Reviewed-by: Alex Bennée 
>
> I'm assuming because this is in a series I'm not otherwise CCed on
> that this is going in through someone else's tree.  Let me know if you
> want me take it through mine.

I intend to take the complete series through my tree unless a maintainer
objects.



Re: [Qemu-devel] [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility

2019-03-07 Thread Yaowei Bai
> > > * The first priority should be adding an in-process iscsi target that
> > >   can be managed with QMP, similar to the built-in NBD server.
> > 
> > Well, people used to manage iscsi targets through targetcli, a command
> > line utility. Our intention is, with targetcli and qemu-tcmu, user can
> > create/remove targets and backstores totally in just one place, so you
> > don't need to create targets in targetcli and then turn to configure
> > backstores in qemu-tcmu with QMP or command line, it's convenient.  So
> > we decide to implement QMP in the future release but it's definitely
> > in our plan.
> 
> I think QMP needs to come first to result in a clean design, because the
> command line tool should only be a wrapper around the QMP code.

Yeah, i agree this makes more sense from this point. Ok, i'll try to
implement it in v2 as your suggestion. Thanks.

> But anyway, I still think the change I had in mind is necessary. Maybe
> you can see the difference best in an example. Your documentation says
> to use this:
> 
> # qemu-tcmu
> # targetcli /backstores/user:qemu create qemulun 1G 
> @id=test@file=/root/test.file

Let's call this one case1.

> 
> I think it should work more like this:
> 
> # qemu-tcmu -blockdev 
> driver=file,filename=/root/test.file,node-name=my_file \
> -export my_export,node=my_file
> # targetcli /backstores/user:qemu create qemulun 1G my_export

And this one case2.

> 
> In fact, something like this is probably required if we want to export
> existing block nodes (that may be in use by a guest) from a running QEMU
> instance. In this case, you don't want to open a new image file, but
> export the already opened image file.

I think the main difference between these two cases is just how the 
configuration
of exported image file is passed to qemu-tcmu. Case1 uses cfgstr while case2
uses command line. Case2 still needs one way to check whether the passed-in
image file was opened, right? If so, case1 should also be able to use the same
way to check that after extracting cfgstr. 

Actually we thought about qemu-tcmu working like case2, but felt is's quite less
flexible. With case2, e.g. when we want to export another new image file with
one qemu-tcmu already running, we have to run another qemu-tcmu with
the configuration of the new image file in commandline, or through QMP of the
running qemu-tcmu, and then configure it with targetcli. So anyway,
there's one more step for case2 to export a new image file. While for case1 
you just need to run qemu-tcmu once and all other operations will be done
within targetcli, which is more friendly to users i think.

So i think qemu-tcmu's quite different from qemu-nbd at this point. We can
export a image file by NBD protocol just with qemu-nbd itself. While for
qemu-tcmu we still need targetcli to complete other ISCSI target
configurations to export a image file. So moving the configuration of image
file from cmdline to targetcli should be reasonable in my opinion.

> 
> (Also, can we somehow get rid of the 1G in the command line? qemu-tcmu
> knows how big the image is and can provide this value.)

Currently this size option is mandatory in targetcli, not all tools are
so smart as QEMU. But maybe we could change it optional in the future.






[Qemu-devel] [PATCH v2] cirrus.yml: Add macOS continuous integration task

2019-03-07 Thread Thomas Huth
cirrus-ci.com also has the possibility to run CI tasks on macOS.
Since most of the QEMU developers do not have access to macOS yet,
let's add a CI pipeline for this operating system here, too.

Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Ed Maste 
Signed-off-by: Thomas Huth 
---
 v2:
 - Move CIRRUS_CLONE_DEPTH to generic part
 - Use python from brew
 - Use mojave-base instead of high-sierra-base

 .cirrus.yml | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index 303fe72..47ef5bc 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -1,10 +1,11 @@
+env:
+  CIRRUS_CLONE_DEPTH: 1
+
 freebsd_12_task:
   freebsd_instance:
 image: freebsd-12-0-release-amd64
 cpu: 8
 memory: 8G
-  env:
-CIRRUS_CLONE_DEPTH: 1
   install_script: pkg install -y
 bison curl cyrus-sasl git glib gmake gnutls
 nettle perl5 pixman pkgconf png usbredir
@@ -14,3 +15,13 @@ freebsd_12_task:
 - ../configure || { cat config.log; exit 1; }
 - gmake -j8
 - gmake -j8 V=1 check
+
+macos_task:
+  osx_instance:
+image: mojave-base
+  install_script:
+- brew install pkg-config python glib pixman make sdl2
+  script:
+- ./configure --python=/usr/local/bin/python3 || { cat config.log; exit 1; 
}
+- gmake -j$(sysctl -n hw.ncpu)
+- gmake check -j$(sysctl -n hw.ncpu)
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v5 04/14] audio: -audiodev command line option basic implementation

2019-03-07 Thread Markus Armbruster
"Zoltán Kővágó"  writes:

> On 2019-03-07 16:56, Gerd Hoffmann wrote:
>> On Tue, Feb 26, 2019 at 02:39:38AM +0100, Zoltán Kővágó wrote:
>>> On 2019-02-20 22:37, Kővágó, Zoltán wrote:
>>> [...]
 diff --git a/audio/audio.c b/audio/audio.c
 index ce8e6ea8c2..8ad8cbe559 100644
 --- a/audio/audio.c
 +++ b/audio/audio.c
>>> [...]
 @@ -2129,3 +1866,170 @@ void AUD_set_volume_in (SWVoiceIn *sw, int mute, 
 uint8_t lvol, uint8_t rvol)
  }
  }
  }
 +
 +void audio_create_pdos(Audiodev *dev)
 +{
 +switch (dev->driver) {
 +#define CASE(DRIVER, driver, pdo_name)  \
 +case AUDIODEV_DRIVER_##DRIVER:  \
 +dev->u.driver.in = g_malloc0(   \
 +sizeof(Audiodev##pdo_name##PerDirectionOptions));   \
>>> This should check has_in before overwriting. It'll work correctly when
>>> called from audio_legacy.c, but when using -audiodev it will overwrite
>>> the options passed by user (and leak memory) when called from
>>> audio_validate_opts. I'll fix it in the next update.
>> 
>> Ping.  4.0 freeze is next tuesday.  Any chance for a v6 early enough
>> that we have a chance to get the first chunk into 4.0?  Monday latest,
>> preferably earlier ...
>
> I'll try to do something this weekend, but I can't promise anything. I
> still haven't got to reading through Markus' comments...

Quoting myself: "We're down to minor stylistic issues.  Good work!"

Addressing these should not be hard.



Re: [Qemu-devel] [PATCH qemu v5] spapr: Support NVIDIA V100 GPU with NVLink2

2019-03-07 Thread Alexey Kardashevskiy



On 08/03/2019 15:30, David Gibson wrote:
> On Fri, Mar 08, 2019 at 12:44:20PM +1100, Alexey Kardashevskiy wrote:
>> NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
>> space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
>> implements special regions for such GPUs and emulates an NVLink bridge.
>> NVLink2-enabled POWER9 CPUs also provide address translation services
>> which includes an ATS shootdown (ATSD) register exported via the NVLink
>> bridge device.
>>
>> This adds a quirk to VFIO to map the GPU memory and create an MR;
>> the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
>> this to get the MR and map it to the system address space.
>> Another quirk does the same for ATSD.
>>
>> This adds additional steps to sPAPR PHB setup:
>>
>> 1. Search for specific GPUs and NPUs, collect findings in
>> sPAPRPHBState::nvgpus, manage system address space mappings;
>>
>> 2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
>> "memory-block", "link-speed" to advertise the NVLink2 function to
>> the guest;
>>
>> 3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
>>
>> 4. Add new memory blocks (with extra "linux,memory-usable" to prevent
>> the guest OS from accessing the new memory until it is onlined) and
>> npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
>> uses it for link discovery.
>>
>> This allocates space for GPU RAM and ATSD like we do for MMIOs by
>> adding 2 new parameters to the phb_placement() hook. Older machine types
>> set these to zero.
>>
>> This puts new memory nodes in a separate NUMA node to replicate the host
>> system setup as the GPU driver relies on this.
>>
>> This adds requirement similar to EEH - one IOMMU group per vPHB.
>> The reason for this is that ATSD registers belong to a physical NPU
>> so they cannot invalidate translations on GPUs attached to another NPU.
>> It is guaranteed by the host platform as it does not mix NVLink bridges
>> or GPUs from different NPU in the same IOMMU group. If more than one
>> IOMMU group is detected on a vPHB, this disables ATSD support for that
>> vPHB and prints a warning.
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>>
>> This is based on David's ppc-for-4.0 +
>> applied but not pushed "iommu replay": 
>> https://patchwork.ozlabs.org/patch/1052644/
>> acked "vfio_info_cap public": https://patchwork.ozlabs.org/patch/1052645/
>>
>>
>> Changes:
>> v5:
>> * converted MRs to VFIOQuirk - this fixed leaks
>>
>> v4:
>> * fixed ATSD placement
>> * fixed spapr_phb_unrealize() to do nvgpu cleanup
>> * replaced warn_report() with Error*
>>
>> v3:
>> * moved GPU RAM above PCI MMIO limit
>> * renamed QOM property to nvlink2-tgt
>> * moved nvlink2 code to its own file
>>
>> ---
>>
>> The example command line for redbud system:
>>
>> pbuild/qemu-aiku1804le-ppc64/ppc64-softmmu/qemu-system-ppc64 \
>> -nodefaults \
>> -chardev stdio,id=STDIO0,signal=off,mux=on \
>> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
>> -mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
>> -enable-kvm -m 384G \
>> -chardev socket,id=SOCKET0,server,nowait,host=localhost,port=4 \
>> -mon chardev=SOCKET0,mode=control \
>> -smp 80,sockets=1,threads=4 \
>> -netdev "tap,id=TAP0,helper=/home/aik/qemu-bridge-helper --br=br0" \
>> -device "virtio-net-pci,id=vnet0,mac=52:54:00:12:34:56,netdev=TAP0" \
>> img/vdisk0.img \
>> -device "vfio-pci,id=vfio0004_04_00_0,host=0004:04:00.0" \
>> -device "vfio-pci,id=vfio0006_00_00_0,host=0006:00:00.0" \
>> -device "vfio-pci,id=vfio0006_00_00_1,host=0006:00:00.1" \
>> -device "vfio-pci,id=vfio0006_00_00_2,host=0006:00:00.2" \
>> -device "vfio-pci,id=vfio0004_05_00_0,host=0004:05:00.0" \
>> -device "vfio-pci,id=vfio0006_00_01_0,host=0006:00:01.0" \
>> -device "vfio-pci,id=vfio0006_00_01_1,host=0006:00:01.1" \
>> -device "vfio-pci,id=vfio0006_00_01_2,host=0006:00:01.2" \
>> -device spapr-pci-host-bridge,id=phb1,index=1 \
>> -device "vfio-pci,id=vfio0035_03_00_0,host=0035:03:00.0" \
>> -device "vfio-pci,id=vfio0007_00_00_0,host=0007:00:00.0" \
>> -device "vfio-pci,id=vfio0007_00_00_1,host=0007:00:00.1" \
>> -device "vfio-pci,id=vfio0007_00_00_2,host=0007:00:00.2" \
>> -device "vfio-pci,id=vfio0035_04_00_0,host=0035:04:00.0" \
>> -device "vfio-pci,id=vfio0007_00_01_0,host=0007:00:01.0" \
>> -device "vfio-pci,id=vfio0007_00_01_1,host=0007:00:01.1" \
>> -device "vfio-pci,id=vfio0007_00_01_2,host=0007:00:01.2" -snapshot \
>> -machine pseries \
>> -L /home/aik/t/qemu-ppc64-bios/ -d guest_errors
>>
>> Note that QEMU attaches PCI devices to the last added vPHB so first
>> 8 devices - 4:04:00.0 till 6:00:01.2 - go to the default vPHB, and
>> 35:03:00.0..7:00:01.2 to the vPHB with id=phb1.
>> ---
>>  hw/ppc/Makefile.objs|   2 +-
>>  hw/vfio/pci.h   |   2 +
>>  include/hw/pci-host/spapr.h |  45 
>>  include/hw/ppc/spapr.h  |   3 +-
>>  hw/ppc/spapr.c  |  29 ++-
>>  hw/ppc/spapr_pci.c   

[Qemu-devel] [Bug 1818880] Re: Deadlock when detaching network interface

2019-03-07 Thread Thomas Huth
** No longer affects: 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/1818880

Title:
  Deadlock when detaching network interface

Status in Ubuntu Cloud Archive:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Confirmed
Status in qemu source package in Bionic:
  Fix Released
Status in qemu source package in Cosmic:
  Fix Released
Status in qemu source package in Disco:
  Fix Released

Bug description:
  [Impact]
  Qemu guests hang indefinitely

  [Description]
  When running a Qemu guest with VirtIO network interfaces, detaching an 
interface that's currently being used can result in a deadlock. The guest 
instance will hang and become unresponsive to commands, and the only option is 
to kill -9 the instance.
  The reason for this is a dealock between a monitor and an RCU thread, which 
will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. 
The monitor thread will acquire the BQL for detaching the network interface, 
and fire up a helper thread to deal with detaching the network adapter. That 
new thread needs to wait on the RCU thread to complete the deletion, but the 
RCU thread wants the BQL to commit its transactions.
  This bug is already fixed upstream (73c6e4013b4c rcu: completely disable 
pthread_atfork callbacks as soon as possible) and included for other series 
(see below), so we don't need to backport it to Bionic onwards.

  Upstream commit:
  https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c

  $ git describe --contains 73c6e4013b4c
  v2.10.0-rc2~1^2~8

  $ rmadison qemu
  ===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe   | amd64, ...
   qemu | 1:2.11+dfsg-1ubuntu7| bionic/universe   | amd64, ...
   qemu | 1:2.12+dfsg-3ubuntu8| cosmic/universe   | amd64, ...
   qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe| amd64, ...

  [Test Case]
  Being a racing condition, this is a tricky bug to reproduce consistently. 
We've had reports of users running into this with OpenStack deployments and 
Windows Server guests, and the scenario is usually like this:
  1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network 
interface
  2) Stress the network interface with e.g. Windows HLK test suite or similar
  3) Repeatedly attach/detach the network adapter that's in use
  It usually takes more than ~4000 attach/detach cycles to trigger the bug.

  [Regression Potential]
  Regressions for this might arise from the fact that the fix changes RCU lock 
code. Since this patch has been upstream and in other series for a while, it's 
unlikely that it would regressions in RCU code specifically. Other code that 
makes use of the RCU locks (MMIO and some monitor events) will be thoroughly 
tested for any regressions with use-case scenarios and scripted runs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions



Re: [Qemu-devel] [PATCH] cirrus.yml: Add macOS continuous integration task

2019-03-07 Thread Thomas Huth
On 07/03/2019 22.52, Li-Wen Hsu wrote:
> On Fri, Mar 8, 2019 at 4:30 AM Thomas Huth  wrote:
>>
>> On 07/03/2019 21.26, Ed Maste wrote:
>>> On Mon, 4 Mar 2019 at 07:11, Philippe Mathieu-Daudé  
>>> wrote:

 On 3/4/19 11:32 AM, Thomas Huth wrote:
> cirrus-ci.com also has the possibility to run CI tasks on macOS.
> Since most of the QEMU developers do not have access to macOS yet,
> let's add a CI pipeline for this operating system here, too.

> Signed-off-by: Thomas Huth 
 Reviewed-by: Philippe Mathieu-Daudé 
>>> Acked-by: Ed Maste 
>>
>> Thanks! I can take this patch through my qtest tree.
> 
> Hi Thomas,
> 
> Sorry for the late reply, I checked and tested the patch, it works
> fine.  BTW, may I suggest:
> 
> From https://cirrus-ci.org/guide/macOS/ , the image high-sierra-base
> is lasted as "Not maintained", how about change to mojave-base?

Definitely! Not sure how I could have missed that... I was either blind,
or, how I remember it, the high-sierra-base image was not marked as
unmaintained yet and marked as the only image that had the brew system
pre-installed back then. Anyway, I've now switched to mojave-base and it
seems to work fine, too.

> Also, perhaps we can put the common:
> 
> env:
>   CIRRUS_CLONE_DEPTH: 1
> 
> in the global area?

Sure! I'll do that in v2.

 Thanks for the review,
  Thomas



Re: [Qemu-devel] [PATCH] cirrus.yml: Add macOS continuous integration task

2019-03-07 Thread Thomas Huth
On 07/03/2019 22.10, Paolo Bonzini wrote:
> On 04/03/19 12:08, Philippe Mathieu-Daudé wrote:
>> +macos_task:
>> +  osx_instance:
>> +image: high-sierra-base
>> +  env:
>> +CIRRUS_CLONE_DEPTH: 1
>> +  install_script:
>> +- brew install pkg-config glib pixman make sdl2
> 
> Could you also install Python 3 ("python" in Homebrew is 3.7) and avoid
> Apple's obsolete /usr/bin/python (also needs something like
> --python=/usr/local/bin/python3 in ./configure below).

Yes, can do.

 Thomas




Re: [Qemu-devel] [PATCH v2 12/18] hw/nvram/fw_cfg: Keep reference of file_data in FWCfgState

2019-03-07 Thread Thomas Huth
On 08/03/2019 02.32, Philippe Mathieu-Daudé wrote:
> The 'file_data' is allocated by read_splashfile() (introduced in
> commit 3d3b8303c6f8).  It is then used by fw_cfg_add_file(). Due
> to the contract interface of fw_cfg_add_file(), it has to be valid
> for the lifetime of the FwCfg object.
> 
> Keep a reference of 'file_data' in FWCfgState to be able to
> free this memory in fw_cfg_common_unrealize().
> We can now remove the res_free() from the main() loop.
> The global boot_splash_filedata is now unused, remove it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/nvram/fw_cfg.c | 10 ++
>  include/hw/nvram/fw_cfg.h |  1 +
>  include/sysemu/sysemu.h   |  1 -
>  vl.c  |  9 -
>  4 files changed, 7 insertions(+), 14 deletions(-)

Reviewed-by: Thomas Huth 



[Qemu-devel] [Bug 1819108] [NEW] qemu-bridge-helper failure but qemu not exit

2019-03-07 Thread cavanxg
Public bug reported:

When qemu-bridge-helper run failed, its parent process qemu is still alive.
This is my command line:

qemu-system-x86_64 -curses -enable-kvm -cpu host -smp 4 -m 4096 \
  -vnc :1 \
  -kernel /data/xugang_vms/boot/vmlinuz \
  -initrd /data/xugang_vms/boot/initram \
  -append 'module_blacklist=drm,evbug net.ifnames=0 biosdevname=0 
ROOTDEV=rootfs' \
  -drive file=/data/xugang_vms/instances/vn7/rootfs.img,format=qcow2,if=virtio \
  -monitor unix:/data/xugang_vms/var/monitor/vn7.sock,server,nowait \
  -netdev bridge,br=vmbr99,helper="/root/bridgehelper --ns=kvm_1 ",id=n1 
-device virtio-net,netdev=n1,mac=92:99:98:76:01:07

"/root/bridgehelper" is self defined helper binary by me. But after
bridge-helper exited with failure(not send fd to qemu process yet), the
linux vm's console will be messed up. I checked the qemu source code(at
net/tap.c) and found following snip:

===>
do {
fd = recv_fd(sv[0]);
} while (fd == -1 && errno == EINTR);
saved_errno = errno;

close(sv[0]);

while (waitpid(pid, , 0) != pid) {
/* loop */
}
<=

why recv_fd will infinitely wait for recv? Maybe it shall waitpid and
then recv_fd ?

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu-bridge-helper failure but qemu not exit

Status in QEMU:
  New

Bug description:
  When qemu-bridge-helper run failed, its parent process qemu is still alive.
  This is my command line:

  qemu-system-x86_64 -curses -enable-kvm -cpu host -smp 4 -m 4096 \
-vnc :1 \
-kernel /data/xugang_vms/boot/vmlinuz \
-initrd /data/xugang_vms/boot/initram \
-append 'module_blacklist=drm,evbug net.ifnames=0 biosdevname=0 
ROOTDEV=rootfs' \
-drive 
file=/data/xugang_vms/instances/vn7/rootfs.img,format=qcow2,if=virtio \
-monitor unix:/data/xugang_vms/var/monitor/vn7.sock,server,nowait \
-netdev bridge,br=vmbr99,helper="/root/bridgehelper --ns=kvm_1 ",id=n1 
-device virtio-net,netdev=n1,mac=92:99:98:76:01:07

  "/root/bridgehelper" is self defined helper binary by me. But after
  bridge-helper exited with failure(not send fd to qemu process yet),
  the linux vm's console will be messed up. I checked the qemu source
  code(at net/tap.c) and found following snip:

  ===>
  do {
  fd = recv_fd(sv[0]);
  } while (fd == -1 && errno == EINTR);
  saved_errno = errno;

  close(sv[0]);

  while (waitpid(pid, , 0) != pid) {
  /* loop */
  }
  <=

  why recv_fd will infinitely wait for recv? Maybe it shall waitpid and
  then recv_fd ?

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



Re: [Qemu-devel] converting build system to Meson?

2019-03-07 Thread Thomas Huth
On 08/03/2019 07.47, Gerd Hoffmann wrote:
>   Hi,
> 
>>> As an aside, it might be a nice idea to drop the in-srcdir
>>> build altogether for QEMU anyway -- it's not really a very
>>> good idea and it means our build system has to cope with two
>>> different ways of working to no particularly useful end.
>>
>> I was actually going to propose that, but I was afraid of throwing two
>> bombs in the same day. :)
> 
> I stopped using in-tree builds years ago.  When test-building different
> configurations using an build/$cfgname out-of-tree build directory is
> the only sane approach.  And IIRC I've managed to break in-tree builds
> because of that.

FWIW, I'm also only doing out-of-tree builds. Thus I'd support a patch,
too, which enforces out of tree builds.

 Thomas



Re: [Qemu-devel] [PATCH v2 07/18] hw/nvram/fw_cfg: Add fw_cfg_common_unrealize()

2019-03-07 Thread Thomas Huth
On 08/03/2019 02.32, Philippe Mathieu-Daudé wrote:
> Back in abe147e0ce4 when fw_cfg_add_file() was introduced, there
> was no QOM design, object where not created and released at runtime.
> Later 38f3adc34d finished the QOM conversion of the fw_cfg device,
> adding the fw_cfg_common_realize() method.
> The time has come to add the equivalent destructor and release the
> memory allocated for 'files'.

You should mention that the unrealize function is currently never called
since the object never gets destroyed (AFAIK). But I hope we can fix
that in the not so distant future, so:

Reviewed-by: Thomas Huth 



Re: [Qemu-devel] [PATCH v2 05/15] ppc/pnv: add a 'dt_isa_nodename' to the chip

2019-03-07 Thread Cédric Le Goater
On 3/8/19 1:01 AM, David Gibson wrote:
> On Thu, Mar 07, 2019 at 11:35:38PM +0100, Cédric Le Goater wrote:
>> The ISA bus has a different DT nodename on POWER9. Compute the name
>> when the PnvChip is realized, that is before it is used by the machine
>> to populate the device tree with the ISA devices.
>>
>> Signed-off-by: Cédric Le Goater 
> 
> I still tend to think that passing an offset into pnv_dt_isa would
> have been a better solution, but this will serve.  Applied.

Do you mean something like below possibly ? 

   int isa_offset = fdt_path_offset(fdt, pnv->chips[0]->dt_isa_nodename);

   /* Populate ISA devices on chip 0 */
   pnv_dt_isa(pnv->isa_bus, fdt, isa_offset);


pnv_dt_isa() is called at the machine level but we could change it
to be called at the chip level for chip0 only.

C.


>> ---
>>  include/hw/ppc/pnv.h |  2 ++
>>  hw/ppc/pnv.c | 18 +-
>>  2 files changed, 7 insertions(+), 13 deletions(-)
>>
>> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
>> index 8d80cb34eebb..c81f157f41a9 100644
>> --- a/include/hw/ppc/pnv.h
>> +++ b/include/hw/ppc/pnv.h
>> @@ -58,6 +58,8 @@ typedef struct PnvChip {
>>  MemoryRegion xscom_mmio;
>>  MemoryRegion xscom;
>>  AddressSpace xscom_as;
>> +
>> +gchar*dt_isa_nodename;
>>  } PnvChip;
>>  
>>  #define TYPE_PNV8_CHIP "pnv8-chip"
>> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
>> index 922e3ec48bb5..6625562d276d 100644
>> --- a/hw/ppc/pnv.c
>> +++ b/hw/ppc/pnv.c
>> @@ -417,24 +417,12 @@ static int pnv_dt_isa_device(DeviceState *dev, void 
>> *opaque)
>>  return 0;
>>  }
>>  
>> -static int pnv_chip_isa_offset(PnvChip *chip, void *fdt)
>> -{
>> -char *name;
>> -int offset;
>> -
>> -name = g_strdup_printf("/xscom@%" PRIx64 "/isa@%x",
>> -   (uint64_t) PNV_XSCOM_BASE(chip), 
>> PNV_XSCOM_LPC_BASE);
>> -offset = fdt_path_offset(fdt, name);
>> -g_free(name);
>> -return offset;
>> -}
>> -
>>  /* The default LPC bus of a multichip system is on chip 0. It's
>>   * recognized by the firmware (skiboot) using a "primary" property.
>>   */
>>  static void pnv_dt_isa(PnvMachineState *pnv, void *fdt)
>>  {
>> -int isa_offset = pnv_chip_isa_offset(pnv->chips[0], fdt);
>> +int isa_offset = fdt_path_offset(fdt, pnv->chips[0]->dt_isa_nodename);
>>  ForeachPopulateArgs args = {
>>  .fdt = fdt,
>>  .offset = isa_offset,
>> @@ -866,6 +854,10 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
>> Error **errp)
>>   _fatal);
>>  pnv_xscom_add_subregion(chip, PNV_XSCOM_LPC_BASE, 
>> >lpc.xscom_regs);
>>  
>> +chip->dt_isa_nodename = g_strdup_printf("/xscom@%" PRIx64 "/isa@%x",
>> +(uint64_t) PNV_XSCOM_BASE(chip),
>> +PNV_XSCOM_LPC_BASE);
>> +
>>  /* Interrupt Management Area. This is the memory region holding
>>   * all the Interrupt Control Presenter (ICP) registers */
>>  pnv_chip_icp_realize(chip8, _err);
> 




Re: [Qemu-devel] [PATCH v2 06/18] hw/nvram/fw_cfg: Remove the unnecessary boot_splash_filedata_size

2019-03-07 Thread Thomas Huth
On 08/03/2019 02.32, Philippe Mathieu-Daudé wrote:
> The 'boot_splash_filedata_size' was introduced as a global variable
> in 3d3b8303c6f. This variable is used as a 'size' argument to the
> fw_cfg_add_file(). This function has an interface contract with his
> 'data' argument, but there is no such contract for 'size' (this is
> not a referenced pointer).  We can simply remove it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/nvram/fw_cfg.c   | 5 ++---
>  include/sysemu/sysemu.h | 1 -
>  vl.c| 1 -
>  3 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 8eb76a382c..b2dc0a80cb 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -217,15 +217,14 @@ static void fw_cfg_bootsplash(FWCfgState *s)
>  }
>  g_free(boot_splash_filedata);
>  boot_splash_filedata = (uint8_t *)file_data;
> -boot_splash_filedata_size = file_size;
>  
>  /* insert data */
>  if (file_type == JPG_FILE) {
>  fw_cfg_add_file(s, "bootsplash.jpg",
> -boot_splash_filedata, boot_splash_filedata_size);
> +boot_splash_filedata, file_size);
>  } else {
>  fw_cfg_add_file(s, "bootsplash.bmp",
> -boot_splash_filedata, boot_splash_filedata_size);
> +boot_splash_filedata, file_size);
>  }
>  g_free(filename);
>  }
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index 89604a8328..6065d9e420 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -110,7 +110,6 @@ extern int old_param;
>  extern int boot_menu;
>  extern bool boot_strict;
>  extern uint8_t *boot_splash_filedata;
> -extern size_t boot_splash_filedata_size;
>  extern bool enable_mlock;
>  extern bool enable_cpu_pm;
>  extern QEMUClockType rtc_clock;
> diff --git a/vl.c b/vl.c
> index 4c5cc0d8ad..fad6fec38c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -188,7 +188,6 @@ const char *prom_envs[MAX_PROM_ENVS];
>  int boot_menu;
>  bool boot_strict;
>  uint8_t *boot_splash_filedata;
> -size_t boot_splash_filedata_size;
>  bool wakeup_suspend_enabled;
>  
>  int icount_align_option;
> 

Nice, one global variable less!

Reviewed-by: Thomas Huth 



Re: [Qemu-devel] [PATCH 18/27] ppc/pnv: add a LPC Controller model for POWER9

2019-03-07 Thread Cédric Le Goater
On 3/8/19 1:19 AM, David Gibson wrote:
> On Thu, Mar 07, 2019 at 08:07:41AM +0100, Cédric Le Goater wrote:
>> On 3/7/19 5:18 AM, David Gibson wrote:
>>> On Wed, Mar 06, 2019 at 09:50:23AM +0100, Cédric Le Goater wrote:
> [snip]
 +static uint64_t pnv_lpc_mmio_read(void *opaque, hwaddr addr, unsigned 
 size)
 +{
 +PnvLpcController *lpc = PNV_LPC(opaque);
 +uint64_t val = 0;
 +uint32_t opb_addr = addr & ECCB_CTL_ADDR_MASK;
 +MemTxResult result;
 +
 +switch (size) {
 +case 4:
 +val = address_space_ldl(>opb_as, opb_addr, 
 MEMTXATTRS_UNSPECIFIED,
 +);
 +break;
 +case 1:
 +val = address_space_ldub(>opb_as, opb_addr, 
 MEMTXATTRS_UNSPECIFIED,
 + );
 +break;
 +default:
 +qemu_log_mask(LOG_GUEST_ERROR, "OPB read failed at @0x%"
 +  HWADDR_PRIx " invalid size %d\n", addr, size);
 +return 0;
 +}
 +
 +if (result != MEMTX_OK) {
 +qemu_log_mask(LOG_GUEST_ERROR, "OPB read failed at @0x%"
 +  HWADDR_PRIx "\n", addr);
 +}
 +
 +return val;
>>>
>>> Couldn't you just map the relevant portion of the OPB AS into the MMIO
>>> AS, rather than having to forward the IOs with explicit read/write
>>> functions?
>>
>> The underlying memory regions (ISA space, LPC HC, OPB regs) are the
>> same on POWER8. So this is one way to share the overall initialization. 
> 
> I don't understand how that relates to my question.  If anything that
> sounds like it makes even more sense to map the common MR with the
> actual registers into the MMIO AS as a subregion, rather than having a
> redirect via the OPB AS.

ok. I will try that.

Thanks,

C.   

> 
>> What I would have liked to do is to simplified the ECCB interface 
>> (see pnv_lpc_do_eccb()).
>>
>> Thanks,
>>
>> C. 
>>
>>
 +}
 +
 +static void pnv_lpc_mmio_write(void *opaque, hwaddr addr,
 +uint64_t val, unsigned size)
 +{
 +PnvLpcController *lpc = PNV_LPC(opaque);
 +uint32_t opb_addr = addr & ECCB_CTL_ADDR_MASK;
 +MemTxResult result;
 +
 +switch (size) {
 +case 4:
 +address_space_stl(>opb_as, opb_addr, val, 
 MEMTXATTRS_UNSPECIFIED,
 +  );
 + break;
 +case 1:
 +address_space_stb(>opb_as, opb_addr, val, 
 MEMTXATTRS_UNSPECIFIED,
 +  );
 +break;
 +default:
 +qemu_log_mask(LOG_GUEST_ERROR, "OPB write failed at @0x%"
 +  HWADDR_PRIx " invalid size %d\n", addr, size);
 +return;
 +}
 +
 +if (result != MEMTX_OK) {
 +qemu_log_mask(LOG_GUEST_ERROR, "OPB write failed at @0x%"
 +  HWADDR_PRIx "\n", addr);
 +}
 +}
 +
 +static const MemoryRegionOps pnv_lpc_mmio_ops = {
 +.read = pnv_lpc_mmio_read,
 +.write = pnv_lpc_mmio_write,
 +.impl = {
 +.min_access_size = 1,
 +.max_access_size = 4,
 +},
 +.endianness = DEVICE_BIG_ENDIAN,
 +};
 +
  static void pnv_lpc_eval_irqs(PnvLpcController *lpc)
  {
  bool lpc_to_opb_irq = false;
 @@ -465,6 +627,43 @@ static const TypeInfo pnv_lpc_power8_info = {
  }
  };
  
 +static void pnv_lpc_power9_realize(DeviceState *dev, Error **errp)
 +{
 +PnvLpcController *lpc = PNV_LPC(dev);
 +PnvLpcClass *plc = PNV_LPC_GET_CLASS(dev);
 +Error *local_err = NULL;
 +
 +plc->parent_realize(dev, _err);
 +if (local_err) {
 +error_propagate(errp, local_err);
 +return;
 +}
 +
 +/* P9 uses a MMIO region */
 +memory_region_init_io(>xscom_regs, OBJECT(lpc), 
 _lpc_mmio_ops,
 +  lpc, "lpcm", PNV9_LPCM_SIZE);
 +}
 +
 +static void pnv_lpc_power9_class_init(ObjectClass *klass, void *data)
 +{
 +DeviceClass *dc = DEVICE_CLASS(klass);
 +PnvLpcClass *plc = PNV_LPC_CLASS(klass);
 +
 +dc->desc = "PowerNV LPC Controller POWER9";
 +
 +plc->psi_irq = PSIHB9_IRQ_LPCHC;
 +
 +device_class_set_parent_realize(dc, pnv_lpc_power9_realize,
 +>parent_realize);
 +}
 +
 +static const TypeInfo pnv_lpc_power9_info = {
 +.name  = TYPE_PNV9_LPC,
 +.parent= TYPE_PNV_LPC,
 +.instance_size = sizeof(PnvLpcController),
 +.class_init= pnv_lpc_power9_class_init,
 +};
 +
  static void pnv_lpc_realize(DeviceState *dev, Error **errp)
  {
  PnvLpcController *lpc = PNV_LPC(dev);
 @@ -540,6 +739,7 @@ static void 

Re: [Qemu-devel] converting build system to Meson?

2019-03-07 Thread Gerd Hoffmann
  Hi,

> > As an aside, it might be a nice idea to drop the in-srcdir
> > build altogether for QEMU anyway -- it's not really a very
> > good idea and it means our build system has to cope with two
> > different ways of working to no particularly useful end.
> 
> I was actually going to propose that, but I was afraid of throwing two
> bombs in the same day. :)

I stopped using in-tree builds years ago.  When test-building different
configurations using an build/$cfgname out-of-tree build directory is
the only sane approach.  And IIRC I've managed to break in-tree builds
because of that.

So, yes, please.

> CentOS 7 doesn't have "native" Python 3 (even the 3.4 version you have
> there is probably coming from Fedora) but it has software collections,
> where you have to do "scl enable rh-python35 './configure && make'".
> You can check if scl and the rh-python35 software collections are
> already installed.

Also:  epel offers a meson package.  It has python34 and python36
packages too.

cheers,
  Gerd




Re: [Qemu-devel] egl: EGL_MESA_image_dma_buf_export not supported / Failed to initialize EGL render node for SPICE GL

2019-03-07 Thread manish jaggi
On Thu, Mar 7, 2019 at 9:55 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, Mar 7, 2019 at 3:00 PM manish jaggi  wrote:
> >
> > Hi List,
> > I am trying to run qemu with spice gl=on with the below command line
> > and getting errors.
> >
> > qemu-system-x86_64 -cdrom ubuntu-18.04.2-desktop-amd64.iso -hda
> > u1.qcow2 -enable-kvm -m 1G -cpu host -smp 8 -machine vmport=off -boot
> > order=dc -device virtio-vga,virgl=on -spice
> > gl=on,unix,addr=/home/mjaggi/spice.sock,password=1,disable-ticketing
> > -soundhw hda -device virtio-serial -chardev
> > spicevmc,id=vdagent,debug=0,name=vdagent -device
> > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> >
> > qemu-system-x86_64: egl: EGL_MESA_image_dma_buf_export not supported
> > qemu-system-x86_64: Failed to initialize EGL render node for SPICE GL
>
> It's a limitation of your graphics driver, it doesn't support the
> required extensions.
>
> Which GPU and driver do you have?
>
AMD RX560, using mainline 5.0 kernel.
is  EGL_MESA_image_dma_buf_export  must for spice gl=on?

> thanks
>
> >
> > Qemu configuration
> > ./configure --enable-sdl --with-sdlabi=2.0 --enable-opengl
> > --enable-virglrenderer --enable-system --enable-modules
> > --target-list=x86_64-softmmu --enable-kvm  --disable-werror
> >
> > ...
> > OpenGL supportyes
> > OpenGL dmabufsyes
> >
> > As per configure script
> >
> > #include 
> > #ifndef EGL_MESA_image_dma_buf_export
> > # error mesa/epoxy lacks support for dmabufs (mesa 10.6+)
> > #endif
> > int main(void) { return 0; }
> > EOF
> >   if compile_prog "" "" ; then
> > opengl_dmabuf=yes
> >   fi
> > fi
> >
> > So if OpenGL dmabufs   is yes, should I be getting
> > EGL_MESA_image_dma_buf_export not supported error ?
> > What I could be missing here
> > Need help/guidance.
> >
> > -Thanks
> > Manish
> >
>
>
> --
> Marc-André Lureau



Re: [Qemu-devel] [PATCH 15/27] ppc/pnv: add a PSI bridge model for POWER9

2019-03-07 Thread Cédric Le Goater
On 3/8/19 1:17 AM, David Gibson wrote:
> On Thu, Mar 07, 2019 at 07:37:51AM +0100, Cédric Le Goater wrote:
>> On 3/7/19 5:10 AM, David Gibson wrote:
>>> On Wed, Mar 06, 2019 at 09:50:20AM +0100, Cédric Le Goater wrote:
 The PSI bridge on POWER9 is very similar to POWER8. The BAR is still
 set through XSCOM but the controls are now entirely done with MMIOs.
 More interrupts are defined and the interrupt controller interface has
 changed to XIVE. The POWER9 model is a first example of the usage of
 the notify() handler of the XiveNotifier interface, linking the PSI
 XiveSource to its owning device model.

 Signed-off-by: Cédric Le Goater 
 ---
  include/hw/ppc/pnv.h   |   6 +
  include/hw/ppc/pnv_psi.h   |  24 +++
  include/hw/ppc/pnv_xscom.h |   3 +
  hw/ppc/pnv.c   |  17 ++
  hw/ppc/pnv_psi.c   | 325 -
  5 files changed, 373 insertions(+), 2 deletions(-)

 diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
 index eb4bba25b3e9..57d0337219be 100644
 --- a/include/hw/ppc/pnv.h
 +++ b/include/hw/ppc/pnv.h
 @@ -84,6 +84,7 @@ typedef struct Pnv9Chip {
  
  /*< public >*/
  PnvXive  xive;
 +PnvPsi   psi;
  } Pnv9Chip;
  
  typedef struct PnvChipClass {
 @@ -231,11 +232,16 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
  #define PNV9_XIVE_PC_SIZE0x0010ull
  #define PNV9_XIVE_PC_BASE(chip)  PNV9_CHIP_BASE(chip, 
 0x00060180ull)
  
 +#define PNV9_PSIHB_SIZE  0x0010ull
 +#define PNV9_PSIHB_BASE(chip)PNV9_CHIP_BASE(chip, 
 0x000603020300ull)
 +
  #define PNV9_XIVE_IC_SIZE0x0008ull
  #define PNV9_XIVE_IC_BASE(chip)  PNV9_CHIP_BASE(chip, 
 0x000603020310ull)
  
  #define PNV9_XIVE_TM_SIZE0x0004ull
  #define PNV9_XIVE_TM_BASE(chip)  PNV9_CHIP_BASE(chip, 
 0x000603020318ull)
  
 +#define PNV9_PSIHB_ESB_SIZE  0x0001ull
 +#define PNV9_PSIHB_ESB_BASE(chip)PNV9_CHIP_BASE(chip, 
 0x00060302031cull)
  
  #endif /* _PPC_PNV_H */
 diff --git a/include/hw/ppc/pnv_psi.h b/include/hw/ppc/pnv_psi.h
 index 585a41cd19b6..d7e1ab282cf8 100644
 --- a/include/hw/ppc/pnv_psi.h
 +++ b/include/hw/ppc/pnv_psi.h
 @@ -21,6 +21,7 @@
  
  #include "hw/sysbus.h"
  #include "hw/ppc/xics.h"
 +#include "hw/ppc/xive.h"
  
  #define TYPE_PNV_PSI "pnv-psi"
  #define PNV_PSI(obj) \
 @@ -28,6 +29,9 @@
  #define TYPE_PNV8_PSI TYPE_PNV_PSI "-POWER8"
  #define PNV8_PSI(obj) \
  OBJECT_CHECK(PnvPsi, (obj), TYPE_PNV8_PSI)
 +#define TYPE_PNV9_PSI TYPE_PNV_PSI "-POWER9"
 +#define PNV9_PSI(obj) \
 +OBJECT_CHECK(PnvPsi, (obj), TYPE_PNV9_PSI)
  
  #define PSIHB_XSCOM_MAX 0x20
  
 @@ -43,6 +47,7 @@ typedef struct PnvPsi {
  
  /* Interrupt generation */
  ICSState ics;
 +XiveSource source;
>>>
>>> Uh... surely these should move to the subtype structures, so you don't
>>> have both of them.
>>
>> I did not introduce a subtype, only a subclass. But we could 
>> possibly. It seemed overkill for one attribute.
>>
>>>
  qemu_irq *qirqs;
  
  /* Registers */
 @@ -82,4 +87,23 @@ typedef enum PnvPsiIrq {
  
  void pnv_psi_irq_set(PnvPsi *psi, int irq, bool state);
  
 +/* P9 PSI Interrupts */
 +#define PSIHB9_IRQ_PSI  0
 +#define PSIHB9_IRQ_OCC  1
 +#define PSIHB9_IRQ_FSI  2
 +#define PSIHB9_IRQ_LPCHC3
 +#define PSIHB9_IRQ_LOCAL_ERR4
 +#define PSIHB9_IRQ_GLOBAL_ERR   5
 +#define PSIHB9_IRQ_TPM  6
 +#define PSIHB9_IRQ_LPC_SIRQ07
 +#define PSIHB9_IRQ_LPC_SIRQ18
 +#define PSIHB9_IRQ_LPC_SIRQ29
 +#define PSIHB9_IRQ_LPC_SIRQ310
 +#define PSIHB9_IRQ_SBE_I2C  11
 +#define PSIHB9_IRQ_DIO  12
 +#define PSIHB9_IRQ_PSU  13
 +#define PSIHB9_NUM_IRQS 14
 +
 +void pnv_psi_pic_print_info(PnvPsi *psi, Monitor *mon);
 +
  #endif /* _PPC_PNV_PSI_H */
 diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
 index 6623ec54a7a8..403a365ed274 100644
 --- a/include/hw/ppc/pnv_xscom.h
 +++ b/include/hw/ppc/pnv_xscom.h
 @@ -73,6 +73,9 @@ typedef struct PnvXScomInterfaceClass {
  #define PNV_XSCOM_OCC_BASE0x0066000
  #define PNV_XSCOM_OCC_SIZE0x6000
  
 +#define PNV9_XSCOM_PSIHB_BASE 0x5012900
 +#define PNV9_XSCOM_PSIHB_SIZE 0x100
 +
  #define PNV9_XSCOM_XIVE_BASE  0x5013000
  #define PNV9_XSCOM_XIVE_SIZE  0x300
  
 diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
 index 67d40dc3eebc..4375f97c7135 100644
 --- a/hw/ppc/pnv.c

[Qemu-devel] [PATCH v7] pflash: Require backend size to match device, improve errors

2019-03-07 Thread Markus Armbruster
From: Alex Bennée 

We reject undersized backends with a rather enigmatic "failed to read
the initial flash content" error.

We happily accept oversized images, ignoring their tail.  Throwing
away parts of firmware that way is pretty much certain to end in an
even more enigmatic failure to boot.

Require the backend's size to match the device's size exactly.  Report
mismatch as "device requires N bytes, block backend 'NAME' provides M
bytes".

Improve the error for actual read failures to "can't read initial
flash content from block backend 'NAME'.

We disabled code to limit device sizes to 8, 16, 32 or 64MiB more than
a decade ago in commit 95d1f3edd5e and c8b153d7949, v0.9.1.  Bury.

Signed-off-by: Alex Bennée 
Signed-off-by: Markus Armbruster 
---
 hw/block/pflash_cfi01.c | 31 ++-
 hw/block/pflash_cfi02.c | 31 +++
 2 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 9d1c356eb6..2e3a05c0b3 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -730,13 +730,6 @@ static void pflash_cfi01_realize(DeviceState *dev, Error 
**errp)
 }
 device_len = sector_len_per_device * blocks_per_device;
 
-/* XXX: to be fixed */
-#if 0
-if (total_len != (8 * 1024 * 1024) && total_len != (16 * 1024 * 1024) &&
-total_len != (32 * 1024 * 1024) && total_len != (64 * 1024 * 1024))
-return NULL;
-#endif
-
 memory_region_init_rom_device(
 >mem, OBJECT(dev),
 _cfi01_ops,
@@ -763,12 +756,32 @@ static void pflash_cfi01_realize(DeviceState *dev, Error 
**errp)
 }
 
 if (pfl->blk) {
+/*
+ * Validate the backing store is the right size for pflash
+ * devices. If the user supplies a larger file we ignore the
+ * tail.
+ */
+int64_t backing_len = blk_getlength(pfl->blk);
+
+if (backing_len < 0) {
+error_setg(errp, "can't get size of block backend '%s'",
+   blk_name(pfl->blk));
+return;
+}
+if (backing_len != total_len) {
+error_setg(errp, "device requires %" PRIu64 " bytes, "
+   "block backend '%s' provides %" PRIu64 " bytes",
+   total_len, blk_name(pfl->blk), backing_len);
+return;
+}
+
 /* read the initial flash content */
 ret = blk_pread(pfl->blk, 0, pfl->storage, total_len);
-
 if (ret < 0) {
 vmstate_unregister_ram(>mem, DEVICE(pfl));
-error_setg(errp, "failed to read the initial flash content");
+error_setg(errp, "can't read initial flash content"
+   " from block backend '%s'",
+   blk_name(pfl->blk));
 return;
 }
 }
diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
index 33779ce807..45b88d65d8 100644
--- a/hw/block/pflash_cfi02.c
+++ b/hw/block/pflash_cfi02.c
@@ -550,12 +550,6 @@ static void pflash_cfi02_realize(DeviceState *dev, Error 
**errp)
 }
 
 chip_len = pfl->sector_len * pfl->nb_blocs;
-/* XXX: to be fixed */
-#if 0
-if (total_len != (8 * 1024 * 1024) && total_len != (16 * 1024 * 1024) &&
-total_len != (32 * 1024 * 1024) && total_len != (64 * 1024 * 1024))
-return NULL;
-#endif
 
 memory_region_init_rom_device(>orig_mem, OBJECT(pfl), pfl->be ?
   _cfi02_ops_be : _cfi02_ops_le,
@@ -581,11 +575,32 @@ static void pflash_cfi02_realize(DeviceState *dev, Error 
**errp)
 }
 
 if (pfl->blk) {
+/*
+ * Validate the backing store is the right size for pflash
+ * devices. If the user supplies a larger file we ignore the
+ * tail.
+ */
+int64_t backing_len = blk_getlength(pfl->blk);
+
+if (backing_len < 0) {
+error_setg(errp, "can't get size of block backend '%s'",
+   blk_name(pfl->blk));
+return;
+}
+if (backing_len != chip_len) {
+error_setg(errp, "device requires %" PRIu32 " bytes, "
+   "block backend '%s' provides %" PRIu64 " bytes",
+   chip_len, blk_name(pfl->blk), backing_len);
+return;
+}
+
 /* read the initial flash content */
 ret = blk_pread(pfl->blk, 0, pfl->storage, chip_len);
 if (ret < 0) {
-vmstate_unregister_ram(>orig_mem, DEVICE(pfl));
-error_setg(errp, "failed to read the initial flash content");
+vmstate_unregister_ram(>mem, DEVICE(pfl));
+error_setg(errp, "can't read initial flash content"
+   " from block backend '%s'",
+   blk_name(pfl->blk));
 return;
 }
 }
-- 
2.17.2




Re: [Qemu-devel] [PATCH v2 07/11] ppc405_boards: Don't size flash memory to match backing image

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 08:01:35AM +0100, Markus Armbruster wrote:
> Alex Bennée  writes:
> 
> > Markus Armbruster  writes:
> >
> >> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
> >> Image size is rounded up to the next multiple of 64KiB.  Useless,
> >> because pflash_cfi02_realize() fails with "failed to read the initial
> >> flash content" unless the rounding is a no-op.
> >>
> >> If the image size exceeds 0x8 Bytes, we overlap first SRAM, then
> >> other stuff.  No idea how that would play out, but a useful outcomes
> >> seem unlikely.
> >>
> >> Map the flash memory at fixed address 0xFFF8 with size 512KiB,
> >> regardless of image size, to match the physical hardware.
> >>
> >> Machine "taihu" maps its boot flash memory similarly.  The code even
> >> has a comment /* XXX: should check that size is 2MB */, followed by
> >> disabled code to adjust the size to 2MiB regardless of image size.
> >>
> >> Its code to map its application flash memory looks the same, except
> >> there the XXX comment asks for 32MiB, and the code to adjust the size
> >> isn't disabled.  Note that pflash_cfi02_realize() fails with "failed
> >> to read the initial flash content" for images smaller than 32MiB.
> >>
> >> Map the boot flash memory at fixed address 0xFFE0 with size 2MiB,
> >> to match the physical hardware.  Delete dead code from application
> >> flash mapping, and simplify some.
> >
> > It seems to me the DEBUG_BOARD_INIT code is probably out of date cruft
> > that could be excised all together. But that doesn't stop this being
> > useful:
> 
> David, would you like me to excise DEBUG_BOARD_INIT?

If you have the chance to look at it, that would be great.

-- 
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 qemu v4 3/3] spapr: Support NVIDIA V100 GPU with NVLink2

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 03:02:32PM -0700, Alex Williamson wrote:
> On Thu,  7 Mar 2019 16:05:18 +1100
> Alexey Kardashevskiy  wrote:
> > diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
> > index 40a12001f580..15ec0b4c2723 100644
> > --- a/hw/vfio/pci-quirks.c
> > +++ b/hw/vfio/pci-quirks.c
> > @@ -2180,3 +2180,123 @@ int vfio_add_virt_caps(VFIOPCIDevice *vdev, Error 
> > **errp)
> >  
> >  return 0;
> >  }
> > +
> > +static void vfio_pci_nvlink2_get_tgt(Object *obj, Visitor *v,
> > + const char *name,
> > + void *opaque, Error **errp)
> > +{
> > +uint64_t tgt = (uint64_t) opaque;
> > +visit_type_uint64(v, name, , errp);
> > +}
> > +
> > +static void vfio_pci_nvlink2_get_link_speed(Object *obj, Visitor *v,
> > + const char *name,
> > + void *opaque, Error 
> > **errp)
> > +{
> > +uint32_t link_speed = (uint32_t)(uint64_t) opaque;
> > +visit_type_uint32(v, name, _speed, errp);
> > +}
> > +
> > +int vfio_pci_nvidia_v100_ram_init(VFIOPCIDevice *vdev, Error **errp)
> > +{
> > +int ret;
> > +void *p;
> > +struct vfio_region_info *nv2region = NULL;
> > +struct vfio_info_cap_header *hdr;
> > +MemoryRegion *nv2mr = g_malloc0(sizeof(*nv2mr));
> 
> This is leaked in the below error paths and there's no cleanup on
> finalize.  I assume these devices don't support hotplug, but they could
> at least use the existing quirk infrastructure so as not to set a bad
> precedent. 
> 
> > +
> > +ret = vfio_get_dev_region_info(>vbasedev,
> > +   VFIO_REGION_TYPE_PCI_VENDOR_TYPE |
> > +   PCI_VENDOR_ID_NVIDIA,
> > +   VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM,
> > +   );
> > +if (ret) {
> > +return ret;
> > +}
> > +
> > +p = mmap(NULL, nv2region->size, PROT_READ | PROT_WRITE | PROT_EXEC,
> > + MAP_SHARED, vdev->vbasedev.fd, nv2region->offset);
> > +
> > +if (!p) {
> > +return -errno;
> > +}
> 
> I think the above suggestion requires simply defining a quirk above:
> 
> VFIOQuirk *quirk;
> 
> Initializing it with one MemoryRegion here:
> 
> quirk = vfio_quirk_alloc(1);
> 
> > +
> > +memory_region_init_ram_ptr(nv2mr, OBJECT(vdev), "nvlink2-mr",
> 
> s/nv2mr/quirk->mem/
> 
> > +   nv2region->size, p);
> 
> Then adding it to the device, for instance assuming there's always a
> BAR0, attach it there:
> 
> QLIST_INSERT_HEAD(>bars[0].quirks, quirk, next);
> 
> At least then it pretends to support cleanup.

This does simplify the cleanup of the extra MRs.  It is a bit odd to
attach it specifically to a BAR that's not otherwise tied to these
resources (both the NV2 memory and ATSD are special NVLink extensions,
not attached to a PCI BAR).


-- 
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 qemu v5] spapr: Support NVIDIA V100 GPU with NVLink2

2019-03-07 Thread David Gibson
On Fri, Mar 08, 2019 at 12:44:20PM +1100, Alexey Kardashevskiy wrote:
> NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
> space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
> implements special regions for such GPUs and emulates an NVLink bridge.
> NVLink2-enabled POWER9 CPUs also provide address translation services
> which includes an ATS shootdown (ATSD) register exported via the NVLink
> bridge device.
> 
> This adds a quirk to VFIO to map the GPU memory and create an MR;
> the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
> this to get the MR and map it to the system address space.
> Another quirk does the same for ATSD.
> 
> This adds additional steps to sPAPR PHB setup:
> 
> 1. Search for specific GPUs and NPUs, collect findings in
> sPAPRPHBState::nvgpus, manage system address space mappings;
> 
> 2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
> "memory-block", "link-speed" to advertise the NVLink2 function to
> the guest;
> 
> 3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
> 
> 4. Add new memory blocks (with extra "linux,memory-usable" to prevent
> the guest OS from accessing the new memory until it is onlined) and
> npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
> uses it for link discovery.
> 
> This allocates space for GPU RAM and ATSD like we do for MMIOs by
> adding 2 new parameters to the phb_placement() hook. Older machine types
> set these to zero.
> 
> This puts new memory nodes in a separate NUMA node to replicate the host
> system setup as the GPU driver relies on this.
> 
> This adds requirement similar to EEH - one IOMMU group per vPHB.
> The reason for this is that ATSD registers belong to a physical NPU
> so they cannot invalidate translations on GPUs attached to another NPU.
> It is guaranteed by the host platform as it does not mix NVLink bridges
> or GPUs from different NPU in the same IOMMU group. If more than one
> IOMMU group is detected on a vPHB, this disables ATSD support for that
> vPHB and prints a warning.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> 
> This is based on David's ppc-for-4.0 +
> applied but not pushed "iommu replay": 
> https://patchwork.ozlabs.org/patch/1052644/
> acked "vfio_info_cap public": https://patchwork.ozlabs.org/patch/1052645/
> 
> 
> Changes:
> v5:
> * converted MRs to VFIOQuirk - this fixed leaks
> 
> v4:
> * fixed ATSD placement
> * fixed spapr_phb_unrealize() to do nvgpu cleanup
> * replaced warn_report() with Error*
> 
> v3:
> * moved GPU RAM above PCI MMIO limit
> * renamed QOM property to nvlink2-tgt
> * moved nvlink2 code to its own file
> 
> ---
> 
> The example command line for redbud system:
> 
> pbuild/qemu-aiku1804le-ppc64/ppc64-softmmu/qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
> -enable-kvm -m 384G \
> -chardev socket,id=SOCKET0,server,nowait,host=localhost,port=4 \
> -mon chardev=SOCKET0,mode=control \
> -smp 80,sockets=1,threads=4 \
> -netdev "tap,id=TAP0,helper=/home/aik/qemu-bridge-helper --br=br0" \
> -device "virtio-net-pci,id=vnet0,mac=52:54:00:12:34:56,netdev=TAP0" \
> img/vdisk0.img \
> -device "vfio-pci,id=vfio0004_04_00_0,host=0004:04:00.0" \
> -device "vfio-pci,id=vfio0006_00_00_0,host=0006:00:00.0" \
> -device "vfio-pci,id=vfio0006_00_00_1,host=0006:00:00.1" \
> -device "vfio-pci,id=vfio0006_00_00_2,host=0006:00:00.2" \
> -device "vfio-pci,id=vfio0004_05_00_0,host=0004:05:00.0" \
> -device "vfio-pci,id=vfio0006_00_01_0,host=0006:00:01.0" \
> -device "vfio-pci,id=vfio0006_00_01_1,host=0006:00:01.1" \
> -device "vfio-pci,id=vfio0006_00_01_2,host=0006:00:01.2" \
> -device spapr-pci-host-bridge,id=phb1,index=1 \
> -device "vfio-pci,id=vfio0035_03_00_0,host=0035:03:00.0" \
> -device "vfio-pci,id=vfio0007_00_00_0,host=0007:00:00.0" \
> -device "vfio-pci,id=vfio0007_00_00_1,host=0007:00:00.1" \
> -device "vfio-pci,id=vfio0007_00_00_2,host=0007:00:00.2" \
> -device "vfio-pci,id=vfio0035_04_00_0,host=0035:04:00.0" \
> -device "vfio-pci,id=vfio0007_00_01_0,host=0007:00:01.0" \
> -device "vfio-pci,id=vfio0007_00_01_1,host=0007:00:01.1" \
> -device "vfio-pci,id=vfio0007_00_01_2,host=0007:00:01.2" -snapshot \
> -machine pseries \
> -L /home/aik/t/qemu-ppc64-bios/ -d guest_errors
> 
> Note that QEMU attaches PCI devices to the last added vPHB so first
> 8 devices - 4:04:00.0 till 6:00:01.2 - go to the default vPHB, and
> 35:03:00.0..7:00:01.2 to the vPHB with id=phb1.
> ---
>  hw/ppc/Makefile.objs|   2 +-
>  hw/vfio/pci.h   |   2 +
>  include/hw/pci-host/spapr.h |  45 
>  include/hw/ppc/spapr.h  |   3 +-
>  hw/ppc/spapr.c  |  29 ++-
>  hw/ppc/spapr_pci.c  |  19 ++
>  hw/ppc/spapr_pci_nvlink2.c  | 441 
>  hw/vfio/pci-quirks.c| 132 +++
>  

Re: [Qemu-devel] [RFC PATCH v2] coroutines: generate wrapper code

2019-03-07 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190220100358.25566-1-vsement...@virtuozzo.com/



Hi,

This series failed the 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.

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




The full log is available at
http://patchew.org/logs/20190220100358.25566-1-vsement...@virtuozzo.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v4 0/4] tests: Allow use of Ports bash and GNU sed extensions

2019-03-07 Thread Michael S. Tsirkin
On Thu, Mar 07, 2019 at 04:27:36PM +0100, Thomas Huth wrote:
> On 07/03/2019 15.58, Philippe Mathieu-Daudé wrote:
> > Hi Thomas,
> 
> ? -^
> 
> I could take the patch for tests/data/acpi/rebuild-expected-aml.sh
> through the qtests tree (if Michael or Igor don't want to take it), but
> the other patches are not related to qtests...
> 
>  Thomas

You can pick it up, sure

Reviewed-by: Michael S. Tsirkin 




Re: [Qemu-devel] [PATCH v5 2/2] Add Nios II semihosting support.

2019-03-07 Thread Sandra Loosemore

On 3/7/19 7:58 AM, Peter Maydell wrote:

On Wed, 13 Feb 2019 at 04:02, Sandra Loosemore  wrote:


This patch adds support for libgloss semihosting to Nios II bare-metal
emulation.

Signed-off-by: Sandra Loosemore 
Signed-off-by: Julian Brown 


Do you have a link to the spec that defines this semihosting
ABI, please ?


Well, I just wrote some derived from the comments in the libgloss 
sources; see the attachment.  :-)


FWIW this is pretty much a direct copy of the m68k semihosting protocol, 
which CodeSourcery contributed ages ago to both libgloss and qemu.


-Sandra
Nios II Semihosting Protocol


The runtime (libgloss) indicates a semihosting request to the debug
agent by issuing a "break 1" instruction.  r4 and r5 are used to pass
parameters per the normal C ABI on nios2.

r4 contains a request code.  r5 is typically a pointer to a 4-word
parameter block, except for the exit operation where it is an
immediate integer value.

The result of the operation is returned in the first word of the
parameter block.  The second word is used to return an errno value,
encoded per the "Errno Values" section of the RSP documentation in the
GDB User Manual.

The supported r4 request codes are:

#define HOSTED_EXIT  0

  Terminate program execution; send a 'W' stop reply to GDB.

  r5 contains the exit code, as an immediate integer rather than indirectly
  in a parameter block.  This semihosting request isn't expected to return.

#define HOSTED_INIT_SIM 1

  Reserved/unimplemented.

#define HOSTED_OPEN 2

  Open file; 'Fopen' GDB fileio request.

  r5 points to a parameter block containing:
  [0] pointer to filename
  [1] filename length
  [2] open flags, encoded per the GDB RSP documentation
  [3] mode, encoded per the GDB RSP documentation

  Return values in parameter block:
  [0] file descriptor or -1 on error
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_CLOSE 3

  Close file; 'Fclose' GDB fileio request.

  r5 points to a parameter block containing:
  [0] file descriptor

  Return values in parameter block:
  [0] return status
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_READ 4

  Read from file; 'Fread' GDB fileio request.

  r5 points to a parameter block containing:
  [0] file descriptor
  [1] pointer to buffer
  [2] buffer size
  
  Return values in parameter block:
  [0] number of bytes read
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_WRITE 5

  Write to file; 'Fwrite' GDB fileio request.

  r5 points to a parameter block containing:
  [0] file descriptor
  [1] pointer to buffer
  [2] byte count
  
  Return values in parameter block:
  [0] number of bytes written
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_LSEEK 6

  File seek; 'Flseek' GDB fileio request.

  r5 points to a parameter block containing:
  [0] file descriptor
  [1] high word of 64-bit offset
  [2] low word of 64-bit offset
  [3] seek flag, encoded per the GDB RSP documentation

  Return values in parameter block:
  [0] high word of 64-bit result
  [1] low word of 64-bit result
  [2] errno, encoded per the GDB RSP documentation

#define HOSTED_RENAME 7

  File rename; 'Frename' GDB fileio request.

  r5 points to a parameter block containing:
  [0] oldname pointer
  [1] oldname length
  [2] newname pointer
  [3] newname length

  Return values in parameter block:
  [0] return status
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_UNLINK 8

  File unlink/delete; 'Funlink' GDB fileio request.

  r5 points to a parameter block containing:
  [0] filename pointer
  [1] filename length

  Return values in parameter block:
  [0] return status
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_STAT 9

  File information; 'Fstat' GDB fileio request.

  r5 points to a parameter block containing:
  [0] filename pointer
  [1] filename length
  [2] pointer to stat buf, using the structure definition in the GDB RSP
  documentation 

  Return values in parameter block:
  [0] return status
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_FSTAT 10

  File information; 'Ffstat' GDB fileio request.
  
  r5 points to a parameter block containing:
  [0] file descriptor
  [1] pointer to stat buf, using the structure definition in the GDB RSP
  documentation 

  Return values in parameter block:
  [0] return status
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_GETTIMEOFDAY 11

  Get current time; 'Fgettimeofday' GDB fileio request.

  r5 points to a parameter block containing:
  [0] timeval pointer, using the structure definition in the GDB RSP
  documentation

  Return values in parameter block:
  [0] return status
  [1] errno, encoded per the GDB RSP documentation

#define HOSTED_ISATTY 12

 Return true if the file descriptor is the GDB console; 'Fisatty' GDB fileio
 request.

  r5 points to a parameter block containing:
  [0] file descriptor

  Return values in 

Re: [Qemu-devel] [PATCH v2 4/5] iothread: push gcontext earlier in the thread_fn

2019-03-07 Thread Peter Xu
On Thu, Mar 07, 2019 at 02:40:39PM +, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2019 at 07:55:31PM +0800, Peter Xu wrote:
> > +/*
> > + * We should do this as soon as we enter the thread, because the
> > + * function will silently fail if it fails to acquire the
> > + * gcontext.
> > + */
> > +g_main_context_push_thread_default(iothread->worker_context);
> 
> I have a hard time understanding this comment.  The mention of how it
> fails makes me think "we'll never find out about failures anyway, so how
> does it help to call this early?".
> 
> I suggest sticking to the point that this function must always be called
> first:
> 
>   /*
>* g_main_context_push_thread_default() must be called before anything
>* in this new thread uses glib.
>*/
> 
> Now people will think before moving this function call.

Sorry to be confusing; this looks good to me.  Please let me know if
you want me to repost this patch alone or the patchset with the change.

Thanks,

-- 
Peter Xu



Re: [Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

2019-03-07 Thread Lilijun (Jerry, Cloud Networking)
Hi, Stefan

This problem is related with backend vhost-user socket abnormal cases, we 
shouldn't ask customers to configure it manually for backend's issues or 
depends on guest OS's network configuration.

Thanks

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Wednesday, March 06, 2019 6:07 PM
> To: Lilijun (Jerry, Cloud Networking) 
> Cc: qemu-devel@nongnu.org; wangxin (U)
> ; wangyunjian
> 
> Subject: Re: [Qemu-devel] Question about VM inner route entry's lost when
> vhost-user reconnect
> 
> On Mon, Mar 04, 2019 at 08:26:23AM +, Lilijun (Jerry, Cloud Networking)
> wrote:
> >   I am running my VM using vhost-user NIC with OVS-DPDK.  The steps of
> my question is shown as follows:
> >  1) In the VM, I add one route entry manually on the vNIC eth0 using the
> linux tool route.
> >  2) When restarting openvswitch service for the crash of the 
> > ovs-vswitchd,
> qemu's vhost-user reconnected successfully after 40s.
> >  3) Here VM's vNIC will receive link down and up events, the interval
> between the two events is about 40s.
> >  3) But that route entry disappeared and that will cause user's network
> traffic interruption and the service failed.
> >
> >  Is there some work on this problem?  Can we keep the vNIC's link up
> status when do vhost-user's reconnecting work?
> 
> Can you add the custom route to the network management tool inside the
> guest so that it will be reinstated when the link comes back up?
> 
> The details of how to do this depend on the guest's distro.
> 
> Stefan



Re: [Qemu-devel] [PATCH v2 16/18] hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()

2019-03-07 Thread Eric Blake
On 3/7/19 7:32 PM, Philippe Mathieu-Daudé wrote:
> The Edk2Crypto object is used to hold configuration values specific
> to EDK2.
> 
> The edk2_add_host_crypto_policy() function loads crypto policies
> from the host, and register them as fw_cfg named file items.
> So far only the 'https' policy is supported.
> 
> An usercase example is the 'HTTPS Boof' feature of OVMF [*].

s/An/A/ since "user" is a pronounced or hard 'u' (English is funny, but
the rule of thumb is you add the consonant only before a soft u, and not
a pronounced one; as in "give an umbrella to a unicorn")

> 
> Usage example:
> 
>   $ qemu-system-x86_64 \
>   -object edk2_crypto,id=https,\

Might as well use --object (both spellings work for qemu, but since
--object is the only spelling for qemu-img/qemu-nbd, being consistent
between the lot is useful).

>   ciphers=/etc/crypto-policies/back-ends/openssl.config,\
>   cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin

(I really should follow through on my threat to teach QemuOpts to ignore
whitespace after ','; but for this commit message, it's obvious the
indentation has to be stripped for the command line to be valid)

> 
> (On Fedora these files are provided by the ca-certificates and
> crypto-policies packages).
> 
> [*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

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



Re: [Qemu-devel] [PATCH v2 13/18] hw/nvram/fw_cfg: Add QMP 'info fw_cfg' command

2019-03-07 Thread Eric Blake
On 3/7/19 7:32 PM, Philippe Mathieu-Daudé wrote:
> When debugging a paravirtualized guest firmware, it results very
> useful to dump the fw_cfg table.
> Add a QMP command which returns the most useful fields.
> Since the QMP protocol is not designed for passing stream data,
> we don't display a fw_cfg item data, only it's size:
> 
> { "execute": "query-fw_cfg-items" }
> {
> "return": [
> {
> "architecture_specific": false,
> "key": 0,
> "writeable": false,
> "size": 4,
> "keyname": "signature"

You could return a base64-encoded representation of the field (we do
that in other interfaces where raw binary can't be passed reliably over
JSON).  For 4 bytes, that makes sense,


> {
> "architecture_specific": true,
> "key": 3,
> "writeable": false,
> "size": 324,
> "keyname": "e820_tables"

for 324 bytes, it gets a bit long. Still, may be worth it for the added
debug visibility.


> +++ b/qapi/misc.json
> @@ -3051,3 +3051,47 @@
>'data': 'NumaOptions',
>'allow-preconfig': true
>  }
> +
> +##
> +# @FirmwareConfigurationItem:
> +#
> +# Firmware Configuration (fw_cfg) item.
> +#
> +# @key: The uint16 selector key.
> +# @keyname: The stringified name if the selector refers to a well-known
> +#   numerically defined item.
> +# @architecture_specific: Indicates whether the configuration setting is

Prefer '-' over '_' in new interfaces.

> +# architecture specific.
> +#  false: The item is a generic configuration item.
> +#  true:  The item is specific to a particular architecture.
> +# @writeable: Indicates whether the configuration setting is writeable by
> +# the guest.

writable

> +# @size: The length of @data associated with the item.
> +# @data: A string representating the firmware configuration data.

representing

> +#Note: This field is currently not used.

Either drop the field until it has a use, or let it be the base64
encoding and use it now.

> +# @path: If the key is a 'file', the named file path.
> +# @order: If the key is a 'file', the named file order.
> +#
> +# Since 4.0
> +##
> +{ 'struct': 'FirmwareConfigurationItem',
> +  'data': { 'key': 'uint16',
> +'*keyname': 'str',
> +'architecture_specific': 'bool',
> +'writeable': 'bool',
> +'*data': 'str',
> +'size': 'int',
> +'*path': 'str',
> +'*order': 'int' } }

Is it worth making 'keyname' an enum type, and turning this into a flat
union where 'path' and 'order' appear on the branch associated with
'file', and where all other well-known keynames have smaller branches?


> +
> +
> +##
> +# @query-fw_cfg-items:

That looks weird to mix - and _. Any reason we can't just go with
query-firmware-config?

> +#
> +# Returns the list of Firmware Configuration items.
> +#
> +# Returns: A list of @FirmwareConfigurationItem for each entry.
> +#
> +# Since 4.0
> +##
> +{ 'command': 'query-fw_cfg-items', 'returns': ['FirmwareConfigurationItem']}
> 

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



[Qemu-devel] [PULL 0/2] target/hppa updates

2019-03-07 Thread Richard Henderson
The following changes since commit 6cb4f6db4f4367faa33da85b15f75bbbd2bed2a6:

  Merge remote-tracking branch 'remotes/cleber/tags/python-next-pull-request' 
into staging (2019-03-07 16:16:02 +)

are available in the Git repository at:

  https://github.com/rth7680/qemu.git tags/pull-hppa-20190307

for you to fetch changes up to b35aec8597e86911d5553c94769f914a52a8b389:

  target/hppa: Optimize blr r0,rn (2019-03-07 17:43:12 -0800)


Fix use after free on temporary.
Optmize branch to next insn via br r0.


Richard Henderson (2):
  target/hppa: Do not return freed temporary
  target/hppa: Optimize blr r0,rn

 target/hppa/translate.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)



Re: [Qemu-devel] Question about VM virtio device's link down delay when vhost-user reconnect

2019-03-07 Thread Michael S. Tsirkin
On Fri, Mar 08, 2019 at 01:53:28AM +, Lilijun (Jerry, Cloud Networking) 
wrote:
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > 
> > On Wed, Mar 06, 2019 at 07:36:44AM +, Lilijun (Jerry, Cloud Networking)
> > wrote:
> > > Thanks a lot for your advice.
> > >
> > > Maybe there are two methods to add this option:
> > > 1) Firstly, add a vhost-user protocol feature to tell Qemu if hide the
> > disconnects from the guest.  Here we just need the backend such as dpdk
> > vhostuser to support this option and the feature.
> > > 2) Secondly, add a VM XML vhost-user nic configuration parameters for
> > Qemu.  This method need more modification and other components such as
> > Libvirt and Nova in openstack to configure it.
> > >
> > > I'd like to choose the first method,  Do you think so?
> > 
> > What we need to decide this is - when is it a good idea to down the link on
> > disconnect.
> > If it depends on vm configuration then it belongs with qemu.
> > If it depends on hardware or other host configuration it might belong with
> > the backend.
> > 
> 
> In my opinion, the vhost-user disconnects is related with the host backend 
> process's restart or other socket close.

Right.

> So, we can add a host configuration such as ovs/dpdk  vhostuser interface's 
> options(ovs-vsctl set interface) to tell Qemu hide the disconnects by 
> vhostuser protocol feature negotiation.
> 
> Thanks

In that case it seems that what we want is actually a set of
commands for signalling link down events to qemu.
Then backend can signal link down before shutdown,
if it does not then if command is supported we can assume backend
is restarted. If command not supported - we assume legacy
backend and behave in a compatible way (i.e. do not drop link).


> > 
> > 
> > > To monitor the status of connection, we can using the command " virsh
> > qemu-monitor-command vm1 --hmp info chardev " to lookup that status.
> > Another one is to add new type event for Qemu to notify libvirt or other
> > upper level components.
> > >
> > > Jerry
> > >
> > > > -Original Message-
> > > > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > > > Sent: Tuesday, March 05, 2019 10:39 AM
> > > > To: Lilijun (Jerry, Cloud Networking) 
> > > > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Liujinsong (Paul)
> > > > ; lixiao (H) ;
> > > > wangyunjian ; wangxin (U)
> > > > ; Gonglei (Arei)
> > > > 
> > > > Subject: Re: Question about VM virtio device's link down delay when
> > > > vhost- user reconnect
> > > >
> > > > On Mon, Mar 04, 2019 at 11:46:32AM +, Lilijun (Jerry, Cloud
> > > > Networking)
> > > > wrote:
> > > > > Hi all,
> > > > >
> > > > >   I am running my VM using vhost-user NIC with OVS-DPDK.  The
> > > > > steps of
> > > > my question is shown as follows:
> > > > >  1) In the VM, I add one route entry manually on the vNIC eth0
> > > > > using
> > > > "route add default gw 192.168.1.2".
> > > > >  2) If openvswitch service was restarted, or the process
> > > > > ovs-vswitchd was
> > > > aborted, the new process may be started successfully after long
> > > > seconds such as 40s for the initialization of DPDK huge page memory.
> > > > >  3) And Qemu's vhost-user closed the connection and
> > > > > reconnected
> > > > successfully after 40s.
> > > > >  4) Here VM's vNIC will receive link down and up events, the
> > > > > interval
> > > > between the two events is about 40s.
> > > > >  5) Then I found that route entry disappeared unexpectedly.
> > > > > This will
> > > > cause some network traffic problems.
> > > > >
> > > > >  I have an idea about this problem. We can add a parameter "
> > > > link_down_delay" for all virtio devices that use vhost-user socket
> > > > such as virtio-net and virtio-blk.
> > > > >
> > > > > If vhost-user socket get a connection closed event when the
> > > > > backend
> > > > process was aborted or restarted, we don't notify VM virtio-net
> > > > device link down right now.
> > > > >When the vhost-user backend recover this socket's connections
> > > > > before
> > > > the time of "link_down_delay" ms passed, we need not do that link
> > > > down notification to VM.
> > > > >Or else, if that's timeout, VM can be notified the link down
> > > > > event as
> > > > before.
> > > > >
> > > > > Is there any other opinions about this solution?  Or some better 
> > > > > ideas?
> > > > Thanks.
> > > > >
> > > > > B.R.
> > > > >
> > > > > Jerry
> > > > >
> > > >
> > > > Rather than hardcode a specific timeout policy, I would go further
> > > > and start with an option to just hide disconnects from guest completely.
> > > > Instead add commands to monitor status of connection and events to
> > > > report changes.  Management tools can then mirror connection status
> > > > to link if they want to.
> > > >
> > > > --
> > > > MST



[Qemu-devel] [PULL 1/2] target/hppa: Do not return freed temporary

2019-03-07 Thread Richard Henderson
For priv levels 1 & 2, we were doing so from do_ibranch_priv.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 target/hppa/translate.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/target/hppa/translate.c b/target/hppa/translate.c
index b4fd307b77..dad8ce563c 100644
--- a/target/hppa/translate.c
+++ b/target/hppa/translate.c
@@ -2007,16 +2007,15 @@ static TCGv_reg do_ibranch_priv(DisasContext *ctx, 
TCGv_reg offset)
 /* Privilege 0 is maximum and is allowed to decrease.  */
 return offset;
 case 3:
-/* Privilege 3 is minimum and is never allowed increase.  */
+/* Privilege 3 is minimum and is never allowed to increase.  */
 dest = get_temp(ctx);
 tcg_gen_ori_reg(dest, offset, 3);
 break;
 default:
-dest = tcg_temp_new();
+dest = get_temp(ctx);
 tcg_gen_andi_reg(dest, offset, -4);
 tcg_gen_ori_reg(dest, dest, ctx->privilege);
 tcg_gen_movcond_reg(TCG_COND_GTU, dest, dest, offset, dest, offset);
-tcg_temp_free(dest);
 break;
 }
 return dest;
-- 
2.17.2




[Qemu-devel] [PULL 2/2] target/hppa: Optimize blr r0,rn

2019-03-07 Thread Richard Henderson
We can eliminate an extra TB in this case, which merely
loads a "return address" into rn.

Signed-off-by: Richard Henderson 
---
 target/hppa/translate.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/target/hppa/translate.c b/target/hppa/translate.c
index dad8ce563c..dc5636fe94 100644
--- a/target/hppa/translate.c
+++ b/target/hppa/translate.c
@@ -3488,12 +3488,16 @@ static bool trans_b_gate(DisasContext *ctx, arg_b_gate 
*a)
 
 static bool trans_blr(DisasContext *ctx, arg_blr *a)
 {
-TCGv_reg tmp = get_temp(ctx);
-
-tcg_gen_shli_reg(tmp, load_gpr(ctx, a->x), 3);
-tcg_gen_addi_reg(tmp, tmp, ctx->iaoq_f + 8);
-/* The computation here never changes privilege level.  */
-return do_ibranch(ctx, tmp, a->l, a->n);
+if (a->x) {
+TCGv_reg tmp = get_temp(ctx);
+tcg_gen_shli_reg(tmp, load_gpr(ctx, a->x), 3);
+tcg_gen_addi_reg(tmp, tmp, ctx->iaoq_f + 8);
+/* The computation here never changes privilege level.  */
+return do_ibranch(ctx, tmp, a->l, a->n);
+} else {
+/* BLR R0,RX is a good way to load PC+8 into RX.  */
+return do_dbranch(ctx, ctx->iaoq_f + 8, a->l, a->n);
+}
 }
 
 static bool trans_bv(DisasContext *ctx, arg_bv *a)
-- 
2.17.2




Re: [Qemu-devel] Question about VM virtio device's link down delay when vhost-user reconnect

2019-03-07 Thread Lilijun (Jerry, Cloud Networking)
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> 
> On Wed, Mar 06, 2019 at 07:36:44AM +, Lilijun (Jerry, Cloud Networking)
> wrote:
> > Thanks a lot for your advice.
> >
> > Maybe there are two methods to add this option:
> > 1) Firstly, add a vhost-user protocol feature to tell Qemu if hide the
> disconnects from the guest.  Here we just need the backend such as dpdk
> vhostuser to support this option and the feature.
> > 2) Secondly, add a VM XML vhost-user nic configuration parameters for
> Qemu.  This method need more modification and other components such as
> Libvirt and Nova in openstack to configure it.
> >
> > I'd like to choose the first method,  Do you think so?
> 
> What we need to decide this is - when is it a good idea to down the link on
> disconnect.
> If it depends on vm configuration then it belongs with qemu.
> If it depends on hardware or other host configuration it might belong with
> the backend.
> 

In my opinion, the vhost-user disconnects is related with the host backend 
process's restart or other socket close.

So, we can add a host configuration such as ovs/dpdk  vhostuser interface's 
options(ovs-vsctl set interface) to tell Qemu hide the disconnects by vhostuser 
protocol feature negotiation.

Thanks

> 
> 
> > To monitor the status of connection, we can using the command " virsh
> qemu-monitor-command vm1 --hmp info chardev " to lookup that status.
> Another one is to add new type event for Qemu to notify libvirt or other
> upper level components.
> >
> > Jerry
> >
> > > -Original Message-
> > > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > > Sent: Tuesday, March 05, 2019 10:39 AM
> > > To: Lilijun (Jerry, Cloud Networking) 
> > > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Liujinsong (Paul)
> > > ; lixiao (H) ;
> > > wangyunjian ; wangxin (U)
> > > ; Gonglei (Arei)
> > > 
> > > Subject: Re: Question about VM virtio device's link down delay when
> > > vhost- user reconnect
> > >
> > > On Mon, Mar 04, 2019 at 11:46:32AM +, Lilijun (Jerry, Cloud
> > > Networking)
> > > wrote:
> > > > Hi all,
> > > >
> > > >   I am running my VM using vhost-user NIC with OVS-DPDK.  The
> > > > steps of
> > > my question is shown as follows:
> > > >  1) In the VM, I add one route entry manually on the vNIC eth0
> > > > using
> > > "route add default gw 192.168.1.2".
> > > >  2) If openvswitch service was restarted, or the process
> > > > ovs-vswitchd was
> > > aborted, the new process may be started successfully after long
> > > seconds such as 40s for the initialization of DPDK huge page memory.
> > > >  3) And Qemu's vhost-user closed the connection and
> > > > reconnected
> > > successfully after 40s.
> > > >  4) Here VM's vNIC will receive link down and up events, the
> > > > interval
> > > between the two events is about 40s.
> > > >  5) Then I found that route entry disappeared unexpectedly.
> > > > This will
> > > cause some network traffic problems.
> > > >
> > > >  I have an idea about this problem. We can add a parameter "
> > > link_down_delay" for all virtio devices that use vhost-user socket
> > > such as virtio-net and virtio-blk.
> > > >
> > > > If vhost-user socket get a connection closed event when the
> > > > backend
> > > process was aborted or restarted, we don't notify VM virtio-net
> > > device link down right now.
> > > >When the vhost-user backend recover this socket's connections
> > > > before
> > > the time of "link_down_delay" ms passed, we need not do that link
> > > down notification to VM.
> > > >Or else, if that's timeout, VM can be notified the link down
> > > > event as
> > > before.
> > > >
> > > > Is there any other opinions about this solution?  Or some better 
> > > > ideas?
> > > Thanks.
> > > >
> > > > B.R.
> > > >
> > > > Jerry
> > > >
> > >
> > > Rather than hardcode a specific timeout policy, I would go further
> > > and start with an option to just hide disconnects from guest completely.
> > > Instead add commands to monitor status of connection and events to
> > > report changes.  Management tools can then mirror connection status
> > > to link if they want to.
> > >
> > > --
> > > MST



[Qemu-devel] [PATCH v2 18/18] hw/arm/virt: Use edk2_add_host_crypto_policy()

2019-03-07 Thread Philippe Mathieu-Daudé
Enable the EDK2 Crypto Policy features on the Virt machine.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/virt.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index bb7255a080..bc2b14af48 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -56,6 +56,7 @@
 #include "hw/intc/arm_gicv3_common.h"
 #include "kvm_arm.h"
 #include "hw/firmware/smbios.h"
+#include "hw/firmware/uefi_edk2.h"
 #include "qapi/visitor.h"
 #include "standard-headers/linux/input.h"
 #include "hw/arm/smmuv3.h"
@@ -1301,6 +1302,11 @@ static void virt_build_smbios(VirtMachineState *vms)
 }
 }
 
+static void virt_uefi_setup(VirtMachineState *vms)
+{
+edk2_add_host_crypto_policy(vms->fw_cfg);
+}
+
 static
 void virt_machine_done(Notifier *notifier, void *data)
 {
@@ -1329,6 +1335,7 @@ void virt_machine_done(Notifier *notifier, void *data)
 
 virt_acpi_setup(vms);
 virt_build_smbios(vms);
+virt_uefi_setup(vms);
 }
 
 static uint64_t virt_cpu_mp_affinity(VirtMachineState *vms, int idx)
-- 
2.20.1




[Qemu-devel] [PATCH v2 17/18] hw/i386: Use edk2_add_host_crypto_policy()

2019-03-07 Thread Philippe Mathieu-Daudé
Enable the EDK2 Crypto Policy features on the PC machine.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/pc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0848cdc18f..736211d623 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -38,6 +38,7 @@
 #include "hw/nvram/fw_cfg.h"
 #include "hw/timer/hpet.h"
 #include "hw/firmware/smbios.h"
+#include "hw/firmware/uefi_edk2.h"
 #include "hw/loader.h"
 #include "elf.h"
 #include "multiboot.h"
@@ -1067,6 +1068,11 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
 return fw_cfg;
 }
 
+static void pc_uefi_setup(PCMachineState *pcms)
+{
+edk2_add_host_crypto_policy(pcms->fw_cfg);
+}
+
 static long get_file_size(FILE *f)
 {
 long where, size;
@@ -1666,6 +1672,7 @@ void pc_machine_done(Notifier *notifier, void *data)
 if (pcms->fw_cfg) {
 pc_build_smbios(pcms);
 pc_build_feature_control_file(pcms);
+pc_uefi_setup(pcms);
 /* update FW_CFG_NB_CPUS to account for -device added CPUs */
 fw_cfg_modify_i16(pcms->fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
 }
-- 
2.20.1




[Qemu-devel] [PATCH v2 16/18] hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()

2019-03-07 Thread Philippe Mathieu-Daudé
The Edk2Crypto object is used to hold configuration values specific
to EDK2.

The edk2_add_host_crypto_policy() function loads crypto policies
from the host, and register them as fw_cfg named file items.
So far only the 'https' policy is supported.

An usercase example is the 'HTTPS Boof' feature of OVMF [*].

Usage example:

  $ qemu-system-x86_64 \
  -object edk2_crypto,id=https,\
  ciphers=/etc/crypto-policies/back-ends/openssl.config,\
  cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin

(On Fedora these files are provided by the ca-certificates and
crypto-policies packages).

[*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README

Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS |   8 ++
 hw/Makefile.objs|   1 +
 hw/firmware/Makefile.objs   |   1 +
 hw/firmware/uefi_edk2_crypto_policies.c | 166 
 include/hw/firmware/uefi_edk2.h |  28 
 5 files changed, 204 insertions(+)
 create mode 100644 hw/firmware/Makefile.objs
 create mode 100644 hw/firmware/uefi_edk2_crypto_policies.c
 create mode 100644 include/hw/firmware/uefi_edk2.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 306fc2aefa..3696b63249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2205,6 +2205,14 @@ F: include/hw/i2c/smbus_master.h
 F: include/hw/i2c/smbus_slave.h
 F: include/hw/i2c/smbus_eeprom.h
 
+EDK2 Firmware
+M: Laszlo Ersek 
+M: Philippe Mathieu-Daudé 
+S: Maintained
+F: docs/interop/firmware.json
+F: hw/firmware/uefi_edk2_crypto_policies.c
+F: include/hw/firmware/uefi_edk2.h
+
 Usermode Emulation
 --
 Overall
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index e2fcd6aafc..da4fb91285 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -8,6 +8,7 @@ devices-dirs-$(CONFIG_SOFTMMU) += char/
 devices-dirs-$(CONFIG_SOFTMMU) += cpu/
 devices-dirs-$(CONFIG_SOFTMMU) += display/
 devices-dirs-$(CONFIG_SOFTMMU) += dma/
+devices-dirs-$(CONFIG_SOFTMMU) += firmware/
 devices-dirs-$(CONFIG_SOFTMMU) += gpio/
 devices-dirs-$(CONFIG_HYPERV) += hyperv/
 devices-dirs-$(CONFIG_SOFTMMU) += i2c/
diff --git a/hw/firmware/Makefile.objs b/hw/firmware/Makefile.objs
new file mode 100644
index 00..ea1f6d44df
--- /dev/null
+++ b/hw/firmware/Makefile.objs
@@ -0,0 +1 @@
+common-obj-y += uefi_edk2_crypto_policies.o
diff --git a/hw/firmware/uefi_edk2_crypto_policies.c 
b/hw/firmware/uefi_edk2_crypto_policies.c
new file mode 100644
index 00..660c7f3655
--- /dev/null
+++ b/hw/firmware/uefi_edk2_crypto_policies.c
@@ -0,0 +1,166 @@
+/*
+ * UEFI EDK2 Support
+ *
+ * Copyright (c) 2019 Red Hat Inc.
+ *
+ * Author:
+ *  Philippe Mathieu-Daudé 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "hw/firmware/uefi_edk2.h"
+
+
+#define TYPE_EDK2_CRYPTO "edk2_crypto"
+
+#define EDK2_CRYPTO_CLASS(klass) \
+ OBJECT_CLASS_CHECK(Edk2CryptoClass, (klass), \
+TYPE_EDK2_CRYPTO)
+#define EDK2_CRYPTO_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(Edk2CryptoClass, (obj), \
+  TYPE_EDK2_CRYPTO)
+#define EDK2_CRYPTO(obj) \
+ INTERFACE_CHECK(Edk2Crypto, (obj), \
+ TYPE_EDK2_CRYPTO)
+
+typedef struct Edk2Crypto {
+Object parent_obj;
+
+/*
+ * Path to the acceptable ciphersuites and the preferred order from
+ * the host-side crypto policy.
+ */
+char *ciphers_path;
+
+/* Path to the trusted CA certificates configured on the host side. */
+char *cacerts_path;
+} Edk2Crypto;
+
+typedef struct Edk2CryptoClass {
+ObjectClass parent_class;
+} Edk2CryptoClass;
+
+
+static void edk2_crypto_prop_set_ciphers(Object *obj, const char *value,
+ Error **errp G_GNUC_UNUSED)
+{
+Edk2Crypto *s = EDK2_CRYPTO(obj);
+
+g_free(s->ciphers_path);
+s->ciphers_path = g_strdup(value);
+}
+
+static char *edk2_crypto_prop_get_ciphers(Object *obj,
+  Error **errp G_GNUC_UNUSED)
+{
+Edk2Crypto *s = EDK2_CRYPTO(obj);
+
+return g_strdup(s->ciphers_path);
+}
+
+static void edk2_crypto_prop_set_cacerts(Object *obj, const char *value,
+ Error **errp G_GNUC_UNUSED)
+{
+Edk2Crypto *s = EDK2_CRYPTO(obj);
+
+g_free(s->cacerts_path);
+s->cacerts_path = g_strdup(value);
+}
+
+static char *edk2_crypto_prop_get_cacerts(Object *obj,
+  Error **errp G_GNUC_UNUSED)
+{
+Edk2Crypto *s = EDK2_CRYPTO(obj);
+
+return g_strdup(s->cacerts_path);
+}
+
+static void edk2_crypto_finalize(Object *obj)
+{
+Edk2Crypto *s = EDK2_CRYPTO(obj);
+
+g_free(s->ciphers_path);
+g_free(s->cacerts_path);
+}
+
+static void edk2_crypto_class_init(ObjectClass *oc, void *data)
+{
+

[Qemu-devel] [PATCH v2 13/18] hw/nvram/fw_cfg: Add QMP 'info fw_cfg' command

2019-03-07 Thread Philippe Mathieu-Daudé
When debugging a paravirtualized guest firmware, it results very
useful to dump the fw_cfg table.
Add a QMP command which returns the most useful fields.
Since the QMP protocol is not designed for passing stream data,
we don't display a fw_cfg item data, only it's size:

{ "execute": "query-fw_cfg-items" }
{
"return": [
{
"architecture_specific": false,
"key": 0,
"writeable": false,
"size": 4,
"keyname": "signature"
},
{
"architecture_specific": false,
"key": 1,
"writeable": false,
"size": 4,
"keyname": "id"
},
{
"architecture_specific": false,
"key": 2,
"writeable": false,
"size": 16,
"keyname": "uuid"
},
...
{
"order": 40,
"architecture_specific": false,
"key": 36,
"writeable": false,
"path": "etc/e820",
"size": 20,
"keyname": "file"
},
{
"order": 30,
"architecture_specific": false,
"key": 37,
"writeable": false,
"path": "etc/smbios/smbios-anchor",
"size": 31,
"keyname": "file"
},
...
{
"architecture_specific": true,
"key": 3,
"writeable": false,
"size": 324,
"keyname": "e820_tables"
},
{
"architecture_specific": true,
"key": 4,
"writeable": false,
"size": 121,
"keyname": "hpet"
}
]
}

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: New commit, asked by Eric/Michael, using Laszlo suggestions
---
 hw/nvram/fw_cfg.c | 76 +++
 qapi/misc.json| 44 +++
 2 files changed, 120 insertions(+)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index fc392cb7e0..2a8d69ba07 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -35,6 +35,7 @@
 #include "qemu/config-file.h"
 #include "qemu/cutils.h"
 #include "qapi/error.h"
+#include "qapi/qapi-commands-misc.h"
 
 #define FW_CFG_FILE_SLOTS_DFLT 0x20
 
@@ -1229,3 +1230,78 @@ static void fw_cfg_register_types(void)
 }
 
 type_init(fw_cfg_register_types)
+
+static FirmwareConfigurationItem *create_qmp_fw_cfg_item(FWCfgState *s,
+ FWCfgEntry *e,
+ bool is_arch_specific,
+ uint16_t key,
+ size_t hex_length)
+{
+FirmwareConfigurationItem *item = g_malloc0(sizeof(*item));
+
+item->key = key;
+item->writeable = e->allow_write;
+item->architecture_specific = is_arch_specific;
+item->size = e->len;
+if (hex_length) {
+item->has_data = true;
+item->data = qemu_strdup_hexlify(e->data, hex_length);
+}
+
+if (!is_arch_specific && key >= FW_CFG_FILE_FIRST) {
+int id = key - FW_CFG_FILE_FIRST;
+const char *path = s->files->f[id].name;
+
+item->has_keyname = true;
+item->keyname = g_strdup("file");
+item->has_order = true;
+item->order = get_fw_cfg_order(s, path);
+item->has_path = true;
+item->path = g_strdup(path);
+} else {
+const char *name;
+
+if (is_arch_specific) {
+key |= FW_CFG_ARCH_LOCAL;
+}
+name = key_name(key);
+if (name) {
+item->has_keyname = true;
+item->keyname = g_strdup(name);
+}
+}
+return item;
+}
+
+FirmwareConfigurationItemList *qmp_query_fw_cfg_items(Error **errp)
+{
+FirmwareConfigurationItemList *item_list = NULL;
+uint32_t max_entries;
+int arch, key;
+FWCfgState *s = fw_cfg_find();
+
+if (s == NULL) {
+return NULL;
+}
+
+max_entries = fw_cfg_max_entry(s);
+for (arch = ARRAY_SIZE(s->entries) - 1; arch >= 0 ; --arch) {
+for (key = max_entries - 1; key >= 0; --key) {
+FirmwareConfigurationItemList *info;
+FWCfgEntry *e = >entries[arch][key];
+size_t qmp_hex_length = 0;
+
+if (!e->len) {
+continue;
+}
+
+info = g_malloc0(sizeof(*info));
+info->value = create_qmp_fw_cfg_item(s, e, arch, key,
+ qmp_hex_length);
+info->next = item_list;
+item_list = info;
+}
+}
+
+return item_list;
+}
diff --git a/qapi/misc.json b/qapi/misc.json
index 8b3ca4fdd3..9d1da7c766 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -3051,3 +3051,47 @@
   'data': 'NumaOptions',
   'allow-preconfig': true
 }
+
+##
+# @FirmwareConfigurationItem:
+#
+# Firmware 

[Qemu-devel] [PATCH v2 15/18] hw/nvram/fw_cfg: Add fw_cfg_add_file_from_host()

2019-03-07 Thread Philippe Mathieu-Daudé
Add a function to read the full content of file on the host, and add
a new 'file' name item to the fw_cfg device.

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: s/ptr/data, corrected documentation (Laszlo)
---
 hw/nvram/fw_cfg.c | 21 +
 include/hw/nvram/fw_cfg.h | 23 +++
 2 files changed, 44 insertions(+)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 4c82dcc125..a46a7c8f06 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -890,6 +890,27 @@ void fw_cfg_add_file(FWCfgState *s,  const char *filename,
 fw_cfg_add_file_callback(s, filename, NULL, NULL, NULL, data, len, true);
 }
 
+void *fw_cfg_add_file_from_host(FWCfgState *s, const char *filename,
+const char *host_path, size_t *len)
+{
+GError *gerr = NULL;
+gchar *data = NULL;
+gsize contents_len = 0;
+
+if (g_file_get_contents(host_path, , _len, )) {
+fw_cfg_add_file(s, filename, data, contents_len);
+} else {
+error_report("%s", gerr->message);
+g_error_free(gerr);
+return NULL;
+}
+if (len) {
+*len = contents_len;
+}
+
+return data;
+}
+
 void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
 void *data, size_t len)
 {
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 5ac9adfe1f..75a29858dc 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -172,6 +172,29 @@ void fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t 
value);
 void fw_cfg_add_file(FWCfgState *s, const char *filename, void *data,
  size_t len);
 
+/**
+ * fw_cfg_add_file_from_host:
+ * @s: fw_cfg device being modified
+ * @filename: name of new fw_cfg file item
+ * @host_path: path of the host file to read the data from
+ * @len: pointer to hold the length of the host file (optional)
+ *
+ * Read the content of a host file as a raw "blob" then add a new NAMED
+ * fw_cfg item of the file size. If @len is provided, it will contain the
+ * total length read from the host file. The data read from the host
+ * filesystem is owned by the new fw_cfg entry, and is stored into the data
+ * structure of the fw_cfg device.
+ * The next available (unused) selector key starting at FW_CFG_FILE_FIRST
+ * will be used; also, a new entry will be added to the file directory
+ * structure residing at key value FW_CFG_FILE_DIR, containing the item name,
+ * data size, and assigned selector key value.
+ *
+ * Returns: pointer to the newly allocated file content, or NULL if an error
+ * occured. The returned pointer must be freed with g_free().
+ */
+void *fw_cfg_add_file_from_host(FWCfgState *s, const char *filename,
+const char *host_path, size_t *len);
+
 /**
  * fw_cfg_add_file_callback:
  * @s: fw_cfg device being modified
-- 
2.20.1




[Qemu-devel] [PATCH qemu v5] spapr: Support NVIDIA V100 GPU with NVLink2

2019-03-07 Thread Alexey Kardashevskiy
NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
implements special regions for such GPUs and emulates an NVLink bridge.
NVLink2-enabled POWER9 CPUs also provide address translation services
which includes an ATS shootdown (ATSD) register exported via the NVLink
bridge device.

This adds a quirk to VFIO to map the GPU memory and create an MR;
the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
this to get the MR and map it to the system address space.
Another quirk does the same for ATSD.

This adds additional steps to sPAPR PHB setup:

1. Search for specific GPUs and NPUs, collect findings in
sPAPRPHBState::nvgpus, manage system address space mappings;

2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
"memory-block", "link-speed" to advertise the NVLink2 function to
the guest;

3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;

4. Add new memory blocks (with extra "linux,memory-usable" to prevent
the guest OS from accessing the new memory until it is onlined) and
npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
uses it for link discovery.

This allocates space for GPU RAM and ATSD like we do for MMIOs by
adding 2 new parameters to the phb_placement() hook. Older machine types
set these to zero.

This puts new memory nodes in a separate NUMA node to replicate the host
system setup as the GPU driver relies on this.

This adds requirement similar to EEH - one IOMMU group per vPHB.
The reason for this is that ATSD registers belong to a physical NPU
so they cannot invalidate translations on GPUs attached to another NPU.
It is guaranteed by the host platform as it does not mix NVLink bridges
or GPUs from different NPU in the same IOMMU group. If more than one
IOMMU group is detected on a vPHB, this disables ATSD support for that
vPHB and prints a warning.

Signed-off-by: Alexey Kardashevskiy 
---

This is based on David's ppc-for-4.0 +
applied but not pushed "iommu replay": 
https://patchwork.ozlabs.org/patch/1052644/
acked "vfio_info_cap public": https://patchwork.ozlabs.org/patch/1052645/


Changes:
v5:
* converted MRs to VFIOQuirk - this fixed leaks

v4:
* fixed ATSD placement
* fixed spapr_phb_unrealize() to do nvgpu cleanup
* replaced warn_report() with Error*

v3:
* moved GPU RAM above PCI MMIO limit
* renamed QOM property to nvlink2-tgt
* moved nvlink2 code to its own file

---

The example command line for redbud system:

pbuild/qemu-aiku1804le-ppc64/ppc64-softmmu/qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
-enable-kvm -m 384G \
-chardev socket,id=SOCKET0,server,nowait,host=localhost,port=4 \
-mon chardev=SOCKET0,mode=control \
-smp 80,sockets=1,threads=4 \
-netdev "tap,id=TAP0,helper=/home/aik/qemu-bridge-helper --br=br0" \
-device "virtio-net-pci,id=vnet0,mac=52:54:00:12:34:56,netdev=TAP0" \
img/vdisk0.img \
-device "vfio-pci,id=vfio0004_04_00_0,host=0004:04:00.0" \
-device "vfio-pci,id=vfio0006_00_00_0,host=0006:00:00.0" \
-device "vfio-pci,id=vfio0006_00_00_1,host=0006:00:00.1" \
-device "vfio-pci,id=vfio0006_00_00_2,host=0006:00:00.2" \
-device "vfio-pci,id=vfio0004_05_00_0,host=0004:05:00.0" \
-device "vfio-pci,id=vfio0006_00_01_0,host=0006:00:01.0" \
-device "vfio-pci,id=vfio0006_00_01_1,host=0006:00:01.1" \
-device "vfio-pci,id=vfio0006_00_01_2,host=0006:00:01.2" \
-device spapr-pci-host-bridge,id=phb1,index=1 \
-device "vfio-pci,id=vfio0035_03_00_0,host=0035:03:00.0" \
-device "vfio-pci,id=vfio0007_00_00_0,host=0007:00:00.0" \
-device "vfio-pci,id=vfio0007_00_00_1,host=0007:00:00.1" \
-device "vfio-pci,id=vfio0007_00_00_2,host=0007:00:00.2" \
-device "vfio-pci,id=vfio0035_04_00_0,host=0035:04:00.0" \
-device "vfio-pci,id=vfio0007_00_01_0,host=0007:00:01.0" \
-device "vfio-pci,id=vfio0007_00_01_1,host=0007:00:01.1" \
-device "vfio-pci,id=vfio0007_00_01_2,host=0007:00:01.2" -snapshot \
-machine pseries \
-L /home/aik/t/qemu-ppc64-bios/ -d guest_errors

Note that QEMU attaches PCI devices to the last added vPHB so first
8 devices - 4:04:00.0 till 6:00:01.2 - go to the default vPHB, and
35:03:00.0..7:00:01.2 to the vPHB with id=phb1.
---
 hw/ppc/Makefile.objs|   2 +-
 hw/vfio/pci.h   |   2 +
 include/hw/pci-host/spapr.h |  45 
 include/hw/ppc/spapr.h  |   3 +-
 hw/ppc/spapr.c  |  29 ++-
 hw/ppc/spapr_pci.c  |  19 ++
 hw/ppc/spapr_pci_nvlink2.c  | 441 
 hw/vfio/pci-quirks.c| 132 +++
 hw/vfio/pci.c   |  14 ++
 hw/vfio/trace-events|   4 +
 10 files changed, 686 insertions(+), 5 deletions(-)
 create mode 100644 hw/ppc/spapr_pci_nvlink2.c

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index b218a048..636e717f207c 100644
--- a/hw/ppc/Makefile.objs

[Qemu-devel] [PATCH v2 11/18] hw/nvram/fw_cfg: Add boot_splash.time_le16 to FWCfgState

2019-03-07 Thread Philippe Mathieu-Daudé
Similar to the previous commit, use the FWCfgState lifetime state
to hold the 'bst_le16' variable content (renaned as time_le16).
Doing so we avoid a memory leak.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 6 +++---
 include/hw/nvram/fw_cfg.h | 3 +++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 182d27f59a..3ac6687a04 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -187,7 +187,6 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 /* insert splash time if user configurated */
 if (boot_splash_time) {
 int64_t bst_val = qemu_opt_get_number(opts, "splash-time", -1);
-uint16_t bst_le16;
 
 /* validate the input */
 if (bst_val < 0 || bst_val > 0x) {
@@ -196,9 +195,10 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 exit(1);
 }
 /* use little endian format */
-bst_le16 = cpu_to_le16(bst_val);
+s->boot_splash.time_le16 = cpu_to_le16(bst_val);
 fw_cfg_add_file(s, "etc/boot-menu-wait",
-g_memdup(_le16, sizeof bst_le16), sizeof bst_le16);
+>boot_splash.time_le16,
+sizeof(s->boot_splash.time_le16));
 }
 
 /* insert splash file if user configurated */
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 99f6fafcaa..fcb771186c 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -55,6 +55,9 @@ struct FWCfgState {
 MemoryRegion dma_iomem;
 
 uint32_t reboot_timeout;
+struct {
+uint16_t time_le16;
+} boot_splash;
 };
 
 struct FWCfgIoState {
-- 
2.20.1




[Qemu-devel] [PATCH v2 14/18] hw/nvram/fw_cfg: Add HMP 'info fw_cfg' command

2019-03-07 Thread Philippe Mathieu-Daudé
When debugging a paravirtualized guest firmware, it results very
useful to dump the fw_cfg table.
Add a HMP command which displays the most useful fields.
We display each fw_cfg item data in hexadecimal (only the first 8
bytes):

$ (echo info fw_cfg; echo q) | qemu-system-x86_64 -S -monitor stdio
(qemu) info fw_cfg
Selector  Well-Known Key  Pathname ArchSpec Perm   Size Order Hex Data
 0x   signature  RO   4   51454d55
 0x0001   id RO   4   0300
 0x0002   uuid   RO  16   ..
 0x0003   ram_size   RO   8   0008
 0x0004   nographic  RO   2   
 0x0005   nb_cpusRO   2   0100
 0x000d   numa   RO  16   ..
 0x000e   boot_menu  RO   2   
 0x000f   max_cpus   RO   2   0100
 0x0019   file_dir   RO2052   000b..
 0x0021   file: etc/acpi/rsdpRO  20  160  5253442050545220..
 0x0022   file: etc/acpi/tables  RO  131072  130  464143534000..
 0x0023   file: etc/boot-fail-wait   RO   4   15  
 0x0024   file: etc/e820 RO  20   40  ..
 0x0025   file: etc/smbios/smbios-anchor RO  31   30  5f534d5f001f0208..
 0x0026   file: etc/smbios/smbios-tables RO 321   20  011b000101020300..
 0x0027   file: etc/system-statesRO   6   90  80818280
 0x0028   file: etc/table-loader RO4096  140  01006574632f..
 0x002a   file: genroms/kvmvapic.bin RO9216   55  55aa12060e0731c0..
 0x0002   irq0_override   *  RO   4   0100
 0x0003   e820_tables *  RO 324   ..
 0x0004   hpet*  RO 121   0101a28680d0..
(qemu) q

$ (echo info fw_cfg; echo q) | qemu-system-mips -S -monitor stdio
(qemu) info fw_cfg
This machine does not use fw_cfg
(qemu) q

$ (echo info fw_cfg; echo q) | qemu-system-ppc -S -monitor stdio
(qemu) info fw_cfg
Selector  Well-Known Key  Pathname ArchSpec Perm   Size Order Hex Data
 0x   signature  RO   4   51454d55
 0x0001   id RO   4   0100
 0x0002   uuid   RO  16   ..
 0x0003   ram_size   RO   8   0008
 0x0004   nographic  RO   2   
 0x0005   nb_cpusRO   2   0100
 0x0006   machine_id RO   2   0200
 0x0007   kernel_addrRO   4   
 0x0008   kernel_sizeRO   4   
 0x0009   kernel_cmdline RO   4   
 0x000a   initrd_addrRO   4   
 0x000b   initdr_sizeRO   4   
 0x000c   boot_deviceRO   2   6300
 0x000e   boot_menu  RO   2   
 0x000f   max_cpus   RO   2   0100
 0x0019   file_dir   RO2052   0002..
 0x0021   file: etc/boot-fail-wait   RO   4   15  
 0x   width   *  RO   2   2003
 0x0001   height  *  RO   2   5802
 0x0002   depth   *  RO   2   2000
 0x0003   tbfreq  *  RO   4   c04bfd00
 0x0004   clockfreq   *  RO   4   80d6da0f
 0x0005   is_kvm  *  RO   4   
 0x0009   busfreq *  RO   4   8014ef03
(qemu) q

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Check fw_cfg != NULL (Michael)
Rename keys, display data in hexa (Laszlo)
---
 hmp-commands-info.hx  | 17 ++
 hw/nvram/fw_cfg.c | 71 ++-
 include/hw/nvram/fw_cfg.h |  2 ++
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index cbee8b944d..2c9538c8da 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -916,6 +916,23 @@ STEXI
 @item info sev
 @findex info sev
 Show SEV information.
+ETEXI
+
+{
+.name   = "fw_cfg",
+.args_type  = "",
+.params = "",
+.help   = "Display the table firmware configuration entries "
+  "registered by a paravirtualized machine. Helpful "
+  "when debugging guest firmwares.",
+.cmd= hmp_info_fw_cfg,
+},
+
+STEXI

[Qemu-devel] [PATCH v2 08/18] hw/nvram/fw_cfg: Move fw_cfg_file_slots_allocate() to common_realize()

2019-03-07 Thread Philippe Mathieu-Daudé
Each implementation (I/O and MEM) calls fw_cfg_file_slots_allocate()
then fw_cfg_common_realize().
Simplify by moving the fw_cfg_file_slots_allocate() call into
fw_cfg_common_realize() where it belongs.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 0fb020edce..ca58d279a4 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -929,19 +929,26 @@ static void fw_cfg_machine_ready(struct Notifier *n, void 
*data)
 qemu_register_reset(fw_cfg_machine_reset, s);
 }
 
-
+static void fw_cfg_file_slots_allocate(FWCfgState *s, Error **errp);
 
 static void fw_cfg_common_realize(DeviceState *dev, Error **errp)
 {
 FWCfgState *s = FW_CFG(dev);
 MachineState *machine = MACHINE(qdev_get_machine());
 uint32_t version = FW_CFG_VERSION;
+Error *local_err = NULL;
 
 if (!fw_cfg_find()) {
 error_setg(errp, "at most one %s device is permitted", TYPE_FW_CFG);
 return;
 }
 
+fw_cfg_file_slots_allocate(s, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
 fw_cfg_add_bytes(s, FW_CFG_SIGNATURE, (char *)"QEMU", 4);
 fw_cfg_add_bytes(s, FW_CFG_UUID, _uuid, 16);
 fw_cfg_add_i16(s, FW_CFG_NOGRAPHIC, (uint16_t)!machine->enable_graphics);
@@ -1108,7 +1115,7 @@ static void fw_cfg_io_realize(DeviceState *dev, Error 
**errp)
 FWCfgIoState *s = FW_CFG_IO(dev);
 Error *local_err = NULL;
 
-fw_cfg_file_slots_allocate(FW_CFG(s), _err);
+fw_cfg_common_realize(dev, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
@@ -1125,8 +1132,6 @@ static void fw_cfg_io_realize(DeviceState *dev, Error 
**errp)
   _cfg_dma_mem_ops, FW_CFG(s), "fwcfg.dma",
   sizeof(dma_addr_t));
 }
-
-fw_cfg_common_realize(dev, errp);
 }
 
 static void fw_cfg_io_class_init(ObjectClass *klass, void *data)
@@ -1162,7 +1167,7 @@ static void fw_cfg_mem_realize(DeviceState *dev, Error 
**errp)
 const MemoryRegionOps *data_ops = _cfg_data_mem_ops;
 Error *local_err = NULL;
 
-fw_cfg_file_slots_allocate(FW_CFG(s), _err);
+fw_cfg_common_realize(dev, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
@@ -1189,8 +1194,6 @@ static void fw_cfg_mem_realize(DeviceState *dev, Error 
**errp)
   sizeof(dma_addr_t));
 sysbus_init_mmio(sbd, _CFG(s)->dma_iomem);
 }
-
-fw_cfg_common_realize(dev, errp);
 }
 
 static void fw_cfg_mem_class_init(ObjectClass *klass, void *data)
-- 
2.20.1




[Qemu-devel] [PATCH v2 10/18] hw/nvram/fw_cfg: Add reboot_timeout to FWCfgState

2019-03-07 Thread Philippe Mathieu-Daudé
Due to the contract interface of fw_cfg_add_file(), the
'reboot_timeout' data has to be valid for the lifetime of the
FwCfg object. For this reason it is copied on the heap with
memdup().

The object state, 'FWCfgState', is also meant to be valid during the
lifetime of the object.
Move the 'reboot_timeout' in FWCfgState to achieve the same purpose.
Doing so we avoid a memory leak.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 4 +++-
 include/hw/nvram/fw_cfg.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index b73a591eff..182d27f59a 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -250,7 +250,9 @@ static void fw_cfg_reboot(FWCfgState *s)
 }
 }
 
-fw_cfg_add_file(s, "etc/boot-fail-wait", g_memdup(_val, 4), 4);
+s->reboot_timeout = rt_val;
+fw_cfg_add_file(s, "etc/boot-fail-wait",
+>reboot_timeout, sizeof(s->reboot_timeout));
 }
 
 static void fw_cfg_write(FWCfgState *s, uint8_t value)
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 828ad9dedc..99f6fafcaa 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -53,6 +53,8 @@ struct FWCfgState {
 dma_addr_t dma_addr;
 AddressSpace *dma_as;
 MemoryRegion dma_iomem;
+
+uint32_t reboot_timeout;
 };
 
 struct FWCfgIoState {
-- 
2.20.1




[Qemu-devel] [PATCH v2 12/18] hw/nvram/fw_cfg: Keep reference of file_data in FWCfgState

2019-03-07 Thread Philippe Mathieu-Daudé
The 'file_data' is allocated by read_splashfile() (introduced in
commit 3d3b8303c6f8).  It is then used by fw_cfg_add_file(). Due
to the contract interface of fw_cfg_add_file(), it has to be valid
for the lifetime of the FwCfg object.

Keep a reference of 'file_data' in FWCfgState to be able to
free this memory in fw_cfg_common_unrealize().
We can now remove the res_free() from the main() loop.
The global boot_splash_filedata is now unused, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 10 ++
 include/hw/nvram/fw_cfg.h |  1 +
 include/sysemu/sysemu.h   |  1 -
 vl.c  |  9 -
 4 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 3ac6687a04..fc392cb7e0 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -215,16 +215,16 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 g_free(filename);
 return;
 }
-g_free(boot_splash_filedata);
-boot_splash_filedata = (uint8_t *)file_data;
+g_free(s->boot_splash.file_data);
+s->boot_splash.file_data = file_data;
 
 /* insert data */
 if (file_type == JPG_FILE) {
 fw_cfg_add_file(s, "bootsplash.jpg",
-boot_splash_filedata, file_size);
+s->boot_splash.file_data, file_size);
 } else {
 fw_cfg_add_file(s, "bootsplash.bmp",
-boot_splash_filedata, file_size);
+s->boot_splash.file_data, file_size);
 }
 g_free(filename);
 }
@@ -974,6 +974,8 @@ static void fw_cfg_common_unrealize(DeviceState *dev, Error 
**errp)
 
 g_free(s->files);
 
+g_free(s->boot_splash.file_data);
+
 g_free(s->entries[0]);
 g_free(s->entries[1]);
 g_free(s->entry_order);
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index fcb771186c..83a0540b6c 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -56,6 +56,7 @@ struct FWCfgState {
 
 uint32_t reboot_timeout;
 struct {
+char *file_data;
 uint16_t time_le16;
 } boot_splash;
 };
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 6065d9e420..3cd856b015 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -109,7 +109,6 @@ extern int no_shutdown;
 extern int old_param;
 extern int boot_menu;
 extern bool boot_strict;
-extern uint8_t *boot_splash_filedata;
 extern bool enable_mlock;
 extern bool enable_cpu_pm;
 extern QEMUClockType rtc_clock;
diff --git a/vl.c b/vl.c
index fad6fec38c..47dd63a309 100644
--- a/vl.c
+++ b/vl.c
@@ -187,7 +187,6 @@ unsigned int nb_prom_envs = 0;
 const char *prom_envs[MAX_PROM_ENVS];
 int boot_menu;
 bool boot_strict;
-uint8_t *boot_splash_filedata;
 bool wakeup_suspend_enabled;
 
 int icount_align_option;
@@ -558,12 +557,6 @@ const char *qemu_get_vm_name(void)
 return qemu_name;
 }
 
-static void res_free(void)
-{
-g_free(boot_splash_filedata);
-boot_splash_filedata = NULL;
-}
-
 static int default_driver_check(void *opaque, QemuOpts *opts, Error **errp)
 {
 const char *driver = qemu_opt_get(opts, "driver");
@@ -4591,8 +4584,6 @@ int main(int argc, char **argv, char **envp)
 job_cancel_sync_all();
 bdrv_close_all();
 
-res_free();
-
 /* vhost-user must be cleaned up before chardevs.  */
 tpm_cleanup();
 net_cleanup();
-- 
2.20.1




[Qemu-devel] [PATCH v2 03/18] cutils: Add qemu_strdup_hexlify() and qemu_strdup_unhexlify()

2019-03-07 Thread Philippe Mathieu-Daudé
Add two helpers: one to represent a binary data as a string of
hexadecimal values, and one to restore a such string into its
original binary data.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/qemu/cutils.h | 33 ++
 util/cutils.c | 55 +++
 2 files changed, 88 insertions(+)

diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index d2dad3057c..375a5508b0 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -171,6 +171,39 @@ bool test_buffer_is_zero_next_accel(void);
 int uleb128_encode_small(uint8_t *out, uint32_t n);
 int uleb128_decode_small(const uint8_t *in, uint32_t *n);
 
+/**
+ * qemu_strdup_hexlify:
+ *
+ * Encode a sequence of binary data into its hexadecimal stringified
+ * representation.
+ *
+ * @ptr: Buffer to hexlify
+ * @size: Length of the buffer
+ *
+ * Use qemu_strdup_unhexlify() to convert the hex string to original data.
+ *
+ * Returns: A newly allocated, zero-terminated hex encoded string representing
+ * the data. The returned string must be freed with g_free().
+ */
+gchar *qemu_strdup_hexlify(gconstpointer ptr, gsize size);
+
+/**
+ * qemu_strdup_unhexlify:
+ *
+ * Decode a sequence of hexadecimal encoded text into binary data.
+ *
+ * @hex_string: String to unhexlify
+ * @out_size: if not NULL: gsize to be written with the data length
+ *
+ * This function is the opposite of qemu_strdup_hexlify().
+ *
+ * Returns: A newly allocated buffer containing the binary data that text
+ * represents. The returned buffer must be freed with g_free().
+ * Note that the returned binary data is not necessarily zero-terminated,
+ * so it should not be used as a character string.
+ */
+gpointer qemu_strdup_unhexlify(const gchar *hex_string, gsize *out_size);
+
 /**
  * qemu_pstrcmp0:
  * @str1: a non-NULL pointer to a C string (*str1 can be NULL)
diff --git a/util/cutils.c b/util/cutils.c
index e098debdc0..bf324c0d8b 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -779,6 +779,61 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n)
 }
 }
 
+static guchar hexval(const gchar v)
+{
+switch (v) {
+case '0' ... '9':
+return v - '0';
+case 'A' ... 'F':
+return v - 'A' + 10;
+case 'a' ... 'f':
+return v - 'a' + 10;
+default:
+return 0;
+}
+}
+
+gchar *qemu_strdup_hexlify(gconstpointer ptr, gsize len)
+{
+guchar *data = (guchar *)ptr;
+gchar *hex_string;
+
+if (!ptr || !len) {
+return g_strdup("");
+}
+
+hex_string = g_malloc(2 * len + 1);
+for (gsize i = 0; i < len; i++) {
+g_snprintf(_string[2 * i], 3, "%02x", data[i]);
+}
+
+return hex_string;
+}
+
+gpointer qemu_strdup_unhexlify(const gchar *hex_string, gsize *out_size)
+{
+size_t size = 0;
+guchar *data = NULL;
+
+if (hex_string) {
+size = strlen(hex_string) / 2;
+if (size) {
+size_t i;
+
+data = g_new(guchar, size + 1);
+for (i = 0; i < size; i++) {
+data[i]  = hexval(*hex_string++) << 4;
+data[i] |= hexval(*hex_string++);
+}
+data[i] = '\0';
+}
+}
+if (out_size) {
+*out_size = size;
+}
+return data;
+}
+
 /*
  * helper to parse debug environment variables
  */
-- 
2.20.1




[Qemu-devel] [PATCH v2 09/18] hw/nvram/fw_cfg: Free file_slots in common_unrealize()

2019-03-07 Thread Philippe Mathieu-Daudé
Called by fw_cfg_common_realize(), fw_cfg_file_slots_allocate()
allocates various buffers.
Free them in fw_cfg_common_unrealize().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index ca58d279a4..b73a591eff 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -971,6 +971,10 @@ static void fw_cfg_common_unrealize(DeviceState *dev, 
Error **errp)
 FWCfgState *s = FW_CFG(dev);
 
 g_free(s->files);
+
+g_free(s->entries[0]);
+g_free(s->entries[1]);
+g_free(s->entry_order);
 }
 
 FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
-- 
2.20.1




[Qemu-devel] [PATCH v2 05/18] hw/nvram/fw_cfg: Use the ldst API

2019-03-07 Thread Philippe Mathieu-Daudé
The load/store API eases code review.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 684c2cf00a..8eb76a382c 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -141,7 +141,7 @@ static char *read_splashfile(char *filename, gsize 
*file_sizep,
 }
 
 /* check magic ID */
-filehead = ((content[0] & 0xff) + (content[1] << 8)) & 0x;
+filehead = lduw_le_p(content);
 if (filehead == 0xd8ff) {
 file_type = JPG_FILE;
 } else if (filehead == 0x4d42) {
@@ -152,7 +152,7 @@ static char *read_splashfile(char *filename, gsize 
*file_sizep,
 
 /* check BMP bpp */
 if (file_type == BMP_FILE) {
-bmp_bpp = (content[28] + (content[29] << 8)) & 0x;
+bmp_bpp = lduw_le_p([28]);
 if (bmp_bpp != 24) {
 goto error;
 }
-- 
2.20.1




[Qemu-devel] [PATCH v2 06/18] hw/nvram/fw_cfg: Remove the unnecessary boot_splash_filedata_size

2019-03-07 Thread Philippe Mathieu-Daudé
The 'boot_splash_filedata_size' was introduced as a global variable
in 3d3b8303c6f. This variable is used as a 'size' argument to the
fw_cfg_add_file(). This function has an interface contract with his
'data' argument, but there is no such contract for 'size' (this is
not a referenced pointer).  We can simply remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c   | 5 ++---
 include/sysemu/sysemu.h | 1 -
 vl.c| 1 -
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 8eb76a382c..b2dc0a80cb 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -217,15 +217,14 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 }
 g_free(boot_splash_filedata);
 boot_splash_filedata = (uint8_t *)file_data;
-boot_splash_filedata_size = file_size;
 
 /* insert data */
 if (file_type == JPG_FILE) {
 fw_cfg_add_file(s, "bootsplash.jpg",
-boot_splash_filedata, boot_splash_filedata_size);
+boot_splash_filedata, file_size);
 } else {
 fw_cfg_add_file(s, "bootsplash.bmp",
-boot_splash_filedata, boot_splash_filedata_size);
+boot_splash_filedata, file_size);
 }
 g_free(filename);
 }
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 89604a8328..6065d9e420 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -110,7 +110,6 @@ extern int old_param;
 extern int boot_menu;
 extern bool boot_strict;
 extern uint8_t *boot_splash_filedata;
-extern size_t boot_splash_filedata_size;
 extern bool enable_mlock;
 extern bool enable_cpu_pm;
 extern QEMUClockType rtc_clock;
diff --git a/vl.c b/vl.c
index 4c5cc0d8ad..fad6fec38c 100644
--- a/vl.c
+++ b/vl.c
@@ -188,7 +188,6 @@ const char *prom_envs[MAX_PROM_ENVS];
 int boot_menu;
 bool boot_strict;
 uint8_t *boot_splash_filedata;
-size_t boot_splash_filedata_size;
 bool wakeup_suspend_enabled;
 
 int icount_align_option;
-- 
2.20.1




[Qemu-devel] [PATCH v2 02/18] hw/i386: Remove unused include

2019-03-07 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Drop files that do use fw_cfg (Michael):
- hw/i386/acpi-build.c
- hw/i386/pc.c
---
 hw/acpi/piix4.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 8fd25a5926..7b98121070 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -28,7 +28,6 @@
 #include "sysemu/sysemu.h"
 #include "qapi/error.h"
 #include "qemu/range.h"
-#include "hw/nvram/fw_cfg.h"
 #include "exec/address-spaces.h"
 #include "hw/acpi/piix4.h"
 #include "hw/acpi/pcihp.h"
-- 
2.20.1




[Qemu-devel] [PATCH v2 07/18] hw/nvram/fw_cfg: Add fw_cfg_common_unrealize()

2019-03-07 Thread Philippe Mathieu-Daudé
Back in abe147e0ce4 when fw_cfg_add_file() was introduced, there
was no QOM design, object where not created and released at runtime.
Later 38f3adc34d finished the QOM conversion of the fw_cfg device,
adding the fw_cfg_common_realize() method.
The time has come to add the equivalent destructor and release the
memory allocated for 'files'.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index b2dc0a80cb..0fb020edce 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -959,6 +959,13 @@ static void fw_cfg_common_realize(DeviceState *dev, Error 
**errp)
 qemu_add_machine_init_done_notifier(>machine_ready);
 }
 
+static void fw_cfg_common_unrealize(DeviceState *dev, Error **errp)
+{
+FWCfgState *s = FW_CFG(dev);
+
+g_free(s->files);
+}
+
 FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
 AddressSpace *dma_as)
 {
@@ -1127,6 +1134,7 @@ static void fw_cfg_io_class_init(ObjectClass *klass, void 
*data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 dc->realize = fw_cfg_io_realize;
+dc->unrealize = fw_cfg_common_unrealize;
 dc->props = fw_cfg_io_properties;
 }
 
@@ -1190,6 +1198,7 @@ static void fw_cfg_mem_class_init(ObjectClass *klass, 
void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 dc->realize = fw_cfg_mem_realize;
+dc->unrealize = fw_cfg_common_unrealize;
 dc->props = fw_cfg_mem_properties;
 }
 
-- 
2.20.1




[Qemu-devel] [PATCH v2 04/18] hw/nvram/fw_cfg: Add trace events

2019-03-07 Thread Philippe Mathieu-Daudé
Add fw_cfg_arch_key_name() to be able to resolve architecture
specific keys. All architectures do have specific keys, thus
implement this function. Architectures that don't use the fw_cfg
device don't have to implement this function, however to ease
the Makefile rules and satisfy the linking, we provide a stub.

Now than we can resolve keys into "well know numeric", add
trace events to display more information when keys are added
(and dump the key content when possible).

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Added fw_cfg_arch_key_name() -> reset R-b
---
 MAINTAINERS   |  1 +
 hw/i386/pc.c  | 21 +
 hw/nvram/fw_cfg.c | 63 ++-
 hw/nvram/trace-events |  7 -
 hw/ppc/Makefile.objs  |  2 +-
 hw/ppc/fw_cfg.c   | 31 +++
 hw/sparc/sun4m.c  | 19 
 hw/sparc64/sun4u.c| 19 
 include/hw/nvram/fw_cfg.h | 11 +++
 stubs/Makefile.objs   |  1 +
 stubs/fw_cfg.c| 19 
 11 files changed, 191 insertions(+), 3 deletions(-)
 create mode 100644 hw/ppc/fw_cfg.c
 create mode 100644 stubs/fw_cfg.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 074ad46d47..306fc2aefa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1659,6 +1659,7 @@ R: Gerd Hoffmann 
 S: Supported
 F: docs/specs/fw_cfg.txt
 F: hw/nvram/fw_cfg.c
+F: stubs/fw_cfg.c
 F: include/hw/nvram/fw_cfg.h
 F: include/standard-headers/linux/qemu_fw_cfg.h
 F: tests/libqos/fw_cfg.c
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 42128183e9..0848cdc18f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -349,6 +349,27 @@ GlobalProperty pc_compat_1_4[] = {
 };
 const size_t pc_compat_1_4_len = G_N_ELEMENTS(pc_compat_1_4);
 
+const char *fw_cfg_arch_key_name(uint16_t key)
+{
+static const struct {
+uint16_t key;
+const char *name;
+} fw_cfg_arch_wellknown_keys[] = {
+{FW_CFG_ACPI_TABLES, "acpi_tables"},
+{FW_CFG_SMBIOS_ENTRIES, "smbios_entries"},
+{FW_CFG_IRQ0_OVERRIDE, "irq0_override"},
+{FW_CFG_E820_TABLE, "e820_tables"},
+{FW_CFG_HPET, "hpet"},
+};
+
+for (size_t i = 0; i < ARRAY_SIZE(fw_cfg_arch_wellknown_keys); i++) {
+if (fw_cfg_arch_wellknown_keys[i].key == key) {
+return fw_cfg_arch_wellknown_keys[i].name;
+}
+}
+return NULL;
+}
+
 void gsi_handler(void *opaque, int n, int level)
 {
 GSIState *s = opaque;
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 7fdf04adc9..684c2cf00a 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -60,6 +60,62 @@ struct FWCfgEntry {
 FWCfgWriteCallback write_cb;
 };
 
+/**
+ * key_name:
+ *
+ * @key: The uint16 selector key.
+ *
+ * Returns: The stringified name if the selector refers to a well-known
+ *  numerically defined item, or NULL on key lookup failure.
+ */
+static const char *key_name(uint16_t key)
+{
+static const char *fw_cfg_wellknown_keys[FW_CFG_FILE_FIRST] = {
+[FW_CFG_SIGNATURE] = "signature",
+[FW_CFG_ID] = "id",
+[FW_CFG_UUID] = "uuid",
+[FW_CFG_RAM_SIZE] = "ram_size",
+[FW_CFG_NOGRAPHIC] = "nographic",
+[FW_CFG_NB_CPUS] = "nb_cpus",
+[FW_CFG_MACHINE_ID] = "machine_id",
+[FW_CFG_KERNEL_ADDR] = "kernel_addr",
+[FW_CFG_KERNEL_SIZE] = "kernel_size",
+[FW_CFG_KERNEL_CMDLINE] = "kernel_cmdline",
+[FW_CFG_INITRD_ADDR] = "initrd_addr",
+[FW_CFG_INITRD_SIZE] = "initdr_size",
+[FW_CFG_BOOT_DEVICE] = "boot_device",
+[FW_CFG_NUMA] = "numa",
+[FW_CFG_BOOT_MENU] = "boot_menu",
+[FW_CFG_MAX_CPUS] = "max_cpus",
+[FW_CFG_KERNEL_ENTRY] = "kernel_entry",
+[FW_CFG_KERNEL_DATA] = "kernel_data",
+[FW_CFG_INITRD_DATA] = "initrd_data",
+[FW_CFG_CMDLINE_ADDR] = "cmdline_addr",
+[FW_CFG_CMDLINE_SIZE] = "cmdline_size",
+[FW_CFG_CMDLINE_DATA] = "cmdline_data",
+[FW_CFG_SETUP_ADDR] = "setup_addr",
+[FW_CFG_SETUP_SIZE] = "setup_size",
+[FW_CFG_SETUP_DATA] = "setup_data",
+[FW_CFG_FILE_DIR] = "file_dir",
+};
+
+if (key & FW_CFG_ARCH_LOCAL) {
+return fw_cfg_arch_key_name(key);
+}
+if (key < FW_CFG_FILE_FIRST) {
+return fw_cfg_wellknown_keys[key];
+}
+
+return NULL;
+}
+
+static inline const char *trace_key_name(uint16_t key)
+{
+const char *name = key_name(key);
+
+return name ? name : "unknown";
+}
+
 #define JPG_FILE 0
 #define BMP_FILE 1
 
@@ -234,7 +290,7 @@ static int fw_cfg_select(FWCfgState *s, uint16_t key)
 }
 }
 
-trace_fw_cfg_select(s, key, ret);
+trace_fw_cfg_select(s, key, trace_key_name(key), ret);
 return ret;
 }
 
@@ -617,6 +673,7 @@ static void *fw_cfg_modify_bytes_read(FWCfgState *s, 
uint16_t key,
 
 void fw_cfg_add_bytes(FWCfgState *s, uint16_t key, void *data, size_t len)
 {
+trace_fw_cfg_add_bytes(key, trace_key_name(key), len);
 

[Qemu-devel] [PATCH v2 00/18] fw_cfg: reduce memleaks, add QMP/HMP info + edk2_add_host_crypto_policy

2019-03-07 Thread Philippe Mathieu-Daudé
Hi,

This series consists of:
- trivial cleanups, add trace events (was in v1)
- add QMP/HMP commands to display the list of fw_cfg entries (reworked from v1)
- add unrealize() method and deallocate various buffers (new in v2)
- add fw_cfg_add_file_from_host (was in v1)
- add edk2_add_host_crypto_policy (new in v2)

Since v1:
- Addressed Michael and Laszlo comments.

Please review,

Phil.

v1: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg01598.html

Philippe Mathieu-Daudé (18):
  hw/arm/virt: Remove null-check in virt_build_smbios()
  hw/i386: Remove unused include
  cutils: Add qemu_strdup_hexlify() and qemu_strdup_unhexlify()
  hw/nvram/fw_cfg: Add trace events
  hw/nvram/fw_cfg: Use the ldst API
  hw/nvram/fw_cfg: Remove the unnecessary boot_splash_filedata_size
  hw/nvram/fw_cfg: Add fw_cfg_common_unrealize()
  hw/nvram/fw_cfg: Move fw_cfg_file_slots_allocate() to common_realize()
  hw/nvram/fw_cfg: Free file_slots in common_unrealize()
  hw/nvram/fw_cfg: Add reboot_timeout to FWCfgState
  hw/nvram/fw_cfg: Add boot_splash.time_le16 to FWCfgState
  hw/nvram/fw_cfg: Keep reference of file_data in FWCfgState
  hw/nvram/fw_cfg: Add QMP 'info fw_cfg' command
  hw/nvram/fw_cfg: Add HMP 'info fw_cfg' command
  hw/nvram/fw_cfg: Add fw_cfg_add_file_from_host()
  hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()
  hw/i386: Use edk2_add_host_crypto_policy()
  hw/arm/virt: Use edk2_add_host_crypto_policy()

 MAINTAINERS |   9 +
 hmp-commands-info.hx|  17 ++
 hw/Makefile.objs|   1 +
 hw/acpi/piix4.c |   1 -
 hw/arm/virt.c   |  11 +-
 hw/firmware/Makefile.objs   |   1 +
 hw/firmware/uefi_edk2_crypto_policies.c | 166 ++
 hw/i386/pc.c|  28 +++
 hw/nvram/fw_cfg.c   | 284 ++--
 hw/nvram/trace-events   |   7 +-
 hw/ppc/Makefile.objs|   2 +-
 hw/ppc/fw_cfg.c |  31 +++
 hw/sparc/sun4m.c|  19 ++
 hw/sparc64/sun4u.c  |  19 ++
 include/hw/firmware/uefi_edk2.h |  28 +++
 include/hw/nvram/fw_cfg.h   |  42 
 include/qemu/cutils.h   |  33 +++
 include/sysemu/sysemu.h |   2 -
 qapi/misc.json  |  44 
 stubs/Makefile.objs |   1 +
 stubs/fw_cfg.c  |  19 ++
 util/cutils.c   |  55 +
 vl.c|  10 -
 23 files changed, 792 insertions(+), 38 deletions(-)
 create mode 100644 hw/firmware/Makefile.objs
 create mode 100644 hw/firmware/uefi_edk2_crypto_policies.c
 create mode 100644 hw/ppc/fw_cfg.c
 create mode 100644 include/hw/firmware/uefi_edk2.h
 create mode 100644 stubs/fw_cfg.c

-- 
2.20.1




[Qemu-devel] [PATCH v2 01/18] hw/arm/virt: Remove null-check in virt_build_smbios()

2019-03-07 Thread Philippe Mathieu-Daudé
Since commit 578f3c7b0835 ("arm: add fw_cfg to "virt" board",
2014-12-22), the machvirt_init() unconditionally creates the
fw_cfg object.  Later, commit c30e15658b1b ("smbios: implement
smbios support for mach-virt", 2015-09-07) added a superfluous
null-check on it.
Remove this superfluous check.

Fixes: c30e15658b1b
Reviewed-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Corrected commit reference (Laszlo)
---
 hw/arm/virt.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index c7fb5348ae..bb7255a080 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1282,10 +1282,6 @@ static void virt_build_smbios(VirtMachineState *vms)
 size_t smbios_tables_len, smbios_anchor_len;
 const char *product = "QEMU Virtual Machine";
 
-if (!vms->fw_cfg) {
-return;
-}
-
 if (kvm_enabled()) {
 product = "KVM Virtual Machine";
 }
-- 
2.20.1




Re: [Qemu-devel] [PATCH RFC v3 00/11] Add RX archtecture support

2019-03-07 Thread Richard Henderson
On 3/1/19 10:21 PM, Yoshinori Sato wrote:
> My git repository is bellow.
> git://git.pf.osdn.net/gitroot/y/ys/ysato/qemu.git

Somehow patch 1 did not arrive, so I am reviewing based on
rebasing this branch against master, and then looking at the diff.

> +struct CCop;

Unused?

> +static inline void cpu_get_tb_cpu_state(CPURXState *env, target_ulong *pc,
> +target_ulong *cs_base, uint32_t 
> *flags)
> +{
> +*pc = env->pc;
> +*cs_base = 0;
> +*flags = 0;
> +}

*flags should contain PSW[PM], I think, so that knowledge of the
privilege level is given to the translator.

Looking forward I see that you're currently testing cpu_psw_pm dynamically for
instructions that require privs, so what you have is not wrong, but this is
exactly the sort of thing that TB flags are for.

> +#define RX_PSW_OP_NEG 4

Unused?

> +#define RX_BYTE 0
> +#define RX_WORD 1
> +#define RX_LONG 2

Redundant with TCGMemOps: MO_8, MO_16, MO_32?

> +++ b/target/rx/insns.decode

Should have a copyright + license notice.

> +BCnd_b 0010 cd:4 dsp:8 
...
> +#BRA_b 0010 1110 dsp:8 # overlaps BCnd_b

FYI, using pattern groups this can be written

{
  BRA_b0010 1110 dsp:8
  Bcnd_b   0010 cd:4 dsp:8
}

I expect to have pattern groups merged this week.

> +static void rx_tr_init_disas_context(DisasContextBase *dcbase, CPUState *cs)
> +{
> +DisasContext *ctx = container_of(dcbase, DisasContext, base);
> +
> +ctx->src = tcg_temp_new();
> +}

This allocation will not survive across a branch or label.
So, after any SHIFTR_REG, for instance.

I think you need to allocate this on demand each insn, and
free it as necessary after each insn.

(Although avoiding branches in tcg is always helpful.)

> +/* generic load / store wrapper */
> +static inline void rx_gen_ldst(unsigned int size, unsigned int dir,
> +TCGv reg, TCGv mem)
> +{
> +if (dir) {
> +tcg_gen_qemu_ld_i32(reg, mem, 0, size | MO_SIGN | MO_TE);
> +} else {
> +tcg_gen_qemu_st_i32(reg, mem, 0, size | MO_TE);
> +}
> +}

It would probably be worthwhile to split this function, and drop the "dir"
parameter.  It is always a constant, so instead of

  rx_gen_ldst(mi, RX_MEMORY_LD, ctx->src, ctx->src);
  rx_gen_ldst(a->sz, RX_MEMORY_ST, cpu_regs[a->rs], ctx->src);

use the shorter

  rx_gen_ld(mi, ctx->src, ctx->src);
  rx_gen_st(a->sz, cpu_regs[a->rs], ctx->src);


> +/* mov.l #uimm4,rd */
> +/* mov.l #uimm8,rd */
> +static bool trans_MOV_ri(DisasContext *ctx, arg_MOV_ri *a)
> +{
> +tcg_gen_movi_i32(cpu_regs[a->rd], a->imm & 0xff);
> +return true;
> +}

a->imm will already have been masked by the decode.
You can drop the & 0xff here.

> +/* mov.l #imm,rd */
> +static bool trans_MOV_rli(DisasContext *ctx, arg_MOV_rli *a)
> +{
> +tcg_gen_movi_i32(cpu_regs[a->rd], a->imm);
> +return true;
> +}

As written, this function is redundant.  We should be using the same MOV_ri,
with the immediate loaded from %b2_li_2.

Likewise for trans_MOV_mi vs trans_MOV_mli.  That said...

> +static bool trans_MOV_mli(DisasContext *ctx, arg_MOV_mli *a)
> +{
> +TCGv imm = tcg_const_i32(a->imm);
> +if (a->ld == 2) {
> +a->dsp = bswap_16(a->dsp);
> +}

This suggests that the decode is incorrect.  Or perhaps the construction of the
32-bit insn passed into decode.  In decode_load_bytes, we construct a
big-endian value, so it would seem this dsp field should be loaded as a
little-endian value.

This could be fixed by not attempting to load the LI constant in decodetree
(for this insn), which would in turn not require that you decode the LD operand
by hand in decodetree.  E.g.

static bool trans_MOV_mli(DisasContext *ctx, arg_MOV_mli *a)
{
TCGv imm;

/* dsp operand comes before immediate operand */
rx_index_addr(a->ld, a->sz, a->rd, s);
imm = tcg_const_i32(li(s, a->li));
rx_gen_st(a->sz, imm, ctx->src);
tcg_temp_free_i32(imm);
return true;
}

This will be easiest if you ever support the big-endian version of RX.

> +/* push rs */
> +static bool trans_PUSH_r(DisasContext *ctx, arg_PUSH_r *a)
> +{
> +if (a->rs != 0) {
> +tcg_gen_subi_i32(cpu_regs[0], cpu_regs[0], 4);
> +rx_gen_ldst(a->sz, RX_MEMORY_ST, cpu_regs[a->rs], cpu_regs[0]);
> +} else {
> +tcg_gen_mov_i32(ctx->src, cpu_regs[a->rs]);
> +tcg_gen_subi_i32(cpu_regs[0], cpu_regs[0], 4);
> +rx_gen_ldst(a->sz, RX_MEMORY_ST, ctx->src, cpu_regs[0]);
> +}
> +return true;

As far as I can see the THEN and ELSE cases have identical operation.

> +static bool trans_XCHG_rl(DisasContext *ctx, arg_XCHG_rl *a)
> +{
> +int sz;
> +TCGv tmp;
> +tmp = tcg_temp_new();
> +if (a->ld == 3) {
> +   /* xchg rs,rd */
> +tcg_gen_mov_i32(tmp, cpu_regs[a->rs]);
> +tcg_gen_mov_i32(cpu_regs[a->rs], cpu_regs[a->rd]);
> +tcg_gen_mov_i32(cpu_regs[a->rd], tmp);
> +} else {
> +

Re: [Qemu-devel] [PATCH v2 11/15] ppc/pnv: POWER9 XSCOM quad support

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:44PM +0100, Cédric Le Goater wrote:
> The POWER9 processor does not support per-core frequency control. The
> cores are arranged in groups of four, along with their respective L2
> and L3 caches, into a structure known as a Quad. The frequency must be
> managed at the Quad level.
> 
> Provide a basic Quad model to fake the settings done by the firmware
> on the Non-Cacheable Unit (NCU). Each core pair (EX) needs a special
> BAR setting for the TIMA area of XIVE because it resides on the same
> address on all chips.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  include/hw/ppc/pnv.h   |  4 ++
>  include/hw/ppc/pnv_core.h  | 10 +
>  include/hw/ppc/pnv_xscom.h | 12 --
>  hw/ppc/pnv.c   | 38 -
>  hw/ppc/pnv_core.c  | 87 ++
>  5 files changed, 146 insertions(+), 5 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 39888f9d52c1..e5b00d373ed2 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -26,6 +26,7 @@
>  #include "hw/ppc/pnv_psi.h"
>  #include "hw/ppc/pnv_occ.h"
>  #include "hw/ppc/pnv_xive.h"
> +#include "hw/ppc/pnv_core.h"
>  
>  #define TYPE_PNV_CHIP "pnv-chip"
>  #define PNV_CHIP(obj) OBJECT_CHECK(PnvChip, (obj), TYPE_PNV_CHIP)
> @@ -89,6 +90,9 @@ typedef struct Pnv9Chip {
>  Pnv9Psi  psi;
>  PnvLpcController lpc;
>  PnvOCC   occ;
> +
> +uint32_t nr_quads;
> +PnvQuad  *quads;
>  } Pnv9Chip;
>  
>  typedef struct PnvChipClass {
> diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
> index cbe9ad36f32c..50cdb2b35838 100644
> --- a/include/hw/ppc/pnv_core.h
> +++ b/include/hw/ppc/pnv_core.h
> @@ -58,4 +58,14 @@ static inline PnvCPUState *pnv_cpu_state(PowerPCCPU *cpu)
>  return (PnvCPUState *)cpu->machine_data;
>  }
>  
> +#define TYPE_PNV_QUAD "powernv-cpu-quad"
> +#define PNV_QUAD(obj) \
> +OBJECT_CHECK(PnvQuad, (obj), TYPE_PNV_QUAD)
> +
> +typedef struct PnvQuad {
> +DeviceState parent_obj;
> +
> +uint32_t id;
> +MemoryRegion xscom_regs;
> +} PnvQuad;
>  #endif /* _PPC_PNV_CORE_H */
> diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
> index 3292459fbb78..68dfae0dfe41 100644
> --- a/include/hw/ppc/pnv_xscom.h
> +++ b/include/hw/ppc/pnv_xscom.h
> @@ -60,10 +60,6 @@ typedef struct PnvXScomInterfaceClass {
>  (PNV_XSCOM_EX_CORE_BASE | ((uint64_t)(core) << 24))
>  #define PNV_XSCOM_EX_SIZE 0x10
>  
> -#define PNV_XSCOM_P9_EC_BASE(core) \
> -((uint64_t)(((core) & 0x1F) + 0x20) << 24)
> -#define PNV_XSCOM_P9_EC_SIZE  0x10
> -
>  #define PNV_XSCOM_LPC_BASE0xb0020
>  #define PNV_XSCOM_LPC_SIZE0x4
>  
> @@ -73,6 +69,14 @@ typedef struct PnvXScomInterfaceClass {
>  #define PNV_XSCOM_OCC_BASE0x0066000
>  #define PNV_XSCOM_OCC_SIZE0x6000
>  
> +#define PNV9_XSCOM_EC_BASE(core) \
> +((uint64_t)(((core) & 0x1F) + 0x20) << 24)
> +#define PNV9_XSCOM_EC_SIZE0x10
> +
> +#define PNV9_XSCOM_EQ_BASE(core) \
> +((uint64_t)(((core) & 0x1C) + 0x40) << 22)
> +#define PNV9_XSCOM_EQ_SIZE0x10
> +
>  #define PNV9_XSCOM_OCC_BASE   PNV_XSCOM_OCC_BASE
>  #define PNV9_XSCOM_OCC_SIZE   0x8000
>  
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 1559a733235b..e68d419203e8 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -963,6 +963,36 @@ static void pnv_chip_power9_instance_init(Object *obj)
> OBJECT(>psi), _abort);
>  }
>  
> +static void pnv_chip_quad_realize(Pnv9Chip *chip9, Error **errp)
> +{
> +PnvChip *chip = PNV_CHIP(chip9);
> +const char *typename = pnv_chip_core_typename(chip);
> +size_t typesize = object_type_get_instance_size(typename);
> +int i;
> +
> +chip9->nr_quads = DIV_ROUND_UP(chip->nr_cores, 4);
> +chip9->quads = g_new0(PnvQuad, chip9->nr_quads);
> +
> +for (i = 0; i < chip9->nr_quads; i++) {
> +char eq_name[32];
> +PnvQuad *eq = >quads[i];
> +PnvCore *pnv_core = PNV_CORE(chip->cores + (i * 4) * typesize);
> +int core_id = CPU_CORE(pnv_core)->core_id;
> +
> +object_initialize(eq, sizeof(*eq), TYPE_PNV_QUAD);
> +snprintf(eq_name, sizeof(eq_name), "eq[%d]", core_id);
> +
> +object_property_add_child(OBJECT(chip), eq_name, OBJECT(eq),
> +  _fatal);
> +object_property_set_int(OBJECT(eq), core_id, "id", _fatal);
> +object_property_set_bool(OBJECT(eq), true, "realized", _fatal);
> +object_unref(OBJECT(eq));
> +
> +pnv_xscom_add_subregion(chip, PNV9_XSCOM_EQ_BASE(eq->id),
> +>xscom_regs);
> +}
> +}
> +
>  static void pnv_chip_power9_realize(DeviceState *dev, Error **errp)
>  {
>  PnvChipClass *pcc = PNV_CHIP_GET_CLASS(dev);
> @@ -977,6 +1007,12 @@ static void pnv_chip_power9_realize(DeviceState *dev, 
> Error **errp)
>  

Re: [Qemu-devel] [PATCH v2 10/15] ppc/pnv: extend XSCOM core support for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:43PM +0100, Cédric Le Goater wrote:
> Provide a new class attribute to define XSCOM operations per CPU
> family and add a couple of XSCOM addresses controlling the power
> management states of the core on POWER9.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
> 
>  Changes in v2 :
> 
>  - new class attribute to define XSCOM operations per CPU family
> 
>  include/hw/ppc/pnv_core.h |   2 +
>  hw/ppc/pnv_core.c | 100 +-
>  2 files changed, 89 insertions(+), 13 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
> index 6874bb847a01..cbe9ad36f32c 100644
> --- a/include/hw/ppc/pnv_core.h
> +++ b/include/hw/ppc/pnv_core.h
> @@ -42,6 +42,8 @@ typedef struct PnvCore {
>  
>  typedef struct PnvCoreClass {
>  DeviceClass parent_class;
> +
> +const MemoryRegionOps *xscom_ops;
>  } PnvCoreClass;
>  
>  #define PNV_CORE_TYPE_SUFFIX "-" TYPE_PNV_CORE
> diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
> index 38179cdc53dc..171474e0805c 100644
> --- a/hw/ppc/pnv_core.c
> +++ b/hw/ppc/pnv_core.c
> @@ -60,8 +60,8 @@ static void pnv_cpu_reset(void *opaque)
>  #define PNV_XSCOM_EX_DTS_RESULT0 0x5
>  #define PNV_XSCOM_EX_DTS_RESULT1 0x50001
>  
> -static uint64_t pnv_core_xscom_read(void *opaque, hwaddr addr,
> -unsigned int width)
> +static uint64_t pnv_core_power8_xscom_read(void *opaque, hwaddr addr,
> +   unsigned int width)
>  {
>  uint32_t offset = addr >> 3;
>  uint64_t val = 0;
> @@ -82,16 +82,74 @@ static uint64_t pnv_core_xscom_read(void *opaque, hwaddr 
> addr,
>  return val;
>  }
>  
> -static void pnv_core_xscom_write(void *opaque, hwaddr addr, uint64_t val,
> - unsigned int width)
> +static void pnv_core_power8_xscom_write(void *opaque, hwaddr addr, uint64_t 
> val,
> +unsigned int width)
>  {
>  qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx "\n",
>addr);
>  }
>  
> -static const MemoryRegionOps pnv_core_xscom_ops = {
> -.read = pnv_core_xscom_read,
> -.write = pnv_core_xscom_write,
> +static const MemoryRegionOps pnv_core_power8_xscom_ops = {
> +.read = pnv_core_power8_xscom_read,
> +.write = pnv_core_power8_xscom_write,
> +.valid.min_access_size = 8,
> +.valid.max_access_size = 8,
> +.impl.min_access_size = 8,
> +.impl.max_access_size = 8,
> +.endianness = DEVICE_BIG_ENDIAN,
> +};
> +
> +
> +/*
> + * POWER9 core controls
> + */
> +#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP 0xf010d
> +#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR 0xf010a
> +
> +static uint64_t pnv_core_power9_xscom_read(void *opaque, hwaddr addr,
> +   unsigned int width)
> +{
> +uint32_t offset = addr >> 3;
> +uint64_t val = 0;
> +
> +/* The result should be 38 C */
> +switch (offset) {
> +case PNV_XSCOM_EX_DTS_RESULT0:
> +val = 0x26f024f023full;
> +break;
> +case PNV_XSCOM_EX_DTS_RESULT1:
> +val = 0x24full;
> +break;
> +case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP:
> +case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
> +val = 0x0;
> +break;
> +default:
> +qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
> +  addr);
> +}
> +
> +return val;
> +}
> +
> +static void pnv_core_power9_xscom_write(void *opaque, hwaddr addr, uint64_t 
> val,
> +unsigned int width)
> +{
> +uint32_t offset = addr >> 3;
> +
> +switch (offset) {
> +case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP:
> +case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
> +break;
> +default:
> +qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx 
> "\n",
> +  addr);
> +}
> +}
> +
> +static const MemoryRegionOps pnv_core_power9_xscom_ops = {
> +.read = pnv_core_power9_xscom_read,
> +.write = pnv_core_power9_xscom_write,
>  .valid.min_access_size = 8,
>  .valid.max_access_size = 8,
>  .impl.min_access_size = 8,
> @@ -138,6 +196,7 @@ static void pnv_realize_vcpu(PowerPCCPU *cpu, PnvChip 
> *chip, Error **errp)
>  static void pnv_core_realize(DeviceState *dev, Error **errp)
>  {
>  PnvCore *pc = PNV_CORE(OBJECT(dev));
> +PnvCoreClass *pcc = PNV_CORE_GET_CLASS(pc);
>  CPUCore *cc = CPU_CORE(OBJECT(dev));
>  const char *typename = pnv_core_cpu_typename(pc);
>  Error *local_err = NULL;
> @@ -180,7 +239,7 @@ static void pnv_core_realize(DeviceState *dev, Error 
> **errp)
>  }
>  
>  snprintf(name, sizeof(name), "xscom-core.%d", cc->core_id);
> -pnv_xscom_region_init(>xscom_regs, OBJECT(dev), _core_xscom_ops,
> +pnv_xscom_region_init(>xscom_regs, OBJECT(dev), pcc->xscom_ops,
>

Re: [Qemu-devel] [PATCH v2 06/15] ppc/pnv: add a LPC Controller model for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:39PM +0100, Cédric Le Goater wrote:
> The LPC Controller on POWER9 is very similar to the one found on
> POWER8 but accesses are now done via on MMIOs, without the XSCOM and
> ECCB logic. The device tree is populated differently so we add a
> specific POWER9 routine for the purpose.
> 
> SerIRQ routing is yet to be done.
> 
> Signed-off-by: Cédric Le Goater 

[snip]
> +static uint64_t pnv_lpc_mmio_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +PnvLpcController *lpc = PNV_LPC(opaque);
> +uint64_t val = 0;
> +uint32_t opb_addr = addr & ECCB_CTL_ADDR_MASK;
> +MemTxResult result;
> +
> +switch (size) {
> +case 4:
> +val = address_space_ldl(>opb_as, opb_addr, 
> MEMTXATTRS_UNSPECIFIED,
> +);

This extra level of indirection via the opb_as still seems very
dubious to me.  But I guess it's something we can fix later, so,
applied.


> +break;
> +case 1:
> +val = address_space_ldub(>opb_as, opb_addr, 
> MEMTXATTRS_UNSPECIFIED,
> + );
> +break;
> +default:
> +qemu_log_mask(LOG_GUEST_ERROR, "OPB read failed at @0x%"
> +  HWADDR_PRIx " invalid size %d\n", addr, size);
> +return 0;
> +}
> +
> +if (result != MEMTX_OK) {
> +qemu_log_mask(LOG_GUEST_ERROR, "OPB read failed at @0x%"
> +  HWADDR_PRIx "\n", addr);
> +}
> +
> +return val;
> +}
> +
> +static void pnv_lpc_mmio_write(void *opaque, hwaddr addr,
> +uint64_t val, unsigned size)
> +{
> +PnvLpcController *lpc = PNV_LPC(opaque);
> +uint32_t opb_addr = addr & ECCB_CTL_ADDR_MASK;
> +MemTxResult result;
> +
> +switch (size) {
> +case 4:
> +address_space_stl(>opb_as, opb_addr, val, 
> MEMTXATTRS_UNSPECIFIED,
> +  );
> + break;
> +case 1:
> +address_space_stb(>opb_as, opb_addr, val, 
> MEMTXATTRS_UNSPECIFIED,
> +  );
> +break;
> +default:
> +qemu_log_mask(LOG_GUEST_ERROR, "OPB write failed at @0x%"
> +  HWADDR_PRIx " invalid size %d\n", addr, size);
> +return;
> +}
> +
> +if (result != MEMTX_OK) {
> +qemu_log_mask(LOG_GUEST_ERROR, "OPB write failed at @0x%"
> +  HWADDR_PRIx "\n", addr);
> +}
> +}
> +
> +static const MemoryRegionOps pnv_lpc_mmio_ops = {
> +.read = pnv_lpc_mmio_read,
> +.write = pnv_lpc_mmio_write,
> +.impl = {
> +.min_access_size = 1,
> +.max_access_size = 4,
> +},
> +.endianness = DEVICE_BIG_ENDIAN,
> +};
> +
>  static void pnv_lpc_eval_irqs(PnvLpcController *lpc)
>  {
>  bool lpc_to_opb_irq = false;
> @@ -465,6 +627,43 @@ static const TypeInfo pnv_lpc_power8_info = {
>  }
>  };
>  
> +static void pnv_lpc_power9_realize(DeviceState *dev, Error **errp)
> +{
> +PnvLpcController *lpc = PNV_LPC(dev);
> +PnvLpcClass *plc = PNV_LPC_GET_CLASS(dev);
> +Error *local_err = NULL;
> +
> +plc->parent_realize(dev, _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> +/* P9 uses a MMIO region */
> +memory_region_init_io(>xscom_regs, OBJECT(lpc), _lpc_mmio_ops,
> +  lpc, "lpcm", PNV9_LPCM_SIZE);
> +}
> +
> +static void pnv_lpc_power9_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +PnvLpcClass *plc = PNV_LPC_CLASS(klass);
> +
> +dc->desc = "PowerNV LPC Controller POWER9";
> +
> +plc->psi_irq = PSIHB9_IRQ_LPCHC;
> +
> +device_class_set_parent_realize(dc, pnv_lpc_power9_realize,
> +>parent_realize);
> +}
> +
> +static const TypeInfo pnv_lpc_power9_info = {
> +.name  = TYPE_PNV9_LPC,
> +.parent= TYPE_PNV_LPC,
> +.instance_size = sizeof(PnvLpcController),
> +.class_init= pnv_lpc_power9_class_init,
> +};
> +
>  static void pnv_lpc_realize(DeviceState *dev, Error **errp)
>  {
>  PnvLpcController *lpc = PNV_LPC(dev);
> @@ -540,6 +739,7 @@ static void pnv_lpc_register_types(void)
>  {
>  type_register_static(_lpc_info);
>  type_register_static(_lpc_power8_info);
> +type_register_static(_lpc_power9_info);
>  }
>  
>  type_init(pnv_lpc_register_types)

-- 
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 v2 12/15] ppc/pnv: activate XSCOM tests for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:45PM +0100, Cédric Le Goater wrote:
> We now have enough support to let the XSCOM test run on POWER9.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  tests/pnv-xscom-test.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
> index 974f8da5b240..63d464048d53 100644
> --- a/tests/pnv-xscom-test.c
> +++ b/tests/pnv-xscom-test.c
> @@ -39,7 +39,6 @@ static const PnvChip pnv_chips[] = {
>  .cfam_id= 0x120d30498000ull,
>  .first_core = 0x1,
>  },
> -#if 0 /* POWER9 support is not ready yet */
>  {
>  .chip_type  = PNV_CHIP_POWER9,
>  .cpu_model  = "POWER9",
> @@ -47,7 +46,6 @@ static const PnvChip pnv_chips[] = {
>  .cfam_id= 0x220d10498000ull,
>  .first_core = 0x0,
>  },
> -#endif
>  };
>  
>  static uint64_t pnv_xscom_addr(const PnvChip *chip, uint32_t pcba)

-- 
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 v2 13/15] ppc/pnv: add more dummy XSCOM addresses

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:46PM +0100, Cédric Le Goater wrote:
> To improve OPAL/skiboot support. We don't need to strictly model these
> XSCOM accesses.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  hw/ppc/pnv_xscom.c | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index 46fae41f32b0..c285ef514e88 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -64,11 +64,21 @@ static uint64_t xscom_read_default(PnvChip *chip, 
> uint32_t pcba)
>  switch (pcba) {
>  case 0xf000f:
>  return PNV_CHIP_GET_CLASS(chip)->chip_cfam_id;
> +case 0x18002:   /* ECID2 */
> +return 0;
> +
>  case 0x1010c00: /* PIBAM FIR */
>  case 0x1010c03: /* PIBAM FIR MASK */
> -case 0x2020007: /* ADU stuff */
> -case 0x2020009: /* ADU stuff */
> -case 0x202000f: /* ADU stuff */
> +
> +/* P9 xscom reset */
> +case 0x0090018: /* Receive status reg */
> +case 0x0090012: /* log register */
> +case 0x0090013: /* error register */
> +
> +/* P8 xscom reset */
> +case 0x2020007: /* ADU stuff, log register */
> +case 0x2020009: /* ADU stuff, error register */
> +case 0x202000f: /* ADU stuff, receive status register*/
>  return 0;
>  case 0x2013f00: /* PBA stuff */
>  case 0x2013f01: /* PBA stuff */
> @@ -100,9 +110,20 @@ static bool xscom_write_default(PnvChip *chip, uint32_t 
> pcba, uint64_t val)
>  case 0x1010c03: /* PIBAM FIR MASK */
>  case 0x1010c04: /* PIBAM FIR MASK */
>  case 0x1010c05: /* PIBAM FIR MASK */
> -case 0x2020007: /* ADU stuff */
> -case 0x2020009: /* ADU stuff */
> -case 0x202000f: /* ADU stuff */
> +/* P9 xscom reset */
> +case 0x0090018: /* Receive status reg */
> +case 0x0090012: /* log register */
> +case 0x0090013: /* error register */
> +
> +/* P8 xscom reset */
> +case 0x2020007: /* ADU stuff, log register */
> +case 0x2020009: /* ADU stuff, error register */
> +case 0x202000f: /* ADU stuff, receive status register*/
> +
> +case 0x2013028: /* CAPP stuff */
> +case 0x201302a: /* CAPP stuff */
> +case 0x2013801: /* CAPP stuff */
> +case 0x2013802: /* CAPP stuff */
>  return true;
>  default:
>  return false;

-- 
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 v2 14/15] ppc/pnv: add a "ibm, opal/power-mgt" device tree node on POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:47PM +0100, Cédric Le Goater wrote:
> Activate only stop0 and stop1 levels. We should not need more levels
> when under QEMU.
> 
> Signed-off-by: Cédric Le Goater 

Applied, although..

> ---
>  hw/ppc/pnv.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index e68d419203e8..8be4d4cbf785 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -438,6 +438,16 @@ static void pnv_dt_isa(PnvMachineState *pnv, void *fdt)
> );
>  }
>  
> +static void pnv_dt_power_mgt(void *fdt)
> +{
> +int off;
> +
> +off = fdt_add_subnode(fdt, 0, "ibm,opal");
> +off = fdt_add_subnode(fdt, off, "power-mgt");
> +
> +_FDT(fdt_setprop_cell(fdt, off, "ibm,enabled-stop-levels", 0xc000));
> +}
> +
>  static void *pnv_dt_create(MachineState *machine)
>  {
>  const char plat_compat[] = "qemu,powernv\0ibm,powernv";
> @@ -493,6 +503,11 @@ static void *pnv_dt_create(MachineState *machine)
>  pnv_dt_bmc_sensors(pnv->bmc, fdt);
>  }
>  
> +/* Create an extra node for power management on Power9 */
> +if (pnv_is_power9(pnv)) {

.. as always, I think specific code calling generic helpers is a
better pattern than generic code conditionally calling specific details.

> +pnv_dt_power_mgt(fdt);
> +}
> +
>  return fdt;
>  }
>  

-- 
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 v2 15/15] target/ppc: add HV support for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:48PM +0100, Cédric Le Goater wrote:
> We now have enough support to boot a PowerNV machine with a POWER9
> processor. Allow HV mode on POWER9.
> 
> Signed-off-by: Cédric Le Goater 

Applied.

> ---
>  target/ppc/translate_init.inc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c
> index af70a3b78c9a..0bd555eb1913 100644
> --- a/target/ppc/translate_init.inc.c
> +++ b/target/ppc/translate_init.inc.c
> @@ -8895,7 +8895,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
> PPC_CACHE | PPC_CACHE_ICBI | PPC_CACHE_DCBZ |
> PPC_MEM_SYNC | PPC_MEM_EIEIO |
> PPC_MEM_TLBSYNC |
> -   PPC_64B | PPC_64BX | PPC_ALTIVEC |
> +   PPC_64B | PPC_64H | PPC_64BX | PPC_ALTIVEC |
> PPC_SEGMENT_64B | PPC_SLBI |
> PPC_POPCNTB | PPC_POPCNTWD |
> PPC_CILDST;
> @@ -8907,6 +8907,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
>  PPC2_ISA205 | PPC2_ISA207S | PPC2_FP_CVT_S64 |
>  PPC2_TM | PPC2_ISA300 | PPC2_PRCNTL;
>  pcc->msr_mask = (1ull << MSR_SF) |
> +(1ull << MSR_SHV) |
>  (1ull << MSR_TM) |
>  (1ull << MSR_VR) |
>  (1ull << MSR_VSX) |

-- 
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 v2 09/15] ppc/pnv: add a OCC model for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:42PM +0100, Cédric Le Goater wrote:
> The OCC on POWER9 is very similar to the one found on POWER8. Provide
> the same routines with P9 values for the registers and IRQ number.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
> 
>  Changes in v2 :
> 
>  - made use of the new class attributes for POWER9
> 
>  include/hw/ppc/pnv.h   |  1 +
>  include/hw/ppc/pnv_occ.h   |  2 ++
>  include/hw/ppc/pnv_xscom.h |  3 ++
>  hw/ppc/pnv.c   | 13 +++
>  hw/ppc/pnv_occ.c   | 72 ++
>  5 files changed, 91 insertions(+)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 1cd1ad622d0b..39888f9d52c1 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -88,6 +88,7 @@ typedef struct Pnv9Chip {
>  PnvXive  xive;
>  Pnv9Psi  psi;
>  PnvLpcController lpc;
> +PnvOCC   occ;
>  } Pnv9Chip;
>  
>  typedef struct PnvChipClass {
> diff --git a/include/hw/ppc/pnv_occ.h b/include/hw/ppc/pnv_occ.h
> index dab5a05f8e99..d22b65a71abe 100644
> --- a/include/hw/ppc/pnv_occ.h
> +++ b/include/hw/ppc/pnv_occ.h
> @@ -25,6 +25,8 @@
>  #define PNV_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV_OCC)
>  #define TYPE_PNV8_OCC TYPE_PNV_OCC "-POWER8"
>  #define PNV8_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV8_OCC)
> +#define TYPE_PNV9_OCC TYPE_PNV_OCC "-POWER9"
> +#define PNV9_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV9_OCC)
>  
>  typedef struct PnvOCC {
>  DeviceState xd;
> diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
> index 403a365ed274..3292459fbb78 100644
> --- a/include/hw/ppc/pnv_xscom.h
> +++ b/include/hw/ppc/pnv_xscom.h
> @@ -73,6 +73,9 @@ typedef struct PnvXScomInterfaceClass {
>  #define PNV_XSCOM_OCC_BASE0x0066000
>  #define PNV_XSCOM_OCC_SIZE0x6000
>  
> +#define PNV9_XSCOM_OCC_BASE   PNV_XSCOM_OCC_BASE
> +#define PNV9_XSCOM_OCC_SIZE   0x8000
> +
>  #define PNV9_XSCOM_PSIHB_BASE 0x5012900
>  #define PNV9_XSCOM_PSIHB_SIZE 0x100
>  
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 6ae9ce679505..1559a733235b 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -956,6 +956,11 @@ static void pnv_chip_power9_instance_init(Object *obj)
>  TYPE_PNV9_LPC, _abort, NULL);
>  object_property_add_const_link(OBJECT(>lpc), "psi",
> OBJECT(>psi), _abort);
> +
> +object_initialize_child(obj, "occ",  >occ, sizeof(chip9->occ),
> +TYPE_PNV9_OCC, _abort, NULL);
> +object_property_add_const_link(OBJECT(>occ), "psi",
> +   OBJECT(>psi), _abort);
>  }
>  
>  static void pnv_chip_power9_realize(DeviceState *dev, Error **errp)
> @@ -1012,6 +1017,14 @@ static void pnv_chip_power9_realize(DeviceState *dev, 
> Error **errp)
>  
>  chip->dt_isa_nodename = g_strdup_printf("/lpcm-opb@%" PRIx64 "/lpc@0",
>  (uint64_t) PNV9_LPCM_BASE(chip));
> +
> +/* Create the simplified OCC model */
> +object_property_set_bool(OBJECT(>occ), true, "realized", 
> _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +pnv_xscom_add_subregion(chip, PNV9_XSCOM_OCC_BASE, 
> >occ.xscom_regs);
>  }
>  
>  static void pnv_chip_power9_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/ppc/pnv_occ.c b/hw/ppc/pnv_occ.c
> index ea725647c988..fdd9296e1bc7 100644
> --- a/hw/ppc/pnv_occ.c
> +++ b/hw/ppc/pnv_occ.c
> @@ -109,6 +109,77 @@ static const TypeInfo pnv_occ_power8_type_info = {
>  .class_init= pnv_occ_power8_class_init,
>  };
>  
> +#define P9_OCB_OCI_OCCMISC  0x6080
> +#define P9_OCB_OCI_OCCMISC_CLEAR0x6081
> +#define P9_OCB_OCI_OCCMISC_OR   0x6082
> +
> +
> +static uint64_t pnv_occ_power9_xscom_read(void *opaque, hwaddr addr,
> +  unsigned size)
> +{
> +PnvOCC *occ = PNV_OCC(opaque);
> +uint32_t offset = addr >> 3;
> +uint64_t val = 0;
> +
> +switch (offset) {
> +case P9_OCB_OCI_OCCMISC:
> +val = occ->occmisc;
> +break;
> +default:
> +qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
> +  HWADDR_PRIx "\n", addr >> 3);
> +}
> +return val;
> +}
> +
> +static void pnv_occ_power9_xscom_write(void *opaque, hwaddr addr,
> +   uint64_t val, unsigned size)
> +{
> +PnvOCC *occ = PNV_OCC(opaque);
> +uint32_t offset = addr >> 3;
> +
> +switch (offset) {
> +case P9_OCB_OCI_OCCMISC_CLEAR:
> +pnv_occ_set_misc(occ, 0);
> +break;
> +case P9_OCB_OCI_OCCMISC_OR:
> +pnv_occ_set_misc(occ, occ->occmisc | val);
> +break;
> +case P9_OCB_OCI_OCCMISC:
> +pnv_occ_set_misc(occ, val);
> +   break;
> +default:
> +qemu_log_mask(LOG_UNIMP, "OCC Unimplemented 

Re: [Qemu-devel] [PATCH v2 08/15] ppc/pnv: add a OCC model class

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:41PM +0100, Cédric Le Goater wrote:
> To ease the introduction of the OCC model for POWER9, provide a new
> class attributes to define XSCOM operations per CPU family and a PSI
> IRQ number.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: David Gibson 

Applied, thanks.

> ---
> 
>  Changes in v2:
> 
>  - new attributes to define XSCOM operations per CPU family and a PSI
>IRQ number.
> 
>  include/hw/ppc/pnv_occ.h | 15 +++
>  hw/ppc/pnv.c |  2 +-
>  hw/ppc/pnv_occ.c | 55 +++-
>  3 files changed, 54 insertions(+), 18 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv_occ.h b/include/hw/ppc/pnv_occ.h
> index 82f299dc76ff..dab5a05f8e99 100644
> --- a/include/hw/ppc/pnv_occ.h
> +++ b/include/hw/ppc/pnv_occ.h
> @@ -23,6 +23,8 @@
>  
>  #define TYPE_PNV_OCC "pnv-occ"
>  #define PNV_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV_OCC)
> +#define TYPE_PNV8_OCC TYPE_PNV_OCC "-POWER8"
> +#define PNV8_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV8_OCC)
>  
>  typedef struct PnvOCC {
>  DeviceState xd;
> @@ -35,4 +37,17 @@ typedef struct PnvOCC {
>  MemoryRegion xscom_regs;
>  } PnvOCC;
>  
> +#define PNV_OCC_CLASS(klass) \
> + OBJECT_CLASS_CHECK(PnvOCCClass, (klass), TYPE_PNV_OCC)
> +#define PNV_OCC_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(PnvOCCClass, (obj), TYPE_PNV_OCC)
> +
> +typedef struct PnvOCCClass {
> +DeviceClass parent_class;
> +
> +int xscom_size;
> +const MemoryRegionOps *xscom_ops;
> +int psi_irq;
> +} PnvOCCClass;
> +
>  #endif /* _PPC_PNV_OCC_H */
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 918fae057b5c..6ae9ce679505 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -790,7 +790,7 @@ static void pnv_chip_power8_instance_init(Object *obj)
> OBJECT(>psi), _abort);
>  
>  object_initialize_child(obj, "occ",  >occ, sizeof(chip8->occ),
> -TYPE_PNV_OCC, _abort, NULL);
> +TYPE_PNV8_OCC, _abort, NULL);
>  object_property_add_const_link(OBJECT(>occ), "psi",
> OBJECT(>psi), _abort);
>  }
> diff --git a/hw/ppc/pnv_occ.c b/hw/ppc/pnv_occ.c
> index 04880f26d612..ea725647c988 100644
> --- a/hw/ppc/pnv_occ.c
> +++ b/hw/ppc/pnv_occ.c
> @@ -34,15 +34,17 @@
>  static void pnv_occ_set_misc(PnvOCC *occ, uint64_t val)
>  {
>  bool irq_state;
> +PnvOCCClass *poc = PNV_OCC_GET_CLASS(occ);
>  
>  val &= 0xull;
>  
>  occ->occmisc = val;
>  irq_state = !!(val >> 63);
> -pnv_psi_irq_set(occ->psi, PSIHB_IRQ_OCC, irq_state);
> +pnv_psi_irq_set(occ->psi, poc->psi_irq, irq_state);
>  }
>  
> -static uint64_t pnv_occ_xscom_read(void *opaque, hwaddr addr, unsigned size)
> +static uint64_t pnv_occ_power8_xscom_read(void *opaque, hwaddr addr,
> +  unsigned size)
>  {
>  PnvOCC *occ = PNV_OCC(opaque);
>  uint32_t offset = addr >> 3;
> @@ -54,13 +56,13 @@ static uint64_t pnv_occ_xscom_read(void *opaque, hwaddr 
> addr, unsigned size)
>  break;
>  default:
>  qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
> -  HWADDR_PRIx "\n", addr);
> +  HWADDR_PRIx "\n", addr >> 3);
>  }
>  return val;
>  }
>  
> -static void pnv_occ_xscom_write(void *opaque, hwaddr addr,
> -uint64_t val, unsigned size)
> +static void pnv_occ_power8_xscom_write(void *opaque, hwaddr addr,
> +   uint64_t val, unsigned size)
>  {
>  PnvOCC *occ = PNV_OCC(opaque);
>  uint32_t offset = addr >> 3;
> @@ -77,13 +79,13 @@ static void pnv_occ_xscom_write(void *opaque, hwaddr addr,
>  break;
>  default:
>  qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
> -  HWADDR_PRIx "\n", addr);
> +  HWADDR_PRIx "\n", addr >> 3);
>  }
>  }
>  
> -static const MemoryRegionOps pnv_occ_xscom_ops = {
> -.read = pnv_occ_xscom_read,
> -.write = pnv_occ_xscom_write,
> +static const MemoryRegionOps pnv_occ_power8_xscom_ops = {
> +.read = pnv_occ_power8_xscom_read,
> +.write = pnv_occ_power8_xscom_write,
>  .valid.min_access_size = 8,
>  .valid.max_access_size = 8,
>  .impl.min_access_size = 8,
> @@ -91,27 +93,42 @@ static const MemoryRegionOps pnv_occ_xscom_ops = {
>  .endianness = DEVICE_BIG_ENDIAN,
>  };
>  
> +static void pnv_occ_power8_class_init(ObjectClass *klass, void *data)
> +{
> +PnvOCCClass *poc = PNV_OCC_CLASS(klass);
> +
> +poc->xscom_size = PNV_XSCOM_OCC_SIZE;
> +poc->xscom_ops = _occ_power8_xscom_ops;
> +poc->psi_irq = PSIHB_IRQ_OCC;
> +}
> +
> +static const TypeInfo pnv_occ_power8_type_info = {
> +.name  = TYPE_PNV8_OCC,
> +.parent= TYPE_PNV_OCC,
> +.instance_size = sizeof(PnvOCC),
> +.class_init= 

Re: [Qemu-devel] [PATCH v2 07/15] ppc/pnv: add SerIRQ routing registers

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:40PM +0100, Cédric Le Goater wrote:
> This is just a simple reminder that SerIRQ routing should be
> addressed.
> 
> Signed-off-by: Cédric Le Goater 
> ---

Applied, thanks.

>  include/hw/ppc/pnv_lpc.h |  2 ++
>  hw/ppc/pnv_lpc.c | 14 ++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/include/hw/ppc/pnv_lpc.h b/include/hw/ppc/pnv_lpc.h
> index 242b18081caa..413579792ed1 100644
> --- a/include/hw/ppc/pnv_lpc.h
> +++ b/include/hw/ppc/pnv_lpc.h
> @@ -55,6 +55,8 @@ typedef struct PnvLpcController {
>  MemoryRegion opb_master_regs;
>  
>  /* OPB Master LS registers */
> +uint32_t opb_irq_route0;
> +uint32_t opb_irq_route1;
>  uint32_t opb_irq_stat;
>  uint32_t opb_irq_mask;
>  uint32_t opb_irq_pol;
> diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
> index 6df694e0abc1..641e2046db92 100644
> --- a/hw/ppc/pnv_lpc.c
> +++ b/hw/ppc/pnv_lpc.c
> @@ -39,6 +39,8 @@ enum {
>  };
>  
>  /* OPB Master LS registers */
> +#define OPB_MASTER_LS_ROUTE00x8
> +#define OPB_MASTER_LS_ROUTE10xC
>  #define OPB_MASTER_LS_IRQ_STAT  0x50
>  #define   OPB_MASTER_IRQ_LPC0x0800
>  #define OPB_MASTER_LS_IRQ_MASK  0x54
> @@ -521,6 +523,12 @@ static uint64_t opb_master_read(void *opaque, hwaddr 
> addr, unsigned size)
>  uint64_t val = 0xul;
>  
>  switch (addr) {
> +case OPB_MASTER_LS_ROUTE0: /* TODO */
> +val = lpc->opb_irq_route0;
> +break;
> +case OPB_MASTER_LS_ROUTE1: /* TODO */
> +val = lpc->opb_irq_route1;
> +break;
>  case OPB_MASTER_LS_IRQ_STAT:
>  val = lpc->opb_irq_stat;
>  break;
> @@ -547,6 +555,12 @@ static void opb_master_write(void *opaque, hwaddr addr,
>  PnvLpcController *lpc = opaque;
>  
>  switch (addr) {
> +case OPB_MASTER_LS_ROUTE0: /* TODO */
> +lpc->opb_irq_route0 = val;
> +break;
> +case OPB_MASTER_LS_ROUTE1: /* TODO */
> +lpc->opb_irq_route1 = val;
> +break;
>  case OPB_MASTER_LS_IRQ_STAT:
>  lpc->opb_irq_stat &= ~val;
>  pnv_lpc_eval_irqs(lpc);

-- 
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 15/27] ppc/pnv: add a PSI bridge model for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 07:37:51AM +0100, Cédric Le Goater wrote:
> On 3/7/19 5:10 AM, David Gibson wrote:
> > On Wed, Mar 06, 2019 at 09:50:20AM +0100, Cédric Le Goater wrote:
> >> The PSI bridge on POWER9 is very similar to POWER8. The BAR is still
> >> set through XSCOM but the controls are now entirely done with MMIOs.
> >> More interrupts are defined and the interrupt controller interface has
> >> changed to XIVE. The POWER9 model is a first example of the usage of
> >> the notify() handler of the XiveNotifier interface, linking the PSI
> >> XiveSource to its owning device model.
> >>
> >> Signed-off-by: Cédric Le Goater 
> >> ---
> >>  include/hw/ppc/pnv.h   |   6 +
> >>  include/hw/ppc/pnv_psi.h   |  24 +++
> >>  include/hw/ppc/pnv_xscom.h |   3 +
> >>  hw/ppc/pnv.c   |  17 ++
> >>  hw/ppc/pnv_psi.c   | 325 -
> >>  5 files changed, 373 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> >> index eb4bba25b3e9..57d0337219be 100644
> >> --- a/include/hw/ppc/pnv.h
> >> +++ b/include/hw/ppc/pnv.h
> >> @@ -84,6 +84,7 @@ typedef struct Pnv9Chip {
> >>  
> >>  /*< public >*/
> >>  PnvXive  xive;
> >> +PnvPsi   psi;
> >>  } Pnv9Chip;
> >>  
> >>  typedef struct PnvChipClass {
> >> @@ -231,11 +232,16 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
> >>  #define PNV9_XIVE_PC_SIZE0x0010ull
> >>  #define PNV9_XIVE_PC_BASE(chip)  PNV9_CHIP_BASE(chip, 
> >> 0x00060180ull)
> >>  
> >> +#define PNV9_PSIHB_SIZE  0x0010ull
> >> +#define PNV9_PSIHB_BASE(chip)PNV9_CHIP_BASE(chip, 
> >> 0x000603020300ull)
> >> +
> >>  #define PNV9_XIVE_IC_SIZE0x0008ull
> >>  #define PNV9_XIVE_IC_BASE(chip)  PNV9_CHIP_BASE(chip, 
> >> 0x000603020310ull)
> >>  
> >>  #define PNV9_XIVE_TM_SIZE0x0004ull
> >>  #define PNV9_XIVE_TM_BASE(chip)  PNV9_CHIP_BASE(chip, 
> >> 0x000603020318ull)
> >>  
> >> +#define PNV9_PSIHB_ESB_SIZE  0x0001ull
> >> +#define PNV9_PSIHB_ESB_BASE(chip)PNV9_CHIP_BASE(chip, 
> >> 0x00060302031cull)
> >>  
> >>  #endif /* _PPC_PNV_H */
> >> diff --git a/include/hw/ppc/pnv_psi.h b/include/hw/ppc/pnv_psi.h
> >> index 585a41cd19b6..d7e1ab282cf8 100644
> >> --- a/include/hw/ppc/pnv_psi.h
> >> +++ b/include/hw/ppc/pnv_psi.h
> >> @@ -21,6 +21,7 @@
> >>  
> >>  #include "hw/sysbus.h"
> >>  #include "hw/ppc/xics.h"
> >> +#include "hw/ppc/xive.h"
> >>  
> >>  #define TYPE_PNV_PSI "pnv-psi"
> >>  #define PNV_PSI(obj) \
> >> @@ -28,6 +29,9 @@
> >>  #define TYPE_PNV8_PSI TYPE_PNV_PSI "-POWER8"
> >>  #define PNV8_PSI(obj) \
> >>  OBJECT_CHECK(PnvPsi, (obj), TYPE_PNV8_PSI)
> >> +#define TYPE_PNV9_PSI TYPE_PNV_PSI "-POWER9"
> >> +#define PNV9_PSI(obj) \
> >> +OBJECT_CHECK(PnvPsi, (obj), TYPE_PNV9_PSI)
> >>  
> >>  #define PSIHB_XSCOM_MAX 0x20
> >>  
> >> @@ -43,6 +47,7 @@ typedef struct PnvPsi {
> >>  
> >>  /* Interrupt generation */
> >>  ICSState ics;
> >> +XiveSource source;
> > 
> > Uh... surely these should move to the subtype structures, so you don't
> > have both of them.
> 
> I did not introduce a subtype, only a subclass. But we could 
> possibly. It seemed overkill for one attribute.
> 
> > 
> >>  qemu_irq *qirqs;
> >>  
> >>  /* Registers */
> >> @@ -82,4 +87,23 @@ typedef enum PnvPsiIrq {
> >>  
> >>  void pnv_psi_irq_set(PnvPsi *psi, int irq, bool state);
> >>  
> >> +/* P9 PSI Interrupts */
> >> +#define PSIHB9_IRQ_PSI  0
> >> +#define PSIHB9_IRQ_OCC  1
> >> +#define PSIHB9_IRQ_FSI  2
> >> +#define PSIHB9_IRQ_LPCHC3
> >> +#define PSIHB9_IRQ_LOCAL_ERR4
> >> +#define PSIHB9_IRQ_GLOBAL_ERR   5
> >> +#define PSIHB9_IRQ_TPM  6
> >> +#define PSIHB9_IRQ_LPC_SIRQ07
> >> +#define PSIHB9_IRQ_LPC_SIRQ18
> >> +#define PSIHB9_IRQ_LPC_SIRQ29
> >> +#define PSIHB9_IRQ_LPC_SIRQ310
> >> +#define PSIHB9_IRQ_SBE_I2C  11
> >> +#define PSIHB9_IRQ_DIO  12
> >> +#define PSIHB9_IRQ_PSU  13
> >> +#define PSIHB9_NUM_IRQS 14
> >> +
> >> +void pnv_psi_pic_print_info(PnvPsi *psi, Monitor *mon);
> >> +
> >>  #endif /* _PPC_PNV_PSI_H */
> >> diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
> >> index 6623ec54a7a8..403a365ed274 100644
> >> --- a/include/hw/ppc/pnv_xscom.h
> >> +++ b/include/hw/ppc/pnv_xscom.h
> >> @@ -73,6 +73,9 @@ typedef struct PnvXScomInterfaceClass {
> >>  #define PNV_XSCOM_OCC_BASE0x0066000
> >>  #define PNV_XSCOM_OCC_SIZE0x6000
> >>  
> >> +#define PNV9_XSCOM_PSIHB_BASE 0x5012900
> >> +#define PNV9_XSCOM_PSIHB_SIZE 0x100
> >> +
> >>  #define PNV9_XSCOM_XIVE_BASE  0x5013000
> >>  #define PNV9_XSCOM_XIVE_SIZE  0x300
> >>  
> >> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> >> index 67d40dc3eebc..4375f97c7135 100644
> >> --- a/hw/ppc/pnv.c
> >> +++ b/hw/ppc/pnv.c
> >> @@ -579,6 

Re: [Qemu-devel] [PATCH] spapr: Use CamelCase properly

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 04:38:28PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 07/03/2019 16:21, David Gibson wrote:
> > The qemu coding standard is to use CamelCase for type and structure names,
> > and the pseries code follows that... sort of.  There are quite a lot of
> > places where we bend the rules in order to preserve the capitalization of
> > internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
> > 
> > That was a bad idea - it frequently leads to names ending up with hard to
> > read clusters of capital letters, and means they don't catch the eye as
> > type identifiers, which is kind of the point of the CamelCase convention in
> > the first place.
> > 
> > In short, keeping type identifiers look like CamelCase is more important
> > than preserving standard capitalization of internal "words".  So, this
> > patch renames a heap of spapr internal type names to a more standard
> > CamelCase.
> > 
> > In addition to case changes, we also make some other identifier renames:
> >   VIOsPAPR* -> SpaprVio*
> > The reverse word ordering was only ever used to mitigate the capital
> > cluster, so revert to the natural ordering.
> >   VIOsPAPRVTYDevice -> SpaprVioVty
> >   VIOsPAPRVLANDevice -> SpaprVioVlan
> > Brevity, since the "Device" didn't add useful information
> >   sPAPRDRConnector -> SpaprDrc
> >   sPAPRDRConnectorClass -> SpaprDrcClass
> > Brevity, and makes it clearer this is the same thing as a "DRC"
> > mentioned in many other places in the code
> > 
> > This is 100% a mechanical search-and-replace patch. It will, however,
> > conflict with essentially any and all outstanding patches touching the
> > spapr code.
> 
> 
> so it would be nice to have the script to fix those outstanding patches
> before reposting.

Sorry, I don't have a script for this.

The patch is equivalent to a scripted replacement, but I didn't
actually make it with a script - I built it up interactively using the
"regexxer" tool.

-- 
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 18/27] ppc/pnv: add a LPC Controller model for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 08:07:41AM +0100, Cédric Le Goater wrote:
> On 3/7/19 5:18 AM, David Gibson wrote:
> > On Wed, Mar 06, 2019 at 09:50:23AM +0100, Cédric Le Goater wrote:
[snip]
> >> +static uint64_t pnv_lpc_mmio_read(void *opaque, hwaddr addr, unsigned 
> >> size)
> >> +{
> >> +PnvLpcController *lpc = PNV_LPC(opaque);
> >> +uint64_t val = 0;
> >> +uint32_t opb_addr = addr & ECCB_CTL_ADDR_MASK;
> >> +MemTxResult result;
> >> +
> >> +switch (size) {
> >> +case 4:
> >> +val = address_space_ldl(>opb_as, opb_addr, 
> >> MEMTXATTRS_UNSPECIFIED,
> >> +);
> >> +break;
> >> +case 1:
> >> +val = address_space_ldub(>opb_as, opb_addr, 
> >> MEMTXATTRS_UNSPECIFIED,
> >> + );
> >> +break;
> >> +default:
> >> +qemu_log_mask(LOG_GUEST_ERROR, "OPB read failed at @0x%"
> >> +  HWADDR_PRIx " invalid size %d\n", addr, size);
> >> +return 0;
> >> +}
> >> +
> >> +if (result != MEMTX_OK) {
> >> +qemu_log_mask(LOG_GUEST_ERROR, "OPB read failed at @0x%"
> >> +  HWADDR_PRIx "\n", addr);
> >> +}
> >> +
> >> +return val;
> > 
> > Couldn't you just map the relevant portion of the OPB AS into the MMIO
> > AS, rather than having to forward the IOs with explicit read/write
> > functions?
> 
> The underlying memory regions (ISA space, LPC HC, OPB regs) are the
> same on POWER8. So this is one way to share the overall initialization. 

I don't understand how that relates to my question.  If anything that
sounds like it makes even more sense to map the common MR with the
actual registers into the MMIO AS as a subregion, rather than having a
redirect via the OPB AS.

> What I would have liked to do is to simplified the ECCB interface 
> (see pnv_lpc_do_eccb()).
> 
> Thanks,
> 
> C. 
> 
> 
> >> +}
> >> +
> >> +static void pnv_lpc_mmio_write(void *opaque, hwaddr addr,
> >> +uint64_t val, unsigned size)
> >> +{
> >> +PnvLpcController *lpc = PNV_LPC(opaque);
> >> +uint32_t opb_addr = addr & ECCB_CTL_ADDR_MASK;
> >> +MemTxResult result;
> >> +
> >> +switch (size) {
> >> +case 4:
> >> +address_space_stl(>opb_as, opb_addr, val, 
> >> MEMTXATTRS_UNSPECIFIED,
> >> +  );
> >> + break;
> >> +case 1:
> >> +address_space_stb(>opb_as, opb_addr, val, 
> >> MEMTXATTRS_UNSPECIFIED,
> >> +  );
> >> +break;
> >> +default:
> >> +qemu_log_mask(LOG_GUEST_ERROR, "OPB write failed at @0x%"
> >> +  HWADDR_PRIx " invalid size %d\n", addr, size);
> >> +return;
> >> +}
> >> +
> >> +if (result != MEMTX_OK) {
> >> +qemu_log_mask(LOG_GUEST_ERROR, "OPB write failed at @0x%"
> >> +  HWADDR_PRIx "\n", addr);
> >> +}
> >> +}
> >> +
> >> +static const MemoryRegionOps pnv_lpc_mmio_ops = {
> >> +.read = pnv_lpc_mmio_read,
> >> +.write = pnv_lpc_mmio_write,
> >> +.impl = {
> >> +.min_access_size = 1,
> >> +.max_access_size = 4,
> >> +},
> >> +.endianness = DEVICE_BIG_ENDIAN,
> >> +};
> >> +
> >>  static void pnv_lpc_eval_irqs(PnvLpcController *lpc)
> >>  {
> >>  bool lpc_to_opb_irq = false;
> >> @@ -465,6 +627,43 @@ static const TypeInfo pnv_lpc_power8_info = {
> >>  }
> >>  };
> >>  
> >> +static void pnv_lpc_power9_realize(DeviceState *dev, Error **errp)
> >> +{
> >> +PnvLpcController *lpc = PNV_LPC(dev);
> >> +PnvLpcClass *plc = PNV_LPC_GET_CLASS(dev);
> >> +Error *local_err = NULL;
> >> +
> >> +plc->parent_realize(dev, _err);
> >> +if (local_err) {
> >> +error_propagate(errp, local_err);
> >> +return;
> >> +}
> >> +
> >> +/* P9 uses a MMIO region */
> >> +memory_region_init_io(>xscom_regs, OBJECT(lpc), 
> >> _lpc_mmio_ops,
> >> +  lpc, "lpcm", PNV9_LPCM_SIZE);
> >> +}
> >> +
> >> +static void pnv_lpc_power9_class_init(ObjectClass *klass, void *data)
> >> +{
> >> +DeviceClass *dc = DEVICE_CLASS(klass);
> >> +PnvLpcClass *plc = PNV_LPC_CLASS(klass);
> >> +
> >> +dc->desc = "PowerNV LPC Controller POWER9";
> >> +
> >> +plc->psi_irq = PSIHB9_IRQ_LPCHC;
> >> +
> >> +device_class_set_parent_realize(dc, pnv_lpc_power9_realize,
> >> +>parent_realize);
> >> +}
> >> +
> >> +static const TypeInfo pnv_lpc_power9_info = {
> >> +.name  = TYPE_PNV9_LPC,
> >> +.parent= TYPE_PNV_LPC,
> >> +.instance_size = sizeof(PnvLpcController),
> >> +.class_init= pnv_lpc_power9_class_init,
> >> +};
> >> +
> >>  static void pnv_lpc_realize(DeviceState *dev, Error **errp)
> >>  {
> >>  PnvLpcController *lpc = PNV_LPC(dev);
> >> @@ -540,6 +739,7 @@ static void pnv_lpc_register_types(void)
> >>  {
> >>  type_register_static(_lpc_info);
> >>  

Re: [Qemu-devel] [PATCH v5 04/14] audio: -audiodev command line option basic implementation

2019-03-07 Thread Zoltán Kővágó
On 2019-03-07 16:56, Gerd Hoffmann wrote:
> On Tue, Feb 26, 2019 at 02:39:38AM +0100, Zoltán Kővágó wrote:
>> On 2019-02-20 22:37, Kővágó, Zoltán wrote:
>> [...]
>>> diff --git a/audio/audio.c b/audio/audio.c
>>> index ce8e6ea8c2..8ad8cbe559 100644
>>> --- a/audio/audio.c
>>> +++ b/audio/audio.c
>> [...]
>>> @@ -2129,3 +1866,170 @@ void AUD_set_volume_in (SWVoiceIn *sw, int mute, 
>>> uint8_t lvol, uint8_t rvol)
>>>  }
>>>  }
>>>  }
>>> +
>>> +void audio_create_pdos(Audiodev *dev)
>>> +{
>>> +switch (dev->driver) {
>>> +#define CASE(DRIVER, driver, pdo_name)  \
>>> +case AUDIODEV_DRIVER_##DRIVER:  \
>>> +dev->u.driver.in = g_malloc0(   \
>>> +sizeof(Audiodev##pdo_name##PerDirectionOptions));   \
>> This should check has_in before overwriting. It'll work correctly when
>> called from audio_legacy.c, but when using -audiodev it will overwrite
>> the options passed by user (and leak memory) when called from
>> audio_validate_opts. I'll fix it in the next update.
> 
> Ping.  4.0 freeze is next tuesday.  Any chance for a v6 early enough
> that we have a chance to get the first chunk into 4.0?  Monday latest,
> preferably earlier ...

I'll try to do something this weekend, but I can't promise anything. I
still haven't got to reading through Markus' comments...

Regards,
Zoltan



Re: [Qemu-devel] [PULL 00/12] sphinx queue

2019-03-07 Thread Philippe Mathieu-Daudé
Hi Peter,

On 3/7/19 5:12 PM, Peter Maydell wrote:
> On Thu, 7 Mar 2019 at 15:24, Peter Maydell  wrote:
>>
>> The only difference from the v3 patchset is that I've
>> changed a -d to -e in patch 10 as suggested by RTH.
>>
>> thanks
>> -- PMM
>>
>> The following changes since commit 32694e98b8d7a246345448a8f707d2e11d6c65e2:
>>
>>   Merge remote-tracking branch 
>> 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2019-03-06 
>> 18:52:19 +)
>>
>> are available in the Git repository at:
>>
>>   https://git.linaro.org/people/pmaydell/qemu-arm.git 
>> tags/pull-sphinx-20190307
>>
>> for you to fetch changes up to c10e01b996df09f6cb4eceb2b7a9754bece927c9:
>>
>>   MAINTAINERS: Add entry for Sphinx documentation infrastructure (2019-03-07 
>> 14:26:47 +)
>>
>> 
>> Enable building and installing rST docs with Sphinx
>>
>> ---
> 
> Applied, thanks.

I'm getting:

./configure --enable-tools --enable-doc
[...]
  GEN qga/qapi-generated/qapi-gen
  GEN docs/qemu-block-drivers.7
  GEN docs/qemu-cpu-models.7
  SPHINX  docs/devel
  SPHINX  docs/interop
  CC  qapi/qapi-visit-core.o
Error: source directory and destination directory are same.
Error: source directory and destination directory are same.
Makefile:880: recipe for target 'docs/interop/index.html' failed
make: *** [docs/interop/index.html] Error 1
make: *** Waiting for unfinished jobs
Makefile:877: recipe for target 'docs/devel/index.html' failed
make: *** [docs/devel/index.html] Error 1
The command "make -j3 && ${TEST_CMD}" exited with 2.

Is it due to the '-j3'?

See: https://travis-ci.org/philmd/qemu/jobs/503343244



Re: [Qemu-devel] Question about hardware cursor in VGA

2019-03-07 Thread BALATON Zoltan

On Thu, 7 Mar 2019, BALATON Zoltan wrote:
I still have the unfinished version using the callbacks which might work with 
force_shadow like for cirrus but I'd need to finish and clean that up. Now 
that we have both implemented probably will allow switching between them but 
may not be able to do it before the freeze so don't wait for that. (The 
define_cursor way is enough for testing at the moment and rewriting it to use 
different callback could be considered bugfix or added in next devel cycle as 
well.)


I've sent a v6 now (of just the ati-vga patch, the other patch in the 
series is unchanged) with this. Defaults to define_cursor but cursor 
rendering via callbacks can be enabled with guest_hwcursor=true property. 
The cursor seems to be less jumpy with it but probably slower. I'm still 
not sure why it jumps with define_cursor but I think that may be a problem 
outside of this device.


I've also attempted to implement DDC for EDID but that's not ready yet and 
it will be a separate series because I'll likely need some changes to i2c 
as well to be able to use bitbang_i2c in this device model. (Probably we 
should merge contents of hw/bitbang_i2c.h in include/hw/i2c.h where the 
structure definition had to be moved already or move this header to 
include to be able to use it outside of hw/i2c. Currently I just #include 
"../i2c/bitbang_i2c.h" from hw/display/ati.c but I think that's not 
acceptable.)


Regards,
BALATON Zoltan



Re: [Qemu-devel] [PATCH v3] hw/display: Add basic ATI VGA emulation

2019-03-07 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190221150353.93de8746...@zero.eik.bme.hu/



Hi,

This series failed the 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.

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

  CC  aarch64-softmmu/hw/intc/aspeed_vic.o
  CC  x86_64-softmmu/hw/virtio/virtio-input-pci.o
In file included from /tmp/qemu-test/src/hw/display/ati.c:19:
/tmp/qemu-test/src/hw/display/ati_regs.h:215: error: "DEFAULT_PITCH" redefined 
[-Werror]
 #define DEFAULT_PITCH   0x16e4
 
In file included from 
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71,
---
 #define DEFAULT_PITCH 0
 
In file included from /tmp/qemu-test/src/hw/display/ati_2d.c:11:
/tmp/qemu-test/src/hw/display/ati_regs.h:215: error: "DEFAULT_PITCH" redefined 
[-Werror]
 #define DEFAULT_PITCH   0x16e4
 
In file included from 
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71,
---
 
  CC  aarch64-softmmu/hw/intc/arm_gicv3_cpuif.o
In file included from /tmp/qemu-test/src/hw/display/ati_2d.c:11:
/tmp/qemu-test/src/hw/display/ati_regs.h:215: error: "DEFAULT_PITCH" redefined 
[-Werror]
 #define DEFAULT_PITCH   0x16e4
 
In file included from 
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71,
---
cc1: all warnings being treated as errors
make[1]: *** [/tmp/qemu-test/src/rules.mak:69: hw/display/ati.o] Error 1
In file included from /tmp/qemu-test/src/hw/display/ati.c:19:
/tmp/qemu-test/src/hw/display/ati_regs.h:215: error: "DEFAULT_PITCH" redefined 
[-Werror]
 #define DEFAULT_PITCH   0x16e4
 
In file included from 
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71,


The full log is available at
http://patchew.org/logs/20190221150353.93de8746...@zero.eik.bme.hu/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [PATCH v6] hw/display: Add basic ATI VGA emulation

2019-03-07 Thread BALATON Zoltan
At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
guests running on these and the PMON2000 firmware of the fulong2e
expect this to be available. Fortunately these are very similar chips
so they can be mostly emulated in the same device model. This patch
adds basic emulation of these ATI VGA chips.

While this is incomplete and currently only enough to run the MIPS
firmware and get framebuffer output with Linux, it allows the fulong2e
board to work more like the real hardware and having it in QEMU in
this state provides a way to experiment with it and allows others to
contribute to improve it. It is compiled for all archs but only the
fulong2e (which currently has no display output at all) is set to use
it by default (in a separate patch).

Signed-off-by: BALATON Zoltan 
Acked-by: Aleksandar Markovic 
---
v6:
- add support for hwcursor rendered in device as well, enable with
  guest_hwcursor=true property

v5:
- review suggestions: add const to model aliases, \n to log, %u in trace
- implemented hardware cursor support

v4:
- fix mingw build (from Gerd)
- set dev_id in realize to allow pci_patch_ids to change bios rom
- add model aliases to select device variant by name instead of id
- misc mode switch and 2d fixes (better but still not quite right)

v3:
- add to default-configs/pci.mak instead of mips64el and ppc only
- rename device_id property to x-device-id
- use extract32/deposit32 in *_offs functions
- add ati-vga to vl.c default_list[]

v2:
- Extended debug logs
- Fix mode switching and some registers
- Fixes to 2D functions

 default-configs/pci.mak  |   1 +
 hw/display/Makefile.objs |   2 +
 hw/display/ati.c | 865 +++
 hw/display/ati_2d.c  | 167 +
 hw/display/ati_dbg.c | 259 ++
 hw/display/ati_int.h |  96 ++
 hw/display/ati_regs.h| 461 +
 hw/display/trace-events  |   4 +
 vl.c |   1 +
 9 files changed, 1856 insertions(+)
 create mode 100644 hw/display/ati.c
 create mode 100644 hw/display/ati_2d.c
 create mode 100644 hw/display/ati_dbg.c
 create mode 100644 hw/display/ati_int.h
 create mode 100644 hw/display/ati_regs.h

diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index 037636fa33..e59e2fa7b6 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -49,3 +49,4 @@ CONFIG_IVSHMEM_DEVICE=$(CONFIG_IVSHMEM)
 CONFIG_ROCKER=y
 CONFIG_VFIO=$(CONFIG_LINUX)
 CONFIG_VFIO_PCI=y
+CONFIG_ATI_VGA=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7c4ae9a0fd..963c23f3c8 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -53,3 +53,5 @@ virtio-gpu-3d.o-cflags := $(VIRGL_CFLAGS)
 virtio-gpu-3d.o-libs += $(VIRGL_LIBS)
 obj-$(CONFIG_DPCD) += dpcd.o
 obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dp.o
+
+obj-$(CONFIG_ATI_VGA) += ati.o ati_2d.o ati_dbg.o
diff --git a/hw/display/ati.c b/hw/display/ati.c
new file mode 100644
index 00..8322f52aff
--- /dev/null
+++ b/hw/display/ati.c
@@ -0,0 +1,865 @@
+/*
+ * QEMU ATI SVGA emulation
+ *
+ * Copyright (c) 2019 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ */
+
+/*
+ * WARNING:
+ * This is very incomplete and only enough for Linux console and some
+ * unaccelerated X output at the moment.
+ * Currently it's little more than a frame buffer with minimal functions,
+ * other more advanced features of the hardware are yet to be implemented.
+ * We only aim for Rage 128 Pro (and some RV100) and 2D only at first,
+ * No 3D at all yet (maybe after 2D works, but feel free to improve it)
+ */
+
+#include "ati_int.h"
+#include "ati_regs.h"
+#include "vga_regs.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "ui/console.h"
+#include "trace.h"
+
+#define ATI_DEBUG_HW_CURSOR 0
+
+static const struct {
+const char *name;
+uint16_t dev_id;
+} ati_model_aliases[] = {
+{ "rage128p", PCI_DEVICE_ID_ATI_RAGE128_PF },
+{ "rv100", PCI_DEVICE_ID_ATI_RADEON_QY },
+};
+
+enum { VGA_MODE, EXT_MODE };
+
+static void ati_vga_switch_mode(ATIVGAState *s)
+{
+DPRINTF("%d -> %d\n",
+s->mode, !!(s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN));
+if (s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN) {
+/* Extended mode enabled */
+s->mode = EXT_MODE;
+if (s->regs.crtc_gen_cntl & CRTC2_EN) {
+/* CRT controller enabled, use CRTC values */
+uint32_t offs = s->regs.crtc_offset & 0x07ff;
+int stride = (s->regs.crtc_pitch & 0x7ff) * 8;
+int bpp = 0;
+int h, v;
+
+if (s->regs.crtc_h_total_disp == 0) {
+s->regs.crtc_h_total_disp = ((640 / 8) - 1) << 16;
+}
+if (s->regs.crtc_v_total_disp == 0) {
+s->regs.crtc_v_total_disp = (480 - 1) << 16;
+  

Re: [Qemu-devel] [PATCH v2 05/15] ppc/pnv: add a 'dt_isa_nodename' to the chip

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:38PM +0100, Cédric Le Goater wrote:
> The ISA bus has a different DT nodename on POWER9. Compute the name
> when the PnvChip is realized, that is before it is used by the machine
> to populate the device tree with the ISA devices.
> 
> Signed-off-by: Cédric Le Goater 

I still tend to think that passing an offset into pnv_dt_isa would
have been a better solution, but this will serve.  Applied.

> ---
>  include/hw/ppc/pnv.h |  2 ++
>  hw/ppc/pnv.c | 18 +-
>  2 files changed, 7 insertions(+), 13 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 8d80cb34eebb..c81f157f41a9 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -58,6 +58,8 @@ typedef struct PnvChip {
>  MemoryRegion xscom_mmio;
>  MemoryRegion xscom;
>  AddressSpace xscom_as;
> +
> +gchar*dt_isa_nodename;
>  } PnvChip;
>  
>  #define TYPE_PNV8_CHIP "pnv8-chip"
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 922e3ec48bb5..6625562d276d 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -417,24 +417,12 @@ static int pnv_dt_isa_device(DeviceState *dev, void 
> *opaque)
>  return 0;
>  }
>  
> -static int pnv_chip_isa_offset(PnvChip *chip, void *fdt)
> -{
> -char *name;
> -int offset;
> -
> -name = g_strdup_printf("/xscom@%" PRIx64 "/isa@%x",
> -   (uint64_t) PNV_XSCOM_BASE(chip), 
> PNV_XSCOM_LPC_BASE);
> -offset = fdt_path_offset(fdt, name);
> -g_free(name);
> -return offset;
> -}
> -
>  /* The default LPC bus of a multichip system is on chip 0. It's
>   * recognized by the firmware (skiboot) using a "primary" property.
>   */
>  static void pnv_dt_isa(PnvMachineState *pnv, void *fdt)
>  {
> -int isa_offset = pnv_chip_isa_offset(pnv->chips[0], fdt);
> +int isa_offset = fdt_path_offset(fdt, pnv->chips[0]->dt_isa_nodename);
>  ForeachPopulateArgs args = {
>  .fdt = fdt,
>  .offset = isa_offset,
> @@ -866,6 +854,10 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
> Error **errp)
>   _fatal);
>  pnv_xscom_add_subregion(chip, PNV_XSCOM_LPC_BASE, 
> >lpc.xscom_regs);
>  
> +chip->dt_isa_nodename = g_strdup_printf("/xscom@%" PRIx64 "/isa@%x",
> +(uint64_t) PNV_XSCOM_BASE(chip),
> +PNV_XSCOM_LPC_BASE);
> +
>  /* Interrupt Management Area. This is the memory region holding
>   * all the Interrupt Control Presenter (ICP) registers */
>  pnv_chip_icp_realize(chip8, _err);

-- 
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 v2 4/7] target/ppc: introduce avr_full_offset() function

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 06:05:17PM +, Mark Cave-Ayland wrote:
> All TCG vector operations require pointers to the base address of the vector
> rather than separate access to the top and bottom 64-bits. Convert the VMX TCG
> instructions to use a new avr_full_offset() function instead of avr64_offset()
> which can then itself be written as a simple wrapper onto vsr_full_offset().
> 
> This same function can also reused in cpu_avr_ptr() to avoid having more than
> one copy of the offset calculation logic.
> 
> Signed-off-by: Mark Cave-Ayland 

Applied, thanks.

> ---
>  target/ppc/cpu.h| 12 +++-
>  target/ppc/translate/vmx-impl.inc.c | 22 +++---
>  target/ppc/translate/vsx-impl.inc.c |  5 -
>  3 files changed, 22 insertions(+), 17 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index d0580c6b6d..2a2792306f 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -2598,14 +2598,24 @@ static inline int vsrl_offset(int i)
>  return offsetof(CPUPPCState, vsr[i].u64[1]);
>  }
>  
> +static inline int vsr_full_offset(int i)
> +{
> +return offsetof(CPUPPCState, vsr[i].u64[0]);
> +}
> +
>  static inline uint64_t *cpu_vsrl_ptr(CPUPPCState *env, int i)
>  {
>  return (uint64_t *)((uintptr_t)env + vsrl_offset(i));
>  }
>  
> +static inline int avr_full_offset(int i)
> +{
> +return vsr_full_offset(i + 32);
> +}
> +
>  static inline ppc_avr_t *cpu_avr_ptr(CPUPPCState *env, int i)
>  {
> -return >vsr[32 + i];
> +return (ppc_avr_t *)((uintptr_t)env + avr_full_offset(i));
>  }
>  
>  void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUPPCState *env);
> diff --git a/target/ppc/translate/vmx-impl.inc.c 
> b/target/ppc/translate/vmx-impl.inc.c
> index f1b15ae2cb..4e5d0bc0e0 100644
> --- a/target/ppc/translate/vmx-impl.inc.c
> +++ b/target/ppc/translate/vmx-impl.inc.c
> @@ -10,7 +10,7 @@
>  static inline TCGv_ptr gen_avr_ptr(int reg)
>  {
>  TCGv_ptr r = tcg_temp_new_ptr();
> -tcg_gen_addi_ptr(r, cpu_env, offsetof(CPUPPCState, vsr[32 + 
> reg].u64[0]));
> +tcg_gen_addi_ptr(r, cpu_env, avr_full_offset(reg));
>  return r;
>  }
>  
> @@ -205,7 +205,7 @@ static void gen_mtvscr(DisasContext *ctx)
>  }
>  
>  val = tcg_temp_new_i32();
> -bofs = avr64_offset(rB(ctx->opcode), true);
> +bofs = avr_full_offset(rB(ctx->opcode));
>  #ifdef HOST_WORDS_BIGENDIAN
>  bofs += 3 * 4;
>  #endif
> @@ -284,9 +284,9 @@ static void glue(gen_, name)(DisasContext *ctx)   
>   \
>  }   \
>  \
>  tcg_op(vece,\
> -   avr64_offset(rD(ctx->opcode), true), \
> -   avr64_offset(rA(ctx->opcode), true), \
> -   avr64_offset(rB(ctx->opcode), true), \
> +   avr_full_offset(rD(ctx->opcode)),\
> +   avr_full_offset(rA(ctx->opcode)),\
> +   avr_full_offset(rB(ctx->opcode)),\
> 16, 16); \
>  }
>  
> @@ -578,10 +578,10 @@ static void glue(gen_, NAME)(DisasContext *ctx) 
> \
>  gen_exception(ctx, POWERPC_EXCP_VPU);   \
>  return; \
>  }   \
> -tcg_gen_gvec_4(avr64_offset(rD(ctx->opcode), true), \
> +tcg_gen_gvec_4(avr_full_offset(rD(ctx->opcode)),\
> offsetof(CPUPPCState, vscr_sat), \
> -   avr64_offset(rA(ctx->opcode), true), \
> -   avr64_offset(rB(ctx->opcode), true), \
> +   avr_full_offset(rA(ctx->opcode)),\
> +   avr_full_offset(rB(ctx->opcode)),\
> 16, 16, ); \
>  }
>  
> @@ -755,7 +755,7 @@ static void glue(gen_, name)(DisasContext *ctx)   
>   \
>  return; \
>  }   \
>  simm = SIMM5(ctx->opcode);  \
> -tcg_op(avr64_offset(rD(ctx->opcode), true), 16, 16, simm);  \
> +tcg_op(avr_full_offset(rD(ctx->opcode)), 16, 16, simm); \
>  }
>  
>  GEN_VXFORM_DUPI(vspltisb, tcg_gen_gvec_dup8i, 6, 12);
> @@ -850,8 +850,8 @@ static void gen_vsplt(DisasContext *ctx, int vece)
>  }
>  
>  uimm = UIMM5(ctx->opcode);
> -bofs = avr64_offset(rB(ctx->opcode), true);
> - 

Re: [Qemu-devel] [PATCH v2 1/7] target/ppc: introduce single fpr_offset() function

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 06:05:14PM +, Mark Cave-Ayland wrote:
> Instead of having multiple copies of the offset calculation logic, move it to 
> a
> single fpr_offset() function.
> 
> Signed-off-by: Mark Cave-Ayland 
> Reviewed-by: Richard Henderson 

Applied, thanks.

> ---
>  target/ppc/cpu.h   | 7 ++-
>  target/ppc/translate.c | 4 ++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 26604ddf98..4bb4e42670 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -2563,9 +2563,14 @@ static inline bool lsw_reg_in_range(int start, int 
> nregs, int rx)
>  }
>  
>  /* Accessors for FP, VMX and VSX registers */
> +static inline int fpr_offset(int i)
> +{
> +return offsetof(CPUPPCState, vsr[i].u64[0]);
> +}
> +
>  static inline uint64_t *cpu_fpr_ptr(CPUPPCState *env, int i)
>  {
> -return >vsr[i].u64[0];
> +return (uint64_t *)((uintptr_t)env + fpr_offset(i));
>  }
>  
>  static inline uint64_t *cpu_vsrl_ptr(CPUPPCState *env, int i)
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 819221f246..3b1992faf1 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -6677,12 +6677,12 @@ GEN_TM_PRIV_NOOP(trechkpt);
>  
>  static inline void get_fpr(TCGv_i64 dst, int regno)
>  {
> -tcg_gen_ld_i64(dst, cpu_env, offsetof(CPUPPCState, vsr[regno].u64[0]));
> +tcg_gen_ld_i64(dst, cpu_env, fpr_offset(regno));
>  }
>  
>  static inline void set_fpr(int regno, TCGv_i64 src)
>  {
> -tcg_gen_st_i64(src, cpu_env, offsetof(CPUPPCState, vsr[regno].u64[0]));
> +tcg_gen_st_i64(src, cpu_env, fpr_offset(regno));
>  }
>  
>  static inline void get_avr64(TCGv_i64 dst, int regno, bool high)

-- 
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 v2 02/15] ppc/pnv: add a PSI bridge model for POWER9

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:35PM +0100, Cédric Le Goater wrote:
> The PSI bridge on POWER9 is very similar to POWER8. The BAR is still
> set through XSCOM but the controls are now entirely done with MMIOs.
> More interrupts are defined and the interrupt controller interface has
> changed to XIVE. The POWER9 model is a first example of the usage of
> the notify() handler of the XiveNotifier interface, linking the PSI
> XiveSource to its owning device model.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
> 
>  Changes in v2 :
>  
>   - introduced a Pnv9Psi (XIVE) model
>   
>  include/hw/ppc/pnv.h   |   6 +
>  include/hw/ppc/pnv_psi.h   |  30 
>  include/hw/ppc/pnv_xscom.h |   3 +
>  hw/ppc/pnv.c   |  18 ++
>  hw/ppc/pnv_psi.c   | 329 -
>  5 files changed, 384 insertions(+), 2 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 3b5f9cd53184..8d80cb34eebb 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -84,6 +84,7 @@ typedef struct Pnv9Chip {
>  
>  /*< public >*/
>  PnvXive  xive;
> +Pnv9Psi  psi;
>  } Pnv9Chip;
>  
>  typedef struct PnvChipClass {
> @@ -231,11 +232,16 @@ void pnv_bmc_powerdown(IPMIBmc *bmc);
>  #define PNV9_XIVE_PC_SIZE0x0010ull
>  #define PNV9_XIVE_PC_BASE(chip)  PNV9_CHIP_BASE(chip, 
> 0x00060180ull)
>  
> +#define PNV9_PSIHB_SIZE  0x0010ull
> +#define PNV9_PSIHB_BASE(chip)PNV9_CHIP_BASE(chip, 
> 0x000603020300ull)
> +
>  #define PNV9_XIVE_IC_SIZE0x0008ull
>  #define PNV9_XIVE_IC_BASE(chip)  PNV9_CHIP_BASE(chip, 
> 0x000603020310ull)
>  
>  #define PNV9_XIVE_TM_SIZE0x0004ull
>  #define PNV9_XIVE_TM_BASE(chip)  PNV9_CHIP_BASE(chip, 
> 0x000603020318ull)
>  
> +#define PNV9_PSIHB_ESB_SIZE  0x0001ull
> +#define PNV9_PSIHB_ESB_BASE(chip)PNV9_CHIP_BASE(chip, 
> 0x00060302031cull)
>  
>  #endif /* _PPC_PNV_H */
> diff --git a/include/hw/ppc/pnv_psi.h b/include/hw/ppc/pnv_psi.h
> index 7087cbcb9ad7..2c1b27e865bd 100644
> --- a/include/hw/ppc/pnv_psi.h
> +++ b/include/hw/ppc/pnv_psi.h
> @@ -21,6 +21,7 @@
>  
>  #include "hw/sysbus.h"
>  #include "hw/ppc/xics.h"
> +#include "hw/ppc/xive.h"
>  
>  #define TYPE_PNV_PSI "pnv-psi"
>  #define PNV_PSI(obj) \
> @@ -57,6 +58,16 @@ typedef struct Pnv8Psi {
>  ICSState ics;
>  } Pnv8Psi;
>  
> +#define TYPE_PNV9_PSI TYPE_PNV_PSI "-POWER9"
> +#define PNV9_PSI(obj) \
> +OBJECT_CHECK(Pnv9Psi, (obj), TYPE_PNV9_PSI)
> +
> +typedef struct Pnv9Psi {
> +PnvPsi   parent;
> +
> +XiveSource source;
> +} Pnv9Psi;
> +
>  #define PNV_PSI_CLASS(klass) \
>   OBJECT_CLASS_CHECK(PnvPsiClass, (klass), TYPE_PNV_PSI)
>  #define PNV_PSI_GET_CLASS(obj) \
> @@ -88,4 +99,23 @@ typedef enum PnvPsiIrq {
>  
>  void pnv_psi_irq_set(PnvPsi *psi, int irq, bool state);
>  
> +/* P9 PSI Interrupts */
> +#define PSIHB9_IRQ_PSI  0
> +#define PSIHB9_IRQ_OCC  1
> +#define PSIHB9_IRQ_FSI  2
> +#define PSIHB9_IRQ_LPCHC3
> +#define PSIHB9_IRQ_LOCAL_ERR4
> +#define PSIHB9_IRQ_GLOBAL_ERR   5
> +#define PSIHB9_IRQ_TPM  6
> +#define PSIHB9_IRQ_LPC_SIRQ07
> +#define PSIHB9_IRQ_LPC_SIRQ18
> +#define PSIHB9_IRQ_LPC_SIRQ29
> +#define PSIHB9_IRQ_LPC_SIRQ310
> +#define PSIHB9_IRQ_SBE_I2C  11
> +#define PSIHB9_IRQ_DIO  12
> +#define PSIHB9_IRQ_PSU  13
> +#define PSIHB9_NUM_IRQS 14
> +
> +void pnv_psi_pic_print_info(Pnv9Psi *psi, Monitor *mon);
> +
>  #endif /* _PPC_PNV_PSI_H */
> diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
> index 6623ec54a7a8..403a365ed274 100644
> --- a/include/hw/ppc/pnv_xscom.h
> +++ b/include/hw/ppc/pnv_xscom.h
> @@ -73,6 +73,9 @@ typedef struct PnvXScomInterfaceClass {
>  #define PNV_XSCOM_OCC_BASE0x0066000
>  #define PNV_XSCOM_OCC_SIZE0x6000
>  
> +#define PNV9_XSCOM_PSIHB_BASE 0x5012900
> +#define PNV9_XSCOM_PSIHB_SIZE 0x100
> +
>  #define PNV9_XSCOM_XIVE_BASE  0x5013000
>  #define PNV9_XSCOM_XIVE_SIZE  0x300
>  
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 5bb2332f167a..1cc454cbbc27 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -579,6 +579,7 @@ static void pnv_chip_power9_pic_print_info(PnvChip *chip, 
> Monitor *mon)
>  Pnv9Chip *chip9 = PNV9_CHIP(chip);
>  
>  pnv_xive_pic_print_info(>xive, mon);
> +pnv_psi_pic_print_info(>psi, mon);
>  }
>  
>  static void pnv_init(MachineState *machine)
> @@ -950,6 +951,11 @@ static void pnv_chip_power9_instance_init(Object *obj)
>  TYPE_PNV_XIVE, _abort, NULL);
>  object_property_add_const_link(OBJECT(>xive), "chip", obj,
> _abort);
> +
> +object_initialize_child(obj, "psi",  >psi, sizeof(chip9->psi),
> +TYPE_PNV9_PSI, _abort, NULL);
> +

Re: [Qemu-devel] [PATCH v3 07/14] ppc405_boards: Don't size flash memory to match backing image

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 02:03:16PM +0100, Markus Armbruster wrote:
> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
> Image size is rounded up to the next multiple of 64KiB.  Useless,
> because pflash_cfi02_realize() fails with "failed to read the initial
> flash content" unless the rounding is a no-op.
> 
> If the image size exceeds 0x8 Bytes, we overlap first SRAM, then
> other stuff.  No idea how that would play out, but useful outcomes
> seem unlikely.
> 
> Map the flash memory at fixed address 0xFFF8 with size 512KiB,
> regardless of image size, to match the physical hardware.
> 
> Machine "taihu" maps its boot flash memory similarly.  The code even
> has a comment /* XXX: should check that size is 2MB */, followed by
> disabled code to adjust the size to 2MiB regardless of image size.
> 
> Its code to map its application flash memory looks the same, except
> there the XXX comment asks for 32MiB, and the code to adjust the size
> isn't disabled.  Note that pflash_cfi02_realize() fails with "failed
> to read the initial flash content" for images smaller than 32MiB.
> 
> Map the boot flash memory at fixed address 0xFFE0 with size 2MiB,
> to match the physical hardware.  Delete dead code from application
> flash mapping, and simplify some.
> 
> Cc: David Gibson 
> Signed-off-by: Markus Armbruster 
> Acked-by: David Gibson 
> Reviewed-by: Alex Bennée 

I'm assuming because this is in a series I'm not otherwise CCed on
that this is going in through someone else's tree.  Let me know if you
want me take it through mine.

> ---
>  hw/ppc/ppc405_boards.c | 51 +-
>  1 file changed, 15 insertions(+), 36 deletions(-)
> 
> diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
> index f47b15f10e..672717ef1b 100644
> --- a/hw/ppc/ppc405_boards.c
> +++ b/hw/ppc/ppc405_boards.c
> @@ -158,7 +158,7 @@ static void ref405ep_init(MachineState *machine)
>  target_ulong kernel_base, initrd_base;
>  long kernel_size, initrd_size;
>  int linux_boot;
> -int fl_idx, fl_sectors, len;
> +int len;
>  DriveInfo *dinfo;
>  MemoryRegion *sysmem = get_system_memory();
>  
> @@ -185,26 +185,19 @@ static void ref405ep_init(MachineState *machine)
>  #ifdef DEBUG_BOARD_INIT
>  printf("%s: register BIOS\n", __func__);
>  #endif
> -fl_idx = 0;
>  #ifdef USE_FLASH_BIOS
> -dinfo = drive_get(IF_PFLASH, 0, fl_idx);
> +dinfo = drive_get(IF_PFLASH, 0, 0);
>  if (dinfo) {
> -BlockBackend *blk = blk_by_legacy_dinfo(dinfo);
> -
> -bios_size = blk_getlength(blk);
> -fl_sectors = (bios_size + 65535) >> 16;
>  #ifdef DEBUG_BOARD_INIT
> -printf("Register parallel flash %d size %lx"
> -   " at addr %lx '%s' %d\n",
> -   fl_idx, bios_size, -bios_size,
> -   blk_name(blk), fl_sectors);
> +printf("Register parallel flash\n");
>  #endif
> +bios_size = 8 * MiB;
>  pflash_cfi02_register((uint32_t)(-bios_size),
>NULL, "ef405ep.bios", bios_size,
> -  blk, 65536, fl_sectors, 1,
> +  dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
> +  64 * KiB, bios_size / (64 * KiB), 1,
>2, 0x0001, 0x22DA, 0x, 0x, 0x555, 
> 0x2AA,
>1);
> -fl_idx++;
>  } else
>  #endif
>  {
> @@ -455,7 +448,7 @@ static void taihu_405ep_init(MachineState *machine)
>  target_ulong kernel_base, initrd_base;
>  long kernel_size, initrd_size;
>  int linux_boot;
> -int fl_idx, fl_sectors;
> +int fl_idx;
>  DriveInfo *dinfo;
>  
>  /* RAM is soldered to the board so the size cannot be changed */
> @@ -486,21 +479,14 @@ static void taihu_405ep_init(MachineState *machine)
>  #if defined(USE_FLASH_BIOS)
>  dinfo = drive_get(IF_PFLASH, 0, fl_idx);
>  if (dinfo) {
> -BlockBackend *blk = blk_by_legacy_dinfo(dinfo);
> -
> -bios_size = blk_getlength(blk);
> -/* XXX: should check that size is 2MB */
> -//bios_size = 2 * 1024 * 1024;
> -fl_sectors = (bios_size + 65535) >> 16;
>  #ifdef DEBUG_BOARD_INIT
> -printf("Register parallel flash %d size %lx"
> -   " at addr %lx '%s' %d\n",
> -   fl_idx, bios_size, -bios_size,
> -   blk_name(blk), fl_sectors);
> +printf("Register boot flash\n");
>  #endif
> -pflash_cfi02_register((uint32_t)(-bios_size),
> +bios_size = 2 * MiB;
> +pflash_cfi02_register(0xFFE0,
>NULL, "taihu_405ep.bios", bios_size,
> -  blk, 65536, fl_sectors, 1,
> +  dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
> +  64 * KiB, bios_size / (64 * KiB), 1,
>4, 0x0001, 0x22DA, 0x, 0x, 

Re: [Qemu-devel] [PATCH v2 2/7] target/ppc: introduce single vsrl_offset() function

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 06:05:15PM +, Mark Cave-Ayland wrote:
> Instead of having multiple copies of the offset calculation logic, move it to 
> a
> single vsrl_offset() function.
> 
> This commit also renames the existing get_vsr()/set_vsr() functions to
> get_vsrl()/set_vsrl() which better describes their purpose.
> 
> Signed-off-by: Mark Cave-Ayland 
> Reviewed-by: Richard Henderson 

Applied, thanks.

> ---
>  target/ppc/cpu.h|  7 ++-
>  target/ppc/translate/vsx-impl.inc.c | 12 ++--
>  2 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 4bb4e42670..4a7df13c2d 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -2573,9 +2573,14 @@ static inline uint64_t *cpu_fpr_ptr(CPUPPCState *env, 
> int i)
>  return (uint64_t *)((uintptr_t)env + fpr_offset(i));
>  }
>  
> +static inline int vsrl_offset(int i)
> +{
> +return offsetof(CPUPPCState, vsr[i].u64[1]);
> +}
> +
>  static inline uint64_t *cpu_vsrl_ptr(CPUPPCState *env, int i)
>  {
> -return >vsr[i].u64[1];
> +return (uint64_t *)((uintptr_t)env + vsrl_offset(i));
>  }
>  
>  static inline ppc_avr_t *cpu_avr_ptr(CPUPPCState *env, int i)
> diff --git a/target/ppc/translate/vsx-impl.inc.c 
> b/target/ppc/translate/vsx-impl.inc.c
> index e73197e717..381ae0f2e9 100644
> --- a/target/ppc/translate/vsx-impl.inc.c
> +++ b/target/ppc/translate/vsx-impl.inc.c
> @@ -1,13 +1,13 @@
>  /***   VSX extension   
> ***/
>  
> -static inline void get_vsr(TCGv_i64 dst, int n)
> +static inline void get_vsrl(TCGv_i64 dst, int n)
>  {
> -tcg_gen_ld_i64(dst, cpu_env, offsetof(CPUPPCState, vsr[n].u64[1]));
> +tcg_gen_ld_i64(dst, cpu_env, vsrl_offset(n));
>  }
>  
> -static inline void set_vsr(int n, TCGv_i64 src)
> +static inline void set_vsrl(int n, TCGv_i64 src)
>  {
> -tcg_gen_st_i64(src, cpu_env, offsetof(CPUPPCState, vsr[n].u64[1]));
> +tcg_gen_st_i64(src, cpu_env, vsrl_offset(n));
>  }
>  
>  static inline int vsr_full_offset(int n)
> @@ -27,7 +27,7 @@ static inline void get_cpu_vsrh(TCGv_i64 dst, int n)
>  static inline void get_cpu_vsrl(TCGv_i64 dst, int n)
>  {
>  if (n < 32) {
> -get_vsr(dst, n);
> +get_vsrl(dst, n);
>  } else {
>  get_avr64(dst, n - 32, false);
>  }
> @@ -45,7 +45,7 @@ static inline void set_cpu_vsrh(int n, TCGv_i64 src)
>  static inline void set_cpu_vsrl(int n, TCGv_i64 src)
>  {
>  if (n < 32) {
> -set_vsr(n, src);
> +set_vsrl(n, src);
>  } else {
>  set_avr64(n - 32, src, false);
>  }

-- 
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 v2 0/7] target/ppc: switch fpr/vsrl registers so all VSX registers are in host endian order

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 06:05:13PM +, Mark Cave-Ayland wrote:
> After some investigation into Andrew's report of corruption in his ppc64le
> tests at https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07234.html, 
> I
> discovered the underlying cause was that the first 32 VSX registers are not
> stored in host endian order.
> 
> This is something that Richard and I had discussed before, but missed that 
> with
> VSX if you have source registers from different register sets then even 
> logical
> operations will give you the wrong result.
> 
> Rather than revert 7b8fe477e1 "target/ppc: convert VSX logical operations to
> vector operations" let's keep the use of the accelerated vector instructions,
> and instead fix the real problem which is to switch the first 32 VSX registers
> to host endian order matching the VMX registers.
> 
> Patches 1-5 aim to consolidate the offset calculations for both CPUPPCState
> and the associated _ptr() functions into one single place.
> 
> With this preliminary work complete, patch 6 switches the first 32 registers
> into host endian order without too much difficulty.
> 
> Finally now that all VSX registers are stored in the same way, the vsr offset
> functions and get_cpu_vsrh()/get_cpu_vsrl() can be simplified accordingly.
> 
> Signed-off-by: Mark Cave-Ayland 

Series applied to ppc-for-4.0, thanks.

> 
> v2:
> - Rebase onto master
> - Rework patchset set based upon av64_offset()/vsr64_offset() as suggested by
>   Richard, rather than using separate low/high accessors
> 
> 
> Mark Cave-Ayland (7):
>   target/ppc: introduce single fpr_offset() function
>   target/ppc: introduce single vsrl_offset() function
>   target/ppc: move Vsr* macros from internal.h to cpu.h
>   target/ppc: introduce avr_full_offset() function
>   target/ppc: improve avr64_offset() and use it to simplify
> get_avr64()/set_avr64()
>   target/ppc: switch fpr/vsrl registers so all VSX registers are in host
> endian order
>   target/ppc: introduce vsr64_offset() to simplify get_cpu_vsr{l,h}()
> and set_cpu_vsr{l,h}()
> 
>  target/ppc/cpu.h| 51 
> ++---
>  target/ppc/internal.h   | 27 +++-
>  target/ppc/machine.c|  8 +++---
>  target/ppc/translate.c  | 20 +++
>  target/ppc/translate/vmx-impl.inc.c | 27 
>  target/ppc/translate/vsx-impl.inc.c | 39 +++-
>  6 files changed, 75 insertions(+), 97 deletions(-)
> 

-- 
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 v2 01/15] ppc/pnv: add a PSI bridge class model

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:34PM +0100, Cédric Le Goater wrote:
> To ease the introduction of the PSI bridge model for POWER9, abstract
> the POWER chip differences in a PnvPsi class model and introduce a
> specific Pnv8Psi type for POWER8. POWER8 interface to the interrupt
> controller is still XICS whereas POWER9 uses the new XIVE model.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
> 
>  Changes in v2 :
> 
>  - introduced a Pnv8Psi (XICS) model
> 
>  include/hw/ppc/pnv.h |  2 +-
>  include/hw/ppc/pnv_psi.h | 29 ++-
>  hw/ppc/pnv.c |  6 ++-
>  hw/ppc/pnv_psi.c | 79 
>  4 files changed, 87 insertions(+), 29 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index eb4bba25b3e9..3b5f9cd53184 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -71,7 +71,7 @@ typedef struct Pnv8Chip {
>  MemoryRegion icp_mmio;
>  
>  PnvLpcController lpc;
> -PnvPsi   psi;
> +Pnv8Psi  psi;
>  PnvOCC   occ;
>  } Pnv8Chip;
>  
> diff --git a/include/hw/ppc/pnv_psi.h b/include/hw/ppc/pnv_psi.h
> index 64ac73512e81..7087cbcb9ad7 100644
> --- a/include/hw/ppc/pnv_psi.h
> +++ b/include/hw/ppc/pnv_psi.h
> @@ -39,7 +39,6 @@ typedef struct PnvPsi {
>  uint64_t fsp_bar;
>  
>  /* Interrupt generation */
> -ICSState ics;
>  qemu_irq *qirqs;
>  
>  /* Registers */
> @@ -48,6 +47,32 @@ typedef struct PnvPsi {
>  MemoryRegion xscom_regs;
>  } PnvPsi;
>  
> +#define TYPE_PNV8_PSI TYPE_PNV_PSI "-POWER8"
> +#define PNV8_PSI(obj) \
> +OBJECT_CHECK(Pnv8Psi, (obj), TYPE_PNV8_PSI)
> +
> +typedef struct Pnv8Psi {
> +PnvPsi   parent;
> +
> +ICSState ics;
> +} Pnv8Psi;
> +
> +#define PNV_PSI_CLASS(klass) \
> + OBJECT_CLASS_CHECK(PnvPsiClass, (klass), TYPE_PNV_PSI)
> +#define PNV_PSI_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(PnvPsiClass, (obj), TYPE_PNV_PSI)
> +
> +typedef struct PnvPsiClass {
> +SysBusDeviceClass parent_class;
> +
> +int chip_type;
> +uint32_t xscom_pcba;
> +uint32_t xscom_size;
> +uint64_t bar_mask;
> +
> +void (*irq_set)(PnvPsi *psi, int, bool state);
> +} PnvPsiClass;
> +
>  /* The PSI and FSP interrupts are muxed on the same IRQ number */
>  typedef enum PnvPsiIrq {
>  PSIHB_IRQ_PSI, /* internal use only */
> @@ -61,6 +86,6 @@ typedef enum PnvPsiIrq {
>  
>  #define PSI_NUM_INTERRUPTS 6
>  
> -extern void pnv_psi_irq_set(PnvPsi *psi, PnvPsiIrq irq, bool state);
> +void pnv_psi_irq_set(PnvPsi *psi, int irq, bool state);
>  
>  #endif /* _PPC_PNV_PSI_H */
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 7660eaa22cf9..5bb2332f167a 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -788,7 +788,7 @@ static void pnv_chip_power8_instance_init(Object *obj)
>  Pnv8Chip *chip8 = PNV8_CHIP(obj);
>  
>  object_initialize_child(obj, "psi",  >psi, sizeof(chip8->psi),
> -TYPE_PNV_PSI, _abort, NULL);
> +TYPE_PNV8_PSI, _abort, NULL);
>  object_property_add_const_link(OBJECT(>psi), "xics",
> OBJECT(qdev_get_machine()), _abort);
>  
> @@ -840,6 +840,7 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
> Error **errp)
>  PnvChipClass *pcc = PNV_CHIP_GET_CLASS(dev);
>  PnvChip *chip = PNV_CHIP(dev);
>  Pnv8Chip *chip8 = PNV8_CHIP(dev);
> +Pnv8Psi *psi8 = >psi;
>  Error *local_err = NULL;
>  
>  pcc->parent_realize(dev, _err);
> @@ -856,7 +857,8 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
> Error **errp)
>  error_propagate(errp, local_err);
>  return;
>  }
> -pnv_xscom_add_subregion(chip, PNV_XSCOM_PSIHB_BASE, 
> >psi.xscom_regs);
> +pnv_xscom_add_subregion(chip, PNV_XSCOM_PSIHB_BASE,
> +_PSI(psi8)->xscom_regs);
>  
>  /* Create LPC controller */
>  object_property_set_bool(OBJECT(>lpc), true, "realized",
> diff --git a/hw/ppc/pnv_psi.c b/hw/ppc/pnv_psi.c
> index e61861bfd3c6..067f733f1e4a 100644
> --- a/hw/ppc/pnv_psi.c
> +++ b/hw/ppc/pnv_psi.c
> @@ -118,10 +118,11 @@
>  
>  static void pnv_psi_set_bar(PnvPsi *psi, uint64_t bar)
>  {
> +PnvPsiClass *ppc = PNV_PSI_GET_CLASS(psi);
>  MemoryRegion *sysmem = get_system_memory();
>  uint64_t old = psi->regs[PSIHB_XSCOM_BAR];
>  
> -psi->regs[PSIHB_XSCOM_BAR] = bar & (PSIHB_BAR_MASK | PSIHB_BAR_EN);
> +psi->regs[PSIHB_XSCOM_BAR] = bar & (ppc->bar_mask | PSIHB_BAR_EN);
>  
>  /* Update MR, always remove it first */
>  if (old & PSIHB_BAR_EN) {
> @@ -130,7 +131,7 @@ static void pnv_psi_set_bar(PnvPsi *psi, uint64_t bar)
>  
>  /* Then add it back if needed */
>  if (bar & PSIHB_BAR_EN) {
> -uint64_t addr = bar & PSIHB_BAR_MASK;
> +uint64_t addr = bar & ppc->bar_mask;
>  memory_region_add_subregion(sysmem, addr, >regs_mr);
>  }
>  }
> @@ -154,7 +155,7 @@ static void pnv_psi_set_cr(PnvPsi *psi, 

Re: [Qemu-devel] [PATCH 0/2] mac: fix booting from hd device with -drive syntax

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 09:20:56PM +, Mark Cave-Ayland wrote:
> These two patches correct a mistake in the original FWPathProvider
> implementation for Old World and New World Macs whereby the alias name is
> used instead of the node name.
> 
> Signed-off-by: Mark Cave-Ayland 

Applied, thanks.

> 
> 
> Mark Cave-Ayland (2):
>   mac_oldworld: use node name instead of alias name for hd device in
> FWPathProvider
>   mac_newworld: use node name instead of alias name for hd device in
> FWPathProvider
> 
>  hw/ppc/mac_newworld.c | 4 ++--
>  hw/ppc/mac_oldworld.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 

-- 
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 v2 04/15] ppc/pnv: add a LPC Controller class model

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:37PM +0100, Cédric Le Goater wrote:
> It will ease the introduction of the LPC Controller model for POWER9.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: David Gibson 

Applied, thanks.

> ---
>  include/hw/ppc/pnv_lpc.h | 15 +++
>  hw/ppc/pnv.c |  2 +-
>  hw/ppc/pnv_lpc.c | 85 
>  3 files changed, 77 insertions(+), 25 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv_lpc.h b/include/hw/ppc/pnv_lpc.h
> index d657489b07ce..f3f24419b19a 100644
> --- a/include/hw/ppc/pnv_lpc.h
> +++ b/include/hw/ppc/pnv_lpc.h
> @@ -24,6 +24,8 @@
>  #define TYPE_PNV_LPC "pnv-lpc"
>  #define PNV_LPC(obj) \
>   OBJECT_CHECK(PnvLpcController, (obj), TYPE_PNV_LPC)
> +#define TYPE_PNV8_LPC TYPE_PNV_LPC "-POWER8"
> +#define PNV8_LPC(obj) OBJECT_CHECK(PnvLpcController, (obj), TYPE_PNV8_LPC)
>  
>  typedef struct PnvLpcController {
>  DeviceState parent;
> @@ -70,6 +72,19 @@ typedef struct PnvLpcController {
>  PnvPsi *psi;
>  } PnvLpcController;
>  
> +#define PNV_LPC_CLASS(klass) \
> + OBJECT_CLASS_CHECK(PnvLpcClass, (klass), TYPE_PNV_LPC)
> +#define PNV_LPC_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(PnvLpcClass, (obj), TYPE_PNV_LPC)
> +
> +typedef struct PnvLpcClass {
> +DeviceClass parent_class;
> +
> +int psi_irq;
> +
> +DeviceRealize parent_realize;
> +} PnvLpcClass;
> +
>  ISABus *pnv_lpc_isa_create(PnvLpcController *lpc, bool use_cpld, Error 
> **errp);
>  
>  #endif /* _PPC_PNV_LPC_H */
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 1cc454cbbc27..922e3ec48bb5 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -794,7 +794,7 @@ static void pnv_chip_power8_instance_init(Object *obj)
> OBJECT(qdev_get_machine()), _abort);
>  
>  object_initialize_child(obj, "lpc",  >lpc, sizeof(chip8->lpc),
> -TYPE_PNV_LPC, _abort, NULL);
> +TYPE_PNV8_LPC, _abort, NULL);
>  object_property_add_const_link(OBJECT(>lpc), "psi",
> OBJECT(>psi), _abort);
>  
> diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
> index 547be609cafe..3c509a30a0af 100644
> --- a/hw/ppc/pnv_lpc.c
> +++ b/hw/ppc/pnv_lpc.c
> @@ -245,6 +245,7 @@ static const MemoryRegionOps pnv_lpc_xscom_ops = {
>  static void pnv_lpc_eval_irqs(PnvLpcController *lpc)
>  {
>  bool lpc_to_opb_irq = false;
> +PnvLpcClass *plc = PNV_LPC_GET_CLASS(lpc);
>  
>  /* Update LPC controller to OPB line */
>  if (lpc->lpc_hc_irqser_ctrl & LPC_HC_IRQSER_EN) {
> @@ -267,7 +268,7 @@ static void pnv_lpc_eval_irqs(PnvLpcController *lpc)
>  lpc->opb_irq_stat |= lpc->opb_irq_input & lpc->opb_irq_mask;
>  
>  /* Reflect the interrupt */
> -pnv_psi_irq_set(lpc->psi, PSIHB_IRQ_LPC_I2C, lpc->opb_irq_stat != 0);
> +pnv_psi_irq_set(lpc->psi, plc->psi_irq, lpc->opb_irq_stat != 0);
>  }
>  
>  static uint64_t lpc_hc_read(void *opaque, hwaddr addr, unsigned size)
> @@ -419,11 +420,65 @@ static const MemoryRegionOps opb_master_ops = {
>  },
>  };
>  
> +static void pnv_lpc_power8_realize(DeviceState *dev, Error **errp)
> +{
> +PnvLpcController *lpc = PNV_LPC(dev);
> +PnvLpcClass *plc = PNV_LPC_GET_CLASS(dev);
> +Error *local_err = NULL;
> +
> +plc->parent_realize(dev, _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> +/* P8 uses a XSCOM region for LPC registers */
> +pnv_xscom_region_init(>xscom_regs, OBJECT(lpc),
> +  _lpc_xscom_ops, lpc, "xscom-lpc",
> +  PNV_XSCOM_LPC_SIZE);
> +}
> +
> +static void pnv_lpc_power8_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +PnvXScomInterfaceClass *xdc = PNV_XSCOM_INTERFACE_CLASS(klass);
> +PnvLpcClass *plc = PNV_LPC_CLASS(klass);
> +
> +dc->desc = "PowerNV LPC Controller POWER8";
> +
> +xdc->dt_xscom = pnv_lpc_dt_xscom;
> +
> +plc->psi_irq = PSIHB_IRQ_LPC_I2C;
> +
> +device_class_set_parent_realize(dc, pnv_lpc_power8_realize,
> +>parent_realize);
> +}
> +
> +static const TypeInfo pnv_lpc_power8_info = {
> +.name  = TYPE_PNV8_LPC,
> +.parent= TYPE_PNV_LPC,
> +.instance_size = sizeof(PnvLpcController),
> +.class_init= pnv_lpc_power8_class_init,
> +.interfaces = (InterfaceInfo[]) {
> +{ TYPE_PNV_XSCOM_INTERFACE },
> +{ }
> +}
> +};
> +
>  static void pnv_lpc_realize(DeviceState *dev, Error **errp)
>  {
>  PnvLpcController *lpc = PNV_LPC(dev);
>  Object *obj;
> -Error *error = NULL;
> +Error *local_err = NULL;
> +
> +obj = object_property_get_link(OBJECT(dev), "psi", _err);
> +if (!obj) {
> +error_propagate(errp, local_err);
> +error_prepend(errp, "required link 'psi' not found: ");
> +return;
> +}
> +/* The LPC controller needs PSI 

Re: [Qemu-devel] [PATCH v2 03/15] ppc/pnv: lpc: fix OPB address ranges

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 11:35:36PM +0100, Cédric Le Goater wrote:
> The PowerNV LPC Controller exposes different sets of registers for
> each of the functional units it encompasses, among which the OPB
> (On-Chip Peripheral Bus) Master and Arbitrer and the LPC HOST
> Controller.
> 
> The mapping addresses of each register range are correct but the sizes
> are too large. Fix the sizes and define the OPB Arbitrer range to fill
> the gap between the OPB Master registers and the LPC HOST Controller
> registers.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
> 
>  Changes in v2 :
> 
>   - wrote a commit log
> 
>  hw/ppc/pnv_lpc.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
> index 9b18ce55e391..547be609cafe 100644
> --- a/hw/ppc/pnv_lpc.c
> +++ b/hw/ppc/pnv_lpc.c
> @@ -89,10 +89,11 @@ enum {
>  #define LPC_FW_OPB_SIZE 0x1000
>  
>  #define LPC_OPB_REGS_OPB_ADDR   0xc001
> -#define LPC_OPB_REGS_OPB_SIZE   0x2000
> +#define LPC_OPB_REGS_OPB_SIZE   0x0060
> +#define LPC_OPB_REGS_OPBA_ADDR  0xc0011000
> +#define LPC_OPB_REGS_OPBA_SIZE  0x0008
>  #define LPC_HC_REGS_OPB_ADDR0xc0012000
> -#define LPC_HC_REGS_OPB_SIZE0x1000
> -
> +#define LPC_HC_REGS_OPB_SIZE0x0100
>  
>  static int pnv_lpc_dt_xscom(PnvXScomInterface *dev, void *fdt, int 
> xscom_offset)
>  {

-- 
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 qemu v4 1/3] spapr_iommu: Do not replay mappings from just created DMA window

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 04:05:16PM +1100, Alexey Kardashevskiy wrote:
> On sPAPR vfio_listener_region_add() is called in 2 situations:
> 1. a new listener is registered from vfio_connect_container();
> 2. a new IOMMU Memory Region is added from rtas_ibm_create_pe_dma_window().
> 
> In both cases vfio_listener_region_add() calls
> memory_region_iommu_replay() to notify newly registered IOMMU notifiers
> about existing mappings which is totally desirable for case 1.
> 
> However for case 2 it is nothing but noop as the window has just been
> created and has no valid mappings so replaying those does not do anything.
> It is barely noticeable with usual guests but if the window happens to be
> really big, such no-op replay might take minutes and trigger RCU stall
> warnings in the guest.
> 
> For example, a upcoming GPU RAM memory region mapped at 64TiB (right
> after SPAPR_PCI_LIMIT) causes a 64bit DMA window to be at least 128TiB
> which is (128<<40)/0x1=2.147.483.648 TCEs to replay.
> 
> This mitigates the problem by adding an "skipping_replay" flag to
> sPAPRTCETable and defining sPAPR own IOMMU MR replay() hook which does
> exactly the same thing as the generic one except it returns early if
> @skipping_replay==true.
> 
> Another way of fixing this would be delaying replay till the very first
> H_PUT_TCE but this does not work if in-kernel H_PUT_TCE handler is
> enabled (a likely case).
> 
> When "ibm,create-pe-dma-window" is complete, the guest will map only
> required regions of the huge DMA window.
> 
> Signed-off-by: Alexey Kardashevskiy 

Applied, thanks.

> ---
> Changes:
> v4:
> * more explaining in the commit log and comments
> ---
>  include/hw/ppc/spapr.h  |  1 +
>  hw/ppc/spapr_iommu.c| 31 +++
>  hw/ppc/spapr_rtas_ddw.c | 10 ++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index ff1bd6061540..2b368e6677c5 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -723,6 +723,7 @@ struct sPAPRTCETable {
>  uint64_t *mig_table;
>  bool bypass;
>  bool need_vfio;
> +bool skipping_replay;
>  int fd;
>  MemoryRegion root;
>  IOMMUMemoryRegion iommu;
> diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
> index 37e98f93214d..8f231799b29b 100644
> --- a/hw/ppc/spapr_iommu.c
> +++ b/hw/ppc/spapr_iommu.c
> @@ -141,6 +141,36 @@ static IOMMUTLBEntry 
> spapr_tce_translate_iommu(IOMMUMemoryRegion *iommu,
>  return ret;
>  }
>  
> +static void spapr_tce_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier *n)
> +{
> +MemoryRegion *mr = MEMORY_REGION(iommu_mr);
> +IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_GET_CLASS(iommu_mr);
> +hwaddr addr, granularity;
> +IOMMUTLBEntry iotlb;
> +sPAPRTCETable *tcet = container_of(iommu_mr, sPAPRTCETable, iommu);
> +
> +if (tcet->skipping_replay) {
> +return;
> +}
> +
> +granularity = memory_region_iommu_get_min_page_size(iommu_mr);
> +
> +for (addr = 0; addr < memory_region_size(mr); addr += granularity) {
> +iotlb = imrc->translate(iommu_mr, addr, IOMMU_NONE, n->iommu_idx);
> +if (iotlb.perm != IOMMU_NONE) {
> +n->notify(n, );
> +}
> +
> +/*
> + * if (2^64 - MR size) < granularity, it's possible to get an
> + * infinite loop here.  This should catch such a wraparound.
> + */
> +if ((addr + granularity) < addr) {
> +break;
> +}
> +}
> +}
> +
>  static int spapr_tce_table_pre_save(void *opaque)
>  {
>  sPAPRTCETable *tcet = SPAPR_TCE_TABLE(opaque);
> @@ -659,6 +689,7 @@ static void 
> spapr_iommu_memory_region_class_init(ObjectClass *klass, void *data)
>  IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_CLASS(klass);
>  
>  imrc->translate = spapr_tce_translate_iommu;
> +imrc->replay = spapr_tce_replay;
>  imrc->get_min_page_size = spapr_tce_get_min_page_size;
>  imrc->notify_flag_changed = spapr_tce_notify_flag_changed;
>  imrc->get_attr = spapr_tce_get_attr;
> diff --git a/hw/ppc/spapr_rtas_ddw.c b/hw/ppc/spapr_rtas_ddw.c
> index cb8a4103592e..cc9d1f5c1cc8 100644
> --- a/hw/ppc/spapr_rtas_ddw.c
> +++ b/hw/ppc/spapr_rtas_ddw.c
> @@ -171,8 +171,18 @@ static void rtas_ibm_create_pe_dma_window(PowerPCCPU 
> *cpu,
>  }
>  
>  win_addr = (windows == 0) ? sphb->dma_win_addr : sphb->dma64_win_addr;
> +/*
> + * We have just created a window, we know for the fact that it is empty,
> + * use a hack to avoid iterating over the table as it is quite possible
> + * to have billions of TCEs, all empty.
> + * Note that we cannot delay this to the first H_PUT_TCE as this hcall is
> + * mostly likely to be handled in KVM so QEMU just does not know if it
> + * happened.
> + */
> +tcet->skipping_replay = true;
>  spapr_tce_table_enable(tcet, page_shift, win_addr,
> 1ULL << (window_shift - 

Re: [Qemu-devel] [PATCH v2 3/7] target/ppc: move Vsr* macros from internal.h to cpu.h

2019-03-07 Thread David Gibson
On Thu, Mar 07, 2019 at 06:05:16PM +, Mark Cave-Ayland wrote:
> It isn't possible to include internal.h from cpu.h so move the Vsr* macros
> into cpu.h alongside the other VMX/VSX register access functions.
> 
> Signed-off-by: Mark Cave-Ayland 

Applied, thanks.

> ---
>  target/ppc/cpu.h  | 20 
>  target/ppc/internal.h | 19 ---
>  2 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 4a7df13c2d..d0580c6b6d 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -2563,6 +2563,26 @@ static inline bool lsw_reg_in_range(int start, int 
> nregs, int rx)
>  }
>  
>  /* Accessors for FP, VMX and VSX registers */
> +#if defined(HOST_WORDS_BIGENDIAN)
> +#define VsrB(i) u8[i]
> +#define VsrSB(i) s8[i]
> +#define VsrH(i) u16[i]
> +#define VsrSH(i) s16[i]
> +#define VsrW(i) u32[i]
> +#define VsrSW(i) s32[i]
> +#define VsrD(i) u64[i]
> +#define VsrSD(i) s64[i]
> +#else
> +#define VsrB(i) u8[15 - (i)]
> +#define VsrSB(i) s8[15 - (i)]
> +#define VsrH(i) u16[7 - (i)]
> +#define VsrSH(i) s16[7 - (i)]
> +#define VsrW(i) u32[3 - (i)]
> +#define VsrSW(i) s32[3 - (i)]
> +#define VsrD(i) u64[1 - (i)]
> +#define VsrSD(i) s64[1 - (i)]
> +#endif
> +
>  static inline int fpr_offset(int i)
>  {
>  return offsetof(CPUPPCState, vsr[i].u64[0]);
> diff --git a/target/ppc/internal.h b/target/ppc/internal.h
> index f26a71ffcf..3ebbdf4da4 100644
> --- a/target/ppc/internal.h
> +++ b/target/ppc/internal.h
> @@ -204,25 +204,6 @@ EXTRACT_HELPER(IMM8, 11, 8);
>  EXTRACT_HELPER(DCMX, 16, 7);
>  EXTRACT_HELPER_SPLIT_3(DCMX_XV, 5, 16, 0, 1, 2, 5, 1, 6, 6);
>  
> -#if defined(HOST_WORDS_BIGENDIAN)
> -#define VsrB(i) u8[i]
> -#define VsrSB(i) s8[i]
> -#define VsrH(i) u16[i]
> -#define VsrSH(i) s16[i]
> -#define VsrW(i) u32[i]
> -#define VsrSW(i) s32[i]
> -#define VsrD(i) u64[i]
> -#define VsrSD(i) s64[i]
> -#else
> -#define VsrB(i) u8[15 - (i)]
> -#define VsrSB(i) s8[15 - (i)]
> -#define VsrH(i) u16[7 - (i)]
> -#define VsrSH(i) s16[7 - (i)]
> -#define VsrW(i) u32[3 - (i)]
> -#define VsrSW(i) s32[3 - (i)]
> -#define VsrD(i) u64[1 - (i)]
> -#define VsrSD(i) s64[1 - (i)]
> -#endif
>  static inline void getVSR(int n, ppc_vsr_t *vsr, CPUPPCState *env)
>  {
>  vsr->VsrD(0) = env->vsr[n].u64[0];

-- 
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] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess

2019-03-07 Thread John G Johnson



> On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi  wrote:
> 
> On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote:
>> On Thu, Mar 07, 2019 at 02:26:09PM +, Stefan Hajnoczi wrote:
>>> On Wed, Mar 06, 2019 at 11:22:53PM -0800, elena.ufimts...@oracle.com wrote:
 diff --git a/docs/devel/qemu-multiprocess.txt 
 b/docs/devel/qemu-multiprocess.txt
 new file mode 100644
 index 000..e29c6c8
 --- /dev/null
 +++ b/docs/devel/qemu-multiprocess.txt
>>> 
>>> Thanks for this document and the interesting work that you are doing.
>>> I'd like to discuss the security advantages gained by disaggregating
>>> QEMU in more detail.
>>> 
>>> The security model for VMs managed by libvirt (most production x86, ppc,
>>> s390 guests) is that the QEMU process is untrusted and only has access
>>> to resources belonging to the guest.  SELinux is used to restrict the
>>> process from accessing other files, processes, etc on the host.
>> 
>> NB it doesn't have to be SELinux. Libvirt also supports AppArmor and
>> can even do isolation with traditional DAC by putting each QEMU under
>> a distinct UID/GID and having libvirtd set ownership on resources each
>> VM is permitted to use.
>> 
>>> QEMU does not hold privileged resources that must be kept away from the
>>> guest.  An escaped guest can access its image file, tap file descriptor,
>>> etc but they are the same resources it could already access via device
>>> emulation.
>>> 
>>> Can you give specific examples of how disaggregation improves security?
> 
> Elena & collaborators: Dan has posted some ideas but please share yours
> so the security benefits of this patch series can be better understood.
> 

Dan covered the main point.  The security regime we use (selinux)
constrains the actions of processes on objects, so having multiple processes
allows us to apply more fine-grained policies.


>> I guess one obvious answer is that the existing security mechanisms like
>> SELinux/ApArmor/DAC can be made to work in a more fine grained manner if
>> there are distinct processes. This would allow for a more useful seccomp
>> filter to better protect against secondary kernel exploits should QEMU
>> itself be exploited, if we can protect individual components.
> 
> Fine-grained sandboxing is possible in theory but tedious in practice.
> From what I can tell this patch series doesn't implement any sandboxing
> for child processes.
> 

The policies aren’t in QEMU, but in the selinux config files.
They would say, for example, that when the QEMU process exec()s the
disk emulation process, the process security context type transitions
to a new type.  This type would have permission to access the VM image
objects, whereas the QEMU process type (and any other device emulation
process types) cannot access them.

If you wanted to use DAC, you could do the something similar by
making the disk emulation executable setuid to a UID than can access
VM image files.

In either case, the policies and permissions are set up before
libvirt even runs, so it doesn’t need to be aware of them.


> There must be a convenient way to get fine-grained sandboxing for
> disaggregated devices.  In other words, it shouldn't be left as an
> exercise to device process authors.
> 

We can add some MAC or DAC suggestions in the documentation.


> How to do this in practice must be clear from the beginning if
> fine-grained sandboxing is the main selling point.
> 
> Some details to start the discussion:
> 
> * How will fine-grained SELinux/AppArmor/DAC policies be configured for
>   each process?  I guess this requires root, so does libvirt need to
>   know about each process?
> 

The polices would apply to process security context types (or
UIDs in a DAC regime), so I would not expect libvirt to be aware of them.


> * We need to make sure that processes cannot send signals to each
>   other, ptrace, interfere in /proc/$PID, etc.  How will this be done?
> 

Any process type restrictions would be enforced by selinux.


> * Were you planning to use any other sandboxing mechanisms
>   (namespaces?)?  How will they be set up if the device processed is
>   forked/executed by an unprivileged QEMU?
> 

All of the QEMU-related process related to a single VM will run
in the same container, but the container is created, along with it selinux
policies, before libvirt is run.


>> Not everything is protected by MAC/DAC. For example network based disks
>> typically have a username + password for accessing the remote storage
>> server. Best practice would be a distinct username for every QEMU process
>> such that each can only access its own storage, but I don't know of any
>> app which does that. So ability to split off backends into separate
>> processes could limit exposure of information that is not otherwise
>> protected by current protection models.
> 
> If the disaggregated disk process with a global username + password is
> 

Re: [Qemu-devel] [PATCH 0/5] QEMU VFIO live migration

2019-03-07 Thread Tian, Kevin
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, March 8, 2019 1:44 AM
> > >
> > > > This kind of data needs to be saved / loaded in pre-copy and
> > > > stop-and-copy phase.
> > > > The data of device memory is held in device memory region.
> > > > Size of devie memory is usually larger than that of device
> > > > memory region. qemu needs to save/load it in chunks of size of
> > > > device memory region.
> > > > Not all device has device memory. Like IGD only uses system
> memory.
> > >
> > > It seems a little gratuitous to me that this is a separate region or
> > > that this data is handled separately.  All of this data is opaque to
> > > QEMU, so why do we need to separate it?
> > hi Alex,
> > as the device state interfaces are provided by kernel, it is expected to
> > meet as general needs as possible. So, do you think there are such use
> > cases from user space that user space knows well of the device, and
> > it wants kernel to return desired data back to it.
> > E.g. It just wants to get whole device config data including all mmios,
> > page tables, pci config data...
> > or, It just wants to get current device memory snapshot, not including any
> > dirty data.
> > Or, It just needs the dirty pages in device memory or system memory.
> > With all this accurate query, quite a lot of useful features can be
> > developped in user space.
> >
> > If all of this data is opaque to user app, seems the only use case is
> > for live migration.
> 
> I can certainly appreciate a more versatile interface, but I think
> we're also trying to create the most simple interface we can, with the
> primary target being live migration.  As soon as we start defining this
> type of device memory and that type of device memory, we're going to
> have another device come along that needs yet another because they have
> a slightly different requirement.  Even without that, we're going to
> have vendor drivers implement it differently, so what works for one
> device for a more targeted approach may not work for all devices.  Can
> you enumerate some specific examples of the use cases you imagine your
> design to enable?
> 

Do we want to consider an use case where user space would like to
selectively introspect a portion of the device state (including implicit 
state which are not available through PCI regions), and may ask for
capability of direct mapping of selected portion for scanning (e.g.
device memory) instead of always turning on dirty logging on all
device state?

Thanks
Kevin



[Qemu-devel] [PATCH v2 05/15] ppc/pnv: add a 'dt_isa_nodename' to the chip

2019-03-07 Thread Cédric Le Goater
The ISA bus has a different DT nodename on POWER9. Compute the name
when the PnvChip is realized, that is before it is used by the machine
to populate the device tree with the ISA devices.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/pnv.h |  2 ++
 hw/ppc/pnv.c | 18 +-
 2 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 8d80cb34eebb..c81f157f41a9 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -58,6 +58,8 @@ typedef struct PnvChip {
 MemoryRegion xscom_mmio;
 MemoryRegion xscom;
 AddressSpace xscom_as;
+
+gchar*dt_isa_nodename;
 } PnvChip;
 
 #define TYPE_PNV8_CHIP "pnv8-chip"
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 922e3ec48bb5..6625562d276d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -417,24 +417,12 @@ static int pnv_dt_isa_device(DeviceState *dev, void 
*opaque)
 return 0;
 }
 
-static int pnv_chip_isa_offset(PnvChip *chip, void *fdt)
-{
-char *name;
-int offset;
-
-name = g_strdup_printf("/xscom@%" PRIx64 "/isa@%x",
-   (uint64_t) PNV_XSCOM_BASE(chip), 
PNV_XSCOM_LPC_BASE);
-offset = fdt_path_offset(fdt, name);
-g_free(name);
-return offset;
-}
-
 /* The default LPC bus of a multichip system is on chip 0. It's
  * recognized by the firmware (skiboot) using a "primary" property.
  */
 static void pnv_dt_isa(PnvMachineState *pnv, void *fdt)
 {
-int isa_offset = pnv_chip_isa_offset(pnv->chips[0], fdt);
+int isa_offset = fdt_path_offset(fdt, pnv->chips[0]->dt_isa_nodename);
 ForeachPopulateArgs args = {
 .fdt = fdt,
 .offset = isa_offset,
@@ -866,6 +854,10 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
Error **errp)
  _fatal);
 pnv_xscom_add_subregion(chip, PNV_XSCOM_LPC_BASE, >lpc.xscom_regs);
 
+chip->dt_isa_nodename = g_strdup_printf("/xscom@%" PRIx64 "/isa@%x",
+(uint64_t) PNV_XSCOM_BASE(chip),
+PNV_XSCOM_LPC_BASE);
+
 /* Interrupt Management Area. This is the memory region holding
  * all the Interrupt Control Presenter (ICP) registers */
 pnv_chip_icp_realize(chip8, _err);
-- 
2.20.1




[Qemu-devel] [PATCH v2 03/15] ppc/pnv: lpc: fix OPB address ranges

2019-03-07 Thread Cédric Le Goater
The PowerNV LPC Controller exposes different sets of registers for
each of the functional units it encompasses, among which the OPB
(On-Chip Peripheral Bus) Master and Arbitrer and the LPC HOST
Controller.

The mapping addresses of each register range are correct but the sizes
are too large. Fix the sizes and define the OPB Arbitrer range to fill
the gap between the OPB Master registers and the LPC HOST Controller
registers.

Signed-off-by: Cédric Le Goater 
---

 Changes in v2 :

  - wrote a commit log

 hw/ppc/pnv_lpc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
index 9b18ce55e391..547be609cafe 100644
--- a/hw/ppc/pnv_lpc.c
+++ b/hw/ppc/pnv_lpc.c
@@ -89,10 +89,11 @@ enum {
 #define LPC_FW_OPB_SIZE 0x1000
 
 #define LPC_OPB_REGS_OPB_ADDR   0xc001
-#define LPC_OPB_REGS_OPB_SIZE   0x2000
+#define LPC_OPB_REGS_OPB_SIZE   0x0060
+#define LPC_OPB_REGS_OPBA_ADDR  0xc0011000
+#define LPC_OPB_REGS_OPBA_SIZE  0x0008
 #define LPC_HC_REGS_OPB_ADDR0xc0012000
-#define LPC_HC_REGS_OPB_SIZE0x1000
-
+#define LPC_HC_REGS_OPB_SIZE0x0100
 
 static int pnv_lpc_dt_xscom(PnvXScomInterface *dev, void *fdt, int 
xscom_offset)
 {
-- 
2.20.1




[Qemu-devel] [PATCH v2 14/15] ppc/pnv: add a "ibm, opal/power-mgt" device tree node on POWER9

2019-03-07 Thread Cédric Le Goater
Activate only stop0 and stop1 levels. We should not need more levels
when under QEMU.

Signed-off-by: Cédric Le Goater 
---
 hw/ppc/pnv.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index e68d419203e8..8be4d4cbf785 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -438,6 +438,16 @@ static void pnv_dt_isa(PnvMachineState *pnv, void *fdt)
);
 }
 
+static void pnv_dt_power_mgt(void *fdt)
+{
+int off;
+
+off = fdt_add_subnode(fdt, 0, "ibm,opal");
+off = fdt_add_subnode(fdt, off, "power-mgt");
+
+_FDT(fdt_setprop_cell(fdt, off, "ibm,enabled-stop-levels", 0xc000));
+}
+
 static void *pnv_dt_create(MachineState *machine)
 {
 const char plat_compat[] = "qemu,powernv\0ibm,powernv";
@@ -493,6 +503,11 @@ static void *pnv_dt_create(MachineState *machine)
 pnv_dt_bmc_sensors(pnv->bmc, fdt);
 }
 
+/* Create an extra node for power management on Power9 */
+if (pnv_is_power9(pnv)) {
+pnv_dt_power_mgt(fdt);
+}
+
 return fdt;
 }
 
-- 
2.20.1




[Qemu-devel] [PATCH v2 08/15] ppc/pnv: add a OCC model class

2019-03-07 Thread Cédric Le Goater
To ease the introduction of the OCC model for POWER9, provide a new
class attributes to define XSCOM operations per CPU family and a PSI
IRQ number.

Signed-off-by: Cédric Le Goater 
Reviewed-by: David Gibson 
---

 Changes in v2:

 - new attributes to define XSCOM operations per CPU family and a PSI
   IRQ number.

 include/hw/ppc/pnv_occ.h | 15 +++
 hw/ppc/pnv.c |  2 +-
 hw/ppc/pnv_occ.c | 55 +++-
 3 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/include/hw/ppc/pnv_occ.h b/include/hw/ppc/pnv_occ.h
index 82f299dc76ff..dab5a05f8e99 100644
--- a/include/hw/ppc/pnv_occ.h
+++ b/include/hw/ppc/pnv_occ.h
@@ -23,6 +23,8 @@
 
 #define TYPE_PNV_OCC "pnv-occ"
 #define PNV_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV_OCC)
+#define TYPE_PNV8_OCC TYPE_PNV_OCC "-POWER8"
+#define PNV8_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV8_OCC)
 
 typedef struct PnvOCC {
 DeviceState xd;
@@ -35,4 +37,17 @@ typedef struct PnvOCC {
 MemoryRegion xscom_regs;
 } PnvOCC;
 
+#define PNV_OCC_CLASS(klass) \
+ OBJECT_CLASS_CHECK(PnvOCCClass, (klass), TYPE_PNV_OCC)
+#define PNV_OCC_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(PnvOCCClass, (obj), TYPE_PNV_OCC)
+
+typedef struct PnvOCCClass {
+DeviceClass parent_class;
+
+int xscom_size;
+const MemoryRegionOps *xscom_ops;
+int psi_irq;
+} PnvOCCClass;
+
 #endif /* _PPC_PNV_OCC_H */
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 918fae057b5c..6ae9ce679505 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -790,7 +790,7 @@ static void pnv_chip_power8_instance_init(Object *obj)
OBJECT(>psi), _abort);
 
 object_initialize_child(obj, "occ",  >occ, sizeof(chip8->occ),
-TYPE_PNV_OCC, _abort, NULL);
+TYPE_PNV8_OCC, _abort, NULL);
 object_property_add_const_link(OBJECT(>occ), "psi",
OBJECT(>psi), _abort);
 }
diff --git a/hw/ppc/pnv_occ.c b/hw/ppc/pnv_occ.c
index 04880f26d612..ea725647c988 100644
--- a/hw/ppc/pnv_occ.c
+++ b/hw/ppc/pnv_occ.c
@@ -34,15 +34,17 @@
 static void pnv_occ_set_misc(PnvOCC *occ, uint64_t val)
 {
 bool irq_state;
+PnvOCCClass *poc = PNV_OCC_GET_CLASS(occ);
 
 val &= 0xull;
 
 occ->occmisc = val;
 irq_state = !!(val >> 63);
-pnv_psi_irq_set(occ->psi, PSIHB_IRQ_OCC, irq_state);
+pnv_psi_irq_set(occ->psi, poc->psi_irq, irq_state);
 }
 
-static uint64_t pnv_occ_xscom_read(void *opaque, hwaddr addr, unsigned size)
+static uint64_t pnv_occ_power8_xscom_read(void *opaque, hwaddr addr,
+  unsigned size)
 {
 PnvOCC *occ = PNV_OCC(opaque);
 uint32_t offset = addr >> 3;
@@ -54,13 +56,13 @@ static uint64_t pnv_occ_xscom_read(void *opaque, hwaddr 
addr, unsigned size)
 break;
 default:
 qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
-  HWADDR_PRIx "\n", addr);
+  HWADDR_PRIx "\n", addr >> 3);
 }
 return val;
 }
 
-static void pnv_occ_xscom_write(void *opaque, hwaddr addr,
-uint64_t val, unsigned size)
+static void pnv_occ_power8_xscom_write(void *opaque, hwaddr addr,
+   uint64_t val, unsigned size)
 {
 PnvOCC *occ = PNV_OCC(opaque);
 uint32_t offset = addr >> 3;
@@ -77,13 +79,13 @@ static void pnv_occ_xscom_write(void *opaque, hwaddr addr,
 break;
 default:
 qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
-  HWADDR_PRIx "\n", addr);
+  HWADDR_PRIx "\n", addr >> 3);
 }
 }
 
-static const MemoryRegionOps pnv_occ_xscom_ops = {
-.read = pnv_occ_xscom_read,
-.write = pnv_occ_xscom_write,
+static const MemoryRegionOps pnv_occ_power8_xscom_ops = {
+.read = pnv_occ_power8_xscom_read,
+.write = pnv_occ_power8_xscom_write,
 .valid.min_access_size = 8,
 .valid.max_access_size = 8,
 .impl.min_access_size = 8,
@@ -91,27 +93,42 @@ static const MemoryRegionOps pnv_occ_xscom_ops = {
 .endianness = DEVICE_BIG_ENDIAN,
 };
 
+static void pnv_occ_power8_class_init(ObjectClass *klass, void *data)
+{
+PnvOCCClass *poc = PNV_OCC_CLASS(klass);
+
+poc->xscom_size = PNV_XSCOM_OCC_SIZE;
+poc->xscom_ops = _occ_power8_xscom_ops;
+poc->psi_irq = PSIHB_IRQ_OCC;
+}
+
+static const TypeInfo pnv_occ_power8_type_info = {
+.name  = TYPE_PNV8_OCC,
+.parent= TYPE_PNV_OCC,
+.instance_size = sizeof(PnvOCC),
+.class_init= pnv_occ_power8_class_init,
+};
 
 static void pnv_occ_realize(DeviceState *dev, Error **errp)
 {
 PnvOCC *occ = PNV_OCC(dev);
+PnvOCCClass *poc = PNV_OCC_GET_CLASS(occ);
 Object *obj;
-Error *error = NULL;
+Error *local_err = NULL;
 
 occ->occmisc = 0;
 
-/* get PSI object from chip */
-obj = object_property_get_link(OBJECT(dev), "psi", );
+

[Qemu-devel] [PATCH v2 12/15] ppc/pnv: activate XSCOM tests for POWER9

2019-03-07 Thread Cédric Le Goater
We now have enough support to let the XSCOM test run on POWER9.

Signed-off-by: Cédric Le Goater 
---
 tests/pnv-xscom-test.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
index 974f8da5b240..63d464048d53 100644
--- a/tests/pnv-xscom-test.c
+++ b/tests/pnv-xscom-test.c
@@ -39,7 +39,6 @@ static const PnvChip pnv_chips[] = {
 .cfam_id= 0x120d30498000ull,
 .first_core = 0x1,
 },
-#if 0 /* POWER9 support is not ready yet */
 {
 .chip_type  = PNV_CHIP_POWER9,
 .cpu_model  = "POWER9",
@@ -47,7 +46,6 @@ static const PnvChip pnv_chips[] = {
 .cfam_id= 0x220d10498000ull,
 .first_core = 0x0,
 },
-#endif
 };
 
 static uint64_t pnv_xscom_addr(const PnvChip *chip, uint32_t pcba)
-- 
2.20.1




[Qemu-devel] [PATCH v2 00/15] ppc: add POWER9 support to the PowerNV platform

2019-03-07 Thread Cédric Le Goater
Hello,

Here is the second round of the patchset adding support for the POWER9
processor to the PowerNV machine. It includes POWER9 models for the
PSI host bridge, the LPC controller, and a minimalist OCC, some
extensions of the CPU core model to support POWER9 XSCOM addresses and
a new PnvQuad model controlling the power management state of group of
four cores on a POWER9 processor.

It should bring the POWER9 PowerNV platform to the same level as
POWER8, that is without PHBs.

A new skiboot image is not provided yet because I would like first to
have a tagged version of skiboot including the recent changes removing
support for DD1. Will come later.

Hopefully, this is good enough for QEMU 4.0.

Thanks,

C.

Changes in v2 :

 - introduced Pnv8Psi (XICS) and Pnv9Psi (XIVE) models
 - wrote a commit log for the changes in the LPC register ranges
 - added a 'dt_isa_nodename' to the chip
 - added new attributes to define XSCOM operations per CPU family and 
   a PSI IRQ number in the OCC class model
 - added a new attribute to define XSCOM operations per CPU family
   in the CPU core class model

Changes in v1 (since PnvXive was last sent) :

 - fixed compilation on clang (forward declarations)
 
 - simplified the hardwiring of the Physical CAM line. removed the
   'hw-cam' property. 
 - removed 'hwaddr offset' from the get_tctx() XiveRouter handler. It
   was a misunderstanding of the PC_THREAD_EN_REGx registers.
 - changed the CPU machine_data presenter type to 'Object *' to accept
   XiveTCTX
 - introduced a new dt_populate() operation to the chip model
 - introduced a new pic_print_info() operation to the chip model
 - removed 'chip_id' from PnvXive.
 - removed 'nr_irqs' and 'nr_ends' from PnvXive. Values are now
   calculated from the VST settings done by FW.   
 - removed 'type' field from the XiveVstInfo struct describing the VSTs
 - simplified pnv_xive_get_ic() grabbing a remote IC
 - introduced a pnv_xive_vst_size() helper computing the size of a VST
   table, direct or indirect. Used to computed the number of virtual
   structures entries provisioned by FW.
 - reworked pnv_xive_vst_addr_*() helpers. Fixed a bug when multiple
   pages are in use.
 - took into account the word_number when doing stores of the virtual
   structures.
 - the IPI and the END sub memory regions of the VC BAR are now
   resized and mapped when the EDT is configured, depending on how the
   VC region was segmented.
 - the XiveSource and the XiveENDSource memory regions are now resized
   and mapped when the VST are configured, depending on how much
   virtual structures entries were provisioned by FW.
 - removed PC_GCONF_CHIPID_OVR handling. Was for debug according to HW
   designers. xive->chip->chip_id is now used as the block id when
   needed.
 - reworked pic_print_info() to use the number of virtual structures
   entries provisioned by FW.

What has not changed (since PnvXive was sent) :

 - GETFIELD/SETFIELD macros. It would break the compatibility with
   skiboot in the register definitions. Still needs some thinking to
   find a common ground. P10 material for QEMU and skiboot probably.
 - The HW interface of XIVE is still bound to the register array. P10
   support will determine which is the best approach.

Cédric Le Goater (15):
  ppc/pnv: add a PSI bridge class model
  ppc/pnv: add a PSI bridge model for POWER9
  ppc/pnv: lpc: fix OPB address ranges
  ppc/pnv: add a LPC Controller class model
  ppc/pnv: add a 'dt_isa_nodename' to the chip
  ppc/pnv: add a LPC Controller model for POWER9
  ppc/pnv: add SerIRQ routing registers
  ppc/pnv: add a OCC model class
  ppc/pnv: add a OCC model for POWER9
  ppc/pnv: extend XSCOM core support for POWER9
  ppc/pnv: POWER9 XSCOM quad support
  ppc/pnv: activate XSCOM tests for POWER9
  ppc/pnv: add more dummy XSCOM addresses
  ppc/pnv: add a "ibm,opal/power-mgt" device tree node on POWER9
  target/ppc: add HV support for POWER9

 include/hw/ppc/pnv.h|  19 +-
 include/hw/ppc/pnv_core.h   |  12 +
 include/hw/ppc/pnv_lpc.h|  26 ++
 include/hw/ppc/pnv_occ.h|  17 ++
 include/hw/ppc/pnv_psi.h|  59 -
 include/hw/ppc/pnv_xscom.h  |  18 +-
 hw/ppc/pnv.c| 134 +--
 hw/ppc/pnv_core.c   | 187 ++-
 hw/ppc/pnv_lpc.c| 306 +---
 hw/ppc/pnv_occ.c| 127 --
 hw/ppc/pnv_psi.c| 404 ++--
 hw/ppc/pnv_xscom.c  |  33 ++-
 target/ppc/translate_init.inc.c |   3 +-
 tests/pnv-xscom-test.c  |   2 -
 14 files changed, 1231 insertions(+), 116 deletions(-)

-- 
2.20.1




[Qemu-devel] [PATCH v2 10/15] ppc/pnv: extend XSCOM core support for POWER9

2019-03-07 Thread Cédric Le Goater
Provide a new class attribute to define XSCOM operations per CPU
family and add a couple of XSCOM addresses controlling the power
management states of the core on POWER9.

Signed-off-by: Cédric Le Goater 
---

 Changes in v2 :

 - new class attribute to define XSCOM operations per CPU family

 include/hw/ppc/pnv_core.h |   2 +
 hw/ppc/pnv_core.c | 100 +-
 2 files changed, 89 insertions(+), 13 deletions(-)

diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index 6874bb847a01..cbe9ad36f32c 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -42,6 +42,8 @@ typedef struct PnvCore {
 
 typedef struct PnvCoreClass {
 DeviceClass parent_class;
+
+const MemoryRegionOps *xscom_ops;
 } PnvCoreClass;
 
 #define PNV_CORE_TYPE_SUFFIX "-" TYPE_PNV_CORE
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 38179cdc53dc..171474e0805c 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -60,8 +60,8 @@ static void pnv_cpu_reset(void *opaque)
 #define PNV_XSCOM_EX_DTS_RESULT0 0x5
 #define PNV_XSCOM_EX_DTS_RESULT1 0x50001
 
-static uint64_t pnv_core_xscom_read(void *opaque, hwaddr addr,
-unsigned int width)
+static uint64_t pnv_core_power8_xscom_read(void *opaque, hwaddr addr,
+   unsigned int width)
 {
 uint32_t offset = addr >> 3;
 uint64_t val = 0;
@@ -82,16 +82,74 @@ static uint64_t pnv_core_xscom_read(void *opaque, hwaddr 
addr,
 return val;
 }
 
-static void pnv_core_xscom_write(void *opaque, hwaddr addr, uint64_t val,
- unsigned int width)
+static void pnv_core_power8_xscom_write(void *opaque, hwaddr addr, uint64_t 
val,
+unsigned int width)
 {
 qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx "\n",
   addr);
 }
 
-static const MemoryRegionOps pnv_core_xscom_ops = {
-.read = pnv_core_xscom_read,
-.write = pnv_core_xscom_write,
+static const MemoryRegionOps pnv_core_power8_xscom_ops = {
+.read = pnv_core_power8_xscom_read,
+.write = pnv_core_power8_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness = DEVICE_BIG_ENDIAN,
+};
+
+
+/*
+ * POWER9 core controls
+ */
+#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP 0xf010d
+#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR 0xf010a
+
+static uint64_t pnv_core_power9_xscom_read(void *opaque, hwaddr addr,
+   unsigned int width)
+{
+uint32_t offset = addr >> 3;
+uint64_t val = 0;
+
+/* The result should be 38 C */
+switch (offset) {
+case PNV_XSCOM_EX_DTS_RESULT0:
+val = 0x26f024f023full;
+break;
+case PNV_XSCOM_EX_DTS_RESULT1:
+val = 0x24full;
+break;
+case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP:
+case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
+val = 0x0;
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
+  addr);
+}
+
+return val;
+}
+
+static void pnv_core_power9_xscom_write(void *opaque, hwaddr addr, uint64_t 
val,
+unsigned int width)
+{
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP:
+case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx 
"\n",
+  addr);
+}
+}
+
+static const MemoryRegionOps pnv_core_power9_xscom_ops = {
+.read = pnv_core_power9_xscom_read,
+.write = pnv_core_power9_xscom_write,
 .valid.min_access_size = 8,
 .valid.max_access_size = 8,
 .impl.min_access_size = 8,
@@ -138,6 +196,7 @@ static void pnv_realize_vcpu(PowerPCCPU *cpu, PnvChip 
*chip, Error **errp)
 static void pnv_core_realize(DeviceState *dev, Error **errp)
 {
 PnvCore *pc = PNV_CORE(OBJECT(dev));
+PnvCoreClass *pcc = PNV_CORE_GET_CLASS(pc);
 CPUCore *cc = CPU_CORE(OBJECT(dev));
 const char *typename = pnv_core_cpu_typename(pc);
 Error *local_err = NULL;
@@ -180,7 +239,7 @@ static void pnv_core_realize(DeviceState *dev, Error **errp)
 }
 
 snprintf(name, sizeof(name), "xscom-core.%d", cc->core_id);
-pnv_xscom_region_init(>xscom_regs, OBJECT(dev), _core_xscom_ops,
+pnv_xscom_region_init(>xscom_regs, OBJECT(dev), pcc->xscom_ops,
   pc, name, PNV_XSCOM_EX_SIZE);
 return;
 
@@ -222,6 +281,20 @@ static Property pnv_core_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static void pnv_core_power8_class_init(ObjectClass *oc, void *data)
+{
+PnvCoreClass *pcc = PNV_CORE_CLASS(oc);
+
+pcc->xscom_ops = _core_power8_xscom_ops;
+}
+
+static void pnv_core_power9_class_init(ObjectClass 

[Qemu-devel] [PATCH v2 11/15] ppc/pnv: POWER9 XSCOM quad support

2019-03-07 Thread Cédric Le Goater
The POWER9 processor does not support per-core frequency control. The
cores are arranged in groups of four, along with their respective L2
and L3 caches, into a structure known as a Quad. The frequency must be
managed at the Quad level.

Provide a basic Quad model to fake the settings done by the firmware
on the Non-Cacheable Unit (NCU). Each core pair (EX) needs a special
BAR setting for the TIMA area of XIVE because it resides on the same
address on all chips.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/pnv.h   |  4 ++
 include/hw/ppc/pnv_core.h  | 10 +
 include/hw/ppc/pnv_xscom.h | 12 --
 hw/ppc/pnv.c   | 38 -
 hw/ppc/pnv_core.c  | 87 ++
 5 files changed, 146 insertions(+), 5 deletions(-)

diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 39888f9d52c1..e5b00d373ed2 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -26,6 +26,7 @@
 #include "hw/ppc/pnv_psi.h"
 #include "hw/ppc/pnv_occ.h"
 #include "hw/ppc/pnv_xive.h"
+#include "hw/ppc/pnv_core.h"
 
 #define TYPE_PNV_CHIP "pnv-chip"
 #define PNV_CHIP(obj) OBJECT_CHECK(PnvChip, (obj), TYPE_PNV_CHIP)
@@ -89,6 +90,9 @@ typedef struct Pnv9Chip {
 Pnv9Psi  psi;
 PnvLpcController lpc;
 PnvOCC   occ;
+
+uint32_t nr_quads;
+PnvQuad  *quads;
 } Pnv9Chip;
 
 typedef struct PnvChipClass {
diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index cbe9ad36f32c..50cdb2b35838 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -58,4 +58,14 @@ static inline PnvCPUState *pnv_cpu_state(PowerPCCPU *cpu)
 return (PnvCPUState *)cpu->machine_data;
 }
 
+#define TYPE_PNV_QUAD "powernv-cpu-quad"
+#define PNV_QUAD(obj) \
+OBJECT_CHECK(PnvQuad, (obj), TYPE_PNV_QUAD)
+
+typedef struct PnvQuad {
+DeviceState parent_obj;
+
+uint32_t id;
+MemoryRegion xscom_regs;
+} PnvQuad;
 #endif /* _PPC_PNV_CORE_H */
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 3292459fbb78..68dfae0dfe41 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -60,10 +60,6 @@ typedef struct PnvXScomInterfaceClass {
 (PNV_XSCOM_EX_CORE_BASE | ((uint64_t)(core) << 24))
 #define PNV_XSCOM_EX_SIZE 0x10
 
-#define PNV_XSCOM_P9_EC_BASE(core) \
-((uint64_t)(((core) & 0x1F) + 0x20) << 24)
-#define PNV_XSCOM_P9_EC_SIZE  0x10
-
 #define PNV_XSCOM_LPC_BASE0xb0020
 #define PNV_XSCOM_LPC_SIZE0x4
 
@@ -73,6 +69,14 @@ typedef struct PnvXScomInterfaceClass {
 #define PNV_XSCOM_OCC_BASE0x0066000
 #define PNV_XSCOM_OCC_SIZE0x6000
 
+#define PNV9_XSCOM_EC_BASE(core) \
+((uint64_t)(((core) & 0x1F) + 0x20) << 24)
+#define PNV9_XSCOM_EC_SIZE0x10
+
+#define PNV9_XSCOM_EQ_BASE(core) \
+((uint64_t)(((core) & 0x1C) + 0x40) << 22)
+#define PNV9_XSCOM_EQ_SIZE0x10
+
 #define PNV9_XSCOM_OCC_BASE   PNV_XSCOM_OCC_BASE
 #define PNV9_XSCOM_OCC_SIZE   0x8000
 
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 1559a733235b..e68d419203e8 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -963,6 +963,36 @@ static void pnv_chip_power9_instance_init(Object *obj)
OBJECT(>psi), _abort);
 }
 
+static void pnv_chip_quad_realize(Pnv9Chip *chip9, Error **errp)
+{
+PnvChip *chip = PNV_CHIP(chip9);
+const char *typename = pnv_chip_core_typename(chip);
+size_t typesize = object_type_get_instance_size(typename);
+int i;
+
+chip9->nr_quads = DIV_ROUND_UP(chip->nr_cores, 4);
+chip9->quads = g_new0(PnvQuad, chip9->nr_quads);
+
+for (i = 0; i < chip9->nr_quads; i++) {
+char eq_name[32];
+PnvQuad *eq = >quads[i];
+PnvCore *pnv_core = PNV_CORE(chip->cores + (i * 4) * typesize);
+int core_id = CPU_CORE(pnv_core)->core_id;
+
+object_initialize(eq, sizeof(*eq), TYPE_PNV_QUAD);
+snprintf(eq_name, sizeof(eq_name), "eq[%d]", core_id);
+
+object_property_add_child(OBJECT(chip), eq_name, OBJECT(eq),
+  _fatal);
+object_property_set_int(OBJECT(eq), core_id, "id", _fatal);
+object_property_set_bool(OBJECT(eq), true, "realized", _fatal);
+object_unref(OBJECT(eq));
+
+pnv_xscom_add_subregion(chip, PNV9_XSCOM_EQ_BASE(eq->id),
+>xscom_regs);
+}
+}
+
 static void pnv_chip_power9_realize(DeviceState *dev, Error **errp)
 {
 PnvChipClass *pcc = PNV_CHIP_GET_CLASS(dev);
@@ -977,6 +1007,12 @@ static void pnv_chip_power9_realize(DeviceState *dev, 
Error **errp)
 return;
 }
 
+pnv_chip_quad_realize(chip9, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
 /* XIVE interrupt controller (POWER9) */
 object_property_set_int(OBJECT(>xive), PNV9_XIVE_IC_BASE(chip),
 "ic-bar", _fatal);
@@ -1135,7 +1171,7 @@ static void 

[Qemu-devel] [PATCH v2 15/15] target/ppc: add HV support for POWER9

2019-03-07 Thread Cédric Le Goater
We now have enough support to boot a PowerNV machine with a POWER9
processor. Allow HV mode on POWER9.

Signed-off-by: Cédric Le Goater 
---
 target/ppc/translate_init.inc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c
index af70a3b78c9a..0bd555eb1913 100644
--- a/target/ppc/translate_init.inc.c
+++ b/target/ppc/translate_init.inc.c
@@ -8895,7 +8895,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
PPC_CACHE | PPC_CACHE_ICBI | PPC_CACHE_DCBZ |
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_MEM_TLBSYNC |
-   PPC_64B | PPC_64BX | PPC_ALTIVEC |
+   PPC_64B | PPC_64H | PPC_64BX | PPC_ALTIVEC |
PPC_SEGMENT_64B | PPC_SLBI |
PPC_POPCNTB | PPC_POPCNTWD |
PPC_CILDST;
@@ -8907,6 +8907,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
 PPC2_ISA205 | PPC2_ISA207S | PPC2_FP_CVT_S64 |
 PPC2_TM | PPC2_ISA300 | PPC2_PRCNTL;
 pcc->msr_mask = (1ull << MSR_SF) |
+(1ull << MSR_SHV) |
 (1ull << MSR_TM) |
 (1ull << MSR_VR) |
 (1ull << MSR_VSX) |
-- 
2.20.1




[Qemu-devel] [PATCH v2 09/15] ppc/pnv: add a OCC model for POWER9

2019-03-07 Thread Cédric Le Goater
The OCC on POWER9 is very similar to the one found on POWER8. Provide
the same routines with P9 values for the registers and IRQ number.

Signed-off-by: Cédric Le Goater 
---

 Changes in v2 :

 - made use of the new class attributes for POWER9

 include/hw/ppc/pnv.h   |  1 +
 include/hw/ppc/pnv_occ.h   |  2 ++
 include/hw/ppc/pnv_xscom.h |  3 ++
 hw/ppc/pnv.c   | 13 +++
 hw/ppc/pnv_occ.c   | 72 ++
 5 files changed, 91 insertions(+)

diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 1cd1ad622d0b..39888f9d52c1 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -88,6 +88,7 @@ typedef struct Pnv9Chip {
 PnvXive  xive;
 Pnv9Psi  psi;
 PnvLpcController lpc;
+PnvOCC   occ;
 } Pnv9Chip;
 
 typedef struct PnvChipClass {
diff --git a/include/hw/ppc/pnv_occ.h b/include/hw/ppc/pnv_occ.h
index dab5a05f8e99..d22b65a71abe 100644
--- a/include/hw/ppc/pnv_occ.h
+++ b/include/hw/ppc/pnv_occ.h
@@ -25,6 +25,8 @@
 #define PNV_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV_OCC)
 #define TYPE_PNV8_OCC TYPE_PNV_OCC "-POWER8"
 #define PNV8_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV8_OCC)
+#define TYPE_PNV9_OCC TYPE_PNV_OCC "-POWER9"
+#define PNV9_OCC(obj) OBJECT_CHECK(PnvOCC, (obj), TYPE_PNV9_OCC)
 
 typedef struct PnvOCC {
 DeviceState xd;
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 403a365ed274..3292459fbb78 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -73,6 +73,9 @@ typedef struct PnvXScomInterfaceClass {
 #define PNV_XSCOM_OCC_BASE0x0066000
 #define PNV_XSCOM_OCC_SIZE0x6000
 
+#define PNV9_XSCOM_OCC_BASE   PNV_XSCOM_OCC_BASE
+#define PNV9_XSCOM_OCC_SIZE   0x8000
+
 #define PNV9_XSCOM_PSIHB_BASE 0x5012900
 #define PNV9_XSCOM_PSIHB_SIZE 0x100
 
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 6ae9ce679505..1559a733235b 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -956,6 +956,11 @@ static void pnv_chip_power9_instance_init(Object *obj)
 TYPE_PNV9_LPC, _abort, NULL);
 object_property_add_const_link(OBJECT(>lpc), "psi",
OBJECT(>psi), _abort);
+
+object_initialize_child(obj, "occ",  >occ, sizeof(chip9->occ),
+TYPE_PNV9_OCC, _abort, NULL);
+object_property_add_const_link(OBJECT(>occ), "psi",
+   OBJECT(>psi), _abort);
 }
 
 static void pnv_chip_power9_realize(DeviceState *dev, Error **errp)
@@ -1012,6 +1017,14 @@ static void pnv_chip_power9_realize(DeviceState *dev, 
Error **errp)
 
 chip->dt_isa_nodename = g_strdup_printf("/lpcm-opb@%" PRIx64 "/lpc@0",
 (uint64_t) PNV9_LPCM_BASE(chip));
+
+/* Create the simplified OCC model */
+object_property_set_bool(OBJECT(>occ), true, "realized", 
_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+pnv_xscom_add_subregion(chip, PNV9_XSCOM_OCC_BASE, >occ.xscom_regs);
 }
 
 static void pnv_chip_power9_class_init(ObjectClass *klass, void *data)
diff --git a/hw/ppc/pnv_occ.c b/hw/ppc/pnv_occ.c
index ea725647c988..fdd9296e1bc7 100644
--- a/hw/ppc/pnv_occ.c
+++ b/hw/ppc/pnv_occ.c
@@ -109,6 +109,77 @@ static const TypeInfo pnv_occ_power8_type_info = {
 .class_init= pnv_occ_power8_class_init,
 };
 
+#define P9_OCB_OCI_OCCMISC  0x6080
+#define P9_OCB_OCI_OCCMISC_CLEAR0x6081
+#define P9_OCB_OCI_OCCMISC_OR   0x6082
+
+
+static uint64_t pnv_occ_power9_xscom_read(void *opaque, hwaddr addr,
+  unsigned size)
+{
+PnvOCC *occ = PNV_OCC(opaque);
+uint32_t offset = addr >> 3;
+uint64_t val = 0;
+
+switch (offset) {
+case P9_OCB_OCI_OCCMISC:
+val = occ->occmisc;
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
+  HWADDR_PRIx "\n", addr >> 3);
+}
+return val;
+}
+
+static void pnv_occ_power9_xscom_write(void *opaque, hwaddr addr,
+   uint64_t val, unsigned size)
+{
+PnvOCC *occ = PNV_OCC(opaque);
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+case P9_OCB_OCI_OCCMISC_CLEAR:
+pnv_occ_set_misc(occ, 0);
+break;
+case P9_OCB_OCI_OCCMISC_OR:
+pnv_occ_set_misc(occ, occ->occmisc | val);
+break;
+case P9_OCB_OCI_OCCMISC:
+pnv_occ_set_misc(occ, val);
+   break;
+default:
+qemu_log_mask(LOG_UNIMP, "OCC Unimplemented register: Ox%"
+  HWADDR_PRIx "\n", addr >> 3);
+}
+}
+
+static const MemoryRegionOps pnv_occ_power9_xscom_ops = {
+.read = pnv_occ_power9_xscom_read,
+.write = pnv_occ_power9_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness 

  1   2   3   4   5   6   7   >