Re: [PATCH 1/2 v3] Configure script for Haiku

2021-07-05 Thread Thomas Huth

On 05/07/2021 21.21, Richard Zak wrote:
The configure script doesn't test for presence of TPM device or support. It 
activates TPM support if not explicitly disabled, and disables TPM support 
if explicitly enabled on Windows. With TPM support compiled in, it causes an 
assertion failure on launch of qemu at util/async.c:669 
qemu_set_current_aio_context() !my_aiocontext. I haven't yet figured out why 
though, but disabling TPM might be best, and there's precedent for it as 
it's disabled if compiling for Windows.


Ok, then please add this information (about the assertion failure) to the 
patch description. And please handle the tpm disablement for Haiku in the 
same spot as the disablement for Windows, so that people still get a sane 
error message in case they try to configure with --enable-tpm on Haiku.


 Thanks,
  Thomas


În dum., 4 iul. 2021 la 14:29, Richard Zak > a scris:



În dum., 4 iul. 2021 la 13:11, Peter Maydell mailto:peter.mayd...@linaro.org>> a scris:

On Sun, 4 Jul 2021 at 17:44, Richard Zak mailto:richard.j@gmail.com>> wrote:
 >
 > Use system capstone, for which a port is maintained by Haiku.
Disable TPM which isn't supported.
 >
 > Signed-off-by: Richard Zak mailto:richard.j@gmail.com>>
 > ---
 >  configure | 3 +++
 >  1 file changed, 3 insertions(+)
 >
 > diff --git a/configure b/configure
 > index e799d908a3..c928071f69 100755
 > --- a/configure
 > +++ b/configure
 > @@ -358,6 +358,7 @@ oss_lib=""
 >  bsd="no"
 >  linux="no"
 >  solaris="no"
 > +haiku="no"
 >  profiler="no"
 >  cocoa="auto"
 >  softmmu="yes"
 > @@ -769,6 +770,8 @@ SunOS)
 >  ;;
 >  Haiku)
 >    haiku="yes"
 > +  tpm="no"

If the autodetect for tpm doesn't get this right, we should fix
the autodetect.

As a general principle we prefer to avoid "do this specific thing
for this specific host OS" whenever we can, in favour of "test
whether we have whatever feature/function/library is required".

thanks
-- PMM


Totally makes sense, and I'll be mindful of that. In this case, the
configure script is enabling TPM support on Haiku, but I don't think it
breaks anything, but I haven't tested it yet.

-- 
Regards,


Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc 



--
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc 





Re: [PATCH v3] linux-user/elfload: Implement ELF_HWCAP for RISC-V

2021-07-05 Thread Bin Meng
On Tue, Jul 6, 2021 at 11:50 AM Kito Cheng  wrote:
>
> Set I, M, A, F, D and C bit for hwcap if misa is set.
>
> V3 Changes:
> - Simplify logic of getting hwcap.
>
> V2 Changes:
> - Only set imafdc bits, sync with upstream linux kernel.

These changelogs should not be in the commit message, but should be
put below ---

>
> Signed-off-by: Kito Cheng 
> ---
>  linux-user/elfload.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index 598ab8aa13..42ef2a1148 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -1434,6 +1434,19 @@ static void elf_core_copy_regs(target_elf_gregset_t 
> *regs,
>  #define ELF_CLASS ELFCLASS64
>  #endif
>
> +#define ELF_HWCAP get_elf_hwcap()
> +
> +static uint32_t get_elf_hwcap(void)
> +{
> +#define MISA_BIT(EXT) (1 << (EXT - 'A'))
> +RISCVCPU *cpu = RISCV_CPU(thread_cpu);
> +uint32_t mask = MISA_BIT('I') | MISA_BIT('M') | MISA_BIT('A')
> +| MISA_BIT('F') | MISA_BIT('D') | MISA_BIT('C');
> +
> +return cpu->env.misa & mask;
> +#undef MISA_BIT
> +}
> +
>  static inline void init_thread(struct target_pt_regs *regs,
> struct image_info *infop)
>  {

Regards,
Bin



[PATCH] target/ppc: mtmsrd is an illegal instruction on BookE

2021-07-05 Thread Nicholas Piggin
MSR is a 32-bit register in BookE and there is no mtmsrd instruction.

Cc: Christian Zigotzky 
Signed-off-by: Nicholas Piggin 
---
 target/ppc/translate.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index f65d1e81ea..d1f482b0f3 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -4940,6 +4940,11 @@ static void gen_mtcrf(DisasContext *ctx)
 #if defined(TARGET_PPC64)
 static void gen_mtmsrd(DisasContext *ctx)
 {
+if (unlikely(!is_book3s_arch2x(ctx))) {
+gen_invalid(ctx);
+return;
+}
+
 CHK_SV;
 
 #if !defined(CONFIG_USER_ONLY)
-- 
2.23.0




Re: [PATCH v3] linux-user/elfload: Implement ELF_HWCAP for RISC-V

2021-07-05 Thread Richard Henderson

On 7/5/21 8:50 PM, Kito Cheng wrote:

Set I, M, A, F, D and C bit for hwcap if misa is set.

V3 Changes:
- Simplify logic of getting hwcap.

V2 Changes:
- Only set imafdc bits, sync with upstream linux kernel.

Signed-off-by: Kito Cheng
---
  linux-user/elfload.c | 13 +
  1 file changed, 13 insertions(+)


Reviewed-by: Richard Henderson 

r~



[PATCH 1/2] roms/u-boot: Bump ppce500 u-boot to v2021.07 to add eTSEC support

2021-07-05 Thread Bin Meng
Update the QEMU shipped u-boot.e500 image built from U-Boot mainline
v2021.07 release, which added eTSEC support to the QEMU ppce500 target,
via the following U-Boot series:

  http://patchwork.ozlabs.org/project/uboot/list/?series=233875&state=*

The cross-compilation toolchain used to build the U-Boot image is:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/10.1.0/x86_64-gcc-10.1.0-nolibc-powerpc-linux.tar.xz

Signed-off-by: Bin Meng 
---

Please pull the full contents (the u-boot.e500 binary) from
https://github.com/lbmeng/qemu, branch qemu-ppc.

 pc-bios/u-boot.e500 | Bin 406920 -> 421720 bytes
 roms/u-boot |   2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/pc-bios/u-boot.e500 b/pc-bios/u-boot.e500
index d2e29f81d6..8e635c8a5c 100644
Binary files a/pc-bios/u-boot.e500 and b/pc-bios/u-boot.e500 differ
diff --git a/roms/u-boot b/roms/u-boot
index b46dd116ce..840658b093 16
--- a/roms/u-boot
+++ b/roms/u-boot
@@ -1 +1 @@
-Subproject commit b46dd116ce03e235f2a7d4843c6278e1da44b5e1
+Subproject commit 840658b093976390e9537724f802281c9c8439f5
-- 
2.25.1




[PATCH 2/2] docs/system: ppc: Update ppce500 documentation with eTSEC support

2021-07-05 Thread Bin Meng
This adds eTSEC support to the PowerPC `ppce500` machine documentation.

Signed-off-by: Bin Meng 
---

 docs/system/ppc/ppce500.rst | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst
index 7a815c1881..afc58f60f5 100644
--- a/docs/system/ppc/ppce500.rst
+++ b/docs/system/ppc/ppce500.rst
@@ -19,6 +19,7 @@ The ``ppce500`` machine supports the following devices:
 * Power-off functionality via one GPIO pin
 * 1 Freescale MPC8xxx PCI host controller
 * VirtIO devices via PCI bus
+* 1 Freescale Enhanced Triple Speed Ethernet controller (eTSEC)
 
 Hardware configuration information
 --
@@ -121,7 +122,7 @@ To boot the 32-bit Linux kernel:
 Running U-Boot
 --
 
-U-Boot mainline v2021.04 release is tested at the time of writing. To build a
+U-Boot mainline v2021.07 release is tested at the time of writing. To build a
 U-Boot mainline bootloader that can be booted by the ``ppce500`` machine, use
 the qemu-ppce500_defconfig with similar commands as described above for Linux:
 
@@ -154,3 +155,10 @@ interface at PCI address 0.1.0, but we can switch that to 
an e1000 NIC by:
 -display none -serial stdio \
 -bios u-boot \
 -nic tap,ifname=tap0,script=no,downscript=no,model=e1000
+
+The QEMU ``ppce500`` machine can also dynamically instantiate an eTSEC device
+if “-device eTSEC” is given to QEMU:
+
+.. code-block:: bash
+
+  -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device 
eTSEC,netdev=net0
-- 
2.25.1




Re: [PATCH v1 3/3] hw/riscv: opentitan: Add the flash alias

2021-07-05 Thread Alistair Francis
On Mon, Jul 5, 2021 at 4:16 PM Bin Meng  wrote:
>
> On Fri, Jul 2, 2021 at 1:20 PM Alistair Francis
>  wrote:
>
> Could you add some commit message to explain this alias?

Yep, I'll add something.

>
> >
> > Signed-off-by: Alistair Francis 
> > ---
> >  include/hw/riscv/opentitan.h | 2 ++
> >  hw/riscv/opentitan.c | 6 ++
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/include/hw/riscv/opentitan.h b/include/hw/riscv/opentitan.h
> > index a488f5e8ec..9f93bebdac 100644
> > --- a/include/hw/riscv/opentitan.h
> > +++ b/include/hw/riscv/opentitan.h
> > @@ -40,6 +40,7 @@ struct LowRISCIbexSoCState {
> >
> >  MemoryRegion flash_mem;
> >  MemoryRegion rom;
> > +MemoryRegion flash_alias;
> >  };
> >
> >  typedef struct OpenTitanState {
> > @@ -54,6 +55,7 @@ enum {
> >  IBEX_DEV_ROM,
> >  IBEX_DEV_RAM,
> >  IBEX_DEV_FLASH,
> > +IBEX_DEV_FLASH_VIRTUAL,
>
> Is this virtual address? But it is still physical?

It's a physical address (OpenTitan has no MMU so all addresses are physical).

There is an alias region to access the flash region, so the region can
be accessed either by it's "real" address or this "virtual" address
range. It's similar to some other MCUs, like the STM range.

The virtual is just the name that they call it.

Alistair

>
> >  IBEX_DEV_UART,
> >  IBEX_DEV_GPIO,
> >  IBEX_DEV_SPI,
> > diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
> > index 933c211b11..36a41c8b5b 100644
> > --- a/hw/riscv/opentitan.c
> > +++ b/hw/riscv/opentitan.c
> > @@ -59,6 +59,7 @@ static const MemMapEntry ibex_memmap[] = {
> >  [IBEX_DEV_NMI_GEN] ={  0x411c,  0x1000  },
> >  [IBEX_DEV_OTBN] =   {  0x411d,  0x1 },
> >  [IBEX_DEV_PERI] =   {  0x411f,  0x1 },
> > +[IBEX_DEV_FLASH_VIRTUAL] =  {  0x8000,  0x8 },
> >  };
> >
> >  static void opentitan_board_init(MachineState *machine)
> > @@ -134,8 +135,13 @@ static void lowrisc_ibex_soc_realize(DeviceState 
> > *dev_soc, Error **errp)
> >  /* Flash memory */
> >  memory_region_init_rom(&s->flash_mem, OBJECT(dev_soc), 
> > "riscv.lowrisc.ibex.flash",
> > memmap[IBEX_DEV_FLASH].size, &error_fatal);
> > +memory_region_init_alias(&s->flash_alias, OBJECT(dev_soc),
> > + "riscv.lowrisc.ibex.flash_virtual", 
> > &s->flash_mem, 0,
> > + memmap[IBEX_DEV_FLASH_VIRTUAL].size);
> >  memory_region_add_subregion(sys_mem, memmap[IBEX_DEV_FLASH].base,
> >  &s->flash_mem);
> > +memory_region_add_subregion(sys_mem, 
> > memmap[IBEX_DEV_FLASH_VIRTUAL].base,
> > +&s->flash_alias);
> >
> >  /* PLIC */
> >  if (!sysbus_realize(SYS_BUS_DEVICE(&s->plic), errp)) {
> > --
>
> Regards,
> Bin



[Bug 1863601] Re: unable to type "|" character in french keyboard.

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  unable to type "|" character in french keyboard.

Status in QEMU:
  Expired

Bug description:
  Unable to type "|" character when using french keyboard. It is
  displaying "<" instead of "|" while pressing AltGr+6 from my keyboard.

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



Re: [PATCH v2 2/6] tests/acceptance: add replay kernel test for ppc64

2021-07-05 Thread Pavel Dovgalyuk

On 05.07.2021 20:46, Willian Rampazzo wrote:

Already upstream :)


Ok, thanks.



On Fri, Jun 25, 2021 at 2:39 AM Pavel Dovgalyuk
 wrote:


This patch adds record/replay test which boots Linux
kernel on ppc64 platform. The test uses kernel binaries
taken from boot_linux_console test.

Signed-off-by: Pavel Dovgalyuk 
---
  tests/acceptance/replay_kernel.py |   13 +
  1 file changed, 13 insertions(+)

diff --git a/tests/acceptance/replay_kernel.py 
b/tests/acceptance/replay_kernel.py
index cdc22cb6d3..7e7f4c8ccc 100644
--- a/tests/acceptance/replay_kernel.py
+++ b/tests/acceptance/replay_kernel.py
@@ -367,6 +367,19 @@ def test_xtensa_lx60(self):
  self.do_test_advcal_2018(file_path, 'santas-sleigh-ride.elf',
   args=('-cpu', 'dc233c'))

+def test_ppc64_e500(self):
+"""
+:avocado: tags=arch:ppc64
+:avocado: tags=machine:ppce500
+:avocado: tags=cpu:e5500
+"""
+tar_hash = '6951d86d644b302898da2fd701739c9406527fe1'
+tar_url = ('https://www.qemu-advent-calendar.org'
+   '/2018/download/day19.tar.xz')
+file_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
+self.do_test_advcal_2018(file_path, 'uImage', ('-cpu', 'e5500'))
+
+
  @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
  class ReplayKernelSlow(ReplayKernelBase):
  # Override the timeout, because this kernel includes an inner








[Bug 1865626] Re: s390x guest hang when ipl boot from a mdev dasd

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  s390x guest hang when ipl boot from a mdev dasd

Status in QEMU:
  Expired

Bug description:
  qemu latest
  kernel 5.3.18

  I am using a passthrough dasd as boot device, the installment looks
  fine and gets into reboot process. However VM could not boot and just
  hang as below after that. I have been checking on "s390: vfio-ccw dasd
  ipl support" series right now but no clue yet. Could anyone take a
  look for it? Thanks.


  s390vsw188:~ # bash test.sh
  LOADPARM=[]
  executing ccw chain at : 0x0018
  executing ccw chain at : 0xe000

  2020-03-01T06:24:56.879314Z qemu-system-s390x: warning: vfio-ccw
  (devno fe.0.): PFCH flag forced


  s390zp12:~ # cat test.sh
  /root/qemu/s390x-softmmu/qemu-system-s390x \
  -machine s390-ccw-virtio,accel=kvm \
  -nographic \
  -bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \
  -device 
vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,,devno=fe.0.,bootindex=1
 \
  -global vfio-ccw.force-orb-pfch=yes \

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



[Bug 1865348] Re: virsh domfsinfo testdom crashes the guest agent

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  virsh domfsinfo testdom crashes the guest agent

Status in QEMU:
  Expired

Bug description:

  [@ ~]# virsh qemu-agent-command vps-01 '{"execute":"guest-get-
  fsinfo"}'

  
  error: Guest agent is not responding: Guest agent disappeared while executing 
command

  [@ ~]# virsh domfsinfo vps-01
  error: Unable to get filesystem information
  error: Guest agent is not responding: Guest agent disappeared while executing 
command

  
  Fault bucket , type 0
  Event Name: APPCRASH
  Response: Not available
  Cab Id: 0

  Problem signature:
  P1: qemu-ga.exe
  P2: 100.0.0.0
  P3: 5c473543
  P4: KERNELBASE.dll
  P5: 6.1.7601.24545
  P6: 5e0eb6bd
  P7: c005
  P8: c4d2
  P9: 
  P10: 

  Attached files:

  These files may be available here:
  
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_qemu-ga.exe_bd2e6535bdb93328680e0285e89e08f2866db83_49df29e2

  Analysis symbol: 
  Rechecking for solution: 0
  Report Id: 2ad29522-5bcc-11ea-bca6-525400e83365
  Report Status: 0

  
  guest os: windows server std 2008r2

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



[Bug 1864536] Re: Support for XSAVES intel instructions in QEMU

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Support for XSAVES intel instructions in QEMU

Status in QEMU:
  Expired

Bug description:
  Dear QEMU developers,

  I am running Hyper-V on qemu+kvm. During it initialization, it checks
  for XSAVES support: first it executes CPUID with EAX = 0xd and ECX = 1
  and looks at bit 3 in the returned value of EAX (Supports
  XSAVES/XRSTORS and IA32_XSS [1]), and then it reads the MSR
  IA32_VMX_PROCBASED_CTLS2 (index 0x48B) and looks at bit 20 (Enable
  XSAVES/XSTORS [2]). If CPUID shows that XSAVES is supported and the
  bit is not enabled in the MSR, Hyper-V decides to fail and stops its
  initialization. It used to work until last spring/summer where
  something might have changed in either KVM or QEMU.

  It seems that KVM sets the correct flags (in CPUID and the MSR) when the host 
CPU supports XSAVES. In QEMU, based on comments in target/i386/cpu.c it seems 
that XSAVES is not added in
  builtin_x86_defs[].features[FEAT_VMX_SECONDARY_CTLS] because it might break 
live migration. Therefore, when setting the MSR for the vcpu, QEMU is masking 
off the feature.

  I have tested two possible solutions:
  - adding the flag in .features[FEAT_VMX_SECONDARY_CTLS]
  - removing the support of the instruction in 
feature_word_info[FEAT_XSAVE].feat_names

  Both solutions work and Hyper-v is happily running. I can provide a
  patch for the solution you might consider applying. Otherwise, is
  there a better way to fix the issue?

  Qemu version: 4.2.0
  Kernel version: 5.5.4
  Qemu command: 
https://gist.github.com/0xabe-io/b4d797538e2160252addc1d1d64738e2

  
  Many thanks,
  Alexandre

  Ref:
  [1] Intel SDM Volume 2A, chapter 3, page 196
  [2] Intel SDM Volume 3C, chapter 24, page 11

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



[Bug 1867786] Re: Qemu PPC64 freezes with multi-core CPU

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Qemu PPC64 freezes with multi-core CPU

Status in QEMU:
  Expired

Bug description:
  I installed Debian 10 on a Qemu PPC64 VM running with the following
  flags:

  qemu-system-ppc64 \
   -nographic -nodefaults -monitor pty -serial stdio \
   -M pseries -cpu POWER9 -smp cores=4,threads=1 -m 4G \
   -drive file=debian-ppc64el-qemu.qcow2,format=qcow2,if=virtio \
   -netdev user,id=network01,$ports -device rtl8139,netdev=network01 \

  
  Within a couple minutes on any operation (could be a Go application or simply 
changing the hostname with hostnamectl, the VM freezes and prints this on the 
console:

  ```
  root@debian:~# [  950.428255] rcu: INFO: rcu_sched self-detected stall on CPU
  [  950.428453] rcu: 3-: (5318 ticks this GP) 
idle=8e2/1/0x4004 softirq=5957/5960 fqs=2544
  [  976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462]

  Message from syslogd@debian at Mar 17 11:35:24 ...
   kernel:[  976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! 
[zsh:462]
  [  980.110018] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: 
{ 3-... } 5276 jiffies s: 93 root: 0x8/.
  [  980.77] rcu: blocking rcu_node structures:
  [ 1013.442268] rcu: INFO: rcu_sched self-detected stall on CPU
  [ 1013.442365] rcu: 3-: (21071 ticks this GP) 
idle=8e2/1/0x4004 softirq=5957/5960 fqs=9342
  ```

  If I change to 1 core on the command line, I haven't seen these
  freezes.

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



[Bug 1865350] Re: fstrim not working with image mounted to path?

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  fstrim not working with image mounted to path?

Status in QEMU:
  Expired

Bug description:
  
  guest os: windows server standard 2016
  qemu agent version 100.0.0

  os supports trimming
  path mounted image does not support trimming

  C:\Users\Administrator>fsutil behavior query disabledeletenotify
  NTFS DisableDeleteNotify = 0
  ReFS DisableDeleteNotify = 1

  
  [@ ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}'
  {"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program 
Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\\\","error":"The given 
volume path is invalid. (0x8901)"}]}}

  
  Looks like the fstrim does not like/check images mounted on a path? Nor 
detects if image trimming is supported.  is a ReFS mounted image without 
trimming support. 

  If I enable trimming on the ReFS image, and configure it win2016, the
  result is still the same.

  
  C:\Users\Administrator>fsutil behavior query disabledeletenotify
  NTFS DisableDeleteNotify = 0
  ReFS DisableDeleteNotify = 0

  [root@c03 ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}'
  {"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program 
Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\\\","error":"The given 
volume path is invalid. (0x8901)"}]}}

  PS. tried this on a win 2016 std server with just one fs, no problems
  then.

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



[Bug 1863710] Re: qemu 4.2 does not process discard(trim) commands

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu 4.2 does not process discard(trim) commands

Status in QEMU:
  Expired

Bug description:
  I'm using Arch Linux with qemu 4.2 and blktrace to monitor discard
  commands as they are sent to the hardware.  Blktrace shows nothing as
  the VM is trimming the SSDs.

  I downgraded to qemu 4.1.1 and blktrace shows lots of discard commands
  as the VM is trimming.

  Kernel version is 5.5.4.

  Attached is the libvirt xml.

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



[Bug 1868617] Re: multiseat: route different spice tablet events to distinct vdagents

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  multiseat: route different spice tablet events to distinct vdagents

Status in QEMU:
  Expired

Bug description:
  docs/multiseat.txt says:

  > Note on spice: Spice handles multihead just fine.  But it can't do
  > multiseat.  For tablet events the event source is sent to the spice
  > agent.  But qemu can't figure it, so it can't do input routing.
  > Fixing this needs a new or extended input interface between
  > libspice-server and qemu.  For keyboard events it is even worse:  The
  > event source isn't included in the spice protocol, so the wire
  > protocol must be extended to support this.

  I'm not sure exactly what "can't figure it" means, but it looks to me
  like qemu can't route incoming tablet events from a spice client to
  distinct vdagent channels.

  I think this part of the process can be fixed within qemu.  I've
  reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to
  address the issues with the keyboard interface at the protocol level.

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



[Bug 1866792] Re: formating vdi-disk over nbd fails

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  formating vdi-disk over nbd fails

Status in QEMU:
  Expired

Bug description:
  Hi,
  after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd 
partitioning works fine, but the system hangs up during formating with 
mkfs.ext4.

  Same procedure with qcow2-image works fine
  Tested on Fedora 31 kernel  5.5.7-200.fc31.x86_64

  -
  #! /bin/sh

  qemu-img create -f qcow2 ~/test.qcow2 32G
  #qemu-img version 4.1.1 (qemu-4.1.1-1.fc31)

  modprobe nbd max_part=8
  qemu-nbd --connect=/dev/nbd2 ~/test.qcow2
  #qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31)

  parted -s /dev/nbd2 "mklabel gpt"
  parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G "
  parted  -s -a optimal /dev/nbd2 "p"

  mkfs.ext4 /dev/nbd2p1

  mkdir /mnt/test_qcow2

  mount /dev/nbd2p1 /mnt/test_qcow2
  df -H

  ---
  #! /bin/sh

  qemu-img create -f vdi ~/test.vdi 32G

  modprobe nbd max_part=8
  qemu-nbd --connect=/dev/nbd4 ~/test.vdi

  parted -s /dev/nbd4 "mklabel gpt"
  parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G "
  parted  -s -a optimal /dev/nbd4 "p"

  mkfs.ext4 /dev/nbd4p1
  #Format hangs up due to IO errors
  #Tested on Fedora 31 kernel  5.5.7-200.fc31.x86_64

  mkdir /mnt/test_vdi

  mount /dev/nbd4p1 /mnt/test_vdi
  df -H
  --

  Kind regards
    Eilert

  PS.: There may be a connection to this bug:
  ​
  #1661758 qemu-nbd causes data corruption in VDI-format disk images

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



[Bug 1865099] Re: cannot run x64 based system on x64 host with Intel Haxm

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  cannot run x64 based system on x64 host with Intel Haxm

Status in QEMU:
  Expired

Bug description:
  i am trying to run Windows 10 x64 on Windows 10 x64 host with intel
  haxm as kernel accelerator, but the system never boots, as far i read
  the documentation everything should be fine...

  the logs are qemu:

  
  `
  D:\vm>qemu-system-x86_64 -d 
guest_errors,out_asm,in_asm,op,op_opt,op_ind,int,exec,cpu,fpu,mmu,pcall,cpu_reset,unimp,page,nochain
 -cpu core2duo -smp 4 -accel hax -drive 
file=w10.img,index=0,media=disk,format=raw -cdrom "E:\test\W10x64ProEn-UK.iso" 
-m 4G -L Bios -usbdevice mouse -usbdevice keyboard -boot menu=on -rtc 
base=localtime,clock=host -name windows
  qemu-system-x86_64: -usbdevice mouse: '-usbdevice' is deprecated, please use 
'-device usb-...' instead
  qemu-system-x86_64: -usbdevice keyboard: '-usbdevice' is deprecated, please 
use '-device usb-...' instead
  HAX is working and emulator runs in fast virt mode.
  CPU Reset (CPU 0)
  EAX= EBX= ECX= EDX=
  ESI= EDI= EBP= ESP=
  EIP= EFL= [---] CPL=0 II=0 A20=0 SMM=0 HLT=0
  ES =   
  CS =   
  SS =   
  DS =   
  FS =   
  GS =   
  LDT=   
  TR =   
  GDT=  
  IDT=  
  CR0= CR2= CR3= CR4=
  DR0= DR1= DR2= 
DR3=
  DR6= DR7=
  CCS= CCD= CCO=DYNAMIC
  EFER=
  FCW= FSW= [ST=0] FTW=ff MXCSR=
  FPR0=  FPR1= 
  FPR2=  FPR3= 
  FPR4=  FPR5= 
  FPR6=  FPR7= 
  XMM00= XMM01=
  XMM02= XMM03=
  XMM04= XMM05=
  XMM06= XMM07=
  CR0 update: CR0=0x6010
  CPU Reset (CPU 1)
  EAX= EBX= ECX= EDX=
  ESI= EDI= EBP= ESP=
  EIP= EFL= [---] CPL=0 II=0 A20=0 SMM=0 HLT=0
  ES =   
  CS =   
  SS =   
  DS =   
  FS =   
  GS =   
  LDT=   
  TR =   
  GDT=  
  IDT=  
  CR0= CR2= CR3= CR4=
  DR0= DR1= DR2= 
DR3=
  DR6= DR7=
  CCS= CCD= CCO=DYNAMIC
  EFER=
  FCW= FSW= [ST=0] FTW=ff MXCSR=
  FPR0=  FPR1= 
  FPR2=  FPR3= 
  FPR4=  FPR5= 
  FPR6=  FPR7= 
  XMM00= XMM01=
  XMM02= XMM03=
  XMM04= XMM05=
  XMM06= XMM07=
  CR0 update: CR0=0x6010
  CPU Reset (CPU 2)
  EAX= EBX= ECX= EDX=
  ESI= EDI= EBP= ESP=
  EIP= EFL= [---] CPL=0 II=0 A20=0 SMM=0 HLT=0
  ES =   
  CS =   
  SS =   
  DS =   
  FS =   
  GS =   
  LDT=   
  TR =   
  GDT=  
  IDT=  
  CR0= CR2= CR3= CR4=
  DR0= DR1= DR2= 
DR3=
  DR6= DR7=
  CCS= CCD= CCO=DYNAMIC
  EFER=
  FCW= FSW= [ST=0] FTW=ff MXCSR=
  FPR0=  FPR1=000

[Bug 1872644] Re: MacOS host qemu-system-x86_64 -cpu host not working

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  MacOS host qemu-system-x86_64 -cpu host not working

Status in QEMU:
  Expired

Bug description:
  MacOS: 10.15.4
  uname -a: Linux door 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  I am using qemu on mac host, with ubuntu client.

  I used to have "-cpu host" in my qemu command as follow:-

  qemu-system-x86_64 \
  -no-user-config \
  -nodefaults \
  -name u64d01 \
  -show-cursor \
  -M q35,accel=hvf,usb=off,vmport=off \
  -cpu host \
  -m 8192M \
  -smp 4 \
  -rtc base=utc,clock=host \
  -device virtio-blk-pci,drive=ssd1 \
  -drive id=ssd1,file=/Users/js/code/vm/qemu/u64d01.qcow2,if=none,format=qcow2 \
  -device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 \
  -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \
  -device virtio-tablet-pci \
  -device virtio-vga \
  -device ich9-intel-hda,id=snd,msi=on \
  -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \
  -audiodev coreaudio,id=snd0

  Base on log of one of the vm, it was definitely working on
  2020-01-17(base on journal inside vm), with qemu 4.2.0, which I
  installed with brew.

  The only way to make it work is to remove "-cpu host".

  Already tried with 4.1.1, 4.2 and 5.0rc2. Same result.

  To reproduce, try above with a Ubuntu 18.04 installation cd. Client
  will crash during kernel loading.

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



[Bug 1865188] Re: Switching from the monitor to the emulated machine with a French keyboard (AZERTY)

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Switching from the monitor to the emulated machine with a French
  keyboard (AZERTY)

Status in QEMU:
  Expired

Bug description:
  Hi,
  I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french 
AZERTY.

  sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr  -boot d -drive
  if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial
  mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom
  ../../distri/11iv1/'HP-
  UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS
  _Install&Recovery_B6821-10046.iso' -net nic,model=tulip  -net tap

  When I want to use the monitor (to change cdrom during the hp-ux
  installation process), the characters I type are misinterpreted. For
  example, I enter "2" at hp-ux prompt, I see : "412691;82;22".
  Impossible to switch from monitor to hp-ux with Ctrl+Alt+1 and
  Ctrl+Alt+2.

  I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options 
-alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal 
than hp-ux. Nothing works.
  Best regards.

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



[Bug 1871267] Re: Multiple (Repeating) Keystrokes in macOS

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Multiple (Repeating) Keystrokes in macOS

Status in QEMU:
  Expired

Bug description:
  Hi,

  I am finding this issue with v4.2.0, or the latest master - on a
  Windows host, with macOS guest. It happens using gtk (SPICE?) or VNC.
  When I get to a place to enter a keystroke, I quite reliably get
  multiple of the same key (i.e. press A, get ).

  Thinking there may be a basic setting to address this? I did try it in
  Linux (kvm), no issue there.

  Thanks!

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



[Bug 1864984] Re: "nr_entries is too big" when using virgl

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  "nr_entries is too big" when using virgl

Status in QEMU:
  Expired

Bug description:
  I have a bootable image where GNOME Shell fails because it hits a
  limit in virtio-gpu.

  In `hw/display/virtio-gpu.c`, there is a limit for `nr_entries` at
  16384. There is no explanation for that limit. But there does not seem
  to be any limit on the kernel side.

  Raising this limit with a patch to 262144 solves the issue.

  Could there be an explanation why this limit is needed? And why this
  value? Or could this limit be just removed?

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



[Bug 1871270] Re: [Feature Request] add usbredir device reset blacklist options support to allow macOS guest to iOS device usbredir

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  [Feature Request] add usbredir device reset blacklist options support
  to allow macOS guest to iOS device usbredir

Status in QEMU:
  Expired

Bug description:
  Description of problem:
  Currently, when a iOS device is redirected to a macOS VM, it falls into a 
reset-not-found loop.
  Version-Release number of selected component (if applicable):
  latest
  How reproducible:
  100%
  Steps to Reproduce:

  
  Connect an iOS device to Ubuntu 18.04.2 LTS (I believe it is the same for any 
distro.)

  
  Connect virt-manager/virt-viewer to a macOS VM through SPICE (I am using OSX 
10.15 Catalina)

  
  Attempt to redirect the iOS device (iPad in my case) to the VM through usb 
redirection.

  
  Actual results:
  For any odd number of attempt, the guest macOS will send a reset to the iOS 
device which causes the host to reset the USB connection in the host side. In 
the UI, it will be displayed as a successful connection for a few seconds 
before it disconnects. After this, the iOS device will reconnect itself, but 
via a different device name /dev/bus/usb/x/y+1.
  For any even number of attempt, when I select the iOS device in the 
virt-manager/virt-viewer UI, the connection will not success and instead a 
LIBUSB_ERROR_NOT_FOUND error will be provided. Then the UI will reload and get 
the new device name of the iOS device, falling into the behavior of the 
aforementioned odd number of attempt.
  Expected results:
  The macOS detects the iOS device and connects to it happily.
  Additional info:
  It seems that this bug has been first identified as in 
https://bugs.freedesktop.org/show_bug.cgi?id=100149, for a Samsung Android 
device, which the developers of SPICE applied a hotfix in 
https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirhost/usbredirhost.c#L147.
 However, there were no settings available for users to fix it.
  A similar bug that also consists of a macOS guest/iOS device pair, but 
instead of being usbredir, is usb-host, has been identified and patched in 
https://github.com/qemu/qemu/commit/ba4c735b4fc74e309ce4b2551d258e442ef513a5, 
which is further modified into 
https://github.com/qemu/qemu/blame/146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8/hw/usb/host-libusb.c#L1486.
 Following such patch, I have attempted to apply such patch at host-side in 
https://github.com/michaellee8/qemu/blob/master/hw/usb/redirect.c (not 
correctly formatted currently, pls ignore it atm), however I discovered that 
this is not enough since it is also a SPICE issue, which resolves to 
virt-manager/virt-viewer.
  This is probably a cross-project issue between qemu, spice (usbredir) and 
virt-manager/virt-viewer, which would some effort to coordinate a solution. 
However a working solution for this problem would probably benefits a lot of 
users whom relies on connecting a mobile device into a VM, for purposes like 
easier mobile development. Considering the report for the Samsung Android 
Device on a PC use case, such issue is probably cross-OS/cross-device.

  cross-references:
  - https://bugzilla.redhat.com/show_bug.cgi?id=1821518
  - https://bugzilla.redhat.com/show_bug.cgi?id=1821517
  - https://gitlab.freedesktop.org/spice/usbredir/-/issues/10

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



[Bug 1866577] Re: powerpc-none-eabi-gdb.exe GDB 9.1 with QEMU 4.2 gdb-stub comes with Reply contains invalid hex digit 79

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  powerpc-none-eabi-gdb.exe GDB 9.1 with QEMU 4.2 gdb-stub comes with
  Reply contains invalid hex digit 79

Status in QEMU:
  Expired

Bug description:
  I am using powerpc-none-eabi-gdb with qemu 4.2, but it comes with 
  the following error:

  undefinedC:\CI-Tools\msys64\powerpc-none-eabi\usr\local\bin\powerpc-
  none-eabi-gdb.exe: warning: Couldn't determine a path for the index
  cache directory.

  ```Not implemented stop reason (assuming exception): undefined```
  The target architecture is assumed to be powerpc:603

  ```
  Reply contains invalid hex digit 79
  ```

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



[Bug 1874486] Re: Bug in qemu-img when converting to streamOptimized vmdk images

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Bug in qemu-img when converting to streamOptimized vmdk images

Status in QEMU:
  Expired

Bug description:
  I reviewed #1006655, and I think I'm already on a newer version, so
  this is either a regression or a new bug.

  I have been recently attempting to convert images from raw and qcow2
  formats to vmdk. It appears that the option
  "subformat=streamOptimized" produces a broken or corrupted disk image.

  Current versions, running on Devuan testing:

  ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-1
all  PXE boot firmware - ROM images for qemu
  ii  qemu  1:3.1+dfsg-8+deb10u4
amd64fast processor emulator, dummy package
  ii  qemu-efi-aarch64  0~20181115.85588389-3   
all  UEFI firmware for 64-bit ARM virtual machines
  ii  qemu-efi-arm  0~20181115.85588389-3   
all  UEFI firmware for 32-bit ARM virtual machines
  ii  qemu-kvm  1:3.1+dfsg-8+deb10u4
amd64QEMU Full virtualization on x86 hardware
  ii  qemu-slof 20180702+dfsg-1 
all  Slimline Open Firmware -- QEMU PowerPC version
  ii  qemu-system   1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries
  ii  qemu-system-arm   1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (arm)
  ii  qemu-system-common1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-data  1:3.1+dfsg-8+deb10u4
all  QEMU full system emulation (data files)
  ii  qemu-system-gui   1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (user interface 
and audio support)
  ii  qemu-system-mips  1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (mips)
  ii  qemu-system-misc  1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (miscellaneous)
  ii  qemu-system-ppc   1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (ppc)
  ii  qemu-system-sparc 1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (sparc)
  ii  qemu-system-x86   1:3.1+dfsg-8+deb10u4
amd64QEMU full system emulation binaries (x86)
  ii  qemu-utils1:3.1+dfsg-8+deb10u4
amd64QEMU utilities

  Current uname -a:
  Linux laptop-dev 5.4.0-0.bpo.3-amd64 #1 SMP Debian 5.4.13-1~bpo10+1 
(2020-02-07) x86_64 GNU/Linux

  Current CPU info:
  $ cat /proc/cpuinfo
  processor   : 0
  vendor_id   : GenuineIntel
  cpu family  : 6
  model   : 158
  model name  : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  stepping: 10
  microcode   : 0xca
  cpu MHz : 800.109
  cache size  : 9216 KB
  physical id : 0
  siblings: 12
  core id : 0
  cpu cores   : 6
  apicid  : 0
  initial apicid  : 0
  fpu : yes
  fpu_exception   : yes
  cpuid level : 22
  wp  : yes
  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx 
est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi 
flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms 
invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves 
dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
  bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf 
mds swapgs itlb_multihit
  bogomips: 4399.99
  clflush size: 64
  cache_alignment : 64
  address sizes   : 39 bits physical, 48 bits virtual
  power management:

  $ cat /proc/meminfo
  MemTotal:

[Bug 1870477] Re: qemu-arm hangs when golang running test

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-arm hangs when golang running test

Status in QEMU:
  Expired

Bug description:
  
  1. Environment:
  Ubuntu 16.04.5 X86_64
  qemu-arm version 4.2.0
  go version go 1.14.1 linux/arm

  2. Summary:
  Sometimes "go run test.go" command hang

  
  3. Reproduction Method (Attempts: 500 Occurred: 1 ): Frequency: 1/500

  
  test.go
  ==
  package main
  import "fmt"
  func main(){
  for i:=0; i<1000; i++ {
  fmt.Printf("[%d] Hello world\n", i)
  }
  }
  ==

  i tested "go run test.go" command called  500 times at qemu arm env.
  qemu hangs about 200~300.

  attached strace log.

  please check.
  thanks

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



[Bug 1881645] Re: qemu-system-x86_64 --help (or --version) gives no output

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-system-x86_64 --help (or --version) gives no output

Status in QEMU:
  Expired

Bug description:
  I have Arch Linux with qemu 5.0.0-6 (seen with pacman). Running VMs work just 
fine, but when I run qemu-system-x86_64 --version or qemu-system-x86_64 --help, 
there is no feedback on the screen. This behavior messes up other applications 
(GNS3 in my case that cannot recognize qemu as correctly installed because 
there is no feedback.)
  My kernel is 5.6.11.

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



[Bug 1879590] Re: Using qemu-system-sparc64 no network interface seems to exist

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Using qemu-system-sparc64 no network interface seems to exist

Status in QEMU:
  Expired

Bug description:
  Using boot command:

  qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/
  -nographic -m 256 -drive
  if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2

  After I log into solaris system I see no network devices other than the 
loopback device.
  All the docs I can see suggest it should come up with a default network 
device that allows communication via the hosts network. Host is ubuntu 64bit.  

  root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version
  QEMU emulator version 5.0.0
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

  
  dladm show-link
  ifconfig -a


  ok boot
  Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
  FCode UFS Reader 1.12 00/07/17 15:48:16.
  Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
  Loading: /platform/sun4v/ufsboot
  SunOS Release 5.10 Version Generic_118822-23 64-bit
  Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
  Use is subject to license terms.
  Hostname: unknown

  unknown console login: root
  Last login: Wed Feb  8 09:01:28 on console
  Sun Microsystems Inc.   SunOS 5.10  Generic January 2005
  # dladm show-link
  # ifconfig -a
  lo0: flags=2001000849 mtu 8232 
index 1
  inet 127.0.0.1 netmask ff00

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



[Bug 1874904] Re: qemu windows with gtk and french keypad not working as expected

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu windows with gtk and french keypad not working as expected

Status in QEMU:
  Expired

Bug description:
  When I use qemu on Windows 10 with a French AZERTY keypad with the
  correct options the emulated system keypad still QWERTY. If I use sdl
  it works fine the emulated keypad is AZERTY.

  Example of command with ubuntu live cd:
  -> qemu-system-x86_64.exe  -m 4G ubuntu-18.04.4-desktop-amd64.iso -display 
gtk -k fr

  NOTES:
   - Using the same command on Linux works fine. The emulated keypad is AZERTY.

  Qemu version : 4.2.0 on Windows 10

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



[Bug 1868055] Re: cannot run golang app with docker, version 17.09.1-ce, disabling core 0 and qemu-arm, version 2.7.

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  cannot run golang app with docker, version 17.09.1-ce, disabling core
  0 and qemu-arm, version 2.7.

Status in QEMU:
  Expired

Bug description:
  Hello!
  I figure out that sometimes simple go application is not working.
  I am using docker + qemu-arm + go( for armv7l).

  These are version info below.

  root@VDBS1535:~# docker -v
  Docker version 17.09.1-ce, build 19e2cf6

  bash-3.2# qemu-arm --version
  qemu-arm version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU 
Project developers

  $ go version
  go version go1.12.6 linux/arm
  $ go env
  GOARCH="arm"
  GOBIN=""
  GOCACHE="/home/quickbuild/.cache/go-build"
  GOEXE=""
  GOFLAGS=""
  GOHOSTARCH="arm"
  GOHOSTOS="linux"
  GOOS="linux"
  GOPATH="/home/quickbuild/go"
  GOPROXY=""
  GORACE=""
  GOROOT="/usr/lib/golang"
  GOTMPDIR=""
  GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_arm"
  GCCGO="gccgo"
  GOARM="7"
  CC="gcc"
  CXX="g++"
  CGO_ENABLED="1"
  GOMOD=""
  CGO_CFLAGS="-g -O2"
  CGO_CPPFLAGS=""
  CGO_CXXFLAGS="-g -O2"
  CGO_FFLAGS="-g -O2"
  CGO_LDFLAGS="-g -O2"
  PKG_CONFIG="pkg-config"
  GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build242285369=/tmp/go-build 
-gno-record-gcc-switches"

  This issue is come only when I disable core 0 using a command below.
  please check "--cpuset-cpus=1-55" option.

  sudo docker run --privileged -d -i -t --cpuset-cpus=1-55 --mount
  type=bind,source="/home/dw83kim/mnt",destination="/mnt" --network host
  --name="ubuntu_core1" ubuntu:xenial-20200212

  
  This is what I have tested in the environment above.

  package main
  func main(){
  for i:=0; i<1000; i++ {
  println("Hello world")
  }
  }

  This is one of the error logs have faced sometimes not always.

  bash-3.2# go run test.go
  fatal error: schedule: holding locks
  panic during panic
  SIGILL: illegal instruction
  PC=0xc9ec4c m=3 sigcode=2

  goroutine 122 [runnable]:
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)
  bash-3.2#

  Please check it.
  Thanks in advance.

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



[Bug 1880722] Re: Problems related to checking page crossing in use_goto_tb()

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Problems related to checking page crossing in use_goto_tb()

Status in QEMU:
  Expired

Bug description:
  The discussion that led to this bug discovery can be found in this
  mailing list thread:
  https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html

  A workaround for this problem would be to check for page crossings for
  both the user and system modes in the use_goto_tb() function across
  targets. Some targets like "hppa" already implement this fix but others
  don't.

  To solve the root cause of this problem, the linux-user/mmap.c should
  be fixed to do all the invalidations required. By doing so, better
  performance results could be achieved, compared to the case of the
  workaround described above.

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



[Bug 1881506] Re: TCG doesn't support a lot of features that should be supported

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  TCG doesn't support a lot of features that should be supported

Status in QEMU:
  Expired

Bug description:
  This is quite odd, and I'm not sure about how to get around it. I'm writing 
an OS in Rust and require APIC support. When I boot my kernel with 
qemu-system-x86_64, however, it dumps out a [lot] of warnings; it claims that 
TCG doesn't support FMA, X2APIC, AVX, F16C, AVX2, RDSEED, SHA-NI, FXSR-OPT, 
misalignsse, 3dnowprefetch, osvw, topoext, perfctr-core, clzero, xsaveerptr, 
ibpb, nrip-save, xsavec, and xsaves, but prints these warnings over 80 times 
before finally doing what I told it to do. Running QEMU 5.0.0 (unknown commit 
hash), as follows:
  qemu-system-x86_64 -drive 
format=raw,file=target\x86_64-kernel-none\debug\bootimage-kernel.bin -serial 
stdio -no-reboot -hdb disk.img -s -m 4G -usb -rtc base=utc,clock=host -cpu 
EPYC-v3,+acpi,+apic,+rdrand,+rdseed,+sse,+sse2,+sse4.1,+sse4.2,+sse4a,+ssse3,+syscall,+x2apic
 -smp cpus=8 -soundhw all
  I would run using HAXM, but my kernel requires RDRAND, and QEMU does not, to 
my knowledge, automatically support RDRAND (and I don't know how to enable it).

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



[Bug 1869782] Re: qemu-arm-static crashes "segmentation fault" when running "svn checkout"

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-arm-static crashes "segmentation fault" when running "svn
  checkout"

Status in QEMU:
  Expired

Bug description:
  I'm not actually sure how far I can help as I so far failed to
  reproduce the issue on my local VM but I get it on Travis CI every
  time. I even went through the hassle of hacking a Debian repository
  into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version
  could fix this.

  This build runs in an armv6h chroot. I don't get the segfault if I do
  the same on an armv7h chroot for some reason.

  Here is where the error occured: https://travis-
  ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420

  Maybe now I'll just try to remove all uses of svn in my build
  scripts...

  Is it actually a viable solution to cross-build with qemu? I'm
  starting to doubt it...

  Would it help if I manage to get this core dump out of Travis somehow
  (maybe make Travis push it to some GIT or upload it to my webserver)?

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



[Bug 1877052] Re: KVM Win 10 guest pauses after kernel upgrade

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  KVM Win 10 guest pauses after kernel upgrade

Status in QEMU:
  Expired
Status in qemu package in Ubuntu:
  Expired

Bug description:
  Hello!
  Unfortunately the bug has apparently reappeared. I have a Windows 10 running 
in a VM, which after my today's "apt upgrade" goes into pause mode after a few 
seconds of running time.

  Until yesterday it used to work and I was able to boot the VM. During
  the kernel update (from 5.4.0-28.33 to 5.4.0-29.34) the VM was active
  and then went into pause mode. Even after a reboot of my host system
  the problem still persists: the VM boots for a few seconds and then
  switches to pause mode.

  Current Kernel: Linux andreas-laptop 5.4.0-29-generic #33-Ubuntu SMP
  Wed Apr 29 14:32:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

  Maybe relevant logfile lines:
  2020-05-06T07:46:42.857574Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
  2020-05-06T07:46:42.857718Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
  2020-05-06T07:46:42.860567Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
  2020-05-06T07:46:42.860582Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
  2020-05-06T07:47:22.901057Z qemu-system-x86_64: terminating on signal 15 from 
pid 1593 (/usr/sbin/libvirtd)
  2020-05-06 07:47:23.101+: shutting down, reason=destroyed


  Kind regards,
     Andreas

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



[Bug 1882241] Re: file transfer over cifs to 64bit guest corrupts large files

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  file transfer over cifs to 64bit guest corrupts large files

Status in QEMU:
  Expired

Bug description:
  qemu 4.0 compiled fom source.
  vm called by
  qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive 
file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom 
/mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net 
nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k 
en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay

  copying large files eg 2.4gb or reading them on a cifs mount in the guest 
causes corruption every time. For smaller files 40-60mb corruption is more than 
50% of the time. tested by md5sum on cifs server, or on host machine vs. on 
guest vm.
  corruption is seen only with 64bit guest using cifs with i82551 emulated 
network device
  ie. 32bit guest using cifs with i82551 emulated network device gives no 
corruption.

  changing the emulated device to vmxnet3 removes the data corruption
  (see below)

  qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive
  file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom
  /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net
  nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0
  -enable-kvm -k en-gb -display vnc=:3 -monitor
  telnet:localhost:7103,server,nowait,nodelay

  this corruption is repeatable. ie. I created new vm, call using top example, 
installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then 
run md5sum "filecopied"
  the md5sum is different every time. copy same file to the host, or to a 32bit 
guest with the same virtual network device and bridge and md5sums are correct. 
The host pysical network adapter is
  lspci|grep Ether
  1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)

  physically connected via gigabit ethernet to cifs server (via gigabit
  switch)

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



[Bug 1883784] Re: [ppc64le] qemu behavior differs from ppc64le hardware

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  [ppc64le] qemu behavior differs from ppc64le hardware

Status in QEMU:
  Expired

Bug description:
  I have some code which passes my test suite on PPC64LE hardware when
  compiled with GCC 10, but the saem binary fails with both qemu-ppc64le
  4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing).

  I'm not getting any errors about illegal instructions or anything,
  like that; the results are just silently different on qemu.

  I've generated a reduced test case, which is attached along with the
  binaries (both are the same code, one is just statically linked).
  They should execute successufully on PPC64LE hardware, but on qemu
  they hit a __builtin_abort (because the computed value doesn't match
  the expected value).

  Without being familiar with PPC assembly I'm not sure what else I can
  do, but if there is anything please let me know.

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



[Bug 1876568] Re: "semtimedop" implementation missing in qemu?

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  "semtimedop" implementation missing in qemu?

Status in QEMU:
  Expired

Bug description:
  I was trying to do an ARMv6 cross compile with qemu-user-static when I
  ran into this:

  https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/326884620#L1596

  I was close to giving up when I found the following:

  https://github.com/osrf/multiarch-docker-image-generation/issues/36

  Most important comment may be this one:

  https://github.com/osrf/multiarch-docker-image-
  generation/issues/36#issuecomment-610626796

  > The "correct" way to fix this does seem to be to implement
  semtimedop in qemu.

  I don't know how much involved the people, discussing there, are in
  the qemu development but I thought it may be a good idea to bring this
  to your attention. If this is already fixed (I haven't found any bug
  about "semtimedop"), then please just close this one and tell me in
  which version the fix will be included.

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



[Bug 1881729] Re: target_read_memory in disas.c ignores possible errors

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  target_read_memory in disas.c ignores possible errors

Status in QEMU:
  Expired

Bug description:
  `target_read_memory` in `disas.c` ignores (possible) errors. This
  leads to disassembler possibly disassembling garbage.

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



[Bug 1882350] Re: it always create sdx device when I configure ide device with hdx name

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  it always create sdx device when I configure ide device with hdx name

Status in QEMU:
  Expired

Bug description:
  I have configured 2 ide disks with name starting with hd, but when the
  vm boots up, it shows disks whose name starting with sd.

  1. ide disks in vm xml:

  



  
  



  

  
  2. in VM:

  sda8:002G  0 disk
  sdb8:16   01G  0 disk

  
  3. from vm.log:

  le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-
  hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive
  file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device
  ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev t

  
  4. rpm info: (I got the same issue on 2 diff envs)
  (1) env1
  qemu-kvm-1.5.3-105
  libvirt-3.2.0-14.el7
  (2) env2
  libvirt-5.9.0-1.el8
  qemu-4.1.0-1.el8

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



[Bug 1882497] Re: Missing 'cmp' utility makes build take 10 times as long

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Missing 'cmp' utility makes build take 10 times as long

Status in QEMU:
  Expired

Bug description:
  I have been doing some work cross compiling qemu for Windows using a
  minimal Fedora container. Recently I started hitting some timeouts on
  the CI service and noticed a build of all targets was going over 1
  hour.

  It seems like the 'cmp' utility from diffutils is used somewhere in
  the process and if it's missing, either a configure or a make gets run
  way too many times - I'll try to pull logs from the CI system at some
  stage soon.

  Could a warning or error be added if cmp is missing?

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



[Bug 1874504] Re: VFIO passthrough spits out thousands of messages

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  VFIO passthrough spits out thousands of messages

Status in QEMU:
  Expired

Bug description:
  started qemu as:
  sudo qemu-system-sparc64 -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB

  messages received thousands of times:

  qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: 
iommu has granularity incompatible with target AS
  qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: 
iommu map to non memory area 4079c000

  qemu version (think telling a lie as sure its 5.0)
  QEMU emulator version 4.2.92
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

  pci device being passed through:

  0b:05.0 Display controller [0380]: 3DLabs Permedia II 2D+3D [3d3d:0009] (rev 
01)
Subsystem: Tech-Source Permedia II 2D+3D [1227:0006]
Flags: medium devsel, IRQ 11
Memory at 8300 (32-bit, non-prefetchable) [disabled] [size=128K]
Memory at 8280 (32-bit, non-prefetchable) [disabled] [size=8M]
Memory at 8200 (32-bit, non-prefetchable) [disabled] [size=8M]
Expansion ROM at 8302 [disabled] [size=64K]
Capabilities: 
Kernel driver in use: vfio-pci

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



[Bug 1884017] Re: Intermittently erratic mouse under Windows 95

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Intermittently erratic mouse under Windows 95

Status in QEMU:
  Expired

Bug description:
  The mouse works fine maybe 75-80% of the time, but intermittently
  (every 20-30 seconds or so), moving the mouse will cause the pointer
  to fly around the screen at high speed, usually colliding with the
  edges, and much more problematically, click all the mouse buttons at
  random, even if you are not clicking. This causes random objects on
  the screen to be clicked and dragged around, rendering the system
  generally unusable.

  I don't know if this is related to #1785485 - it happens even if you
  never use the scroll wheel.

  qemu version: 5.0.0 (openSUSE Tumbleweed)

  Launch command line: qemu-system-i386 -hda win95.qcow2 -cpu pentium2
  -m 16 -vga cirrus -soundhw sb16 -nic user,model=pcnet -rtc
  base=localtime

  OS version: Windows 95 4.00.950 C

  I have made the disk image available here:
  https://home.gloveraoki.me/share/win95.qcow2.lz

  Setup notes: In order to make Windows 95 detect the system devices
  correctly, after first install you must change the driver for "Plug
  and Play BIOS" to "PCI bus". I have already done this in the above
  image.

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



[Bug 1884425] Re: MIPS64EL emu hangs at reboot

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  MIPS64EL emu hangs at reboot

Status in QEMU:
  Expired

Bug description:
  QEMU Release version: 5.0.50 (v5.0.0-1411-g26bf4a2921-dirty)

  Full command line: qemu-system-mips64el -hda nt4svr.qcow2 -M magnum -L
  . -global ds1225y.filename=nvram  -global ds1225y.size=8200 -net nic
  -net user -cdrom en_winnt_4.0_svr.iso

  Host machine: Windows 10 1909 64-bit, QEMU running under WSL with the
  latest Kali distro and the latest Xming.

  Guest machine: MIPS64EL Magnum machine, no OS needs to be installed to
  reproduce - just change some stuff in the Setup program and try to
  exit

  Note: Custom ROM with Windows NT support used, NTPROM.RAW used from
  http://hpoussineau.free.fr/qemu/firmware/magnum-4000/setup.zip

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



[Bug 1885827] Re: building plugin failed on Windows with mingw

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  building plugin failed on Windows with mingw

Status in QEMU:
  Expired

Bug description:
  I want to build QEMU 4.2.0's plugin module on Windows 7/10 with Mingw, but 
the building process faild.
   
  The step I follow is listed below:
  1. create "dsp_build" diretory under source file folder

  2.  change directory to dsp_build , and run ../configure 
--target-list=dsp-softmmu --cross-prefix=x86_64-w64-mingw32- --enable-gtk 
--enable-sdl --enable-debug --enable-plugins
  3. build qemu project
  4. switch dir to /dsp_build, make -C tests/plugin, yeilds error: 
 CC  bb.o
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: 
error: variable 'qemu_plugin_version' definition is marked dllimport
 17 | QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
|^~~
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: 
warning: 'qemu_plugin_version' redeclared without dllimport attribute: previous 
dllimport ignored [-Wattributes]
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In 
function 'vcpu_tb_exec':
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:33:29: 
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 33 | unsigned long n_insns = (unsigned long)udata;
| ^
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In 
function 'vcpu_tb_trans':
   D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:51:46: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
 51 |  (void *)n_insns);

  5.  Then , I modified the QEMU_flags and the compilation command
  arguments($(CC) ..) in  the  makefile :

  BUILD_DIR := $(CURDIR)/../..

include $(BUILD_DIR)/config-host.mak
include $(SRC_PATH)/rules.mak

  $(call set-vpath, $(SRC_PATH)/tests/plugin)

NAMES :=
NAMES += bb
NAMES += empty
NAMES += insn
NAMES += mem
NAMES += hotblocks
NAMES += howvec
NAMES += hotpages

  SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES)))

QEMU_CFLAGS += -fPIC-DBUILDING_DLL  #added  
-DBUILDING_DLL
QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu

  all: $(SONAMES)

lib%.so: %.o
$(CC) -fPIC -shared -o $@ $^ $(LDLIBS) -L 
/c/msys64/mingw64/lib/ -lglib-2.0
# original cmd: $(CC) -shared -Wl,-soname,$@ -o $@ $^ 
$(LDLIBS)

clean:
rm -f *.o *.so *.d
rm -Rf .libs

  .PHONY: all clean

  6.  Executing make yeilds:

  make: enter   
“/d/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/build_dsp/tests/plugin”
CC  bb.o
  x86_64-w64-mingw32-gcc -fPIC -shared -o libbb.so bb.o  -L 
/c/msys64/mingw64/lib/ -lglib-2.0
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 bb.o: in function `plugin_exit':
  D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:28: 
undefined reference to `qemu_plugin_outs'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:29: 
undefined reference to `__stack_chk_fail'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 bb.o: in function `vcpu_tb_trans':
  D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:41: 
undefined reference to `qemu_plugin_tb_n_insns'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:44: 
undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:46: 
undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:49: 
undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/..

[Bug 1875080] Re: USB host device data transfer with control endpoint

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  USB host device data transfer with control endpoint

Status in QEMU:
  Expired

Bug description:
  QEMU emulator version 4.2.0
  Host -> Arch Linux kernel version: 5.4.34-1-lts
  Guest -> Various Linux Distros

  I sent a control message with data through endpoint zero.
  On the other side message is received with all fields correct except data 
buffer.
  I've tested the data field inside guest with usbmon and data field was 
correct but after packet leaved qemu, data filed is lost.

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



[Bug 1885553] Re: make-check test failed with "Segmentation fault"

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  make-check test failed with "Segmentation fault"

Status in QEMU:
  Expired

Bug description:
  While running the make-check testing on arm architecture the test failed with 
error:
  "kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core 
dumped)". Apart from that make-install test always passes.
  The problem doesn't reproduce in 100%
  qemu - from the master branch
  RHEL-8 kernel 4.18.0-221.el8.aarch64
  Logfile with an error you can to find in attachment

  Thanks

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



[Bug 1886155] Re: error: argument 2 of ‘__atomic_load’ discards ‘const’ qualifier

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  error: argument 2 of ‘__atomic_load’ discards ‘const’ qualifier

Status in QEMU:
  Expired

Bug description:
  GCC 11 reports the following errors:

  [  125s] In file included from 
/home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/seqlock.h:17,
  [  125s]  from 
/home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/qht.h:10,
  [  125s]  from 
/home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:69:
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 
'qht_do_lookup':
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:499:27: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   499 | void *p = atomic_rcu_read(&b->pointers[i]);
  [  125s]   |   ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:506:13: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   506 | b = atomic_rcu_read(&b->next);
  [  125s]   | ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 
'qht_lookup_custom':
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:534:11: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   534 | map = atomic_rcu_read(&ht->map);
  [  125s]   |   ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 
'qht_statistics_init':
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:907:11: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   907 | map = atomic_rcu_read(&ht->map);
  [  125s]   |   ^~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: 
error: argument 2 of '__atomic_load' discards 'const' qualifier 
[-Werror=incompatible-pointer-types]
  [  125s]   153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
  [  125s]   | ^
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: 
note: in expansion of macro 'atomic_rcu_read__nocheck'
  [  125s]   161 | atomic_rcu_read__nocheck(ptr, &_val); \
  [  125s]   | ^~~~
  [  125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:941:21: note: in 
expansion of macro 'atomic_rcu_read'
  [  125s]   941 | b = atomic_rcu_read(&b->next);
  [  125s]   | ^~~

To manage notifications about this bug go to:
https://bugs.launchpad.net/

[Bug 1891749] Re: CGA Mode 6 is only 100 pixels tall, when it's supposed to be 200

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  CGA Mode 6 is only 100 pixels tall, when it's supposed to be 200

Status in QEMU:
  Expired

Bug description:
  I have written a program that used CGA Mode 6 (640x200 black and
  white). However qemu-system-i386 only displays the first 100 pixels,
  effectively limiting the resolution of mode 6 to 640x100. When running
  the same program on a real computer it uses the whole 640x200 pixels.

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



[Bug 1888492] Re: After installing Ubuntu, restart and pop up the CMD command prompt

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  After installing Ubuntu, restart and pop up the CMD command prompt

Status in QEMU:
  Expired

Bug description:
  QEMU release version: V5.1.0
  time:2020年7月22日10:34:40
  Operation: 安装完Ubuntu后重新启动,并弹出CMD命令提示符
  use Ubuntu release version :V20.04-desktop.
  use windows release version: windows 10.
  Question:
  Command used:qemu-system-x86_64.exe -name test -m 4096 -machine accel=hax 
-cdrom .\workspace\ubuntu\ubuntu-20.04-desktop-amd64.iso 
.\workspace\img\ubuntu.img
  HAX is working and emulator runs in fast virt mode.
  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  (qemu:660): Gtk-WARNING **: Negative content width -7 (allocation 1,
  extents 4x4) while allocating gadget (node headerbar, owner
  GtkHeaderBar)

  (qemu:660): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  allocate widget with width -102 and height 16

  (qemu:660): Gtk-WARNING **: Negative content width -23 (allocation 1, extents 
12x12) while allocating gadget (node label, owner GtkLabel)
  qemu-system-x86_64.exe: Gtk: gtk_distribute_natural_allocation: assertion 
'extra_space >= 0' failed

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



[Bug 1877052] Re: KVM Win 10 guest pauses after kernel upgrade

2021-07-05 Thread Launchpad Bug Tracker
[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  KVM Win 10 guest pauses after kernel upgrade

Status in QEMU:
  Expired
Status in qemu package in Ubuntu:
  Expired

Bug description:
  Hello!
  Unfortunately the bug has apparently reappeared. I have a Windows 10 running 
in a VM, which after my today's "apt upgrade" goes into pause mode after a few 
seconds of running time.

  Until yesterday it used to work and I was able to boot the VM. During
  the kernel update (from 5.4.0-28.33 to 5.4.0-29.34) the VM was active
  and then went into pause mode. Even after a reboot of my host system
  the problem still persists: the VM boots for a few seconds and then
  switches to pause mode.

  Current Kernel: Linux andreas-laptop 5.4.0-29-generic #33-Ubuntu SMP
  Wed Apr 29 14:32:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

  Maybe relevant logfile lines:
  2020-05-06T07:46:42.857574Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
  2020-05-06T07:46:42.857718Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
  2020-05-06T07:46:42.860567Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
  2020-05-06T07:46:42.860582Z qemu-system-x86_64: warning: host doesn't support 
requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
  2020-05-06T07:47:22.901057Z qemu-system-x86_64: terminating on signal 15 from 
pid 1593 (/usr/sbin/libvirtd)
  2020-05-06 07:47:23.101+: shutting down, reason=destroyed


  Kind regards,
     Andreas

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



[Bug 1904259] Re: include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty (Clang 11; Ubuntu 16 i686)

2021-07-05 Thread Launchpad Bug Tracker
[Expired for Ubuntu because there has been no activity for 60 days.]

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

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

Title:
  include/qemu/atomic.h:495:5: error: misaligned atomic operation may
  incur significant performance penalty (Clang 11; Ubuntu 16 i686)

Status in QEMU:
  Expired
Status in Ubuntu:
  Expired

Bug description:
  Hello.
  I haven't found any "official" executables, for emulating RISC-V (32bit; 
64bit) so I had to compile those myself.

  I found that auto-generated build scripts, for Ninja, contained some
  warnings interpreted as errors:

  
  oceanfish81@gollvm:~/Desktop/qemu/build$ ninja -j 1
  [2/1977] Compiling C object libqemuutil.a.p/util_qsp.c.o
  FAILED: libqemuutil.a.p/util_qsp.c.o 
  clang-11 -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
-I/usr/include/gio-unix-2.0/ -Xclang -fcolor-diagnostics -pipe -Wall 
-Winvalid-pch -Werror -std=gnu99 -O2 -g -m32 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body 
-Wnested-externs -Wendif-labels -Wexpansion-to-defined 
-Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value 
-Wno-string-plus-int -Wno-typedef-redefinition 
-Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong 
-isystem /home/oceanfish81/Desktop/qemu/linux-headers -isystem linux-headers 
-iquote /home/oceanfish81/Desktop/qemu/tcg/i386 -iquote . -iquote 
/home/oceanfish81/Desktop/qemu -iquote /home/oceanfish81/Desktop/qemu/accel/tcg 
-iquote /home/oceanfish81/Desktop/qemu/include -iquote 
/home/oceanfish81/Desktop/qemu/disas/libvixl -pthread -Wno-unused-function 
-fPIC -MD -MQ libqemuutil.a.p/util_qsp.c.o -MF libqemuutil.a.p/util_qsp.c.o.d 
-o libqemuutil.a.p/util_qsp.c.o -c ../util/qsp.c
  In file included from ../util/qsp.c:62:
  In file included from /home/oceanfish81/Desktop/qemu/include/qemu/thread.h:4:
  In file included from 
/home/oceanfish81/Desktop/qemu/include/qemu/processor.h:10:
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:495:5: error: misaligned 
atomic operation may incur significant performance penalty 
[-Werror,-Watomic-alignment]
  qatomic_set__nocheck(ptr, val);
  ^
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:138:5: note: expanded 
from macro 'qatomic_set__nocheck'
  __atomic_store_n(ptr, i, __ATOMIC_RELAXED)
  ^
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:485:12: error: 
misaligned atomic operation may incur significant performance penalty 
[-Werror,-Watomic-alignment]
  return qatomic_read__nocheck(ptr);
 ^
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:129:5: note: expanded 
from macro 'qatomic_read__nocheck'
  __atomic_load_n(ptr, __ATOMIC_RELAXED)
  ^
  2 errors generated.
  ninja: build stopped: subcommand failed.

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



[Bug 1904259] Re: include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty (Clang 11; Ubuntu 16 i686)

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  include/qemu/atomic.h:495:5: error: misaligned atomic operation may
  incur significant performance penalty (Clang 11; Ubuntu 16 i686)

Status in QEMU:
  Expired
Status in Ubuntu:
  Expired

Bug description:
  Hello.
  I haven't found any "official" executables, for emulating RISC-V (32bit; 
64bit) so I had to compile those myself.

  I found that auto-generated build scripts, for Ninja, contained some
  warnings interpreted as errors:

  
  oceanfish81@gollvm:~/Desktop/qemu/build$ ninja -j 1
  [2/1977] Compiling C object libqemuutil.a.p/util_qsp.c.o
  FAILED: libqemuutil.a.p/util_qsp.c.o 
  clang-11 -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
-I/usr/include/gio-unix-2.0/ -Xclang -fcolor-diagnostics -pipe -Wall 
-Winvalid-pch -Werror -std=gnu99 -O2 -g -m32 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body 
-Wnested-externs -Wendif-labels -Wexpansion-to-defined 
-Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value 
-Wno-string-plus-int -Wno-typedef-redefinition 
-Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong 
-isystem /home/oceanfish81/Desktop/qemu/linux-headers -isystem linux-headers 
-iquote /home/oceanfish81/Desktop/qemu/tcg/i386 -iquote . -iquote 
/home/oceanfish81/Desktop/qemu -iquote /home/oceanfish81/Desktop/qemu/accel/tcg 
-iquote /home/oceanfish81/Desktop/qemu/include -iquote 
/home/oceanfish81/Desktop/qemu/disas/libvixl -pthread -Wno-unused-function 
-fPIC -MD -MQ libqemuutil.a.p/util_qsp.c.o -MF libqemuutil.a.p/util_qsp.c.o.d 
-o libqemuutil.a.p/util_qsp.c.o -c ../util/qsp.c
  In file included from ../util/qsp.c:62:
  In file included from /home/oceanfish81/Desktop/qemu/include/qemu/thread.h:4:
  In file included from 
/home/oceanfish81/Desktop/qemu/include/qemu/processor.h:10:
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:495:5: error: misaligned 
atomic operation may incur significant performance penalty 
[-Werror,-Watomic-alignment]
  qatomic_set__nocheck(ptr, val);
  ^
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:138:5: note: expanded 
from macro 'qatomic_set__nocheck'
  __atomic_store_n(ptr, i, __ATOMIC_RELAXED)
  ^
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:485:12: error: 
misaligned atomic operation may incur significant performance penalty 
[-Werror,-Watomic-alignment]
  return qatomic_read__nocheck(ptr);
 ^
  /home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:129:5: note: expanded 
from macro 'qatomic_read__nocheck'
  __atomic_load_n(ptr, __ATOMIC_RELAXED)
  ^
  2 errors generated.
  ninja: build stopped: subcommand failed.

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



[Bug 1886285] Re: Provide SMB option to support Windows 2000

2021-07-05 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Provide SMB option to support Windows 2000

Status in QEMU:
  Expired

Bug description:
  As of SAMBA 4.11
  (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is
  disabled by default (and may be removed in the future). This breaks
  SMB shares with Windows 2000 guests.

  Adding the following line to smb.conf fixes this:

  min protocol = NT1

  I would propose that an option be added to add this line to smb.conf
  to support these legacy operating systems.

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



support for raspberry3/3B/4B

2021-07-05 Thread 殷冬
Hi team of qemu
I see the qemu6.0 has supported for raspberryPick 2B. but i want use it for 
raspberrypi 3/3B/4B. So can you tell me about raspberrypi 3/3B/4B plan ?


| |
殷冬
|
|
邮箱:yindongb...@126.com
|

签名由 网易邮箱大师 定制

[PATCH v3] linux-user/elfload: Implement ELF_HWCAP for RISC-V

2021-07-05 Thread Kito Cheng
Set I, M, A, F, D and C bit for hwcap if misa is set.

V3 Changes:
- Simplify logic of getting hwcap.

V2 Changes:
- Only set imafdc bits, sync with upstream linux kernel.

Signed-off-by: Kito Cheng 
---
 linux-user/elfload.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 598ab8aa13..42ef2a1148 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1434,6 +1434,19 @@ static void elf_core_copy_regs(target_elf_gregset_t 
*regs,
 #define ELF_CLASS ELFCLASS64
 #endif
 
+#define ELF_HWCAP get_elf_hwcap()
+
+static uint32_t get_elf_hwcap(void)
+{
+#define MISA_BIT(EXT) (1 << (EXT - 'A'))
+RISCVCPU *cpu = RISCV_CPU(thread_cpu);
+uint32_t mask = MISA_BIT('I') | MISA_BIT('M') | MISA_BIT('A')
+| MISA_BIT('F') | MISA_BIT('D') | MISA_BIT('C');
+
+return cpu->env.misa & mask;
+#undef MISA_BIT
+}
+
 static inline void init_thread(struct target_pt_regs *regs,
struct image_info *infop)
 {
-- 
2.31.1




Re: [PATCH v2] linux-user/elfload: Implement ELF_HWCAP for RISC-V

2021-07-05 Thread Richard Henderson

On 7/4/21 11:43 PM, Kito Cheng wrote:

+static uint32_t get_elf_hwcap(void)
+{
+RISCVCPU *cpu = RISCV_CPU(thread_cpu);
+uint32_t hwcap = 0;
+
+#define MISA_BIT(EXT) (1 << (EXT - 'A'))
+#define GET_EXT(EXT)   \
+do {   \
+if (cpu->env.misa & MISA_BIT(EXT)) {\
+hwcap |= MISA_BIT(EXT);\
+}  \
+} while (0)
+
+GET_EXT('I');
+GET_EXT('M');
+GET_EXT('A');
+GET_EXT('F');
+GET_EXT('D');
+GET_EXT('C');


You're not transforming the bits; there's no reason to be so around-the-bush about this. 
Just use


uint32_t mask = MISA_BIT('I') | ...
return cpu->env.misa & mask;


r~



Re: [PATCH v5 04/10] hw/intc: GICv3 ITS Command processing

2021-07-05 Thread shashi . mallela
On Mon, 2021-07-05 at 20:47 -0400, shashi.mall...@linaro.org wrote:
> On Mon, 2021-07-05 at 15:54 +0100, Peter Maydell wrote:
> > On Wed, 30 Jun 2021 at 16:32, Shashi Mallela <
> > shashi.mall...@linaro.org> wrote:
> > > Added ITS command queue handling for MAPTI,MAPI commands,handled
> > > ITS
> > > translation which triggers an LPI via INT command as well as
> > > write
> > > to GITS_TRANSLATER register,defined enum to differentiate between
> > > ITS
> > > command interrupt trigger and GITS_TRANSLATER based interrupt
> > > trigger.
> > > Each of these commands make use of other functionalities
> > > implemented to
> > > get device table entry,collection table entry or interrupt
> > > translation
> > > table entry required for their processing.
> > > 
> > > Signed-off-by: Shashi Mallela 
> > > ---
> > > +static MemTxResult process_mapti(GICv3ITSState *s, uint64_t
> > > value,
> > > + uint32_t offset, bool
> > > ignore_pInt)
> > > +{
> > > +AddressSpace *as = &s->gicv3->dma_as;
> > > +uint32_t devid, eventid;
> > > +uint32_t pIntid = 0;
> > > +uint32_t max_eventid, max_Intid;
> > > +bool dte_valid;
> > > +MemTxResult res = MEMTX_OK;
> > > +uint16_t icid = 0;
> > > +uint64_t dte = 0;
> > > +IteEntry ite;
> > > +uint32_t int_spurious = INTID_SPURIOUS;
> > > +uint64_t idbits;
> > > +
> > > +devid = ((value & DEVID_MASK) >> DEVID_SHIFT);
> > > +offset += NUM_BYTES_IN_DW;
> > > +value = address_space_ldq_le(as, s->cq.base_addr + offset,
> > > + MEMTXATTRS_UNSPECIFIED, &res);
> > > +
> > > +if (res != MEMTX_OK) {
> > > +return res;
> > > +}
> > > +
> > > +eventid = (value & EVENTID_MASK);
> > > +
> > > +if (!ignore_pInt) {
> > > +pIntid = ((value & pINTID_MASK) >> pINTID_SHIFT);
> > > +}
> > > +
> > > +offset += NUM_BYTES_IN_DW;
> > > +value = address_space_ldq_le(as, s->cq.base_addr + offset,
> > > + MEMTXATTRS_UNSPECIFIED, &res);
> > > +
> > > +if (res != MEMTX_OK) {
> > > +return res;
> > > +}
> > > +
> > > +icid = value & ICID_MASK;
> > > +
> > > +dte = get_dte(s, devid, &res);
> > > +
> > > +if (res != MEMTX_OK) {
> > > +return res;
> > > +}
> > > +dte_valid = dte & TABLE_ENTRY_VALID_MASK;
> > > +
> > > +max_eventid = (1UL << (((dte >> 1U) & SIZE_MASK) + 1));
> > > +
> > > +if (!ignore_pInt) {
> > > +idbits = MIN(FIELD_EX64(s->gicv3->cpu->gicr_propbaser,
> > > GICR_PROPBASER,
> > > +IDBITS), GICD_TYPER_IDBITS);
> > 
> > I missed this the first time around, but I don't think this is
> > right.
> > Different CPUs could have different GICR_PROPBASER values, so
> > checking
> > against just one of them is wrong. The pseudocode only tests
> > LPIOutOfRange()
> > which is documented as testing "larger than GICD_TYPER.IDbits or
> > not
> > in
> > the LPI range and not 1023". So I don't think we should be looking
> > at the GICR_PROPBASER field here.
> > 
> > More generally, "s->gicv3->cpu->something" is usually going to be
> > wrong, because it is implicitly looking at CPU 0; often either
> > there
> > should be something else telling is which CPU to use (as in
> > &s->gicv3->cpu[rdbase] where the CTE told us which redistributor),
> > or we might need to operate on all CPUs/redistributors. The only
> > exception is where we can guarantee that all the CPUs are the same
> > (eg when looking at GICR_TYPER.PLPIS.)
> In that case,the validation of IDBITS(in case of ITS enabled) could
> be
> done during the write of gicr_propbaser register value itself(in
> arm_gicv3_redist.c) and the its command processing code here can just
> extract the idbits for its use.
> > thanks
> > -- PMM
Hi Peter

Please ignore my last comment.

To address this scenario,i think the feasible option would be to call
get_cte() to get the rdbase corresponding to icid value passed to mapti
command.Since each icid is mapped to a rdbase(by virtue of calling MAPC
command),if the collection table has a valid mapping for this icid we
continue processing this MAPTI command using &s->gicv3->cpu[rdbase]
applicable propbaser value to validate idbits, else return without
further processing.

Thanks
Shashi  




Re: [PATCH] migration: failover: reset partially_hotplugged

2021-07-05 Thread Jason Wang



在 2021/6/29 下午11:29, Laurent Vivier 写道:

When the card is plugged back, reset the partially_hotplugged flag to false

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1787194
Signed-off-by: Laurent Vivier 
---
  hw/net/virtio-net.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index bd7958b9f0ee..16d20cdee52a 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3234,6 +3234,7 @@ static bool failover_replug_primary(VirtIONet *n, 
DeviceState *dev,
  }
  hotplug_handler_plug(hotplug_ctrl, dev, &err);
  }
+pdev->partially_hotplugged = false;
  
  out:

  error_propagate(errp, err);



Acked-by: Jason Wang 





Re: [PATCH v4 2/3] target/ppc: change ppc_hash32_xlate to use mmu_idx

2021-07-05 Thread David Gibson
On Mon, Jul 05, 2021 at 11:31:13AM -0300, Bruno Piazera Larsen wrote:
> 
> On 05/07/2021 01:24, David Gibson wrote:
> 
> > > Changed hash32 address translation to use the supplied mmu_idx, instead
> > > of using what was stored in the msr, for parity purposes (radix64
> > > already uses that).
> 
> > Well.. parity and conceptual correctness.  The translation is supposed
> > to use mmu_idx, not look at the CPU again to get the right context.
> > AFAIK there isn't a situation in hash32 where they'll get out of sync,
> > but nothing guarantees that.
> 
> 
> Fair point, I can change the description if I do end up with a new
> version, but
> 
> > I think the right approach is to duplicate the helper macros in
> > mmu-hash32.h for now.  We can unify them later with a more thorough
> > review (which would probably involve creating a new header for things
> > common to all BookS family MMUs).
> 
> This doesn't work directly. I'd need to put in an ifndef
> PPC_MMU_BOOK3S_V3_H, which also feels a bit dubious to me. I can go
> with whichever one you prefer

Ah... good point, because both headers are included in some places.

Ok, in that case let's jump ahead instead.  Let's create a new
mmu-books.h to cover all MMUs based on the "classic" powerpc model,
and put them in there.  hash32 and book3s-v3 can include that, BookE,
4xx etc. will not.

For now these will be the only things in there, but there will
probably be more we can add later on.

-- 
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: [PATCH v2] Set icon for QEMU binary on Mac OS

2021-07-05 Thread Programmingkid



> On Jul 5, 2021, at 4:07 PM, Paolo Bonzini  wrote:
> 
> Well, you're not using $ICON at all but I can clean that up myself. Thanks 
> for testing.
> 
> Paolo
> 

Please send me the cleaned up patch for testing once you complete it. Thank you.


> Il lun 5 lug 2021, 21:53 John Arbuckle  ha scritto:
> Signed-off-by: John Arbuckle 
> ---
> v1 changes:
> Rewrote the patch as the maintainer had wanted.
> 
>  meson.build| 15 ++-
>  scripts/entitlement.sh | 10 +-
>  2 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index db6789af9c..499ab49981 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -2360,8 +2360,7 @@ foreach target : target_dirs
>endif
>foreach exe: execs
>  exe_name = exe['name']
> -exe_sign = 'CONFIG_HVF' in config_target
> -if exe_sign
> +if targetos == 'darwin'
>exe_name += '-unsigned'
>  endif
> 
> @@ -2375,7 +2374,13 @@ foreach target : target_dirs
> link_args: link_args,
> gui_app: exe['gui'])
> 
> -if exe_sign
> +if 'CONFIG_HVF' in config_target
> +  entitlements = meson.current_source_dir() / 
> 'accel/hvf/entitlements.plist'
> +else
> +  entitlements = '/dev/null'
> +endif
> +if targetos == 'darwin'
> +  icon = '...'
>emulators += {exe['name'] : custom_target(exe['name'],
> depends: emulator,
> output: exe['name'],
> @@ -2383,14 +2388,14 @@ foreach target : target_dirs
>   meson.current_source_dir() / 'scripts/entitlement.sh',
>   meson.current_build_dir() / exe_name,
>   meson.current_build_dir() / exe['name'],
> - meson.current_source_dir() / 
> 'accel/hvf/entitlements.plist'
> + entitlements, icon
> ])
>}
> 
>meson.add_install_script('scripts/entitlement.sh', '--install',
> get_option('bindir') / exe_name,
> get_option('bindir') / exe['name'],
> -   meson.current_source_dir() / 
> 'accel/hvf/entitlements.plist')
> +   entitlements, icon)
>  else
>emulators += {exe['name']: emulator}
>  endif
> diff --git a/scripts/entitlement.sh b/scripts/entitlement.sh
> index f7aaaf2766..46e378426b 100755
> --- a/scripts/entitlement.sh
> +++ b/scripts/entitlement.sh
> @@ -11,6 +11,7 @@ fi
>  SRC="$1"
>  DST="$2"
>  ENTITLEMENT="$3"
> +ICON="$4"
> 
>  if $in_place; then
>trap 'rm "$DST.tmp"' exit
> @@ -20,6 +21,13 @@ else
>cd "$MESON_INSTALL_DESTDIR_PREFIX"
>  fi
> 
> -codesign --entitlements "$ENTITLEMENT" --force -s - "$SRC"
> +if test "$ENTITLEMENT" != '/dev/null'; then
> +  codesign --entitlements "$ENTITLEMENT" --force -s - "$SRC"
> +fi
> +
> +# Add the QEMU icon to the binary on Mac OS
> +Rez -append '../pc-bios/qemu.rsrc' -o "$SRC"
> +SetFile -a C "$SRC"
> +
>  mv -f "$SRC" "$DST"
>  trap '' exit
> -- 
> 2.24.3 (Apple Git-128)
> 




Re: [PATCH v5 04/10] hw/intc: GICv3 ITS Command processing

2021-07-05 Thread shashi . mallela
On Mon, 2021-07-05 at 15:54 +0100, Peter Maydell wrote:
> On Wed, 30 Jun 2021 at 16:32, Shashi Mallela <
> shashi.mall...@linaro.org> wrote:
> > Added ITS command queue handling for MAPTI,MAPI commands,handled
> > ITS
> > translation which triggers an LPI via INT command as well as write
> > to GITS_TRANSLATER register,defined enum to differentiate between
> > ITS
> > command interrupt trigger and GITS_TRANSLATER based interrupt
> > trigger.
> > Each of these commands make use of other functionalities
> > implemented to
> > get device table entry,collection table entry or interrupt
> > translation
> > table entry required for their processing.
> > 
> > Signed-off-by: Shashi Mallela 
> > ---
> > +static MemTxResult process_mapti(GICv3ITSState *s, uint64_t value,
> > + uint32_t offset, bool
> > ignore_pInt)
> > +{
> > +AddressSpace *as = &s->gicv3->dma_as;
> > +uint32_t devid, eventid;
> > +uint32_t pIntid = 0;
> > +uint32_t max_eventid, max_Intid;
> > +bool dte_valid;
> > +MemTxResult res = MEMTX_OK;
> > +uint16_t icid = 0;
> > +uint64_t dte = 0;
> > +IteEntry ite;
> > +uint32_t int_spurious = INTID_SPURIOUS;
> > +uint64_t idbits;
> > +
> > +devid = ((value & DEVID_MASK) >> DEVID_SHIFT);
> > +offset += NUM_BYTES_IN_DW;
> > +value = address_space_ldq_le(as, s->cq.base_addr + offset,
> > + MEMTXATTRS_UNSPECIFIED, &res);
> > +
> > +if (res != MEMTX_OK) {
> > +return res;
> > +}
> > +
> > +eventid = (value & EVENTID_MASK);
> > +
> > +if (!ignore_pInt) {
> > +pIntid = ((value & pINTID_MASK) >> pINTID_SHIFT);
> > +}
> > +
> > +offset += NUM_BYTES_IN_DW;
> > +value = address_space_ldq_le(as, s->cq.base_addr + offset,
> > + MEMTXATTRS_UNSPECIFIED, &res);
> > +
> > +if (res != MEMTX_OK) {
> > +return res;
> > +}
> > +
> > +icid = value & ICID_MASK;
> > +
> > +dte = get_dte(s, devid, &res);
> > +
> > +if (res != MEMTX_OK) {
> > +return res;
> > +}
> > +dte_valid = dte & TABLE_ENTRY_VALID_MASK;
> > +
> > +max_eventid = (1UL << (((dte >> 1U) & SIZE_MASK) + 1));
> > +
> > +if (!ignore_pInt) {
> > +idbits = MIN(FIELD_EX64(s->gicv3->cpu->gicr_propbaser,
> > GICR_PROPBASER,
> > +IDBITS), GICD_TYPER_IDBITS);
> 
> I missed this the first time around, but I don't think this is right.
> Different CPUs could have different GICR_PROPBASER values, so
> checking
> against just one of them is wrong. The pseudocode only tests
> LPIOutOfRange()
> which is documented as testing "larger than GICD_TYPER.IDbits or not
> in
> the LPI range and not 1023". So I don't think we should be looking
> at the GICR_PROPBASER field here.
> 
> More generally, "s->gicv3->cpu->something" is usually going to be
> wrong, because it is implicitly looking at CPU 0; often either there
> should be something else telling is which CPU to use (as in
> &s->gicv3->cpu[rdbase] where the CTE told us which redistributor),
> or we might need to operate on all CPUs/redistributors. The only
> exception is where we can guarantee that all the CPUs are the same
> (eg when looking at GICR_TYPER.PLPIS.)
In that case,the validation of IDBITS(in case of ITS enabled) could be
done during the write of gicr_propbaser register value itself(in
arm_gicv3_redist.c) and the its command processing code here can just
extract the idbits for its use.
> 
> thanks
> -- PMM




[PATCH 15/20] Hexagon HVX (target/hexagon) instruction decoding

2021-07-05 Thread Taylor Simpson
Add new file to target/hexagon/meson.build

Signed-off-by: Taylor Simpson 
---
 target/hexagon/mmvec/decode_ext_mmvec.h |  24 
 target/hexagon/decode.c |  24 +++-
 target/hexagon/mmvec/decode_ext_mmvec.c | 235 
 target/hexagon/meson.build  |   1 +
 4 files changed, 282 insertions(+), 2 deletions(-)
 create mode 100644 target/hexagon/mmvec/decode_ext_mmvec.h
 create mode 100644 target/hexagon/mmvec/decode_ext_mmvec.c

diff --git a/target/hexagon/mmvec/decode_ext_mmvec.h 
b/target/hexagon/mmvec/decode_ext_mmvec.h
new file mode 100644
index 000..3664b68
--- /dev/null
+++ b/target/hexagon/mmvec/decode_ext_mmvec.h
@@ -0,0 +1,24 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see .
+ */
+
+#ifndef HEXAGON_DECODE_EXT_MMVEC_H
+#define HEXAGON_DECODE_EXT_MMVEC_H
+
+void mmvec_ext_decode_checks(Packet *pkt, bool disas_only);
+SlotMask mmvec_ext_decode_find_iclass_slots(int opcode);
+
+#endif
diff --git a/target/hexagon/decode.c b/target/hexagon/decode.c
index d424245..653bfd7 100644
--- a/target/hexagon/decode.c
+++ b/target/hexagon/decode.c
@@ -22,6 +22,7 @@
 #include "decode.h"
 #include "insn.h"
 #include "printinsn.h"
+#include "mmvec/decode_ext_mmvec.h"
 
 #define fZXTN(N, M, VAL) ((VAL) & ((1LL << (N)) - 1))
 
@@ -566,8 +567,12 @@ static void decode_remove_extenders(Packet *packet)
 
 static SlotMask get_valid_slots(const Packet *pkt, unsigned int slot)
 {
-return find_iclass_slots(pkt->insn[slot].opcode,
- pkt->insn[slot].iclass);
+if (GET_ATTRIB(pkt->insn[slot].opcode, A_EXTENSION)) {
+return mmvec_ext_decode_find_iclass_slots(pkt->insn[slot].opcode);
+} else {
+return find_iclass_slots(pkt->insn[slot].opcode,
+ pkt->insn[slot].iclass);
+}
 }
 
 #define DECODE_NEW_TABLE(TAG, SIZE, WHATNOT) /* NOTHING */
@@ -728,6 +733,11 @@ decode_insns_tablewalk(Insn *insn, const DectreeTable 
*table,
 }
 decode_op(insn, opc, encoding);
 return 1;
+} else if (table->table[i].type == DECTREE_EXTSPACE) {
+/*
+ * For now, HVX will be the only coproc
+ */
+return decode_insns_tablewalk(insn, ext_trees[EXT_IDX_mmvec], 
encoding);
 } else {
 return 0;
 }
@@ -874,6 +884,7 @@ int decode_packet(int max_words, const uint32_t *words, 
Packet *pkt,
 int words_read = 0;
 bool end_of_packet = false;
 int new_insns = 0;
+int i;
 uint32_t encoding32;
 
 /* Initialize */
@@ -901,6 +912,11 @@ int decode_packet(int max_words, const uint32_t *words, 
Packet *pkt,
 return 0;
 }
 pkt->encod_pkt_size_in_bytes = words_read * 4;
+pkt->pkt_has_hvx = false;
+for (i = 0; i < num_insns; i++) {
+pkt->pkt_has_hvx |=
+GET_ATTRIB(pkt->insn[i].opcode, A_CVI);
+}
 
 /*
  * Check for :endloop in the parse bits
@@ -931,6 +947,10 @@ int decode_packet(int max_words, const uint32_t *words, 
Packet *pkt,
 decode_set_slot_number(pkt);
 decode_fill_newvalue_regno(pkt);
 
+if (pkt->pkt_has_hvx) {
+mmvec_ext_decode_checks(pkt, disas_only);
+}
+
 if (!disas_only) {
 decode_shuffle_for_execution(pkt);
 decode_split_cmpjump(pkt);
diff --git a/target/hexagon/mmvec/decode_ext_mmvec.c 
b/target/hexagon/mmvec/decode_ext_mmvec.c
new file mode 100644
index 000..b5b1bf1
--- /dev/null
+++ b/target/hexagon/mmvec/decode_ext_mmvec.c
@@ -0,0 +1,235 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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"
+#

[PATCH 17/20] Hexagon HVX (tests/tcg/hexagon) vector_add_int test

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 tests/tcg/hexagon/vector_add_int.c | 61 ++
 tests/tcg/hexagon/Makefile.target  |  3 ++
 2 files changed, 64 insertions(+)
 create mode 100644 tests/tcg/hexagon/vector_add_int.c

diff --git a/tests/tcg/hexagon/vector_add_int.c 
b/tests/tcg/hexagon/vector_add_int.c
new file mode 100644
index 000..d6010ea
--- /dev/null
+++ b/tests/tcg/hexagon/vector_add_int.c
@@ -0,0 +1,61 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 
+
+int gA[401];
+int gB[401];
+int gC[401];
+
+void vector_add_int()
+{
+  int i;
+  for (i = 0; i < 400; i++) {
+gA[i] = gB[i] + gC[i];
+  }
+}
+
+int main()
+{
+  int error = 0;
+  int i;
+  for (i = 0; i < 400; i++) {
+gB[i] = i * 2;
+gC[i] = i * 3;
+  }
+  gA[400] = 17;
+  vector_add_int();
+  for (i = 0; i < 400; i++) {
+if (gA[i] != i * 5) {
+error++;
+printf("ERROR: gB[%d] = %d\t", i, gB[i]);
+printf("gC[%d] = %d\t", i, gC[i]);
+printf("gA[%d] = %d\n", i, gA[i]);
+}
+  }
+  if (gA[400] != 17) {
+error++;
+printf("ERROR: Overran the buffer\n");
+  }
+  if (!error) {
+printf("PASS\n");
+return 0;
+  } else {
+printf("FAIL\n");
+return 1;
+  }
+}
diff --git a/tests/tcg/hexagon/Makefile.target 
b/tests/tcg/hexagon/Makefile.target
index 0992787..88db7dd 100644
--- a/tests/tcg/hexagon/Makefile.target
+++ b/tests/tcg/hexagon/Makefile.target
@@ -46,7 +46,10 @@ HEX_TESTS += circ
 HEX_TESTS += brev
 HEX_TESTS += load_unpack
 HEX_TESTS += load_align
+HEX_TESTS += vector_add_int
 HEX_TESTS += atomics
 HEX_TESTS += fpstuff
 
 TESTS += $(HEX_TESTS)
+
+vector_add_int: CFLAGS += -mhvx -fvectorize
-- 
2.7.4



[PATCH 03/20] Hexagon HVX (target/hexagon) register names

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/hex_regs.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/hexagon/hex_regs.h b/target/hexagon/hex_regs.h
index f291911..e1b3149 100644
--- a/target/hexagon/hex_regs.h
+++ b/target/hexagon/hex_regs.h
@@ -76,6 +76,7 @@ enum {
 /* Use reserved control registers for qemu execution counts */
 HEX_REG_QEMU_PKT_CNT  = 52,
 HEX_REG_QEMU_INSN_CNT = 53,
+HEX_REG_QEMU_HVX_CNT  = 54,
 HEX_REG_UTIMERLO  = 62,
 HEX_REG_UTIMERHI  = 63,
 };
-- 
2.7.4



[PATCH 11/20] Hexagon HVX (target/hexagon) instruction utility functions

2021-07-05 Thread Taylor Simpson
Functions to support scatter/gather
Add new file to target/hexagon/meson.build

Signed-off-by: Taylor Simpson 
---
 target/hexagon/arch.h   |   1 +
 target/hexagon/mmvec/system_ext_mmvec.h |  35 ++
 target/hexagon/arch.c   |   9 +++
 target/hexagon/mmvec/system_ext_mmvec.c | 119 
 target/hexagon/meson.build  |   1 +
 5 files changed, 165 insertions(+)
 create mode 100644 target/hexagon/mmvec/system_ext_mmvec.h
 create mode 100644 target/hexagon/mmvec/system_ext_mmvec.c

diff --git a/target/hexagon/arch.h b/target/hexagon/arch.h
index 7091806..133cb6d 100644
--- a/target/hexagon/arch.h
+++ b/target/hexagon/arch.h
@@ -24,6 +24,7 @@ extern const uint8_t rLPS_table_64x4[64][4];
 extern const uint8_t AC_next_state_MPS_64[64];
 extern const uint8_t AC_next_state_LPS_64[64];
 
+uint32_t count_leading_ones_2(uint16_t src);
 uint64_t interleave(uint32_t odd, uint32_t even);
 uint64_t deinterleave(uint64_t src);
 int32_t conv_round(int32_t a, int n);
diff --git a/target/hexagon/mmvec/system_ext_mmvec.h 
b/target/hexagon/mmvec/system_ext_mmvec.h
new file mode 100644
index 000..d103191
--- /dev/null
+++ b/target/hexagon/mmvec/system_ext_mmvec.h
@@ -0,0 +1,35 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see .
+ */
+
+#ifndef HEXAGON_SYSTEM_EXT_MMVEC_H
+#define HEXAGON_SYSTEM_EXT_MMVEC_H
+
+void mem_load_vector(CPUHexagonState *env, target_ulong vaddr,
+ int size, uint8_t *data);
+void mem_gather_store(CPUHexagonState *env, target_ulong vaddr,
+  int slot, uint8_t *data);
+void mem_store_vector(CPUHexagonState *env, target_ulong vaddr,
+  int slot, int size,
+  uint8_t *data, uint8_t *mask, bool invert);
+void mem_vector_scatter_init(CPUHexagonState *env, int slot,
+ target_ulong base_vaddr, int length,
+ int element_size);
+void mem_vector_gather_init(CPUHexagonState *env, int slot,
+target_ulong base_vaddr, int length,
+int element_size);
+
+#endif
diff --git a/target/hexagon/arch.c b/target/hexagon/arch.c
index 68a55b3..b2ff905 100644
--- a/target/hexagon/arch.c
+++ b/target/hexagon/arch.c
@@ -118,6 +118,15 @@ const uint8_t AC_next_state_LPS_64[64] = {
 37, 38, 38, 63
 };
 
+uint32_t count_leading_ones_2(uint16_t src)
+{
+int ret;
+for (ret = 0; src & 0x8000; src <<= 1) {
+ret++;
+}
+return ret;
+}
+
 #define BITS_MASK_8 0xULL
 #define PAIR_MASK_8 0xULL
 #define NYBL_MASK_8 0x0f0f0f0f0f0f0f0fULL
diff --git a/target/hexagon/mmvec/system_ext_mmvec.c 
b/target/hexagon/mmvec/system_ext_mmvec.c
new file mode 100644
index 000..fbd7505
--- /dev/null
+++ b/target/hexagon/mmvec/system_ext_mmvec.c
@@ -0,0 +1,119 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu.h"
+#include "cpu.h"
+#include "mmvec/system_ext_mmvec.h"
+
+void mem_gather_store(CPUHexagonState *env, target_ulong vaddr,
+  int slot, uint8_t *data)
+{
+size_t size = sizeof(MMVector);
+
+/*
+ * If it's a gather store update store data from temporary register
+ * and clear flag
+ */
+memcpy(data, &env->tmp_VRegs[0].ub[0], size);
+env->VRegs_updated_tmp = 0;
+env->gather_issued = false;
+
+env->vstore_pending[slot] = 1;
+env->vstore[slot].va   = vaddr;
+env->vstore[slot].size = size;
+memcpy(&env->vstore[slot].data.ub[0], 

[PATCH 13/20] Hexagon HVX (target/hexagon) TCG generation

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/translate.h |  54 
 target/hexagon/genptr.c|  15 
 target/hexagon/translate.c | 199 +
 3 files changed, 268 insertions(+)

diff --git a/target/hexagon/translate.h b/target/hexagon/translate.h
index 703fd13..fe3c7c5 100644
--- a/target/hexagon/translate.h
+++ b/target/hexagon/translate.h
@@ -29,6 +29,7 @@ typedef struct DisasContext {
 uint32_t mem_idx;
 uint32_t num_packets;
 uint32_t num_insns;
+uint32_t num_hvx_insns;
 int reg_log[REG_WRITES_MAX];
 int reg_log_idx;
 DECLARE_BITMAP(regs_written, TOTAL_PER_THREAD_REGS);
@@ -37,6 +38,16 @@ typedef struct DisasContext {
 DECLARE_BITMAP(pregs_written, NUM_PREGS);
 uint8_t store_width[STORES_MAX];
 bool s1_store_processed;
+int vreg_log[NUM_VREGS];
+bool vreg_is_predicated[NUM_VREGS];
+int vreg_log_idx;
+DECLARE_BITMAP(vregs_updated_tmp, NUM_VREGS);
+DECLARE_BITMAP(vregs_updated, NUM_VREGS);
+DECLARE_BITMAP(vregs_select, NUM_VREGS);
+int qreg_log[NUM_QREGS];
+bool qreg_is_predicated[NUM_QREGS];
+int qreg_log_idx;
+bool is_gather_store_insn;
 } DisasContext;
 
 static inline void ctx_log_reg_write(DisasContext *ctx, int rnum)
@@ -67,6 +78,41 @@ static inline bool is_preloaded(DisasContext *ctx, int num)
 return test_bit(num, ctx->regs_written);
 }
 
+static inline void ctx_log_vreg_write(DisasContext *ctx,
+  int rnum, VRegWriteType type,
+  bool is_predicated)
+{
+if (type != EXT_TMP) {
+ctx->vreg_log[ctx->vreg_log_idx] = rnum;
+ctx->vreg_is_predicated[ctx->vreg_log_idx] = is_predicated;
+ctx->vreg_log_idx++;
+
+set_bit(rnum, ctx->vregs_updated);
+}
+if (type == EXT_NEW) {
+set_bit(rnum, ctx->vregs_select);
+}
+if (type == EXT_TMP) {
+set_bit(rnum, ctx->vregs_updated_tmp);
+}
+}
+
+static inline void ctx_log_vreg_write_pair(DisasContext *ctx,
+   int rnum, VRegWriteType type,
+   bool is_predicated)
+{
+ctx_log_vreg_write(ctx, rnum ^ 0, type, is_predicated);
+ctx_log_vreg_write(ctx, rnum ^ 1, type, is_predicated);
+}
+
+static inline void ctx_log_qreg_write(DisasContext *ctx,
+  int rnum, bool is_predicated)
+{
+ctx->qreg_log[ctx->qreg_log_idx] = rnum;
+ctx->qreg_is_predicated[ctx->qreg_log_idx] = is_predicated;
+ctx->qreg_log_idx++;
+}
+
 extern TCGv hex_gpr[TOTAL_PER_THREAD_REGS];
 extern TCGv hex_pred[NUM_PREGS];
 extern TCGv hex_next_PC;
@@ -85,6 +131,14 @@ extern TCGv hex_dczero_addr;
 extern TCGv hex_llsc_addr;
 extern TCGv hex_llsc_val;
 extern TCGv_i64 hex_llsc_val_i64;
+extern TCGv hex_is_gather_store_insn;
+extern TCGv hex_VRegs_updated_tmp;
+extern TCGv hex_VRegs_updated;
+extern TCGv hex_VRegs_select;
+extern TCGv hex_QRegs_updated;
+extern TCGv hex_vstore_addr[VSTORES_MAX];
+extern TCGv hex_vstore_size[VSTORES_MAX];
+extern TCGv hex_vstore_pending[VSTORES_MAX];
 
 void process_store(DisasContext *ctx, Packet *pkt, int slot_num);
 #endif
diff --git a/target/hexagon/genptr.c b/target/hexagon/genptr.c
index 7333299..da8527d 100644
--- a/target/hexagon/genptr.c
+++ b/target/hexagon/genptr.c
@@ -167,6 +167,9 @@ static inline void gen_read_ctrl_reg(DisasContext *ctx, 
const int reg_num,
 } else if (reg_num == HEX_REG_QEMU_INSN_CNT) {
 tcg_gen_addi_tl(dest, hex_gpr[HEX_REG_QEMU_INSN_CNT],
 ctx->num_insns);
+} else if (reg_num == HEX_REG_QEMU_HVX_CNT) {
+tcg_gen_addi_tl(dest, hex_gpr[HEX_REG_QEMU_HVX_CNT],
+ctx->num_hvx_insns);
 } else {
 tcg_gen_mov_tl(dest, hex_gpr[reg_num]);
 }
@@ -194,6 +197,12 @@ static inline void gen_read_ctrl_reg_pair(DisasContext 
*ctx, const int reg_num,
 tcg_gen_concat_i32_i64(dest, pkt_cnt, insn_cnt);
 tcg_temp_free(pkt_cnt);
 tcg_temp_free(insn_cnt);
+} else if (reg_num == HEX_REG_QEMU_HVX_CNT) {
+TCGv hvx_cnt = tcg_temp_new();
+tcg_gen_addi_tl(hvx_cnt, hex_gpr[HEX_REG_QEMU_HVX_CNT],
+ctx->num_hvx_insns);
+tcg_gen_concat_i32_i64(dest, hvx_cnt, hex_gpr[reg_num + 1]);
+tcg_temp_free(hvx_cnt);
 } else {
 tcg_gen_concat_i32_i64(dest,
 hex_gpr[reg_num],
@@ -229,6 +238,9 @@ static inline void gen_write_ctrl_reg(DisasContext *ctx, 
int reg_num,
 if (reg_num == HEX_REG_QEMU_INSN_CNT) {
 ctx->num_insns = 0;
 }
+if (reg_num == HEX_REG_QEMU_HVX_CNT) {
+ctx->num_hvx_insns = 0;
+}
 }
 }
 
@@ -250,6 +262,9 @@ static inline void gen_write_ctrl_reg_pair(DisasContext 
*ctx, int reg_num,
 ctx->num_packets = 0;
 ctx->num_insns = 0;
 }
+if (reg_num == HEX_REG_QEMU_HVX_CNT) {
+ 

[PATCH 18/20] Hexagon HVX (tests/tcg/hexagon) hvx_misc test

2021-07-05 Thread Taylor Simpson
Tests for
packet semantics
vector loads (aligned and unaligned)
vector stores (aligned and unaligned)
vector masked stores
vector operations

Signed-off-by: Taylor Simpson 
---
 tests/tcg/hexagon/hvx_misc.c  | 331 ++
 tests/tcg/hexagon/Makefile.target |   2 +
 2 files changed, 333 insertions(+)
 create mode 100644 tests/tcg/hexagon/hvx_misc.c

diff --git a/tests/tcg/hexagon/hvx_misc.c b/tests/tcg/hexagon/hvx_misc.c
new file mode 100644
index 000..b226134
--- /dev/null
+++ b/tests/tcg/hexagon/hvx_misc.c
@@ -0,0 +1,331 @@
+/*
+ *  Copyright(c) 2021 Qualcomm Innovation Center, Inc. All Rights Reserved.
+ *
+ *  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 
+#include 
+#include 
+
+int err;
+
+static void __check(int line, uint64_t result, uint64_t expect)
+{
+if (result != expect) {
+printf("ERROR at line %d: 0x%016llx != 0x%016llx\n",
+   line, result, expect);
+err++;
+}
+}
+
+#define check(RES, EXP) __check(__LINE__, RES, EXP)
+
+#define MAX_VEC_SIZE_BYTES 128
+
+typedef union {
+uint64_t ud[MAX_VEC_SIZE_BYTES / 8];
+int64_t   d[MAX_VEC_SIZE_BYTES / 8];
+uint32_t uw[MAX_VEC_SIZE_BYTES / 4];
+int32_t   w[MAX_VEC_SIZE_BYTES / 4];
+uint16_t uh[MAX_VEC_SIZE_BYTES / 2];
+int16_t   h[MAX_VEC_SIZE_BYTES / 2];
+uint8_t  ub[MAX_VEC_SIZE_BYTES / 1];
+int8_tb[MAX_VEC_SIZE_BYTES / 1];
+} MMVector;
+
+#define BUFSIZE  16
+#define OUTSIZE  16
+#define MASKMOD  3
+
+MMVector buffer0[BUFSIZE] __attribute__((aligned(MAX_VEC_SIZE_BYTES)));
+MMVector buffer1[BUFSIZE] __attribute__((aligned(MAX_VEC_SIZE_BYTES)));
+MMVector mask[BUFSIZE] __attribute__((aligned(MAX_VEC_SIZE_BYTES)));
+MMVector output[OUTSIZE] __attribute__((aligned(MAX_VEC_SIZE_BYTES)));
+MMVector expect[OUTSIZE] __attribute__((aligned(MAX_VEC_SIZE_BYTES)));
+
+#define CHECK_OUTPUT_FUNC(FIELD, FIELDSZ) \
+static void check_output_##FIELD(int line, size_t num_vectors) \
+{ \
+for (int i = 0; i < num_vectors; i++) { \
+for (int j = 0; j < MAX_VEC_SIZE_BYTES / FIELDSZ; j++) { \
+__check(line, output[i].FIELD[j], expect[i].FIELD[j]); \
+} \
+} \
+}
+
+CHECK_OUTPUT_FUNC(d,  8)
+CHECK_OUTPUT_FUNC(w,  4)
+CHECK_OUTPUT_FUNC(h,  2)
+CHECK_OUTPUT_FUNC(b,  1)
+
+static void init_buffers(void)
+{
+int counter0 = 0;
+int counter1 = 17;
+for (int i = 0; i < BUFSIZE; i++) {
+for (int j = 0; j < MAX_VEC_SIZE_BYTES; j++) {
+buffer0[i].b[j] = counter0++;
+buffer1[i].b[j] = counter1++;
+}
+for (int j = 0; j < MAX_VEC_SIZE_BYTES / 4; j++) {
+mask[i].w[j] = (i + j % MASKMOD == 0) ? 0 : 1;
+}
+}
+}
+
+static void test_load_tmp(void)
+{
+void *p0 = buffer0;
+void *p1 = buffer1;
+void *pout = output;
+
+for (int i = 0; i < BUFSIZE; i++) {
+/*
+ * Load into v2 as .tmp, then ues it in the next packet
+ * Should get the new value within the same packet and
+ * the old value in the next packet
+ */
+asm("v3 = vmem(%0 + #0)\n\t"
+"r1 = #1\n\t"
+"v2 = vsplat(r1)\n\t"
+"{\n\t"
+"v2.tmp = vmem(%1 + #0)\n\t"
+"v4.w = vadd(v2.w, v3.w)\n\t"
+"}\n\t"
+"v4.w = vadd(v4.w, v2.w)\n\t"
+"vmem(%2 + #0) = v4\n\t"
+: : "r"(p0), "r"(p1), "r"(pout)
+: "r1", "v2", "v3", "v4", "v6", "memory");
+p0 += sizeof(MMVector);
+p1 += sizeof(MMVector);
+pout += sizeof(MMVector);
+
+for (int j = 0; j < MAX_VEC_SIZE_BYTES / 4; j++) {
+expect[i].w[j] = buffer0[i].w[j] + buffer1[i].w[j] + 1;
+}
+}
+
+check_output_w(__LINE__, BUFSIZE);
+}
+
+static void test_load_cur(void)
+{
+void *p0 = buffer0;
+void *pout = output;
+
+for (int i = 0; i < BUFSIZE; i++) {
+asm("{\n\t"
+"v2.cur = vmem(%0 + #0)\n\t"
+"vmem(%1 + #0) = v2\n\t"
+"}\n\t"
+: : "r"(p0), "r"(pout) : "v2", "memory");
+p0 += sizeof(MMVector);
+pout += sizeof(MMVector);
+
+for (int j = 0; j < MAX_VEC_SIZE_BYTES / 4; j++) {
+expect[i].uw[j] = buffer0[i].uw[j];
+}
+}
+
+check_output_w(__LINE__, BUFSIZE);

[PATCH 02/20] Hexagon HVX (target/hexagon) add Hexagon Vector eXtensions (HVX) to core

2021-07-05 Thread Taylor Simpson
HVX is a set of wide vector instructions.  Machine state includes
vector registers (VRegs)
vector predicate registers (QRegs)
temporary registers for intermediate values
store buffer (masked stores and scatter/gather)

Signed-off-by: Taylor Simpson 
---
 target/hexagon/cpu.h| 35 -
 target/hexagon/hex_arch_types.h |  5 +++
 target/hexagon/insn.h   |  3 ++
 target/hexagon/internal.h   |  3 ++
 target/hexagon/mmvec/mmvec.h| 83 +
 target/hexagon/cpu.c| 72 ++-
 6 files changed, 198 insertions(+), 3 deletions(-)
 create mode 100644 target/hexagon/mmvec/mmvec.h

diff --git a/target/hexagon/cpu.h b/target/hexagon/cpu.h
index 2855dd3..0b377c3 100644
--- a/target/hexagon/cpu.h
+++ b/target/hexagon/cpu.h
@@ -26,6 +26,7 @@ typedef struct CPUHexagonState CPUHexagonState;
 #include "qemu-common.h"
 #include "exec/cpu-defs.h"
 #include "hex_regs.h"
+#include "mmvec/mmvec.h"
 
 #define NUM_PREGS 4
 #define TOTAL_PER_THREAD_REGS 64
@@ -34,6 +35,7 @@ typedef struct CPUHexagonState CPUHexagonState;
 #define STORES_MAX 2
 #define REG_WRITES_MAX 32
 #define PRED_WRITES_MAX 5   /* 4 insns + endloop */
+#define VSTORES_MAX 2
 
 #define TYPE_HEXAGON_CPU "hexagon-cpu"
 
@@ -52,6 +54,13 @@ typedef struct {
 uint64_t data64;
 } MemLog;
 
+typedef struct {
+target_ulong va;
+int size;
+MMVector mask QEMU_ALIGNED(16);
+MMVector data QEMU_ALIGNED(16);
+} VStoreLog;
+
 #define EXEC_STATUS_OK  0x
 #define EXEC_STATUS_STOP0x0002
 #define EXEC_STATUS_REPLAY  0x0010
@@ -98,7 +107,31 @@ struct CPUHexagonState {
 uint64_t llsc_val_i64;
 
 target_ulong is_gather_store_insn;
-target_ulong gather_issued;
+bool gather_issued;
+
+MMVector VRegs[NUM_VREGS] QEMU_ALIGNED(16);
+MMVector future_VRegs[NUM_VREGS] QEMU_ALIGNED(16);
+MMVector tmp_VRegs[NUM_VREGS] QEMU_ALIGNED(16);
+
+VRegMask VRegs_updated_tmp;
+VRegMask VRegs_updated;
+VRegMask VRegs_select;
+
+MMQReg QRegs[NUM_QREGS] QEMU_ALIGNED(16);
+MMQReg future_QRegs[NUM_QREGS] QEMU_ALIGNED(16);
+QRegMask QRegs_updated;
+
+/* Temporaries used within instructions */
+MMVector zero_vector QEMU_ALIGNED(16);
+MMVectorPair VddV QEMU_ALIGNED(16),
+ VuuV QEMU_ALIGNED(16),
+ VvvV QEMU_ALIGNED(16),
+ VxxV QEMU_ALIGNED(16);
+
+VStoreLog vstore[VSTORES_MAX];
+target_ulong vstore_pending[VSTORES_MAX];
+bool vtcm_pending;
+VTCMStoreLog vtcm_log;
 };
 
 #define HEXAGON_CPU_CLASS(klass) \
diff --git a/target/hexagon/hex_arch_types.h b/target/hexagon/hex_arch_types.h
index d721e1f..78ad607 100644
--- a/target/hexagon/hex_arch_types.h
+++ b/target/hexagon/hex_arch_types.h
@@ -19,6 +19,7 @@
 #define HEXAGON_ARCH_TYPES_H
 
 #include "qemu/osdep.h"
+#include "mmvec/mmvec.h"
 #include "qemu/int128.h"
 
 /*
@@ -35,4 +36,8 @@ typedef uint64_tsize8u_t;
 typedef int64_t size8s_t;
 typedef Int128  size16s_t;
 
+typedef MMVector  mmvector_t;
+typedef MMVectorPair  mmvector_pair_t;
+typedef MMQRegmmqret_t;
+
 #endif
diff --git a/target/hexagon/insn.h b/target/hexagon/insn.h
index 2e34591..3872f90 100644
--- a/target/hexagon/insn.h
+++ b/target/hexagon/insn.h
@@ -67,6 +67,9 @@ struct Packet {
 bool pkt_has_store_s0;
 bool pkt_has_store_s1;
 
+bool pkt_has_hvx;
+bool pkt_has_vhist;
+
 Insn insn[INSTRUCTIONS_MAX];
 };
 
diff --git a/target/hexagon/internal.h b/target/hexagon/internal.h
index 6b20aff..82ac304 100644
--- a/target/hexagon/internal.h
+++ b/target/hexagon/internal.h
@@ -31,6 +31,9 @@
 
 int hexagon_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
 int hexagon_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
+
+void hexagon_debug_vreg(CPUHexagonState *env, int regnum);
+void hexagon_debug_qreg(CPUHexagonState *env, int regnum);
 void hexagon_debug(CPUHexagonState *env);
 
 extern const char * const hexagon_regnames[TOTAL_PER_THREAD_REGS];
diff --git a/target/hexagon/mmvec/mmvec.h b/target/hexagon/mmvec/mmvec.h
new file mode 100644
index 000..061ccce
--- /dev/null
+++ b/target/hexagon/mmvec/mmvec.h
@@ -0,0 +1,83 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 progr

[PATCH 10/20] Hexagon HVX (target/hexagon) C preprocessor for decode tree

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/gen_dectree_import.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/target/hexagon/gen_dectree_import.c 
b/target/hexagon/gen_dectree_import.c
index 5b7ecfc..2374030 100644
--- a/target/hexagon/gen_dectree_import.c
+++ b/target/hexagon/gen_dectree_import.c
@@ -40,6 +40,11 @@ const char * const opcode_names[] = {
  * Q6INSN(A2_add,"Rd32=add(Rs32,Rt32)",ATTRIBS(),
  * "Add 32-bit registers",
  * { RdV=RsV+RtV;})
+ * HVX instructions have the following form
+ * EXTINSN(V6_vinsertwr, "Vx32.w=vinsert(Rt32)",
+ * ATTRIBS(A_EXTENSION,A_CVI,A_CVI_VX,A_CVI_LATE),
+ * "Insert Word Scalar into Vector",
+ * VxV.uw[0] = RtV;)
  */
 const char * const opcode_syntax[XX_LAST_OPCODE] = {
 #define Q6INSN(TAG, BEH, ATTRIBS, DESCR, SEM) \
@@ -105,6 +110,14 @@ static const char *get_opcode_enc(int opcode)
 
 static const char *get_opcode_enc_class(int opcode)
 {
+const char *tmp = opcode_encodings[opcode].encoding;
+if (tmp == NULL) {
+const char *test = "V6_";/* HVX */
+char *name = (char *)opcode_names[opcode];
+if (strncmp(name, test, strlen(test)) == 0) {
+return "EXT_mmvec";
+}
+}
 return opcode_enc_class_names[opcode_encodings[opcode].enc_class];
 }
 
-- 
2.7.4



[PATCH 20/20] Hexagon HVX (tests/tcg/hexagon) histogram test

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 tests/tcg/hexagon/hvx_histogram_input.h | 717 
 tests/tcg/hexagon/hvx_histogram_row.h   |  24 ++
 tests/tcg/hexagon/hvx_histogram.c   |  88 
 tests/tcg/hexagon/Makefile.target   |   5 +
 tests/tcg/hexagon/hvx_histogram_row.S   | 294 +
 5 files changed, 1128 insertions(+)
 create mode 100644 tests/tcg/hexagon/hvx_histogram_input.h
 create mode 100644 tests/tcg/hexagon/hvx_histogram_row.h
 create mode 100644 tests/tcg/hexagon/hvx_histogram.c
 create mode 100644 tests/tcg/hexagon/hvx_histogram_row.S

diff --git a/tests/tcg/hexagon/hvx_histogram_input.h 
b/tests/tcg/hexagon/hvx_histogram_input.h
new file mode 100644
index 000..2f91092
--- /dev/null
+++ b/tests/tcg/hexagon/hvx_histogram_input.h
@@ -0,0 +1,717 @@
+/*
+ *  Copyright(c) 2021 Qualcomm Innovation Center, Inc. All Rights Reserved.
+ *
+ *  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 .
+ */
+
+{ 0x26, 0x32, 0x2e, 0x2e, 0x2d, 0x2c, 0x2d, 0x2d,
+  0x2c, 0x2e, 0x31, 0x33, 0x36, 0x39, 0x3b, 0x3f,
+  0x42, 0x46, 0x4a, 0x4c, 0x51, 0x53, 0x53, 0x54,
+  0x56, 0x57, 0x58, 0x57, 0x56, 0x52, 0x51, 0x4f,
+  0x4c, 0x49, 0x47, 0x42, 0x3e, 0x3b, 0x38, 0x35,
+  0x33, 0x30, 0x2e, 0x2c, 0x2b, 0x2a, 0x2a, 0x28,
+  0x28, 0x27, 0x27, 0x28, 0x29, 0x2a, 0x2c, 0x2e,
+  0x2f, 0x33, 0x36, 0x38, 0x3c, 0x3d, 0x40, 0x42,
+  0x43, 0x42, 0x43, 0x44, 0x43, 0x41, 0x40, 0x3b,
+  0x3b, 0x3a, 0x38, 0x35, 0x32, 0x2f, 0x2c, 0x29,
+  0x27, 0x26, 0x23, 0x21, 0x1e, 0x1c, 0x1a, 0x19,
+  0x17, 0x15, 0x15, 0x14, 0x13, 0x12, 0x11, 0x10,
+  0x0f, 0x0e, 0x0f, 0x0f, 0x0e, 0x0d, 0x0d, 0x0d,
+  0x0c, 0x0d, 0x0e, 0x0c, 0x0c, 0x0c, 0x0c, 0x0c,
+  0x0c, 0x0c, 0x0d, 0x0c, 0x0f, 0x0e, 0x0f, 0x0f,
+  0x0f, 0x10, 0x11, 0x12, 0x14, 0x16, 0x17, 0x19,
+  0x1c, 0x1d, 0x21, 0x25, 0x27, 0x29, 0x2b, 0x2f,
+  0x31, 0x33, 0x36, 0x38, 0x39, 0x3a, 0x3b, 0x3c,
+  0x3c, 0x3d, 0x3e, 0x3e, 0x3c, 0x3b, 0x3a, 0x39,
+  0x39, 0x3a, 0x3a, 0x3a, 0x3a, 0x3c, 0x3e, 0x43,
+  0x47, 0x4a, 0x4d, 0x51, 0x51, 0x54, 0x56, 0x56,
+  0x57, 0x56, 0x53, 0x4f, 0x4b, 0x47, 0x43, 0x41,
+  0x3e, 0x3c, 0x3a, 0x37, 0x36, 0x33, 0x32, 0x34,
+  0x34, 0x34, 0x34, 0x35, 0x36, 0x39, 0x3d, 0x3d,
+  0x3f, 0x40, 0x40, 0x40, 0x40, 0x3e, 0x40, 0x40,
+  0x42, 0x44, 0x47, 0x48, 0x4b, 0x4e, 0x56, 0x5c,
+  0x62, 0x68, 0x6f, 0x73, 0x76, 0x79, 0x7a, 0x7c,
+  0x7e, 0x7c, 0x78, 0x72, 0x6e, 0x69, 0x65, 0x60,
+  0x5b, 0x56, 0x52, 0x4d, 0x4a, 0x48, 0x47, 0x46,
+  0x44, 0x43, 0x42, 0x41, 0x41, 0x41, 0x40, 0x40,
+  0x3f, 0x3e, 0x3d, 0x3c, 0x3b, 0x3b, 0x38, 0x37,
+  0x36, 0x35, 0x36, 0x35, 0x36, 0x37, 0x38, 0x3c,
+  0x3d, 0x3f, 0x42, 0x44, 0x46, 0x48, 0x4b, 0x4c,
+  0x4e, 0x4e, 0x4d, 0x4c, 0x4a, 0x48, 0x49, 0x49,
+  0x4b, 0x4d, 0x4e, },
+{ 0x23, 0x2d, 0x29, 0x29, 0x28, 0x28, 0x29, 0x29,
+  0x28, 0x2b, 0x2d, 0x2f, 0x32, 0x34, 0x36, 0x3a,
+  0x3d, 0x41, 0x44, 0x47, 0x4a, 0x4c, 0x4e, 0x4e,
+  0x50, 0x51, 0x51, 0x51, 0x4f, 0x4c, 0x4b, 0x48,
+  0x46, 0x44, 0x40, 0x3d, 0x39, 0x36, 0x34, 0x30,
+  0x2f, 0x2d, 0x2a, 0x29, 0x28, 0x27, 0x26, 0x25,
+  0x25, 0x24, 0x24, 0x24, 0x26, 0x28, 0x28, 0x2a,
+  0x2b, 0x2e, 0x32, 0x34, 0x37, 0x39, 0x3b, 0x3c,
+  0x3d, 0x3d, 0x3e, 0x3e, 0x3e, 0x3c, 0x3b, 0x38,
+  0x37, 0x35, 0x33, 0x30, 0x2e, 0x2b, 0x27, 0x25,
+  0x24, 0x21, 0x20, 0x1d, 0x1b, 0x1a, 0x18, 0x16,
+  0x15, 0x14, 0x13, 0x12, 0x10, 0x11, 0x10, 0x0e,
+  0x0e, 0x0d, 0x0d, 0x0d, 0x0d, 0x0c, 0x0c, 0x0b,
+  0x0b, 0x0b, 0x0c, 0x0b, 0x0b, 0x09, 0x0a, 0x0b,
+  0x0b, 0x0a, 0x0a, 0x0c, 0x0c, 0x0c, 0x0d, 0x0e,
+  0x0e, 0x0f, 0x0f, 0x11, 0x12, 0x15, 0x15, 0x17,
+  0x1a, 0x1c, 0x1f, 0x22, 0x25, 0x26, 0x29, 0x2a,
+  0x2d, 0x30, 0x33, 0x34, 0x35, 0x35, 0x37, 0x37,
+  0x39, 0x3a, 0x39, 0x38, 0x37, 0x36, 0x36, 0x37,
+  0x35, 0x36, 0x35, 0x35, 0x36, 0x37, 0x3a, 0x3e,
+  0x40, 0x43, 0x48, 0x49, 0x4b, 0x4c, 0x4d, 0x4e,
+  0x4f, 0x4f, 0x4c, 0x48, 0x45, 0x41, 0x3e, 0x3b,
+  0x3a, 0x37, 0x36, 0x33, 0x32, 0x31, 0x30, 0x31,
+  0x32, 0x31, 0x31, 0x31, 0x31, 0x34, 0x37, 0x38,
+  0x3a, 0x3b, 0x3b, 0x3b, 0x3c, 0x3b, 0x3d, 0x3e,
+  0x3f, 0x40, 0x43, 0x44, 0x47, 0x4b, 0x4f, 0x56,
+  0x5a, 0x60, 0x66, 0x69, 0x6a, 0x6e, 0x71, 0x72,
+  0x73, 0x72, 0x6d, 0x69, 0x66, 0x60, 0

[PATCH 04/20] Hexagon HVX (target/hexagon) support in gdbstub

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/gdbstub.c | 66 
 1 file changed, 66 insertions(+)

diff --git a/target/hexagon/gdbstub.c b/target/hexagon/gdbstub.c
index 9c8c04c..b804e97 100644
--- a/target/hexagon/gdbstub.c
+++ b/target/hexagon/gdbstub.c
@@ -21,6 +21,30 @@
 #include "cpu.h"
 #include "internal.h"
 
+static int gdb_get_vreg(CPUHexagonState *env, GByteArray *mem_buf, int n)
+{
+int total = 0;
+int i;
+for (i = 0; i < MAX_VEC_SIZE_BYTES / sizeof(uint32_t); i++) {
+total += gdb_get_regl(mem_buf, env->VRegs[n].uw[i]);
+mem_buf += sizeof(uint32_t);
+}
+return total;
+}
+
+static int gdb_get_qreg(CPUHexagonState *env, GByteArray *mem_buf, int n)
+{
+int total = 0;
+int i;
+for (i = 0;
+ i < MAX_VEC_SIZE_BYTES / sizeof(uint32_t) / BITS_PER_BYTE;
+ i++) {
+total += gdb_get_regl(mem_buf, env->QRegs[n].uw[i]);
+mem_buf += sizeof(uint32_t);
+}
+return total;
+}
+
 int hexagon_gdb_read_register(CPUState *cs, GByteArray *mem_buf, int n)
 {
 HexagonCPU *cpu = HEXAGON_CPU(cs);
@@ -29,10 +53,42 @@ int hexagon_gdb_read_register(CPUState *cs, GByteArray 
*mem_buf, int n)
 if (n < TOTAL_PER_THREAD_REGS) {
 return gdb_get_regl(mem_buf, env->gpr[n]);
 }
+n -= TOTAL_PER_THREAD_REGS;
+
+if (n < NUM_VREGS) {
+return gdb_get_vreg(env, mem_buf, n);
+}
+n -= NUM_VREGS;
+
+if (n < NUM_QREGS) {
+return gdb_get_qreg(env, mem_buf, n);
+}
 
 g_assert_not_reached();
 }
 
+static int gdb_put_vreg(CPUHexagonState *env, uint8_t *mem_buf, int n)
+{
+int i;
+for (i = 0; i < MAX_VEC_SIZE_BYTES / sizeof(uint32_t); i++) {
+env->VRegs[n].uw[i] = ldtul_p(mem_buf);
+mem_buf += sizeof(uint32_t);
+}
+return MAX_VEC_SIZE_BYTES;
+}
+
+static int gdb_put_qreg(CPUHexagonState *env, uint8_t *mem_buf, int n)
+{
+int i;
+for (i = 0;
+ i < MAX_VEC_SIZE_BYTES / sizeof(uint32_t) / BITS_PER_BYTE;
+ i++) {
+env->QRegs[n].uw[i] = ldtul_p(mem_buf);
+mem_buf += sizeof(uint32_t);
+}
+return MAX_VEC_SIZE_BYTES / BITS_PER_BYTE;
+}
+
 int hexagon_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n)
 {
 HexagonCPU *cpu = HEXAGON_CPU(cs);
@@ -42,6 +98,16 @@ int hexagon_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 env->gpr[n] = ldtul_p(mem_buf);
 return sizeof(target_ulong);
 }
+n -= TOTAL_PER_THREAD_REGS;
+
+if (n < NUM_VREGS) {
+return gdb_put_vreg(env, mem_buf, n);
+}
+n -= NUM_VREGS;
+
+if (n < NUM_QREGS) {
+return gdb_put_qreg(env, mem_buf, n);
+}
 
 g_assert_not_reached();
 }
-- 
2.7.4



[PATCH 16/20] Hexagon HVX (target/hexagon) import instruction encodings

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/decode.c  |   4 +
 target/hexagon/imported/allextenc.def|  20 +
 target/hexagon/imported/encode.def   |   1 +
 target/hexagon/imported/mmvec/encode_ext.def | 794 +++
 4 files changed, 819 insertions(+)
 create mode 100644 target/hexagon/imported/allextenc.def
 create mode 100644 target/hexagon/imported/mmvec/encode_ext.def

diff --git a/target/hexagon/decode.c b/target/hexagon/decode.c
index 653bfd7..6f0f27b 100644
--- a/target/hexagon/decode.c
+++ b/target/hexagon/decode.c
@@ -47,6 +47,7 @@ enum {
 /* Name   Num Table */
 DEF_REGMAP(R_16,  16, 0, 1, 2, 3, 4, 5, 6, 7, 16, 17, 18, 19, 20, 21, 22, 23)
 DEF_REGMAP(R__8,  8,  0, 2, 4, 6, 16, 18, 20, 22)
+DEF_REGMAP(R_8,   8,  0, 1, 2, 3, 4, 5, 6, 7)
 
 #define DECODE_MAPPED_REG(OPNUM, NAME) \
 insn->regno[OPNUM] = DECODE_REGISTER_##NAME[insn->regno[OPNUM]];
@@ -158,6 +159,9 @@ static void decode_ext_init(void)
 for (i = EXT_IDX_noext; i < EXT_IDX_noext_AFTER; i++) {
 ext_trees[i] = &dectree_table_DECODE_EXT_EXT_noext;
 }
+for (i = EXT_IDX_mmvec; i < EXT_IDX_mmvec_AFTER; i++) {
+ext_trees[i] = &dectree_table_DECODE_EXT_EXT_mmvec;
+}
 }
 
 typedef struct {
diff --git a/target/hexagon/imported/allextenc.def 
b/target/hexagon/imported/allextenc.def
new file mode 100644
index 000..39a3e93
--- /dev/null
+++ b/target/hexagon/imported/allextenc.def
@@ -0,0 +1,20 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+#define EXTNAME mmvec
+#include "mmvec/encode_ext.def"
+#undef EXTNAME
diff --git a/target/hexagon/imported/encode.def 
b/target/hexagon/imported/encode.def
index b9368d1..e40e7fb 100644
--- a/target/hexagon/imported/encode.def
+++ b/target/hexagon/imported/encode.def
@@ -71,6 +71,7 @@
 
 #include "encode_pp.def"
 #include "encode_subinsn.def"
+#include "allextenc.def"
 
 #ifdef __SELF_DEF_FIELD32
 #undef __SELF_DEF_FIELD32
diff --git a/target/hexagon/imported/mmvec/encode_ext.def 
b/target/hexagon/imported/mmvec/encode_ext.def
new file mode 100644
index 000..6fbbe2c
--- /dev/null
+++ b/target/hexagon/imported/mmvec/encode_ext.def
@@ -0,0 +1,794 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+#define CONCAT(A,B) A##B
+#define EXTEXTNAME(X) CONCAT(EXT_,X)
+#define DEF_ENC(TAG,STR) DEF_EXT_ENC(TAG,EXTEXTNAME(EXTNAME),STR)
+
+
+#ifndef NO_MMVEC
+DEF_ENC(V6_extractw,  ICLASS_LD" 001 0 000s  PP0u  --1d") /* 
coproc insn, returns Rd */
+#endif
+
+
+#ifndef NO_MMVEC
+
+
+
+DEF_CLASS32(ICLASS_NCJ" 1---  PP-- ",COPROC_VMEM)
+DEF_CLASS32(ICLASS_NCJ" 1000 0-0t PPi--iii ---d",BaseOffset_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1000 1-0t PPivviii 
---d",BaseOffset_if_Pv_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1000 0-1t PPi--iii 
",BaseOffset_VMEM_Stores1)
+DEF_CLASS32(ICLASS_NCJ" 1000 1-0t PPi--iii 
00--",BaseOffset_VMEM_Stores2)
+DEF_CLASS32(ICLASS_NCJ" 1000 1-1t PPivviii 
",BaseOffset_if_Pv_VMEM_Stores)
+
+DEF_CLASS32(ICLASS_NCJ" 1001 0-0x PP---iii ---d",PostImm_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1001 1-0x PP-vviii 
---d",PostImm_if_Pv_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1001 0-1x PP---iii ",PostImm_VMEM_Stores1)
+DEF_CLASS32(ICLASS_NCJ" 1001 1-0x PP---iii 00--",PostImm_VMEM_Stores2)
+DEF_CLASS32(ICLASS_NCJ" 1001 1-1x PP-vviii 
",PostImm_if_Pv_VMEM_Stores)
+
+DEF_CLASS32(ICLASS_NCJ" 1011 0-0x PPu- ---d",PostM_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1011 1-0x PPuvv--

[PATCH 19/20] Hexagon HVX (tests/tcg/hexagon) scatter_gather test

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 tests/tcg/hexagon/scatter_gather.c | 1011 
 tests/tcg/hexagon/Makefile.target  |2 +
 2 files changed, 1013 insertions(+)
 create mode 100644 tests/tcg/hexagon/scatter_gather.c

diff --git a/tests/tcg/hexagon/scatter_gather.c 
b/tests/tcg/hexagon/scatter_gather.c
new file mode 100644
index 000..b93eb18
--- /dev/null
+++ b/tests/tcg/hexagon/scatter_gather.c
@@ -0,0 +1,1011 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+/*
+ * This example tests the HVX scatter/gather instructions
+ *
+ * See section 5.13 of the V68 HVX Programmer's Reference
+ *
+ * There are 3 main classes operations
+ * _16 16-bit elements and 16-bit offsets
+ * _32 32-bit elements and 32-bit offsets
+ * _16_32  16-bit elements and 32-bit offsets
+ *
+ * There are also masked and accumulate versions
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+typedef long HVX_Vector   __attribute__((__vector_size__(128)))
+  __attribute__((aligned(128)));
+typedef long HVX_VectorPair   __attribute__((__vector_size__(256)))
+  __attribute__((aligned(128)));
+typedef long HVX_VectorPred   __attribute__((__vector_size__(128)))
+  __attribute__((aligned(128)));
+
+#define VSCATTER_16(BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermh_128B((int)BASE, RGN, OFF, VALS)
+#define VSCATTER_16_MASKED(MASK, BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermhq_128B(MASK, (int)BASE, RGN, OFF, VALS)
+#define VSCATTER_32(BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermw_128B((int)BASE, RGN, OFF, VALS)
+#define VSCATTER_32_MASKED(MASK, BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermwq_128B(MASK, (int)BASE, RGN, OFF, VALS)
+#define VSCATTER_16_32(BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermhw_128B((int)BASE, RGN, OFF, VALS)
+#define VSCATTER_16_32_MASKED(MASK, BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermhwq_128B(MASK, (int)BASE, RGN, OFF, VALS)
+#define VSCATTER_16_ACC(BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermh_add_128B((int)BASE, RGN, OFF, VALS)
+#define VSCATTER_32_ACC(BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermw_add_128B((int)BASE, RGN, OFF, VALS)
+#define VSCATTER_16_32_ACC(BASE, RGN, OFF, VALS) \
+__builtin_HEXAGON_V6_vscattermhw_add_128B((int)BASE, RGN, OFF, VALS)
+
+#define VGATHER_16(DSTADDR, BASE, RGN, OFF) \
+__builtin_HEXAGON_V6_vgathermh_128B(DSTADDR, (int)BASE, RGN, OFF)
+#define VGATHER_16_MASKED(DSTADDR, MASK, BASE, RGN, OFF) \
+__builtin_HEXAGON_V6_vgathermhq_128B(DSTADDR, MASK, (int)BASE, RGN, OFF)
+#define VGATHER_32(DSTADDR, BASE, RGN, OFF) \
+__builtin_HEXAGON_V6_vgathermw_128B(DSTADDR, (int)BASE, RGN, OFF)
+#define VGATHER_32_MASKED(DSTADDR, MASK, BASE, RGN, OFF) \
+__builtin_HEXAGON_V6_vgathermwq_128B(DSTADDR, MASK, (int)BASE, RGN, OFF)
+#define VGATHER_16_32(DSTADDR, BASE, RGN, OFF) \
+__builtin_HEXAGON_V6_vgathermhw_128B(DSTADDR, (int)BASE, RGN, OFF)
+#define VGATHER_16_32_MASKED(DSTADDR, MASK, BASE, RGN, OFF) \
+__builtin_HEXAGON_V6_vgathermhwq_128B(DSTADDR, MASK, (int)BASE, RGN, OFF)
+
+#define VSHUFF_H(V) \
+__builtin_HEXAGON_V6_vshuffh_128B(V)
+#define VSPLAT_H(X) \
+__builtin_HEXAGON_V6_lvsplath_128B(X)
+#define VAND_VAL(PRED, VAL) \
+__builtin_HEXAGON_V6_vandvrt_128B(PRED, VAL)
+#define VDEAL_H(V) \
+__builtin_HEXAGON_V6_vdealh_128B(V)
+
+int err;
+
+/* define the number of rows/cols in a square matrix */
+#define MATRIX_SIZE 64
+
+/* define the size of the scatter buffer */
+#define SCATTER_BUFFER_SIZE (MATRIX_SIZE * MATRIX_SIZE)
+
+/* fake vtcm - put buffers together and force alignment */
+static struct {
+unsigned short vscatter16[SCATTER_BUFFER_SIZE];
+unsigned short vgather16[MATRIX_SIZE];
+unsigned int   vscatter32[SCATTER_BUFFER_SIZE];
+unsigned int   vgather32[MATRIX_SIZE];
+unsigned short vscatter16_32[SCATTER_BUFFER_SIZE];
+unsigned short vgather16_32[MATRIX_SIZE];
+} vtcm __attribute__((aligned(0x1)));
+
+/* declare the arrays of reference values */
+unsigned short vscatter16_ref[SCATTER_BUFFER_SIZE];
+unsigned short vgat

[PATCH 06/20] Hexagon HVX (target/hexagon) macros

2021-07-05 Thread Taylor Simpson
macros to interface with the generator
macros referenced in instruction semantics

Signed-off-by: Taylor Simpson 
---
 target/hexagon/macros.h   |  22 ++
 target/hexagon/mmvec/macros.h | 478 ++
 2 files changed, 500 insertions(+)
 create mode 100644 target/hexagon/mmvec/macros.h

diff --git a/target/hexagon/macros.h b/target/hexagon/macros.h
index 094b8da..852183f 100644
--- a/target/hexagon/macros.h
+++ b/target/hexagon/macros.h
@@ -269,6 +269,10 @@ static inline void gen_pred_cancel(TCGv pred, int slot_num)
 
 #define fNEWREG_ST(VAL) (VAL)
 
+#define fVSATUVALN(N, VAL) \
+({ \
+(((int)(VAL)) < 0) ? 0 : ((1LL << (N)) - 1); \
+})
 #define fSATUVALN(N, VAL) \
 ({ \
 fSET_OVERFLOW(); \
@@ -279,10 +283,16 @@ static inline void gen_pred_cancel(TCGv pred, int 
slot_num)
 fSET_OVERFLOW(); \
 ((VAL) < 0) ? (-(1LL << ((N) - 1))) : ((1LL << ((N) - 1)) - 1); \
 })
+#define fVSATVALN(N, VAL) \
+({ \
+((VAL) < 0) ? (-(1LL << ((N) - 1))) : ((1LL << ((N) - 1)) - 1); \
+})
 #define fZXTN(N, M, VAL) (((N) != 0) ? extract64((VAL), 0, (N)) : 0LL)
 #define fSXTN(N, M, VAL) (((N) != 0) ? sextract64((VAL), 0, (N)) : 0LL)
 #define fSATN(N, VAL) \
 ((fSXTN(N, 64, VAL) == (VAL)) ? (VAL) : fSATVALN(N, VAL))
+#define fVSATN(N, VAL) \
+((fSXTN(N, 64, VAL) == (VAL)) ? (VAL) : fVSATVALN(N, VAL))
 #define fADDSAT64(DST, A, B) \
 do { \
 uint64_t __a = fCAST8u(A); \
@@ -305,12 +315,18 @@ static inline void gen_pred_cancel(TCGv pred, int 
slot_num)
 DST = __sum; \
 } \
 } while (0)
+#define fVSATUN(N, VAL) \
+((fZXTN(N, 64, VAL) == (VAL)) ? (VAL) : fVSATUVALN(N, VAL))
 #define fSATUN(N, VAL) \
 ((fZXTN(N, 64, VAL) == (VAL)) ? (VAL) : fSATUVALN(N, VAL))
 #define fSATH(VAL) (fSATN(16, VAL))
 #define fSATUH(VAL) (fSATUN(16, VAL))
+#define fVSATH(VAL) (fVSATN(16, VAL))
+#define fVSATUH(VAL) (fVSATUN(16, VAL))
 #define fSATUB(VAL) (fSATUN(8, VAL))
 #define fSATB(VAL) (fSATN(8, VAL))
+#define fVSATUB(VAL) (fVSATUN(8, VAL))
+#define fVSATB(VAL) (fVSATN(8, VAL))
 #define fIMMEXT(IMM) (IMM = IMM)
 #define fMUST_IMMEXT(IMM) fIMMEXT(IMM)
 
@@ -417,6 +433,8 @@ static inline TCGv gen_read_ireg(TCGv result, TCGv val, int 
shift)
 #define fCAST4s(A) ((int32_t)(A))
 #define fCAST8u(A) ((uint64_t)(A))
 #define fCAST8s(A) ((int64_t)(A))
+#define fCAST2_2s(A) ((int16_t)(A))
+#define fCAST2_2u(A) ((uint16_t)(A))
 #define fCAST4_4s(A) ((int32_t)(A))
 #define fCAST4_4u(A) ((uint32_t)(A))
 #define fCAST4_8s(A) ((int64_t)((int32_t)(A)))
@@ -514,7 +532,9 @@ static inline TCGv gen_read_ireg(TCGv result, TCGv val, int 
shift)
 #define fPM_M(REG, MVAL)do { REG = REG + (MVAL); } while (0)
 #endif
 #define fSCALE(N, A) (((int64_t)(A)) << N)
+#define fVSATW(A) fVSATN(32, ((long long)A))
 #define fSATW(A) fSATN(32, ((long long)A))
+#define fVSAT(A) fVSATN(32, (A))
 #define fSAT(A) fSATN(32, (A))
 #define fSAT_ORIG_SHL(A, ORIG_REG) \
 int32_t)((fSAT(A)) ^ ((int32_t)(ORIG_REG < 0) \
@@ -651,12 +671,14 @@ static inline TCGv gen_read_ireg(TCGv result, TCGv val, 
int shift)
 fSETBIT(j, DST, VAL); \
 } \
 } while (0)
+#define fCOUNTONES_2(VAL) ctpop16(VAL)
 #define fCOUNTONES_4(VAL) ctpop32(VAL)
 #define fCOUNTONES_8(VAL) ctpop64(VAL)
 #define fBREV_8(VAL) revbit64(VAL)
 #define fBREV_4(VAL) revbit32(VAL)
 #define fCL1_8(VAL) clo64(VAL)
 #define fCL1_4(VAL) clo32(VAL)
+#define fCL1_2(VAL) count_leading_ones_2(VAL)
 #define fINTERLEAVE(ODD, EVEN) interleave(ODD, EVEN)
 #define fDEINTERLEAVE(MIXED) deinterleave(MIXED)
 #define fHIDE(A) A
diff --git a/target/hexagon/mmvec/macros.h b/target/hexagon/mmvec/macros.h
new file mode 100644
index 000..52a5b87
--- /dev/null
+++ b/target/hexagon/mmvec/macros.h
@@ -0,0 +1,478 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see .
+ */
+
+#ifndef HEXAGON_MMVEC_MACROS_H
+#define HEXAGON_MMVEC_MACROS_H
+
+#include "qemu/osdep.h"
+#include "qemu/host-utils.h"
+#include "arch.h"
+#include "mmvec/system_ext_mmvec.h"
+
+#ifndef QEMU_GENERATE
+#define VdV  (*(MMVector *)(VdV_void))
+#define VsV  (*(MMVector *)(VsV_void))
+#define VuV  (*(MMVector *)(VuV_void))
+#define VvV  (*(MMVector *)(VvV_void))
+#define VwV  (*(MMVector *)(VwV_vo

[PATCH 09/20] Hexagon HVX (target/hexagon) semantics generator - part 2

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/gen_helper_funcs.py  | 111 ++--
 target/hexagon/gen_helper_protos.py |  16 ++-
 target/hexagon/gen_tcg_funcs.py | 254 ++--
 3 files changed, 359 insertions(+), 22 deletions(-)

diff --git a/target/hexagon/gen_helper_funcs.py 
b/target/hexagon/gen_helper_funcs.py
index 2b1c5d8..c152002 100755
--- a/target/hexagon/gen_helper_funcs.py
+++ b/target/hexagon/gen_helper_funcs.py
@@ -48,12 +48,26 @@ def gen_helper_arg_pair(f,regtype,regid,regno):
 if regno >= 0 : f.write(", ")
 f.write("int64_t %s%sV" % (regtype,regid))
 
+def gen_helper_arg_ext(f,regtype,regid,regno):
+if regno > 0 : f.write(", ")
+f.write("void *%s%sV_void" % (regtype,regid))
+
+def gen_helper_arg_ext_pair(f,regtype,regid,regno):
+if regno > 0 : f.write(", ")
+f.write("void *%s%sV_void" % (regtype,regid))
+
 def gen_helper_arg_opn(f,regtype,regid,i,tag):
 if (hex_common.is_pair(regid)):
-gen_helper_arg_pair(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+gen_helper_arg_ext_pair(f,regtype,regid,i)
+else:
+gen_helper_arg_pair(f,regtype,regid,i)
 elif (hex_common.is_single(regid)):
 if hex_common.is_old_val(regtype, regid, tag):
-gen_helper_arg(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+gen_helper_arg_ext(f,regtype,regid,i)
+else:
+gen_helper_arg(f,regtype,regid,i)
 elif hex_common.is_new_val(regtype, regid, tag):
 gen_helper_arg_new(f,regtype,regid,i)
 else:
@@ -72,25 +86,67 @@ def 
gen_helper_dest_decl_pair(f,regtype,regid,regno,subfield=""):
 f.write("int64_t %s%sV%s = 0;\n" % \
 (regtype,regid,subfield))
 
+def gen_helper_dest_decl_ext(f,regtype,regid):
+if (regtype == "Q"):
+f.write("/* %s%sV is *(MMQReg *)(%s%sV_void) */\n" % \
+(regtype,regid,regtype,regid))
+else:
+f.write("/* %s%sV is *(MMVector *)(%s%sV_void) */\n" % \
+(regtype,regid,regtype,regid))
+
+def gen_helper_dest_decl_ext_pair(f,regtype,regid,regno):
+f.write("/* %s%sV is *(MMVectorPair *))%s%sV_void) */\n" % \
+(regtype,regid,regtype, regid))
+
 def gen_helper_dest_decl_opn(f,regtype,regid,i):
 if (hex_common.is_pair(regid)):
-gen_helper_dest_decl_pair(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+gen_helper_dest_decl_ext_pair(f,regtype,regid, i)
+else:
+gen_helper_dest_decl_pair(f,regtype,regid,i)
 elif (hex_common.is_single(regid)):
-gen_helper_dest_decl(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+gen_helper_dest_decl_ext(f,regtype,regid)
+else:
+gen_helper_dest_decl(f,regtype,regid,i)
 else:
 print("Bad register parse: ",regtype,regid,toss,numregs)
 
+def gen_helper_src_var_ext(f,regtype,regid):
+if (regtype == "Q"):
+   f.write("/* %s%sV is *(MMQReg *)(%s%sV_void) */\n" % \
+   (regtype,regid,regtype,regid))
+else:
+   f.write("/* %s%sV is *(MMVector *)(%s%sV_void) */\n" % \
+   (regtype,regid,regtype,regid))
+
+def gen_helper_src_var_ext_pair(f,regtype,regid,regno):
+f.write("/* %s%sV%s is *(MMVectorPair *)(%s%sV%s_void) */\n" % \
+(regtype,regid,regno,regtype,regid,regno))
+
 def gen_helper_return(f,regtype,regid,regno):
 f.write("return %s%sV;\n" % (regtype,regid))
 
 def gen_helper_return_pair(f,regtype,regid,regno):
 f.write("return %s%sV;\n" % (regtype,regid))
 
+def gen_helper_dst_write_ext(f,regtype,regid):
+return
+
+def gen_helper_dst_write_ext_pair(f,regtype,regid):
+return
+
 def gen_helper_return_opn(f, regtype, regid, i):
 if (hex_common.is_pair(regid)):
-gen_helper_return_pair(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+gen_helper_dst_write_ext_pair(f,regtype,regid)
+else:
+gen_helper_return_pair(f,regtype,regid,i)
 elif (hex_common.is_single(regid)):
-gen_helper_return(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+gen_helper_dst_write_ext(f,regtype,regid)
+else:
+gen_helper_return(f,regtype,regid,i)
 else:
 print("Bad register parse: ",regtype,regid,toss,numregs)
 
@@ -129,14 +185,20 @@ def gen_helper_function(f, tag, tagregs, tagimms):
 % (tag, tag))
 else:
 ## The return type of the function is the type of the destination
-## register
+## register (if scalar)
 i=0
 for regtype,regid,toss,numregs in regs:
 if (hex_common.is_written(regid)):
 if (hex_common.is_pair(regid)):
-gen_helper_return_type_pair(f,regtype,regid,i)
+if (hex_common.is_hvx_reg(regtype)):
+cont

[PATCH 05/20] Hexagon HVX (target/hexagon) instruction attributes

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/attribs_def.h.inc | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/target/hexagon/attribs_def.h.inc b/target/hexagon/attribs_def.h.inc
index 3815509..4138a7a 100644
--- a/target/hexagon/attribs_def.h.inc
+++ b/target/hexagon/attribs_def.h.inc
@@ -41,6 +41,27 @@ DEF_ATTRIB(STORE, "Stores to memory", "", "")
 DEF_ATTRIB(MEMLIKE, "Memory-like instruction", "", "")
 DEF_ATTRIB(MEMLIKE_PACKET_RULES, "follows Memory-like packet rules", "", "")
 
+/* V6 Vector attributes */
+DEF_ATTRIB(CVI, "Executes on the HVX extension", "", "")
+
+DEF_ATTRIB(CVI_NEW, "New value memory instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_VM, "Memory instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_VP, "Permute instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_VP_VS, "Double vector permute/shft insn executes on HVX", "", 
"")
+DEF_ATTRIB(CVI_VX, "Multiply instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_VX_DV, "Double vector multiply insn executes on HVX", "", "")
+DEF_ATTRIB(CVI_VS, "Shift instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_VS_VX, "Permute/shift and multiply insn executes on HVX", "", 
"")
+DEF_ATTRIB(CVI_VA, "ALU instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_VA_DV, "Double vector alu instruction executes on HVX", "", "")
+DEF_ATTRIB(CVI_4SLOT, "Consumes all the vector execution resources", "", "")
+DEF_ATTRIB(CVI_TMP, "Transient Memory Load not written to register", "", "")
+DEF_ATTRIB(CVI_GATHER, "CVI Gather operation", "", "")
+DEF_ATTRIB(CVI_SCATTER, "CVI Scatter operation", "", "")
+DEF_ATTRIB(CVI_SCATTER_RELEASE, "CVI Store Release for scatter", "", "")
+DEF_ATTRIB(CVI_TMP_DST, "CVI instruction that doesn't write a register", "", 
"")
+DEF_ATTRIB(CVI_SLOT23, "Can execute in slot 2 or slot 3 (HVX)", "", "")
+
 
 /* Change-of-flow attributes */
 DEF_ATTRIB(JUMP, "Jump-type instruction", "", "")
@@ -86,6 +107,7 @@ DEF_ATTRIB(HWLOOP1_END, "Ends HW loop1", "", "")
 DEF_ATTRIB(DCZEROA, "dczeroa type", "", "")
 DEF_ATTRIB(ICFLUSHOP, "icflush op type", "", "")
 DEF_ATTRIB(DCFLUSHOP, "dcflush op type", "", "")
+DEF_ATTRIB(L2FLUSHOP, "l2flush op type", "", "")
 DEF_ATTRIB(DCFETCH, "dcfetch type", "", "")
 
 DEF_ATTRIB(L2FETCH, "Instruction is l2fetch type", "", "")
-- 
2.7.4



[PATCH 00/20] Hexagon HVX (target/hexagon) patch series

2021-07-05 Thread Taylor Simpson
This series adds support for the Hexagon Vector eXtensions (HVX)

These instructions are documented here
https://developer.qualcomm.com/downloads/qualcomm-hexagon-v66-hvx-programmer-s-reference-manual

Hexagon HVX is a wide vector engine with 128 byte vectors.

See patch 01 Hexagon HVX README for more information.

*** Known checkpatch issues ***

The following are known checkpatch errors in the series
target/hexagon/gen_semantics.cSuspicious ; after while (0)
tests/tcg/hexagon/hvx_misc.c  Spaces around operator in macro invocation


Taylor Simpson (20):
  Hexagon HVX (target/hexagon) README
  Hexagon HVX (target/hexagon) add Hexagon Vector eXtensions (HVX) to
core
  Hexagon HVX (target/hexagon) register names
  Hexagon HVX (target/hexagon) support in gdbstub
  Hexagon HVX (target/hexagon) instruction attributes
  Hexagon HVX (target/hexagon) macros
  Hexagon HVX (target/hexagon) import macro definitions
  Hexagon HVX (target/hexagon) semantics generator
  Hexagon HVX (target/hexagon) semantics generator - part 2
  Hexagon HVX (target/hexagon) C preprocessor for decode tree
  Hexagon HVX (target/hexagon) instruction utility functions
  Hexagon HVX (target/hexagon) helper functions
  Hexagon HVX (target/hexagon) TCG generation
  Hexagon HVX (target/hexagon) import semantics
  Hexagon HVX (target/hexagon) instruction decoding
  Hexagon HVX (target/hexagon) import instruction encodings
  Hexagon HVX (tests/tcg/hexagon) vector_add_int test
  Hexagon HVX (tests/tcg/hexagon) hvx_misc test
  Hexagon HVX (tests/tcg/hexagon) scatter_gather test
  Hexagon HVX (tests/tcg/hexagon) histogram test

 target/hexagon/arch.h|1 +
 target/hexagon/cpu.h |   35 +-
 target/hexagon/helper.h  |1 +
 target/hexagon/hex_arch_types.h  |5 +
 target/hexagon/hex_regs.h|1 +
 target/hexagon/insn.h|3 +
 target/hexagon/internal.h|3 +
 target/hexagon/macros.h  |   22 +
 target/hexagon/mmvec/decode_ext_mmvec.h  |   24 +
 target/hexagon/mmvec/macros.h|  478 +
 target/hexagon/mmvec/mmvec.h |   83 +
 target/hexagon/mmvec/system_ext_mmvec.h  |   35 +
 target/hexagon/translate.h   |   54 +
 tests/tcg/hexagon/hvx_histogram_input.h  |  717 +++
 tests/tcg/hexagon/hvx_histogram_row.h|   24 +
 target/hexagon/attribs_def.h.inc |   22 +
 target/hexagon/arch.c|9 +
 target/hexagon/cpu.c |   72 +-
 target/hexagon/decode.c  |   28 +-
 target/hexagon/gdbstub.c |   66 +
 target/hexagon/gen_dectree_import.c  |   13 +
 target/hexagon/gen_semantics.c   |   33 +
 target/hexagon/genptr.c  |  111 ++
 target/hexagon/mmvec/decode_ext_mmvec.c  |  235 +++
 target/hexagon/mmvec/system_ext_mmvec.c  |  119 ++
 target/hexagon/op_helper.c   |   74 +-
 target/hexagon/translate.c   |  199 ++
 tests/tcg/hexagon/hvx_histogram.c|   88 +
 tests/tcg/hexagon/hvx_misc.c |  331 
 tests/tcg/hexagon/scatter_gather.c   | 1011 ++
 tests/tcg/hexagon/vector_add_int.c   |   61 +
 target/hexagon/README|   83 +-
 target/hexagon/gen_helper_funcs.py   |  111 +-
 target/hexagon/gen_helper_protos.py  |   16 +-
 target/hexagon/gen_tcg_funcs.py  |  254 ++-
 target/hexagon/hex_common.py |9 +-
 target/hexagon/imported/allext.idef  |   25 +
 target/hexagon/imported/allext_macros.def|   25 +
 target/hexagon/imported/allextenc.def|   20 +
 target/hexagon/imported/allidefs.def |1 +
 target/hexagon/imported/encode.def   |1 +
 target/hexagon/imported/macros.def   |   88 +
 target/hexagon/imported/mmvec/encode_ext.def |  794 
 target/hexagon/imported/mmvec/ext.idef   | 2606 ++
 target/hexagon/imported/mmvec/macros.def |  842 +
 target/hexagon/meson.build   |2 +
 tests/tcg/hexagon/Makefile.target|   12 +
 tests/tcg/hexagon/hvx_histogram_row.S|  294 +++
 48 files changed, 9110 insertions(+), 31 deletions(-)
 create mode 100644 target/hexagon/mmvec/decode_ext_mmvec.h
 create mode 100644 target/hexagon/mmvec/macros.h
 create mode 100644 target/hexagon/mmvec/mmvec.h
 create mode 100644 target/hexagon/mmvec/system_ext_mmvec.h
 create mode 100644 tests/tcg/hexagon/hvx_histogram_input.h
 create mode 100644 tests/tcg/hexagon/hvx_histogram_row.h
 create mode 100644 target/hexagon/mmvec/decode_ext_mmvec.c
 create mode 100644 target/hexagon/mmvec/system_ext_mmvec.c
 create mode 100644 tests/tcg/hexagon/hvx_histogram.c
 create mode 100644 tests/tcg/hexagon/hvx_misc.c
 create mode 100644 tests/tcg/hex

[PATCH 07/20] Hexagon HVX (target/hexagon) import macro definitions

2021-07-05 Thread Taylor Simpson
Imported from the Hexagon architecture library
imported/allext_macros.def   Top level macro include for all extensions
imported/macros.def  Scalar core macros (some HVX here)
imported/mmvec/macros.defHVX macro definitions
The macro definition files specify instruction attributes that are applied
to each instruction that reverences the macro.

Signed-off-by: Taylor Simpson 
---
 target/hexagon/imported/allext_macros.def |  25 +
 target/hexagon/imported/macros.def|  88 
 target/hexagon/imported/mmvec/macros.def  | 842 ++
 3 files changed, 955 insertions(+)
 create mode 100644 target/hexagon/imported/allext_macros.def
 create mode 100755 target/hexagon/imported/mmvec/macros.def

diff --git a/target/hexagon/imported/allext_macros.def 
b/target/hexagon/imported/allext_macros.def
new file mode 100644
index 000..9c91199
--- /dev/null
+++ b/target/hexagon/imported/allext_macros.def
@@ -0,0 +1,25 @@
+/*
+ *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+/*
+ * Top level file for all instruction set extensions
+ */
+#define EXTNAME mmvec
+#define EXTSTR "mmvec"
+#include "mmvec/macros.def"
+#undef EXTNAME
+#undef EXTSTR
diff --git a/target/hexagon/imported/macros.def 
b/target/hexagon/imported/macros.def
index 32ed3bf..e23f915 100755
--- a/target/hexagon/imported/macros.def
+++ b/target/hexagon/imported/macros.def
@@ -177,6 +177,12 @@ DEF_MACRO(
 )
 
 DEF_MACRO(
+fVSATUVALN,
+({ ((VAL) < 0) ? 0 : ((1LL<<(N))-1);}),
+()
+)
+
+DEF_MACRO(
 fSATUVALN,
 ({fSET_OVERFLOW(); ((VAL) < 0) ? 0 : ((1LL<<(N))-1);}),
 ()
@@ -189,6 +195,12 @@ DEF_MACRO(
 )
 
 DEF_MACRO(
+fVSATVALN,
+({((VAL) < 0) ? (-(1LL<<((N)-1))) : ((1LL<<((N)-1))-1);}),
+()
+)
+
+DEF_MACRO(
 fZXTN, /* macro name */
 ((VAL) & ((1LL<<(N))-1)),
 /* attribs */
@@ -205,6 +217,11 @@ DEF_MACRO(
 ((fSXTN(N,64,VAL) == (VAL)) ? (VAL) : fSATVALN(N,VAL)),
 ()
 )
+DEF_MACRO(
+fVSATN,
+((fSXTN(N,64,VAL) == (VAL)) ? (VAL) : fVSATVALN(N,VAL)),
+()
+)
 
 DEF_MACRO(
 fADDSAT64,
@@ -235,6 +252,12 @@ DEF_MACRO(
 )
 
 DEF_MACRO(
+fVSATUN,
+((fZXTN(N,64,VAL) == (VAL)) ? (VAL) : fVSATUVALN(N,VAL)),
+()
+)
+
+DEF_MACRO(
 fSATUN,
 ((fZXTN(N,64,VAL) == (VAL)) ? (VAL) : fSATUVALN(N,VAL)),
 ()
@@ -254,6 +277,19 @@ DEF_MACRO(
 )
 
 DEF_MACRO(
+fVSATH,
+(fVSATN(16,VAL)),
+()
+)
+
+DEF_MACRO(
+fVSATUH,
+(fVSATUN(16,VAL)),
+()
+)
+
+
+DEF_MACRO(
 fSATUB,
 (fSATUN(8,VAL)),
 ()
@@ -265,6 +301,20 @@ DEF_MACRO(
 )
 
 
+DEF_MACRO(
+fVSATUB,
+(fVSATUN(8,VAL)),
+()
+)
+DEF_MACRO(
+fVSATB,
+(fVSATN(8,VAL)),
+()
+)
+
+
+
+
 /*/
 /* immediate extension   */
 /*/
@@ -557,6 +607,18 @@ DEF_MACRO(
 )
 
 DEF_MACRO(
+fCAST2_2s, /* macro name */
+((size2s_t)(A)),
+/* optional attributes */
+)
+
+DEF_MACRO(
+fCAST2_2u, /* macro name */
+((size2u_t)(A)),
+/* optional attributes */
+)
+
+DEF_MACRO(
 fCAST4_4s, /* macro name */
 ((size4s_t)(A)),
 /* optional attributes */
@@ -876,6 +938,11 @@ DEF_MACRO(
 (((size8s_t)(A)).
+ */
+
+DEF_MACRO(fDUMPQ,
+   do {
+   printf(STR ":" #REG ": 0x%016llx\n",REG.ud[0]);
+   } while (0),
+   ()
+)
+
+DEF_MACRO(fUSE_LOOKUP_ADDRESS_BY_REV,
+   PROC->arch_proc_options->mmvec_use_full_va_for_lookup,
+   ()
+)
+
+DEF_MACRO(fUSE_LOOKUP_ADDRESS,
+   1,
+   ()
+)
+
+DEF_MACRO(fNOTQ,
+   ({mmqreg_t _ret = {0}; int _i_; for (_i_ = 0; _i_ < fVECSIZE()/64; 
_i_++) _ret.ud[_i_] = ~VAL.ud[_i_]; _ret;}),
+   ()
+)
+
+DEF_MACRO(fGETQBITS,
+   ((MASK) & (REG.w[(BITNO)>>5] >> ((BITNO) & 0x1f))),
+   ()
+)
+
+DEF_MACRO(fGETQBIT,
+   fGETQBITS(REG,1,1,BITNO),
+   ()
+)
+
+DEF_MACRO(fGENMASKW,
+   (((fGETQBIT(QREG,(IDX*4+0)) ? 0xFF : 0x0) << 0)
+   |((fGETQBIT(QREG,(IDX*4+1)) ? 0xFF : 0x0) << 8)
+   |((fGETQBIT(QREG,(IDX*4+2)) ? 0xFF : 0x0) << 16)
+   |((fGETQBIT(QREG,(IDX*4+3)) ? 0xFF : 0x0) << 24)),
+   ()
+)
+DEF_MACRO(fGET10BIT,
+   {
+   COE = (fGETUBYTE(3,VAL) >> (2 * POS)) & 3) << 8) | 
fGETUBYTE(POS,VAL)) <

[PATCH 08/20] Hexagon HVX (target/hexagon) semantics generator

2021-07-05 Thread Taylor Simpson
Add HVX support to the semantics generator

Signed-off-by: Taylor Simpson 
---
 target/hexagon/gen_semantics.c | 33 +
 target/hexagon/hex_common.py   |  9 -
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/target/hexagon/gen_semantics.c b/target/hexagon/gen_semantics.c
index c5fccec..4a2bdd7 100644
--- a/target/hexagon/gen_semantics.c
+++ b/target/hexagon/gen_semantics.c
@@ -44,6 +44,11 @@ int main(int argc, char *argv[])
  * Q6INSN(A2_add,"Rd32=add(Rs32,Rt32)",ATTRIBS(),
  * "Add 32-bit registers",
  * { RdV=RsV+RtV;})
+ * HVX instructions have the following form
+ * EXTINSN(V6_vinsertwr, "Vx32.w=vinsert(Rt32)",
+ * ATTRIBS(A_EXTENSION,A_CVI,A_CVI_VX),
+ * "Insert Word Scalar into Vector",
+ * VxV.uw[0] = RtV;)
  */
 #define Q6INSN(TAG, BEH, ATTRIBS, DESCR, SEM) \
 do { \
@@ -59,8 +64,23 @@ int main(int argc, char *argv[])
  ")\n", \
 #TAG, STRINGIZE(ATTRIBS)); \
 } while (0);
+#define EXTINSN(TAG, BEH, ATTRIBS, DESCR, SEM) \
+do { \
+fprintf(outfile, "SEMANTICS( \\\n" \
+ "\"%s\", \\\n" \
+ "%s, \\\n" \
+ "\"\"\"%s\"\"\" \\\n" \
+ ")\n", \
+#TAG, STRINGIZE(BEH), STRINGIZE(SEM)); \
+fprintf(outfile, "ATTRIBUTES( \\\n" \
+ "\"%s\", \\\n" \
+ "\"%s\" \\\n" \
+ ")\n", \
+#TAG, STRINGIZE(ATTRIBS)); \
+} while (0);
 #include "imported/allidefs.def"
 #undef Q6INSN
+#undef EXTINSN
 
 /*
  * Process the macro definitions
@@ -83,6 +103,19 @@ int main(int argc, char *argv[])
 #include "imported/macros.def"
 #undef DEF_MACRO
 
+/*
+ * Process the macros for HVX
+ */
+#define DEF_MACRO(MNAME, BEH, ATTRS) \
+fprintf(outfile, "MACROATTRIB( \\\n" \
+ "\"%s\", \\\n" \
+ "\"\"\"%s\"\"\", \\\n" \
+ "\"%s\" \\\n" \
+ ")\n", \
+#MNAME, STRINGIZE(BEH), STRINGIZE(ATTRS));
+#include "imported/allext_macros.def"
+#undef DEF_MACRO
+
 fclose(outfile);
 return 0;
 }
diff --git a/target/hexagon/hex_common.py b/target/hexagon/hex_common.py
index b3b5340..d07e48b 100755
--- a/target/hexagon/hex_common.py
+++ b/target/hexagon/hex_common.py
@@ -143,6 +143,9 @@ def compute_tag_immediates(tag):
 ##  Ppredicate register
 ##  RGPR register
 ##  Mmodifier register
+##  QHVX predicate vector
+##  VHVX vector register
+##  OHVX new vector register
 ##  regid can be one of the following
 ##  d, e destination register
 ##  dd   destination register pair
@@ -178,6 +181,9 @@ def is_readwrite(regid):
 def is_scalar_reg(regtype):
 return regtype in "RPC"
 
+def is_hvx_reg(regtype):
+return regtype in "VQ"
+
 def is_old_val(regtype, regid, tag):
 return regtype+regid+'V' in semdict[tag]
 
@@ -187,7 +193,8 @@ def is_new_val(regtype, regid, tag):
 def need_slot(tag):
 if ('A_CONDEXEC' in attribdict[tag] or
 'A_STORE' in attribdict[tag] or
-'A_LOAD' in attribdict[tag]):
+'A_LOAD' in attribdict[tag] or
+'A_CVI' in attribdict[tag]):
 return 1
 else:
 return 0
-- 
2.7.4



[PATCH 01/20] Hexagon HVX (target/hexagon) README

2021-07-05 Thread Taylor Simpson
Signed-off-by: Taylor Simpson 
---
 target/hexagon/README | 83 ++-
 1 file changed, 82 insertions(+), 1 deletion(-)

diff --git a/target/hexagon/README b/target/hexagon/README
index b0b2435..9a57802 100644
--- a/target/hexagon/README
+++ b/target/hexagon/README
@@ -1,9 +1,13 @@
 Hexagon is Qualcomm's very long instruction word (VLIW) digital signal
-processor(DSP).
+processor(DSP).  We also support Hexagon Vector eXtensions (HVX).  HVX
+is a wide vector coprocessor designed for high performance computer vision,
+image processing, machine learning, and other workloads.
 
 The following versions of the Hexagon core are supported
 Scalar core: v67
 
https://developer.qualcomm.com/downloads/qualcomm-hexagon-v67-programmer-s-reference-manual
+HVX extension: v66
+
https://developer.qualcomm.com/downloads/qualcomm-hexagon-v66-hvx-programmer-s-reference-manual
 
 We presented an overview of the project at the 2019 KVM Forum.
 
https://kvmforum2019.sched.com/event/Tmwc/qemu-hexagon-automatic-translation-of-the-isa-manual-pseudcode-to-tiny-code-instructions-of-a-vliw-architecture-niccolo-izzo-revng-taylor-simpson-qualcomm-innovation-center
@@ -124,6 +128,73 @@ There are also cases where we brute force the TCG code 
generation.
 Instructions with multiple definitions are examples.  These require special
 handling because qemu helpers can only return a single value.
 
+For HVX vectors, the generator behaves slightly differently.  The wide vectors
+won't fit in a TCGv or TCGv_i64, so we pass TCGv_ptr variables to pass the
+address to helper functions.  Here's an example for an HVX vector-add-word
+istruction.
+static void generate_V6_vaddw(
+CPUHexagonState *env,
+DisasContext *ctx,
+Insn *insn,
+Packet *pkt)
+{
+const int VdN = insn->regno[0];
+const intptr_t VdV_off =
+offsetof(CPUHexagonState,
+ future_VRegs[VdN]);
+TCGv_ptr VdV = tcg_temp_local_new_ptr();
+tcg_gen_addi_ptr(VdV, cpu_env, VdV_off);
+const int VuN = insn->regno[1];
+const intptr_t VuV_off =
+vreg_src_off(ctx, VuN);
+TCGv_ptr VuV = tcg_temp_local_new_ptr();
+const int VvN = insn->regno[2];
+const intptr_t VvV_off =
+vreg_src_off(ctx, VvN);
+TCGv_ptr VvV = tcg_temp_local_new_ptr();
+tcg_gen_addi_ptr(VuV, cpu_env, VuV_off);
+tcg_gen_addi_ptr(VvV, cpu_env, VvV_off);
+TCGv slot = tcg_const_tl(insn->slot);
+gen_helper_V6_vaddw(cpu_env, VdV, VuV, VvV, slot);
+tcg_temp_free(slot);
+gen_log_vreg_write(VdV_off, VdN, EXT_DFL, insn->slot, false, 
pkt->pkt_has_vhist);
+ctx_log_vreg_write(ctx, VdN, EXT_DFL, false);
+tcg_temp_free_ptr(VdV);
+tcg_temp_free_ptr(VuV);
+tcg_temp_free_ptr(VvV);
+}
+
+Notice that we also generate a variable named _off for each operand of
+the instruction.  This makes it easy to override the instruction semantics with
+functions from tcg-op-gved.h.  Here's the override for this instruction.
+#define fGEN_TCG_V6_vaddw(SHORTCODE) \
+tcg_gen_gvec_add(MO_32, VdV_off, VuV_off, VvV_off, \
+ sizeof(MMVector), sizeof(MMVector))
+
+Finally, we notice that the override doesn't use the TCGv_ptr variables, so
+we don't generate them when an override is present.  Here is what we generate
+when the override is present.
+static void generate_V6_vaddw(
+CPUHexagonState *env,
+DisasContext *ctx,
+Insn *insn,
+Packet *pkt)
+{
+const int VdN = insn->regno[0];
+const intptr_t VdV_off =
+offsetof(CPUHexagonState,
+ future_VRegs[VdN]);
+const int VuN = insn->regno[1];
+const intptr_t VuV_off =
+vreg_src_off(ctx, VuN);
+const int VvN = insn->regno[2];
+const intptr_t VvV_off =
+vreg_src_off(ctx, VvN);
+fGEN_TCG_V6_vaddw({ fHIDE(int i;) fVFOREACH(32, i) { VdV.w[i] = 
VuV.w[i] + VvV.w[i] ; } });
+gen_log_vreg_write(VdV_off, VdN, EXT_DFL, insn->slot, false, 
pkt->pkt_has_vhist);
+ctx_log_vreg_write(ctx, VdN, EXT_DFL, false);
+}
+
 In addition to instruction semantics, we use a generator to create the decode
 tree.  This generation is also a two step process.  The first step is to run
 target/hexagon/gen_dectree_import.c to produce
@@ -140,6 +211,7 @@ runtime information for each thread and contains stuff like 
the GPR and
 predicate registers.
 
 macros.h
+mmvec/macros.h
 
 The Hexagon arch lib relies heavily on macros for the instruction semantics.
 This is a great advantage for qemu because we can override them for different
@@ -203,6 +275,15 @@ During runtime, the following fields in CPUHexagonState 
(see cpu.h) are used
 pred_written

[PATCH 12/20] Hexagon HVX (target/hexagon) helper functions

2021-07-05 Thread Taylor Simpson
Commit vector stores (masked and scatter/gather)
Log vector register writes
Add the execution counters to the debug log

Signed-off-by: Taylor Simpson 
---
 target/hexagon/helper.h|  1 +
 target/hexagon/op_helper.c | 51 --
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/target/hexagon/helper.h b/target/hexagon/helper.h
index ca201fb..e41a5a1 100644
--- a/target/hexagon/helper.h
+++ b/target/hexagon/helper.h
@@ -23,6 +23,7 @@ DEF_HELPER_1(debug_start_packet, void, env)
 DEF_HELPER_FLAGS_3(debug_check_store_width, TCG_CALL_NO_WG, void, env, int, 
int)
 DEF_HELPER_FLAGS_3(debug_commit_end, TCG_CALL_NO_WG, void, env, int, int)
 DEF_HELPER_2(commit_store, void, env, int)
+DEF_HELPER_1(commit_hvx_stores, void, env)
 DEF_HELPER_FLAGS_4(fcircadd, TCG_CALL_NO_RWG_SE, s32, s32, s32, s32, s32)
 DEF_HELPER_FLAGS_1(fbrev, TCG_CALL_NO_RWG_SE, i32, i32)
 DEF_HELPER_3(sfrecipa, i64, env, f32, f32)
diff --git a/target/hexagon/op_helper.c b/target/hexagon/op_helper.c
index 4595559..4e196f9 100644
--- a/target/hexagon/op_helper.c
+++ b/target/hexagon/op_helper.c
@@ -25,6 +25,8 @@
 #include "arch.h"
 #include "hex_arch_types.h"
 #include "fma_emu.h"
+#include "mmvec/mmvec.h"
+#include "mmvec/macros.h"
 
 #define SF_BIAS127
 #define SF_MANTBITS23
@@ -162,6 +164,50 @@ void HELPER(commit_store)(CPUHexagonState *env, int 
slot_num)
 }
 }
 
+void HELPER(commit_hvx_stores)(CPUHexagonState *env)
+{
+int i;
+
+/* Normal (possibly masked) vector store */
+for (i = 0; i < VSTORES_MAX; i++) {
+if (env->vstore_pending[i]) {
+env->vstore_pending[i] = 0;
+target_ulong va = env->vstore[i].va;
+int size = env->vstore[i].size;
+for (int j = 0; j < size; j++) {
+if (env->vstore[i].mask.ub[j]) {
+put_user_u8(env->vstore[i].data.ub[j], va + j);
+}
+}
+}
+}
+
+/* Scatter store */
+if (env->vtcm_pending) {
+env->vtcm_pending = false;
+if (env->vtcm_log.op) {
+/* Need to perform the scatter read/modify/write at commit time */
+if (env->vtcm_log.op_size == 2) {
+SCATTER_OP_WRITE_TO_MEM(uint16_t);
+} else if (env->vtcm_log.op_size == 4) {
+/* Word Scatter += */
+SCATTER_OP_WRITE_TO_MEM(uint32_t);
+} else {
+g_assert_not_reached();
+}
+} else {
+for (i = 0; i < env->vtcm_log.size; i++) {
+if (env->vtcm_log.mask.ub[i] != 0) {
+put_user_u8(env->vtcm_log.data.ub[i], env->vtcm_log.va[i]);
+env->vtcm_log.mask.ub[i] = 0;
+env->vtcm_log.data.ub[i] = 0;
+}
+
+}
+}
+}
+}
+
 static void print_store(CPUHexagonState *env, int slot)
 {
 if (!(env->slot_cancelled & (1 << slot))) {
@@ -240,9 +286,10 @@ void HELPER(debug_commit_end)(CPUHexagonState *env, int 
has_st0, int has_st1)
 HEX_DEBUG_LOG("Next PC = " TARGET_FMT_lx "\n", env->next_PC);
 HEX_DEBUG_LOG("Exec counters: pkt = " TARGET_FMT_lx
   ", insn = " TARGET_FMT_lx
-  "\n",
+  ", hvx = " TARGET_FMT_lx "\n",
   env->gpr[HEX_REG_QEMU_PKT_CNT],
-  env->gpr[HEX_REG_QEMU_INSN_CNT]);
+  env->gpr[HEX_REG_QEMU_INSN_CNT],
+  env->gpr[HEX_REG_QEMU_HVX_CNT]);
 
 }
 
-- 
2.7.4



RE: [PATCH 05/12] linux-user: Extract target errno to 'target_errno_defs.h'

2021-07-05 Thread Taylor Simpson


> -Original Message-
> From: Philippe Mathieu-Daudé  On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Sunday, July 4, 2021 12:38 PM
> To: qemu-devel@nongnu.org
> Cc: Richard Henderson ; Jiaxun Yang
> ; Laurent Vivier ; Aleksandar
> Rikalo ; Taylor Simpson
> ; Philippe Mathieu-Daudé ;
> Aurelien Jarno ; Helge Deller 
> Subject: [PATCH 05/12] linux-user: Extract target errno to
> 'target_errno_defs.h'
> 


> diff --git a/linux-user/hexagon/target_errno_defs.h b/linux-
> user/hexagon/target_errno_defs.h
> new file mode 100644
> index 000..5daac4f5a83
> --- /dev/null
> +++ b/linux-user/hexagon/target_errno_defs.h
> @@ -0,0 +1,6 @@
> +#ifndef HEXAGON_TARGET_ERRNO_H
> +#define HEXAGON_TARGET_ERRNO_H

These should be HEXAGON_TARGET_ERRNO_DEFS_H.  Ditto for the other targets.

Otherwise,
Reviewed-by: Taylor Simpson 


Thanks,
Taylor



RE: [PATCH 12/12] linux-user: Extract target errno related functions to 'target_errno.h'

2021-07-05 Thread Taylor Simpson


> -Original Message-
> From: Philippe Mathieu-Daudé  On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Sunday, July 4, 2021 12:38 PM
> To: qemu-devel@nongnu.org
> Cc: Richard Henderson ; Jiaxun Yang
> ; Laurent Vivier ; Aleksandar
> Rikalo ; Taylor Simpson
> ; Philippe Mathieu-Daudé ;
> Aurelien Jarno ; Helge Deller 
> Subject: [PATCH 12/12] linux-user: Extract target errno related functions to
> 'target_errno.h'
> 
> diff --git a/linux-user/target_errno.h b/linux-user/target_errno.h new file
> mode 100644 index 000..4e5e9d384c9
> --- /dev/null
> +++ b/linux-user/target_errno.h
> @@ -0,0 +1,32 @@
> +
> +void target_to_host_errno_table_init(void);

This is added as static in linux-user/syscall.c in patch 10/12.  But then, 
removed from syscall.c in this patch and added to linux-user/target_errno.c in 
this patch.

Is this so that each patch in the series will build?

> diff --git a/linux-user/target_errno.c b/linux-user/target_errno.c new file
> mode 100644 index 000..2a7320d240f
> --- /dev/null
> +++ b/linux-user/target_errno.c
> @@ -0,0 +1,183 @@
> +/*
> + *  Linux syscalls

Copy/paste error?

Could you add a more descriptive comment to this file for posterity?
- How does the default behavior get inherited by targets?
- How does a target override the default behavior?
- A pointer to a target that is overriding the default behavior?


Thanks,
Taylor


[PATCH 3/4] dp8393x: Store CAM registers as 16-bit

2021-07-05 Thread Mark Cave-Ayland
From: Philippe Mathieu-Daudé 

Per the DP83932C datasheet from July 1995:

  4.0 SONIC Registers
  4.1 THE CAM UNIT

The Content Addressable Memory (CAM) consists of sixteen
48-bit entries for complete address filtering of network
packets. Each entry corresponds to a 48-bit destination
address that is user programmable and can contain any
combination of Multicast or Physical addresses. Each entry
is partitioned into three 16-bit CAM cells accessible
through CAM Address Ports (CAP 2, CAP 1 and CAP 0) with
CAP0 corresponding to the least significant 16 bits of
the Destination Address and CAP2 corresponding to the
most significant bits.

Store the CAM registers as 16-bit as it simplifies the code.
There is no change in the migration stream.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/net/dp8393x.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index cc7c001edb..22ceea338c 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -157,7 +157,7 @@ struct dp8393xState {
 MemoryRegion mmio;
 
 /* Registers */
-uint8_t cam[16][6];
+uint16_t cam[16][3];
 uint16_t regs[0x40];
 
 /* Temporaries */
@@ -280,15 +280,13 @@ static void dp8393x_do_load_cam(dp8393xState *s)
 address_space_read(&s->as, dp8393x_cdp(s),
MEMTXATTRS_UNSPECIFIED, s->data, size);
 index = dp8393x_get(s, width, 0) & 0xf;
-s->cam[index][0] = dp8393x_get(s, width, 1) & 0xff;
-s->cam[index][1] = dp8393x_get(s, width, 1) >> 8;
-s->cam[index][2] = dp8393x_get(s, width, 2) & 0xff;
-s->cam[index][3] = dp8393x_get(s, width, 2) >> 8;
-s->cam[index][4] = dp8393x_get(s, width, 3) & 0xff;
-s->cam[index][5] = dp8393x_get(s, width, 3) >> 8;
-trace_dp8393x_load_cam(index, s->cam[index][0], s->cam[index][1],
-   s->cam[index][2], s->cam[index][3],
-   s->cam[index][4], s->cam[index][5]);
+s->cam[index][0] = dp8393x_get(s, width, 1);
+s->cam[index][1] = dp8393x_get(s, width, 2);
+s->cam[index][2] = dp8393x_get(s, width, 3);
+trace_dp8393x_load_cam(index,
+   s->cam[index][0] >> 8, s->cam[index][0] & 0xff,
+   s->cam[index][1] >> 8, s->cam[index][1] & 0xff,
+   s->cam[index][2] >> 8, s->cam[index][2] & 0xff);
 /* Move to next entry */
 s->regs[SONIC_CDC]--;
 s->regs[SONIC_CDP] += size;
@@ -591,8 +589,7 @@ static uint64_t dp8393x_read(void *opaque, hwaddr addr, 
unsigned int size)
 case SONIC_CAP1:
 case SONIC_CAP0:
 if (s->regs[SONIC_CR] & SONIC_CR_RST) {
-val = s->cam[s->regs[SONIC_CEP] & 0xf][2 * (SONIC_CAP0 - reg) + 1] 
<< 8;
-val |= s->cam[s->regs[SONIC_CEP] & 0xf][2 * (SONIC_CAP0 - reg)];
+val = s->cam[s->regs[SONIC_CEP] & 0xf][2 * (SONIC_CAP0 - reg)];
 }
 break;
 /* All other registers have no special contraints */
@@ -990,7 +987,7 @@ static const VMStateDescription vmstate_dp8393x = {
 .version_id = 0,
 .minimum_version_id = 0,
 .fields = (VMStateField []) {
-VMSTATE_BUFFER_UNSAFE(cam, dp8393xState, 0, 16 * 6),
+VMSTATE_BUFFER_UNSAFE(cam, dp8393xState, 0, 16 * 3 * 2),
 VMSTATE_UINT16_ARRAY(regs, dp8393xState, 0x40),
 VMSTATE_END_OF_LIST()
 }
-- 
2.20.1




[PATCH 2/4] dp8393x: Replace address_space_rw(is_write=1) by address_space_write()

2021-07-05 Thread Mark Cave-Ayland
From: Philippe Mathieu-Daudé 

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

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 44a1955015..cc7c001edb 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -820,8 +820,8 @@ static ssize_t dp8393x_receive(NetClientState *nc, const 
uint8_t * buf,
 size = sizeof(uint16_t) * width;
 address = dp8393x_crda(s) + sizeof(uint16_t) * 6 * width;
 dp8393x_put(s, width, 0, 0);
-address_space_rw(&s->as, address, MEMTXATTRS_UNSPECIFIED,
- (uint8_t *)s->data, size, 1);
+address_space_write(&s->as, address, MEMTXATTRS_UNSPECIFIED,
+(uint8_t *)s->data, size);
 
 /* Move to next descriptor */
 s->regs[SONIC_CRDA] = s->regs[SONIC_LLFA];
@@ -850,8 +850,8 @@ static ssize_t dp8393x_receive(NetClientState *nc, const 
uint8_t * buf,
 /* Pad short packets to keep pointers aligned */
 if (rx_len < padded_len) {
 size = padded_len - rx_len;
-address_space_rw(&s->as, address, MEMTXATTRS_UNSPECIFIED,
-(uint8_t *)"\xFF\xFF\xFF", size, 1);
+address_space_write(&s->as, address, MEMTXATTRS_UNSPECIFIED,
+(uint8_t *)"\xFF\xFF\xFF", size);
 address += size;
 }
 
-- 
2.20.1




[PATCH 4/4] dp8393x: Rewrite dp8393x_get() / dp8393x_put()

2021-07-05 Thread Mark Cave-Ayland
From: Philippe Mathieu-Daudé 

Instead of accessing N registers via a single address_space API
call using a temporary buffer (stored in the device state) and
updating each register, move the address_space call in the
register put/get. The load/store and word size checks are moved
to put/get too. This simplifies a bit, making the code easier
to read.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/net/dp8393x.c | 160 +++
 1 file changed, 63 insertions(+), 97 deletions(-)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 22ceea338c..a03f8f0837 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -162,7 +162,6 @@ struct dp8393xState {
 
 /* Temporaries */
 uint8_t tx_buffer[0x1];
-uint16_t data[12];
 int loopback_packet;
 
 /* Memory access */
@@ -219,34 +218,48 @@ static uint32_t dp8393x_wt(dp8393xState *s)
 return s->regs[SONIC_WT1] << 16 | s->regs[SONIC_WT0];
 }
 
-static uint16_t dp8393x_get(dp8393xState *s, int width, int offset)
+static uint16_t dp8393x_get(dp8393xState *s, hwaddr addr, int offset)
 {
+const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
 uint16_t val;
 
-if (s->big_endian) {
-val = be16_to_cpu(s->data[offset * width + width - 1]);
+if (s->regs[SONIC_DCR] & SONIC_DCR_DW) {
+addr += offset << 2;
+if (s->big_endian) {
+val = address_space_ldl_be(&s->as, addr, attrs, NULL);
+} else {
+val = address_space_ldl_le(&s->as, addr, attrs, NULL);
+}
 } else {
-val = le16_to_cpu(s->data[offset * width]);
+addr += offset << 1;
+if (s->big_endian) {
+val = address_space_lduw_be(&s->as, addr, attrs, NULL);
+} else {
+val = address_space_lduw_le(&s->as, addr, attrs, NULL);
+}
 }
+
 return val;
 }
 
-static void dp8393x_put(dp8393xState *s, int width, int offset,
-uint16_t val)
+static void dp8393x_put(dp8393xState *s,
+hwaddr addr, int offset, uint16_t val)
 {
-if (s->big_endian) {
-if (width == 2) {
-s->data[offset * 2] = 0;
-s->data[offset * 2 + 1] = cpu_to_be16(val);
+const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
+
+if (s->regs[SONIC_DCR] & SONIC_DCR_DW) {
+addr += offset << 2;
+if (s->big_endian) {
+address_space_stl_be(&s->as, addr, val, attrs, NULL);
 } else {
-s->data[offset] = cpu_to_be16(val);
+address_space_stl_le(&s->as, addr, val, attrs, NULL);
 }
 } else {
-if (width == 2) {
-s->data[offset * 2] = cpu_to_le16(val);
-s->data[offset * 2 + 1] = 0;
+addr += offset << 1;
+if (s->big_endian) {
+address_space_stw_be(&s->as, addr, val, attrs, NULL);
 } else {
-s->data[offset] = cpu_to_le16(val);
+address_space_stw_le(&s->as, addr, val, attrs, NULL);
 }
 }
 }
@@ -277,12 +290,10 @@ static void dp8393x_do_load_cam(dp8393xState *s)
 
 while (s->regs[SONIC_CDC] & 0x1f) {
 /* Fill current entry */
-address_space_read(&s->as, dp8393x_cdp(s),
-   MEMTXATTRS_UNSPECIFIED, s->data, size);
-index = dp8393x_get(s, width, 0) & 0xf;
-s->cam[index][0] = dp8393x_get(s, width, 1);
-s->cam[index][1] = dp8393x_get(s, width, 2);
-s->cam[index][2] = dp8393x_get(s, width, 3);
+index = dp8393x_get(s, dp8393x_cdp(s), 0) & 0xf;
+s->cam[index][0] = dp8393x_get(s, dp8393x_cdp(s), 1);
+s->cam[index][1] = dp8393x_get(s, dp8393x_cdp(s), 2);
+s->cam[index][2] = dp8393x_get(s, dp8393x_cdp(s), 3);
 trace_dp8393x_load_cam(index,
s->cam[index][0] >> 8, s->cam[index][0] & 0xff,
s->cam[index][1] >> 8, s->cam[index][1] & 0xff,
@@ -293,9 +304,7 @@ static void dp8393x_do_load_cam(dp8393xState *s)
 }
 
 /* Read CAM enable */
-address_space_read(&s->as, dp8393x_cdp(s),
-   MEMTXATTRS_UNSPECIFIED, s->data, size);
-s->regs[SONIC_CE] = dp8393x_get(s, width, 0);
+s->regs[SONIC_CE] = dp8393x_get(s, dp8393x_cdp(s), 0);
 trace_dp8393x_load_cam_done(s->regs[SONIC_CE]);
 
 /* Done */
@@ -311,14 +320,12 @@ static void dp8393x_do_read_rra(dp8393xState *s)
 /* Read memory */
 width = (s->regs[SONIC_DCR] & SONIC_DCR_DW) ? 2 : 1;
 size = sizeof(uint16_t) * 4 * width;
-address_space_read(&s->as, dp8393x_rrp(s),
-   MEMTXATTRS_UNSPECIFIED, s->data, size);
 
 /* Update SONIC registers */
-s->regs[SONIC_CRBA0] = dp8393x_get(s, width, 0);
-s->regs[SONIC_CRBA1] = dp8393x_get(s, width, 1);
-s->regs[SONIC_RBWC0] = dp8393x_get(s, width, 2);
-s->regs[SONIC_RBWC1] = dp8393x_get(s, width, 3);
+s->regs[SONIC_CRBA0] = dp8393x_get(s, dp8393x_rrp(s), 0);
+s->regs[SONIC_CRBA1] = dp8393x_ge

[PATCH 1/4] dp8393x: don't force 32-bit register access

2021-07-05 Thread Mark Cave-Ayland
Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" set 
.impl.min_access_size
and .impl.max_access_size to 4 to try and fix the Linux jazzsonic driver which 
uses
32-bit accesses.

The problem with forcing the register access to 32-bit in this way is that 
since the
dp8393x uses 16-bit registers, a manual endian swap is required for devices on 
big
endian machines with 32-bit accesses.

For both access sizes and machine endians the QEMU memory API can do the right 
thing
automatically: all that is needed is to set .impl.min_access_size to 2 to 
declare that
the dp8393x implements 16-bit registers.

Normally .impl.max_access_size should also be set to 2, however that doesn't 
quite
work in this case since the register stride is specified using a (dynamic) 
it_shift
property which is applied during the MMIO access itself. The effect of this is 
that
for a 32-bit access the memory API performs 2 x 16-bit accesses, but the use of
it_shift within the MMIO access itself causes the register value to be repeated 
in both
the top 16-bits and bottom 16-bits. The Linux jazzsonic driver expects the 
stride to be
zero-extended up to access size and therefore fails to correctly detect the 
dp8393x
device due to the extra data in the top 16-bits.

The solution here is to remove .impl.max_access_size so that the memory API will
correctly zero-extend the 16-bit registers to the access size up to and 
including
it_shift. Since it_shift is never greater than 2 than this will always do the 
right
thing for both 16-bit and 32-bit accesses regardless of the machine endian, 
allowing
the manual endian swap code to be removed.

Signed-off-by: Mark Cave-Ayland 
Fixes: 3fe9a838ec ("dp8393x: Always use 32-bit accesses")
---
 hw/net/dp8393x.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 11810c9b60..44a1955015 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -602,15 +602,14 @@ static uint64_t dp8393x_read(void *opaque, hwaddr addr, 
unsigned int size)
 
 trace_dp8393x_read(reg, reg_names[reg], val, size);
 
-return s->big_endian ? val << 16 : val;
+return val;
 }
 
-static void dp8393x_write(void *opaque, hwaddr addr, uint64_t data,
+static void dp8393x_write(void *opaque, hwaddr addr, uint64_t val,
   unsigned int size)
 {
 dp8393xState *s = opaque;
 int reg = addr >> s->it_shift;
-uint32_t val = s->big_endian ? data >> 16 : data;
 
 trace_dp8393x_write(reg, reg_names[reg], val, size);
 
@@ -691,11 +690,16 @@ static void dp8393x_write(void *opaque, hwaddr addr, 
uint64_t data,
 }
 }
 
+/*
+ * Since .impl.max_access_size is effectively controlled by the it_shift
+ * property, leave it unspecified for now to allow the memory API to
+ * correctly zero extend the 16-bit register values to the access size up to 
and
+ * including it_shift.
+ */
 static const MemoryRegionOps dp8393x_ops = {
 .read = dp8393x_read,
 .write = dp8393x_write,
-.impl.min_access_size = 4,
-.impl.max_access_size = 4,
+.impl.min_access_size = 2,
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-- 
2.20.1




[PATCH 0/4] dp8393x: fixes and improvements

2021-07-05 Thread Mark Cave-Ayland
(was: [RFC PATCH 0/6] dp8393x: Housekeeping)

This is an updated version of Phil's patchset previously posted at
https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg00440.html which
I've tested locally on Linux/m68k, MacOS and NetBSD/arc.

Signed-off-by: Mark Cave-Ayland 


Changes since RFC:
- Drop patch 1 "dp8393x: fix CAM descriptor entry index" from this patchset as
  it has already been queued to mips-next
- Update patch 2 "dp8393x: don't force 32-bit register access" including 
improved
  comment explaining the current solution
- Drop patch 3 "dp8393x: Restrict bus access to 16/32-bit operations" since it
  causes a regression with MacOS
- Fix offsets in patch 6 "dp8393x: Rewrite dp8393x_get() / dp8393x_put()"

Signed-off-by: Mark Cave-Ayland 


Mark Cave-Ayland (1):
  dp8393x: don't force 32-bit register access

Philippe Mathieu-Daudé (3):
  dp8393x: Replace address_space_rw(is_write=1) by address_space_write()
  dp8393x: Store CAM registers as 16-bit
  dp8393x: Rewrite dp8393x_get() / dp8393x_put()

 hw/net/dp8393x.c | 195 ---
 1 file changed, 81 insertions(+), 114 deletions(-)

-- 
2.20.1




Re: [PATCH v4 11/22] tests/docker: expand centos8 package list

2021-07-05 Thread Daniel P . Berrangé
On Mon, Jul 05, 2021 at 10:41:55PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 05, 2021 at 09:27:56PM +0100, Alex Bennée wrote:
> > 
> > Daniel P. Berrangé  writes:
> > 
> > > This is the fully expanded list of build pre-requisites QEMU can
> > > conceivably use in any scenario.
> > >
> > > Reviewed-by: Philippe Mathieu-Daudé 
> > > Signed-off-by: Daniel P. Berrangé 
> > > ---
> > >  tests/docker/dockerfiles/centos8.docker | 68 +
> > >  1 file changed, 68 insertions(+)
> > >
> > > diff --git a/tests/docker/dockerfiles/centos8.docker 
> > > b/tests/docker/dockerfiles/centos8.docker
> > > index 5f1c57b4ad..4cc4c0c8a1 100644
> > > --- a/tests/docker/dockerfiles/centos8.docker
> > > +++ b/tests/docker/dockerfiles/centos8.docker
> > > @@ -3,36 +3,104 @@ FROM docker.io/centos:8
> > >  RUN dnf -y update
> > >  ENV PACKAGES \
> > >  SDL2-devel \
> > > +alsa-lib-devel \
> > > +bc \
> > > +brlapi-devel \
> > >  bzip2 \
> > >  bzip2-devel \
> > > +ca-certificates \
> > > +capstone-devel \
> > 
> > CentOS8 doesn't seem to package capstone-devel or is it meant to come
> > from somewhere else?
> 
> It comes in via the EPEL repository, along with a few other of the
> packages listed here. Take a look at this job, line 1385 onwards:
> 
>   https://gitlab.com/berrange/qemu/-/jobs/1369975075

Oh actually, this is a bisect issue in the series. The EPEL and
advanced virt repos are only enabled in the later patch in the
series that converts to lcitool auto-generation.

IOW, this current patch should have gained:

 RUN dnf install -y dnf-plugins-core && \
   dnf config-manager --set-enabled powertools && \
+  dnf install -y centos-release-advanced-virtualization && \
+  dnf install -y epel-release && \
   dnf install -y $PACKAGES


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




Re: [PATCH v4 11/22] tests/docker: expand centos8 package list

2021-07-05 Thread Daniel P . Berrangé
On Mon, Jul 05, 2021 at 09:27:56PM +0100, Alex Bennée wrote:
> 
> Daniel P. Berrangé  writes:
> 
> > This is the fully expanded list of build pre-requisites QEMU can
> > conceivably use in any scenario.
> >
> > Reviewed-by: Philippe Mathieu-Daudé 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >  tests/docker/dockerfiles/centos8.docker | 68 +
> >  1 file changed, 68 insertions(+)
> >
> > diff --git a/tests/docker/dockerfiles/centos8.docker 
> > b/tests/docker/dockerfiles/centos8.docker
> > index 5f1c57b4ad..4cc4c0c8a1 100644
> > --- a/tests/docker/dockerfiles/centos8.docker
> > +++ b/tests/docker/dockerfiles/centos8.docker
> > @@ -3,36 +3,104 @@ FROM docker.io/centos:8
> >  RUN dnf -y update
> >  ENV PACKAGES \
> >  SDL2-devel \
> > +alsa-lib-devel \
> > +bc \
> > +brlapi-devel \
> >  bzip2 \
> >  bzip2-devel \
> > +ca-certificates \
> > +capstone-devel \
> 
> CentOS8 doesn't seem to package capstone-devel or is it meant to come
> from somewhere else?

It comes in via the EPEL repository, along with a few other of the
packages listed here. Take a look at this job, line 1385 onwards:

  https://gitlab.com/berrange/qemu/-/jobs/1369975075


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




Re: [PATCH v3] dp8393x: don't force 32-bit register access

2021-07-05 Thread Philippe Mathieu-Daudé
On 7/5/21 9:33 PM, Mark Cave-Ayland wrote:
> On 05/07/2021 08:52, Mark Cave-Ayland wrote:
> 
>> I think the problem is because of the interaction of
>> .impl.max_access_size = 2 and the it_shift property specifying a
>> stride of 4 bytes: when the 4 byte access is split into 2 x 2 byte
>> accesses then for a read reg = addr >> s->it_shift causes the second
>> access to be a duplicate of the first rather than containing zeros.

I believe this is something I tried to fix earlier, see:

"hw/misc: Add support for interleaved memory accesses"
https://www.mail-archive.com/qemu-devel@nongnu.org/msg730721.html
(in particular:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg730725.html)

and

"hw/misc: Add memory_region_add_subregion_aliased() helper"
https://www.mail-archive.com/qemu-block@nongnu.org/msg83742.html

I plan to respin during next dev cycle...

> After some more experiments I'm fairly confident this is the issue: if
> you rely on applying it_shift within the MMIO access itself then you
> lose the zero extension of the result to the access size as done by the
> memory API.
> 
> I'll come up with a new version which I shall send as part of an updated
> and tested v2 of Phil's housekeeping patchset, since the endian changes
> were really helpful when studying the descriptors.
I'm fine if we take the patch Finn has tested (I'll amend a comment
explaining the limitations) and we fix the details in the next cycle.



Re: [PATCH v4 0/4] avocado-qemu: New SMMUv3 and intel IOMMU tests

2021-07-05 Thread Willian Rampazzo
On Mon, Jul 5, 2021 at 6:20 PM Philippe Mathieu-Daudé  wrote:
>
> On 7/5/21 11:10 PM, Willian Rampazzo wrote:
> > Hi Eric,
> >
> > On Mon, Jul 5, 2021 at 4:55 AM Eric Auger  wrote:
> >>
> >> Hi Wainer,
> >>
> >> On 7/1/21 1:22 AM, Wainer dos Santos Moschetta wrote:
> >>> Hi,
> >>>
> >>> On 6/29/21 5:17 PM, Eric Auger wrote:
>  Hi Cleber, all,
> 
>  On 6/29/21 4:36 PM, Eric Auger wrote:
> > This series adds ARM SMMU and Intel IOMMU functional
> > tests using Fedora cloud-init images.
> >
> > ARM SMMU tests feature guests with and without RIL
> > (range invalidation support) using respectively fedora 33
> > and 31.  For each, we test the protection of virtio-net-pci
> > and virtio-block-pci devices. Also strict=no and passthrough
> > modes are tested. So there is a total of 6 tests.
> >
> > The series applies on top of Cleber's series:
> > - [PATCH 0/3] Acceptance Tests: support choosing specific
> >
> > Note:
> > - SMMU tests 2, 3, 5, 6 (resp. test_smmu_noril_passthrough and
> > test_smmu_noril_nostrict) pass but the log reports:
> > "WARN: Test passed but there were warnings during execution."
> > This seems due to the lack of hash when fetching the kernel and
> > initrd through fetch_asset():
> > WARNI| No hash provided. Cannot check the asset file integrity.
>  I wanted to emphasize that point and wondered how we could fix that
>  issue. Looks a pity the tests get tagged as WARN due to a lack of sha1.
>  Any advice?
> >>>
> >>> As Willian mentioned somewhere, to supress the WARN you can pass the
> >>> kernel and initrd checksums (sha1) to the fetch_asset() method.
> >>>
> >>> Below is an draft implementation. It would need to fill out the
> >>> remaining checksums and adjust the `smmu.py` tests.
> >>>
> >>> - Wainer
> >>>
> >>> 
> >>>
> >>> diff --git a/tests/acceptance/avocado_qemu/__init__.py
> >>> b/tests/acceptance/avocado_qemu/__init__.py
> >>> index 00eb0bfcc8..83637e2654 100644
> >>> --- a/tests/acceptance/avocado_qemu/__init__.py
> >>> +++ b/tests/acceptance/avocado_qemu/__init__.py
> >>> @@ -312,6 +312,8 @@ class LinuxDistro:
> >>>  {'checksum':
> >>> 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0',
> >>>  'pxeboot_url':
> >>> "https://archives.fedoraproject.org/pub/archive/fedora/";
> >>> "linux/releases/31/Everything/x86_64/os/images/pxeboot/",
> >>> +'pxeboot_initrd_chksum':
> >>> 'dd0340a1b39bd28f88532babd4581c67649ec5b1',
> >>> +'pxeboot_vmlinuz_chksum':
> >>> '5b6f6876e1b5bda314f93893271da0d5777b1f3c',
> >> where did you get the checksum? I don't see any at the URL? Did you
> >> generate it yourself?
> >
> > It is possible to use the hash you generate from the downloaded file.
> >
> > While I was reviewing this series, I thought it makes more sense to
> > have Wainer's path applied first and then have your changes. I did
> > this here, with the addition of myu suggestions in the series:
> > https://gitlab.com/willianrampazzo/qemu/-/commits/test_eric_auger_v5.
>
> Off-list review is a bit unhandy (in particular when asked on the list).
>
> Why don't you post your improvements as v5? I don't think Eric will be
> offended: this is the opposite, you are helping him to get his patches
> merged ;)

Oh, I did review each of his patches in the list and also already made
the changes to speed up the process :)

He mentioned today to me that his series is still depending on one
from Cleber that was not merged yet, so we need to wait for that.

>
> > Feel free to pick it and resend a new version.
> >
> > Wainer, check if you agree with the changes to your patch and ack it.
> >
> > Regards,
>




Re: [PATCH v3] dp8393x: don't force 32-bit register access

2021-07-05 Thread Philippe Mathieu-Daudé
On 7/5/21 3:44 AM, Finn Thain wrote:
> On Sun, 4 Jul 2021, Mark Cave-Ayland wrote:
> 
>> Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that all 
>> accesses
>> to the registers were 32-bit 
> 
> As I said, that assumption was not made there.
> 
> If commit 3fe9a838ec is deficient it is probably because I am unaware of 
> the ability of the QEMU memory API to accomplish the desired result. 
> 
> That's not to say that the API can't do it, just that I don't know enough 
> about the API.
> 
>> but this is actually not the case. The access size is determined by the 
>> CPU instruction used and not the number of physical address lines.
>>
> 
> Again, that is an over-simplification. To explain: in Apple hardware at 
> least, the access size that the SONIC chip sees is a consequence of bus 
> sizing logic that is not part of the CPU and is not part of the SONIC chip 
> either.
> 
> AIUI, this logic is what Philippe alluded to when he said about this 
> patch, "This sounds to me like the 'QEMU doesn't model busses so we end 
> using kludge to hide bugs' pattern".

For the Jazz Magnum, the bus is partly represented in this datasheet:
https://datasheet.datasheetarchive.com/originals/scans/Scans-054/DSAIH000102184.pdf

I found the individual technical datasheet once, now I need to find them
again :/

I'll try to implement the missing parts in the next dev cycle.

Regards,

Phil.



Re: [PATCH v4 0/4] avocado-qemu: New SMMUv3 and intel IOMMU tests

2021-07-05 Thread Philippe Mathieu-Daudé
On 7/5/21 11:10 PM, Willian Rampazzo wrote:
> Hi Eric,
> 
> On Mon, Jul 5, 2021 at 4:55 AM Eric Auger  wrote:
>>
>> Hi Wainer,
>>
>> On 7/1/21 1:22 AM, Wainer dos Santos Moschetta wrote:
>>> Hi,
>>>
>>> On 6/29/21 5:17 PM, Eric Auger wrote:
 Hi Cleber, all,

 On 6/29/21 4:36 PM, Eric Auger wrote:
> This series adds ARM SMMU and Intel IOMMU functional
> tests using Fedora cloud-init images.
>
> ARM SMMU tests feature guests with and without RIL
> (range invalidation support) using respectively fedora 33
> and 31.  For each, we test the protection of virtio-net-pci
> and virtio-block-pci devices. Also strict=no and passthrough
> modes are tested. So there is a total of 6 tests.
>
> The series applies on top of Cleber's series:
> - [PATCH 0/3] Acceptance Tests: support choosing specific
>
> Note:
> - SMMU tests 2, 3, 5, 6 (resp. test_smmu_noril_passthrough and
> test_smmu_noril_nostrict) pass but the log reports:
> "WARN: Test passed but there were warnings during execution."
> This seems due to the lack of hash when fetching the kernel and
> initrd through fetch_asset():
> WARNI| No hash provided. Cannot check the asset file integrity.
 I wanted to emphasize that point and wondered how we could fix that
 issue. Looks a pity the tests get tagged as WARN due to a lack of sha1.
 Any advice?
>>>
>>> As Willian mentioned somewhere, to supress the WARN you can pass the
>>> kernel and initrd checksums (sha1) to the fetch_asset() method.
>>>
>>> Below is an draft implementation. It would need to fill out the
>>> remaining checksums and adjust the `smmu.py` tests.
>>>
>>> - Wainer
>>>
>>> 
>>>
>>> diff --git a/tests/acceptance/avocado_qemu/__init__.py
>>> b/tests/acceptance/avocado_qemu/__init__.py
>>> index 00eb0bfcc8..83637e2654 100644
>>> --- a/tests/acceptance/avocado_qemu/__init__.py
>>> +++ b/tests/acceptance/avocado_qemu/__init__.py
>>> @@ -312,6 +312,8 @@ class LinuxDistro:
>>>  {'checksum':
>>> 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0',
>>>  'pxeboot_url':
>>> "https://archives.fedoraproject.org/pub/archive/fedora/";
>>> "linux/releases/31/Everything/x86_64/os/images/pxeboot/",
>>> +'pxeboot_initrd_chksum':
>>> 'dd0340a1b39bd28f88532babd4581c67649ec5b1',
>>> +'pxeboot_vmlinuz_chksum':
>>> '5b6f6876e1b5bda314f93893271da0d5777b1f3c',
>> where did you get the checksum? I don't see any at the URL? Did you
>> generate it yourself?
> 
> It is possible to use the hash you generate from the downloaded file.
> 
> While I was reviewing this series, I thought it makes more sense to
> have Wainer's path applied first and then have your changes. I did
> this here, with the addition of myu suggestions in the series:
> https://gitlab.com/willianrampazzo/qemu/-/commits/test_eric_auger_v5.

Off-list review is a bit unhandy (in particular when asked on the list).

Why don't you post your improvements as v5? I don't think Eric will be
offended: this is the opposite, you are helping him to get his patches
merged ;)

> Feel free to pick it and resend a new version.
> 
> Wainer, check if you agree with the changes to your patch and ack it.
> 
> Regards,




Re: [PATCH v4 4/4] avocado_qemu: Fix KNOWN_DISTROS map into the LinuxDistro class

2021-07-05 Thread Willian Rampazzo
On Tue, Jun 29, 2021 at 11:36 AM Eric Auger  wrote:
>
> From: Wainer dos Santos Moschetta 
>
> As the KNOWN_DISTROS grows, more loosely methods will be created in
> the avocado_qemu/__init__.py file.
>
> Let's refactor the code so that KNOWN_DISTROS and related methods are
> packaged in a class
>
> Signed-off-by: Wainer dos Santos Moschetta 
> Signed-off-by: Eric Auger 
>
> ---
>
> [Eric] rebase and add commit message
> ---
>  tests/acceptance/avocado_qemu/__init__.py | 160 +++---
>  tests/acceptance/intel_iommu.py   |  12 +-
>  tests/acceptance/smmu.py  |  12 +-
>  3 files changed, 94 insertions(+), 90 deletions(-)
>

As suggested in the cover letter, moving the changes from Wainer to
the beginning of the patches makes more sense and reduces the amount
of changes.

The code refactoring from Wainer is here:
https://gitlab.com/willianrampazzo/qemu/-/commits/test_eric_auger_v5




Re: [PATCH v4 3/4] avocado_qemu: Add Intel iommu tests

2021-07-05 Thread Willian Rampazzo
On Tue, Jun 29, 2021 at 11:36 AM Eric Auger  wrote:
>
> Add Intel IOMMU functional tests based on fedora 31.
> Different configs are checked:
> - strict
> - caching mode, strict
> - passthrough.
>
> Signed-off-by: Eric Auger 
> Acked-by: Peter Xu 
> ---
>  tests/acceptance/intel_iommu.py | 115 
>  1 file changed, 115 insertions(+)
>  create mode 100644 tests/acceptance/intel_iommu.py
>
> diff --git a/tests/acceptance/intel_iommu.py b/tests/acceptance/intel_iommu.py
> new file mode 100644
> index 00..0b68d3c572
> --- /dev/null
> +++ b/tests/acceptance/intel_iommu.py
> @@ -0,0 +1,115 @@
> +# INTEL_IOMMU Functional tests
> +#
> +# Copyright (c) 2021 Red Hat, Inc.
> +#
> +# Author:
> +#  Eric Auger 
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or
> +# later.  See the COPYING file in the top-level directory.
> +
> +import os

"os" package is not used, you can remove it, unless you add the skipIf
decorator, then you will need it.

> +
> +from avocado_qemu import LinuxTest, BUILD_DIR

BUILD_DIR is not used in this file.

> +from avocado.utils import ssh

The ssh package is not used in this file.

> +
> +class INTEL_IOMMU(LinuxTest):

I suggest you use IntelIOMMU as the class name, so it conforms to
Python class naming.

> +"""
> +:avocado: tags=arch:x86_64
> +:avocado: tags=distro:fedora
> +:avocado: tags=distro_version:31
> +:avocado: tags=machine:q35
> +:avocado: tags=accel:kvm
> +:avocado: tags=intel_iommu
> +"""
> +
> +IOMMU_ADDON = ',iommu_platform=on,disable-modern=off,disable-legacy=on'
> +kernel_path = None
> +initrd_path = None
> +kernel_params = None
> +
> +def set_up_boot(self):
> +path = self.download_boot()
> +self.vm.add_args('-device', 'virtio-blk-pci,bus=pcie.0,scsi=off,' +
> + 'drive=drv0,id=virtio-disk0,bootindex=1,'
> + 'werror=stop,rerror=stop' + self.IOMMU_ADDON)
> +self.vm.add_args('-device', 'virtio-gpu-pci' + self.IOMMU_ADDON)
> +self.vm.add_args('-drive',
> + 'file=%s,if=none,cache=writethrough,id=drv0' % path)
> +
> +def setUp(self):
> +super(INTEL_IOMMU, self).setUp(None, 'virtio-net-pci' + 
> self.IOMMU_ADDON)

If you change the class name, you need to change it here too.

> +
> +def add_common_args(self):
> +self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0')
> +self.vm.add_args('-object',
> + 'rng-random,id=rng0,filename=/dev/urandom')
> +
> +def common_vm_setup(self, custom_kernel=None):
> +self.require_accelerator("kvm")
> +self.add_common_args()
> +self.vm.add_args("-accel", "kvm")
> +
> +if custom_kernel is None:
> +return
> +
> +kernel_url = self.get_pxeboot_url() + 'vmlinuz'
> +initrd_url = self.get_pxeboot_url() + 'initrd.img'
> +self.kernel_path = self.fetch_asset(kernel_url)
> +self.initrd_path = self.fetch_asset(initrd_url)
> +
> +def run_and_check(self):
> +if self.kernel_path:
> +self.vm.add_args('-kernel', self.kernel_path,
> + '-append', self.kernel_params,
> + '-initrd', self.initrd_path)
> +self.launch_and_wait()
> +self.ssh_command('cat /proc/cmdline')
> +self.ssh_command('dmesg | grep -e DMAR -e IOMMU')
> +self.ssh_command('find /sys/kernel/iommu_groups/ -type l')
> +self.ssh_command('dnf -y install numactl-devel')
> +
> +def test_intel_iommu(self):
> +"""
> +:avocado: tags=intel_iommu_intremap
> +"""
> +
> +self.common_vm_setup(True)
> +self.vm.add_args('-device', 'intel-iommu,intremap=on')
> +self.vm.add_args('-machine', 'kernel_irqchip=split')
> +
> +self.kernel_params = self.get_default_kernel_params() + ' quiet 
> intel_iommu=on'
> +self.run_and_check()
> +
> +def test_intel_iommu_strict(self):
> +"""
> +:avocado: tags=intel_iommu_strict
> +"""
> +
> +self.common_vm_setup(True)
> +self.vm.add_args('-device', 'intel-iommu,intremap=on')
> +self.vm.add_args('-machine', 'kernel_irqchip=split')
> +self.kernel_params = self.get_default_kernel_params() + ' quiet 
> intel_iommu=on,strict'
> +self.run_and_check()
> +
> +def test_intel_iommu_strict_cm(self):
> +"""
> +:avocado: tags=intel_iommu_strict_cm
> +"""
> +
> +self.common_vm_setup(True)
> +self.vm.add_args('-device', 
> 'intel-iommu,intremap=on,caching-mode=on')
> +self.vm.add_args('-machine', 'kernel_irqchip=split')
> +self.kernel_params = self.get_default_kernel_params() + ' quiet 
> intel_iommu=on,strict'
> +self.run_and_check()
> +
> +def test_intel_iommu_pt(self):
> +"""
> +:avocado: tags=intel_iommu_pt
> +   

Re: [PATCH v4 0/4] avocado-qemu: New SMMUv3 and intel IOMMU tests

2021-07-05 Thread Willian Rampazzo
Hi Eric,

On Mon, Jul 5, 2021 at 4:55 AM Eric Auger  wrote:
>
> Hi Wainer,
>
> On 7/1/21 1:22 AM, Wainer dos Santos Moschetta wrote:
> > Hi,
> >
> > On 6/29/21 5:17 PM, Eric Auger wrote:
> >> Hi Cleber, all,
> >>
> >> On 6/29/21 4:36 PM, Eric Auger wrote:
> >>> This series adds ARM SMMU and Intel IOMMU functional
> >>> tests using Fedora cloud-init images.
> >>>
> >>> ARM SMMU tests feature guests with and without RIL
> >>> (range invalidation support) using respectively fedora 33
> >>> and 31.  For each, we test the protection of virtio-net-pci
> >>> and virtio-block-pci devices. Also strict=no and passthrough
> >>> modes are tested. So there is a total of 6 tests.
> >>>
> >>> The series applies on top of Cleber's series:
> >>> - [PATCH 0/3] Acceptance Tests: support choosing specific
> >>>
> >>> Note:
> >>> - SMMU tests 2, 3, 5, 6 (resp. test_smmu_noril_passthrough and
> >>> test_smmu_noril_nostrict) pass but the log reports:
> >>> "WARN: Test passed but there were warnings during execution."
> >>> This seems due to the lack of hash when fetching the kernel and
> >>> initrd through fetch_asset():
> >>> WARNI| No hash provided. Cannot check the asset file integrity.
> >> I wanted to emphasize that point and wondered how we could fix that
> >> issue. Looks a pity the tests get tagged as WARN due to a lack of sha1.
> >> Any advice?
> >
> > As Willian mentioned somewhere, to supress the WARN you can pass the
> > kernel and initrd checksums (sha1) to the fetch_asset() method.
> >
> > Below is an draft implementation. It would need to fill out the
> > remaining checksums and adjust the `smmu.py` tests.
> >
> > - Wainer
> >
> > 
> >
> > diff --git a/tests/acceptance/avocado_qemu/__init__.py
> > b/tests/acceptance/avocado_qemu/__init__.py
> > index 00eb0bfcc8..83637e2654 100644
> > --- a/tests/acceptance/avocado_qemu/__init__.py
> > +++ b/tests/acceptance/avocado_qemu/__init__.py
> > @@ -312,6 +312,8 @@ class LinuxDistro:
> >  {'checksum':
> > 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0',
> >  'pxeboot_url':
> > "https://archives.fedoraproject.org/pub/archive/fedora/";
> > "linux/releases/31/Everything/x86_64/os/images/pxeboot/",
> > +'pxeboot_initrd_chksum':
> > 'dd0340a1b39bd28f88532babd4581c67649ec5b1',
> > +'pxeboot_vmlinuz_chksum':
> > '5b6f6876e1b5bda314f93893271da0d5777b1f3c',
> where did you get the checksum? I don't see any at the URL? Did you
> generate it yourself?

It is possible to use the hash you generate from the downloaded file.

While I was reviewing this series, I thought it makes more sense to
have Wainer's path applied first and then have your changes. I did
this here, with the addition of myu suggestions in the series:
https://gitlab.com/willianrampazzo/qemu/-/commits/test_eric_auger_v5.

Feel free to pick it and resend a new version.

Wainer, check if you agree with the changes to your patch and ack it.

Regards,

>
> Thanks
>
> Eric
> >  'kernel_params':
> > "root=UUID=b1438b9b-2cab-4065-a99a-08a96687f73c ro "
> >"no_timer_check net.ifnames=0 "
> >"console=tty1 console=ttyS0,115200n8"},
> > @@ -371,6 +373,16 @@ def pxeboot_url(self):
> >  """Gets the repository url where pxeboot files can be found"""
> >  return self._info.get('pxeboot_url', None)
> >
> > +@property
> > +def pxeboot_initrd_chksum(self):
> > +"""Gets the pxeboot initrd file checksum"""
> > +return self._info.get('pxeboot_initrd_chksum', None)
> > +
> > +@property
> > +def pxeboot_vmlinuz_chksum(self):
> > +"""Gets the pxeboot vmlinuz file checksum"""
> > +return self._info.get('pxeboot_vmlinuz_chksum', None)
> > +
> >  @property
> >  def checksum(self):
> >  """Gets the cloud-image file checksum"""
> > diff --git a/tests/acceptance/intel_iommu.py
> > b/tests/acceptance/intel_iommu.py
> > index bf8dea6e4f..a2f38ee2e9 100644
> > --- a/tests/acceptance/intel_iommu.py
> > +++ b/tests/acceptance/intel_iommu.py
> > @@ -55,8 +55,10 @@ def common_vm_setup(self, custom_kernel=None):
> >
> >  kernel_url = self.distro.pxeboot_url + 'vmlinuz'
> >  initrd_url = self.distro.pxeboot_url + 'initrd.img'
> > -self.kernel_path = self.fetch_asset(kernel_url)
> > -self.initrd_path = self.fetch_asset(initrd_url)
> > +self.kernel_path = self.fetch_asset(kernel_url,
> > + asset_hash=self.distro.pxeboot_vmlinuz_chksum)
> > +self.initrd_path = self.fetch_asset(initrd_url,
> > + asset_hash=self.distro.pxeboot_initrd_chksum)
> >
> >  def run_and_check(self):
> >  if self.kernel_path:
> >
> >>
> >> Best Regards
> >>
> >> Eric
> >>> History:
> >>> v3 -> v4:
> >>> - I added Wainer's refactoring of KNOWN_DISTROS
> >>> into a class (last patch) and took into account his comments.
> >>>
> >>> v2 -> v3:
> >>> - Added Intel IOMMU tests were added. Differ

Re: [PATCH v4 2/4] avocado_qemu: Add SMMUv3 tests

2021-07-05 Thread Willian Rampazzo
On Tue, Jun 29, 2021 at 11:36 AM Eric Auger  wrote:
>
> Add new tests checking the good behavior of the SMMUv3 protecting
> 2 virtio pci devices (block and net). We check the guest boots and
> we are able to install a package. Different guest configs are tested:
> standard, passthrough an strict=0. This is tested with both fedora 31 and
> 33. The former uses a 5.3 kernel without range invalidation whereas the
> latter uses a 5.8 kernel that features range invalidation.
>
> Signed-off-by: Eric Auger 
>
> ---
>
> v3 -> v4:
> - add tags for machine, distro in the class
> - removed smp and memory overrides
> - set default param value of common_vm_setup to False
>
> v1 -> v2:
> - removed ssh import
> - combined add_command_args() and common_vm_setup()
> - moved tags in class' docstring and added tags=arch:aarch64
> - use self.get_default_kernel_params()
> - added RIL tests with fed33 + introduce new tags
> ---
>  tests/acceptance/smmu.py | 132 +++
>  1 file changed, 132 insertions(+)
>  create mode 100644 tests/acceptance/smmu.py
>

As stated in the thread, this test does not need to run on CI, so with
the skipIf statement:

Reviewed-by: Willian Rampazzo 




Re: [PATCH v4 2/4] avocado_qemu: Add SMMUv3 tests

2021-07-05 Thread Willian Rampazzo
Hi Eric,

On Mon, Jul 5, 2021 at 5:00 AM Eric Auger  wrote:
>
> Hi Wainer,
>
> On 7/1/21 8:13 PM, Wainer dos Santos Moschetta wrote:
> > Hi,
> >
> > On 6/29/21 11:36 AM, Eric Auger wrote:
> >> Add new tests checking the good behavior of the SMMUv3 protecting
> >> 2 virtio pci devices (block and net). We check the guest boots and
> >> we are able to install a package. Different guest configs are tested:
> >> standard, passthrough an strict=0. This is tested with both fedora 31
> >> and
> >> 33. The former uses a 5.3 kernel without range invalidation whereas the
> >> latter uses a 5.8 kernel that features range invalidation.
> >>
> >> Signed-off-by: Eric Auger 
> >>
> >> ---
> >>
> >> v3 -> v4:
> >> - add tags for machine, distro in the class
> >> - removed smp and memory overrides
> >> - set default param value of common_vm_setup to False
> >>
> >> v1 -> v2:
> >> - removed ssh import
> >> - combined add_command_args() and common_vm_setup()
> >> - moved tags in class' docstring and added tags=arch:aarch64
> >> - use self.get_default_kernel_params()
> >> - added RIL tests with fed33 + introduce new tags
> >> ---
> >>   tests/acceptance/smmu.py | 132 +++
> >>   1 file changed, 132 insertions(+)
> >>   create mode 100644 tests/acceptance/smmu.py
> >
> > Reviewed-by: Wainer dos Santos Moschetta 
> >
> > Tested-by: Wainer dos Santos Moschetta 
> >
> > I tested it in a Fedora 32 aarch64 host. The execution output:
> >
> > # ./tests/venv/bin/avocado run tests/acceptance/smmu.py
> > JOB ID : 1625038f5a2ae17c8ba6c503d3df8661ff528942
> > JOB LOG:
> > /root/avocado/job-results/job-2021-07-01T13.38-1625038/job.log
> >  (1/6) tests/acceptance/smmu.py:SMMU.test_smmu_noril: PASS (175.54 s)
> >  (2/6) tests/acceptance/smmu.py:SMMU.test_smmu_noril_passthrough:
> > WARN: Test passed but there were warnings during execution. Check the
> > log for details. (168.39 s)
> >  (3/6) tests/acceptance/smmu.py:SMMU.test_smmu_noril_nostrict: WARN:
> > Test passed but there were warnings during execution. Check the log
> > for details. (161.58 s)
> >  (4/6) tests/acceptance/smmu.py:SMMU.test_smmu_ril: PASS (150.85 s)
> >  (5/6) tests/acceptance/smmu.py:SMMU.test_smmu_ril_passthrough: WARN:
> > Test passed but there were warnings during execution. Check the log
> > for details. (177.56 s)
> >  (6/6) tests/acceptance/smmu.py:SMMU.test_smmu_ril_nostrict: WARN:
> > Test passed but there were warnings during execution. Check the log
> > for details. (190.86 s)
> > RESULTS: PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 4 | INTERRUPT 0
> > | CANCEL 0
> > JOB TIME   : 1026.50 s
> >
> > One thing that caught my attention was the amount of time spent on
> > each test. It spend more than 2 minutes on the package installation
> > (`self.ssh_command('dnf -y install numactl-devel')`) in the guest.
> >
> > Without that operation, it runs way faster:
> >
> > # ./tests/venv/bin/avocado run tests/acceptance/smmu.py
> > JOB ID : 24f22f99169ece37df64d72d2eb373921f378aac
> > JOB LOG:
> > /root/avocado/job-results/job-2021-07-01T13.28-24f22f9/job.log
> >  (1/6) tests/acceptance/smmu.py:SMMU.test_smmu_noril: PASS (39.61 s)
> >  (2/6) tests/acceptance/smmu.py:SMMU.test_smmu_noril_passthrough:
> > WARN: Test passed but there were warnings during execution. Check the
> > log for details. (48.32 s)
> >  (3/6) tests/acceptance/smmu.py:SMMU.test_smmu_noril_nostrict: WARN:
> > Test passed but there were warnings during execution. Check the log
> > for details. (48.10 s)
> >  (4/6) tests/acceptance/smmu.py:SMMU.test_smmu_ril: PASS (39.22 s)
> >  (5/6) tests/acceptance/smmu.py:SMMU.test_smmu_ril_passthrough: WARN:
> > Test passed but there were warnings during execution. Check the log
> > for details. (52.92 s)
> >  (6/6) tests/acceptance/smmu.py:SMMU.test_smmu_ril_nostrict: WARN:
> > Test passed but there were warnings during execution. Check the log
> > for details. (50.96 s)
> > RESULTS: PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 4 | INTERRUPT 0
> > | CANCEL 0
> > JOB TIME   : 280.62 s
> >
> > Install a package seems a good exerciser for disk I/O and networking,
> > but maybe you can use another method for the sake of speed up the tests?
>
> As discussed earlier with Cleber, I am aware the test duration is long
> but it was useful finding bugs for SMMU with range invalidation. such a
> bug could not be hit with a single boot + ping for instance.
>
> Maybe we should have a mechanism that allows to put some tests out of
> the automatic CI?
>

You can use the skipIf decorator in the class. See here:
https://gitlab.com/willianrampazzo/qemu/-/commit/6f249845827ed041b55d275a8cb803666ac3c7af

Regards,

> Thanks
>
> Eric
> >
> > - Wainer
> >
> >>
> >> diff --git a/tests/acceptance/smmu.py b/tests/acceptance/smmu.py
> >> new file mode 100644
> >> index 00..c1d4b88e5f
> >> --- /dev/null
> >> +++ b/tests/acceptance/smmu.py
> >> @@ -0,0 +1,132 @@
> >> +# SMMUv3 Functional tests
> >> +#
> >> +# Copyright (c) 2021 Red

[PATCH v6 1/2] target/s390x: Fix SIGILL and SIGFPE psw.addr reporting

2021-07-05 Thread Ilya Leoshkevich
For SIGILL, SIGFPE and SIGTRAP the PSW must point after the
instruction, and at the instruction for other signals. Currently under
qemu-user for SIGFILL and SIGFPE it points at the instruction.

Fix by advancing psw.addr for these signals.

Buglink: https://gitlab.com/qemu-project/qemu/-/issues/319
Signed-off-by: Ilya Leoshkevich 
Co-developed-by: Ulrich Weigand 
---
 linux-user/s390x/cpu_loop.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/linux-user/s390x/cpu_loop.c b/linux-user/s390x/cpu_loop.c
index 30568139df..6e7dfb290a 100644
--- a/linux-user/s390x/cpu_loop.c
+++ b/linux-user/s390x/cpu_loop.c
@@ -64,7 +64,13 @@ void cpu_loop(CPUS390XState *env)
 case EXCP_DEBUG:
 sig = TARGET_SIGTRAP;
 n = TARGET_TRAP_BRKPT;
-goto do_signal_pc;
+/*
+ * For SIGTRAP the PSW must point after the instruction, which it
+ * already does thanks to s390x_tr_tb_stop(). si_addr doesn't need
+ * to be filled.
+ */
+addr = 0;
+goto do_signal;
 case EXCP_PGM:
 n = env->int_pgm_code;
 switch (n) {
@@ -133,6 +139,10 @@ void cpu_loop(CPUS390XState *env)
 
 do_signal_pc:
 addr = env->psw.addr;
+/*
+ * For SIGILL and SIGFPE the PSW must point after the instruction.
+ */
+env->psw.addr += env->int_pgm_ilen;
 do_signal:
 info.si_signo = sig;
 info.si_errno = 0;
-- 
2.31.1




  1   2   3   4   >