Re: [Qemu-devel] [BUG] [low severity] a strange appearance of message involving slirp while doing "empty" make

2019-03-21 Thread Thomas Huth
On 20/03/2019 22.08, Aleksandar Markovic wrote:
> Folks,
> 
> If qemu tree is already fully built, and "make" is attempted, for 3.1, the 
> outcome is:
> 
> $ make
>   CHK version_gen.h
> $
> 
> For 4.0-rc0, the outcome seems to be different:
> 
> $ make
> make[1]: Entering directory '/home/build/malta-mips64r6/qemu-4.0/slirp'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory '/home/build/malta-mips64r6/qemu-4.0/slirp'
>   CHK version_gen.h
> $
> 
> Not sure how significant is that, but I report it just in case.

It's likely because slirp is currently being reworked to become a
separate project, so the makefiles have been changed a little bit. I
guess the message will go away again once slirp has become a stand-alone
library.

 Thomas




Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

2019-03-21 Thread Thomas Huth
On 15/03/2019 20.06, Aleksandar Markovic wrote:
>> From: Thomas Huth 
>> Subject: Re: Maintainers, please tell us how to boot your machines!
>>
>>> On Tue, Mar 12, 2019 at 6:44 PM Markus Armbruster 
>>> wrote:
>> [...]
 I gathered the machine types, mapped them to source files, which I
 fed to get_maintainer.pl.  Results are appended.  If you're cc'ed,
 MAINTAINERS fingers you for at least one machine type's source file.
 Please tell us for all of them how to to a "meaningful" boot test.
>> [...]
 = hw/mips/mips_mipssim.c =
 Aleksandar Markovic  (odd fixer:Mipssim)
 Aleksandar Rikalo  (reviewer:Mipssim)
 Aurelien Jarno  (maintainer:MIPS)
>>>
>>> See this thread:
>>> http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg04071.html
>>
>> You can still create an image for the mipssim machine with "buildroot".
>> It's cumbersome, and you've got to use an older Linux kernel (< 3.6
>> IIRC), but it's doable. I once built an image for this machine a couple
>> of months ago. Let me know if you want it.
>>
> 
> Thomas,
> 
> That would be great! Please attach the procedure you use, it is a valuable
> information. I truly appreciate your participation!

Here we go (finally):

 wget https://buildroot.org/downloads/buildroot-2014.11.tar.bz2
 tar -xaf buildroot-2014.11.tar.bz2
 cd buildroot-2014.11/
 make menuconfig

Target Options:
 Target Architecture = MIPS little endian
 Target Arch Variant = mips32r2
 Soft float = y

Kernel:
 Kernel = y
 Kernel version = 3.6.11
 Kernel config = defconfig
 Defconfig name = mipssim
 Kernel binary format = vmlinux

Toolchain:
 Kernel Headers Version = manually
  linux version = 3.6.11
  Custom kernel header series = 3.6.x

Filesystem images:
 initial RAM filesystem linked into linux kernel =y

... then exit and save the config, and finally type "make".

Then you should be able to run:

 qemu-system-mipsel -M mipssim -nographic -kernel output/images/vmlinux


 HTH,
  Thomas



[Qemu-devel] [PATCH] target/xtensa: fix break_dependency for repeated resources

2019-03-21 Thread Max Filippov
break_dependency incorrectly handles the case of dependency on an opcode
that references the same register multiple times. E.g. the following
instruction is translated incorrectly:

  { or a2, a3, a3 ; or a3, a2, a2 }

This happens because resource indices of both dependency graph nodes are
incremented, and a copy for the second instance of the same register in
the ending node is not done.
Only increment resource index of the ending node of the dependency.
Add test.

Signed-off-by: Max Filippov 
---
 target/xtensa/translate.c|  1 -
 tests/tcg/xtensa/test_flix.S | 17 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index 77bc04d6b0f6..65561d2c4972 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -1041,7 +1041,6 @@ static bool break_dependency(struct slot_prop *a,
 copy[n].resource = b->in[j].resource;
 copy[n].arg = b->arg + index;
 ++n;
-++i;
 ++j;
 rv = true;
 }
diff --git a/tests/tcg/xtensa/test_flix.S b/tests/tcg/xtensa/test_flix.S
index 7c259e701897..7af06b2b8882 100644
--- a/tests/tcg/xtensa/test_flix.S
+++ b/tests/tcg/xtensa/test_flix.S
@@ -55,6 +55,23 @@ test sum
 .previous
 test_end
 
+test rep_dependency
+
+{
+movia2, 1
+movia3, 2
+nop
+}
+{
+or  a2, a3, a3
+or  a3, a2, a2
+nop
+}
+assert  eqi, a2, 2
+assert  eqi, a3, 1
+
+test_end
+
 #endif
 
 test_suite_end
-- 
2.11.0




Re: [Qemu-devel] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess

2019-03-21 Thread John G Johnson


 
>  On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote:
> 
>> On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi  wrote:
>>> 
>>> On Thu, Mar 07, 2019 at 02:51:20PM +, Daniel P. Berrangé wrote:
 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.
> 
> 
> Note that currently all QEMU instances run by libvirt have seccomp
> policy applied that explicitly forbids any use of fork+exec as a way
> to reduce avenues of attack for an exploited QEMU.
> 
> Even in a modularized QEMU I'd be loathe to allow QEMU to have the
> fork+exec privileged, unless "QEMU" in this case was just a stub
> process that does nothing more than fork+exec the other binaries,
> while having zero attack exposed to the untrusted guest OS.
> 

We’re looking at a couple ways to address your concerns.
One is a stub process, as you mentioned above, but if we need to
create programming to fork() and exec() the required emulation
programs before exec()ing QEMU, then it may make sense to just put
that programming into libvirt itself.

Both paths would need similar changes to QEMU, such as the
ability to receive descriptions of the emulation processes the parent
process has created, and file descriptors that it has setup to
communicate with them.  Each remote device would then be matched with
its corresponding external process.

The difference would be whether to create a new stub program
to create the emulation processes, or delegate that task to libvirt’s
QEMU driver.

Do you have an opinion on a stub program vs libvirt integration?

JJ




Re: [Qemu-devel] [Xen-devel] [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE

2019-03-21 Thread Roger Pau Monné
On Wed, Mar 20, 2019 at 01:28:47PM -0400, Jason Andryuk wrote:
> On Fri, Mar 15, 2019 at 12:28 PM Andrew Cooper
>  wrote:
> >
> > On 15/03/2019 09:17, Paul Durrant wrote:
> > >> -Original Message-
> > >> From: Jason Andryuk [mailto:jandr...@gmail.com]
> > >> Sent: 14 March 2019 18:16
> > >> To: Paul Durrant 
> > >> Cc: qemu-devel@nongnu.org; xen-de...@lists.xenproject.org; 
> > >> marma...@invisiblethingslab.com; Simon
> > >> Gaiser ; Stefano Stabellini 
> > >> ; Anthony Perard
> > >> 
> > >> Subject: Re: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
> > >>
> > >> On Wed, Mar 13, 2019 at 11:09 AM Paul Durrant  
> > >> wrote:
> >  -Original Message-
> >  From: Jason Andryuk [mailto:jandr...@gmail.com]
> >  Sent: 11 March 2019 18:02
> >  To: qemu-devel@nongnu.org
> >  Cc: xen-de...@lists.xenproject.org; marma...@invisiblethingslab.com; 
> >  Simon Gaiser
> >  ; Jason Andryuk ; 
> >  Stefano Stabellini
> >  ; Anthony Perard ; 
> >  Paul Durrant
> >  
> >  Subject: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
> > 
> >  From: Simon Gaiser 
> > 
> >  If a pci memory region has a size < XEN_PAGE_SIZE it can get located at
> >  an address which is not page aligned.
> > >>> IIRC the PCI spec says that the minimum memory region size should be at 
> > >>> least 4k. Should we even be
> > >> tolerating BARs smaller than that?
> > >>>   Paul
> > >>>
> > >> Hi, Paul.
> > >>
> > >> Simon found this, so it affects a real device.  Simon, do you recall
> > >> which device was affected?
> > >>
> > >> I think BARs only need to be power-of-two size and aligned, and 4k is
> > >> not a minimum.  16bytes may be a minimum, but I don't know what the
> > >> spec says.
> > >>
> > >> On an Ivy Bridge system, here are some of the devices with BARs smaller 
> > >> than 4K:
> > >> 00:16.0 Communication controller: Intel Corporation 7 Series/C210
> > >> Series Chipset Family MEI Controller #1 (rev 04)
> > >>Memory at d0735000 (64-bit, non-prefetchable) [disabled] [size=16]
> > >> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> > >> Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
> > >>Memory at d0739000 (32-bit, non-prefetchable) [disabled] [size=1K]
> > >> 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family
> > >> SMBus Controller (rev 04)
> > >>Memory at d0734000 (64-bit, non-prefetchable) [disabled] [size=256]
> > >> 02:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host
> > >> Controller (rev 30)
> > >>Memory at d0503000 (32-bit, non-prefetchable) [disabled] [size=256]
> > >>
> > >> These examples are all 4K aligned, so this is not an issue on this 
> > >> machine.
> > >>
> > >> Reviewing the code, I'm now wondering if the following in
> > >> hw/xen/xen_pt.c:xen_pt_region_update is wrong:rc =
> > >> xc_domain_memory_mapping(xen_xc, xen_domid,
> > >>  XEN_PFN(guest_addr + XC_PAGE_SIZE - 
> > >> 1),
> > >>  XEN_PFN(machine_addr + XC_PAGE_SIZE 
> > >> - 1),
> > >>  XEN_PFN(size + XC_PAGE_SIZE - 1),
> > >>  op);
> > >>
> > >> If a bar of size 0x100 is at 0xd0500800, then the machine_addr passed
> > >> in would be 0xd0501000 which is past the actual location.  Should the
> > >> call arguments just be XEN_PFN(guest_addr) & XEN_PFN(machine_addr)?
> > >>
> > >> BARs smaller than a page would also be a problem if BARs for different
> > >> devices shared the same page.
> > > Exactly. We cannot pass them through with any degree of safety (not that 
> > > passthrough of an arbitrary device is a particularly safe thing to do 
> > > anyway). The xen-pt code would instead need to trap those BARs and 
> > > perform the accesses to the real BAR itself. Ultimately though I think we 
> > > should be retiring the xen-pt code in favour of a standalone emulator.
> >
> > It doesn't matter if the BAR is smaller than 4k, if there are holes next
> > to it.
> >
> > Do we know what the case is in practice for these USB controllers?
> >
> > If the worst comes to the worst, we can re-enumerate the PCI bus to
> > ensure that all bars smaller than 4k still have 4k alignment between
> > them.  That way we can safely pass them through even when they are smaller.
> 
> Andrew, thanks for checking the spec on the minimum BAR size.
> 
> Dropping the Round PCI region patch from QMEU, the guest HVM will have:
> 
> 00:06.0 SD Host controller: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 
> 07)
> Memory at f2028800 (32-bit, non-prefetchable) [size=256]
> 00:07.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev 04) (prog-if 30 [XHCI])
> Memory at f2024000 (64-bit, non-prefetchable) [size=8K]
> 00:08.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
> Family USB Enhanced Host 

[Qemu-devel] Re [Qemu-block] [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

2019-03-21 Thread lizhengui

The fcntl call fails in the actual scene and it is really hard to happen. But 
according to a good coding style, I think there should be a error handling for 
a system call.

+ if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {

The flags is a int type. According to strict programming specifications, it 
should be converted to unsigned type before doing bitwise operator. I am doing 
this just to avoid codex warnings.
If you think it is not necessary to do so,  I can remove it.


-邮件原件-
发件人: Eric Blake [mailto:ebl...@redhat.com] 
发送时间: 2019年3月22日 10:01
收件人: lizhengui; Paolo Bonzini; stefa...@redhat.com; mre...@redhat.com; 
kw...@redhat.com
抄送: wangjie (P); qemu-devel@nongnu.org; qemu-bl...@nongnu.org; Fangyi (C)
主题: Re: [Qemu-block] [PATCH] qemu-pr-helper: check the return value of fcntl in 
do_pr_out

[top-posting is harder to read on technical lists; I'm reordering your message 
before replying inline]

> On 20/03/19 15:07, Zhengui li wrote:
>> The function fcntl maybe return -1, which is not a unsigned type.
>> Unsigned type or Negative values should not do bitwise operator with 
>> O_ACCMODE.
> 
> Did you actually find a case in which the fcntl can fail?

On 3/21/19 8:50 PM, lizhengui wrote:

> If the fd is invalid or interrupted by signal.

If the fd is invalid, we have a coding bug on our hand - we should not be 
calling do_pr_out with an invalid fd. Do you have a backtrace where that 
actually happened?

As for being interrupted by a signal, that's not possible. fcntl() can only be 
interrupted by signal forF_SETLKW, F_OFD_SETLKW, F_GETLK, F_SETLK, F_OFD_GETLK, 
or F_OFD_SETLK.

I agree that your fix avoids a bug if it can actually happen - but I also want 
to know if it happened in practice or whether it is just plugging a theoretical 
hole (it may determine whether your patch must go into 4.0, or can slip to 4.1).

>> -if ((fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY) {
>> +flags = fcntl(fd, F_GETFL);
>> +if (flags < 0) {
>> +return -1;
>> +}

This addition is fine.

>> +
>> +if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {

This cast is not. You already guaranteed that flags is non-negative by the code 
added above, and therefore the bitwise-and on the signed type is well-defined, 
without the need to muddy things up with a cast.

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



Re: [Qemu-devel] [PATCH v3 13/15] spapr/irq: introduce a spapr_irq_init_device() helper

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:12PM +0100, Cédric Le Goater wrote:
> The way the XICS and the XIVE devices are initialized follows the same
> pattern. First, try to connect to the KVM device and if not possible
> fallback on the emulated device, unless a kernel_irqchip is required.
> The spapr_irq_init_device() routine implements this sequence in
> generic way using new sPAPR IRQ handlers ->init_emu() and ->init_kvm().
> 
> The XIVE init sequence is moved under the associated sPAPR IRQ
> ->init() handler. This will change again when KVM support is added for
> the dual interrupt mode.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
>  include/hw/ppc/spapr_irq.h  |  2 +
>  include/hw/ppc/spapr_xive.h |  1 +
>  hw/intc/spapr_xive.c| 26 +++
>  hw/ppc/spapr_irq.c  | 89 +
>  4 files changed, 78 insertions(+), 40 deletions(-)
> 
> diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
> index b855f74e4428..14cab73c9c07 100644
> --- a/include/hw/ppc/spapr_irq.h
> +++ b/include/hw/ppc/spapr_irq.h
> @@ -48,6 +48,8 @@ typedef struct SpaprIrq {
>  void (*reset)(SpaprMachineState *spapr, Error **errp);
>  void (*set_irq)(void *opaque, int srcno, int val);
>  const char *(*get_nodename)(SpaprMachineState *spapr);
> +void (*init_emu)(SpaprMachineState *spapr, Error **errp);
> +void (*init_kvm)(SpaprMachineState *spapr, Error **errp);
>  } SpaprIrq;
>  
>  extern SpaprIrq spapr_irq_xics;
> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> index 0b5e972d52c8..b26befcf6b56 100644
> --- a/include/hw/ppc/spapr_xive.h
> +++ b/include/hw/ppc/spapr_xive.h
> @@ -66,6 +66,7 @@ void spapr_xive_map_mmio(SpaprXive *xive);
>  
>  int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
>   uint32_t *out_server, uint8_t *out_prio);
> +void spapr_xive_init(SpaprXive *xive, Error **errp);
>  
>  /*
>   * KVM XIVE device helpers
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index a3cbbdf7aff0..f889c89dc2e9 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -280,7 +280,6 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> **errp)
>  XiveSource *xsrc = >source;
>  XiveENDSource *end_xsrc = >end_source;
>  Error *local_err = NULL;
> -MachineState *machine = MACHINE(qdev_get_machine());
>  
>  if (!xive->nr_irqs) {
>  error_setg(errp, "Number of interrupt needs to be greater 0");
> @@ -331,27 +330,12 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> **errp)
> xive->tm_base + XIVE_TM_USER_PAGE * (1 << 
> TM_SHIFT));
>  
>  qemu_register_reset(spapr_xive_reset, dev);
> +}
>  
> -if (kvm_enabled() && machine_kernel_irqchip_allowed(machine)) {
> -kvmppc_xive_connect(xive, _err);
> -if (local_err && machine_kernel_irqchip_required(machine)) {
> -error_prepend(_err,
> -  "kernel_irqchip requested but unavailable: ");
> -error_propagate(errp, local_err);
> -return;
> -}
> -
> -if (!local_err) {
> -return;
> -}
> -
> -/*
> - * We failed to initialize the XIVE KVM device, fallback to
> - * emulated mode
> - */
> -error_prepend(_err, "kernel_irqchip allowed but unavailable: 
> ");
> -warn_report_err(local_err);
> -}
> +void spapr_xive_init(SpaprXive *xive, Error **errp)
> +{
> +XiveSource *xsrc = >source;
> +XiveENDSource *end_xsrc = >end_source;
>  
>  /* TIMA initialization */
>  memory_region_init_io(>tm_mmio, OBJECT(xive), _tm_ops, xive,
> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> index d7130f66dbaa..0c65de35f52a 100644
> --- a/hw/ppc/spapr_irq.c
> +++ b/hw/ppc/spapr_irq.c
> @@ -61,36 +61,50 @@ void spapr_irq_msi_reset(SpaprMachineState *spapr)
>  bitmap_clear(spapr->irq_map, 0, spapr->irq_map_nr);
>  }
>  
> -
> -/*
> - * XICS IRQ backend.
> - */
> -
> -static void spapr_irq_init_xics(SpaprMachineState *spapr, int nr_irqs,
> -Error **errp)
> +static void spapr_irq_init_device(SpaprMachineState *spapr,
> +  SpaprIrq *irq, Error **errp)
>  {
>  MachineState *machine = MACHINE(spapr);
> -Object *obj;
>  Error *local_err = NULL;
> -bool xics_kvm = false;
>  
> -if (kvm_enabled()) {
> -if (machine_kernel_irqchip_allowed(machine) &&
> -!xics_kvm_init(spapr, _err)) {
> -xics_kvm = true;
> -}
> -if (machine_kernel_irqchip_required(machine) && !xics_kvm) {
> +if (kvm_enabled() && machine_kernel_irqchip_allowed(machine)) {
> +irq->init_kvm(spapr, _err);
> +if (local_err && machine_kernel_irqchip_required(machine)) {
>  error_prepend(_err,
>"kernel_irqchip requested but unavailable: ");

Re: [Qemu-devel] [RFC for-4.1 00/25] Many style fixes for target/ppc

2019-03-21 Thread David Gibson
On Fri, Mar 22, 2019 at 11:15:19AM +1100, David Gibson wrote:
> target/ppc has a lot of old code that doesn't stick to the modern
> style guidelines.  That means we keep getting checkpatch warnings from
> code motions in there, or from people copying the local style rather
> than the global style.
> 
> I'm sick of it, so here's a big series to fix many of the style
> problems in target/ppc.
> 
> It doesn't cover every checkpatch warning: outright false positives
> are ignored of course, but there are also some things that it's not
> obvious how to fix (often involving hairy nested macros).  Still, it's
> a good start.

Oops, sorry, the first two patches weren't supposed to be in this series.

> 
> Alexey Kardashevskiy (1):
>   spapr: Support NVIDIA V100 GPU with NVLink2
> 
> David Gibson (23):
>   target/ppc: Style fixes for ppc-models.[ch]
>   target/ppc: Style fixes for cpu.[ch]
>   target/ppc: Style fixes for int_helper.c
>   target/ppc: Style fixes for fpu_helper.c
>   target/ppc: Style fixes for dfp_helper.c
>   target/ppc: Style fixes for excp_helper.c
>   target/ppc: Style fixes for gdbstub.c
>   target/ppc: Style fixes for helper_regs.h
>   target/ppc: Style fixes for kvm_ppc.h and kvm.c
>   target/ppc: Style fixes for machine.c
>   target/ppc: Style fixes for mem_helper.c
>   target/ppc: Style fixes for mfrom_table.inc.c & mfrom_table_gen.c
>   target/ppc: Style fixes for misc_helper.c
>   target/ppc: Style fixes for mmu-hash32.[ch]
>   target/ppc: Style fixes for mmu-hash64.[ch]
>   target/ppc: Style fixes for mmu_helper.c
>   target/ppc: Style fixes for monitor.c
>   target/ppc: Style fixes for translate_init.inc.c
>   target/ppc: Style fixes for translate.c
>   target/ppc: Style fixes for translate/fp-impl.inc.c
>   target/ppc: Style fixes for translate/vsx-impl.inc.c
>   target/ppc: Style fixes for translate/vmx-impl.inc.c
>   target/ppc: Style fixes for translate/spe-impl.inc.c
> 
> Philippe Mathieu-Daudé (1):
>   hw/ppc/prep: Drop useless inclusion of "hw/input/i8042.h"
> 
>  hw/ppc/Makefile.objs|   2 +-
>  hw/ppc/prep.c   |   1 -
>  hw/ppc/spapr.c  |  48 ++-
>  hw/ppc/spapr_pci.c  |  19 ++
>  hw/ppc/spapr_pci_nvlink2.c  | 450 
>  hw/vfio/pci-quirks.c| 131 +++
>  hw/vfio/pci.c   |  14 +
>  hw/vfio/pci.h   |   2 +
>  hw/vfio/trace-events|   4 +
>  include/hw/pci-host/spapr.h |  45 +++
>  include/hw/ppc/spapr.h  |   5 +-
>  target/ppc/cpu-models.c |   2 +-
>  target/ppc/cpu-models.h |   3 +-
>  target/ppc/cpu.h| 239 +++--
>  target/ppc/dfp_helper.c |  14 +-
>  target/ppc/excp_helper.c|  87 +++--
>  target/ppc/fpu_helper.c | 134 +---
>  target/ppc/gdbstub.c|  34 +-
>  target/ppc/helper_regs.h|  10 +-
>  target/ppc/int_helper.c |  70 ++--
>  target/ppc/kvm.c| 178 ++
>  target/ppc/kvm_ppc.h|   3 +-
>  target/ppc/machine.c| 106 +++---
>  target/ppc/mem_helper.c |  33 +-
>  target/ppc/mfrom_table.inc.c|   3 +-
>  target/ppc/mfrom_table_gen.c|   8 +-
>  target/ppc/misc_helper.c|   9 +-
>  target/ppc/mmu-hash32.c |  19 +-
>  target/ppc/mmu-hash64.c |  62 ++--
>  target/ppc/mmu_helper.c | 131 ---
>  target/ppc/monitor.c|  13 +-
>  target/ppc/translate.c  | 507 +---
>  target/ppc/translate/fp-impl.inc.c  |  52 +--
>  target/ppc/translate/spe-impl.inc.c |  14 +-
>  target/ppc/translate/vmx-impl.inc.c |  26 +-
>  target/ppc/translate/vsx-impl.inc.c |  15 +-
>  target/ppc/translate_init.inc.c | 240 +++--
>  37 files changed, 1921 insertions(+), 812 deletions(-)
>  create mode 100644 hw/ppc/spapr_pci_nvlink2.c
> 

-- 
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 v3 14/15] spapr/irq: initialize the IRQ device only once

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:13PM +0100, Cédric Le Goater wrote:
> Add a check to make sure that the routine initializing the emulated
> IRQ device is called once. We don't have much to test on the XICS
> side, so we introduce a 'static bool'. Not very elegant but works well
> enough.

What's the rationale for this?

> 
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/intc/spapr_xive.c |  9 +
>  hw/intc/xics_spapr.c | 10 ++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index f889c89dc2e9..15d41d9cd36d 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -337,6 +337,15 @@ void spapr_xive_init(SpaprXive *xive, Error **errp)
>  XiveSource *xsrc = >source;
>  XiveENDSource *end_xsrc = >end_source;
>  
> +/*
> + * The emulated XIVE device can only be initialized once. If the
> + * ESB memory region has been already mapped, it means we have been
> + * through there.
> + */
> +if (memory_region_is_mapped(>esb_mmio)) {
> +return;
> +}
> +
>  /* TIMA initialization */
>  memory_region_init_io(>tm_mmio, OBJECT(xive), _tm_ops, xive,
>"xive.tima", 4ull << TM_SHIFT);
> diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
> index 9d2b8adef7c5..67e82f3720b0 100644
> --- a/hw/intc/xics_spapr.c
> +++ b/hw/intc/xics_spapr.c
> @@ -239,6 +239,16 @@ static void rtas_int_on(PowerPCCPU *cpu, 
> SpaprMachineState *spapr,
>  
>  void xics_spapr_init(SpaprMachineState *spapr)
>  {
> +static bool init_done;
> +
> +/*
> + * Emulated mode can only be initialized once.
> + */
> +if (init_done) {
> +return;
> +}
> +init_done = true;
> +
>  /* Registration of global state belongs into realize */
>  spapr_rtas_register(RTAS_IBM_SET_XIVE, "ibm,set-xive", rtas_set_xive);
>  spapr_rtas_register(RTAS_IBM_GET_XIVE, "ibm,get-xive", rtas_get_xive);

-- 
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 v3 15/15] spapr/irq: add KVM support to the 'dual' machine

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:14PM +0100, Cédric Le Goater wrote:
> The interrupt mode is chosen by the CAS negotiation process and
> activated after a reset to take into account the required changes in
> the machine. This brings new constraints on how the associated KVM IRQ
> device is initialized.
> 
> Currently, each model takes care of the initialization of the KVM
> device in their realize method but this is not possible anymore as the
> initialization needs to be done globaly when the interrupt mode is
> known, i.e. when machine is reseted. It also means that we need a way
> to delete a KVM device when another mode is chosen.
> 
> Also, to support migration, the QEMU objects holding the state to
> transfer should always be available but not necessarily activated.
> 
> The overall approach of this proposal is to initialize both interrupt
> mode at the QEMU level to keep the IRQ number space in sync and to
> allow switching from one mode to another. For the KVM side of things,
> the whole initialization of the KVM device, sources and presenters, is
> grouped in a single routine. The XICS and XIVE sPAPR IRQ reset
> handlers are modified accordingly to handle the init and the delete
> sequences of the KVM device.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
> 
>  Changes since v2:
> 
>  - introduced the use of spapr_irq_init_device() 
> 
>  include/hw/ppc/xive.h|  1 -
>  hw/intc/spapr_xive_kvm.c | 29 ++-
>  hw/intc/xics_kvm.c   | 26 
>  hw/intc/xive.c   |  4 
>  hw/ppc/spapr_irq.c   | 51 ++--
>  5 files changed, 92 insertions(+), 19 deletions(-)
> 
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index edb8937f17fb..d872f96d1a1b 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -432,7 +432,6 @@ static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, 
> uint32_t nvt_idx)
>   */
>  
>  void kvmppc_xive_source_reset_one(XiveSource *xsrc, int srcno, Error **errp);
> -void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp);
>  void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
>  void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
>  void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp);
> diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
> index 78d2ea433c98..5577a88bf10f 100644
> --- a/hw/intc/spapr_xive_kvm.c
> +++ b/hw/intc/spapr_xive_kvm.c
> @@ -238,7 +238,7 @@ void kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
> srcno, Error **errp)
>true, errp);
>  }
>  
> -void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp)
> +static void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp)
>  {
>  int i;
>  
> @@ -690,6 +690,15 @@ void kvmppc_xive_connect(SpaprXive *xive, Error **errp)
>  Error *local_err = NULL;
>  size_t esb_len = (1ull << xsrc->esb_shift) * xsrc->nr_irqs;
>  size_t tima_len = 4ull << TM_SHIFT;
> +CPUState *cs;
> +
> +/*
> + * The KVM XIVE device already in use. This is the case when
> + * rebooting under the XIVE-only interrupt mode.
> + */
> +if (xive->fd != -1) {
> +return;
> +}
>  
>  if (!kvmppc_has_cap_xive()) {
>  error_setg(errp, "IRQ_XIVE capability must be present for KVM");
> @@ -738,6 +747,24 @@ void kvmppc_xive_connect(SpaprXive *xive, Error **errp)
>  xive->change = qemu_add_vm_change_state_handler(
>  kvmppc_xive_change_state_handler, xive);
>  
> +/* Connect the presenters to the initial VCPUs of the machine */
> +CPU_FOREACH(cs) {
> +PowerPCCPU *cpu = POWERPC_CPU(cs);
> +
> +kvmppc_xive_cpu_connect(spapr_cpu_state(cpu)->tctx, _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +}
> +
> +/* Update the KVM sources */
> +kvmppc_xive_source_reset(xsrc, _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
>  kvm_kernel_irqchip = true;
>  kvm_msi_via_irqfd_allowed = true;
>  kvm_gsi_direct_mapping = true;
> diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
> index b3a01326d261..b33d1f2f789e 100644
> --- a/hw/intc/xics_kvm.c
> +++ b/hw/intc/xics_kvm.c
> @@ -33,6 +33,7 @@
>  #include "trace.h"
>  #include "sysemu/kvm.h"
>  #include "hw/ppc/spapr.h"
> +#include "hw/ppc/spapr_cpu_core.h"
>  #include "hw/ppc/xics.h"
>  #include "hw/ppc/xics_spapr.h"
>  #include "kvm_ppc.h"
> @@ -342,6 +343,16 @@ static void rtas_dummy(PowerPCCPU *cpu, 
> SpaprMachineState *spapr,
>  int xics_kvm_init(SpaprMachineState *spapr, Error **errp)
>  {
>  int rc;
> +CPUState *cs;
> +Error *local_err = NULL;
> +
> +/*
> + * The KVM XICS device already in use. This is the case when
> + * rebooting under the XICS-only interrupt mode.
> + */
> +if (kernel_xics_fd != 

Re: [Qemu-devel] [PATCH v3 08/15] spapr/rtas: modify spapr_rtas_register() to remove RTAS handlers

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:07PM +0100, Cédric Le Goater wrote:
> Removing RTAS handlers will become necessary when the new pseries
> machine supporting multiple interrupt mode is introduced.
> 
> Signed-off-by: Cédric Le Goater 

This makes sense independent of the rest, so I've applied it to ppc-for-4.1.

> ---
>  include/hw/ppc/spapr.h | 4 
>  hw/ppc/spapr_rtas.c| 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 2b4c05a2ec33..6a067db04351 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -671,6 +671,10 @@ typedef void (*spapr_rtas_fn)(PowerPCCPU *cpu, 
> SpaprMachineState *sm,
>uint32_t nargs, target_ulong args,
>uint32_t nret, target_ulong rets);
>  void spapr_rtas_register(int token, const char *name, spapr_rtas_fn fn);
> +static inline void spapr_rtas_unregister(int token)
> +{
> +spapr_rtas_register(token, NULL, NULL);
> +}
>  target_ulong spapr_rtas_call(PowerPCCPU *cpu, SpaprMachineState *sm,
>   uint32_t token, uint32_t nargs, target_ulong 
> args,
>   uint32_t nret, target_ulong rets);
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index 24c45b12d46b..ee24212765be 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -404,7 +404,7 @@ void spapr_rtas_register(int token, const char *name, 
> spapr_rtas_fn fn)
>  
>  token -= RTAS_TOKEN_BASE;
>  
> -assert(!rtas_table[token].name);
> +assert(!name || !rtas_table[token].name);
>  
>  rtas_table[token].name = name;
>  rtas_table[token].fn = fn;

-- 
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 v3 12/15] spapr/irq: remove spapr_ics_create()

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:11PM +0100, Cédric Le Goater wrote:
> spapr_ics_create() is only called once. Merge it in spapr_irq_init_xics()
> and simplify a bit the error handling by using 'error_fatal' .
> 
> Signed-off-by: Cédric Le Goater 

Seems like a good cleanup, regardless of the rest.  Applied to ppc-for-4.1.

> ---
>  hw/ppc/spapr_irq.c | 44 ++--
>  1 file changed, 14 insertions(+), 30 deletions(-)
> 
> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> index b4e3128b7f06..d7130f66dbaa 100644
> --- a/hw/ppc/spapr_irq.c
> +++ b/hw/ppc/spapr_irq.c
> @@ -66,36 +66,11 @@ void spapr_irq_msi_reset(SpaprMachineState *spapr)
>   * XICS IRQ backend.
>   */
>  
> -static ICSState *spapr_ics_create(SpaprMachineState *spapr,
> -  int nr_irqs, Error **errp)
> -{
> -Error *local_err = NULL;
> -Object *obj;
> -
> -obj = object_new(TYPE_ICS_SIMPLE);
> -object_property_add_child(OBJECT(spapr), "ics", obj, _abort);
> -object_property_add_const_link(obj, ICS_PROP_XICS, OBJECT(spapr),
> -   _abort);
> -object_property_set_int(obj, nr_irqs, "nr-irqs", _err);
> -if (local_err) {
> -goto error;
> -}
> -object_property_set_bool(obj, true, "realized", _err);
> -if (local_err) {
> -goto error;
> -}
> -
> -return ICS_BASE(obj);
> -
> -error:
> -error_propagate(errp, local_err);
> -return NULL;
> -}
> -
>  static void spapr_irq_init_xics(SpaprMachineState *spapr, int nr_irqs,
>  Error **errp)
>  {
>  MachineState *machine = MACHINE(spapr);
> +Object *obj;
>  Error *local_err = NULL;
>  bool xics_kvm = false;
>  
> @@ -107,7 +82,8 @@ static void spapr_irq_init_xics(SpaprMachineState *spapr, 
> int nr_irqs,
>  if (machine_kernel_irqchip_required(machine) && !xics_kvm) {
>  error_prepend(_err,
>"kernel_irqchip requested but unavailable: ");
> -goto error;
> +error_propagate(errp, local_err);
> +return;
>  }
>  error_free(local_err);
>  local_err = NULL;
> @@ -117,10 +93,18 @@ static void spapr_irq_init_xics(SpaprMachineState 
> *spapr, int nr_irqs,
>  xics_spapr_init(spapr);
>  }
>  
> -spapr->ics = spapr_ics_create(spapr, nr_irqs, _err);
> +obj = object_new(TYPE_ICS_SIMPLE);
> +object_property_add_child(OBJECT(spapr), "ics", obj, _abort);
> +object_property_add_const_link(obj, ICS_PROP_XICS, OBJECT(spapr),
> +   _fatal);
> +object_property_set_int(obj, nr_irqs, "nr-irqs",  _fatal);
> +object_property_set_bool(obj, true, "realized", _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
>  
> -error:
> -error_propagate(errp, local_err);
> +spapr->ics = ICS_BASE(obj);
>  }
>  
>  #define ICS_IRQ_FREE(ics, srcno)   \

-- 
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 v3 04/15] spapr/xive: add state synchronization with KVM

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:03PM +0100, Cédric Le Goater wrote:
> This extends the KVM XIVE device backend with 'synchronize_state'
> methods used to retrieve the state from KVM. The HW state of the
> sources, the KVM device and the thread interrupt contexts are
> collected for the monitor usage and also migration.
> 
> These get operations rely on their KVM counterpart in the host kernel
> which acts as a proxy for OPAL, the host firmware. The set operations
> will be added for migration support later.
> 
> Signed-off-by: Cédric Le Goater 
> ---
> 
>  Changes since v2:
> 
>  - removed the capture of the OS CAM line value from KVM
>  - added xive_end_is_valid() check
> 
>  include/hw/ppc/spapr_xive.h |  8 
>  include/hw/ppc/xive.h   |  1 +
>  hw/intc/spapr_xive.c| 17 +---
>  hw/intc/spapr_xive_kvm.c| 87 +
>  hw/intc/xive.c  | 10 +
>  5 files changed, 116 insertions(+), 7 deletions(-)
> 
> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> index 03685910e76b..7e49badd8c9a 100644
> --- a/include/hw/ppc/spapr_xive.h
> +++ b/include/hw/ppc/spapr_xive.h
> @@ -44,6 +44,13 @@ typedef struct SpaprXive {
>  void  *tm_mmap;
>  } SpaprXive;
>  
> +/*
> + * The sPAPR machine has a unique XIVE IC device. Assign a fixed value
> + * to the controller block id value. It can nevertheless be changed
> + * for testing purpose.
> + */
> +#define SPAPR_XIVE_BLOCK_ID 0x0
> +
>  bool spapr_xive_irq_claim(SpaprXive *xive, uint32_t lisn, bool lsi);
>  bool spapr_xive_irq_free(SpaprXive *xive, uint32_t lisn);
>  void spapr_xive_pic_print_info(SpaprXive *xive, Monitor *mon);
> @@ -74,5 +81,6 @@ void kvmppc_xive_set_queue_config(SpaprXive *xive, uint8_t 
> end_blk,
>  void kvmppc_xive_get_queue_config(SpaprXive *xive, uint8_t end_blk,
>   uint32_t end_idx, XiveEND *end,
>   Error **errp);
> +void kvmppc_xive_synchronize_state(SpaprXive *xive, Error **errp);
>  
>  #endif /* PPC_SPAPR_XIVE_H */
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index dd115da30ebc..78c919c4a590 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -435,5 +435,6 @@ void kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
> srcno, Error **errp);
>  void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp);
>  void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
>  void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
> +void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp);
>  
>  #endif /* PPC_XIVE_H */
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index cde2fd7c8997..4d07140f1078 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -40,13 +40,6 @@
>  
>  #define SPAPR_XIVE_NVT_BASE 0x400
>  
> -/*
> - * The sPAPR machine has a unique XIVE IC device. Assign a fixed value
> - * to the controller block id value. It can nevertheless be changed
> - * for testing purpose.
> - */
> -#define SPAPR_XIVE_BLOCK_ID 0x0
> -
>  /*
>   * sPAPR NVT and END indexing helpers
>   */
> @@ -156,6 +149,16 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
> *mon)
>  XiveSource *xsrc = >source;
>  int i;
>  
> +if (kvm_irqchip_in_kernel()) {
> +Error *local_err = NULL;
> +
> +kvmppc_xive_synchronize_state(xive, _err);
> +if (local_err) {
> +error_report_err(local_err);
> +return;
> +}
> +}
> +
>  monitor_printf(mon, "  LSIN PQEISN CPU/PRIO EQ\n");
>  
>  for (i = 0; i < xive->nr_irqs; i++) {
> diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
> index 2714f8e4702e..2e46661cb3ad 100644
> --- a/hw/intc/spapr_xive_kvm.c
> +++ b/hw/intc/spapr_xive_kvm.c
> @@ -60,6 +60,51 @@ static void kvm_cpu_enable(CPUState *cs)
>  /*
>   * XIVE Thread Interrupt Management context (KVM)
>   */
> +static void kvmppc_xive_cpu_get_state(XiveTCTX *tctx, Error **errp)
> +{
> +uint64_t state[2] = { 0 };
> +int ret;
> +
> +ret = kvm_get_one_reg(tctx->cs, KVM_REG_PPC_VP_STATE, state);
> +if (ret != 0) {
> +error_setg_errno(errp, errno,
> + "XIVE: could not capture KVM state of CPU %ld",
> + kvm_arch_vcpu_id(tctx->cs));
> +return;
> +}
> +
> +/* word0 and word1 of the OS ring. */
> +*((uint64_t *) >regs[TM_QW1_OS]) = state[0];
> +}
> +
> +typedef struct {
> +XiveTCTX *tctx;
> +Error *err;
> +} XiveCpuGetState;
> +
> +static void kvmppc_xive_cpu_do_synchronize_state(CPUState *cpu,
> + run_on_cpu_data arg)
> +{
> +XiveCpuGetState *s = arg.host_ptr;
> +
> +kvmppc_xive_cpu_get_state(s->tctx, >err);
> +}
> +
> +void kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp)
> +{
> +XiveCpuGetState s = {
> +.tctx = tctx,
> +.err = NULL,
> +  

Re: [Qemu-devel] [Qemu-block] [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

2019-03-21 Thread Eric Blake
[top-posting is harder to read on technical lists; I'm reordering your
message before replying inline]

> On 20/03/19 15:07, Zhengui li wrote:
>> The function fcntl maybe return -1, which is not a unsigned type.
>> Unsigned type or Negative values should not do bitwise operator with 
>> O_ACCMODE.
> 
> Did you actually find a case in which the fcntl can fail?

On 3/21/19 8:50 PM, lizhengui wrote:

> If the fd is invalid or interrupted by signal.

If the fd is invalid, we have a coding bug on our hand - we should not
be calling do_pr_out with an invalid fd. Do you have a backtrace where
that actually happened?

As for being interrupted by a signal, that's not possible. fcntl() can
only be interrupted by signal forF_SETLKW, F_OFD_SETLKW, F_GETLK,
F_SETLK, F_OFD_GETLK, or F_OFD_SETLK.

I agree that your fix avoids a bug if it can actually happen - but I
also want to know if it happened in practice or whether it is just
plugging a theoretical hole (it may determine whether your patch must go
into 4.0, or can slip to 4.1).

>> -if ((fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY) {
>> +flags = fcntl(fd, F_GETFL);
>> +if (flags < 0) {
>> +return -1;
>> +}

This addition is fine.

>> +
>> +if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {

This cast is not. You already guaranteed that flags is non-negative by
the code added above, and therefore the bitwise-and on the signed type
is well-defined, without the need to muddy things up with a cast.

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v3 2/2] vfio-ccw: support async command subregion

2019-03-21 Thread Eric Farman




On 3/1/19 4:39 AM, Cornelia Huck wrote:

A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt/clear request to the device; if not, fall
back to emulation (as done today).

Signed-off-by: Cornelia Huck 
---
  hw/s390x/css.c  |  27 +++--
  hw/vfio/ccw.c   | 109 +++-
  include/hw/s390x/s390-ccw.h |   3 +
  3 files changed, 133 insertions(+), 6 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index f92b046cd33e..32e69804967b 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -22,6 +22,7 @@
  #include "trace.h"
  #include "hw/s390x/s390_flic.h"
  #include "hw/s390x/s390-virtio-ccw.h"
+#include "hw/s390x/s390-ccw.h"
  
  typedef struct CrwContainer {

  CRW crw;
@@ -1194,6 +1195,26 @@ static void sch_handle_start_func_virtual(SubchDev *sch)
  
  }
  
+static void sch_handle_halt_func_passthrough(SubchDev *sch)

+{
+int ret;
+
+ret = vfio_ccw_handle_halt(sch);
+if (ret == -ENOSYS) {
+sch_handle_halt_func(sch);
+}
+}
+
+static void sch_handle_clear_func_passthrough(SubchDev *sch)
+{
+int ret;
+
+ret = vfio_ccw_handle_clear(sch);
+if (ret == -ENOSYS) {
+sch_handle_clear_func(sch);
+}
+}
+
  static IOInstEnding sch_handle_start_func_passthrough(SubchDev *sch)
  {
  
@@ -1237,11 +1258,9 @@ IOInstEnding do_subchannel_work_passthrough(SubchDev *sch)

  SCSW *s = >curr_status.scsw;
  
  if (s->ctrl & SCSW_FCTL_CLEAR_FUNC) {

-/* TODO: Clear handling */
-sch_handle_clear_func(sch);
+sch_handle_clear_func_passthrough(sch);
  } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {
-/* TODO: Halt handling */
-sch_handle_halt_func(sch);
+sch_handle_halt_func_passthrough(sch);
  } else if (s->ctrl & SCSW_FCTL_START_FUNC) {
  return sch_handle_start_func_passthrough(sch);
  }
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 9246729a75d6..633dbbce36da 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -2,9 +2,12 @@
   * vfio based subchannel assignment support
   *
   * Copyright 2017 IBM Corp.
+ * Copyright 2019 Red Hat, Inc.
+ *
   * Author(s): Dong Jia Shi 
   *Xiao Feng Ren 
   *Pierre Morel 
+ *Cornelia Huck 
   *
   * This work is licensed under the terms of the GNU GPL, version 2 or (at
   * your option) any later version. See the COPYING file in the top-level
@@ -32,6 +35,9 @@ typedef struct VFIOCCWDevice {
  uint64_t io_region_size;
  uint64_t io_region_offset;
  struct ccw_io_region *io_region;
+uint64_t async_cmd_region_size;
+uint64_t async_cmd_region_offset;
+struct ccw_cmd_region *async_cmd_region;
  EventNotifier io_notifier;
  bool force_orb_pfch;
  bool warned_orb_pfch;
@@ -114,6 +120,87 @@ again:
  }
  }
  
+int vfio_ccw_handle_clear(SubchDev *sch)

+{
+S390CCWDevice *cdev = sch->driver_data;
+VFIOCCWDevice *vcdev = DO_UPCAST(VFIOCCWDevice, cdev, cdev);
+struct ccw_cmd_region *region = vcdev->async_cmd_region;
+int ret;
+
+if (!vcdev->async_cmd_region) {
+/* Async command region not available, fall back to emulation */
+return -ENOSYS;
+}
+
+memset(region, 0, sizeof(*region));
+region->command = VFIO_CCW_ASYNC_CMD_CSCH;
+
+again:
+ret = pwrite(vcdev->vdev.fd, region,
+ vcdev->async_cmd_region_size, vcdev->async_cmd_region_offset);
+if (ret != vcdev->async_cmd_region_size) {
+if (errno == EAGAIN) {
+goto again;
+}
+error_report("vfio-ccw: write cmd region failed with errno=%d", errno);
+ret = -errno;
+} else {
+ret = region->ret_code;
+}
+switch (ret) {
+case 0:
+case -ENODEV:
+case -EACCES:
+return 0;
+case -EFAULT:
+default:
+sch_gen_unit_exception(sch);
+css_inject_io_interrupt(sch);
+return 0;
+}
+}
+
+int vfio_ccw_handle_halt(SubchDev *sch)
+{
+S390CCWDevice *cdev = sch->driver_data;
+VFIOCCWDevice *vcdev = DO_UPCAST(VFIOCCWDevice, cdev, cdev);
+struct ccw_cmd_region *region = vcdev->async_cmd_region;
+int ret;
+
+if (!vcdev->async_cmd_region) {
+/* Async command region not available, fall back to emulation */
+return -ENOSYS;
+}
+
+memset(region, 0, sizeof(*region));
+region->command = VFIO_CCW_ASYNC_CMD_HSCH;
+
+again:
+ret = pwrite(vcdev->vdev.fd, region,
+ vcdev->async_cmd_region_size, vcdev->async_cmd_region_offset);
+if (ret != vcdev->async_cmd_region_size) {
+if (errno == EAGAIN) {
+goto again;
+}
+error_report("vfio-ccw: write cmd region failed with errno=%d", errno);
+ret = -errno;
+} else {
+ret = region->ret_code;
+}
+switch (ret) {
+case 0:
+case -EBUSY:
+case -ENODEV:
+case -EACCES:
+return 0;
+

Re: [Qemu-devel] [PATCH v3 0/2] vfio-ccw: support hsch/csch (QEMU part)

2019-03-21 Thread Eric Farman




On 3/1/19 4:39 AM, Cornelia Huck wrote:


[I'm not quite happy with how this async processing hooks up in css.c;
ideas welcome.]


I guess I'm not unhappy with it, but it does look a little odd.  Not 
sure I have a better idea right now...  Will ponder that for a while.


 - Eric




Re: [Qemu-devel] [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

2019-03-21 Thread lizhengui
If the fd is invalid or interrupted by signal.

-邮件原件-
发件人: Paolo Bonzini [mailto:pbonz...@redhat.com] 
发送时间: 2019年3月21日 18:38
收件人: lizhengui; stefa...@redhat.com; mre...@redhat.com; kw...@redhat.com
抄送: qemu-bl...@nongnu.org; qemu-devel@nongnu.org; Fangyi (C); wangjie (P)
主题: Re: [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

On 20/03/19 15:07, Zhengui li wrote:
> The function fcntl maybe return -1, which is not a unsigned type.
> Unsigned type or Negative values should not do bitwise operator with 
> O_ACCMODE.

Did you actually find a case in which the fcntl can fail?

Paolo

> Signed-off-by: Zhengui li 
> ---
>  scsi/qemu-pr-helper.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c index 
> e7af637..fcbe4d9 100644
> --- a/scsi/qemu-pr-helper.c
> +++ b/scsi/qemu-pr-helper.c
> @@ -551,8 +551,14 @@ static int do_pr_out(int fd, const uint8_t *cdb, uint8_t 
> *sense,
>   const uint8_t *param, int sz)  {
>  int resp_sz;
> +int flags;
>  
> -if ((fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY) {
> +flags = fcntl(fd, F_GETFL);
> +if (flags < 0) {
> +return -1;
> +}
> +
> +if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {
>  scsi_build_sense(sense, SENSE_CODE(INVALID_OPCODE));
>  return CHECK_CONDITION;
>  }
> 



Re: [Qemu-devel] [RFC for-4.1 00/25] Many style fixes for target/ppc

2019-03-21 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190322001544.9794-1-da...@gibson.dropbear.id.au/



Hi,

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

Message-id: 20190322001544.9794-1-da...@gibson.dropbear.id.au
Subject: [Qemu-devel] [RFC for-4.1 00/25] Many style fixes for target/ppc
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 t [tag update]patchew/20190321144914.19934-1-...@kaod.org -> 
patchew/20190321144914.19934-1-...@kaod.org
 * [new tag]   
patchew/20190322001544.9794-1-da...@gibson.dropbear.id.au -> 
patchew/20190322001544.9794-1-da...@gibson.dropbear.id.au
Switched to a new branch 'test'
d9a6215ecc target/ppc: Style fixes for translate/spe-impl.inc.c
65eb138512 target/ppc: Style fixes for translate/vmx-impl.inc.c
8d94edbb00 target/ppc: Style fixes for translate/vsx-impl.inc.c
3caa9d49eb target/ppc: Style fixes for translate/fp-impl.inc.c
101d9580ee target/ppc: Style fixes for translate.c
461682526f target/ppc: Style fixes for translate_init.inc.c
4aeb580b71 target/ppc: Style fixes for monitor.c
364bed3f12 target/ppc: Style fixes for mmu_helper.c
a2f32fdcab target/ppc: Style fixes for mmu-hash64.[ch]
d52341d796 target/ppc: Style fixes for mmu-hash32.[ch]
465ef88fa6 target/ppc: Style fixes for misc_helper.c
cf4f0dde0d target/ppc: Style fixes for mfrom_table.inc.c & mfrom_table_gen.c
6b40470682 target/ppc: Style fixes for mem_helper.c
197f1940be target/ppc: Style fixes for machine.c
cc497c316b target/ppc: Style fixes for kvm_ppc.h and kvm.c
62ba6a3440 target/ppc: Style fixes for helper_regs.h
a1eb273604 target/ppc: Style fixes for gdbstub.c
2731feaffd target/ppc: Style fixes for excp_helper.c
7061f73523 target/ppc: Style fixes for dfp_helper.c
07ce42ad0f target/ppc: Style fixes for fpu_helper.c
c4b4fbf526 target/ppc: Style fixes for int_helper.c
6a09c460c6 target/ppc: Style fixes for cpu.[ch]
d60f69cf64 target/ppc: Style fixes for ppc-models.[ch]
0b955f8caf hw/ppc/prep: Drop useless inclusion of "hw/input/i8042.h"
c57df151ad spapr: Support NVIDIA V100 GPU with NVLink2

=== OUTPUT BEGIN ===
1/25 Checking commit c57df151ad04 (spapr: Support NVIDIA V100 GPU with NVLink2)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#258: 
new file mode 100644

total: 0 errors, 1 warnings, 877 lines checked

Patch 1/25 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/25 Checking commit 0b955f8caf6d (hw/ppc/prep: Drop useless inclusion of 
"hw/input/i8042.h")
3/25 Checking commit d60f69cf648e (target/ppc: Style fixes for ppc-models.[ch])
4/25 Checking commit 6a09c460c6d7 (target/ppc: Style fixes for cpu.[ch])
5/25 Checking commit c4b4fbf52642 (target/ppc: Style fixes for int_helper.c)
6/25 Checking commit 07ce42ad0f3b (target/ppc: Style fixes for fpu_helper.c)
WARNING: Block comments use a leading /* on a separate line
#129: FILE: target/ppc/fpu_helper.c:2229:
+/*  \

WARNING: Block comments use a leading /* on a separate line
#158: FILE: target/ppc/fpu_helper.c:2286:
+/*  \

WARNING: Block comments use a leading /* on a separate line
#181: FILE: target/ppc/fpu_helper.c:2340:
+/*\

WARNING: Block comments use a leading /* on a separate line
#351: FILE: target/ppc/fpu_helper.c:3182:
+/* \

total: 0 errors, 4 warnings, 328 lines checked

Patch 6/25 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/25 Checking commit 7061f73523cd (target/ppc: Style fixes for dfp_helper.c)
ERROR: spaces required around that '+' (ctx:VxV)
#35: FILE: target/ppc/dfp_helper.c:1119:
+decNumberSetBCD(, digits+((size) / 4) - n, n); \
   ^

total: 1 errors, 0 warnings, 39 lines checked

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

8/25 Checking commit 2731feaffd29 (target/ppc: Style fixes for excp_helper.c)
9/25 Checking commit a1eb273604e4 (target/ppc: Style fixes for gdbstub.c)
10/25 Checking commit 62ba6a34409b (target/ppc: Style fixes for helper_regs.h)
11/25 Checking commit cc497c316b30 (target/ppc: Style fixes for kvm_ppc.h and 
kvm.c)
WARNING: line over 80 characters
#440: FILE: target/ppc/kvm.c:2719:

[Qemu-devel] [RFC for-4.1 15/25] target/ppc: Style fixes for misc_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/misc_helper.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/target/ppc/misc_helper.c b/target/ppc/misc_helper.c
index c65d1ade15..0a81e98ee9 100644
--- a/target/ppc/misc_helper.c
+++ b/target/ppc/misc_helper.c
@@ -210,10 +210,11 @@ void ppc_store_msr(CPUPPCState *env, target_ulong value)
 hreg_store_msr(env, value, 0);
 }
 
-/* This code is lifted from MacOnLinux. It is called whenever
- * THRM1,2 or 3 is read an fixes up the values in such a way
- * that will make MacOS not hang. These registers exist on some
- * 75x and 74xx processors.
+/*
+ * This code is lifted from MacOnLinux. It is called whenever THRM1,2
+ * or 3 is read an fixes up the values in such a way that will make
+ * MacOS not hang. These registers exist on some 75x and 74xx
+ * processors.
  */
 void helper_fixup_thrm(CPUPPCState *env)
 {
-- 
2.20.1




Re: [Qemu-devel] [PATCH v3 02/15] spapr/xive: add KVM support

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:01PM +0100, Cédric Le Goater wrote:
> This introduces a set of helpers when KVM is in use, which create the
> KVM XIVE device, initialize the interrupt sources at a KVM level and
> connect the interrupt presenters to the vCPU.
> 
> They also handle the initialization of the TIMA and the source ESB
> memory regions of the controller. These have a different type under
> KVM. They are 'ram device' memory mappings, similarly to VFIO, exposed
> to the guest and the associated VMAs on the host are populated
> dynamically with the appropriate pages using a fault handler.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
> 
>  Changes since v2:
> 
>  - rebased on new naming scheme
>  - rebased on new configuration system
>  - replaced error_report_err() by warn_report_err()
>  
>  include/hw/ppc/spapr_xive.h |  10 ++
>  include/hw/ppc/xive.h   |  13 ++
>  target/ppc/kvm_ppc.h|   6 +
>  hw/intc/spapr_xive.c|  48 +++-
>  hw/intc/spapr_xive_kvm.c| 237 
>  hw/intc/xive.c  |  21 +++-
>  hw/ppc/spapr_irq.c  |   6 +-
>  target/ppc/kvm.c|   7 ++
>  hw/intc/Makefile.objs   |   1 +
>  hw/ppc/Kconfig  |   5 +
>  10 files changed, 344 insertions(+), 10 deletions(-)
>  create mode 100644 hw/intc/spapr_xive_kvm.c
> 
> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> index fc3e9652f99a..0edcc762dedd 100644
> --- a/include/hw/ppc/spapr_xive.h
> +++ b/include/hw/ppc/spapr_xive.h
> @@ -38,6 +38,10 @@ typedef struct SpaprXive {
>  /* TIMA mapping address */
>  hwaddrtm_base;
>  MemoryRegion  tm_mmio;
> +
> +/* KVM support */
> +int   fd;
> +void  *tm_mmap;
>  } SpaprXive;
>  
>  bool spapr_xive_irq_claim(SpaprXive *xive, uint32_t lisn, bool lsi);
> @@ -49,5 +53,11 @@ void spapr_dt_xive(SpaprMachineState *spapr, uint32_t 
> nr_servers, void *fdt,
> uint32_t phandle);
>  void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx);
>  void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool enable);
> +void spapr_xive_map_mmio(SpaprXive *xive);
> +
> +/*
> + * KVM XIVE device helpers
> + */
> +void kvmppc_xive_connect(SpaprXive *xive, Error **errp);
>  
>  #endif /* PPC_SPAPR_XIVE_H */
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index c4f27742ca09..dd115da30ebc 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -140,6 +140,7 @@
>  #ifndef PPC_XIVE_H
>  #define PPC_XIVE_H
>  
> +#include "sysemu/kvm.h"
>  #include "hw/qdev-core.h"
>  #include "hw/sysbus.h"
>  #include "hw/ppc/xive_regs.h"
> @@ -194,6 +195,9 @@ typedef struct XiveSource {
>  uint32_tesb_shift;
>  MemoryRegionesb_mmio;
>  
> +/* KVM support */
> +void*esb_mmap;
> +
>  XiveNotifier*xive;
>  } XiveSource;
>  
> @@ -423,4 +427,13 @@ static inline uint32_t xive_nvt_cam_line(uint8_t 
> nvt_blk, uint32_t nvt_idx)
>  return (nvt_blk << 19) | nvt_idx;
>  }
>  
> +/*
> + * KVM XIVE device helpers
> + */
> +
> +void kvmppc_xive_source_reset_one(XiveSource *xsrc, int srcno, Error **errp);
> +void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp);
> +void kvmppc_xive_source_set_irq(void *opaque, int srcno, int val);
> +void kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp);
> +
>  #endif /* PPC_XIVE_H */
> diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
> index 2c2ea30e87f3..7d2b8becd2b9 100644
> --- a/target/ppc/kvm_ppc.h
> +++ b/target/ppc/kvm_ppc.h
> @@ -60,6 +60,7 @@ bool kvmppc_has_cap_fixup_hcalls(void);
>  bool kvmppc_has_cap_htm(void);
>  bool kvmppc_has_cap_mmu_radix(void);
>  bool kvmppc_has_cap_mmu_hash_v3(void);
> +bool kvmppc_has_cap_xive(void);
>  int kvmppc_get_cap_safe_cache(void);
>  int kvmppc_get_cap_safe_bounds_check(void);
>  int kvmppc_get_cap_safe_indirect_branch(void);
> @@ -315,6 +316,11 @@ static inline bool kvmppc_has_cap_mmu_hash_v3(void)
>  return false;
>  }
>  
> +static inline bool kvmppc_has_cap_xive(void)
> +{
> +return false;
> +}
> +
>  static inline int kvmppc_get_cap_safe_cache(void)
>  {
>  return 0;
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 097f88d4608d..84ecbf3adf24 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -173,7 +173,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
> *mon)
>  }
>  }
>  
> -static void spapr_xive_map_mmio(SpaprXive *xive)
> +void spapr_xive_map_mmio(SpaprXive *xive)
>  {
>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 0, xive->vc_base);
>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 1, xive->end_base);
> @@ -250,6 +250,9 @@ static void spapr_xive_instance_init(Object *obj)
>  object_initialize_child(obj, "end_source", >end_source,
>  sizeof(xive->end_source), TYPE_XIVE_END_SOURCE,
>  _abort, NULL);
> +
> +/* Not connected to the KVM XIVE 

[Qemu-devel] [RFC for-4.1 13/25] target/ppc: Style fixes for mem_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/mem_helper.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/target/ppc/mem_helper.c b/target/ppc/mem_helper.c
index 9c5a68579e..5b0f9ee50d 100644
--- a/target/ppc/mem_helper.c
+++ b/target/ppc/mem_helper.c
@@ -27,7 +27,7 @@
 #include "internal.h"
 #include "qemu/atomic128.h"
 
-//#define DEBUG_OP
+/* #define DEBUG_OP */
 
 static inline bool needs_byteswap(const CPUPPCState *env)
 {
@@ -103,10 +103,11 @@ void helper_lsw(CPUPPCState *env, target_ulong addr, 
uint32_t nb, uint32_t reg)
 do_lsw(env, addr, nb, reg, GETPC());
 }
 
-/* PPC32 specification says we must generate an exception if
- * rA is in the range of registers to be loaded.
- * In an other hand, IBM says this is valid, but rA won't be loaded.
- * For now, I'll follow the spec...
+/*
+ * PPC32 specification says we must generate an exception if rA is in
+ * the range of registers to be loaded.  In an other hand, IBM says
+ * this is valid, but rA won't be loaded.  For now, I'll follow the
+ * spec...
  */
 void helper_lswx(CPUPPCState *env, target_ulong addr, uint32_t reg,
  uint32_t ra, uint32_t rb)
@@ -199,7 +200,8 @@ void helper_dcbzep(CPUPPCState *env, target_ulong addr, 
uint32_t opcode)
 void helper_icbi(CPUPPCState *env, target_ulong addr)
 {
 addr &= ~(env->dcache_line_size - 1);
-/* Invalidate one cache line :
+/*
+ * Invalidate one cache line :
  * PowerPC specification says this is to be treated like a load
  * (not a fetch) by the MMU. To be sure it will be so,
  * do the load "by hand".
@@ -346,17 +348,19 @@ uint32_t helper_stqcx_be_parallel(CPUPPCState *env, 
target_ulong addr,
 #define LO_IDX 0
 #endif
 
-/* We use msr_le to determine index ordering in a vector.  However,
-   byteswapping is not simply controlled by msr_le.  We also need to take
-   into account endianness of the target.  This is done for the little-endian
-   PPC64 user-mode target. */
+/*
+ * We use msr_le to determine index ordering in a vector.  However,
+ * byteswapping is not simply controlled by msr_le.  We also need to
+ * take into account endianness of the target.  This is done for the
+ * little-endian PPC64 user-mode target.
+ */
 
 #define LVE(name, access, swap, element)\
 void helper_##name(CPUPPCState *env, ppc_avr_t *r,  \
target_ulong addr)   \
 {   \
 size_t n_elems = ARRAY_SIZE(r->element);\
-int adjust = HI_IDX*(n_elems - 1);  \
+int adjust = HI_IDX * (n_elems - 1);\
 int sh = sizeof(r->element[0]) >> 1;\
 int index = (addr & 0xf) >> sh; \
 if (msr_le) {   \
@@ -476,12 +480,13 @@ VSX_STXVL(stxvll, 1)
 
 void helper_tbegin(CPUPPCState *env)
 {
-/* As a degenerate implementation, always fail tbegin.  The reason
+/*
+ * As a degenerate implementation, always fail tbegin.  The reason
  * given is "Nesting overflow".  The "persistent" bit is set,
  * providing a hint to the error handler to not retry.  The TFIAR
  * captures the address of the failure, which is this tbegin
- * instruction.  Instruction execution will continue with the
- * next instruction in memory, which is precisely what we want.
+ * instruction.  Instruction execution will continue with the next
+ * instruction in memory, which is precisely what we want.
  */
 
 env->spr[SPR_TEXASR] =
-- 
2.20.1




Re: [Qemu-devel] [PATCH] sifive_prci: Read and write PRCI registers

2019-03-21 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190322002749.26561-1-pal...@sifive.com/



Hi,

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

Message-id: 20190322002749.26561-1-pal...@sifive.com
Subject: [Qemu-devel] [PATCH] sifive_prci: Read and write PRCI registers
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/20190322002749.26561-1-pal...@sifive.com -> 
patchew/20190322002749.26561-1-pal...@sifive.com
Switched to a new branch 'test'
ba8be4dcb6 sifive_prci: Read and write PRCI registers

=== OUTPUT BEGIN ===
ERROR: that open brace { should be on the previous line
#35: FILE: hw/riscv/sifive_prci.c:29:
+switch(addr)
+{

ERROR: space required before the open parenthesis '('
#35: FILE: hw/riscv/sifive_prci.c:29:
+switch(addr)

ERROR: that open brace { should be on the previous line
#54: FILE: hw/riscv/sifive_prci.c:48:
+switch(addr)
+{

ERROR: space required before the open parenthesis '('
#54: FILE: hw/riscv/sifive_prci.c:48:
+switch(addr)

ERROR: trailing whitespace
#72: FILE: hw/riscv/sifive_prci.c:66:
+s->plloutdiv = (uint32_t) val64; $

total: 5 errors, 0 warnings, 115 lines checked

Commit ba8be4dcb6c4 (sifive_prci: Read and write PRCI registers) has style 
problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190322002749.26561-1-pal...@sifive.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [RFC for-4.1 16/25] target/ppc: Style fixes for mmu-hash32.[ch]

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/mmu-hash32.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/target/ppc/mmu-hash32.c b/target/ppc/mmu-hash32.c
index e8562a7c87..f83944b78c 100644
--- a/target/ppc/mmu-hash32.c
+++ b/target/ppc/mmu-hash32.c
@@ -27,7 +27,7 @@
 #include "mmu-hash32.h"
 #include "exec/log.h"
 
-//#define DEBUG_BAT
+/* #define DEBUG_BAT */
 
 #ifdef DEBUG_BATS
 #  define LOG_BATS(...) qemu_log_mask(CPU_LOG_MMU, __VA_ARGS__)
@@ -228,8 +228,10 @@ static int ppc_hash32_direct_store(PowerPCCPU *cpu, 
target_ulong sr,
 qemu_log_mask(CPU_LOG_MMU, "direct store...\n");
 
 if ((sr & 0x1FF0) >> 20 == 0x07f) {
-/* Memory-forced I/O controller interface access */
-/* If T=1 and BUID=x'07F', the 601 performs a memory access
+/*
+ * Memory-forced I/O controller interface access
+ *
+ * If T=1 and BUID=x'07F', the 601 performs a memory access
  * to SR[28-31] LA[4-31], bypassing all protection mechanisms.
  */
 *raddr = ((sr & 0xF) << 28) | (eaddr & 0x0FFF);
@@ -266,8 +268,9 @@ static int ppc_hash32_direct_store(PowerPCCPU *cpu, 
target_ulong sr,
 return 1;
 case ACCESS_CACHE:
 /* dcba, dcbt, dcbtst, dcbf, dcbi, dcbst, dcbz, or icbi */
-/* Should make the instruction do no-op.
- * As it already do no-op, it's quite easy :-)
+/*
+ * Should make the instruction do no-op.  As it already do
+ * no-op, it's quite easy :-)
  */
 *raddr = eaddr;
 return 0;
@@ -519,8 +522,10 @@ int ppc_hash32_handle_mmu_fault(PowerPCCPU *cpu, vaddr 
eaddr, int rwx,
 if (rwx == 1) {
 new_pte1 |= HPTE32_R_C; /* set changed (dirty) bit */
 } else {
-/* Treat the page as read-only for now, so that a later write
- * will pass through this function again to set the C bit */
+/*
+ * Treat the page as read-only for now, so that a later write
+ * will pass through this function again to set the C bit
+ */
 prot &= ~PAGE_WRITE;
 }
 
-- 
2.20.1




Re: [Qemu-devel] [PATCH v3 03/15] spapr/xive: add hcall support when under KVM

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:02PM +0100, Cédric Le Goater wrote:
> XIVE hcalls are all redirected to QEMU as none are on a fast path.
> When necessary, QEMU invokes KVM through specific ioctls to perform
> host operations. QEMU should have done the necessary checks before
> calling KVM and, in case of failure, H_HARDWARE is simply returned.
> 
> H_INT_ESB is a special case that could have been handled under KVM
> but the impact on performance was low when under QEMU. Here are some
> figures :
> 
> kernel irqchip  OFF  ON
> H_INT_ESBKVM   QEMU
> 
> rtl8139 (LSI )  1.19 1.24  1.23  Gbits/sec
> virtio 31.8042.30   --   Gbits/sec
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
> 
>  What has not changed :
> 
>  - Memory barriers have not been included. Only loads are performed on
>the ESB management page (no stores for now) and stores are done
>only on the trigger page. We should be fine as for the load
>ordering on the management page.

I'm not entirely sure I'm convinced by this reasoning, but I'll take
your word for it.

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


[Qemu-devel] [RFC for-4.1 17/25] target/ppc: Style fixes for mmu-hash64.[ch]

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/mmu-hash64.c | 62 +
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
index a2b1ec5040..90f4b306b2 100644
--- a/target/ppc/mmu-hash64.c
+++ b/target/ppc/mmu-hash64.c
@@ -29,7 +29,7 @@
 #include "hw/hw.h"
 #include "mmu-book3s-v3.h"
 
-//#define DEBUG_SLB
+/* #define DEBUG_SLB */
 
 #ifdef DEBUG_SLB
 #  define LOG_SLB(...) qemu_log_mask(CPU_LOG_MMU, __VA_ARGS__)
@@ -57,9 +57,11 @@ static ppc_slb_t *slb_lookup(PowerPCCPU *cpu, target_ulong 
eaddr)
 
 LOG_SLB("%s: slot %d %016" PRIx64 " %016"
 PRIx64 "\n", __func__, n, slb->esid, slb->vsid);
-/* We check for 1T matches on all MMUs here - if the MMU
+/*
+ * We check for 1T matches on all MMUs here - if the MMU
  * doesn't have 1T segment support, we will have prevented 1T
- * entries from being inserted in the slbmte code. */
+ * entries from being inserted in the slbmte code.
+ */
 if (((slb->esid == esid_256M) &&
  ((slb->vsid & SLB_VSID_B) == SLB_VSID_B_256M))
 || ((slb->esid == esid_1T) &&
@@ -102,7 +104,8 @@ void helper_slbia(CPUPPCState *env)
 
 if (slb->esid & SLB_ESID_V) {
 slb->esid &= ~SLB_ESID_V;
-/* XXX: given the fact that segment size is 256 MB or 1TB,
+/*
+ * XXX: given the fact that segment size is 256 MB or 1TB,
  *  and we still don't have a tlb_flush_mask(env, n, mask)
  *  in QEMU, we just invalidate all TLBs
  */
@@ -125,7 +128,8 @@ static void __helper_slbie(CPUPPCState *env, target_ulong 
addr,
 if (slb->esid & SLB_ESID_V) {
 slb->esid &= ~SLB_ESID_V;
 
-/* XXX: given the fact that segment size is 256 MB or 1TB,
+/*
+ * XXX: given the fact that segment size is 256 MB or 1TB,
  *  and we still don't have a tlb_flush_mask(env, n, mask)
  *  in QEMU, we just invalidate all TLBs
  */
@@ -305,8 +309,10 @@ static int ppc_hash64_pte_prot(PowerPCCPU *cpu,
 {
 CPUPPCState *env = >env;
 unsigned pp, key;
-/* Some pp bit combinations have undefined behaviour, so default
- * to no access in those cases */
+/*
+ * Some pp bit combinations have undefined behaviour, so default
+ * to no access in those cases
+ */
 int prot = 0;
 
 key = !!(msr_pr ? (slb->vsid & SLB_VSID_KP)
@@ -375,7 +381,7 @@ static int ppc_hash64_amr_prot(PowerPCCPU *cpu, 
ppc_hash_pte64_t pte)
 }
 
 key = HPTE64_R_KEY(pte.pte1);
-amrbits = (env->spr[SPR_AMR] >> 2*(31 - key)) & 0x3;
+amrbits = (env->spr[SPR_AMR] >> 2 * (31 - key)) & 0x3;
 
 /* fprintf(stderr, "AMR protection: key=%d AMR=0x%" PRIx64 "\n", key, */
 /* env->spr[SPR_AMR]); */
@@ -546,8 +552,9 @@ static hwaddr ppc_hash64_pteg_search(PowerPCCPU *cpu, 
hwaddr hash,
 if (*pshift == 0) {
 continue;
 }
-/* We don't do anything with pshift yet as qemu TLB only deals
- * with 4K pages anyway
+/*
+ * We don't do anything with pshift yet as qemu TLB only
+ * deals with 4K pages anyway
  */
 pte->pte0 = pte0;
 pte->pte1 = pte1;
@@ -571,8 +578,10 @@ static hwaddr ppc_hash64_htab_lookup(PowerPCCPU *cpu,
 uint64_t vsid, epnmask, epn, ptem;
 const PPCHash64SegmentPageSizes *sps = slb->sps;
 
-/* The SLB store path should prevent any bad page size encodings
- * getting in there, so: */
+/*
+ * The SLB store path should prevent any bad page size encodings
+ * getting in there, so:
+ */
 assert(sps);
 
 /* If ISL is set in LPCR we need to clamp the page size to 4K */
@@ -731,11 +740,12 @@ int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr 
eaddr,
 
 assert((rwx == 0) || (rwx == 1) || (rwx == 2));
 
-/* Note on LPCR usage: 970 uses HID4, but our special variant
- * of store_spr copies relevant fields into env->spr[SPR_LPCR].
- * Similarily we filter unimplemented bits when storing into
- * LPCR depending on the MMU version. This code can thus just
- * use the LPCR "as-is".
+/*
+ * Note on LPCR usage: 970 uses HID4, but our special variant of
+ * store_spr copies relevant fields into env->spr[SPR_LPCR].
+ * Similarily we filter unimplemented bits when storing into LPCR
+ * depending on the MMU version. This code can thus just use the
+ * LPCR "as-is".
  */
 
 /* 1. Handle real mode accesses */
@@ -874,8 +884,10 @@ skip_slb_search:
 if (rwx == 1) {
 new_pte1 |= HPTE64_R_C; /* set changed (dirty) bit */
 } else {
-/* Treat the page as read-only for now, so that a later write
- * will pass through this function again to set the C bit */
+/*
+ * Treat the page as 

[Qemu-devel] [RFC for-4.1 14/25] target/ppc: Style fixes for mfrom_table.inc.c & mfrom_table_gen.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/mfrom_table.inc.c | 3 +--
 target/ppc/mfrom_table_gen.c | 8 +---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/target/ppc/mfrom_table.inc.c b/target/ppc/mfrom_table.inc.c
index 6a1fa375c9..1653b974a4 100644
--- a/target/ppc/mfrom_table.inc.c
+++ b/target/ppc/mfrom_table.inc.c
@@ -1,5 +1,4 @@
-static const uint8_t mfrom_ROM_table[602] =
-{
+static const uint8_t mfrom_ROM_table[602] = {
  77,  77,  76,  76,  75,  75,  74,  74,
  73,  73,  72,  72,  71,  71,  70,  70,
  69,  69,  68,  68,  68,  67,  67,  66,
diff --git a/target/ppc/mfrom_table_gen.c b/target/ppc/mfrom_table_gen.c
index 631791808e..f96c4268ba 100644
--- a/target/ppc/mfrom_table_gen.c
+++ b/target/ppc/mfrom_table_gen.c
@@ -2,7 +2,7 @@
 #include "qemu/osdep.h"
 #include 
 
-int main (void)
+int main(void)
 {
 double d;
 uint8_t n;
@@ -10,7 +10,8 @@ int main (void)
 
 printf("static const uint8_t mfrom_ROM_table[602] =\n{\n");
 for (i = 0; i < 602; i++) {
-/* Extremely decomposed:
+/*
+ * Extremely decomposed:
  *-T0 / 256
  * T0 = 256 * log10(10  + 1.0) + 0.5
  */
@@ -23,8 +24,9 @@ int main (void)
 d += 0.5;
 n = d;
 printf("%3d, ", n);
-if ((i & 7) == 7)
+if ((i & 7) == 7) {
 printf("\n");
+}
 }
 printf("\n};\n");
 
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 21/25] target/ppc: Style fixes for translate.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/translate.c | 507 +
 1 file changed, 315 insertions(+), 192 deletions(-)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 98b37cebc2..67aa128ef1 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -42,8 +42,8 @@
 #define GDBSTUB_SINGLE_STEP 0x4
 
 /* Include definitions for instructions classes and implementations flags */
-//#define PPC_DEBUG_DISAS
-//#define DO_PPC_STATISTICS
+/* #define PPC_DEBUG_DISAS */
+/* #define DO_PPC_STATISTICS */
 
 #ifdef PPC_DEBUG_DISAS
 #  define LOG_DISAS(...) qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__)
@@ -54,9 +54,9 @@
 /* Code translation helpers  */
 
 /* global register indexes */
-static char cpu_reg_names[10*3 + 22*4 /* GPR */
-+ 10*4 + 22*5 /* SPE GPRh */
-+ 8*5 /* CRF */];
+static char cpu_reg_names[10 * 3 + 22 * 4   /* GPR */
+  + 10 * 4 + 22 * 5 /* SPE GPRh */
+  + 8 * 5   /* CRF */];
 static TCGv cpu_gpr[32];
 static TCGv cpu_gprh[32];
 static TCGv_i32 cpu_crf[8];
@@ -78,7 +78,7 @@ static TCGv_i32 cpu_access_type;
 void ppc_translate_init(void)
 {
 int i;
-char* p;
+char *p;
 size_t cpu_reg_names_size;
 
 p = cpu_reg_names;
@@ -146,7 +146,8 @@ void ppc_translate_init(void)
offsetof(CPUPPCState, fpscr), "fpscr");
 
 cpu_access_type = tcg_global_mem_new_i32(cpu_env,
- offsetof(CPUPPCState, 
access_type), "access_type");
+ offsetof(CPUPPCState, 
access_type),
+ "access_type");
 }
 
 /* internal defines */
@@ -246,8 +247,9 @@ static void gen_exception_err(DisasContext *ctx, uint32_t 
excp, uint32_t error)
 {
 TCGv_i32 t0, t1;
 
-/* These are all synchronous exceptions, we set the PC back to
- * the faulting instruction
+/*
+ * These are all synchronous exceptions, we set the PC back to the
+ * faulting instruction
  */
 if (ctx->exception == POWERPC_EXCP_NONE) {
 gen_update_nip(ctx, ctx->base.pc_next - 4);
@@ -264,8 +266,9 @@ static void gen_exception(DisasContext *ctx, uint32_t excp)
 {
 TCGv_i32 t0;
 
-/* These are all synchronous exceptions, we set the PC back to
- * the faulting instruction
+/*
+ * These are all synchronous exceptions, we set the PC back to the
+ * faulting instruction
  */
 if (ctx->exception == POWERPC_EXCP_NONE) {
 gen_update_nip(ctx, ctx->base.pc_next - 4);
@@ -320,8 +323,9 @@ static void gen_debug_exception(DisasContext *ctx)
 {
 TCGv_i32 t0;
 
-/* These are all synchronous exceptions, we set the PC back to
- * the faulting instruction
+/*
+ * These are all synchronous exceptions, we set the PC back to the
+ * faulting instruction
  */
 if ((ctx->exception != POWERPC_EXCP_BRANCH) &&
 (ctx->exception != POWERPC_EXCP_SYNC)) {
@@ -602,9 +606,11 @@ static inline void gen_op_cmp(TCGv arg0, TCGv arg1, int s, 
int crf)
 
 tcg_gen_movi_tl(t0, CRF_EQ);
 tcg_gen_movi_tl(t1, CRF_LT);
-tcg_gen_movcond_tl((s ? TCG_COND_LT : TCG_COND_LTU), t0, arg0, arg1, t1, 
t0);
+tcg_gen_movcond_tl((s ? TCG_COND_LT : TCG_COND_LTU),
+   t0, arg0, arg1, t1, t0);
 tcg_gen_movi_tl(t1, CRF_GT);
-tcg_gen_movcond_tl((s ? TCG_COND_GT : TCG_COND_GTU), t0, arg0, arg1, t1, 
t0);
+tcg_gen_movcond_tl((s ? TCG_COND_GT : TCG_COND_GTU),
+   t0, arg0, arg1, t1, t0);
 
 tcg_gen_trunc_tl_i32(t, t0);
 tcg_gen_trunc_tl_i32(cpu_crf[crf], cpu_so);
@@ -840,9 +846,11 @@ static inline void gen_op_arith_add(DisasContext *ctx, 
TCGv ret, TCGv arg1,
 
 if (compute_ca) {
 if (NARROW_MODE(ctx)) {
-/* Caution: a non-obvious corner case of the spec is that we
-   must produce the *entire* 64-bit addition, but produce the
-   carry into bit 32.  */
+/*
+ * Caution: a non-obvious corner case of the spec is that
+ * we must produce the *entire* 64-bit addition, but
+ * produce the carry into bit 32.
+ */
 TCGv t1 = tcg_temp_new();
 tcg_gen_xor_tl(t1, arg1, arg2);/* add without carry */
 tcg_gen_add_tl(t0, arg1, arg2);
@@ -1017,12 +1025,13 @@ static inline void gen_op_arith_divw(DisasContext *ctx, 
TCGv ret, TCGv arg1,
 tcg_temp_free_i32(t2);
 tcg_temp_free_i32(t3);
 
-if (unlikely(Rc(ctx->opcode) != 0))
+if (unlikely(Rc(ctx->opcode) != 0)) {
 gen_set_Rc0(ctx, ret);
+}
 }
 /* Div functions */
 #define GEN_INT_ARITH_DIVW(name, opc3, sign, compute_ov)  \
-static void glue(gen_, name)(DisasContext *ctx)
   \
+static void glue(gen_, name)(DisasContext *ctx)

Re: [Qemu-devel] [PATCH v3 01/15] linux-headers: update to 5.1-rc1

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 03:49:00PM +0100, Cédric Le Goater wrote:
> These changes provide the interface with the KVM device implementing
> the XIVE native exploitation interrupt mode. Also used to retrieve the
> state of the KVM device for the monitor usage and for migration.
> 
> Available from :
> 
>   https://github.com/legoater/linux/commits/xive-5.1

Obviously the final version of this will need to be against a version
in Linus' tree, and you should give a SHA in the commit message.

> 
> Signed-off-by: Cédric Le Goater 
> ---
>  linux-headers/asm-powerpc/kvm.h | 46 +
>  linux-headers/linux/kvm.h   | 11 
>  2 files changed, 57 insertions(+)
> 
> diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
> index 8c876c166ef2..07daf7bf6fe4 100644
> --- a/linux-headers/asm-powerpc/kvm.h
> +++ b/linux-headers/asm-powerpc/kvm.h
> @@ -480,6 +480,8 @@ struct kvm_ppc_cpu_char {
>  #define  KVM_REG_PPC_ICP_PPRI_SHIFT  16  /* pending irq priority */
>  #define  KVM_REG_PPC_ICP_PPRI_MASK   0xff
>  
> +#define KVM_REG_PPC_VP_STATE (KVM_REG_PPC | KVM_REG_SIZE_U128 | 0x8d)
> +
>  /* Device control API: PPC-specific devices */
>  #define KVM_DEV_MPIC_GRP_MISC1
>  #define   KVM_DEV_MPIC_BASE_ADDR 0   /* 64-bit */
> @@ -675,4 +677,48 @@ struct kvm_ppc_cpu_char {
>  #define  KVM_XICS_PRESENTED  (1ULL << 43)
>  #define  KVM_XICS_QUEUED (1ULL << 44)
>  
> +/* POWER9 XIVE Native Interrupt Controller */
> +#define KVM_DEV_XIVE_GRP_CTRL1
> +#define   KVM_DEV_XIVE_RESET 1
> +#define   KVM_DEV_XIVE_EQ_SYNC   2
> +#define KVM_DEV_XIVE_GRP_SOURCE  2   /* 64-bit source 
> identifier */
> +#define KVM_DEV_XIVE_GRP_SOURCE_CONFIG   3   /* 64-bit source 
> identifier */
> +#define KVM_DEV_XIVE_GRP_EQ_CONFIG   4   /* 64-bit EQ identifier */
> +#define KVM_DEV_XIVE_GRP_SOURCE_SYNC 5   /* 64-bit source identifier */
> +
> +/* Layout of 64-bit XIVE source attribute values */
> +#define KVM_XIVE_LEVEL_SENSITIVE (1ULL << 0)
> +#define KVM_XIVE_LEVEL_ASSERTED  (1ULL << 1)
> +
> +/* Layout of 64-bit XIVE source configuration attribute values */
> +#define KVM_XIVE_SOURCE_PRIORITY_SHIFT   0
> +#define KVM_XIVE_SOURCE_PRIORITY_MASK0x7
> +#define KVM_XIVE_SOURCE_SERVER_SHIFT 3
> +#define KVM_XIVE_SOURCE_SERVER_MASK  0xfff8ULL
> +#define KVM_XIVE_SOURCE_MASKED_SHIFT 32
> +#define KVM_XIVE_SOURCE_MASKED_MASK  0x1ULL
> +#define KVM_XIVE_SOURCE_EISN_SHIFT   33
> +#define KVM_XIVE_SOURCE_EISN_MASK0xfffeULL
> +
> +/* Layout of 64-bit EQ identifier */
> +#define KVM_XIVE_EQ_PRIORITY_SHIFT   0
> +#define KVM_XIVE_EQ_PRIORITY_MASK0x7
> +#define KVM_XIVE_EQ_SERVER_SHIFT 3
> +#define KVM_XIVE_EQ_SERVER_MASK  0xfff8ULL
> +
> +/* Layout of EQ configuration values (64 bytes) */
> +struct kvm_ppc_xive_eq {
> + __u32 flags;
> + __u32 qshift;
> + __u64 qaddr;
> + __u32 qtoggle;
> + __u32 qindex;
> + __u8  pad[40];
> +};
> +
> +#define KVM_XIVE_EQ_ALWAYS_NOTIFY0x0001
> +
> +#define KVM_XIVE_TIMA_PAGE_OFFSET0
> +#define KVM_XIVE_ESB_PAGE_OFFSET 4
> +
>  #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index b53ee5974802..49ff307fa094 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -1,3 +1,4 @@
> +
>  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>  #ifndef __LINUX_KVM_H
>  #define __LINUX_KVM_H
> @@ -988,6 +989,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_ARM_VM_IPA_SIZE 165
>  #define KVM_CAP_MANUAL_DIRTY_LOG_PROTECT 166
>  #define KVM_CAP_HYPERV_CPUID 167
> +#define KVM_CAP_PPC_IRQ_XIVE 168
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> @@ -1182,6 +1184,11 @@ struct kvm_create_device {
>   __u32   flags;  /* in: KVM_CREATE_DEVICE_xxx */
>  };
>  
> +struct kvm_destroy_device {
> + __u32   fd; /* in: device handle */
> + __u32   flags;  /* in: unused */
> +};
> +
>  struct kvm_device_attr {
>   __u32   flags;  /* no flags currently defined */
>   __u32   group;  /* device-defined */
> @@ -1211,6 +1218,8 @@ enum kvm_device_type {
>  #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
>   KVM_DEV_TYPE_ARM_VGIC_ITS,
>  #define KVM_DEV_TYPE_ARM_VGIC_ITSKVM_DEV_TYPE_ARM_VGIC_ITS
> + KVM_DEV_TYPE_XIVE,
> +#define KVM_DEV_TYPE_XIVEKVM_DEV_TYPE_XIVE
>   KVM_DEV_TYPE_MAX,
>  };
>  
> @@ -1328,6 +1337,8 @@ struct kvm_s390_ucas_mapping {
>  #define KVM_GET_DEVICE_ATTR_IOW(KVMIO,  0xe2, struct kvm_device_attr)
>  #define KVM_HAS_DEVICE_ATTR_IOW(KVMIO,  0xe3, struct kvm_device_attr)
>  
> +#define KVM_DESTROY_DEVICE _IOWR(KVMIO,  0xf0, struct kvm_destroy_device)
> +
>  /*
>   * ioctls for vcpu fds
>   */

-- 
David Gibson| I'll have my music baroque, and my code

[Qemu-devel] [RFC for-4.1 23/25] target/ppc: Style fixes for translate/vsx-impl.inc.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/translate/vsx-impl.inc.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 508e9199c8..0cb09891a6 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -751,7 +751,7 @@ static void gen_xxpermdi(DisasContext *ctx)
 #define SGN_MASK_SP 0x80008000ull
 
 #define VSX_SCALAR_MOVE(name, op, sgn_mask)   \
-static void glue(gen_, name)(DisasContext * ctx)  \
+static void glue(gen_, name)(DisasContext *ctx)   \
 { \
 TCGv_i64 xb, sgm; \
 if (unlikely(!ctx->vsx_enabled)) {\
@@ -848,7 +848,7 @@ VSX_SCALAR_MOVE_QP(xsnegqp, OP_NEG, SGN_MASK_DP)
 VSX_SCALAR_MOVE_QP(xscpsgnqp, OP_CPSGN, SGN_MASK_DP)
 
 #define VSX_VECTOR_MOVE(name, op, sgn_mask)  \
-static void glue(gen_, name)(DisasContext * ctx) \
+static void glue(gen_, name)(DisasContext *ctx)  \
 {\
 TCGv_i64 xbh, xbl, sgm;  \
 if (unlikely(!ctx->vsx_enabled)) {   \
@@ -910,7 +910,7 @@ VSX_VECTOR_MOVE(xvnegsp, OP_NEG, SGN_MASK_SP)
 VSX_VECTOR_MOVE(xvcpsgnsp, OP_CPSGN, SGN_MASK_SP)
 
 #define GEN_VSX_HELPER_2(name, op1, op2, inval, type) \
-static void gen_##name(DisasContext * ctx)\
+static void gen_##name(DisasContext *ctx) \
 { \
 TCGv_i32 opc; \
 if (unlikely(!ctx->vsx_enabled)) {\
@@ -923,7 +923,7 @@ static void gen_##name(DisasContext * ctx)  
  \
 }
 
 #define GEN_VSX_HELPER_XT_XB_ENV(name, op1, op2, inval, type) \
-static void gen_##name(DisasContext * ctx)\
+static void gen_##name(DisasContext *ctx) \
 { \
 TCGv_i64 t0;  \
 TCGv_i64 t1;  \
@@ -1230,7 +1230,7 @@ static void gen_xxbrw(DisasContext *ctx)
 }
 
 #define VSX_LOGICAL(name, vece, tcg_op)  \
-static void glue(gen_, name)(DisasContext * ctx) \
+static void glue(gen_, name)(DisasContext *ctx)  \
 {\
 if (unlikely(!ctx->vsx_enabled)) {   \
 gen_exception(ctx, POWERPC_EXCP_VSXU);   \
@@ -1251,7 +1251,7 @@ VSX_LOGICAL(xxlnand, MO_64, tcg_gen_gvec_nand)
 VSX_LOGICAL(xxlorc, MO_64, tcg_gen_gvec_orc)
 
 #define VSX_XXMRG(name, high)   \
-static void glue(gen_, name)(DisasContext * ctx)\
+static void glue(gen_, name)(DisasContext *ctx) \
 {   \
 TCGv_i64 a0, a1, b0, b1, tmp;   \
 if (unlikely(!ctx->vsx_enabled)) {  \
@@ -1444,7 +1444,8 @@ static void gen_##name(DisasContext *ctx) 
  \
 xb = tcg_const_tl(xB(ctx->opcode)); \
 t0 = tcg_temp_new_i32();\
 t1 = tcg_temp_new_i64();\
-/* uimm > 15 out of bound and for   \
+/*  \
+ * uimm > 15 out of bound and for   \
  * uimm > 12 handle as per hardware in helper   \
  */ \
 if (uimm > 15) {\
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 07/25] target/ppc: Style fixes for dfp_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/dfp_helper.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/target/ppc/dfp_helper.c b/target/ppc/dfp_helper.c
index 9164fe701b..ddab65c7ba 100644
--- a/target/ppc/dfp_helper.c
+++ b/target/ppc/dfp_helper.c
@@ -1104,19 +1104,19 @@ void helper_##op(CPUPPCState *env, uint64_t *t, 
uint64_t *b, uint32_t s) \
 }\
 }\
  \
-while (offset < (size)/4) {  \
+while (offset < (size) / 4) {\
 n++; \
-digits[(size)/4-n] = dfp_get_bcd_digit_##size(dfp.b64, offset++);\
-if (digits[(size)/4-n] > 10) {   \
+digits[(size) / 4 - n] = dfp_get_bcd_digit_##size(dfp.b64, offset++); \
+if (digits[(size) / 4 - n] > 10) {   \
 dfp_set_FPSCR_flag(, FP_VX | FP_VXCVI, FPSCR_VE);\
 return;  \
 } else { \
-nonzero |= (digits[(size)/4-n] > 0); \
+nonzero |= (digits[(size) / 4 - n] > 0); \
 }\
 }\
  \
 if (nonzero) {   \
-decNumberSetBCD(, digits+((size)/4)-n, n); \
+decNumberSetBCD(, digits+((size) / 4) - n, n); \
 }\
  \
 if (s && sgn)  { \
@@ -1170,13 +1170,13 @@ DFP_HELPER_XEX(dxexq, 128)
 static void dfp_set_raw_exp_64(uint64_t *t, uint64_t raw)
 {
 *t &= 0x8003ULL;
-*t |= (raw << (63-13));
+*t |= (raw << (63 - 13));
 }
 
 static void dfp_set_raw_exp_128(uint64_t *t, uint64_t raw)
 {
 t[HI_IDX] &= 0x80003fffULL;
-t[HI_IDX] |= (raw << (63-17));
+t[HI_IDX] |= (raw << (63 - 17));
 }
 
 #define DFP_HELPER_IEX(op, size)  \
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 19/25] target/ppc: Style fixes for monitor.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/monitor.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
index 04deec8030..451ca722b3 100644
--- a/target/ppc/monitor.c
+++ b/target/ppc/monitor.c
@@ -27,32 +27,33 @@
 #include "monitor/hmp-target.h"
 #include "hmp.h"
 
-static target_long monitor_get_ccr (const struct MonitorDef *md, int val)
+static target_long monitor_get_ccr(const struct MonitorDef *md, int val)
 {
 CPUArchState *env = mon_get_cpu_env();
 unsigned int u;
 int i;
 
 u = 0;
-for (i = 0; i < 8; i++)
+for (i = 0; i < 8; i++) {
 u |= env->crf[i] << (32 - (4 * (i + 1)));
+}
 
 return u;
 }
 
-static target_long monitor_get_decr (const struct MonitorDef *md, int val)
+static target_long monitor_get_decr(const struct MonitorDef *md, int val)
 {
 CPUArchState *env = mon_get_cpu_env();
 return cpu_ppc_load_decr(env);
 }
 
-static target_long monitor_get_tbu (const struct MonitorDef *md, int val)
+static target_long monitor_get_tbu(const struct MonitorDef *md, int val)
 {
 CPUArchState *env = mon_get_cpu_env();
 return cpu_ppc_load_tbu(env);
 }
 
-static target_long monitor_get_tbl (const struct MonitorDef *md, int val)
+static target_long monitor_get_tbl(const struct MonitorDef *md, int val)
 {
 CPUArchState *env = mon_get_cpu_env();
 return cpu_ppc_load_tbl(env);
@@ -66,7 +67,7 @@ void hmp_info_tlb(Monitor *mon, const QDict *qdict)
 monitor_printf(mon, "No CPU available\n");
 return;
 }
-dump_mmu((FILE*)mon, (fprintf_function)monitor_printf, env1);
+dump_mmu((FILE *)mon, (fprintf_function)monitor_printf, env1);
 }
 
 const MonitorDef monitor_defs[] = {
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 00/25] Many style fixes for target/ppc

2019-03-21 Thread David Gibson
target/ppc has a lot of old code that doesn't stick to the modern
style guidelines.  That means we keep getting checkpatch warnings from
code motions in there, or from people copying the local style rather
than the global style.

I'm sick of it, so here's a big series to fix many of the style
problems in target/ppc.

It doesn't cover every checkpatch warning: outright false positives
are ignored of course, but there are also some things that it's not
obvious how to fix (often involving hairy nested macros).  Still, it's
a good start.

Alexey Kardashevskiy (1):
  spapr: Support NVIDIA V100 GPU with NVLink2

David Gibson (23):
  target/ppc: Style fixes for ppc-models.[ch]
  target/ppc: Style fixes for cpu.[ch]
  target/ppc: Style fixes for int_helper.c
  target/ppc: Style fixes for fpu_helper.c
  target/ppc: Style fixes for dfp_helper.c
  target/ppc: Style fixes for excp_helper.c
  target/ppc: Style fixes for gdbstub.c
  target/ppc: Style fixes for helper_regs.h
  target/ppc: Style fixes for kvm_ppc.h and kvm.c
  target/ppc: Style fixes for machine.c
  target/ppc: Style fixes for mem_helper.c
  target/ppc: Style fixes for mfrom_table.inc.c & mfrom_table_gen.c
  target/ppc: Style fixes for misc_helper.c
  target/ppc: Style fixes for mmu-hash32.[ch]
  target/ppc: Style fixes for mmu-hash64.[ch]
  target/ppc: Style fixes for mmu_helper.c
  target/ppc: Style fixes for monitor.c
  target/ppc: Style fixes for translate_init.inc.c
  target/ppc: Style fixes for translate.c
  target/ppc: Style fixes for translate/fp-impl.inc.c
  target/ppc: Style fixes for translate/vsx-impl.inc.c
  target/ppc: Style fixes for translate/vmx-impl.inc.c
  target/ppc: Style fixes for translate/spe-impl.inc.c

Philippe Mathieu-Daudé (1):
  hw/ppc/prep: Drop useless inclusion of "hw/input/i8042.h"

 hw/ppc/Makefile.objs|   2 +-
 hw/ppc/prep.c   |   1 -
 hw/ppc/spapr.c  |  48 ++-
 hw/ppc/spapr_pci.c  |  19 ++
 hw/ppc/spapr_pci_nvlink2.c  | 450 
 hw/vfio/pci-quirks.c| 131 +++
 hw/vfio/pci.c   |  14 +
 hw/vfio/pci.h   |   2 +
 hw/vfio/trace-events|   4 +
 include/hw/pci-host/spapr.h |  45 +++
 include/hw/ppc/spapr.h  |   5 +-
 target/ppc/cpu-models.c |   2 +-
 target/ppc/cpu-models.h |   3 +-
 target/ppc/cpu.h| 239 +++--
 target/ppc/dfp_helper.c |  14 +-
 target/ppc/excp_helper.c|  87 +++--
 target/ppc/fpu_helper.c | 134 +---
 target/ppc/gdbstub.c|  34 +-
 target/ppc/helper_regs.h|  10 +-
 target/ppc/int_helper.c |  70 ++--
 target/ppc/kvm.c| 178 ++
 target/ppc/kvm_ppc.h|   3 +-
 target/ppc/machine.c| 106 +++---
 target/ppc/mem_helper.c |  33 +-
 target/ppc/mfrom_table.inc.c|   3 +-
 target/ppc/mfrom_table_gen.c|   8 +-
 target/ppc/misc_helper.c|   9 +-
 target/ppc/mmu-hash32.c |  19 +-
 target/ppc/mmu-hash64.c |  62 ++--
 target/ppc/mmu_helper.c | 131 ---
 target/ppc/monitor.c|  13 +-
 target/ppc/translate.c  | 507 +---
 target/ppc/translate/fp-impl.inc.c  |  52 +--
 target/ppc/translate/spe-impl.inc.c |  14 +-
 target/ppc/translate/vmx-impl.inc.c |  26 +-
 target/ppc/translate/vsx-impl.inc.c |  15 +-
 target/ppc/translate_init.inc.c | 240 +++--
 37 files changed, 1921 insertions(+), 812 deletions(-)
 create mode 100644 hw/ppc/spapr_pci_nvlink2.c

-- 
2.20.1




[Qemu-devel] [RFC for-4.1 20/25] target/ppc: Style fixes for translate_init.inc.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/translate_init.inc.c | 240 +++-
 1 file changed, 146 insertions(+), 94 deletions(-)

diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c
index 0bd555eb19..78e4cd3e87 100644
--- a/target/ppc/translate_init.inc.c
+++ b/target/ppc/translate_init.inc.c
@@ -40,12 +40,13 @@
 #include "fpu/softfloat.h"
 #include "qapi/qapi-commands-target.h"
 
-//#define PPC_DUMP_CPU
-//#define PPC_DEBUG_SPR
-//#define PPC_DUMP_SPR_ACCESSES
+/* #define PPC_DUMP_CPU */
+/* #define PPC_DEBUG_SPR */
+/* #define PPC_DUMP_SPR_ACCESSES */
 /* #define USE_APPLE_GDB */
 
-/* Generic callbacks:
+/*
+ * Generic callbacks:
  * do nothing but store/retrieve spr value
  */
 static void spr_load_dump_spr(int sprn)
@@ -57,7 +58,7 @@ static void spr_load_dump_spr(int sprn)
 #endif
 }
 
-static void spr_read_generic (DisasContext *ctx, int gprn, int sprn)
+static void spr_read_generic(DisasContext *ctx, int gprn, int sprn)
 {
 gen_load_spr(cpu_gpr[gprn], sprn);
 spr_load_dump_spr(sprn);
@@ -229,13 +230,13 @@ static void spr_read_tbu(DisasContext *ctx, int gprn, int 
sprn)
 }
 }
 
-__attribute__ (( unused ))
+ATTRIBUTE_UNUSED
 static void spr_read_atbl(DisasContext *ctx, int gprn, int sprn)
 {
 gen_helper_load_atbl(cpu_gpr[gprn], cpu_env);
 }
 
-__attribute__ (( unused ))
+ATTRIBUTE_UNUSED
 static void spr_read_atbu(DisasContext *ctx, int gprn, int sprn)
 {
 gen_helper_load_atbu(cpu_gpr[gprn], cpu_env);
@@ -266,20 +267,20 @@ static void spr_write_tbu(DisasContext *ctx, int sprn, 
int gprn)
 }
 }
 
-__attribute__ (( unused ))
+ATTRIBUTE_UNUSED
 static void spr_write_atbl(DisasContext *ctx, int sprn, int gprn)
 {
 gen_helper_store_atbl(cpu_env, cpu_gpr[gprn]);
 }
 
-__attribute__ (( unused ))
+ATTRIBUTE_UNUSED
 static void spr_write_atbu(DisasContext *ctx, int sprn, int gprn)
 {
 gen_helper_store_atbu(cpu_env, cpu_gpr[gprn]);
 }
 
 #if defined(TARGET_PPC64)
-__attribute__ (( unused ))
+ATTRIBUTE_UNUSED
 static void spr_read_purr(DisasContext *ctx, int gprn, int sprn)
 {
 gen_helper_load_purr(cpu_gpr[gprn], cpu_env);
@@ -318,12 +319,16 @@ static void spr_write_hdecr(DisasContext *ctx, int sprn, 
int gprn)
 /* IBAT0L...IBAT7L */
 static void spr_read_ibat(DisasContext *ctx, int gprn, int sprn)
 {
-tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env, offsetof(CPUPPCState, IBAT[sprn & 
1][(sprn - SPR_IBAT0U) / 2]));
+tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env,
+  offsetof(CPUPPCState,
+   IBAT[sprn & 1][(sprn - SPR_IBAT0U) / 2]));
 }
 
 static void spr_read_ibat_h(DisasContext *ctx, int gprn, int sprn)
 {
-tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env, offsetof(CPUPPCState, IBAT[sprn & 
1][((sprn - SPR_IBAT4U) / 2) + 4]));
+tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env,
+  offsetof(CPUPPCState,
+   IBAT[sprn & 1][((sprn - SPR_IBAT4U) / 2) + 4]));
 }
 
 static void spr_write_ibatu(DisasContext *ctx, int sprn, int gprn)
@@ -358,12 +363,16 @@ static void spr_write_ibatl_h(DisasContext *ctx, int 
sprn, int gprn)
 /* DBAT0L...DBAT7L */
 static void spr_read_dbat(DisasContext *ctx, int gprn, int sprn)
 {
-tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env, offsetof(CPUPPCState, DBAT[sprn & 
1][(sprn - SPR_DBAT0U) / 2]));
+tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env,
+  offsetof(CPUPPCState,
+   DBAT[sprn & 1][(sprn - SPR_DBAT0U) / 2]));
 }
 
 static void spr_read_dbat_h(DisasContext *ctx, int gprn, int sprn)
 {
-tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env, offsetof(CPUPPCState, DBAT[sprn & 
1][((sprn - SPR_DBAT4U) / 2) + 4]));
+tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env,
+  offsetof(CPUPPCState,
+   DBAT[sprn & 1][((sprn - SPR_DBAT4U) / 2) + 4]));
 }
 
 static void spr_write_dbatu(DisasContext *ctx, int sprn, int gprn)
@@ -472,7 +481,9 @@ static void spr_write_hid0_601(DisasContext *ctx, int sprn, 
int gprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_read_601_ubat(DisasContext *ctx, int gprn, int sprn)
 {
-tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env, offsetof(CPUPPCState, IBAT[sprn & 
1][(sprn - SPR_IBAT0U) / 2]));
+tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env,
+  offsetof(CPUPPCState,
+   IBAT[sprn & 1][(sprn - SPR_IBAT0U) / 2]));
 }
 
 static void spr_write_601_ubatu(DisasContext *ctx, int sprn, int gprn)
@@ -531,7 +542,8 @@ static void spr_write_booke_tsr(DisasContext *ctx, int 
sprn, int gprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_read_403_pbr(DisasContext *ctx, int gprn, int sprn)
 {
-tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env, offsetof(CPUPPCState, pb[sprn - 
SPR_403_PBL1]));
+tcg_gen_ld_tl(cpu_gpr[gprn], cpu_env,
+  offsetof(CPUPPCState, pb[sprn - SPR_403_PBL1]));
 }
 
 static void spr_write_403_pbr(DisasContext *ctx, int sprn, int gprn)
@@ -660,14 +672,20 @@ static inline void vscr_init(CPUPPCState *env, uint32_t 
val)
 
 static 

[Qemu-devel] [RFC for-4.1 25/25] target/ppc: Style fixes for translate/spe-impl.inc.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/translate/spe-impl.inc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/target/ppc/translate/spe-impl.inc.c 
b/target/ppc/translate/spe-impl.inc.c
index 8c1c16c63e..7ab0a29b5f 100644
--- a/target/ppc/translate/spe-impl.inc.c
+++ b/target/ppc/translate/spe-impl.inc.c
@@ -18,7 +18,8 @@ static inline void gen_evmra(DisasContext *ctx)
 TCGv_i64 tmp = tcg_temp_new_i64();
 
 /* tmp := rA_lo + rA_hi << 32 */
-tcg_gen_concat_tl_i64(tmp, cpu_gpr[rA(ctx->opcode)], 
cpu_gprh[rA(ctx->opcode)]);
+tcg_gen_concat_tl_i64(tmp, cpu_gpr[rA(ctx->opcode)],
+  cpu_gprh[rA(ctx->opcode)]);
 
 /* spe_acc := tmp */
 tcg_gen_st_i64(tmp, cpu_env, offsetof(CPUPPCState, spe_acc));
@@ -780,7 +781,7 @@ static inline void gen_op_evstwwo(DisasContext *ctx, TCGv 
addr)
 }
 
 #define GEN_SPEOP_LDST(name, opc2, sh)\
-static void glue(gen_, name)(DisasContext *ctx)
   \
+static void glue(gen_, name)(DisasContext *ctx)   \
 { \
 TCGv t0;  \
 if (unlikely(!ctx->spe_enabled)) {\
@@ -1089,7 +1090,8 @@ static inline void gen_efsabs(DisasContext *ctx)
 gen_exception(ctx, POWERPC_EXCP_SPEU);
 return;
 }
-tcg_gen_andi_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)], 
(target_long)~0x8000LL);
+tcg_gen_andi_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)],
+(target_long)~0x8000LL);
 }
 static inline void gen_efsnabs(DisasContext *ctx)
 {
@@ -1097,7 +1099,8 @@ static inline void gen_efsnabs(DisasContext *ctx)
 gen_exception(ctx, POWERPC_EXCP_SPEU);
 return;
 }
-tcg_gen_ori_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)], 
0x8000);
+tcg_gen_ori_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)],
+   0x8000);
 }
 static inline void gen_efsneg(DisasContext *ctx)
 {
@@ -1105,7 +1108,8 @@ static inline void gen_efsneg(DisasContext *ctx)
 gen_exception(ctx, POWERPC_EXCP_SPEU);
 return;
 }
-tcg_gen_xori_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)], 
0x8000);
+tcg_gen_xori_tl(cpu_gpr[rD(ctx->opcode)], cpu_gpr[rA(ctx->opcode)],
+0x8000);
 }
 
 /* Conversion */
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 06/25] target/ppc: Style fixes for fpu_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/fpu_helper.c | 134 +---
 1 file changed, 83 insertions(+), 51 deletions(-)

diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index 2ed4f42275..0b7308f539 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -90,10 +90,12 @@ uint32_t helper_tosingle(uint64_t arg)
 ret  = extract64(arg, 62, 2) << 30;
 ret |= extract64(arg, 29, 30);
 } else {
-/* Zero or Denormal result.  If the exponent is in bounds for
- * a single-precision denormal result, extract the proper bits.
- * If the input is not zero, and the exponent is out of bounds,
- * then the result is undefined; this underflows to zero.
+/*
+ * Zero or Denormal result.  If the exponent is in bounds for
+ * a single-precision denormal result, extract the proper
+ * bits.  If the input is not zero, and the exponent is out of
+ * bounds, then the result is undefined; this underflows to
+ * zero.
  */
 ret = extract64(arg, 63, 1) << 31;
 if (unlikely(exp >= 874)) {
@@ -1090,7 +1092,7 @@ uint32_t helper_ftsqrt(uint64_t frb)
 fe_flag = 1;
 } else if (unlikely(float64_is_neg(frb))) {
 fe_flag = 1;
-} else if (!float64_is_zero(frb) && (e_b <= (-1022+52))) {
+} else if (!float64_is_zero(frb) && (e_b <= (-1022 + 52))) {
 fe_flag = 1;
 }
 
@@ -1789,7 +1791,8 @@ uint32_t helper_efdcmpeq(CPUPPCState *env, uint64_t op1, 
uint64_t op2)
 #define float64_to_float64(x, env) x
 
 
-/* VSX_ADD_SUB - VSX floating point add/subract
+/*
+ * VSX_ADD_SUB - VSX floating point add/subract
  *   name  - instruction mnemonic
  *   op- operation (add or sub)
  *   nels  - number of elements (1, 2 or 4)
@@ -1872,7 +1875,8 @@ void helper_xsaddqp(CPUPPCState *env, uint32_t opcode)
 do_float_check_status(env, GETPC());
 }
 
-/* VSX_MUL - VSX floating point multiply
+/*
+ * VSX_MUL - VSX floating point multiply
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
  *   tp- type (float32 or float64)
@@ -1950,7 +1954,8 @@ void helper_xsmulqp(CPUPPCState *env, uint32_t opcode)
 do_float_check_status(env, GETPC());
 }
 
-/* VSX_DIV - VSX floating point divide
+/*
+ * VSX_DIV - VSX floating point divide
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
  *   tp- type (float32 or float64)
@@ -2034,7 +2039,8 @@ void helper_xsdivqp(CPUPPCState *env, uint32_t opcode)
 do_float_check_status(env, GETPC());
 }
 
-/* VSX_RE  - VSX floating point reciprocal estimate
+/*
+ * VSX_RE  - VSX floating point reciprocal estimate
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
  *   tp- type (float32 or float64)
@@ -2075,7 +2081,8 @@ VSX_RE(xsresp, 1, float64, VsrD(0), 1, 1)
 VSX_RE(xvredp, 2, float64, VsrD(i), 0, 0)
 VSX_RE(xvresp, 4, float32, VsrW(i), 0, 0)
 
-/* VSX_SQRT - VSX floating point square root
+/*
+ * VSX_SQRT - VSX floating point square root
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
  *   tp- type (float32 or float64)
@@ -2124,7 +2131,8 @@ VSX_SQRT(xssqrtsp, 1, float64, VsrD(0), 1, 1)
 VSX_SQRT(xvsqrtdp, 2, float64, VsrD(i), 0, 0)
 VSX_SQRT(xvsqrtsp, 4, float32, VsrW(i), 0, 0)
 
-/* VSX_RSQRTE - VSX floating point reciprocal square root estimate
+/*
+ *VSX_RSQRTE - VSX floating point reciprocal square root estimate
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
  *   tp- type (float32 or float64)
@@ -2174,7 +2182,8 @@ VSX_RSQRTE(xsrsqrtesp, 1, float64, VsrD(0), 1, 1)
 VSX_RSQRTE(xvrsqrtedp, 2, float64, VsrD(i), 0, 0)
 VSX_RSQRTE(xvrsqrtesp, 4, float32, VsrW(i), 0, 0)
 
-/* VSX_TDIV - VSX floating point test for divide
+/*
+ * VSX_TDIV - VSX floating point test for divide
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
  *   tp- type (float32 or float64)
@@ -2207,18 +2216,20 @@ void helper_##op(CPUPPCState *env, uint32_t opcode) 
\
 if (unlikely(tp##_is_any_nan(xa.fld) || \
  tp##_is_any_nan(xb.fld))) {\
 fe_flag = 1;\
-} else if ((e_b <= emin) || (e_b >= (emax-2))) {\
+} else if ((e_b <= emin) || (e_b >= (emax - 2))) {  \
 fe_flag = 1;\
 } else if (!tp##_is_zero(xa.fld) && \
(((e_a - e_b) >= emax) ||\
-((e_a - e_b) <= (emin+1)) ||\
- (e_a <= (emin+nbits {  \
+((e_a - e_b) <= (emin + 1)) ||  \
+

[Qemu-devel] [RFC for-4.1 02/25] hw/ppc/prep: Drop useless inclusion of "hw/input/i8042.h"

2019-03-21 Thread David Gibson
From: Philippe Mathieu-Daudé 

In commit 47973a2dbf we split the last generic chipset out of
the PC board, but missed to remove the i8042 keyboard controller.
This omission was later fixed in commit 7cb00357c1, but here we
forgot to remove the "i8042.h" include. Do it now.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20190316201528.9140-1-phi...@redhat.com>
Signed-off-by: David Gibson 
---
 hw/ppc/prep.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 847d320465..b7f459d475 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -40,7 +40,6 @@
 #include "hw/ide.h"
 #include "hw/loader.h"
 #include "hw/timer/mc146818rtc.h"
-#include "hw/input/i8042.h"
 #include "hw/isa/pc87312.h"
 #include "hw/net/ne2000-isa.h"
 #include "sysemu/arch_init.h"
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 01/25] spapr: Support NVIDIA V100 GPU with NVLink2

2019-03-21 Thread David Gibson
From: 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 as the GPU RAM
needs to be configured equally distant from any other node in the system.
Unlike the host setup which assigns numa ids from 255 downwards, this
adds new NUMA nodes after the user configures nodes or from 1 if none
were configured.

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 
[aw: for vfio portions]
Acked-by: Alex Williamson 
Message-Id: <20190312082103.130561-1-...@ozlabs.ru>
Signed-off-by: David Gibson 
---
 hw/ppc/Makefile.objs|   2 +-
 hw/ppc/spapr.c  |  48 +++-
 hw/ppc/spapr_pci.c  |  19 ++
 hw/ppc/spapr_pci_nvlink2.c  | 450 
 hw/vfio/pci-quirks.c| 131 +++
 hw/vfio/pci.c   |  14 ++
 hw/vfio/pci.h   |   2 +
 hw/vfio/trace-events|   4 +
 include/hw/pci-host/spapr.h |  45 
 include/hw/ppc/spapr.h  |   5 +-
 10 files changed, 711 insertions(+), 9 deletions(-)
 create mode 100644 hw/ppc/spapr_pci_nvlink2.c

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index b218a0..636e717f20 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -9,7 +9,7 @@ obj-$(CONFIG_SPAPR_RNG) +=  spapr_rng.o
 # IBM PowerNV
 obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
pnv_occ.o pnv_bmc.o
 ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
-obj-y += spapr_pci_vfio.o
+obj-y += spapr_pci_vfio.o spapr_pci_nvlink2.o
 endif
 obj-$(CONFIG_PSERIES) += spapr_rtas_ddw.o
 # PowerPC 4xx boards
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 6c16d6cfaf..adde36a01d 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1034,12 +1034,13 @@ static void spapr_dt_rtas(SpaprMachineState *spapr, 
void *fdt)
 0, cpu_to_be32(SPAPR_MEMORY_BLOCK_SIZE),
 cpu_to_be32(max_cpus / smp_threads),
 };
+uint32_t maxdomain = cpu_to_be32(spapr->gpu_numa_id > 1 ? 1 : 0);
 uint32_t maxdomains[] = {
 cpu_to_be32(4),
-cpu_to_be32(0),
-cpu_to_be32(0),
-cpu_to_be32(0),
-cpu_to_be32(nb_numa_nodes ? nb_numa_nodes : 1),
+maxdomain,
+maxdomain,
+maxdomain,
+cpu_to_be32(spapr->gpu_numa_id),
 };
 
 _FDT(rtas = fdt_add_subnode(fdt, 0, "rtas"));
@@ -1713,6 +1714,16 @@ static void spapr_machine_reset(void)
 spapr_irq_msi_reset(spapr);
 }
 
+/*
+ * NVLink2-connected GPU RAM needs to be placed on a separate NUMA node.
+ * We assign a new numa ID per GPU in spapr_pci_collect_nvgpu() which is
+ * called from vPHB reset handler so we initialize the counter here.
+ * If no NUMA is configured from the QEMU side, we start from 1 as GPU RAM
+ * must be equally distant from any other node.
+ * The final value of spapr->gpu_numa_id is going to be written to
+ * max-associativity-domains in spapr_build_fdt().
+ */
+spapr->gpu_numa_id = MAX(1, nb_numa_nodes);
 qemu_devices_reset();
 
 /*
@@ -3928,7 +3939,9 @@ static void spapr_phb_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 smc->phb_placement(spapr, sphb->index,
>buid, 

[Qemu-devel] [RFC for-4.1 10/25] target/ppc: Style fixes for helper_regs.h

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/helper_regs.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/target/ppc/helper_regs.h b/target/ppc/helper_regs.h
index a2205e1044..8397819dee 100644
--- a/target/ppc/helper_regs.h
+++ b/target/ppc/helper_regs.h
@@ -44,10 +44,11 @@ static inline void hreg_swap_gpr_tgpr(CPUPPCState *env)
 
 static inline void hreg_compute_mem_idx(CPUPPCState *env)
 {
-/* This is our encoding for server processors. The architecture
+/*
+ * This is our encoding for server processors. The architecture
  * specifies that there is no such thing as userspace with
- * translation off, however it appears that MacOS does it and
- * some 32-bit CPUs support it. Weird...
+ * translation off, however it appears that MacOS does it and some
+ * 32-bit CPUs support it. Weird...
  *
  *   0 = Guest User space virtual mode
  *   1 = Guest Kernel space virtual mode
@@ -143,7 +144,8 @@ static inline int hreg_store_msr(CPUPPCState *env, 
target_ulong value,
 /* Change the exception prefix on PowerPC 601 */
 env->excp_prefix = ((value >> MSR_EP) & 1) * 0xFFF0;
 }
-/* If PR=1 then EE, IR and DR must be 1
+/*
+ * If PR=1 then EE, IR and DR must be 1
  *
  * Note: We only enforce this on 64-bit server processors.
  * It appears that:
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 22/25] target/ppc: Style fixes for translate/fp-impl.inc.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/translate/fp-impl.inc.c | 52 ++
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/target/ppc/translate/fp-impl.inc.c 
b/target/ppc/translate/fp-impl.inc.c
index 0f21a4e477..9dcff947c0 100644
--- a/target/ppc/translate/fp-impl.inc.c
+++ b/target/ppc/translate/fp-impl.inc.c
@@ -585,11 +585,13 @@ static void gen_mcrfs(DisasContext *ctx)
 shift = 4 * nibble;
 tcg_gen_shri_tl(tmp, cpu_fpscr, shift);
 tcg_gen_trunc_tl_i32(cpu_crf[crfD(ctx->opcode)], tmp);
-tcg_gen_andi_i32(cpu_crf[crfD(ctx->opcode)], cpu_crf[crfD(ctx->opcode)], 
0xf);
+tcg_gen_andi_i32(cpu_crf[crfD(ctx->opcode)], cpu_crf[crfD(ctx->opcode)],
+ 0xf);
 tcg_temp_free(tmp);
 tcg_gen_extu_tl_i64(tnew_fpscr, cpu_fpscr);
 /* Only the exception bits (including FX) should be cleared if read */
-tcg_gen_andi_i64(tnew_fpscr, tnew_fpscr, ~((0xF << shift) & 
FP_EX_CLEAR_BITS));
+tcg_gen_andi_i64(tnew_fpscr, tnew_fpscr,
+ ~((0xF << shift) & FP_EX_CLEAR_BITS));
 /* FEX and VX need to be updated, so don't set fpscr directly */
 tmask = tcg_const_i32(1 << nibble);
 gen_helper_store_fpscr(cpu_env, tnew_fpscr, tmask);
@@ -735,7 +737,7 @@ static void gen_mtfsfi(DisasContext *ctx)
 
 /*** Floating-point load   ***/
 #define GEN_LDF(name, ldop, opc, type)\
-static void glue(gen_, name)(DisasContext *ctx)
   \
+static void glue(gen_, name)(DisasContext *ctx)   \
 { \
 TCGv EA;  \
 TCGv_i64 t0;  \
@@ -754,7 +756,7 @@ static void glue(gen_, name)(DisasContext *ctx)
 }
 
 #define GEN_LDUF(name, ldop, opc, type)   \
-static void glue(gen_, name##u)(DisasContext *ctx) 
   \
+static void glue(gen_, name##u)(DisasContext *ctx)\
 { \
 TCGv EA;  \
 TCGv_i64 t0;  \
@@ -778,7 +780,7 @@ static void glue(gen_, name##u)(DisasContext *ctx)
 }
 
 #define GEN_LDUXF(name, ldop, opc, type)  \
-static void glue(gen_, name##ux)(DisasContext *ctx)
   \
+static void glue(gen_, name##ux)(DisasContext *ctx)   \
 { \
 TCGv EA;  \
 TCGv_i64 t0;  \
@@ -802,7 +804,7 @@ static void glue(gen_, name##ux)(DisasContext *ctx)
 }
 
 #define GEN_LDXF(name, ldop, opc2, opc3, type)\
-static void glue(gen_, name##x)(DisasContext *ctx) 
   \
+static void glue(gen_, name##x)(DisasContext *ctx)\
 { \
 TCGv EA;  \
 TCGv_i64 t0;  \
@@ -872,8 +874,10 @@ static void gen_lfdp(DisasContext *ctx)
 EA = tcg_temp_new();
 gen_addr_imm_index(ctx, EA, 0);
 t0 = tcg_temp_new_i64();
-/* We only need to swap high and low halves. gen_qemu_ld64_i64 does
-   necessary 64-bit byteswap already. */
+/*
+ * We only need to swap high and low halves. gen_qemu_ld64_i64
+ * does necessary 64-bit byteswap already.
+ */
 if (unlikely(ctx->le_mode)) {
 gen_qemu_ld64_i64(ctx, t0, EA);
 set_fpr(rD(ctx->opcode) + 1, t0);
@@ -904,8 +908,10 @@ static void gen_lfdpx(DisasContext *ctx)
 EA = tcg_temp_new();
 gen_addr_reg_index(ctx, EA);
 t0 = tcg_temp_new_i64();
-/* We only need to swap high and low halves. gen_qemu_ld64_i64 does
-   necessary 64-bit byteswap already. */
+/*
+ * We only need to swap high and low halves. gen_qemu_ld64_i64
+ * does necessary 64-bit byteswap already.
+ */
 if (unlikely(ctx->le_mode)) {
 gen_qemu_ld64_i64(ctx, t0, EA);
 set_fpr(rD(ctx->opcode) + 1, t0);
@@ -966,7 +972,7 @@ static void gen_lfiwzx(DisasContext *ctx)
 }
 /*** Floating-point store  ***/
 #define GEN_STF(name, stop, opc, type)\
-static void glue(gen_, name)(DisasContext *ctx)
   \
+static void glue(gen_, 

[Qemu-devel] [RFC for-4.1 03/25] target/ppc: Style fixes for ppc-models.[ch]

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/cpu-models.c | 2 +-
 target/ppc/cpu-models.h | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/ppc/cpu-models.c b/target/ppc/cpu-models.c
index 7c75963e3c..9d7050b5fa 100644
--- a/target/ppc/cpu-models.c
+++ b/target/ppc/cpu-models.c
@@ -740,7 +740,7 @@
 POWERPC_DEF("7457a_v1.2",CPU_POWERPC_74x7A_v12,  7455,
 "PowerPC 7457A v1.2 (G4)")
 /* 64 bits PowerPC   */
-#if defined (TARGET_PPC64)
+#if defined(TARGET_PPC64)
 POWERPC_DEF("970_v2.2",  CPU_POWERPC_970_v22,970,
 "PowerPC 970 v2.2")
 POWERPC_DEF("970fx_v1.0",CPU_POWERPC_970FX_v10,  970,
diff --git a/target/ppc/cpu-models.h b/target/ppc/cpu-models.h
index efdb2fa53c..4fdb73034d 100644
--- a/target/ppc/cpu-models.h
+++ b/target/ppc/cpu-models.h
@@ -393,7 +393,8 @@ enum {
 CPU_POWERPC_RS64IV = 0x0037,
 #endif /* defined(TARGET_PPC64) */
 /* Original POWER */
-/* XXX: should be POWER (RIOS), RSC3308, RSC4608,
+/*
+ * XXX: should be POWER (RIOS), RSC3308, RSC4608,
  * POWER2 (RIOS2) & RSC2 (P2SC) here
  */
 /* PA Semi core */
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 11/25] target/ppc: Style fixes for kvm_ppc.h and kvm.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/kvm.c | 178 +++
 target/ppc/kvm_ppc.h |   3 +-
 2 files changed, 115 insertions(+), 66 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 2427c8ee13..a1c223385d 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -49,7 +49,7 @@
 #include "elf.h"
 #include "sysemu/kvm_int.h"
 
-//#define DEBUG_KVM
+/* #define DEBUG_KVM */
 
 #ifdef DEBUG_KVM
 #define DPRINTF(fmt, ...) \
@@ -65,8 +65,8 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 KVM_CAP_LAST_INFO
 };
 
-static int cap_interrupt_unset = false;
-static int cap_interrupt_level = false;
+static int cap_interrupt_unset;
+static int cap_interrupt_level;
 static int cap_segstate;
 static int cap_booke_sregs;
 static int cap_ppc_smt;
@@ -96,7 +96,8 @@ static int cap_large_decr;
 
 static uint32_t debug_inst_opcode;
 
-/* XXX We have a race condition where we actually have a level triggered
+/*
+ * XXX We have a race condition where we actually have a level triggered
  * interrupt, but the infrastructure can't expose that yet, so the guest
  * takes but ignores it, goes to sleep and never gets notified that there's
  * still an interrupt pending.
@@ -114,10 +115,12 @@ static void kvm_kick_cpu(void *opaque)
 qemu_cpu_kick(CPU(cpu));
 }
 
-/* Check whether we are running with KVM-PR (instead of KVM-HV).  This
+/*
+ * Check whether we are running with KVM-PR (instead of KVM-HV).  This
  * should only be used for fallback tests - generally we should use
  * explicit capabilities for the features we want, rather than
- * assuming what is/isn't available depending on the KVM variant. */
+ * assuming what is/isn't available depending on the KVM variant.
+ */
 static bool kvmppc_is_pr(KVMState *ks)
 {
 /* Assume KVM-PR if the GET_PVINFO capability is available */
@@ -143,8 +146,10 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 cap_hior = kvm_check_extension(s, KVM_CAP_PPC_HIOR);
 cap_epr = kvm_check_extension(s, KVM_CAP_PPC_EPR);
 cap_ppc_watchdog = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_WATCHDOG);
-/* Note: we don't set cap_papr here, because this capability is
- * only activated after this by kvmppc_set_papr() */
+/*
+ * Note: we don't set cap_papr here, because this capability is
+ * only activated after this by kvmppc_set_papr()
+ */
 cap_htab_fd = kvm_vm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
 cap_fixup_hcalls = kvm_check_extension(s, KVM_CAP_PPC_FIXUP_HCALL);
 cap_ppc_smt = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT);
@@ -160,7 +165,8 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
  * in KVM at this moment.
  *
  * TODO: call kvm_vm_check_extension() with the right capability
- * after the kernel starts implementing it.*/
+ * after the kernel starts implementing it.
+ */
 cap_ppc_pvr_compat = false;
 
 if (!cap_interrupt_level) {
@@ -186,10 +192,13 @@ static int kvm_arch_sync_sregs(PowerPCCPU *cpu)
 int ret;
 
 if (cenv->excp_model == POWERPC_EXCP_BOOKE) {
-/* What we're really trying to say is "if we're on BookE, we use
-   the native PVR for now". This is the only sane way to check
-   it though, so we potentially confuse users that they can run
-   BookE guests on BookS. Let's hope nobody dares enough :) */
+/*
+ * What we're really trying to say is "if we're on BookE, we
+ * use the native PVR for now". This is the only sane way to
+ * check it though, so we potentially confuse users that they
+ * can run BookE guests on BookS. Let's hope nobody dares
+ * enough :)
+ */
 return 0;
 } else {
 if (!cap_segstate) {
@@ -421,12 +430,14 @@ void kvm_check_mmu(PowerPCCPU *cpu, Error **errp)
 }
 
 if (ppc_hash64_has(cpu, PPC_HASH64_CI_LARGEPAGE)) {
-/* Mostly what guest pagesizes we can use are related to the
+/*
+ * Mostly what guest pagesizes we can use are related to the
  * host pages used to map guest RAM, which is handled in the
  * platform code. Cache-Inhibited largepages (64k) however are
  * used for I/O, so if they're mapped to the host at all it
  * will be a normal mapping, not a special hugepage one used
- * for RAM. */
+ * for RAM.
+ */
 if (getpagesize() < 0x1) {
 error_setg(errp,
"KVM can't supply 64kiB CI pages, which guest expects");
@@ -440,9 +451,9 @@ unsigned long kvm_arch_vcpu_id(CPUState *cpu)
 return POWERPC_CPU(cpu)->vcpu_id;
 }
 
-/* e500 supports 2 h/w breakpoint and 2 watchpoint.
- * book3s supports only 1 watchpoint, so array size
- * of 4 is sufficient for now.
+/*
+ * e500 supports 2 h/w breakpoint and 2 watchpoint.  book3s supports
+ * only 1 watchpoint, so array size of 4 is sufficient for now.
  */
 #define MAX_HW_BKPTS 4
 
@@ -497,9 +508,12 

[Qemu-devel] [RFC for-4.1 04/25] target/ppc: Style fixes for cpu.[ch]

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/cpu.h | 239 ++-
 1 file changed, 130 insertions(+), 109 deletions(-)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index fc12b4688e..5d25b17539 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -23,23 +23,28 @@
 #include "qemu-common.h"
 #include "qemu/int128.h"
 
-//#define PPC_EMULATE_32BITS_HYPV
+/* #define PPC_EMULATE_32BITS_HYPV */
 
-#if defined (TARGET_PPC64)
+#if defined(TARGET_PPC64)
 /* PowerPC 64 definitions */
 #define TARGET_LONG_BITS 64
 #define TARGET_PAGE_BITS 12
 
 #define TCG_GUEST_DEFAULT_MO 0
 
-/* Note that the official physical address space bits is 62-M where M
-   is implementation dependent.  I've not looked up M for the set of
-   cpus we emulate at the system level.  */
+/*
+ * Note that the official physical address space bits is 62-M where M
+ * is implementation dependent.  I've not looked up M for the set of
+ * cpus we emulate at the system level.
+ */
 #define TARGET_PHYS_ADDR_SPACE_BITS 62
 
-/* Note that the PPC environment architecture talks about 80 bit virtual
-   addresses, with segmentation.  Obviously that's not all visible to a
-   single process, which is all we're concerned with here.  */
+/*
+ * Note that the PPC environment architecture talks about 80 bit
+ * virtual addresses, with segmentation.  Obviously that's not all
+ * visible to a single process, which is all we're concerned with
+ * here.
+ */
 #ifdef TARGET_ABI32
 # define TARGET_VIRT_ADDR_SPACE_BITS 32
 #else
@@ -49,7 +54,7 @@
 #define TARGET_PAGE_BITS_64K 16
 #define TARGET_PAGE_BITS_16M 24
 
-#else /* defined (TARGET_PPC64) */
+#else /* defined(TARGET_PPC64) */
 /* PowerPC 32 definitions */
 #define TARGET_LONG_BITS 32
 #define TARGET_PAGE_BITS 12
@@ -57,14 +62,14 @@
 #define TARGET_PHYS_ADDR_SPACE_BITS 36
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
-#endif /* defined (TARGET_PPC64) */
+#endif /* defined(TARGET_PPC64) */
 
 #define CPUArchState struct CPUPPCState
 
 #include "exec/cpu-defs.h"
 #include "cpu-qom.h"
 
-#if defined (TARGET_PPC64)
+#if defined(TARGET_PPC64)
 #define PPC_ELF_MACHINE EM_PPC64
 #else
 #define PPC_ELF_MACHINE EM_PPC
@@ -237,9 +242,11 @@ struct ppc_spr_t {
 const char *name;
 target_ulong default_value;
 #ifdef CONFIG_KVM
-/* We (ab)use the fact that all the SPRs will have ids for the
+/*
+ * We (ab)use the fact that all the SPRs will have ids for the
  * ONE_REG interface will have KVM_REG_PPC to use 0 as meaning,
- * don't sync this */
+ * don't sync this
+ */
 uint64_t one_reg_id;
 #endif
 };
@@ -656,39 +663,39 @@ enum {
 #define fpscr_eex (((env->fpscr) >> FPSCR_XX) & ((env->fpscr) >> FPSCR_XE) &  \
0x1F)
 
-#define FP_FX  (1ull << FPSCR_FX)
-#define FP_FEX (1ull << FPSCR_FEX)
-#define FP_VX  (1ull << FPSCR_VX)
-#define FP_OX  (1ull << FPSCR_OX)
-#define FP_UX  (1ull << FPSCR_UX)
-#define FP_ZX  (1ull << FPSCR_ZX)
-#define FP_XX  (1ull << FPSCR_XX)
-#define FP_VXSNAN  (1ull << FPSCR_VXSNAN)
-#define FP_VXISI   (1ull << FPSCR_VXISI)
-#define FP_VXIDI   (1ull << FPSCR_VXIDI)
-#define FP_VXZDZ   (1ull << FPSCR_VXZDZ)
-#define FP_VXIMZ   (1ull << FPSCR_VXIMZ)
-#define FP_VXVC(1ull << FPSCR_VXVC)
-#define FP_FR  (1ull << FSPCR_FR)
-#define FP_FI  (1ull << FPSCR_FI)
-#define FP_C   (1ull << FPSCR_C)
-#define FP_FL  (1ull << FPSCR_FL)
-#define FP_FG  (1ull << FPSCR_FG)
-#define FP_FE  (1ull << FPSCR_FE)
-#define FP_FU  (1ull << FPSCR_FU)
-#define FP_FPCC(FP_FL | FP_FG | FP_FE | FP_FU)
-#define FP_FPRF(FP_C  | FP_FL | FP_FG | FP_FE | FP_FU)
-#define FP_VXSOFT  (1ull << FPSCR_VXSOFT)
-#define FP_VXSQRT  (1ull << FPSCR_VXSQRT)
-#define FP_VXCVI   (1ull << FPSCR_VXCVI)
-#define FP_VE  (1ull << FPSCR_VE)
-#define FP_OE  (1ull << FPSCR_OE)
-#define FP_UE  (1ull << FPSCR_UE)
-#define FP_ZE  (1ull << FPSCR_ZE)
-#define FP_XE  (1ull << FPSCR_XE)
-#define FP_NI  (1ull << FPSCR_NI)
-#define FP_RN1 (1ull << FPSCR_RN1)
-#define FP_RN  (1ull << FPSCR_RN)
+#define FP_FX   (1ull << FPSCR_FX)
+#define FP_FEX  (1ull << FPSCR_FEX)
+#define FP_VX   (1ull << FPSCR_VX)
+#define FP_OX   (1ull << FPSCR_OX)
+#define FP_UX   (1ull << FPSCR_UX)
+#define FP_ZX   (1ull << FPSCR_ZX)
+#define FP_XX   (1ull << FPSCR_XX)
+#define FP_VXSNAN   (1ull << FPSCR_VXSNAN)
+#define FP_VXISI(1ull << FPSCR_VXISI)
+#define FP_VXIDI(1ull << FPSCR_VXIDI)
+#define FP_VXZDZ(1ull << FPSCR_VXZDZ)
+#define FP_VXIMZ(1ull << FPSCR_VXIMZ)
+#define FP_VXVC (1ull << FPSCR_VXVC)
+#define FP_FR   (1ull << FSPCR_FR)
+#define FP_FI   (1ull << FPSCR_FI)
+#define FP_C(1ull << FPSCR_C)
+#define FP_FL 

[Qemu-devel] [RFC for-4.1 18/25] target/ppc: Style fixes for mmu_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/mmu_helper.c | 131 
 1 file changed, 80 insertions(+), 51 deletions(-)

diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
index 4a6be4d63b..a01a12a4af 100644
--- a/target/ppc/mmu_helper.c
+++ b/target/ppc/mmu_helper.c
@@ -32,11 +32,11 @@
 #include "mmu-book3s-v3.h"
 #include "mmu-radix64.h"
 
-//#define DEBUG_MMU
-//#define DEBUG_BATS
-//#define DEBUG_SOFTWARE_TLB
-//#define DUMP_PAGE_TABLES
-//#define FLUSH_ALL_TLBS
+/* #define DEBUG_MMU */
+/* #define DEBUG_BATS */
+/* #define DEBUG_SOFTWARE_TLB */
+/* #define DUMP_PAGE_TABLES */
+/* #define FLUSH_ALL_TLBS */
 
 #ifdef DEBUG_MMU
 #  define LOG_MMU_STATE(cpu) log_cpu_state_mask(CPU_LOG_MMU, (cpu), 0)
@@ -151,7 +151,8 @@ static int check_prot(int prot, int rw, int access_type)
 }
 
 static inline int ppc6xx_tlb_pte_check(mmu_ctx_t *ctx, target_ulong pte0,
-   target_ulong pte1, int h, int rw, int 
type)
+   target_ulong pte1, int h,
+   int rw, int type)
 {
 target_ulong ptem, mmask;
 int access, ret, pteh, ptev, pp;
@@ -331,7 +332,8 @@ static inline int ppc6xx_tlb_check(CPUPPCState *env, 
mmu_ctx_t *ctx,
   pte_is_valid(tlb->pte0) ? "valid" : "inval",
   tlb->EPN, eaddr, tlb->pte1,
   rw ? 'S' : 'L', access_type == ACCESS_CODE ? 'I' : 'D');
-switch (ppc6xx_tlb_pte_check(ctx, tlb->pte0, tlb->pte1, 0, rw, 
access_type)) {
+switch (ppc6xx_tlb_pte_check(ctx, tlb->pte0, tlb->pte1,
+ 0, rw, access_type)) {
 case -3:
 /* TLB inconsistency */
 return -1;
@@ -346,9 +348,11 @@ static inline int ppc6xx_tlb_check(CPUPPCState *env, 
mmu_ctx_t *ctx,
 break;
 case 0:
 /* access granted */
-/* XXX: we should go on looping to check all TLBs consistency
- *  but we can speed-up the whole thing as the
- *  result would be undefined if TLBs are not consistent.
+/*
+ * XXX: we should go on looping to check all TLBs
+ *  consistency but we can speed-up the whole thing as
+ *  the result would be undefined if TLBs are not
+ *  consistent.
  */
 ret = 0;
 best = nr;
@@ -549,14 +553,17 @@ static inline int get_segment_6xx_tlb(CPUPPCState *env, 
mmu_ctx_t *ctx,
 qemu_log_mask(CPU_LOG_MMU, "direct store...\n");
 /* Direct-store segment : absolutely *BUGGY* for now */
 
-/* Direct-store implies a 32-bit MMU.
+/*
+ * Direct-store implies a 32-bit MMU.
  * Check the Segment Register's bus unit ID (BUID).
  */
 sr = env->sr[eaddr >> 28];
 if ((sr & 0x1FF0) >> 20 == 0x07f) {
 /* Memory-forced I/O controller interface access */
-/* If T=1 and BUID=x'07F', the 601 performs a memory access
- * to SR[28-31] LA[4-31], bypassing all protection mechanisms.
+/*
+ * If T=1 and BUID=x'07F', the 601 performs a memory
+ * access to SR[28-31] LA[4-31], bypassing all protection
+ * mechanisms.
  */
 ctx->raddr = ((sr & 0xF) << 28) | (eaddr & 0x0FFF);
 ctx->prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
@@ -578,8 +585,9 @@ static inline int get_segment_6xx_tlb(CPUPPCState *env, 
mmu_ctx_t *ctx,
 return -4;
 case ACCESS_CACHE:
 /* dcba, dcbt, dcbtst, dcbf, dcbi, dcbst, dcbz, or icbi */
-/* Should make the instruction do no-op.
- * As it already do no-op, it's quite easy :-)
+/*
+ * Should make the instruction do no-op.  As it already do
+ * no-op, it's quite easy :-)
  */
 ctx->raddr = eaddr;
 return 0;
@@ -941,12 +949,14 @@ static uint32_t mmubooke206_esr(int mmu_idx, bool rw)
 return esr;
 }
 
-/* Get EPID register given the mmu_idx. If this is regular load,
- * construct the EPID access bits from current processor state  */
-
-/* Get the effective AS and PR bits and the PID. The PID is returned only if
- * EPID load is requested, otherwise the caller must detect the correct EPID.
- * Return true if valid EPID is returned. */
+/*
+ * Get EPID register given the mmu_idx. If this is regular load,
+ * construct the EPID access bits from current processor state
+ *
+ * Get the effective AS and PR bits and the PID. The PID is returned
+ * only if EPID load is requested, otherwise the caller must detect
+ * the correct EPID.  Return true if valid EPID is returned.
+ */
 static bool mmubooke206_get_as(CPUPPCState *env,
int mmu_idx, uint32_t *epid_out,
bool *as_out, bool *pr_out)
@@ -1373,8 +1383,9 @@ 

[Qemu-devel] [RFC for-4.1 24/25] target/ppc: Style fixes for translate/vmx-impl.inc.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/translate/vmx-impl.inc.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/target/ppc/translate/vmx-impl.inc.c 
b/target/ppc/translate/vmx-impl.inc.c
index eb10c533ca..bd3ff40e68 100644
--- a/target/ppc/translate/vmx-impl.inc.c
+++ b/target/ppc/translate/vmx-impl.inc.c
@@ -15,7 +15,7 @@ static inline TCGv_ptr gen_avr_ptr(int reg)
 }
 
 #define GEN_VR_LDX(name, opc2, opc3)  \
-static void glue(gen_, name)(DisasContext *ctx)
   \
+static void glue(gen_, name)(DisasContext *ctx)   \
 { \
 TCGv EA;  \
 TCGv_i64 avr; \
@@ -28,8 +28,10 @@ static void glue(gen_, name)(DisasContext *ctx)
 EA = tcg_temp_new();  \
 gen_addr_reg_index(ctx, EA);  \
 tcg_gen_andi_tl(EA, EA, ~0xf);\
-/* We only need to swap high and low halves. gen_qemu_ld64_i64 does   \
-   necessary 64-bit byteswap already. */  \
+/*\
+ * We only need to swap high and low halves. gen_qemu_ld64_i64\
+ * does necessary 64-bit byteswap already.\
+ */   \
 if (ctx->le_mode) {   \
 gen_qemu_ld64_i64(ctx, avr, EA);  \
 set_avr64(rD(ctx->opcode), avr, false);   \
@@ -61,8 +63,10 @@ static void gen_st##name(DisasContext *ctx)  
 \
 EA = tcg_temp_new();  \
 gen_addr_reg_index(ctx, EA);  \
 tcg_gen_andi_tl(EA, EA, ~0xf);\
-/* We only need to swap high and low halves. gen_qemu_st64_i64 does   \
-   necessary 64-bit byteswap already. */  \
+/*\
+ * We only need to swap high and low halves. gen_qemu_st64_i64\
+ * does necessary 64-bit byteswap already.\
+ */   \
 if (ctx->le_mode) {   \
 get_avr64(avr, rD(ctx->opcode), false);   \
 gen_qemu_st64_i64(ctx, avr, EA);  \
@@ -296,7 +300,7 @@ GEN_VXFORM_V(vnand, MO_64, tcg_gen_gvec_nand, 2, 22);
 GEN_VXFORM_V(vorc, MO_64, tcg_gen_gvec_orc, 2, 21);
 
 #define GEN_VXFORM(name, opc2, opc3)\
-static void glue(gen_, name)(DisasContext *ctx)
 \
+static void glue(gen_, name)(DisasContext *ctx) \
 {   \
 TCGv_ptr ra, rb, rd;\
 if (unlikely(!ctx->altivec_enabled)) {  \
@@ -306,7 +310,7 @@ static void glue(gen_, name)(DisasContext *ctx)
 ra = gen_avr_ptr(rA(ctx->opcode));  \
 rb = gen_avr_ptr(rB(ctx->opcode));  \
 rd = gen_avr_ptr(rD(ctx->opcode));  \
-gen_helper_##name (rd, ra, rb); \
+gen_helper_##name(rd, ra, rb);  \
 tcg_temp_free_ptr(ra);  \
 tcg_temp_free_ptr(rb);  \
 tcg_temp_free_ptr(rd);  \
@@ -758,7 +762,7 @@ GEN_VXFORM_DUPI(vspltish, tcg_gen_gvec_dup16i, 6, 13);
 GEN_VXFORM_DUPI(vspltisw, tcg_gen_gvec_dup32i, 6, 14);
 
 #define GEN_VXFORM_NOA(name, opc2, opc3)\
-static void glue(gen_, name)(DisasContext *ctx)
 \
+static void glue(gen_, name)(DisasContext *ctx) \
 {   \
 TCGv_ptr rb, rd;\
 if (unlikely(!ctx->altivec_enabled)) {  \
@@ -767,9 +771,9 @@ static void glue(gen_, name)(DisasContext *ctx)
 }  

[Qemu-devel] [RFC for-4.1 12/25] target/ppc: Style fixes for machine.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/machine.c | 106 +--
 1 file changed, 63 insertions(+), 43 deletions(-)

diff --git a/target/ppc/machine.c b/target/ppc/machine.c
index a92d0ad3a3..25cdb9088b 100644
--- a/target/ppc/machine.c
+++ b/target/ppc/machine.c
@@ -24,22 +24,26 @@ static int cpu_load_old(QEMUFile *f, void *opaque, int 
version_id)
 #endif
 target_ulong xer;
 
-for (i = 0; i < 32; i++)
+for (i = 0; i < 32; i++) {
 qemu_get_betls(f, >gpr[i]);
+}
 #if !defined(TARGET_PPC64)
-for (i = 0; i < 32; i++)
+for (i = 0; i < 32; i++) {
 qemu_get_betls(f, >gprh[i]);
+}
 #endif
 qemu_get_betls(f, >lr);
 qemu_get_betls(f, >ctr);
-for (i = 0; i < 8; i++)
+for (i = 0; i < 8; i++) {
 qemu_get_be32s(f, >crf[i]);
+}
 qemu_get_betls(f, );
 cpu_write_xer(env, xer);
 qemu_get_betls(f, >reserve_addr);
 qemu_get_betls(f, >msr);
-for (i = 0; i < 4; i++)
+for (i = 0; i < 4; i++) {
 qemu_get_betls(f, >tgpr[i]);
+}
 for (i = 0; i < 32; i++) {
 union {
 float64 d;
@@ -56,14 +60,19 @@ static int cpu_load_old(QEMUFile *f, void *opaque, int 
version_id)
 qemu_get_sbe32s(f, _nr);
 #endif
 qemu_get_betls(f, );
-for (i = 0; i < 32; i++)
+for (i = 0; i < 32; i++) {
 qemu_get_betls(f, >sr[i]);
-for (i = 0; i < 2; i++)
-for (j = 0; j < 8; j++)
+}
+for (i = 0; i < 2; i++) {
+for (j = 0; j < 8; j++) {
 qemu_get_betls(f, >DBAT[i][j]);
-for (i = 0; i < 2; i++)
-for (j = 0; j < 8; j++)
+}
+}
+for (i = 0; i < 2; i++) {
+for (j = 0; j < 8; j++) {
 qemu_get_betls(f, >IBAT[i][j]);
+}
+}
 qemu_get_sbe32s(f, >nb_tlb);
 qemu_get_sbe32s(f, >tlb_per_way);
 qemu_get_sbe32s(f, >nb_ways);
@@ -71,17 +80,19 @@ static int cpu_load_old(QEMUFile *f, void *opaque, int 
version_id)
 qemu_get_sbe32s(f, >id_tlbs);
 qemu_get_sbe32s(f, >nb_pids);
 if (env->tlb.tlb6) {
-// XXX assumes 6xx
+/* XXX assumes 6xx */
 for (i = 0; i < env->nb_tlb; i++) {
 qemu_get_betls(f, >tlb.tlb6[i].pte0);
 qemu_get_betls(f, >tlb.tlb6[i].pte1);
 qemu_get_betls(f, >tlb.tlb6[i].EPN);
 }
 }
-for (i = 0; i < 4; i++)
+for (i = 0; i < 4; i++) {
 qemu_get_betls(f, >pb[i]);
-for (i = 0; i < 1024; i++)
+}
+for (i = 0; i < 1024; i++) {
 qemu_get_betls(f, >spr[i]);
+}
 if (!cpu->vhyp) {
 ppc_store_sdr1(env, sdr1);
 }
@@ -94,8 +105,9 @@ static int cpu_load_old(QEMUFile *f, void *opaque, int 
version_id)
 qemu_get_sbe32s(f, >error_code);
 qemu_get_be32s(f, >pending_interrupts);
 qemu_get_be32s(f, >irq_input_state);
-for (i = 0; i < POWERPC_EXCP_NB; i++)
+for (i = 0; i < POWERPC_EXCP_NB; i++) {
 qemu_get_betls(f, >excp_vectors[i]);
+}
 qemu_get_betls(f, >excp_prefix);
 qemu_get_betls(f, >ivor_mask);
 qemu_get_betls(f, >ivpr_mask);
@@ -253,22 +265,24 @@ static int cpu_pre_save(void *opaque)
 env->spr[SPR_BOOKE_SPEFSCR] = env->spe_fscr;
 
 for (i = 0; (i < 4) && (i < env->nb_BATs); i++) {
-env->spr[SPR_DBAT0U + 2*i] = env->DBAT[0][i];
-env->spr[SPR_DBAT0U + 2*i + 1] = env->DBAT[1][i];
-env->spr[SPR_IBAT0U + 2*i] = env->IBAT[0][i];
-env->spr[SPR_IBAT0U + 2*i + 1] = env->IBAT[1][i];
+env->spr[SPR_DBAT0U + 2 * i] = env->DBAT[0][i];
+env->spr[SPR_DBAT0U + 2 * i + 1] = env->DBAT[1][i];
+env->spr[SPR_IBAT0U + 2 * i] = env->IBAT[0][i];
+env->spr[SPR_IBAT0U + 2 * i + 1] = env->IBAT[1][i];
 }
-for (i = 0; (i < 4) && ((i+4) < env->nb_BATs); i++) {
-env->spr[SPR_DBAT4U + 2*i] = env->DBAT[0][i+4];
-env->spr[SPR_DBAT4U + 2*i + 1] = env->DBAT[1][i+4];
-env->spr[SPR_IBAT4U + 2*i] = env->IBAT[0][i+4];
-env->spr[SPR_IBAT4U + 2*i + 1] = env->IBAT[1][i+4];
+for (i = 0; (i < 4) && ((i + 4) < env->nb_BATs); i++) {
+env->spr[SPR_DBAT4U + 2 * i] = env->DBAT[0][i + 4];
+env->spr[SPR_DBAT4U + 2 * i + 1] = env->DBAT[1][i + 4];
+env->spr[SPR_IBAT4U + 2 * i] = env->IBAT[0][i + 4];
+env->spr[SPR_IBAT4U + 2 * i + 1] = env->IBAT[1][i + 4];
 }
 
 /* Hacks for migration compatibility between 2.6, 2.7 & 2.8 */
 if (cpu->pre_2_8_migration) {
-/* Mask out bits that got added to msr_mask since the versions
- * which stupidly included it in the migration stream. */
+/*
+ * Mask out bits that got added to msr_mask since the versions
+ * which stupidly included it in the migration stream.
+ */
 target_ulong metamask = 0
 #if defined(TARGET_PPC64)
 | (1ULL << MSR_TS0)
@@ -277,9 +291,10 @@ static int cpu_pre_save(void *opaque)
 ;
 cpu->mig_msr_mask = env->msr_mask & ~metamask;
 

[Qemu-devel] [RFC for-4.1 08/25] target/ppc: Style fixes for excp_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/excp_helper.c | 87 
 1 file changed, 53 insertions(+), 34 deletions(-)

diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index beafcf1ebd..ec2c177091 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -25,9 +25,9 @@
 #include "internal.h"
 #include "helper_regs.h"
 
-//#define DEBUG_OP
-//#define DEBUG_SOFTWARE_TLB
-//#define DEBUG_EXCEPTIONS
+/* #define DEBUG_OP */
+/* #define DEBUG_SOFTWARE_TLB */
+/* #define DEBUG_EXCEPTIONS */
 
 #ifdef DEBUG_EXCEPTIONS
 #  define LOG_EXCP(...) qemu_log(__VA_ARGS__)
@@ -126,8 +126,9 @@ static uint64_t ppc_excp_vector_offset(CPUState *cs, int 
ail)
 return offset;
 }
 
-/* Note that this function should be greatly optimized
- * when called with a constant excp, from ppc_hw_interrupt
+/*
+ * Note that this function should be greatly optimized when called
+ * with a constant excp, from ppc_hw_interrupt
  */
 static inline void powerpc_excp(PowerPCCPU *cpu, int excp_model, int excp)
 {
@@ -147,7 +148,8 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 msr = env->msr & ~0x783fULL;
 }
 
-/* new interrupt handler msr preserves existing HV and ME unless
+/*
+ * new interrupt handler msr preserves existing HV and ME unless
  * explicitly overriden
  */
 new_msr = env->msr & (((target_ulong)1 << MSR_ME) | MSR_HVB);
@@ -166,7 +168,8 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 excp = powerpc_reset_wakeup(cs, env, excp, );
 }
 
-/* Exception targetting modifiers
+/*
+ * Exception targetting modifiers
  *
  * LPES0 is supported on POWER7/8/9
  * LPES1 is not supported (old iSeries mode)
@@ -194,7 +197,8 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 ail = 0;
 }
 
-/* Hypervisor emulation assistance interrupt only exists on server
+/*
+ * Hypervisor emulation assistance interrupt only exists on server
  * arch 2.05 server or later. We also don't want to generate it if
  * we don't have HVB in msr_mask (PAPR mode).
  */
@@ -229,8 +233,9 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 break;
 case POWERPC_EXCP_MCHECK:/* Machine check exception  */
 if (msr_me == 0) {
-/* Machine check exception is not enabled.
- * Enter checkstop state.
+/*
+ * Machine check exception is not enabled.  Enter
+ * checkstop state.
  */
 fprintf(stderr, "Machine check while not allowed. "
 "Entering checkstop state\n");
@@ -242,8 +247,9 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 cpu_interrupt_exittb(cs);
 }
 if (env->msr_mask & MSR_HVB) {
-/* ISA specifies HV, but can be delivered to guest with HV clear
- * (e.g., see FWNMI in PAPR).
+/*
+ * ISA specifies HV, but can be delivered to guest with HV
+ * clear (e.g., see FWNMI in PAPR).
  */
 new_msr |= (target_ulong)MSR_HVB;
 }
@@ -294,9 +300,10 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 break;
 case POWERPC_EXCP_ALIGN: /* Alignment exception  */
 /* Get rS/rD and rA from faulting opcode */
-/* Note: the opcode fields will not be set properly for a direct
- * store load/store, but nobody cares as nobody actually uses
- * direct store segments.
+/*
+ * Note: the opcode fields will not be set properly for a
+ * direct store load/store, but nobody cares as nobody
+ * actually uses direct store segments.
  */
 env->spr[SPR_DSISR] |= (env->error_code & 0x03FF) >> 16;
 break;
@@ -310,7 +317,8 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 return;
 }
 
-/* FP exceptions always have NIP pointing to the faulting
+/*
+ * FP exceptions always have NIP pointing to the faulting
  * instruction, so always use store_next and claim we are
  * precise in the MSR.
  */
@@ -341,7 +349,8 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 dump_syscall(env);
 lev = env->error_code;
 
-/* We need to correct the NIP which in this case is supposed
+/*
+ * We need to correct the NIP which in this case is supposed
  * to point to the next instruction
  */
 env->nip += 4;
@@ -425,8 +434,9 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 new_msr |= ((target_ulong)1 << MSR_ME);
 }
 if 

[Qemu-devel] [RFC for-4.1 09/25] target/ppc: Style fixes for gdbstub.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/gdbstub.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
index fbf3821f4b..ce3625f44e 100644
--- a/target/ppc/gdbstub.c
+++ b/target/ppc/gdbstub.c
@@ -33,14 +33,14 @@ static int ppc_gdb_register_len_apple(int n)
 return 8;
 case 64 ... 95:
 return 16;
-case 64+32: /* nip */
-case 65+32: /* msr */
-case 67+32: /* lr */
-case 68+32: /* ctr */
-case 70+32: /* fpscr */
+case 64 + 32: /* nip */
+case 65 + 32: /* msr */
+case 67 + 32: /* lr */
+case 68 + 32: /* ctr */
+case 70 + 32: /* fpscr */
 return 8;
-case 66+32: /* cr */
-case 69+32: /* xer */
+case 66 + 32: /* cr */
+case 69 + 32: /* xer */
 return 4;
 default:
 return 0;
@@ -84,11 +84,14 @@ static int ppc_gdb_register_len(int n)
 }
 }
 
-/* We need to present the registers to gdb in the "current" memory ordering.
-   For user-only mode we get this for free; TARGET_WORDS_BIGENDIAN is set to
-   the proper ordering for the binary, and cannot be changed.
-   For system mode, TARGET_WORDS_BIGENDIAN is always set, and we must check
-   the current mode of the chip to see if we're running in little-endian.  */
+/*
+ * We need to present the registers to gdb in the "current" memory
+ * ordering.  For user-only mode we get this for free;
+ * TARGET_WORDS_BIGENDIAN is set to the proper ordering for the
+ * binary, and cannot be changed.  For system mode,
+ * TARGET_WORDS_BIGENDIAN is always set, and we must check the current
+ * mode of the chip to see if we're running in little-endian.
+ */
 void ppc_maybe_bswap_register(CPUPPCState *env, uint8_t *mem_buf, int len)
 {
 #ifndef CONFIG_USER_ONLY
@@ -104,11 +107,12 @@ void ppc_maybe_bswap_register(CPUPPCState *env, uint8_t 
*mem_buf, int len)
 #endif
 }
 
-/* Old gdb always expects FP registers.  Newer (xml-aware) gdb only
+/*
+ * Old gdb always expects FP registers.  Newer (xml-aware) gdb only
  * expects whatever the target description contains.  Due to a
  * historical mishap the FP registers appear in between core integer
- * regs and PC, MSR, CR, and so forth.  We hack round this by giving the
- * FP regs zero size when talking to a newer gdb.
+ * regs and PC, MSR, CR, and so forth.  We hack round this by giving
+ * the FP regs zero size when talking to a newer gdb.
  */
 
 int ppc_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
-- 
2.20.1




[Qemu-devel] [RFC for-4.1 05/25] target/ppc: Style fixes for int_helper.c

2019-03-21 Thread David Gibson
Signed-off-by: David Gibson 
---
 target/ppc/int_helper.c | 70 +++--
 1 file changed, 39 insertions(+), 31 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 162add561e..f6a088ac08 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -137,7 +137,8 @@ uint64_t helper_divde(CPUPPCState *env, uint64_t rau, 
uint64_t rbu, uint32_t oe)
 /* if x = 0xab, returns 0xababababababababa */
 #define pattern(x) (((x) & 0xff) * (~(target_ulong)0 / 0xff))
 
-/* substract 1 from each byte, and with inverse, check if MSB is set at each
+/*
+ * subtract 1 from each byte, and with inverse, check if MSB is set at each
  * byte.
  * i.e. ((0x00 - 0x01) & ~(0x00)) & 0x80
  *  (0xFF & 0xFF) & 0x80 = 0x80 (zero found)
@@ -156,7 +157,8 @@ uint32_t helper_cmpeqb(target_ulong ra, target_ulong rb)
 #undef haszero
 #undef hasvalue
 
-/* Return invalid random number.
+/*
+ * Return invalid random number.
  *
  * FIXME: Add rng backend or other mechanism to get cryptographically suitable
  * random number
@@ -181,7 +183,7 @@ uint64_t helper_bpermd(uint64_t rs, uint64_t rb)
 uint64_t ra = 0;
 
 for (i = 0; i < 8; i++) {
-int index = (rs >> (i*8)) & 0xFF;
+int index = (rs >> (i * 8)) & 0xFF;
 if (index < 64) {
 if (rb & PPC_BIT(index)) {
 ra |= 1 << i;
@@ -370,7 +372,8 @@ target_ulong helper_divso(CPUPPCState *env, target_ulong 
arg1,
 /* 602 specific instructions */
 /* mfrom is the most crazy instruction ever seen, imho ! */
 /* Real implementation uses a ROM table. Do the same */
-/* Extremely decomposed:
+/*
+ * Extremely decomposed:
  *  -arg / 256
  * return 256 * log10(10   + 1.0) + 0.5
  */
@@ -393,7 +396,7 @@ target_ulong helper_602_mfrom(target_ulong arg)
 for (index = 0; index < ARRAY_SIZE(r->element); index++)
 #else
 #define VECTOR_FOR_INORDER_I(index, element)\
-for (index = ARRAY_SIZE(r->element)-1; index >= 0; index--)
+for (index = ARRAY_SIZE(r->element) - 1; index >= 0; index--)
 #endif
 
 /* Saturating arithmetic helpers.  */
@@ -634,7 +637,8 @@ void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t 
*b)   \
 }   \
 }
 
-/* VABSDU - Vector absolute difference unsigned
+/*
+ * VABSDU - Vector absolute difference unsigned
  *   name- instruction mnemonic suffix (b: byte, h: halfword, w: word)
  *   element - element type to access from vector
  */
@@ -739,7 +743,8 @@ void helper_vcmpne##suffix(CPUPPCState *env, ppc_avr_t *r,  
\
 }   \
 }
 
-/* VCMPNEZ - Vector compare not equal to zero
+/*
+ * VCMPNEZ - Vector compare not equal to zero
  *   suffix  - instruction mnemonic suffix (b: byte, h: halfword, w: word)
  *   element - element type to access from vector
  */
@@ -1138,7 +1143,7 @@ void helper_vpermr(CPUPPCState *env, ppc_avr_t *r, 
ppc_avr_t *a, ppc_avr_t *b,
 #define VBPERMQ_DW(index) (((index) & 0x40) != 0)
 #define EXTRACT_BIT(avr, i, index) (extract64((avr)->u64[i], index, 1))
 #else
-#define VBPERMQ_INDEX(avr, i) ((avr)->u8[15-(i)])
+#define VBPERMQ_INDEX(avr, i) ((avr)->u8[15 - (i)])
 #define VBPERMD_INDEX(i) (1 - i)
 #define VBPERMQ_DW(index) (((index) & 0x40) == 0)
 #define EXTRACT_BIT(avr, i, index) \
@@ -1169,7 +1174,7 @@ void helper_vbpermq(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t 
*b)
 int index = VBPERMQ_INDEX(b, i);
 
 if (index < 128) {
-uint64_t mask = (1ull << (63-(index & 0x3F)));
+uint64_t mask = (1ull << (63 - (index & 0x3F)));
 if (a->u64[VBPERMQ_DW(index)] & mask) {
 perm |= (0x8000 >> i);
 }
@@ -1449,9 +1454,9 @@ void helper_vgbbd(ppc_avr_t *r, ppc_avr_t *b)
 
 VECTOR_FOR_INORDER_I(i, u8) {
 #if defined(HOST_WORDS_BIGENDIAN)
-t[i>>3] |= VGBBD_MASKS[b->u8[i]] >> (i & 7);
+t[i >> 3] |= VGBBD_MASKS[b->u8[i]] >> (i & 7);
 #else
-t[i>>3] |= VGBBD_MASKS[b->u8[i]] >> (7-(i & 7));
+t[i >> 3] |= VGBBD_MASKS[b->u8[i]] >> (7 - (i & 7));
 #endif
 }
 
@@ -1463,19 +1468,19 @@ void helper_vgbbd(ppc_avr_t *r, ppc_avr_t *b)
 void helper_##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)  \
 { \
 int i, j; \
-trgtyp prod[sizeof(ppc_avr_t)/sizeof(a->srcfld[0])];  \
+trgtyp prod[sizeof(ppc_avr_t) / sizeof(a->srcfld[0])];\
   \
 VECTOR_FOR_INORDER_I(i, srcfld) { \
 prod[i] = 0;  \
 for (j = 0; j < sizeof(a->srcfld[0]) * 8; j++) {  \
-if (a->srcfld[i] & (1ullsrcfld[i] 

Re: [Qemu-devel] [PATCH v4] hw/acpi: extract acpi_add_rom_blob()

2019-03-21 Thread Wei Yang
On Thu, Mar 21, 2019 at 02:50:42PM +0100, Igor Mammedov wrote:
>On Thu, 21 Mar 2019 08:21:53 +0800
>Wei Yang  wrote:
>
>> arm and i386 has almost the same function acpi_add_rom_blob(), except
>> giving different FWCfgCallback function.
>> 
>> This patch moves acpi_add_rom_blob() to utils.c by passing
>> FWCfgCallback to it.
>> 
>> Signed-off-by: Wei Yang 
>> 
>> ---
>> v4:
>>   * extract -> moves
>>   * adjust comment in source to make checkpatch happy
>> v3:
>>   * put acpi_add_rom_blob() to hw/acpi/utils.c
>> v2:
>>   * remove unused header in original source file
>> ---
>>  hw/acpi/Makefile.objs|  2 +-
>>  hw/acpi/utils.c  | 36 
>>  hw/arm/virt-acpi-build.c | 26 ++
>>  hw/i386/acpi-build.c | 26 ++
>>  include/hw/acpi/utils.h  |  9 +
>>  5 files changed, 66 insertions(+), 33 deletions(-)
>>  create mode 100644 hw/acpi/utils.c
>>  create mode 100644 include/hw/acpi/utils.h
>> 
>> diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
>> index 2d46e3789a..ba93c5b64a 100644
>> --- a/hw/acpi/Makefile.objs
>> +++ b/hw/acpi/Makefile.objs
>> @@ -10,7 +10,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
>>  
>>  common-obj-y += acpi_interface.o
>>  common-obj-y += bios-linker-loader.o
>> -common-obj-y += aml-build.o
>> +common-obj-y += aml-build.o utils.o
>>  common-obj-$(CONFIG_TPM) += tpm.o
>>  
>>  common-obj-$(CONFIG_IPMI) += ipmi.o
>> diff --git a/hw/acpi/utils.c b/hw/acpi/utils.c
>> new file mode 100644
>> index 00..9747996c8c
>> --- /dev/null
>> +++ b/hw/acpi/utils.c
>> @@ -0,0 +1,36 @@
>> +/*
>> + * Utilities for generating ACPI tables and passing them to Guests
>> + *
>> + * Copyright (C) 2019 Intel Corporation
>> + * Copyright (C) 2019 Red Hat Inc
>> + *
>> + * Author: Wei Yang 
>> + * Author: Igor Mammedov 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> +
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> +
>> + * You should have received a copy of the GNU General Public License along
>> + * with this program; if not, see .
>> + */
>> +
>> +#include "qemu/osdep.h"
>
>> +#include 
>is it necessary?
>

Will remove this.

>> +#include "hw/acpi/aml-build.h"
>> +#include "hw/acpi/utils.h"
>
>
>> +
>> +MemoryRegion *acpi_add_rom_blob(FWCfgCallback update, void *opaque,
>> +GArray *blob, const char *name,
>> +uint64_t max_size)
>> +{
>> +return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
>> +name, update, opaque, NULL, true);
>> +}
>> +
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 57679a89bf..a846f74a14 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -37,9 +37,9 @@
>>  #include "hw/acpi/acpi.h"
>>  #include "hw/nvram/fw_cfg.h"
>>  #include "hw/acpi/bios-linker-loader.h"
>> -#include "hw/loader.h"
>>  #include "hw/hw.h"
>>  #include "hw/acpi/aml-build.h"
>> +#include "hw/acpi/utils.h"
>>  #include "hw/pci/pcie_host.h"
>>  #include "hw/pci/pci.h"
>>  #include "hw/arm/virt.h"
>> @@ -881,14 +881,6 @@ static void virt_acpi_build_reset(void *build_opaque)
>>  build_state->patched = false;
>>  }
>>  
>> -static MemoryRegion *acpi_add_rom_blob(AcpiBuildState *build_state,
>> -   GArray *blob, const char *name,
>> -   uint64_t max_size)
>> -{
>> -return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
>> -name, virt_acpi_build_update, build_state, NULL, 
>> true);
>> -}
>> -
>>  static const VMStateDescription vmstate_virt_acpi_build = {
>>  .name = "virt_acpi_build",
>>  .version_id = 1,
>> @@ -920,20 +912,22 @@ void virt_acpi_setup(VirtMachineState *vms)
>>  virt_acpi_build(vms, );
>>  
>>  /* Now expose it all to Guest */
>> -build_state->table_mr = acpi_add_rom_blob(build_state, 
>> tables.table_data,
>> -   ACPI_BUILD_TABLE_FILE,
>> -   ACPI_BUILD_TABLE_MAX_SIZE);
>> +build_state->table_mr = acpi_add_rom_blob(virt_acpi_build_update,
>> +  build_state, 
>> tables.table_data,
>> +  ACPI_BUILD_TABLE_FILE,
>> +  ACPI_BUILD_TABLE_MAX_SIZE);
>>  assert(build_state->table_mr != 

[Qemu-devel] [PATCH] sifive_prci: Read and write PRCI registers

2019-03-21 Thread Palmer Dabbelt
From: Nathaniel Graff 

Writes to the SiFive PRCI registers are preserved while leaving the
ready bits set for the HFX/HFR oscillators and the lock bit set for the
PLL.

Signed-off-by: Nathaniel Graff 
Reviewed-by: Michael Clark 
Reviewed-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/sifive_prci.c | 51 --
 include/hw/riscv/sifive_prci.h | 32 +
 2 files changed, 75 insertions(+), 8 deletions(-)

diff --git a/hw/riscv/sifive_prci.c b/hw/riscv/sifive_prci.c
index 0910ea32c1a5..1435423a23e4 100644
--- a/hw/riscv/sifive_prci.c
+++ b/hw/riscv/sifive_prci.c
@@ -23,15 +23,19 @@
 #include "target/riscv/cpu.h"
 #include "hw/riscv/sifive_prci.h"
 
-/* currently implements enough to mock freedom-e-sdk BSP clock programming */
-
 static uint64_t sifive_prci_read(void *opaque, hwaddr addr, unsigned int size)
 {
-if (addr == 0 /* PRCI_HFROSCCFG */) {
-return 1 << 31; /* ROSC_RDY */
-}
-if (addr == 8 /* PRCI_PLLCFG*/) {
-return 1 << 31; /* PLL_LOCK */
+SiFivePRCIState *s = opaque;
+switch(addr)
+{
+case SIFIVE_PRCI_HFROSCCFG:
+return s->hfrosccfg;
+case SIFIVE_PRCI_HFXOSCCFG:
+return s->hfxosccfg;
+case SIFIVE_PRCI_PLLCFG:
+return s->pllcfg;
+case SIFIVE_PRCI_PLLOUTDIV:
+return s->plloutdiv;
 }
 hw_error("%s: read: addr=0x%x\n", __func__, (int)addr);
 return 0;
@@ -40,7 +44,31 @@ static uint64_t sifive_prci_read(void *opaque, hwaddr addr, 
unsigned int size)
 static void sifive_prci_write(void *opaque, hwaddr addr,
uint64_t val64, unsigned int size)
 {
-/* discard writes */
+SiFivePRCIState *s = opaque;
+switch(addr)
+{
+case SIFIVE_PRCI_HFROSCCFG:
+s->hfrosccfg = (uint32_t) val64;
+/* OSC stays ready */
+s->hfrosccfg |= SIFIVE_PRCI_HFROSCCFG_RDY;
+break;
+case SIFIVE_PRCI_HFXOSCCFG:
+s->hfxosccfg = (uint32_t) val64;
+/* OSC stays ready */
+s->hfxosccfg |= SIFIVE_PRCI_HFXOSCCFG_RDY;
+break;
+case SIFIVE_PRCI_PLLCFG:
+s->pllcfg = (uint32_t) val64;
+/* PLL stays locked */
+s->pllcfg |= SIFIVE_PRCI_PLLCFG_LOCK;
+break;
+case SIFIVE_PRCI_PLLOUTDIV:
+s->plloutdiv = (uint32_t) val64; 
+break;
+default:
+hw_error("%s: bad write: addr=0x%x v=0x%x\n",
+__func__, (int)addr, (int)val64);
+}
 }
 
 static const MemoryRegionOps sifive_prci_ops = {
@@ -60,6 +88,13 @@ static void sifive_prci_init(Object *obj)
 memory_region_init_io(>mmio, obj, _prci_ops, s,
   TYPE_SIFIVE_PRCI, 0x8000);
 sysbus_init_mmio(SYS_BUS_DEVICE(obj), >mmio);
+
+s->hfrosccfg = (SIFIVE_PRCI_HFROSCCFG_RDY | SIFIVE_PRCI_HFROSCCFG_EN);
+s->hfxosccfg = (SIFIVE_PRCI_HFROSCCFG_RDY | SIFIVE_PRCI_HFROSCCFG_EN);
+s->pllcfg = (SIFIVE_PRCI_PLLCFG_REFSEL | SIFIVE_PRCI_PLLCFG_BYPASS |
+SIFIVE_PRCI_PLLCFG_LOCK);
+s->plloutdiv = SIFIVE_PRCI_PLLOUTDIV_DIV1;
+
 }
 
 static const TypeInfo sifive_prci_info = {
diff --git a/include/hw/riscv/sifive_prci.h b/include/hw/riscv/sifive_prci.h
index b6f4c486cc1e..bd51c4af3c1c 100644
--- a/include/hw/riscv/sifive_prci.h
+++ b/include/hw/riscv/sifive_prci.h
@@ -19,6 +19,34 @@
 #ifndef HW_SIFIVE_PRCI_H
 #define HW_SIFIVE_PRCI_H
 
+enum {
+SIFIVE_PRCI_HFROSCCFG   = 0x0,
+SIFIVE_PRCI_HFXOSCCFG   = 0x4,
+SIFIVE_PRCI_PLLCFG  = 0x8,
+SIFIVE_PRCI_PLLOUTDIV   = 0xC
+};
+
+enum {
+SIFIVE_PRCI_HFROSCCFG_RDY   = (1 << 31),
+SIFIVE_PRCI_HFROSCCFG_EN= (1 << 30)
+};
+
+enum {
+SIFIVE_PRCI_HFXOSCCFG_RDY   = (1 << 31),
+SIFIVE_PRCI_HFXOSCCFG_EN= (1 << 30)
+};
+
+enum {
+SIFIVE_PRCI_PLLCFG_PLLSEL   = (1 << 16),
+SIFIVE_PRCI_PLLCFG_REFSEL   = (1 << 17),
+SIFIVE_PRCI_PLLCFG_BYPASS   = (1 << 18),
+SIFIVE_PRCI_PLLCFG_LOCK = (1 << 31)
+};
+
+enum {
+SIFIVE_PRCI_PLLOUTDIV_DIV1  = (1 << 8)
+};
+
 #define TYPE_SIFIVE_PRCI "riscv.sifive.prci"
 
 #define SIFIVE_PRCI(obj) \
@@ -30,6 +58,10 @@ typedef struct SiFivePRCIState {
 
 /*< public >*/
 MemoryRegion mmio;
+uint32_t hfrosccfg;
+uint32_t hfxosccfg;
+uint32_t pllcfg;
+uint32_t plloutdiv;
 } SiFivePRCIState;
 
 DeviceState *sifive_prci_create(hwaddr addr);
-- 
2.19.2




Re: [Qemu-devel] [PATCH qemu] spapr/nvlink2: Correct error messages

2019-03-21 Thread David Gibson
On Thu, Mar 21, 2019 at 05:48:27PM +1100, Alexey Kardashevskiy wrote:
> This corrects rather confusing error messages; can be squashed.
> 
> Fixes: 0afa2635ef75 ("spapr: Support NVIDIA V100 GPU with NVLink2", 
> 2019-03-12)
> Signed-off-by: Alexey Kardashevskiy 

Applied and squashed.

> ---
>  hw/ppc/spapr_pci_nvlink2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/spapr_pci_nvlink2.c b/hw/ppc/spapr_pci_nvlink2.c
> index 3aa66aff6dbd..eda8c752aa22 100644
> --- a/hw/ppc/spapr_pci_nvlink2.c
> +++ b/hw/ppc/spapr_pci_nvlink2.c
> @@ -90,7 +90,7 @@ static void spapr_pci_collect_nvgpu(struct 
> spapr_phb_pci_nvgpu_config *nvgpus,
>  struct spapr_phb_pci_nvgpu_slot *nvslot = spapr_nvgpu_get_slot(nvgpus, 
> tgt);
>  
>  if (!nvslot) {
> -error_setg(errp, "Found too many NVLink bridges per GPU");
> +error_setg(errp, "Found too many GPUs per vPHB");
>  return;
>  }
>  g_assert(!nvslot->gpdev);
> @@ -110,13 +110,13 @@ static void spapr_pci_collect_nvnpu(struct 
> spapr_phb_pci_nvgpu_config *nvgpus,
>  int j;
>  
>  if (!nvslot) {
> -error_setg(errp, "Found too many NVLink bridges per GPU");
> +error_setg(errp, "Found too many NVLink bridges per vPHB");
>  return;
>  }
>  
>  j = nvslot->linknum;
>  if (j == ARRAY_SIZE(nvslot->links)) {
> -error_setg(errp, "Found too many NVLink2 bridges");
> +error_setg(errp, "Found too many NVLink bridges per GPU");
>  return;
>  }
>  ++nvslot->linknum;

-- 
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 for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Laszlo Ersek
On 03/21/19 23:32, Laszlo Ersek wrote:

> Cool, so let me try this. I'm going to download the xz.old file
> manually. Rename it to just xz. It will then match the built-in
> checksum, and will be used as a cached copy. Then I will try building my
> series in *that* ("old") VM.

Summary:

(1) The image file at
 has been recently
uploaded ("Last-Modified: Wed, 27 Feb 2019 11:48:18 GMT") by someone
unknown to me, and its sha256sum doesn't match the sha256sum in the
"tests/vm/openbsd" test script.

This is why my earlier attempts at the OpenBSD build test have failed.
And in fact I don't understand how it could work for anyone else -- the
compiler that the "tests/vm/openbsd" script specifies is neither
installed, nor available with "pkg_add", in this image.


(2) Against the "old" image
, which indeed
has the expected
sha256sum=8c6cedc483e602cfee5e04f0406c64eb99138495e8ca580bc0293bcf0640c1bf,
the build test *does* succeed.

(

In order to make use of the old image, it has to be downloaded manually,
then moved/renamed to:

  $HOME/.cache/qemu-vm/download/bc4733f6c6e76931702528a515a1bf70eb8baecd

because the last filename component must be the sha1sum of the URL
itself, for the caching mechanism to recognize the compressed image:

> $ echo -n 'http://download.patchew.org/openbsd-6.1-amd64.img.xz' \
>   | sha1sum
> bc4733f6c6e76931702528a515a1bf70eb8baecd  -

)

I'm attaching the log of the successful OpenBSD build test, which I
captured with "screen" (see the "BUNZIP2" lines in it, in particular).

Thanks,
Laszlo


screen.log.xz
Description: application/xz


Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Laszlo Ersek
On 03/21/19 21:58, Philippe Mathieu-Daudé wrote:
> Le jeu. 21 mars 2019 18:22, Laszlo Ersek  a écrit :

>> Unfortunately, I got the exact same setup error:

>>> ERROR: "x86_64-unknown-openbsd6.1-gcc-4.9.4" either does not exist
>>> or does not work

> $ VERBOSE=1 make
> Or DEBUG=1. If default ./configure && make fails you get shell and can
> run again with nodefault options. You can check basevm.py in tests/.

I used the "interactive shell" commands from "docs/devel/testing.rst",
to look around inside the image.

The preinstalled gcc is this one:

> qemu-openbsd# gcc --version
> gcc (GCC) 4.2.1 20070719

not what the "openbsd" test case refers to.

Let's see what I could install myself:

> qemu-openbsd# cat /etc/installurl
> https://fastly.cdn.openbsd.org/pub/OpenBSD

> qemu-openbsd# pkg_info -Q gcc
> [...]
> gcc-4.9.4p12
> [...]

> qemu-openbsd# pkg_add gcc-4.9.4p12

And then this gives me "x86_64-unknown-openbsd6.4-gcc-4.9.4". Again,
*not* what the "openbsd" script refers to.

Then I look at the "openbsd" script itself, and realize it downloads:

> cimg = 
> self._download_with_cache("http://download.patchew.org/openbsd-6.1-amd64.img.xz;,
> 
> sha256sum='8c6cedc483e602cfee5e04f0406c64eb99138495e8ca580bc0293bcf0640c1bf')

Hmmm. Can I perhaps *browse* the download directory on patchew, in
Firefox? I sure can, directory listing is enabled:

> README 25-Aug-2017 12:14  
>  0
> freebsd-11.1-amd64.img.xz  03-Aug-2017 09:21  
>  545422116
> netbsd-7.1-amd64.img.xz03-Aug-2017 09:32  
>  224195948
> openbsd-6.1-amd64.img.xz   27-Feb-2019 11:48  
>  675094624
> openbsd-6.1-amd64.img.xz.old   16-Aug-2017 03:23  
>  622579972
> patchew-db-small.tar.xz15-Mar-2018 10:17  
>   10451488

There it is. "openbsd-6.1-amd64.img.xz.old" has an mtime of "16-Aug-2017
03:23", which slightly precedes commit fdfaa33291eb ("tests: Add OpenBSD
image", 2017-09-22).

But someone must have added that ".old" suffix to the filename
*recently*, and uploaded "openbsd-6.1-amd64.img.xz" in its place -- see
the mtime on "openbsd-6.1-amd64.img.xz": "27-Feb-2019 11:48".

I guess the "openbsd" script should have been updated too, in sync. :/

Bonus question: why doesn't the download abort with an sha256sum
mismatch? Here's what I get on my end, after manually fetching both
images:

> 0a836e5013fd502c2c1e14f3f29b25bb1f1ee946abb27d3ca3596d678a728476  
> openbsd-6.1-amd64.img.xz
> 8c6cedc483e602cfee5e04f0406c64eb99138495e8ca580bc0293bcf0640c1bf  
> openbsd-6.1-amd64.img.xz.old

The "old" image matches the checksum (added in original commit
fdfaa33291eb, see above), but the new one doesn't.

... Aaargh, "basevm.py" only uses the checksum for local caching (i.e.
for identifying stale vs. up-to-date local copies), not for
verification!

Cool, so let me try this. I'm going to download the xz.old file
manually. Rename it to just xz. It will then match the built-in
checksum, and will be used as a cached copy. Then I will try building my
series in *that* ("old") VM.

Thanks
Laszlo



[Qemu-devel] [PATCH] docker: trivial changes to `make docker` help

2019-03-21 Thread Wainer dos Santos Moschetta
Apply double quotes and period punctuation uniformly.

Signed-off-by: Wainer dos Santos Moschetta 
---
 tests/docker/Makefile.include | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 60314d293a..c0e1bf57a3 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -151,15 +151,15 @@ docker:
@echo
@echo 'docker:  Print this help.'
@echo 'docker-all-tests:Run all image/test combinations.'
-   @echo 'docker-TEST: Run TEST on all image combinations.'
+   @echo 'docker-TEST: Run "TEST" on all image combinations.'
@echo 'docker-clean:Kill and remove residual docker testing 
containers.'
@echo 'docker-TEST@IMAGE:   Run "TEST" in container "IMAGE".'
@echo ' Note: "TEST" is one of the listed test 
name,'
@echo ' or a script name under 
$$QEMU_SRC/tests/docker/;'
-   @echo ' "IMAGE" is one of the listed container 
name."'
+   @echo ' "IMAGE" is one of the listed container 
name.'
@echo 'docker-image:Build all images.'
@echo 'docker-image-IMAGE:  Build image "IMAGE".'
-   @echo 'docker-run:  For manually running a "TEST" with 
"IMAGE"'
+   @echo 'docker-run:  For manually running a "TEST" with 
"IMAGE".'
@echo
@echo 'Available container images:'
@echo '$(DOCKER_IMAGES)'
-- 
2.20.1




Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

2019-03-21 Thread Philippe Mathieu-Daudé
Le mar. 19 mars 2019 19:40, Markus Armbruster  a écrit :

> Markus Armbruster  writes:
>
> > Dear board code maintainers,
> >
> > This is a (rather late) follow-up to the last QEMU summit.  Minutes[*]:
> >
> >  * Deprecating unmaintained features (devices, targets, backends) in QEMU
> >
> >QEMU has a mechanism to deprecate features but there remains a lot of
> >old unmaintained code.  Refactoring is hindered by untested legacy
> >code, so there is a desire to deprecate unmaintained features more
> >often.
> >
> >[...]
> >
> >We should require at least a minimal test for each board; if nobody
> >cares enough to come up with one, that board should be deprecated.
> >
> >[...]
> >
> >Also see the qemu-devel discussion about deprecating code:
> >
> https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html.
> >
> > That's a link to "Minutes of KVM Forum BoF on deprecating stuff".
> > Quote:
> >
> >  * One obvious class of candidates for removal is machines we don't know
> >how to boot, or can't boot, say because we lack required firmware
> >and/or OS.
> >
> >Of course, "can boot" should be an automated test.  As a first step
> >towards that, we should at least document how to boot each machine.
> >We're going to ask machine maintainers to do that.
> >
> > Let's get going on this.
> >
> > I gathered the machine types, mapped them to source files, which I fed
> > to get_maintainer.pl.  Results are appended.  If you're cc'ed,
> > MAINTAINERS fingers you for at least one machine type's source file.
> > Please tell us for all of them how to to a "meaningful" boot test.
> >
> > For now, what's "meaningful" is entirely up to you.  Booting Linux
> > certainly is.
> >
> > Make sure to include a complete QEMU command line.  If your QEMU command
> > line requires resources beyond the QEMU source tree and what we build
> > from it, please detail them, and provide download URLs as far as
> > possible.
> >
> > Goals for this exercise:
> >
> > * Gather information we need to cover more machines in our automated
> >   testing.
> >
> >   Related work:
> >   [PATCH v4 00/19] Acceptance Tests: target architecture support
> >   Message-Id: <20190312121150.8638-1-cr...@redhat.com>
> >   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html
> >
> > * Maybe identify a few machines we don't know how to boot anymore.
> >
> > Thanks in advance for your help!
>
> Quite a few maintainers replied, and a few others, too.  Thank you!
>
> I still have to fully digest the replies, in particular whether there's
> enough detail for me to actually boot a guest.
>
> I'm still lacking information on 26 machines.  If you're cc'ed, you're
> considered a possible source of information.  Please help.
>
> If you're a supporter or maintainer, but can't help, please consider
> adjusting MAINTAINERS to S: Odd Fixes for the machine.
>
> Machines with at least one supporter:
>
> = hw/xenpv/xen_machine_pv.c =
> Stefano Stabellini  (supporter:X86)
> Anthony Perard  (supporter:X86)
> Paul Durrant  (supporter:X86)
> xen-de...@lists.xenproject.org (open list:X86)
>
> Machines with no supporter, but at least one maintainer:
>
> = hw/arm/integratorcp.c =
> Peter Maydell  (maintainer:Integrator CP)
> qemu-...@nongnu.org (open list:Integrator CP)
>
> = hw/arm/omap_sx1.c =
> Peter Maydell  (maintainer:OMAP)
> qemu-...@nongnu.org (open list:ARM)
>
> = hw/mips/mips_jazz.c =
> "Hervé Poussineau"  (maintainer:Jazz)
> Aleksandar Rikalo  (reviewer:Jazz)
> Aurelien Jarno  (maintainer:MIPS)
> Aleksandar Markovic  (maintainer:MIPS)
>
> = hw/mips/mips_r4k.c =
> Aurelien Jarno  (maintainer:R4000)
> Aleksandar Rikalo  (reviewer:R4000)
> Aleksandar Markovic  (maintainer:MIPS)
>
> = hw/moxie/moxiesim.c =
> Anthony Green  (maintainer:Moxie)
>
> = hw/nios2/10m50_devboard.c =
> Chris Wulff  (maintainer:NiosII)
> Marek Vasut  (maintainer:NiosII)
>
> = hw/ppc/virtex_ml507.c =
> "Edgar E. Iglesias"  (odd
> fixer:virtex_ml507)
> David Gibson  (maintainer:PowerPC)
> qemu-...@nongnu.org (open list:virtex_ml507)
>
> = hw/tricore/tricore_testboard.c =
> Bastian Koppelmann 
> (maintainer:TriCore)
>
> = hw/unicore32/puv3.c =
> Guan Xuetao  (maintainer:UniCore32)
>
> Machines with no maintainer and no supporter:
>
> = hw/arm/collie.c =
> Peter Maydell  (odd fixer:Sharp SL-5500
> (Co...)
> qemu-...@nongnu.org (open list:Sharp SL-5500 (Co...)
>
> = hw/arm/exynos4_boards.c =
> Igor Mitsyanko  (odd fixer:Exynos)
> Peter Maydell  (odd fixer:Exynos)
> qemu-...@nongnu.org (open list:Exynos)
>
> = hw/arm/imx25_pdk.c =
> Peter Maydell  (odd fixer:i.MX25 PDK)
> Jean-Christophe Dubois  (reviewer:i.MX25 PDK)
> qemu-...@nongnu.org (open list:i.MX25 PDK)
>
> = hw/arm/mainstone.c =
> Andrzej Zaborowski  (odd fixer:PXA2XX)
> Peter Maydell  (odd 

Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Philippe Mathieu-Daudé
Le jeu. 21 mars 2019 18:22, Laszlo Ersek  a écrit :

> On 03/21/19 17:55, Laszlo Ersek wrote:
> > On 03/21/19 12:52, Peter Maydell wrote:
> >> On Thu, 21 Mar 2019 at 11:34, Laszlo Ersek  wrote:
> >>>
> >>> Repo:   https://github.com/lersek/qemu.git
> >>> Branch: edk2_build_v3
> >>>
> >>> Version 2, that is:
> >>>
> >>>   [Qemu-devel] [PATCH v2 00/12] bundle edk2 platform firmware with QEMU
> >>>
> >>> was posted at:
> >>>
> >>>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04670.html
> >>>   20190313210057.32584-1-lersek@redhat.com">http://mid.mail-archive.com/20190313210057.32584-1-lersek@redhat.com
> >>>
> >>> Updates in v3 are noted on each patch individually, in the Notes
> >>> section. In summary,
> >>>
> >>> - I've picked up feedback tags from the v2 thread (see above),
> >>>
> >>> - I've replaced the xz compression with bz2 compression according to
> the
> >>>   subthread
> >>>
> >>> Re: [Qemu-devel] [PULL 00/12] EDK2 Firmware roms
> >>
> >> Thanks. Could you check that this works in the OpenBSD VM test?
> >> It should just be a matter of
> >>   make -C build vm-build-openbsd
> >
> > Actually I tried to do that before posting v3, following the
> > instructions in "docs/devel/testing.rst":
> >
> >   cd $QEMU_SRC/tests/vm
> >   ./openbsd --build-image --image /mnt/data/tmp/openbsd.img
> >   ./openbsd --debug --image /mnt/data/tmp/openbsd.img \
> > --build-qemu $QEMU_SRC
>

These isn't the line I remember using with vmtest openbsd. I remember
specifying host-cc and python.
I guess you can find it in openbsd.py under tests/vm/.

>
> > The first "openbsd" invocation succeeded, but the second failed, with a
> > complaint about some (cross?)compiler missing.
> >
> > Anyway I'll now retry with the make command you specify above.
>
> Unfortunately, I got the exact same setup error:
>
> > make: Entering directory `.../tmp/qemu-build-opt.d'
> > VM-IMAGE openbsd
> > --2019-03-21 18:14:46--
> http://download.patchew.org/openbsd-6.1-amd64.img.xz
> > Resolving download.patchew.org (download.patchew.org)... 140.211.15.4
> > Connecting to download.patchew.org 
> > (download.patchew.org)|140.211.15.4|:80...
> connected.
> > HTTP request sent, awaiting response... 200 OK
> > Length: 675094624 (644M) [application/octet-stream]
> > Saving to:
> '.../.cache/qemu-vm/download/bc4733f6c6e76931702528a515a1bf70eb8baecd.download'
> >
> >
> 100%[=>]
> 675,094,624 12.0MB/s   in 53s
> >
> > 2019-03-21 18:15:40 (12.1 MB/s) -
> '.../.cache/qemu-vm/download/bc4733f6c6e76931702528a515a1bf70eb8baecd.download'
> saved [675094624/675094624]
> >
> > Extracting the image...
> > .../.cache/qemu-vm/images/openbsd.img.tmp.xz (1/1)
> >   100 %643.8 MiB / 32.0 GiB = 0.020   253 MiB/s   2:09
> > VM-BUILD openbsd
> > Cloning into
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot'...
> > done.
> > Checking out files: 100% (6748/6748), done.
> > Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path
> 'dtc'
> > Cloning into
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/dtc'...
> > Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git)
> registered for path 'ui/keycodemapdb'
> > Cloning into
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/ui/keycodemapdb'...
> > Submodule 'tests/fp/berkeley-softfloat-3' (
> https://github.com/cota/berkeley-softfloat-3) registered for path
> 'tests/fp/berkeley-softfloat-3'
> > Cloning into
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/tests/fp/berkeley-softfloat-3'...
> > Submodule 'tests/fp/berkeley-testfloat-3' (
> https://github.com/cota/berkeley-testfloat-3) registered for path
> 'tests/fp/berkeley-testfloat-3'
> > Cloning into
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/tests/fp/berkeley-testfloat-3'...
> >
> > ERROR: "x86_64-unknown-openbsd6.1-gcc-4.9.4" either does not exist or
> does not work
> >
> > make: *** [vm-build-openbsd] Error 3
> > make: Leaving directory `.../tmp/qemu-build-opt.d'
>

To reach shell even on failure you have to use smth like:

$ VERBOSE=1 make
Or DEBUG=1. If default ./configure && make fails you get shell and can run
again with nodefault options. You can check basevm.py in tests/.


> Thanks,
> Laszlo
>


Re: [Qemu-devel] QUEM booting from external

2019-03-21 Thread John Snow



On 3/20/19 8:38 PM, Grove, Michael wrote:
> Hi All,
> 
> Sorry for going straight to  the developers but I have a very complex  
> problem. I have QNX application/OS that is licensed to the physical media it 
> exists on(media ID). When you boot on bare metal directly from the media all 
> is good. When I boot form the media in QEMU it acts like the media is copied 
> and fails to license. Any suggestions, I'm using windows10 as my host OS.
>  Here is the launch  command:
> 
> qemu-system-i386.exe  -L . -name NavigtorVM -m 900 -drive 
> file=\\.\PhysicalDrive3,if=ide,index=0,media=disk,format=raw,copy-on-read=off 
> -netdev tap,id=mynet0,ifname=Ethernet -device e1000,netdev=mynet0
> 
> 
> Thank You,
> 
> Michael Grove
> Sr. Controls Engineer - Show Control Sys.
> Walt Disney World
> Design & Engineering
> (407) 492-9867
> michael.gr...@disney.com
> 

I don't know much about how QEMU on Windows works (Sorry!) but it's
probably using disk metadata to guess...

(...Err, can you do PCI passthrough without KVM? You could try passing
through a disk controller and letting the guest have raw access to the
actual disk hardware which would be the most surefire way to get this to
work, I think...)

But failing that grand idea, it's probably using things like your disk
type, model, serial and wwn to identify the disk. You probably want a
SATA disk instead of a PATA one (I am assuming in 2019...), so try
creating an AHCI controller and an IDE device attached to the AHCI
controller instead (Q35 does this by default; you'll have to create the
controller yourself if you use i440fx based boards as above.)

Then, try fiddling around with some hardware info tool to get the SATA
information for the disk you want to emulate, then reproduce it in your
command line invocation.

Check out this line from a libvirt test:

-device
ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,wwn=5000c50015ea71ad

You should be able to use serial=foo, model=bar and version=baz to try
and mimic your real drive a bit more closely.

But it still might not work. It might also be against your licensing
agreement to try to run it in a VM, technically, but I'm not in charge
of you or your destiny :)

--js



Re: [Qemu-devel] [PATCH v3 1/2] vfio-ccw: new capability chain support

2019-03-21 Thread Eric Farman




On 3/1/19 4:39 AM, Cornelia Huck wrote:

To be replaced with a real linux-headers update.

Signed-off-by: Cornelia Huck 


This looks straightforward.

Reviewed-by: Eric Farman 


---
  linux-headers/linux/vfio.h |  4 
  linux-headers/linux/vfio_ccw.h | 12 
  2 files changed, 16 insertions(+)

diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 12a7b1dc53c8..24f505199f83 100644
--- a/linux-headers/linux/vfio.h
+++ b/linux-headers/linux/vfio.h
@@ -353,6 +353,10 @@ struct vfio_region_gfx_edid {
  #define VFIO_DEVICE_GFX_LINK_STATE_DOWN  2
  };
  
+#define VFIO_REGION_TYPE_CCW			(2)

+/* ccw sub-types */
+#define VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD  (1)
+
  /*
   * 10de vendor sub-type
   *
diff --git a/linux-headers/linux/vfio_ccw.h b/linux-headers/linux/vfio_ccw.h
index 5bf96c3812d2..fcc3e69ef526 100644
--- a/linux-headers/linux/vfio_ccw.h
+++ b/linux-headers/linux/vfio_ccw.h
@@ -12,6 +12,7 @@
  
  #include 
  
+/* used for START SUBCHANNEL, always present */

  struct ccw_io_region {
  #define ORB_AREA_SIZE 12
__u8orb_area[ORB_AREA_SIZE];
@@ -22,4 +23,15 @@ struct ccw_io_region {
__u32   ret_code;
  } __attribute__((packed));
  
+/*

+ * used for processing commands that trigger asynchronous actions
+ * Note: this is controlled by a capability
+ */
+#define VFIO_CCW_ASYNC_CMD_HSCH (1 << 0)
+#define VFIO_CCW_ASYNC_CMD_CSCH (1 << 1)
+struct ccw_cmd_region {
+   __u32 command;
+   __u32 ret_code;
+} __attribute__((packed));
+
  #endif






[Qemu-devel] [PATCH] acpi: verify file entries in bios_linker_loader_add_pointer()

2019-03-21 Thread Liam Merwick
The callers to bios_linker_find_file() assert that the file entry returned
is not NULL, except for those in bios_linker_loader_add_pointer().  Add two
asserts in that case for completeness and to facilitate static code analysis.

Signed-off-by: Liam Merwick 
---
 hw/acpi/bios-linker-loader.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/acpi/bios-linker-loader.c b/hw/acpi/bios-linker-loader.c
index d16b8bbcb187..626c04a39f92 100644
--- a/hw/acpi/bios-linker-loader.c
+++ b/hw/acpi/bios-linker-loader.c
@@ -283,6 +283,8 @@ void bios_linker_loader_add_pointer(BIOSLinker *linker,
 const BiosLinkerFileEntry *source_file =
 bios_linker_find_file(linker, src_file);
 
+assert(dst_file);
+assert(source_file);
 assert(dst_patched_offset < dst_file->blob->len);
 assert(dst_patched_offset + dst_patched_size <= dst_file->blob->len);
 assert(src_offset < source_file->blob->len);
-- 
1.8.3.1




Re: [Qemu-devel] Can't build without --disable-tcg after upgrading gcc (I think)

2019-03-21 Thread Markus Armbruster
Richard Henderson  writes:

> On 3/21/19 11:10 AM, Markus Armbruster wrote:
>> I re-ran the failing compile with "-c -o tcg/tcg-op.o" replaced by "-E
>> -dD -o tcg/tcg-op.i", and uploaded the resulting tcg-op.i to
>> 
>> https://www.pond.sub.org/~armbru/debug/tcg-op.i
>> 
>> Diffing this against yours might provide clues.
>
> Either you're not building master,
>
> -# 1 "/home/rth/work/qemu/qemu/accel/tcg/tcg-runtime.h" 1
> +# 1 "/home/armbru/work/qemu/tcg/tcg-runtime.h" 1
>
> since this file got moved 18 months ago,
>
> commit 61a3f8f6c047620f4d55ade4f5607a9d019984c6
> Author: Philippe Mathieu-Daudé 
> Date:   Mon Sep 11 18:33:26 2017 -0300
>
> accel/tcg: move tcg-runtime to accel/tcg/
>
> Or, despite ccache -C, you're getting wrong results.
>
> I myself hate ccache for the oddball effects it has, often not dissimilar to
> this, and do not have it installed at all.

This one time, it's totally innocent, and I'm totally guilty :)

I had tcg/tcg-runtime.h in my source tree.  I have no idea how it
managed to evade deletion there.  I have no idea why it didn't interfere
with my builds all that time, but since yesterday does.

Thank you, Richard!



Re: [Qemu-devel] [PATCH RFC v4 04/12] target/rx: RX disassembler

2019-03-21 Thread Richard Henderson
On 3/20/19 7:16 AM, Yoshinori Sato wrote:
> +static const char *cond[] = {
> +"eq", "ne", "c", "nc", "gtu", "leu", "pz", "n",
> +"ge", "lt", "gt", "le", "o", "no", "ra", "f"
> +};

const char * const cond[]

Or since they are all very short strings,

const char cond[][4]

> +static const char *cr[] = {
> +"psw", "", "usp", "fpsw", "", "", "", "",
> +"bpsw", "bpc", "isp", "fintv", "intb", "", "", "",
> +};
> +static const char *msize[] = {
> +"b", "w", "l", "ub", "uw",
> +};

Similarly.  Although cr has longer strings.  And cr[1] = "pc".

> +static void operand(DisasContext *ctx, int ld, int mi, int rs, int rd)
> +{
> +int dsp;
> +const char *mis;
> +static const char *sizes[] = {".b", ".w", ".l"};

Similarly.  Although why not include .ub and .uw here?


r~



[Qemu-devel] [PULL 5/5] docs: add note about stibp CPU feature for spectre v2

2019-03-21 Thread Eduardo Habkost
From: Daniel P. Berrangé 

While the stibp CPU feature is not commonly used by guest OS for spectre
mitigation due to its performance impact, it is none the less best
practice to expose it to all guest OS. This allows the guest OS to
decide whether to make use or it.

Signed-off-by: Daniel P. Berrangé 
Message-Id: <20190307121838.6345-3-berra...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 docs/qemu-cpu-models.texi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi
index 0ce528806d..23c11dc86f 100644
--- a/docs/qemu-cpu-models.texi
+++ b/docs/qemu-cpu-models.texi
@@ -168,6 +168,17 @@ Requires the host CPU microcode to support this feature 
before it
 can be used for guest CPUs.
 
 
+@item @code{stibp}
+
+Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some
+operating systems.
+
+Must be explicitly turned on for all Intel CPU models.
+
+Requires the host CPU microcode to support this feature before it
+can be used for guest CPUs.
+
+
 @item @code{ssbd}
 
 Required to enable the CVE-2018-3639 fix
@@ -258,6 +269,17 @@ Requires the host CPU microcode to support this feature 
before it
 can be used for guest CPUs.
 
 
+@item @code{stibp}
+
+Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some
+operating systems.
+
+Must be explicitly turned on for all AMD CPU models.
+
+Requires the host CPU microcode to support this feature before it
+can be used for guest CPUs.
+
+
 @item @code{virt-ssbd}
 
 Required to enable the CVE-2018-3639 fix
-- 
2.18.0.rc1.1.g3f1ff2140




Re: [Qemu-devel] [PATCH RFC v4 03/12] target/rx: CPU definition

2019-03-21 Thread Richard Henderson
On 3/20/19 7:16 AM, Yoshinori Sato wrote:
> +#define FPSW_MASK 0xfc007cff
> +#define FPSW_RM_MASK 0x0003
> +#define FPSW_DN (1 << 8)

It's slightly confusing to have this as a mask,

> +#define FPSW_CAUSE_MASK 0x00fc
> +#define FPSW_CAUSE_SHIFT 2
> +#define FPSW_CAUSE   2
> +#define FPSW_CAUSE_V 2

and these as a bit.  You might either rename to FPSW_DN_MASK, or define as a 
bit.

Alternately, convert all of these to use "hw/registerfields.h", a la

FIELD(FPSW, RM, 0, 2)
FIELD(FPSW, CAUSE, 2, 6)
FIELD(FPSW, CV, 2, 1)
...
FIELD(FPSW, DN, 8, 1)
FIELD(FPSW, ENABLE, 10, 5)
FIELD(FPSW, EV, 10, 1)
...
FIELD(FPSW, FLAG, 26, 5)
FIELD(FPSW, FV, 26, 1)
...
FIELD(FPSW, FS, 31, 1)

> +#define FPSW_CAUSE_O 3
> +#define FPSW_CAUSE_Z 4
> +#define FPSW_CAUSE_U 5
> +#define FPSW_CAUSE_X 6
> +#define FPSW_CAUSE_E 7
> +#define FPSW_ENABLE_MASK 0x7c00
> +#define FPSW_ENABLE  10

If not using FIELD, perhaps FPSW_ENABLE_SHIFT to match FPSW_CAUSE_SHIFT?

> +#define RX_PSW_OP_NONE 0
> +#define RX_PSW_OP_SUB 1
> +#define RX_PSW_OP_ADD 2
> +#define RX_PSW_OP_SHLL 3

Unused.

> +typedef struct CPURXState {
> +/* CPU registers */
> +uint32_t regs[16];  /* general registers */
> +uint32_t psw;   /* processor status */

As discussed in reply to patch 2, remove this.

> +/* Flag operation */
> +uint32_t psw_op;
> +uint32_t psw_v[3];

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 = deposit32(*flags, PSW_PM,  1, env->psw_pm);

It might be worthwhile to include PSW_U.  I'll discuss elsewhere

> +static inline uint32_t pack_psw(CPURXState *env)

Why is this missing rx_cpu_ prefix, to match rx_cpu_unpack_psw?

> +static bool rx_cpu_has_work(CPUState *cs)
> +{
> +return cs->interrupt_request & CPU_INTERRUPT_HARD;

Surely CPU_INTERRUPT_FIR needs to be included here.

> +static void rx_cpu_reset(CPUState *s)
> +{
> +RXCPU *cpu = RXCPU(s);
> +RXCPUClass *rcc = RXCPU_GET_CLASS(cpu);
> +CPURXState *env = >env;
> +uint32_t *resetvec;
> +
> +rcc->parent_reset(s);
> +
> +memset(env, 0, offsetof(CPURXState, end_reset_fields));
> +
> +resetvec = rom_ptr(0xfffc, 4);
> +if (resetvec) {
> +/* In the case of kernel, it is ignored because it is not set. */
> +env->pc = ldl_p(resetvec);
> +}
> +env->psw = 0x;

You can't just assign, you need.

  rx_cpu_unpack_psw(env, 0, 1);

And, as a reminder from patch 2 review, set fp_status here.

> +static uint32_t extable[32];
> +
> +void rx_load_image(RXCPU *cpu, const char *filename,
> +   uint32_t start, uint32_t size)
> +{
> +long kernel_size;
> +int i;
> +
> +kernel_size = load_image_targphys(filename, start, size);
> +if (kernel_size < 0) {
> +fprintf(stderr, "qemu: could not load kernel '%s'\n", filename);
> +exit(1);
> +}
> +cpu->env.pc = start;
> +
> +/* setup exception trap trampoline */
> +for (i = 0; i < 32; i++) {
> +extable[i] = 0x10 + i * 4;
> +}

These assignments need to be in target-endianness, not host-endianness.

Since RX is currently little-endian only, perhaps just

extable[i] = cpu_to_le32(0x10 + i * 4);

> +rom_add_blob_fixed("extable", extable, sizeof(extable), 0xff80);
> +}
> 



r~



[Qemu-devel] [PULL 3/5] i386: Disable OSPKE on CPU model definitions

2019-03-21 Thread Eduardo Habkost
Currently, the Cascadelake-Server, Icelake-Client, and
Icelake-Server are always generating the following warning:

  qemu-system-x86_64: warning: \
host doesn't support requested feature: CPUID.07H:ECX [bit 4]

This happens because OSPKE was never returned by
GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word().
OSPKE is a runtime flag automatically set by the KVM module or by
TCG code, was always cleared by x86_cpu_filter_features(), and
was not supposed to appear on the CPU model table.

Remove the OSPKE flag from the CPU model table entries, to avoid
the bogus warning and avoid returning invalid feature data on
query-cpu-* QMP commands.  As OSPKE was always cleared by
x86_cpu_filter_features(), this won't have any guest-visible
impact.

Include a test case that should detect the problem if we introduce
a similar bug again.

Fixes: c7a88b52f62b ("i386: Add new model of Cascadelake-Server")
Fixes: 8a11c62da914 ("i386: Add new CPU model Icelake-{Server,Client}")
Cc: Tao Xu 
Cc: Robert Hoo 
Signed-off-by: Eduardo Habkost 
Message-Id: <20190319200515.14999-1-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c   |  6 +++---
 tests/acceptance/cpu_queries.py | 33 +
 2 files changed, 36 insertions(+), 3 deletions(-)
 create mode 100644 tests/acceptance/cpu_queries.py

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 9d3a20eac4..d6bb57d210 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2532,7 +2532,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_7_0_EBX_AVX512BW | CPUID_7_0_EBX_AVX512CD |
 CPUID_7_0_EBX_AVX512VL | CPUID_7_0_EBX_CLFLUSHOPT,
 .features[FEAT_7_0_ECX] =
-CPUID_7_0_ECX_PKU | CPUID_7_0_ECX_OSPKE |
+CPUID_7_0_ECX_PKU |
 CPUID_7_0_ECX_AVX512VNNI,
 .features[FEAT_7_0_EDX] =
 CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_SPEC_CTRL_SSBD,
@@ -2585,7 +2585,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_7_0_EBX_SMAP,
 .features[FEAT_7_0_ECX] =
 CPUID_7_0_ECX_VBMI | CPUID_7_0_ECX_UMIP | CPUID_7_0_ECX_PKU |
-CPUID_7_0_ECX_OSPKE | CPUID_7_0_ECX_VBMI2 | CPUID_7_0_ECX_GFNI |
+CPUID_7_0_ECX_VBMI2 | CPUID_7_0_ECX_GFNI |
 CPUID_7_0_ECX_VAES | CPUID_7_0_ECX_VPCLMULQDQ |
 CPUID_7_0_ECX_AVX512VNNI | CPUID_7_0_ECX_AVX512BITALG |
 CPUID_7_0_ECX_AVX512_VPOPCNTDQ,
@@ -2643,7 +2643,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_7_0_EBX_AVX512VL | CPUID_7_0_EBX_CLFLUSHOPT,
 .features[FEAT_7_0_ECX] =
 CPUID_7_0_ECX_VBMI | CPUID_7_0_ECX_UMIP | CPUID_7_0_ECX_PKU |
-CPUID_7_0_ECX_OSPKE | CPUID_7_0_ECX_VBMI2 | CPUID_7_0_ECX_GFNI |
+CPUID_7_0_ECX_VBMI2 | CPUID_7_0_ECX_GFNI |
 CPUID_7_0_ECX_VAES | CPUID_7_0_ECX_VPCLMULQDQ |
 CPUID_7_0_ECX_AVX512VNNI | CPUID_7_0_ECX_AVX512BITALG |
 CPUID_7_0_ECX_AVX512_VPOPCNTDQ | CPUID_7_0_ECX_LA57,
diff --git a/tests/acceptance/cpu_queries.py b/tests/acceptance/cpu_queries.py
new file mode 100644
index 00..e71edec39f
--- /dev/null
+++ b/tests/acceptance/cpu_queries.py
@@ -0,0 +1,33 @@
+# Sanity check of query-cpu-* results
+#
+# Copyright (c) 2019 Red Hat, Inc.
+#
+# Author:
+#  Eduardo Habkost 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+import logging
+
+from avocado_qemu import Test
+
+class QueryCPUModelExpansion(Test):
+"""
+Run query-cpu-model-expansion for each CPU model, and validate results
+"""
+
+def test(self):
+self.vm.set_machine('none')
+self.vm.add_args('-S')
+self.vm.launch()
+
+cpus = self.vm.command('query-cpu-definitions')
+for c in cpus:
+print(repr(c))
+self.assertNotIn('', c['unavailable-features'], c['name'])
+
+for c in cpus:
+model = {'name': c['name']}
+e = self.vm.command('query-cpu-model-expansion', model=model, 
type='full')
+self.assertEquals(e['model']['name'], c['name'])
-- 
2.18.0.rc1.1.g3f1ff2140




[Qemu-devel] [PULL 2/5] i386: Make arch_capabilities migratable

2019-03-21 Thread Eduardo Habkost
Now that kvm_arch_get_supported_cpuid() will only return
arch_capabilities if QEMU is able to initialize the MSR properly,
we know that the feature is safely migratable.

Signed-off-by: Eduardo Habkost 
Message-Id: <20190125220606.4864-3-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index d90c01a059..9d3a20eac4 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1089,7 +1089,6 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 .reg = R_EDX,
 },
 .tcg_features = TCG_7_0_EDX_FEATURES,
-.unmigratable_flags = CPUID_7_0_EDX_ARCH_CAPABILITIES,
 },
 [FEAT_8000_0007_EDX] = {
 .type = CPUID_FEATURE_WORD,
-- 
2.18.0.rc1.1.g3f1ff2140




[Qemu-devel] [PULL 4/5] docs: clarify that spec-ctrl is only needed for Spectre v2

2019-03-21 Thread Eduardo Habkost
From: Daniel P. Berrangé 

The docs currently say that the spec-ctrl feature is needed for both
Spectre variants, but it is only used to address Spectre v2. Also
remove the note about retpolines. The guest OS is usually treated
as a blackbox from host mgmt pov, so it won't have knowledge about
use of retpolines and thus should unconditionally expose spec-ctrl,
allowing the guest to decide whether to use it or not.

Signed-off-by: Daniel P. Berrangé 
Message-Id: <20190307121838.6345-2-berra...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 docs/qemu-cpu-models.texi | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi
index 1b72584161..0ce528806d 100644
--- a/docs/qemu-cpu-models.texi
+++ b/docs/qemu-cpu-models.texi
@@ -158,8 +158,7 @@ support this feature.
 
 @item @code{spec-ctrl}
 
-Required to enable the Spectre (CVE-2017-5753 and CVE-2017-5715) fix,
-in cases where retpolines are not sufficient.
+Required to enable the Spectre v2 (CVE-2017-5715) fix.
 
 Included by default in Intel CPU models with -IBRS suffix.
 
@@ -249,8 +248,7 @@ included if using "Host passthrough" or "Host model".
 
 @item @code{ibpb}
 
-Required to enable the Spectre (CVE-2017-5753 and CVE-2017-5715) fix,
-in cases where retpolines are not sufficient.
+Required to enable the Spectre v2 (CVE-2017-5715) fix.
 
 Included by default in AMD CPU models with -IBPB suffix.
 
-- 
2.18.0.rc1.1.g3f1ff2140




[Qemu-devel] [PULL 1/5] i386: kvm: Disable arch_capabilities if MSR can't be set

2019-03-21 Thread Eduardo Habkost
KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES:

1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES
   is always supported") makes GET_SUPPORTED_CPUID return
   arch_capabilities even if running on SVM.  This makes "-cpu
   host,migratable=off" incorrectly expose arch_capabilities on CPUID on
   AMD hosts (where the MSR is not emulated by KVM).

2) KVM_GET_MSR_INDEX_LIST does not return MSR_IA32_ARCH_CAPABILITIES if
   the MSR is not supported by the host CPU.  This makes QEMU not
   initialize the MSR properly at kvm_put_msrs() on those hosts.

Work around both bugs on the QEMU side, by checking if the MSR
was returned by KVM_GET_MSR_INDEX_LIST before returning the
feature flag on kvm_arch_get_supported_cpuid().

This has the unfortunate side effect of making arch_capabilities
unavailable on hosts without hardware support for the MSR until bug #2
is fixed on KVM, but I can't see another way to work around bug #1
without that side effect.

Signed-off-by: Eduardo Habkost 
Message-Id: <20190125220606.4864-2-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/kvm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index beae1b99da..3b29ce5c0d 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -389,6 +389,15 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, 
uint32_t function,
 if (host_tsx_blacklisted()) {
 ret &= ~(CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_HLE);
 }
+} else if (function == 7 && index == 0 && reg == R_EDX) {
+/*
+ * Linux v4.17-v4.20 incorrectly return ARCH_CAPABILITIES on SVM hosts.
+ * We can detect the bug by checking if MSR_IA32_ARCH_CAPABILITIES is
+ * returned by KVM_GET_MSR_INDEX_LIST.
+ */
+if (!has_msr_arch_capabs) {
+ret &= ~CPUID_7_0_EDX_ARCH_CAPABILITIES;
+}
 } else if (function == 0x8001 && reg == R_ECX) {
 /*
  * It's safe to enable TOPOEXT even if it's not returned by
-- 
2.18.0.rc1.1.g3f1ff2140




Re: [Qemu-devel] [PATCH] virtio-vga: only enable for specific boards

2019-03-21 Thread Laszlo Ersek
On 03/21/19 15:29, Paolo Bonzini wrote:
> When virtio-vga was added, the intention was to only support it for
> those machines where the firmware does not know about virtio-gpu,
> and supported VGA legacy hardware before virtio-{gpu,vga} were
> introduced.
> 
> The Kconfig switch however enabled virtio-vga for all machines with
> a PCI bus, and libvirt then prefers it even on hardware where
> virtio-gpu would be preferrable.  At least for now, only enable
> virtio-vga for PC, hppa and pSeries machines, as was the case
> before Kconfig dependencies were introduced.
> 
> Reported-by: Laszlo Ersek 
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/display/Kconfig | 2 +-
>  hw/hppa/Kconfig| 1 +
>  hw/i386/Kconfig| 1 +
>  hw/ppc/Kconfig | 1 +
>  4 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/display/Kconfig b/hw/display/Kconfig
> index 86c1d544c5..72be57a403 100644
> --- a/hw/display/Kconfig
> +++ b/hw/display/Kconfig
> @@ -100,7 +100,7 @@ config VIRTIO_GPU
>  
>  config VIRTIO_VGA
>  bool
> -default y if PCI_DEVICES
> +# defaults to "N", enabled by specific boards
>  depends on VIRTIO_PCI
>  select VGA
>  
> diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
> index 7334f57081..6e5d74a825 100644
> --- a/hw/hppa/Kconfig
> +++ b/hw/hppa/Kconfig
> @@ -2,6 +2,7 @@ config DINO
>  bool
>  imply PCI_DEVICES
>  imply E1000_PCI
> +imply VIRTIO_VGA
>  select PCI
>  select SERIAL
>  select ISA_BUS
> diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
> index 8e8444dbf9..a6aed7c131 100644
> --- a/hw/i386/Kconfig
> +++ b/hw/i386/Kconfig
> @@ -19,6 +19,7 @@ config PC
>  imply TPM_CRB
>  imply TPM_TIS
>  imply VGA_PCI
> +imply VIRTIO_VGA
>  select FDC
>  select I8259
>  select I8254
> diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
> index ae07b4da63..a3465155f0 100644
> --- a/hw/ppc/Kconfig
> +++ b/hw/ppc/Kconfig
> @@ -2,6 +2,7 @@ config PSERIES
>  bool
>  imply PCI_DEVICES
>  imply TEST_DEVICES
> +imply VIRTIO_VGA
>  select DIMM
>  select PCI
>  select SPAPR_VSCSI
> 

I tried to apply this for testing, on top of
c692931cda9dc6cbc16b89d5094a725a10dbb641, but git-am failed. The
conflicts are in "hw/hppa/Kconfig" and "hw/i386/Kconfig". In the former,
the conflict is due to E1000_PCI, in the latter, the conflict occurs due
to VGA_PCI -- upstream doesn't seem to have either of those.

Thanks
Laszlo



[Qemu-devel] [PULL 0/5] x86 queue for -rc1

2019-03-21 Thread Eduardo Habkost
The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:

  Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/x86-next-pull-request

for you to fetch changes up to 21ee4787e53367590f284915bf4c30c684e65bdf:

  docs: add note about stibp CPU feature for spectre v2 (2019-03-20 12:18:15 
-0300)


x86 queue for -rc1

A few fixes that missed -rc0:
* CPU model documentation updates (Daniel P. Berrangé)
* Fix bogus OSPKE warnings (Eduardo Habkost)
* Work around KVM bugs when handing arch_capabilities
  (Eduardo Habkost)



Daniel P. Berrangé (2):
  docs: clarify that spec-ctrl is only needed for Spectre v2
  docs: add note about stibp CPU feature for spectre v2

Eduardo Habkost (3):
  i386: kvm: Disable arch_capabilities if MSR can't be set
  i386: Make arch_capabilities migratable
  i386: Disable OSPKE on CPU model definitions

 docs/qemu-cpu-models.texi   | 28 
 target/i386/cpu.c   |  7 +++
 target/i386/kvm.c   |  9 +
 tests/acceptance/cpu_queries.py | 33 +
 4 files changed, 69 insertions(+), 8 deletions(-)
 create mode 100644 tests/acceptance/cpu_queries.py

-- 
2.18.0.rc1.1.g3f1ff2140




Re: [Qemu-devel] Can't build without --disable-tcg after upgrading gcc (I think)

2019-03-21 Thread Richard Henderson
On 3/21/19 11:10 AM, Markus Armbruster wrote:
> I re-ran the failing compile with "-c -o tcg/tcg-op.o" replaced by "-E
> -dD -o tcg/tcg-op.i", and uploaded the resulting tcg-op.i to
> 
> https://www.pond.sub.org/~armbru/debug/tcg-op.i
> 
> Diffing this against yours might provide clues.

Either you're not building master,

-# 1 "/home/rth/work/qemu/qemu/accel/tcg/tcg-runtime.h" 1
+# 1 "/home/armbru/work/qemu/tcg/tcg-runtime.h" 1

since this file got moved 18 months ago,

commit 61a3f8f6c047620f4d55ade4f5607a9d019984c6
Author: Philippe Mathieu-Daudé 
Date:   Mon Sep 11 18:33:26 2017 -0300

accel/tcg: move tcg-runtime to accel/tcg/

Or, despite ccache -C, you're getting wrong results.

I myself hate ccache for the oddball effects it has, often not dissimilar to
this, and do not have it installed at all.


r~



Re: [Qemu-devel] [PATCH v6 0/2] Nios II generic board config and semihosting

2019-03-21 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/1553193630-28611-1-git-send-email-san...@codesourcery.com/



Hi,

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

Subject: [Qemu-devel] [PATCH v6 0/2] Nios II generic board config and 
semihosting
Message-id: 1553193630-28611-1-git-send-email-san...@codesourcery.com
Type: series

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

From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1553193630-28611-1-git-send-email-san...@codesourcery.com -> 
patchew/1553193630-28611-1-git-send-email-san...@codesourcery.com
Switched to a new branch 'test'
25e8e96 Add Nios II semihosting support.
531d106 Add generic Nios II board.

=== OUTPUT BEGIN ===
1/2 Checking commit 531d10673f8d (Add generic Nios II board.)
WARNING: Block comments use a leading /* on a separate line
#76: FILE: hw/nios2/boot.c:152:
+/* The Nios II processor reference guide documents that the

WARNING: Block comments use * on subsequent lines
#77: FILE: hw/nios2/boot.c:153:
+/* The Nios II processor reference guide documents that the
+   kernel is placed at virtual memory address 0xc000,

WARNING: Block comments use a trailing */ on a separate line
#79: FILE: hw/nios2/boot.c:155:
+   and adjust the entry to get the address in physical RAM.  */

ERROR: else should follow close brace '}'
#87: FILE: hw/nios2/boot.c:163:
+}
+else {

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

WARNING: Block comments use a leading /* on a separate line
#188: FILE: hw/nios2/generic_nommu.c:86:
+/* The libgloss linker script doesn't include an exception vector,

WARNING: Block comments use * on subsequent lines
#189: FILE: hw/nios2/generic_nommu.c:87:
+/* The libgloss linker script doesn't include an exception vector,
+   so use the reset address.  Boo.  */

WARNING: Block comments use a trailing */ on a separate line
#189: FILE: hw/nios2/generic_nommu.c:87:
+   so use the reset address.  Boo.  */

WARNING: Block comments use a leading /* on a separate line
#192: FILE: hw/nios2/generic_nommu.c:90:
+/* The linker script does have a TLB miss memory region declared,

WARNING: Block comments use * on subsequent lines
#193: FILE: hw/nios2/generic_nommu.c:91:
+/* The linker script does have a TLB miss memory region declared,
+   but this should never be used with no MMU.  */

WARNING: Block comments use a trailing */ on a separate line
#193: FILE: hw/nios2/generic_nommu.c:91:
+   but this should never be used with no MMU.  */

total: 1 errors, 10 warnings, 154 lines checked

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

2/2 Checking commit 25e8e964d9bf (Add Nios II semihosting support.)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#111: 
new file mode 100644

WARNING: Block comments use a leading /* on a separate line
#263: FILE: target/nios2/nios2-semi.c:148:
+/* The nios2 semihosting ABI does not provide any way to report this

WARNING: Block comments use a leading /* on a separate line
#293: FILE: target/nios2/nios2-semi.c:178:
+/* FIXME: We've already lost the high bits of the lseek

WARNING: Block comments use * on subsequent lines
#294: FILE: target/nios2/nios2-semi.c:179:
+/* FIXME: We've already lost the high bits of the lseek
+   return value.  */

WARNING: Block comments use a trailing */ on a separate line
#294: FILE: target/nios2/nios2-semi.c:179:
+   return value.  */

WARNING: Block comments use a leading /* on a separate line
#302: FILE: target/nios2/nios2-semi.c:187:
+/* Read the input value from the argument block; fail the semihosting

total: 0 errors, 6 warnings, 521 lines checked

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

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/1553193630-28611-1-git-send-email-san...@codesourcery.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH 1/2] trace: handle tracefs path truncation

2019-03-21 Thread Liam Merwick

On 21/03/2019 17:08, Stefan Hajnoczi wrote:

If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.

This issue does not occur on real-world systems since tracefs is mounted
on /sys/kernel/debug/tracing/, but the compiler is smart enough to
foresee the possibility and warn about the unchecked snprintf(3) return
value.  This patch fixes the compiler warning.

Reported-by: Markus Armbruster 
Signed-off-by: Stefan Hajnoczi 



Reviewed-by: Liam Merwick 



---
  trace/ftrace.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/trace/ftrace.c b/trace/ftrace.c
index 61692a8682..9749543d9b 100644
--- a/trace/ftrace.c
+++ b/trace/ftrace.c
@@ -53,7 +53,11 @@ bool ftrace_init(void)
  }
  
  if (tracefs_found) {

-snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir);
+if (snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir)
+>= sizeof(path)) {
+fprintf(stderr, "Using tracefs mountpoint would exceed 
PATH_MAX\n");
+return false;
+}
  trace_fd = open(path, O_WRONLY);
  if (trace_fd < 0) {
  if (errno == EACCES) {
@@ -72,7 +76,11 @@ bool ftrace_init(void)
  }
  close(trace_fd);
  }
-snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir);
+if (snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir)
+>= sizeof(path)) {
+fprintf(stderr, "Using tracefs mountpoint would exceed 
PATH_MAX\n");
+return false;
+}
  trace_marker_fd = open(path, O_WRONLY);
  if (trace_marker_fd < 0) {
  perror("Could not open ftrace 'trace_marker' file");






[Qemu-devel] [PATCH v6 1/2] Add generic Nios II board.

2019-03-21 Thread Sandra Loosemore
This patch adds support for a generic MMU-less Nios II board that can
be used e.g. for bare-metal compiler testing with the linker script
and startup code provided by libgloss.  Nios II booting is also
tweaked so that bare-metal binaries start executing in RAM starting at
0x, rather than an alias at 0xc000, which allows features
such as unwinding to work when binaries are linked to start at the
beginning of the address space.

The generic_nommu.c parts are based on code by Andrew Jenner, which was
in turn based on code by Marek Vasut.

Originally by Marek Vasut and Andrew Jenner.

Signed-off-by: Sandra Loosemore 
Signed-off-by: Julian Brown 
Signed-off-by: Andrew Jenner 
Signed-off-by: Marek Vasut 
---
 default-configs/nios2-softmmu.mak |   1 +
 hw/nios2/Kconfig  |   4 ++
 hw/nios2/Makefile.objs|   1 +
 hw/nios2/boot.c   |  17 ---
 hw/nios2/generic_nommu.c  | 104 ++
 5 files changed, 121 insertions(+), 6 deletions(-)
 create mode 100644 hw/nios2/generic_nommu.c

diff --git a/default-configs/nios2-softmmu.mak 
b/default-configs/nios2-softmmu.mak
index e11dc54..e130d02 100644
--- a/default-configs/nios2-softmmu.mak
+++ b/default-configs/nios2-softmmu.mak
@@ -3,3 +3,4 @@
 # Boards:
 #
 CONFIG_NIOS2_10M50=y
+CONFIG_NIOS2_GENERIC_NOMMU=y
diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
index ab953e0..b10ea64 100644
--- a/hw/nios2/Kconfig
+++ b/hw/nios2/Kconfig
@@ -4,5 +4,9 @@ config NIOS2_10M50
 select SERIAL
 select ALTERA_TIMER
 
+config NIOS2_GENERIC_NOMMU
+bool
+select NIOS2
+
 config NIOS2
 bool
diff --git a/hw/nios2/Makefile.objs b/hw/nios2/Makefile.objs
index 89a419a..3e01798 100644
--- a/hw/nios2/Makefile.objs
+++ b/hw/nios2/Makefile.objs
@@ -1,2 +1,3 @@
 obj-y = boot.o cpu_pic.o
 obj-$(CONFIG_NIOS2_10M50) += 10m50_devboard.o
+obj-$(CONFIG_NIOS2_GENERIC_NOMMU) += generic_nommu.o
diff --git a/hw/nios2/boot.c b/hw/nios2/boot.c
index 5f0ab2f..771877d 100644
--- a/hw/nios2/boot.c
+++ b/hw/nios2/boot.c
@@ -138,7 +138,6 @@ void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
 if (kernel_filename) {
 int kernel_size, fdt_size;
 uint64_t entry, low, high;
-uint32_t base32;
 int big_endian = 0;
 
 #ifdef TARGET_WORDS_BIGENDIAN
@@ -149,16 +148,22 @@ void nios2_load_kernel(Nios2CPU *cpu, hwaddr ddr_base,
 kernel_size = load_elf(kernel_filename, NULL, NULL, NULL,
, , ,
big_endian, EM_ALTERA_NIOS2, 0, 0);
-base32 = entry;
-if (base32 == 0xc000) {
+if ((uint32_t)entry == 0xc000) {
+/* The Nios II processor reference guide documents that the
+   kernel is placed at virtual memory address 0xc000,
+   and we've got something that points there.  Reload it
+   and adjust the entry to get the address in physical RAM.  */
 kernel_size = load_elf(kernel_filename, NULL,
translate_kernel_address, NULL,
, NULL, NULL,
big_endian, EM_ALTERA_NIOS2, 0, 0);
+boot_info.bootstrap_pc = ddr_base + 0xc000 +
+(entry & 0x07ff);
+}
+else {
+/* Use the entry point in the ELF image.  */
+boot_info.bootstrap_pc = (uint32_t)entry;
 }
-
-/* Always boot into physical ram. */
-boot_info.bootstrap_pc = ddr_base + 0xc000 + (entry & 0x07ff);
 
 /* If it wasn't an ELF image, try an u-boot image. */
 if (kernel_size < 0) {
diff --git a/hw/nios2/generic_nommu.c b/hw/nios2/generic_nommu.c
new file mode 100644
index 000..af8983a
--- /dev/null
+++ b/hw/nios2/generic_nommu.c
@@ -0,0 +1,104 @@
+/*
+ * Generic simulator target with no MMU or devices.  This emulation is
+ * compatible with the libgloss qemu-hosted.ld linker script for using
+ * QEMU as an instruction set simulator.
+ *
+ * Copyright (c) 2018-2019 Mentor Graphics
+ *
+ * Copyright (c) 2016 Marek Vasut 
+ *
+ * Based on LabX device code
+ *
+ * Copyright (c) 2012 Chris Wulff 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include 

Re: [Qemu-devel] [Qemu-block] [PATCH] tests/qemu-iotests/235: Allow fallback to tcg and remove it from quick group

2019-03-21 Thread Eric Blake
On 3/21/19 3:23 AM, Thomas Huth wrote:

> pipelines in that case. I had to manually select the test cases in the
> .gitlab-ci.yml file due to this. I don't mind too much, but IMHO "make
> check-block" should simply run everywhere, with every QEMU binary, and
> not only if you've compiled it with the right options and/or KVM is
> available. Otherwise, we maybe need a "make check-block-simple" or "make
> check-block-ci" target, that uses another new group beside the "quick"
> group? I.e. introduce a "ci" or "simple" group into

I don't know how to tell '-g quick' apart from '-g simple', but having a
'-g ci' where we can add or remove tests from ci by editing
qemu-iotests/group seems reasonable.  Then switching 'make check-block'
to prefer -g ci makes sense, while developers wanting a bit more
coverage without long waits can still rely on -g quick.

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



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH v6 2/2] Add Nios II semihosting support.

2019-03-21 Thread Sandra Loosemore
This patch adds support for libgloss semihosting to Nios II bare-metal
emulation.  The specification for the protocol can be found in the
libgloss sources.

Signed-off-by: Sandra Loosemore 
Signed-off-by: Julian Brown 
---
 qemu-options.hx|   8 +-
 target/nios2/Makefile.objs |   2 +-
 target/nios2/cpu.h |   4 +-
 target/nios2/helper.c  |  13 ++
 target/nios2/nios2-semi.c  | 448 +
 5 files changed, 469 insertions(+), 6 deletions(-)
 create mode 100644 target/nios2/nios2-semi.c

diff --git a/qemu-options.hx b/qemu-options.hx
index 08749a3..4135d5d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3968,21 +3968,21 @@ ETEXI
 DEF("semihosting", 0, QEMU_OPTION_semihosting,
 "-semihostingsemihosting mode\n",
 QEMU_ARCH_ARM | QEMU_ARCH_M68K | QEMU_ARCH_XTENSA | QEMU_ARCH_LM32 |
-QEMU_ARCH_MIPS)
+QEMU_ARCH_MIPS | QEMU_ARCH_NIOS2)
 STEXI
 @item -semihosting
 @findex -semihosting
-Enable semihosting mode (ARM, M68K, Xtensa, MIPS only).
+Enable semihosting mode (ARM, M68K, Xtensa, MIPS, Nios II only).
 ETEXI
 DEF("semihosting-config", HAS_ARG, QEMU_OPTION_semihosting_config,
 "-semihosting-config 
[enable=on|off][,target=native|gdb|auto][,arg=str[,...]]\n" \
 "semihosting configuration\n",
 QEMU_ARCH_ARM | QEMU_ARCH_M68K | QEMU_ARCH_XTENSA | QEMU_ARCH_LM32 |
-QEMU_ARCH_MIPS)
+QEMU_ARCH_MIPS | QEMU_ARCH_NIOS2)
 STEXI
 @item -semihosting-config 
[enable=on|off][,target=native|gdb|auto][,arg=str[,...]]
 @findex -semihosting-config
-Enable and configure semihosting (ARM, M68K, Xtensa, MIPS only).
+Enable and configure semihosting (ARM, M68K, Xtensa, MIPS, Nios II only).
 @table @option
 @item target=@code{native|gdb|auto}
 Defines where the semihosting calls will be addressed, to QEMU (@code{native})
diff --git a/target/nios2/Makefile.objs b/target/nios2/Makefile.objs
index 2a11c5c..010de0e 100644
--- a/target/nios2/Makefile.objs
+++ b/target/nios2/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += translate.o op_helper.o helper.o cpu.o mmu.o
+obj-y += translate.o op_helper.o helper.o cpu.o mmu.o nios2-semi.o
 obj-$(CONFIG_SOFTMMU) += monitor.o
 
 $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS)
diff --git a/target/nios2/cpu.h b/target/nios2/cpu.h
index 047f376..afd30d5 100644
--- a/target/nios2/cpu.h
+++ b/target/nios2/cpu.h
@@ -141,7 +141,7 @@ typedef struct Nios2CPUClass {
 #define R_PC 64
 
 /* Exceptions */
-#define EXCP_BREAK-1
+#define EXCP_BREAK0x1000
 #define EXCP_RESET0
 #define EXCP_PRESET   1
 #define EXCP_IRQ  2
@@ -223,6 +223,8 @@ void nios2_cpu_do_unaligned_access(CPUState *cpu, vaddr 
addr,
 qemu_irq *nios2_cpu_pic_init(Nios2CPU *cpu);
 void nios2_check_interrupts(CPUNios2State *env);
 
+void do_nios2_semihosting(CPUNios2State *env);
+
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
 #ifdef CONFIG_USER_ONLY
 # define TARGET_VIRT_ADDR_SPACE_BITS 31
diff --git a/target/nios2/helper.c b/target/nios2/helper.c
index a8b8ec6..bb0a784 100644
--- a/target/nios2/helper.c
+++ b/target/nios2/helper.c
@@ -23,8 +23,10 @@
 #include "cpu.h"
 #include "qemu/host-utils.h"
 #include "exec/exec-all.h"
+#include "exec/cpu_ldst.h"
 #include "exec/log.h"
 #include "exec/helper-proto.h"
+#include "exec/semihost.h"
 
 #if defined(CONFIG_USER_ONLY)
 
@@ -169,6 +171,17 @@ void nios2_cpu_do_interrupt(CPUState *cs)
 break;
 
 case EXCP_BREAK:
+qemu_log_mask(CPU_LOG_INT, "BREAK exception at pc=%x\n",
+  env->regs[R_PC]);
+/* The semihosting instruction is "break 1".  */
+if (semihosting_enabled() &&
+cpu_ldl_code(env, env->regs[R_PC]) == 0x003da07a)  {
+qemu_log_mask(CPU_LOG_INT, "Entering semihosting\n");
+env->regs[R_PC] += 4;
+do_nios2_semihosting(env);
+break;
+}
+
 if ((env->regs[CR_STATUS] & CR_STATUS_EH) == 0) {
 env->regs[CR_BSTATUS] = env->regs[CR_STATUS];
 env->regs[R_BA] = env->regs[R_PC] + 4;
diff --git a/target/nios2/nios2-semi.c b/target/nios2/nios2-semi.c
new file mode 100644
index 000..4e45a27
--- /dev/null
+++ b/target/nios2/nios2-semi.c
@@ -0,0 +1,448 @@
+/*
+ *  Nios II Semihosting syscall interface.
+ *  This code is derived from m68k-semi.c.
+ *
+ *  Copyright (c) 2017-2019 Mentor Graphics
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see 

Re: [Qemu-devel] [PATCH 2/2] trace: avoid SystemTap dtrace(1) warnings on empty files

2019-03-21 Thread Liam Merwick

On 21/03/2019 17:08, Stefan Hajnoczi wrote:

target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}".  SystemTap's
dtrace(1) tool prints a warning when processing this input file.

This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there are no enabled trace events.

Fixes: 23c3d569f44284066714ff7c46bc4f19e630583f ("target/hppa: add TLB trace 
events")
Reported-by: Markus Armbruster 
Signed-off-by: Stefan Hajnoczi 



Reviewed-by: Liam Merwick 



---
  scripts/tracetool/format/d.py | 5 +
  1 file changed, 5 insertions(+)

diff --git a/scripts/tracetool/format/d.py b/scripts/tracetool/format/d.py
index 78397c24d2..c7cb2a93a6 100644
--- a/scripts/tracetool/format/d.py
+++ b/scripts/tracetool/format/d.py
@@ -33,6 +33,11 @@ def generate(events, backend, group):
  events = [e for e in events
if "disable" not in e.properties]
  
+# SystemTap's dtrace(1) warns about empty "provider qemu {}" but is happy

+# with an empty file.  Avoid the warning.
+if not events:
+return
+
  out('/* This file is autogenerated by tracetool, do not edit. */'
  '',
  'provider qemu {')






[Qemu-devel] [PATCH v6 0/2] Nios II generic board config and semihosting

2019-03-21 Thread Sandra Loosemore
This is the sixth version of the patch series last posted here:
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg03167.html

Changes since v5 include:
- The code to allow booting from a low memory address has been simplified
  and better commented.
- Random devices not supported by the libgloss BSP have been removed from
  the new nios2-generic-nommu emulation.
- FIXMEs in the semihosting code have been fixed, along with other nits
  from review.

Also, the semihosting specification can now be found in libgloss.

Sandra Loosemore (2):
  Add generic Nios II board.
  Add Nios II semihosting support.

 default-configs/nios2-softmmu.mak |   1 +
 hw/nios2/Kconfig  |   4 +
 hw/nios2/Makefile.objs|   1 +
 hw/nios2/boot.c   |  17 +-
 hw/nios2/generic_nommu.c  | 104 +
 qemu-options.hx   |   8 +-
 target/nios2/Makefile.objs|   2 +-
 target/nios2/cpu.h|   4 +-
 target/nios2/helper.c |  13 ++
 target/nios2/nios2-semi.c | 448 ++
 10 files changed, 590 insertions(+), 12 deletions(-)
 create mode 100644 hw/nios2/generic_nommu.c
 create mode 100644 target/nios2/nios2-semi.c

-- 
2.8.1




Re: [Qemu-devel] [PATCH 2/2] trace: avoid SystemTap dtrace(1) warnings on empty files

2019-03-21 Thread Markus Armbruster
Stefan Hajnoczi  writes:

> target/hppa/trace-events only contains disabled events, resulting in a
> trace-dtrace.dtrace file that says "provider qemu {}".  SystemTap's
> dtrace(1) tool prints a warning when processing this input file.
>
> This patch avoids the error by emitting an empty file instead of
> "provider qemu {}" when there are no enabled trace events.
>
> Fixes: 23c3d569f44284066714ff7c46bc4f19e630583f ("target/hppa: add TLB trace 
> events")
> Reported-by: Markus Armbruster 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  scripts/tracetool/format/d.py | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/scripts/tracetool/format/d.py b/scripts/tracetool/format/d.py
> index 78397c24d2..c7cb2a93a6 100644
> --- a/scripts/tracetool/format/d.py
> +++ b/scripts/tracetool/format/d.py
> @@ -33,6 +33,11 @@ def generate(events, backend, group):
>  events = [e for e in events
>if "disable" not in e.properties]
>  
> +# SystemTap's dtrace(1) warns about empty "provider qemu {}" but is happy
> +# with an empty file.  Avoid the warning.
> +if not events:
> +return
> +
>  out('/* This file is autogenerated by tracetool, do not edit. */'
>  '',
>  'provider qemu {')

Results in an empty file.  I'm fine with that.  I'd also be fine with a
file that just has the comment.

Reviewed-by: Markus Armbruster 



Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Laszlo Ersek
On 03/21/19 18:58, Peter Maydell wrote:
> On Thu, 21 Mar 2019 at 17:35, Laszlo Ersek  wrote:
>> It simply keeps the status quo from before the patchset.
>>
>> The specific emulation targets that virtio-vga should not be enabled for
>> (regardless of other targets / machine types) are arm/aarch64. IOW, in
>> the longer term, it's not that virtio-vga is suitable only for PC ||
>> DINO || PSERIES, but that it's *not* suitable for arm/aarch64.
> 
> Relying on the device not being present for aarch64 seems
> fragile to me. It will break if we add a different
> aarch64 machine other than "virt" and want that other
> machine to have virtio-vga. It will also break if we
> ever manage to get full heterogenous-CPU support and
> end up with a single qemu-system binary that can emulate
> both AArch64 virt and x86-64 pc machines :-)
> 
> If what you want is "don't use virtio-vga when using KVM
> on aarch64" then why not have logic that implements that?

That's actually the logic that I implemented originally (or something very 
close to it -- 
),
 but since then, this code has been modified in libvirt multiple times:

* [libvirt] [PATCH v2 00/17] cleanups and improvements for video device code
  https://www.redhat.com/archives/libvir-list/2016-October/msg00533.html
  
https://libvirt.org/git/?p=libvirt.git;a=shortlog;hp=a62655f9c33a8f7c6257779ddbdbf1352d53a526;h=fb8f3b1c22c8f272bb9a47e8f8915acc3cfb47f1

* [libvirt] [PATCH v3 0/6] Add support for video and input devices on S390
  https://www.redhat.com/archives/libvir-list/2018-March/msg01519.html
  
https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=4bbf7f8cb5bf979ea2f5c247b2ddb884a07ac33f

I'm not implying that those patches must have introduced a libvirt regression, 
I just agree that the code deserves investigation. This is why I added 
libvir-list to the CC list when reporting the problem.

> For 4.0 we should definitely just retain what we had
> before the introduction of KConfig, but as a general
> thing we should look to not have to have this odd
> wrinkle.
> 
> (AFAIK virtio-vga is no different in this regard to the other
> vga PCI devices, which also won't work in KVM setups.)

I agree -- please refer to the "domcapabilities" part (1) of my report:

https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06060.html

> @@ -92,6 +92,8 @@
>  
>
>  vga
> +cirrus
> +vmvga
>  virtio
>
>  

"cirrus" and "vmvga" look wrong for aarch64.

Thanks
Laszlo



Re: [Qemu-devel] [PATCH 1/2] trace: handle tracefs path truncation

2019-03-21 Thread Markus Armbruster
Stefan Hajnoczi  writes:

> If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
> This is a system misconfiguration and the user must resolve it so that
> applications can perform path-based system calls successfully.
>
> This issue does not occur on real-world systems since tracefs is mounted
> on /sys/kernel/debug/tracing/, but the compiler is smart enough to
> foresee the possibility and warn about the unchecked snprintf(3) return
> value.  This patch fixes the compiler warning.
>
> Reported-by: Markus Armbruster 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  trace/ftrace.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/trace/ftrace.c b/trace/ftrace.c
> index 61692a8682..9749543d9b 100644
> --- a/trace/ftrace.c
> +++ b/trace/ftrace.c
> @@ -53,7 +53,11 @@ bool ftrace_init(void)
>  }
>  
>  if (tracefs_found) {
> -snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir);
> +if (snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir)
> +>= sizeof(path)) {
> +fprintf(stderr, "Using tracefs mountpoint would exceed 
> PATH_MAX\n");
> +return false;
> +}
>  trace_fd = open(path, O_WRONLY);
>  if (trace_fd < 0) {
>  if (errno == EACCES) {
> @@ -72,7 +76,11 @@ bool ftrace_init(void)
>  }
>  close(trace_fd);
>  }
> -snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir);
> +if (snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, 
> subdir)
> +>= sizeof(path)) {
> +fprintf(stderr, "Using tracefs mountpoint would exceed 
> PATH_MAX\n");
> +return false;
> +}
>  trace_marker_fd = open(path, O_WRONLY);
>  if (trace_marker_fd < 0) {
>  perror("Could not open ftrace 'trace_marker' file");

If we expected these errors to happen, then I'd suggest to include the
problematic mount point in the error message.  Since we don't, it
doesn't feel worth the bother.

Reviewed-by: Markus Armbruster 



Re: [Qemu-devel] Can't build without --disable-tcg after upgrading gcc (I think)

2019-03-21 Thread Markus Armbruster
Richard Henderson  writes:

> On 3/20/19 11:38 PM, Markus Armbruster wrote:
>> Yesterday's "dnf upgrade" on my F28 box upgraded gcc to
>> gcc-8.2.1-6.fc28.x86_64 from 8.3.1-2.fc28.x86_64.  Since then (I think),
>> builds fail for me, details appended.  Any ideas?
>> 
>> My temporary work-around is configure --disable-tcg.
>
> No ideas.  I just did that same dnf upgrade, rm -rf build,
> and everything worked fine.
>
> gcc version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)
> commit c692931cda9dc6cbc16b89d5094a725a10dbb641
>   (HEAD -> master, origin/master, origin/HEAD)

In an empty build directory:

$ ccache -C
$ ../configure --disable-gnutls --disable-nettle --disable-gcrypt 
--disable-sdl --disable-gtk --disable-vte --disable-curses --disable-vnc 
--disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa 
--disable-virtfs --disable-mpath --disable-xen --disable-xen-pci-passthrough 
--disable-brlapi --disable-curl --disable-membarrier --disable-bluez 
--disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma 
--disable-pvrdma --disable-vde --disable-netmap --disable-linux-aio 
--disable-cap-ng --disable-attr --disable-vhost-net --disable-vhost-crypto 
--disable-spice --disable-rbd --disable-libiscsi --disable-libnfs 
--disable-smartcard --disable-libusb --disable-live-block-migration 
--disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 
--disable-seccomp --disable-coroutine-pool --disable-glusterfs --disable-tpm 
--disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc 
--disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl 
--disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug 
--disable-tools --disable-vxhs --disable-bochs --disable-cloop --disable-dmg 
--disable-qcow1 --disable-vdi --disable-vvfat --disable-qed --disable-parallels 
--disable-sheepdog --disable-crypto-afalg --disable-vhost-user 
--disable-capstone --disable-debug-mutex --disable-libpmem
$ make V=1
[...]
cc -iquote /work/armbru/qemu/bld-min/tcg -iquote tcg -iquote 
/home/armbru/work/qemu/tcg -iquote /home/armbru/work/qemu/tcg/i386 
-I/home/armbru/work/qemu/linux-headers 
-I/home/armbru/work/qemu/bld-min/linux-headers -iquote . -iquote 
/home/armbru/work/qemu -iquote /home/armbru/work/qemu/accel/tcg -iquote 
/home/armbru/work/qemu/include -I/usr/include/pixman-1  
-I/home/armbru/work/qemu/dtc/libfdt -Werror  -pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include  -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -std=gnu99  -Wexpansion-to-defined 
-Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong  -I../linux-headers -iquote .. -iquote 
/home/armbru/work/qemu/target/i386 -DNEED_CPU_H -iquote 
/home/armbru/work/qemu/include -MMD -MP -MT tcg/tcg-op.o -MF tcg/tcg-op.d -O2 
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g   -c -o tcg/tcg-op.o 
/home/armbru/work/qemu/tcg/tcg-op.c
/home/armbru/work/qemu/tcg/tcg-op.c: In function ‘tcg_gen_clz_i32’:
/home/armbru/work/qemu/tcg/tcg-op.c:430:9: error: implicit declaration of 
function ‘gen_helper_clz_i32’; did you mean ‘gen_helper_rem_i32’? 
[-Werror=implicit-function-declaration]
 gen_helper_clz_i32(ret, arg1, arg2);
 ^~
 gen_helper_rem_i32
/home/armbru/work/qemu/tcg/tcg-op.c:430:9: error: nested extern declaration 
of ‘gen_helper_clz_i32’ [-Werror=nested-externs]
[many more...]

My collection of --disable is a somewhat stale attempt at a
close-to-minimal build, and shouldn't matter.

I re-ran the failing compile with "-c -o tcg/tcg-op.o" replaced by "-E
-dD -o tcg/tcg-op.i", and uploaded the resulting tcg-op.i to

https://www.pond.sub.org/~armbru/debug/tcg-op.i

Diffing this against yours might provide clues.



Re: [Qemu-devel] [Qemu-block] [PATCH] tests/qemu-iotests/235: Allow fallback to tcg and remove it from quick group

2019-03-21 Thread John Snow



On 3/21/19 4:23 AM, Thomas Huth wrote:
> On 20/03/2019 18.32, John Snow wrote:
>>
>>
>> On 3/1/19 7:20 AM, Thomas Huth wrote:
>>> iotest 235 currently only works with KVM - this is bad for systems where
>>> it is not available, e.g. CI pipelines. The test also works when using
>>> "tcg" as accelerator, so we can simply add that to the list of accelerators,
>>> too. But still, there might be the case that someone compiled their
>>> QEMU with --disable-tcg and still try to run the iotests in a CI pipeline
>>> where KVM is not available - in that case it would be best to use the
>>> "qtest" accelerator for this test. However, that currently hangs and I
>>> did not succeed to get it working with "accel=qtest" yet. Thus, as long
>>> as this is not fixed, it's likely better to remove this test from the
>>> "quick" group so that it does not fail on CI pipelines.
>>>
>>> Signed-off-by: Thomas Huth 
>>
>> What happens if we set accel=kvm:tcg but leave it in quick group? It
>> will still fail in those cases where we have neither accelerator for
>> whichever reason, but maybe that's better than just trying to prevent it
>> from running ... ?
> 
> ... but since it is failing, you can't use "make check-block" in the CI
> pipelines in that case. I had to manually select the test cases in the
> .gitlab-ci.yml file due to this. I don't mind too much, but IMHO "make
> check-block" should simply run everywhere, with every QEMU binary, and
> not only if you've compiled it with the right options and/or KVM is
> available. Otherwise, we maybe need a "make check-block-simple" or "make
> check-block-ci" target, that uses another new group beside the "quick"
> group? I.e. introduce a "ci" or "simple" group into
> tests/qemu-iotests/group ?
> 

It still feels like papering over the problem to me; if the test is
failing on qtest that feels like an accurate test result we shouldn't
hide or ignore...?

I realize that's inconvenient, but is it common for us to have neither
TCG nor KVM? (I genuinely don't know. I'd have thought that's fairly
rare? Clearly not for you.)

If the problem is that the test suite stops on first failure, should we
amend the execution to continue on in those cases?

--js

(I guess I should look at why the test doesn't work under qtest, but I
have some downstream work to finish before I could prioritize that.)



[Qemu-devel] [PATCH v2] test-announce-self: convert to qgraph

2019-03-21 Thread Paolo Bonzini
This removes the duplicated initialization code.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Paolo Bonzini 
---
 tests/Makefile.include |  3 --
 tests/test-announce-self.c | 73 --
 tests/virtio-net-test.c| 30 
 3 files changed, 30 insertions(+), 76 deletions(-)
 delete mode 100644 tests/test-announce-self.c

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 852f17b8c7..6b904d7430 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -195,7 +195,6 @@ check-qtest-i386-$(CONFIG_SLIRP) += 
tests/test-netfilter$(EXESUF)
 check-qtest-i386-$(CONFIG_POSIX) += tests/test-filter-mirror$(EXESUF)
 check-qtest-i386-$(CONFIG_RTL8139_PCI) += tests/test-filter-redirector$(EXESUF)
 check-qtest-i386-y += tests/migration-test$(EXESUF)
-check-qtest-i386-y += tests/test-announce-self$(EXESUF)
 check-qtest-i386-y += tests/test-x86-cpuid-compat$(EXESUF)
 check-qtest-i386-y += tests/numa-test$(EXESUF)
 check-qtest-x86_64-y += $(check-qtest-i386-y)
@@ -232,7 +231,6 @@ check-qtest-ppc64-y += $(check-qtest-ppc-y)
 check-qtest-ppc64-$(CONFIG_PSERIES) += tests/device-plug-test$(EXESUF)
 check-qtest-ppc64-$(CONFIG_POWERNV) += tests/pnv-xscom-test$(EXESUF)
 check-qtest-ppc64-y += tests/migration-test$(EXESUF)
-check-qtest-ppc64-y += tests/test-announce-self$(EXESUF)
 check-qtest-ppc64-$(CONFIG_PSERIES) += tests/rtas-test$(EXESUF)
 check-qtest-ppc64-$(CONFIG_SLIRP) += tests/pxe-test$(EXESUF)
 check-qtest-ppc64-$(CONFIG_USB_UHCI) += tests/usb-hcd-uhci-test$(EXESUF)
@@ -817,7 +815,6 @@ tests/usb-hcd-ehci-test$(EXESUF): tests/usb-hcd-ehci-test.o 
$(libqos-usb-obj-y)
 tests/usb-hcd-xhci-test$(EXESUF): tests/usb-hcd-xhci-test.o $(libqos-usb-obj-y)
 tests/cpu-plug-test$(EXESUF): tests/cpu-plug-test.o
 tests/migration-test$(EXESUF): tests/migration-test.o
-tests/test-announce-self$(EXESUF): tests/test-announce-self.o
 tests/qemu-iotests/socket_scm_helper$(EXESUF): 
tests/qemu-iotests/socket_scm_helper.o
 tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o $(test-util-obj-y)
 tests/test-keyval$(EXESUF): tests/test-keyval.o $(test-util-obj-y) 
$(test-qapi-obj-y)
diff --git a/tests/test-announce-self.c b/tests/test-announce-self.c
deleted file mode 100644
index 0e6d466aa4..00
--- a/tests/test-announce-self.c
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * QTest testcase for qemu_announce_self
- *
- * Copyright (c) 2017 Red hat, Inc.
- * Copyright (c) 2014 SUSE LINUX Products GmbH
- *
- * 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 "libqtest.h"
-#include "qapi/qmp/qdict.h"
-#include "qemu-common.h"
-#include "qemu/sockets.h"
-#include "qemu/iov.h"
-#include "libqos/libqos-pc.h"
-#include "libqos/libqos-spapr.h"
-
-#ifndef ETH_P_RARP
-#define ETH_P_RARP 0x8035
-#endif
-
-
-static void test_announce(QTestState *qs, int socket)
-{
-char buffer[60];
-int len;
-QDict *rsp;
-int ret;
-uint16_t *proto = (uint16_t *)[12];
-
-rsp = qtest_qmp(qs, "{ 'execute' : 'announce-self', "
-  " 'arguments': {"
-  " 'initial': 50, 'max': 550,"
-  " 'rounds': 10, 'step': 50 } }");
-assert(!qdict_haskey(rsp, "error"));
-qobject_unref(rsp);
-
-/* Catch the packet and make sure it's a RARP */
-ret = qemu_recv(socket, , sizeof(len), 0);
-g_assert_cmpint(ret, ==,  sizeof(len));
-len = ntohl(len);
-
-ret = qemu_recv(socket, buffer, len, 0);
-g_assert_cmpint(*proto, ==, htons(ETH_P_RARP));
-}
-
-static void setup(gconstpointer data)
-{
-QTestState *qs;
-void (*func) (QTestState *qs, int socket) = data;
-int sv[2], ret;
-
-ret = socketpair(PF_UNIX, SOCK_STREAM, 0, sv);
-g_assert_cmpint(ret, !=, -1);
-
-qs = qtest_initf("-netdev socket,fd=%d,id=hs0 -device "
- "virtio-net-pci,netdev=hs0", sv[1]);
-func(qs, sv[0]);
-
-/* End test */
-close(sv[0]);
-qtest_quit(qs);
-}
-
-int main(int argc, char **argv)
-{
-g_test_init(, , NULL);
-qtest_add_data_func("/virtio/net/test_announce_self", test_announce, 
setup);
-
-return g_test_run();
-}
diff --git a/tests/virtio-net-test.c b/tests/virtio-net-test.c
index c58e670e2f..0d956f36fe 100644
--- a/tests/virtio-net-test.c
+++ b/tests/virtio-net-test.c
@@ -15,6 +15,10 @@
 #include "libqos/qgraph.h"
 #include "libqos/virtio-net.h"
 
+#ifndef ETH_P_RARP
+#define ETH_P_RARP 0x8035
+#endif
+
 #define PCI_SLOT_HP 0x06
 #define PCI_SLOT0x04
 
@@ -168,6 +172,31 @@ static void hotplug(void *obj, void *data, QGuestAllocator 
*t_alloc)
 }
 }
 
+static void announce_self(void *obj, void *data, QGuestAllocator *t_alloc)
+{
+int *sv = data;
+char buffer[60];
+int len;
+QDict *rsp;
+int ret;
+uint16_t *proto = (uint16_t *)[12];
+
+rsp = qmp("{ 'execute' : 'announce-self', "
+  " 

Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 17:35, Laszlo Ersek  wrote:
> It simply keeps the status quo from before the patchset.
>
> The specific emulation targets that virtio-vga should not be enabled for
> (regardless of other targets / machine types) are arm/aarch64. IOW, in
> the longer term, it's not that virtio-vga is suitable only for PC ||
> DINO || PSERIES, but that it's *not* suitable for arm/aarch64.

Relying on the device not being present for aarch64 seems
fragile to me. It will break if we add a different
aarch64 machine other than "virt" and want that other
machine to have virtio-vga. It will also break if we
ever manage to get full heterogenous-CPU support and
end up with a single qemu-system binary that can emulate
both AArch64 virt and x86-64 pc machines :-)

If what you want is "don't use virtio-vga when using KVM
on aarch64" then why not have logic that implements that?

For 4.0 we should definitely just retain what we had
before the introduction of KConfig, but as a general
thing we should look to not have to have this odd
wrinkle.

(AFAIK virtio-vga is no different in this regard to the other
vga PCI devices, which also won't work in KVM setups.)

thanks
-- PMM



Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Laszlo Ersek
On 03/21/19 15:21, Philippe Mathieu-Daudé wrote:
> Le jeu. 21 mars 2019 13:39, Laszlo Ersek  a écrit :
> 
>> On 03/21/19 01:53, Laszlo Ersek wrote:
>>> Hi Paolo,
>>>
>>> (+libvir-list)
>>>
>>> I'd like to report a regression introduced by this patch set:
>>>
>>> On 03/07/19 21:58, Paolo Bonzini wrote:
 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:

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

 for you to fetch changes up to
 576c3f2f16e7392e28cc9fe10d9a920d67d3645b:

   kconfig: add documentation (2019-03-07 21:54:22 +0100)

 
 Initial Kconfig work, excluding ARM and MIPS

 
>>>
>>
>> In brief, the regression is that the aarch64 system emulator now lists
>> the "virtio-vga" device for the "virt" machine type:
>>
>> $ qemu-system-aarch64 -M virt -device \? | grep virtio-vga
>> name "virtio-vga", bus PCI
>>
>> Here's where I think the issue was introduced:
>>
>> (1) In commit 82f5181777eb ("kconfig: introduce kconfig files",
>> 2019-03-07), VIRTIO_VGA was introduced simply as a bool (with no other
>> clauses) in "hw/display/Kconfig".
>>
>> (2) In commit 7c28b925b7e1 ("build: convert pci.mak to Kconfig",
>> 2019-03-07), VIRTIO_VGA received the following clauses:
>>
>> default y if PCI_DEVICES
>> depends on VIRTIO_PCI
>> select VGA
>>
>> This is too lax, because it permits virtio-vga for aarch64, while that
>> shouldn't happen (and it doesn't matches the previous state of the tree).
>>
> 
> Similar case I noticed in another thread. The Virt machine uses a chipset
> that provides PCI. Does this machine expose PCI slots?

It provides a PCI Express hierarchy, so "yes". (If you mean traditional
PCI, that is also available through the pcie-pci bridge device model,
which you can plug into the PCIE hierarchy.)

> If yes, this config
> is correct, the machine can get any PCI daughter card.

Haha, right, in theory :) On the same note, the ARMv8 architecture
should also, "in theory", have allowed the host side page mappings
unconditionally override the guest side mappings, like it works on x86.
Because in that case, QemuVideoDxe / the framebuffer would have just
worked in aarch64 guests too, I wouldn't have had to write VirtioGpuDxe
in the first place, and everybody would have been happy with just
virtio-vga.

But ARMv8 is not like that, so things don't work like that.

> Else we shouldn't
> use PCI_DEVICES that way.
> 
> Why Virt machine now default to virtio-vga?

See above, plus my answer to Peter.

Thanks
Laszlo

>> (3) In commit b42075bb7767 ("virtio: express virtio dependencies with
>> Kconfig", 2019-03-07), the determination of virtio-vga was switched to
>> the Kconfig system. Importantly, in this patch, the line
>>
>>   CONFIG_VIRTIO_VGA=y
>>
>> was removed *only* from the following file:
>>
>>   default-configs/i386-softmmu.mak
>>
>> (4) Both of the remaining instances of
>>
>>   CONFIG_VIRTIO_VGA=y
>>
>> were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express
>> dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64:
>> Express dependencies of 'pseries' and 'powernv' machines with kconfig",
>> 2019-03-07), from files
>>
>>   default-configs/hppa-softmmu.mak
>>   default-configs/ppc64-softmmu.mak
>>
>> respectively.
>>
>>
>> Therefore I think commit 7c28b925b7e1 has the bug. The VIRTIO_VGA
>> restriction
>>
>>   depends on VIRTIO_PCI
>>
>> should now be replaced with
>>
>>   depends on VIRTIO_PCI && (PC || DINO || PSERIES)
>>
>> Thanks
>> Laszlo
>>
>>
> 




Re: [Qemu-devel] [PATCH] test-announce-self: convert to qgraph

2019-03-21 Thread Thomas Huth
On 12/03/2019 17.57, Paolo Bonzini wrote:
> This removes the duplicated initialization code.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  tests/Makefile.include |  3 --
>  tests/test-announce-self.c | 82 --
>  tests/virtio-net-test.c| 30 ++
>  3 files changed, 30 insertions(+), 85 deletions(-)
>  delete mode 100644 tests/test-announce-self.c
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index a5719551dd..56764c7543 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -195,7 +195,6 @@ check-qtest-i386-$(CONFIG_SLIRP) += 
> tests/test-netfilter$(EXESUF)
>  check-qtest-i386-$(CONFIG_POSIX) += tests/test-filter-mirror$(EXESUF)
>  check-qtest-i386-$(CONFIG_RTL8139_PCI) += 
> tests/test-filter-redirector$(EXESUF)
>  check-qtest-i386-y += tests/migration-test$(EXESUF)
> -check-qtest-i386-y += tests/test-announce-self$(EXESUF)
>  check-qtest-i386-y += tests/test-x86-cpuid-compat$(EXESUF)
>  check-qtest-i386-y += tests/numa-test$(EXESUF)
>  check-qtest-x86_64-y += $(check-qtest-i386-y)
> @@ -232,7 +231,6 @@ check-qtest-ppc64-y += $(check-qtest-ppc-y)
>  check-qtest-ppc64-$(CONFIG_PSERIES) += tests/device-plug-test$(EXESUF)
>  check-qtest-ppc64-$(CONFIG_POWERNV) += tests/pnv-xscom-test$(EXESUF)
>  check-qtest-ppc64-y += tests/migration-test$(EXESUF)
> -check-qtest-ppc64-y += tests/test-announce-self$(EXESUF)
>  check-qtest-ppc64-$(CONFIG_PSERIES) += tests/rtas-test$(EXESUF)
>  check-qtest-ppc64-$(CONFIG_SLIRP) += tests/pxe-test$(EXESUF)
>  check-qtest-ppc64-$(CONFIG_USB_UHCI) += tests/usb-hcd-uhci-test$(EXESUF)
> @@ -817,7 +815,6 @@ tests/usb-hcd-ehci-test$(EXESUF): 
> tests/usb-hcd-ehci-test.o $(libqos-usb-obj-y)
>  tests/usb-hcd-xhci-test$(EXESUF): tests/usb-hcd-xhci-test.o 
> $(libqos-usb-obj-y)
>  tests/cpu-plug-test$(EXESUF): tests/cpu-plug-test.o
>  tests/migration-test$(EXESUF): tests/migration-test.o
> -tests/test-announce-self$(EXESUF): tests/test-announce-self.o
>  tests/qemu-iotests/socket_scm_helper$(EXESUF): 
> tests/qemu-iotests/socket_scm_helper.o
>  tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o $(test-util-obj-y)
>  tests/test-keyval$(EXESUF): tests/test-keyval.o $(test-util-obj-y) 
> $(test-qapi-obj-y)
> diff --git a/tests/test-announce-self.c b/tests/test-announce-self.c
> deleted file mode 100644
> index 1644d34a3f..00
> --- a/tests/test-announce-self.c
> +++ /dev/null
> @@ -1,82 +0,0 @@
> -/*
> - * QTest testcase for qemu_announce_self
> - *
> - * Copyright (c) 2017 Red hat, Inc.
> - * Copyright (c) 2014 SUSE LINUX Products GmbH
> - *
> - * 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 "libqtest.h"
> -#include "qapi/qmp/qdict.h"
> -#include "qemu-common.h"
> -#include "qemu/sockets.h"
> -#include "qemu/iov.h"
> -#include "libqos/libqos-pc.h"
> -#include "libqos/libqos-spapr.h"
> -
> -#ifndef ETH_P_RARP
> -#define ETH_P_RARP 0x8035
> -#endif
> -
> -static QTestState *test_init(int socket)
> -{
> -char *args;
> -
> -args = g_strdup_printf("-netdev socket,fd=%d,id=hs0 -device "
> -   "virtio-net-pci,netdev=hs0", socket);
> -
> -return qtest_start(args);
> -}

This function has recently been removed to fix the memory leak here.
Could you please rebase your patch?

 Thomas



Re: [Qemu-devel] [PATCH] target/riscv: Zero extend the inputs of divuw and remuw

2019-03-21 Thread Richard Henderson
On 3/21/19 7:59 AM, Palmer Dabbelt wrote:
> While running the GCC test suite against 4.0.0-rc0, Kito found a
> regression introduced by the decodetree conversion that caused divuw and
> remuw to sign-extend their inputs.  The ISA manual says they are
> supposed to be zero extended:
> 
> DIVW and DIVUW instructions are only valid for RV64, and divide the
> lower 32 bits of rs1 by the lower 32 bits of rs2, treating them as
> signed and unsigned integers respectively, placing the 32-bit
> quotient in rd, sign-extended to 64 bits. REMW and REMUW
> instructions are only valid for RV64, and provide the corresponding
> signed and unsigned remainder operations respectively.  Both REMW
> and REMUW always sign-extend the 32-bit result to 64 bits, including
> on a divide by zero.
> 
> Here's Kito's reduced test case from the GCC test suite
> 
> unsigned calc_mp(unsigned mod)
> {
>  unsigned a,b,c;
>  c=-1;
>  a=c/mod;
>  b=0-a*mod;
>  if (b > mod) { a += 1; b-=mod; }
>  return b;
> }
> 
> int main(int argc, char *argv[])
> {
>  unsigned x = 1234;
>  unsigned y = calc_mp(x);
> 
>  if ((sizeof (y) == 4 && y != 680)
>   || (sizeof (y) == 2 && y != 134))
> abort ();
>  exit (0);
> }
> 
> I haven't done any other testing on this, but it does fix the test case.
> 
> Signed-off-by: Palmer Dabbelt 
> ---
>  target/riscv/insn_trans/trans_rvm.inc.c |  4 ++--
>  target/riscv/translate.c| 21 +
>  2 files changed, 23 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~



Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Laszlo Ersek
On 03/21/19 14:04, Peter Maydell wrote:
> On Thu, 21 Mar 2019 at 12:40, Laszlo Ersek  wrote:
>> In brief, the regression is that the aarch64 system emulator now lists
>> the "virtio-vga" device for the "virt" machine type:
>>
>> $ qemu-system-aarch64 -M virt -device \? | grep virtio-vga
>> name "virtio-vga", bus PCI
>>
>> Here's where I think the issue was introduced:
>>
>> (1) In commit 82f5181777eb ("kconfig: introduce kconfig files",
>> 2019-03-07), VIRTIO_VGA was introduced simply as a bool (with no other
>> clauses) in "hw/display/Kconfig".
>>
>> (2) In commit 7c28b925b7e1 ("build: convert pci.mak to Kconfig",
>> 2019-03-07), VIRTIO_VGA received the following clauses:
>>
>> default y if PCI_DEVICES
>> depends on VIRTIO_PCI
>> select VGA
>>
>> This is too lax, because it permits virtio-vga for aarch64, while that
>> shouldn't happen (and it doesn't matches the previous state of the tree).
>>
>> (3) In commit b42075bb7767 ("virtio: express virtio dependencies with
>> Kconfig", 2019-03-07), the determination of virtio-vga was switched to
>> the Kconfig system. Importantly, in this patch, the line
>>
>>   CONFIG_VIRTIO_VGA=y
>>
>> was removed *only* from the following file:
>>
>>   default-configs/i386-softmmu.mak
>>
>> (4) Both of the remaining instances of
>>
>>   CONFIG_VIRTIO_VGA=y
>>
>> were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express
>> dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64:
>> Express dependencies of 'pseries' and 'powernv' machines with kconfig",
>> 2019-03-07), from files
>>
>>   default-configs/hppa-softmmu.mak
>>   default-configs/ppc64-softmmu.mak
>>
>> respectively.
>>
>>
>> Therefore I think commit 7c28b925b7e1 has the bug. The VIRTIO_VGA
>> restriction
>>
>>   depends on VIRTIO_PCI
>>
>> should now be replaced with
>>
>>   depends on VIRTIO_PCI && (PC || DINO || PSERIES)
> 
> Should it? What makes the virtio-vga device only
> suitable for those three machines?

It simply keeps the status quo from before the patchset.

The specific emulation targets that virtio-vga should not be enabled for
(regardless of other targets / machine types) are arm/aarch64. IOW, in
the longer term, it's not that virtio-vga is suitable only for PC ||
DINO || PSERIES, but that it's *not* suitable for arm/aarch64.

My original libvirt commit explains it:

https://libvirt.org/git/?p=libvirt.git;a=commit;h=706b5b627719e95a33606c463bc83c841c7b5b0e


Regarding the guest firmware: in edk2 there are two relevant drivers,
QemuVideoDxe and VirtioGpuDxe. The former is framebuffer-based, the
latter is a genuine virtio drier (no framebuffer). The former doesn't
work on arm/aarch64 KVM, the latter does.

The "virtio-vga" device presents a conflict for these drivers because it
could be bound by both drivers, at the same time. (The device presents
both interfaces.) Arbitration between UEFI drivers is very tricky. To
keep things platform independent and sane in both drivers, VirtioGpuDxe
never binds virtio-vga, only virtio-gpu-pci. Therefore, in OVMF, where
both drivers are included, virtio-vga is deterministically bound by
QemuVideoDxe, a framebuffer is exposed, and Windows is happy. You can
still use virtio-gpu-pci, and that will be bound by VirtioGpuDxe
(windows won't be happy, but you asked for it).

Whereas in ArmVirtQemu, only VirtioGpuDxe is included, as QemuVideoDxe
has no chance of working (on KVM). If you then boot with virtio-vga,
VirtioGpuDxe will still yield... but there won't be another driver to
bind the device instead. So, there you *must* use virtio-gpu-pci, for
VirtioGpuDxe to like the device.

Again, the goal is to keep VirtioGpuDxe and QemuVideoDxe
platform-independent; i.e. refrain from aarch64-specific and
x64-specific quirks in either. They bind or yield purely based on the
device model they see.

So, if you allow libvirt to see virtio-vga on aarch64, it will pick
virtio-vga for the guest, and then VirtioGpuDxe will not bind it, and
there's nothing else to bind it.

Thanks,
Laszlo



Re: [Qemu-devel] [PATCH RFC v4 02/12] target/rx: TCG helper

2019-03-21 Thread Richard Henderson
On 3/20/19 7:16 AM, Yoshinori Sato wrote:
> +void rx_cpu_unpack_psw(CPURXState *env, int all)
> +{
> +if (env->psw_pm == 0) {
> +env->psw_ipl = extract32(env->psw, PSW_IPL, 4);
> +if (all) {
> +env->psw_pm = extract32(env->psw, PSW_PM, 1);
> +}
> +env->psw_u =  extract32(env->psw, PSW_U, 1);
> +env->psw_i =  extract32(env->psw, PSW_I, 1);
> +}
> +env->psw_o = extract32(env->psw, PSW_O, 1) << 31;
> +env->psw_s = extract32(env->psw, PSW_S, 1) << 31;
> +env->psw_z = extract32(env->psw, PSW_Z, 1) ? 0 : 1;
> +env->psw_c = extract32(env->psw, PSW_C, 1);
> +}

I think this function should take the psw value to extract as an argument.
Otherwise, if psw_pm == 1, you're leaving garbage values in env->psw, and I
think that can be confusing.

In fact, since pack_psw does not read env->psw at all, I would remove that
variable.

> +uint32_t helper_mvfc(CPURXState *env, uint32_t cr)
> +{
> +switch (cr) {
> +case 0:
> +return pack_psw(env);
> +case 2:
> +return env->psw_u ? env->regs[0] : env->usp;
> +case 3:
> +return env->fpsw;
> +case 8:
> +return env->bpsw;
> +case 9:
> +return env->bpc;
> +case 10:
> +return env->psw_u ? env->isp : env->regs[0];
> +case 11:
> +return env->fintv;
> +case 12:
> +return env->intb;
> +default:
> +g_assert_not_reached();
> +return -1;

This should only assert if it is caught in translate.c and rejected as an
invalid instruction.  I don't see that happening though.

I think the best option is to move all of this into translate.c.  You have
defined tcg temporaries for (almost) all of these, although many are currently
unused. It's easy to handle any without tcg temporaries with

  tcg_gen_ld_i32(tmp, cpu_env, offsetof(CPURXState, field));

At which point your default case can simply return false to signal an illegal
instruction.

I now see that PC is a control register number 1, not handled here, and that
"MVFC PC, rN" should use ctx->pc.


> +void helper_mvtc(CPURXState *env, uint32_t cr, uint32_t val)
> +{
> +switch (cr) {
...
> +default:
> +g_assert_not_reached();
> +}
> +}

Likewise.

> +void helper_unpack_psw(CPURXState *env)
> +{
> +uint32_t prev_u;
> +prev_u = env->psw_u;
> +rx_cpu_unpack_psw(env, 1);
> +if (prev_u != env->psw_u) {
> +if (env->psw_u) {
> +env->isp = env->regs[0];
> +env->regs[0] = env->usp;
> +} else {
> +env->usp = env->regs[0];
> +env->regs[0] = env->isp;
> +}
> +}
> +}

Again, I think this should take the full psw as an argument.

> +/* fp operations */
> +static void update_fpsw(CPURXState *env, float32 ret, uintptr_t retaddr)
> +{
> +int xcpt, cause, enable;
> +
> +env->psw_z = (*((uint32_t *)) == 0); \
> +env->psw_s = (*((uint32_t *)) >= 0x8000UL); \

(1) You do not need this casting, float32 == uint32_t,
(2) The result is wrong for -0.0.

env->psw_s = ret;   /* sign in bit 31 */
env->psw_z = ret & 0x7fff;  /* remove sign from -0.0 */

> +xcpt = get_float_exception_flags(>fp_status);
> +
> +/* Clear the cause entries */
> +env->fpsw = deposit32(env->fpsw, FPSW_CAUSE, 5, 0);
> +
> +if (unlikely(xcpt)) {
> +if (xcpt & float_flag_invalid) {
> +env->fpsw = deposit32(env->fpsw, FPSW_CAUSE_V, 1, 1);
> +env->fpsw = deposit32(env->fpsw, FPSW_FLAG_V, 1, 1);
> +}
> +if (xcpt & float_flag_divbyzero) {
> +env->fpsw = deposit32(env->fpsw, FPSW_CAUSE_Z, 1, 1);
> +env->fpsw = deposit32(env->fpsw, FPSW_FLAG_Z, 1, 1);
> +}
> +if (xcpt & float_flag_overflow) {
> +env->fpsw = deposit32(env->fpsw, FPSW_CAUSE_O, 1, 1);
> +env->fpsw = deposit32(env->fpsw, FPSW_FLAG_O, 1, 1);
> +}
> +if (xcpt & float_flag_underflow) {
> +env->fpsw = deposit32(env->fpsw, FPSW_CAUSE_U, 1, 1);
> +env->fpsw = deposit32(env->fpsw, FPSW_FLAG_U, 1, 1);
> +}
> +if (xcpt & float_flag_inexact) {
> +env->fpsw = deposit32(env->fpsw, FPSW_CAUSE_X, 1, 1);
> +env->fpsw = deposit32(env->fpsw, FPSW_FLAG_X, 1, 1);
> +}

What I don't see here is the "unimplemented processing" exception that you get
for denormal inputs or outputs, and DN = 0.

There is support for this in softfloat, although it looks funny.
You must always have

  set_flush_to_zero(1, >fp_status);
  set_flush_inputs_to_zero(1, >fp_status);

Do this during reset, I think.

This enables within softfloat the float_flag_{input,output}_denormal bits.
Here in update_fpsw you would do

if ((xcpt & (float_flag_input_denormal
 | float_flag_output_denormal))
&& !(env->fpsw & FPSW_DN)) {
env->fpsw = deposit32(env->fpsw, FPSW_CAUSE_E, 1, 1);
}

> +/* Generate an 

Re: [Qemu-devel] [PATCH] .travis.yml: reduce number of targets built while disabling things

2019-03-21 Thread Wainer dos Santos Moschetta




On 03/21/2019 09:48 AM, Alex Bennée wrote:

This build keeps timing out on Travis and it's unlikely including the
additional guest front-ends will catch any failures in the fallback
code.

Signed-off-by: Alex Bennée 
---
  .travis.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Wainer dos Santos Moschetta 



diff --git a/.travis.yml b/.travis.yml
index 3fb3dab46e..2e06aee9d0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -107,7 +107,7 @@ matrix:
  
  
  - env:

-- CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr 
--disable-brlapi --disable-libusb --disable-user --disable-replication"
+- CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr 
--disable-brlapi --disable-libusb --disable-replication 
--target-list=${MAIN_SOFTMMU_TARGETS}"
  
  
  # Module builds are mostly of interest to major distros





Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Laszlo Ersek
On 03/21/19 17:55, Laszlo Ersek wrote:
> On 03/21/19 12:52, Peter Maydell wrote:
>> On Thu, 21 Mar 2019 at 11:34, Laszlo Ersek  wrote:
>>>
>>> Repo:   https://github.com/lersek/qemu.git
>>> Branch: edk2_build_v3
>>>
>>> Version 2, that is:
>>>
>>>   [Qemu-devel] [PATCH v2 00/12] bundle edk2 platform firmware with QEMU
>>>
>>> was posted at:
>>>
>>>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04670.html
>>>   20190313210057.32584-1-lersek@redhat.com">http://mid.mail-archive.com/20190313210057.32584-1-lersek@redhat.com
>>>
>>> Updates in v3 are noted on each patch individually, in the Notes
>>> section. In summary,
>>>
>>> - I've picked up feedback tags from the v2 thread (see above),
>>>
>>> - I've replaced the xz compression with bz2 compression according to the
>>>   subthread
>>>
>>> Re: [Qemu-devel] [PULL 00/12] EDK2 Firmware roms
>>
>> Thanks. Could you check that this works in the OpenBSD VM test?
>> It should just be a matter of
>>   make -C build vm-build-openbsd
>
> Actually I tried to do that before posting v3, following the
> instructions in "docs/devel/testing.rst":
>
>   cd $QEMU_SRC/tests/vm
>   ./openbsd --build-image --image /mnt/data/tmp/openbsd.img
>   ./openbsd --debug --image /mnt/data/tmp/openbsd.img \
> --build-qemu $QEMU_SRC
>
> The first "openbsd" invocation succeeded, but the second failed, with a
> complaint about some (cross?)compiler missing.
>
> Anyway I'll now retry with the make command you specify above.

Unfortunately, I got the exact same setup error:

> make: Entering directory `.../tmp/qemu-build-opt.d'
> VM-IMAGE openbsd
> --2019-03-21 18:14:46--  http://download.patchew.org/openbsd-6.1-amd64.img.xz
> Resolving download.patchew.org (download.patchew.org)... 140.211.15.4
> Connecting to download.patchew.org (download.patchew.org)|140.211.15.4|:80... 
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 675094624 (644M) [application/octet-stream]
> Saving to: 
> '.../.cache/qemu-vm/download/bc4733f6c6e76931702528a515a1bf70eb8baecd.download'
>
> 100%[=>]
>  675,094,624 12.0MB/s   in 53s
>
> 2019-03-21 18:15:40 (12.1 MB/s) - 
> '.../.cache/qemu-vm/download/bc4733f6c6e76931702528a515a1bf70eb8baecd.download'
>  saved [675094624/675094624]
>
> Extracting the image...
> .../.cache/qemu-vm/images/openbsd.img.tmp.xz (1/1)
>   100 %643.8 MiB / 32.0 GiB = 0.020   253 MiB/s   2:09
> VM-BUILD openbsd
> Cloning into 
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot'...
> done.
> Checking out files: 100% (6748/6748), done.
> Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc'
> Cloning into 
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/dtc'...
> Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) 
> registered for path 'ui/keycodemapdb'
> Cloning into 
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/ui/keycodemapdb'...
> Submodule 'tests/fp/berkeley-softfloat-3' 
> (https://github.com/cota/berkeley-softfloat-3) registered for path 
> 'tests/fp/berkeley-softfloat-3'
> Cloning into 
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/tests/fp/berkeley-softfloat-3'...
> Submodule 'tests/fp/berkeley-testfloat-3' 
> (https://github.com/cota/berkeley-testfloat-3) registered for path 
> 'tests/fp/berkeley-testfloat-3'
> Cloning into 
> '.../tmp/qemu-build-opt.d/vm-test-N8zknt.tmp/data-35ed0.tar.vroot/tests/fp/berkeley-testfloat-3'...
>
> ERROR: "x86_64-unknown-openbsd6.1-gcc-4.9.4" either does not exist or does 
> not work
>
> make: *** [vm-build-openbsd] Error 3
> make: Leaving directory `.../tmp/qemu-build-opt.d'

Thanks,
Laszlo



Re: [Qemu-devel] [PATCH v3 6/8] slirp: clarify license of slirp files using SPDX

2019-03-21 Thread Thomas Huth
On 14/03/2019 14.10, Marc-André Lureau wrote:
> Add SPDX license identifier to clarify the license of files without
> explicit license header.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  slirp/src/bootp.h  | 1 +
>  slirp/src/ip6.h| 1 +
>  slirp/src/ip6_icmp.h   | 1 +
>  slirp/src/libslirp.h   | 1 +
>  slirp/src/slirp.h  | 1 +
>  slirp/src/stream.h | 1 +
>  slirp/src/tftp.h   | 1 +
>  slirp/src/ip6_icmp.c   | 1 +
>  slirp/src/ip6_input.c  | 1 +
>  slirp/src/ip6_output.c | 1 +
>  slirp/src/ndp_table.c  | 1 +
>  slirp/src/udp6.c   | 1 +
>  12 files changed, 12 insertions(+)

Reviewed-by: Thomas Huth 



Re: [Qemu-devel] [PATCH v3 5/8] slirp: clarify license of slirp files using SPDX

2019-03-21 Thread Thomas Huth
On 14/03/2019 14.10, Marc-André Lureau wrote:
> Add SPDX license identifier to clarify the license of files with
> reference to BSD license from slirp COPYRIGHT file.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  slirp/src/debug.h  | 1 +
>  slirp/src/if.h | 1 +
>  slirp/src/main.h   | 1 +
>  slirp/src/misc.h   | 1 +
>  slirp/src/sbuf.h   | 1 +
>  slirp/src/socket.h | 1 +
>  slirp/src/if.c | 1 +
>  slirp/src/mbuf.c   | 1 +
>  slirp/src/misc.c   | 1 +
>  slirp/src/sbuf.c   | 1 +
>  slirp/src/socket.c | 1 +
>  11 files changed, 11 insertions(+)

Reviewed-by: Thomas Huth 



Re: [Qemu-devel] [PATCH] virtio-vga: only enable for specific boards

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 14:41, Paolo Bonzini  wrote:
>
> When virtio-vga was added, the intention was to only support it for
> those machines where the firmware does not know about virtio-gpu,
> and supported VGA legacy hardware before virtio-{gpu,vga} were
> introduced.
>
> The Kconfig switch however enabled virtio-vga for all machines with
> a PCI bus, and libvirt then prefers it even on hardware where
> virtio-gpu would be preferrable.  At least for now, only enable
> virtio-vga for PC, hppa and pSeries machines, as was the case
> before Kconfig dependencies were introduced.

Do we have a reference to a bug report against libvirt for this?

> Reported-by: Laszlo Ersek 
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/display/Kconfig | 2 +-
>  hw/hppa/Kconfig| 1 +
>  hw/i386/Kconfig| 1 +
>  hw/ppc/Kconfig | 1 +
>  4 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/display/Kconfig b/hw/display/Kconfig
> index 86c1d544c5..72be57a403 100644
> --- a/hw/display/Kconfig
> +++ b/hw/display/Kconfig
> @@ -100,7 +100,7 @@ config VIRTIO_GPU
>
>  config VIRTIO_VGA
>  bool
> -default y if PCI_DEVICES
> +# defaults to "N", enabled by specific boards
>  depends on VIRTIO_PCI
>  select VGA

Could we have a comment that says what the criterion for
a board needing to enable it is, so that if we add new
boards in future we know whether they need to enable it or not?
(If the answer is "never for any new board", that's useful
to say.)

thanks
-- PMM



Re: [Qemu-devel] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node

2019-03-21 Thread Andrey Shinkevich


On 21/03/2019 13:53, Kevin Wolf wrote:
> Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben:
>> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
 Oh, I see. Let's use a shorter chain for simplicity:

 A <- B <- C <- D <- E
>>>
>>> Written from right to left, i.e. E being the base and A the top layer?
>>> We usually write things the other write round, I hope this doesn't get
>>> too confusing later.
>>
>> Oh my... yes, of course you're right, I should have written it the other
>> way around:
>>
>> E <- D <- C <- B <- A
>>
 1) If we stream first from E to C we add a filter F:

 A <- B <- F <- C <- D <- E
>>
>> ( which should have been written   E <- D <- C <- F <- B <- A )
>>
 Now we can't stream from C to A because F is on the way, and the F-C
 link is frozen.
>>>
>>> Why is a frozen link a problem? The streaming operation isn't going to
>>> change this link, it just copies data from the subchain (including F
>>> and C) to A. This is not something that a frozen link should prevent.
>>
>> Not the operation itself, but the first thing that block-stream does is
>> freeze the chain from top (A) to base (C), so this would fail if there's
>> already a frozen link on the way (C <- F on this case?).
> 
> Oh, I see. I think this is why I suggested a counter originally instead
> of a bool.
> 
>>> So it seems frozen links allow the wrong case, but block the correct
>>> one? :-(
>>
>> Yes, we probably need to rethink this scenario a bit.
> 
> But yes, even with a counter, the other problem would still remain (that
> the first job can't remove the filter on completion because the second
> one has frozen its link to the filter).

With this example E <- D <- C <- F <- B <- A,

In the current implementation of the copy-on-read filter,
its bs->backing is not initialized (while it is not true for the filter
in block-commit job). So, bdrv_freeze_backing_chain() doesn't go beyond 
the cor-filter node. With the two parallel block-stream jobs, we get the
following sub-chains frozen:
F <- B <- A
E <- D <- C
as C <- F backing BdrvChild link doesn't exist.
If the cor-filter is inserted with the bdrv_append(), we get two
BdrvChild links (file and backing) pointed to the same BlockDriverState
'C' and additionally some child-permissions issues that I have not 
resolved yet...
Due to the fact mentioned above, freezing the backing chain works with
the filter inserted. But, with the one BdrvChild *file link only in the
BlockDriverState of the cor-filter, we encounter a broken chain each
time we iterate through it with the backing_bs(F) (=NULL) in many other
pieces of the code. In turn, it breaks the existing model.
That's the point! (((
What can we do with that?

In my patch Stream-block-job-involves-copy-on-read-filter.patch :

static BlockDriverState *child_file_bs(BlockDriverState *bs)
{
 return bs->file ? bs->file->bs : NULL;
}

static BlockDriverState *skip_filter(BlockDriverState *bs)
{
 BlockDriverState *ret_bs = bs;

 while (ret_bs && ret_bs->drv && ret_bs->drv->is_filter) {
 ret_bs = child_file_bs(ret_bs);
 }

 return ret_bs;
}

But the solution above looks clumsy to me.
I would appreciate to hear any other ideas from you.

Andrey

> 
> I don't think that's a case we want to just forbid because nobody needs
> this anyway. It's a sign of a more fundamental problem in our design,
> and I'm sure it will bite us in other places, too.
> 
> Kevin
> 


Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 16:55, Laszlo Ersek  wrote:
> On 03/21/19 12:52, Peter Maydell wrote:
> > Thanks. Could you check that this works in the OpenBSD VM test?
> > It should just be a matter of
> >   make -C build vm-build-openbsd
>
> Actually I tried to do that before posting v3, following the
> instructions in "docs/devel/testing.rst":
>
>   cd $QEMU_SRC/tests/vm
>   ./openbsd --build-image --image /mnt/data/tmp/openbsd.img
>   ./openbsd --debug --image /mnt/data/tmp/openbsd.img \
> --build-qemu $QEMU_SRC

This is in the "manual invocation" subsection of the docs.
You want the "quickstart" subsection which has the same
'make vm-build-whatever' command I suggest.

> Aha! So first I guess I should run at least configure, for setting up an
> out-of-tree build, and then try the "make" command.

You need to configure, yes. I think it should work on an in-tree
build, but I've never tried it as I never use in-tree builds.
(We're probably going to get rid of in-tree build support in 4.1.)

thanks
-- PMM



Re: [Qemu-devel] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node

2019-03-21 Thread Andrey Shinkevich


On 21/03/2019 14:53, Vladimir Sementsov-Ogievskiy wrote:
> 21.03.2019 13:53, Kevin Wolf wrote:
>> Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben:
>>> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
> Oh, I see. Let's use a shorter chain for simplicity:
>
>  A <- B <- C <- D <- E

 Written from right to left, i.e. E being the base and A the top layer?
 We usually write things the other write round, I hope this doesn't get
 too confusing later.
>>>
>>> Oh my... yes, of course you're right, I should have written it the other
>>> way around:
>>>
>>>  E <- D <- C <- B <- A
>>>
> 1) If we stream first from E to C we add a filter F:
>
>  A <- B <- F <- C <- D <- E
>>>
>>> ( which should have been written   E <- D <- C <- F <- B <- A )
>>>
>  Now we can't stream from C to A because F is on the way, and the F-C
>  link is frozen.

 Why is a frozen link a problem? The streaming operation isn't going to
 change this link, it just copies data from the subchain (including F
 and C) to A. This is not something that a frozen link should prevent.
>>>
>>> Not the operation itself, but the first thing that block-stream does is
>>> freeze the chain from top (A) to base (C), so this would fail if there's
>>> already a frozen link on the way (C <- F on this case?).
>>
>> Oh, I see. I think this is why I suggested a counter originally instead
>> of a bool.
>>
 So it seems frozen links allow the wrong case, but block the correct
 one? :-(
>>>
>>> Yes, we probably need to rethink this scenario a bit.
>>
>> But yes, even with a counter, the other problem would still remain (that
>> the first job can't remove the filter on completion because the second
>> one has frozen its link to the filter).
>>
>> I don't think that's a case we want to just forbid because nobody needs
>> this anyway. It's a sign of a more fundamental problem in our design,
>> and I'm sure it will bite us in other places, too.
>>
>> Kevin
>>
> 
> Does it mean that we now have problems with other jobs which already has
> filter if use them in parallel with stream?
> 

In the current implementation of the iotests, only the
TestParallelOps::test_stream_parallel() in the #030
detects the issue.

Andrey


[Qemu-devel] [PATCH 2/2] trace: avoid SystemTap dtrace(1) warnings on empty files

2019-03-21 Thread Stefan Hajnoczi
target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}".  SystemTap's
dtrace(1) tool prints a warning when processing this input file.

This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there are no enabled trace events.

Fixes: 23c3d569f44284066714ff7c46bc4f19e630583f ("target/hppa: add TLB trace 
events")
Reported-by: Markus Armbruster 
Signed-off-by: Stefan Hajnoczi 
---
 scripts/tracetool/format/d.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/tracetool/format/d.py b/scripts/tracetool/format/d.py
index 78397c24d2..c7cb2a93a6 100644
--- a/scripts/tracetool/format/d.py
+++ b/scripts/tracetool/format/d.py
@@ -33,6 +33,11 @@ def generate(events, backend, group):
 events = [e for e in events
   if "disable" not in e.properties]
 
+# SystemTap's dtrace(1) warns about empty "provider qemu {}" but is happy
+# with an empty file.  Avoid the warning.
+if not events:
+return
+
 out('/* This file is autogenerated by tracetool, do not edit. */'
 '',
 'provider qemu {')
-- 
2.20.1




[Qemu-devel] [PATCH 0/2] trace: fix compilation issues for QEMU 4.0.0

2019-03-21 Thread Stefan Hajnoczi
These patches fix compilation issues spotted by Markus Armbruster
.  See the patches for details.

Stefan Hajnoczi (2):
  trace: handle tracefs path truncation
  trace: avoid SystemTap dtrace(1) warnings on empty files

 trace/ftrace.c| 12 ++--
 scripts/tracetool/format/d.py |  5 +
 2 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.20.1




[Qemu-devel] [PATCH 1/2] trace: handle tracefs path truncation

2019-03-21 Thread Stefan Hajnoczi
If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.

This issue does not occur on real-world systems since tracefs is mounted
on /sys/kernel/debug/tracing/, but the compiler is smart enough to
foresee the possibility and warn about the unchecked snprintf(3) return
value.  This patch fixes the compiler warning.

Reported-by: Markus Armbruster 
Signed-off-by: Stefan Hajnoczi 
---
 trace/ftrace.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/trace/ftrace.c b/trace/ftrace.c
index 61692a8682..9749543d9b 100644
--- a/trace/ftrace.c
+++ b/trace/ftrace.c
@@ -53,7 +53,11 @@ bool ftrace_init(void)
 }
 
 if (tracefs_found) {
-snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir);
+if (snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir)
+>= sizeof(path)) {
+fprintf(stderr, "Using tracefs mountpoint would exceed 
PATH_MAX\n");
+return false;
+}
 trace_fd = open(path, O_WRONLY);
 if (trace_fd < 0) {
 if (errno == EACCES) {
@@ -72,7 +76,11 @@ bool ftrace_init(void)
 }
 close(trace_fd);
 }
-snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir);
+if (snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir)
+>= sizeof(path)) {
+fprintf(stderr, "Using tracefs mountpoint would exceed 
PATH_MAX\n");
+return false;
+}
 trace_marker_fd = open(path, O_WRONLY);
 if (trace_marker_fd < 0) {
 perror("Could not open ftrace 'trace_marker' file");
-- 
2.20.1




  1   2   3   >