Re: [Qemu-devel] [PATCH] block: Override the driver in the filename with the user-specified one

[Alberto Garcia]

On Mon 24 Aug 2015 08:54:56 PM CEST, Max Reitz wrote:

  [bdrv_fill_options()]
> User-specified options should always have precedence over any other
> option. The thing is, we consider the filename to be specified by the
> user.

For user-specified options like the "lazy-refcounts" case that I
mentioned it makes sense, because that's the way the user wants to open
it.

For the image format it sounds counter-intuitive to me: the format is
already set when the file is opened, the user doesn't have a choice
there, or does she?

> So it is actually correct that this option overrides the @drv
> parameter given to bdrv_open(), because that cannot be set by the user
> and is always set by qemu internally.

Is that really the case?

The drv parameter of bdrv_open() is being set by the user in a number of
places: qmp_drive_backup(), qmp_drive_mirror(), qmp_change_blockdev()
and qemu-img create.

> So I think the problem here is not in bdrv_fill_options(), but rather
> in blockdev.c:external_snapshot_prepare(). This function should not
> pass the driver as the @drv parameter to bdrv_open(), but rather set
> the "driver" option in @options in order to mark this a user-specified
> option.

I guess in that case we should change that in all the other places I
mentioned above.

Berto

Re: [Qemu-devel] [PATCH COLO-Frame v8 00/34] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service (FT)

[zhanghailiang]

On 2015/8/24 22:38, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

This is the 8th version of COLO.


I'm seeing an occasional error:

   pcibus_reset: Assertion `bus->irq_count[i] == 0' failed.

on the secondary; have you seen that?

bus->irq_count[4] is -1 in my backtrace; it's
colo_process_incoming_checkpoints->qemu_devices_reset->qbus_walk_children->qbus_reset_one->pcibus_reset



No, we didn't come across such problem. Is there anything special for your test 
? What's your command line ?
Did it happen during the first checkpoint process ?

Thanks,
zhanghailiang


Dave


Here is only COLO frame part, include: VM checkpoint,
failover, proxy API, block replication API, not include block replication.
The block part is treated as a separate series.

As usual, we provide 'basic' and 'developing' branches in github:
https://github.com/coloft/qemu/commits/colo-v1.5-basic
https://github.com/coloft/qemu/commits/colo-v1.5-developing (more features)

The 'basic' branch is exactly the same with this patch series,
We will keep this series simple as possible, just for easy review.

The extra features in colo-v1.5-developing branch:
1) Separate ram and device save/load process to reduce size of extra memory
used during checkpoint
2) Live migrate part of dirty pages to slave during sleep time.
3) You get the statistic info about checkpoint by command 'info migrate'

Please reference to the follow link to test COLO.
http://wiki.qemu.org/Features/COLO.

COLO is a totally new feature which is still in early stage,
your comments and feedback are warmly welcomed.

NOTE:
We have decided to re-implement the colo proxy in userspace (In qemu exactly).
you can find the discussion about why & how to realize the colo proxy in qemu 
from the follow link:
http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg04069.html

TODO:
1. COLO function switch on/off
2. The capability of continuous FT
3. Optimize the performance.

v8:
- Move some global variables into MigrationIncomingState and MigrationState
- Move some cleanup work form colo thread and colo incoming thread into failover
   BH function and also fix the code logic for the cleanup work.
- fix the bug that colo thread and colo incoming thread possibly block in the
   socket 'recv' call when do failover work.
- Optimize colo_flush_ram_cache()
- Add migration state for incoming side, we use the state to verify if migration
   incoming side is in COLO state or not (Patch 5).
- Drop the patch 'COLO: Disable qdev hotplug when VM is in COLO mode', since it 
is not correct.

zhanghailiang (34):
   configure: Add parameter for configure to enable/disable COLO support
   migration: Introduce capability 'colo' to migration
   COLO: migrate colo related info to slave
   colo-comm/migration: skip colo info section for special cases
   migration: Add state records for migration incoming
   migration: Integrate COLO checkpoint process into migration
   migration: Integrate COLO checkpoint process into loadvm
   COLO: Implement colo checkpoint protocol
   COLO: Add a new RunState RUN_STATE_COLO
   QEMUSizedBuffer: Introduce two help functions for qsb
   COLO: Save VM state to slave when do checkpoint
   COLO RAM: Load PVM's dirty page into SVM's RAM cache temporarily
   COLO VMstate: Load VM state into qsb before restore it
   arch_init: Start to trace dirty pages of SVM
   COLO RAM: Flush cached RAM into SVM's memory
   COLO failover: Introduce a new command to trigger a failover
   COLO failover: Introduce state to record failover process
   COLO failover: Implement COLO primary/secondary vm failover work
   qmp event: Add event notification for COLO error
   COLO failover: Don't do failover during loading VM's state
   COLO: Add new command parameter 'forward_nic' 'colo_script' for net
   COLO NIC: Init/remove colo nic devices when add/cleanup tap devices
   tap: Make launch_script() public
   COLO NIC: Implement colo nic device interface configure()
   colo-nic: Handle secondary VM's original net device configure
   COLO NIC: Implement colo nic init/destroy function
   COLO NIC: Some init work related with proxy module
   COLO: Handle nfnetlink message from proxy module
   COLO: Do checkpoint according to the result of packets comparation
   COLO: Improve checkpoint efficiency by do additional periodic
 checkpoint
   COLO: Add colo-set-checkpoint-period command
   COLO NIC: Implement NIC checkpoint and failover
   COLO: Implement shutdown checkpoint
   COLO: Add block replication into colo process

  configure |  33 +-
  docs/qmp/qmp-events.txt   |  16 +
  hmp-commands.hx   |  30 ++
  hmp.c |  15 +
  hmp.h |   2 +
  include/exec/cpu-all.h|   1 +
  include/migration/colo.h  |  45 +++
  include/migration/failover.h  |  33 ++
  include/migration/migration.h |  19 +
  include/migration/qemu-file.h |   3 +-
  include/net/colo-nic.h|  37 ++
 

Re: [Qemu-devel] [RFC 2/4] hw/i386: Introduce AMD IOMMU

[David kiarie]

On Tue, Aug 25, 2015 at 9:39 AM, Valentine Sinitsyn
 wrote:
> Hi,
>
>
> On 25.08.2015 04:19, David Kiarie wrote:
>>
>> From: David 
>>
>> Add AMD IOMMU emulation to Qemu. This is a very basic AMD IOMMU
>> emulation that only does translation and some basic Event logging.
>> Guest translation enables nested PCI passthrough
>>
>> Signed-off-by: David Kiarie 
>> ---
>>   hw/i386/Makefile.objs |   1 +
>>   hw/i386/amd_iommu.c   | 993
>> ++
>>   hw/i386/amd_iommu.h   | 298 +++
>>   3 files changed, 1292 insertions(+)
>>   create mode 100644 hw/i386/amd_iommu.c
>>   create mode 100644 hw/i386/amd_iommu.h
>>
>> diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
>> index ebd1015..2bae11c 100644
>> --- a/hw/i386/Makefile.objs
>> +++ b/hw/i386/Makefile.objs
>> @@ -3,6 +3,7 @@ obj-y += multiboot.o
>>   obj-y += pc.o pc_piix.o pc_q35.o
>>   obj-y += pc_sysfw.o
>>   obj-y += intel_iommu.o
>> +obj-y += amd_iommu.o
>>   obj-$(CONFIG_XEN) += ../xenpv/ xen/
>>
>>   obj-y += kvmvapic.o
>> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
>> new file mode 100644
>> index 000..a3a0b20
>> --- /dev/null
>> +++ b/hw/i386/amd_iommu.c
>> @@ -0,0 +1,993 @@
>> +/*
>> + * QEMU emulation of an AMD IOMMU (AMD-Vi)
>> + *
>> + * Copyright (C) 2011 Eduard - Gabriel Munteanu
>> + * Copyright (C) 2015 David Kiarie, 
>> + *
>> + * 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 "hw/i386/amd_iommu.h"
>> +
>> +#define PCI_EXT_CAP_ID_PASID 0x1B
>> +#define PCI_EXT_CAP_ID_PRI   0x13
>> +
>> +#define PCI_SLOT(devfn)  (((devfn) >> 3) & 0x1f)
>> +#define PCI_FUNC(devfn)  ((devfn) & 0x07)
>> +
>> +#define MAX_VA_ADDR  (64UL << 5)
>> +#define MAX_PH_ADDR  (48UL << 8)
>> +#define MAX_GVA_ADDR (64UL << 15)
>> +
>> +//#define DEBUG_AMD_IOMMU
>> +#ifdef DEBUG_AMD_IOMMU
>> +enum {
>> +DEBUG_GENERAL, DEBUG_CAPAB, DEBUG_MMIO, DEBUG_ELOG,
>> +DEBUG_CACHE, DEBUG_COMMAND, DEBUG_MMU
>> +};
>> +
>> +#define IOMMU_DBGBIT(x)   (1 << DEBUG_##x)
>> +static int iommu_dbgflags = IOMMU_DBGBIT(GENERAL) | IOMMU_DBGBIT(MMU) |
>> IOMMU_DBGBIT(MMIO);
>> +//| IOMMU_DBGBIT(CAPAB) | IOMMU_DBGBIT(ELOG) | IOMMU_DBGBIT(CACHE) |
>> IOMMU_DBGBIT(COMMAND);
>> +
>> +#define IOMMU_DPRINTF(what, fmt, ...) do { \
>> +if (iommu_dbgflags & IOMMU_DBGBIT(what)) { \
>> +fprintf(stderr, "(amd-iommu)%s: " fmt "\n", __func__, \
>> +## __VA_ARGS__); } \
>> +} while (0)
>> +#else
>> +#define IOMMU_DPRINTF(what, fmt, ...) do {} while (0)
>> +#endif
>> +
>> +/* helper functions - FIXME - provide for reading one byte */
>> +static uint16_t amd_iommu_readw(AMDIOMMUState *s, hwaddr addr)
>> +{
>> +return lduw_le_p(&s->mmior[addr]);
>> +}
>> +
>> +static uint32_t amd_iommu_readl(AMDIOMMUState *s, hwaddr addr)
>> +{
>> +return ldl_le_p(&s->mmior[addr]);
>> +}
>> +
>> +static uint64_t amd_iommu_readq(AMDIOMMUState *s, hwaddr addr)
>> +{
>> +return ldq_le_p(&s->mmior[addr]);
>> +}
>> +
>> +static void amd_iommu_writew(AMDIOMMUState *s, hwaddr addr, uint16_t val)
>> +{
>> +stw_le_p(&s->mmior[addr], val);
>> +}
>> +
>> +static void amd_iommu_writel(AMDIOMMUState *s, hwaddr addr, uint32_t val)
>> +{
>> +stl_le_p(&s->mmior[addr], val);
>> +}
>> +
>> +static void amd_iommu_writeq(AMDIOMMUState *s, hwaddr addr, uint64_t val)
>> +{
>> +stq_le_p(&s->mmior[addr], val);
>> +}
>> +
>> +/* execute a completion wait command */
>> +static void amd_iommu_completion_wait(AMDIOMMUState *s, uint8_t *cmd)
>> +{
>> +unsigned int addr;
>> +
>> +/* completion store */
>> +if(cmd[0] & COM_COMPLETION_STORE_MASK){
>> +addr = le64_to_cpu(*(uint64_t*)cmd) & COM_STORE_ADDRESS_MASK;
>> +if(dma_memory_write(&address_space_memory, addr, cmd + 8, 8)){
>> +IOMMU_DPRINTF(ELOG, "error: fail to write at address
>> 0%x"PRIx64, addr);
>> +}
>> +
>> +}
>> +
>> +/* set completion interrupt */
>
> When I was experimenting with a real IOMMU, it all looked like if both
> COM_COMPLETION_STORE_MASK and COM_COMPLETION_BIT are set in the command,
> only an interrupt is generated. Could someone comment on this?

Which bit do you mean by COM_COMPLETION_BIT ?Do you mean
'COM_COMPLETION_INTR ? If yes, when would such a scenario occur ?

I have checked on from the spec, I can't f

[Qemu-devel] [Bug 1488363] [NEW] qemu 2.4.0 hangs using vfio for pci passthrough of graphics card

[Peter Maloney]

Public bug reported:

2.3.0 (manjaro distro package) works fine. 2.4.0 (manjaro or the arch
vanilla one) hangs on the SeaBIOS screen when saying "Press F12 for boot
menu". All tested with the same hardware, OS, command and configuration.
It also starts without the GPU passed through, even with the USB passed
through. I am using the latest SeaBIOS 1.8.2.

The release notes say:
 VFIO
Support for resetting AMD Bonaire and Hawaii GPUs
Platform device passthrough support for Calxeda xgmac devices 

So maybe something there broke it.

I am using the arch qemu 2.4.0 PKGBUILD (modified to have make -j8 and removed 
iscsi, gluster, ceph, etc.), which uses vanilla sources and no patches. 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qemu

I am not using a frontend. I am using a script I wrote that generates
the command below.

Guest OS here would be 64 bit windows 7, but it didn't start so that's
not relevant. Also a Manjaro Linux VM won't start.

CPU is AMD FX-8150; board is Gigabyte GA-990FXA-UD5 (990FX chipset).

full command line (without the \ after each line) is:

qemu-system-x86_64
-enable-kvm
-M q35
-m 3584
-cpu host
-boot c
-smp 7,sockets=1,cores=7,threads=1
-vga none
-device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1
-device 
vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom
-device vfio-pci,host=00:14.2,bus=pcie.0
-device vfio-pci,host=00:16.0,bus=root.1
-device vfio-pci,host=00:16.2,bus=root.1
-usb
-device ahci,bus=pcie.0,id=ahci
-drive 
file=/dev/data/vm1,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on
-drive media=cdrom,id=cdrom,index=5,media=cdrom
-netdev type=tap,id=net0,ifname=tap-vm1
-device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05
-monitor stdio
-boot menu=on


$ lspci -nn | grep -E "04:00.0|00:14.2|00:16.0|00:16.2"
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 
Azalia (Intel HDA) [1002:4383] (rev 40)
00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Bonaire XTX [Radeon R7 260X] [1002:6658]


Also I have this one that also hangs:
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba]

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu 2.4.0 hangs using vfio for pci passthrough of graphics card

Status in QEMU:
  New

Bug description:
  2.3.0 (manjaro distro package) works fine. 2.4.0 (manjaro or the arch
  vanilla one) hangs on the SeaBIOS screen when saying "Press F12 for
  boot menu". All tested with the same hardware, OS, command and
  configuration. It also starts without the GPU passed through, even
  with the USB passed through. I am using the latest SeaBIOS 1.8.2.

  The release notes say:
   VFIO
  Support for resetting AMD Bonaire and Hawaii GPUs
  Platform device passthrough support for Calxeda xgmac devices 
  
  So maybe something there broke it.
  
  I am using the arch qemu 2.4.0 PKGBUILD (modified to have make -j8 and 
removed iscsi, gluster, ceph, etc.), which uses vanilla sources and no patches. 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qemu

  I am not using a frontend. I am using a script I wrote that generates
  the command below.

  Guest OS here would be 64 bit windows 7, but it didn't start so that's
  not relevant. Also a Manjaro Linux VM won't start.

  CPU is AMD FX-8150; board is Gigabyte GA-990FXA-UD5 (990FX chipset).

  full command line (without the \ after each line) is:

  qemu-system-x86_64
  -enable-kvm
  -M q35
  -m 3584
  -cpu host
  -boot c
  -smp 7,sockets=1,cores=7,threads=1
  -vga none
  -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1
  -device 
vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom
  -device vfio-pci,host=00:14.2,bus=pcie.0
  -device vfio-pci,host=00:16.0,bus=root.1
  -device vfio-pci,host=00:16.2,bus=root.1
  -usb
  -device ahci,bus=pcie.0,id=ahci
  -drive 
file=/dev/data/vm1,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on
  -drive media=cdrom,id=cdrom,index=5,media=cdrom
  -netdev type=tap,id=net0,ifname=tap-vm1
  -device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05
  -monitor stdio
  -boot menu=on

  
  $ lspci -nn | grep -E "04:00.0|00:14.2|00:16.0|00:16.2"
  00:14.2 Aud

Re: [Qemu-devel] [RFC 2/4] hw/i386: Introduce AMD IOMMU

[David kiarie]

On Tue, Aug 25, 2015 at 10:31 AM, Valentine Sinitsyn
 wrote:
>
>
> On 25.08.2015 12:25, David kiarie wrote:
>>
>> On Tue, Aug 25, 2015 at 9:39 AM, Valentine Sinitsyn
>>  wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 25.08.2015 04:19, David Kiarie wrote:


 From: David 

 Add AMD IOMMU emulation to Qemu. This is a very basic AMD IOMMU
 emulation that only does translation and some basic Event logging.
 Guest translation enables nested PCI passthrough

 Signed-off-by: David Kiarie 
 ---
hw/i386/Makefile.objs |   1 +
hw/i386/amd_iommu.c   | 993
 ++
hw/i386/amd_iommu.h   | 298 +++
3 files changed, 1292 insertions(+)
create mode 100644 hw/i386/amd_iommu.c
create mode 100644 hw/i386/amd_iommu.h

 diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
 index ebd1015..2bae11c 100644
 --- a/hw/i386/Makefile.objs
 +++ b/hw/i386/Makefile.objs
 @@ -3,6 +3,7 @@ obj-y += multiboot.o
obj-y += pc.o pc_piix.o pc_q35.o
obj-y += pc_sysfw.o
obj-y += intel_iommu.o
 +obj-y += amd_iommu.o
obj-$(CONFIG_XEN) += ../xenpv/ xen/

obj-y += kvmvapic.o
 diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
 new file mode 100644
 index 000..a3a0b20
 --- /dev/null
 +++ b/hw/i386/amd_iommu.c
 @@ -0,0 +1,993 @@
 +/*
 + * QEMU emulation of an AMD IOMMU (AMD-Vi)
 + *
 + * Copyright (C) 2011 Eduard - Gabriel Munteanu
 + * Copyright (C) 2015 David Kiarie, 
 + *
 + * 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 "hw/i386/amd_iommu.h"
 +
 +#define PCI_EXT_CAP_ID_PASID 0x1B
 +#define PCI_EXT_CAP_ID_PRI   0x13
 +
 +#define PCI_SLOT(devfn)  (((devfn) >> 3) & 0x1f)
 +#define PCI_FUNC(devfn)  ((devfn) & 0x07)
 +
 +#define MAX_VA_ADDR  (64UL << 5)
 +#define MAX_PH_ADDR  (48UL << 8)
 +#define MAX_GVA_ADDR (64UL << 15)
 +
 +//#define DEBUG_AMD_IOMMU
 +#ifdef DEBUG_AMD_IOMMU
 +enum {
 +DEBUG_GENERAL, DEBUG_CAPAB, DEBUG_MMIO, DEBUG_ELOG,
 +DEBUG_CACHE, DEBUG_COMMAND, DEBUG_MMU
 +};
 +
 +#define IOMMU_DBGBIT(x)   (1 << DEBUG_##x)
 +static int iommu_dbgflags = IOMMU_DBGBIT(GENERAL) | IOMMU_DBGBIT(MMU) |
 IOMMU_DBGBIT(MMIO);
 +//| IOMMU_DBGBIT(CAPAB) | IOMMU_DBGBIT(ELOG) | IOMMU_DBGBIT(CACHE) |
 IOMMU_DBGBIT(COMMAND);
 +
 +#define IOMMU_DPRINTF(what, fmt, ...) do { \
 +if (iommu_dbgflags & IOMMU_DBGBIT(what)) { \
 +fprintf(stderr, "(amd-iommu)%s: " fmt "\n", __func__, \
 +## __VA_ARGS__); } \
 +} while (0)
 +#else
 +#define IOMMU_DPRINTF(what, fmt, ...) do {} while (0)
 +#endif
 +
 +/* helper functions - FIXME - provide for reading one byte */
 +static uint16_t amd_iommu_readw(AMDIOMMUState *s, hwaddr addr)
 +{
 +return lduw_le_p(&s->mmior[addr]);
 +}
 +
 +static uint32_t amd_iommu_readl(AMDIOMMUState *s, hwaddr addr)
 +{
 +return ldl_le_p(&s->mmior[addr]);
 +}
 +
 +static uint64_t amd_iommu_readq(AMDIOMMUState *s, hwaddr addr)
 +{
 +return ldq_le_p(&s->mmior[addr]);
 +}
 +
 +static void amd_iommu_writew(AMDIOMMUState *s, hwaddr addr, uint16_t
 val)
 +{
 +stw_le_p(&s->mmior[addr], val);
 +}
 +
 +static void amd_iommu_writel(AMDIOMMUState *s, hwaddr addr, uint32_t
 val)
 +{
 +stl_le_p(&s->mmior[addr], val);
 +}
 +
 +static void amd_iommu_writeq(AMDIOMMUState *s, hwaddr addr, uint64_t
 val)
 +{
 +stq_le_p(&s->mmior[addr], val);
 +}
 +
 +/* execute a completion wait command */
 +static void amd_iommu_completion_wait(AMDIOMMUState *s, uint8_t *cmd)
 +{
 +unsigned int addr;
 +
 +/* completion store */
 +if(cmd[0] & COM_COMPLETION_STORE_MASK){
 +addr = le64_to_cpu(*(uint64_t*)cmd) & COM_STORE_ADDRESS_MASK;
 +if(dma_memory_write(&address_space_memory, addr, cmd + 8, 8)){
 +IOMMU_DPRINTF(ELOG, "error: fail to write at address
 0%x"PRIx64, addr);
 +}
 +
 +  

Re: [Qemu-devel] qemu-doc.texi: Improve USB documentation... and maybe even QEMU also

[Markus Armbruster]

Programmingkid  writes:

> On Aug 24, 2015, at 12:38 PM, Markus Armbruster wrote:
>
>> Programmingkid  writes:
>> 
>>> On Aug 24, 2015, at 5:45 AM, Markus Armbruster wrote:
>>> 
 Copying the USB maintainer.
 
 Programmingkid  writes:
 
> On Aug 8, 2015, at 8:48 AM, Programmingkid wrote:
> 
>> 
>> On Aug 8, 2015, at 2:04 AM, Markus Armbruster wrote:
 
 USB devices can be connected with the @option{-usbdevice}
 commandline option
 -or the @code{usb_add} monitor command.  Available devices are:
 +or the @code{usb_add} monitor command. Note: some devices may
 only work if
 +added like this: -usb -device . Available devices are:
>>> 
>>> I'm afraid "may only work" is a bit misleading.  All of them work with
>>> -device.  Old ones are also supported by -usbdevice for backward
>>> compatibility.  The whole section should be rewritten to point to
>>> -device instead of legacy -usbdevice, but that's no reason to hold up
>>> your patch.
>> 
>> I did not know -usbdevice was considered legacy. If that is the
>> case, then it should probably
>> be removed from the documentation in favor for -usb -device
>> .
> 
> Right now using "-usb -device mouse" doesn't work.
 
 You need to say -device usb-mouse.  See docs/qdev-device-use.txt.  Does
 it work for you when you do that?
>>> 
>>> It does. Thank you for this information. 
>> 
>> My pleasure.
>> 
>  Neither does
> "-usbdevice usb-audio".
 
 Yes.  Legacy -usbdevice only supports the devices that predate -device.
 
> I think we can all agree that consistency among all the USB devices is
> a good thing.
> Should all USB devices be added like this: -usb -device  ? 
 
 "Should" is perhaps a bit strong.  While -device is the recommended way
 to add a USB device, -usbdevice is still a supported (if legacy) way to
 do it.
 
 Of course, "supported, but legacy" interfaces such as -usbdevice may
 become deprecated, and then you should really move to newer interfaces,
 because deprecated ones may go away.  Doesn't look terribly probable to
 me for -usbdevice, though.
 
> This is an experimental patch of not how QEMU currently works, but how
> I think it should work.
> 
> This documentation adds an "usb_remove" monitor command. This isn't
> available right now,
> but a patch could be made to change this. Any suggestions or additions
> are welcomed.
 
 Why do you think we need usb_remove in addition to device_del?
>>> 
>>> Ok. usb_remove isn't needed. Why is it that "device_add usb-kbd" works, but
>>> "device_del usb-kbd" doesn't work? I am given this error message:
>>> "Device 'usb-kbd' not found".
>> 
>> device_del's argument isn't a driver, it's a device ID.  Try this:
>> 
>>(qemu) device_add usb-mouse,id=mouse0
>>(qemu) info usb
>>  Device 0.0, Port 1, Speed 12 Mb/s, Product QEMU USB Mouse
>>(qemu) device_del mouse0
>>(qemu) info usb
>>(qemu) 
>
> The problem is with "info usb". It doesn't print the id you gave it. I
> will make a patch that
> will print the id's. 

Yes, "info usb" doesn't show the qdev ID.  Neither does "info pci".
"info qom" and "info qtree" do.

Re: [Qemu-devel] [PATCH v1 2/3] object.c: object_class_dynamic_cast return NULL if the class has no type

[Peter Crosthwaite]

On Mon, Aug 24, 2015 at 4:36 PM, Alistair Francis
 wrote:
> On Mon, Aug 17, 2015 at 4:37 PM, Peter Crosthwaite
>  wrote:
>> On Mon, Aug 17, 2015 at 3:33 PM, Andreas Färber  wrote:
>>> Am 18.08.2015 um 00:24 schrieb Alistair Francis:
 On Sat, Aug 15, 2015 at 2:22 PM, Peter Crosthwaite
  wrote:
> On Mon, Jul 27, 2015 at 11:37 AM, Alistair Francis
>  wrote:
>> If the ObjectClass has no type return NULL instead of trying to compare
>> the type name.
>>
>
> What was the issue?

 There is a seg fault in object_class_dynamic_cast() because there is
 no type in the ObjectClass struct.
>>>
>>> That should never happen, ever since TYPE_OBJECT is no longer NULL.
>>>
 It happens when it is trying to cast the "pci-device", which is called
 from the ahci_irq_lower() function. The function is testing if the
 device is a pci device, so it should return NULL if it isn't valid.
>>
>> Yes so I vaguely remember this now. It is about MSI interrupts which
>> have nothing to do with sysbus implementation. My solution was to rip
>> that PCI specific stuff out of AHCI completely in my branch. Should
>> sysbus and PCI AHCI classes install their own separate logic for this
>> part via a virtualised hook?
>>
>> On the topic though, I notice many PCI devices have this MSI specific
>> logic in them. Is it possible for devs to just treat interrupts as
>> pins and the PCI layers do the MSI vs non-MSI logic switch in core
>> layers?
>>
>> If Andreas' idea don't work this is still a core QOM bug though. I
>> think object_dynamic_cast should not have this segfault when passed a
>> non implementing object.
>>
>> Regards,
>> Peter
>>
>>>
>>> It rather sounds as if some build-time dependency is wrong, which we
>>> used to run into for the Container type before Paolo macrofied this.
>>>
>>> Please try again with a clean build - if it still occurs, we'll need a
>>> reproducible test case to investigate what is going on rather than
>>> papering over a latent bug.
>
> Hey,
>
> Sorry abut the delay, but I didn't get a chance to look at this last
> week. I tried with a clean setup and still see the seg fault.
>
> I will try to look into it more this week, but if anyone is interested
> here are the steps to reproduce:
>
> On the latest mainline QEMU, with my 2nd and 3rd patches applied
> $ ./configure --target-list="aarch64-softmmu,microblazeel-softmmu"
> --disable-pie --disable-sdl --disable-werror # This is what is
> required at work
> $ ./aarch64-softmmu/qemu-system-aarch64 -M xlnx-ep108 -display none
> -kernel ./u-boot.elf -m 800 -nographic -serial mon:stdio # Boot
> u-boot on QEMU
>
> The image I'm using is available at: http://1drv.ms/1NxDXLo
>

So it's not a core bug. That container_of in ahci_lower_irq is
incorrectly assuming that the passed AHCIState * is always for a PCI,
which it is not in the sysbus case. So it's incorrectly getting the
offset of QOM the object and the QOM cast is treating some invalid
offset into the (or past) object as a QOM object base address.

The simplest solution is a back pointer in AHCIState to the
encapsulating device (would be a DeviceState *). The container_of is
replaced with a nav of this pointer and then the conditional PCI cast
can work.

Regards,
Peter

> Thanks,
>
> Alistair
>
>>>
>>> Thanks,
>>> Andreas
>>>
>>> --
>>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
>>

Re: [Qemu-devel] [RFC 2/4] hw/i386: Introduce AMD IOMMU

[David kiarie]

Also, am not sure what HATS, GATS and sizes of virtual addresses(for
both guest and host) I should be using.

On Tue, Aug 25, 2015 at 10:41 AM, David kiarie  wrote:
> On Tue, Aug 25, 2015 at 10:31 AM, Valentine Sinitsyn
>  wrote:
>>
>>
>> On 25.08.2015 12:25, David kiarie wrote:
>>>
>>> On Tue, Aug 25, 2015 at 9:39 AM, Valentine Sinitsyn
>>>  wrote:

 Hi,


 On 25.08.2015 04:19, David Kiarie wrote:
>
>
> From: David 
>
> Add AMD IOMMU emulation to Qemu. This is a very basic AMD IOMMU
> emulation that only does translation and some basic Event logging.
> Guest translation enables nested PCI passthrough
>
> Signed-off-by: David Kiarie 
> ---
>hw/i386/Makefile.objs |   1 +
>hw/i386/amd_iommu.c   | 993
> ++
>hw/i386/amd_iommu.h   | 298 +++
>3 files changed, 1292 insertions(+)
>create mode 100644 hw/i386/amd_iommu.c
>create mode 100644 hw/i386/amd_iommu.h
>
> diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
> index ebd1015..2bae11c 100644
> --- a/hw/i386/Makefile.objs
> +++ b/hw/i386/Makefile.objs
> @@ -3,6 +3,7 @@ obj-y += multiboot.o
>obj-y += pc.o pc_piix.o pc_q35.o
>obj-y += pc_sysfw.o
>obj-y += intel_iommu.o
> +obj-y += amd_iommu.o
>obj-$(CONFIG_XEN) += ../xenpv/ xen/
>
>obj-y += kvmvapic.o
> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> new file mode 100644
> index 000..a3a0b20
> --- /dev/null
> +++ b/hw/i386/amd_iommu.c
> @@ -0,0 +1,993 @@
> +/*
> + * QEMU emulation of an AMD IOMMU (AMD-Vi)
> + *
> + * Copyright (C) 2011 Eduard - Gabriel Munteanu
> + * Copyright (C) 2015 David Kiarie, 
> + *
> + * 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 "hw/i386/amd_iommu.h"
> +
> +#define PCI_EXT_CAP_ID_PASID 0x1B
> +#define PCI_EXT_CAP_ID_PRI   0x13
> +
> +#define PCI_SLOT(devfn)  (((devfn) >> 3) & 0x1f)
> +#define PCI_FUNC(devfn)  ((devfn) & 0x07)
> +
> +#define MAX_VA_ADDR  (64UL << 5)
> +#define MAX_PH_ADDR  (48UL << 8)
> +#define MAX_GVA_ADDR (64UL << 15)
> +
> +//#define DEBUG_AMD_IOMMU
> +#ifdef DEBUG_AMD_IOMMU
> +enum {
> +DEBUG_GENERAL, DEBUG_CAPAB, DEBUG_MMIO, DEBUG_ELOG,
> +DEBUG_CACHE, DEBUG_COMMAND, DEBUG_MMU
> +};
> +
> +#define IOMMU_DBGBIT(x)   (1 << DEBUG_##x)
> +static int iommu_dbgflags = IOMMU_DBGBIT(GENERAL) | IOMMU_DBGBIT(MMU) |
> IOMMU_DBGBIT(MMIO);
> +//| IOMMU_DBGBIT(CAPAB) | IOMMU_DBGBIT(ELOG) | IOMMU_DBGBIT(CACHE) |
> IOMMU_DBGBIT(COMMAND);
> +
> +#define IOMMU_DPRINTF(what, fmt, ...) do { \
> +if (iommu_dbgflags & IOMMU_DBGBIT(what)) { \
> +fprintf(stderr, "(amd-iommu)%s: " fmt "\n", __func__, \
> +## __VA_ARGS__); } \
> +} while (0)
> +#else
> +#define IOMMU_DPRINTF(what, fmt, ...) do {} while (0)
> +#endif
> +
> +/* helper functions - FIXME - provide for reading one byte */
> +static uint16_t amd_iommu_readw(AMDIOMMUState *s, hwaddr addr)
> +{
> +return lduw_le_p(&s->mmior[addr]);
> +}
> +
> +static uint32_t amd_iommu_readl(AMDIOMMUState *s, hwaddr addr)
> +{
> +return ldl_le_p(&s->mmior[addr]);
> +}
> +
> +static uint64_t amd_iommu_readq(AMDIOMMUState *s, hwaddr addr)
> +{
> +return ldq_le_p(&s->mmior[addr]);
> +}
> +
> +static void amd_iommu_writew(AMDIOMMUState *s, hwaddr addr, uint16_t
> val)
> +{
> +stw_le_p(&s->mmior[addr], val);
> +}
> +
> +static void amd_iommu_writel(AMDIOMMUState *s, hwaddr addr, uint32_t
> val)
> +{
> +stl_le_p(&s->mmior[addr], val);
> +}
> +
> +static void amd_iommu_writeq(AMDIOMMUState *s, hwaddr addr, uint64_t
> val)
> +{
> +stq_le_p(&s->mmior[addr], val);
> +}
> +
> +/* execute a completion wait command */
> +static void amd_iommu_completion_wait(AMDIOMMUState *s, uint8_t *cmd)
> +{
> +unsigned int addr;
> +
> +/* completion store */
> +if(cmd[

Re: [Qemu-devel] [PATCH] target-sparc: Store mmu index in TB flags

[Dennis Luehring]

Am 25.08.2015 um 08:44 schrieb Artyom Tarasenko:

>your patch gives the worst result in stream benchmark but nearly the best in
>pugixml compile times and prime.c runtime
>every tried patch or branch nearly halfs the speed of the stream benchmark
>comapred to qemu-git-master

This is very surprising: the patch should have no effect on a sun4u machine.
Have you applied it to the master or some other branch?
Have you pulled the master branch recently? Maybe there was another
change affecting the performance?


i've completely removed my git qemu folder and freshly cloned the 
qemu-master, applied the patch

and rechecked if applied - and these are my numbers
i always remove my qemu-master (i always use master, other branch or 
clean master + patch) and build completely and im always using the same

settings, remadisk etc. for compilation and benchmarking

and its not realy surprising - there are ~5 people in the talk - each 
with different ideas where the slowness
comes from and all use different or non formalized "bechmark-suits" 
(like your combination or my 3 tests) -
each test i've made seems to give wired or suprising results - so my 
conclusion is: no one realy knows what it is and where it
comes from - and as long as there is no equal benchmark-suite (for 
example NetBSD + the 3 tests) it will go on to be

surprising or wired when i post results

Example:

at first it was - your RAM is full, your system is swapping, your 
harddisk is slow etc. talks with "Artyom Tarasenko", "Aurelien Jarno" 
and some others
- none of these are a problem - i've got more then enough RAM and CPU 
power in my host and free in the guest, and using a ramdisk for the 
image make IO less noisy


"Aurelien Jarno" said it could be the 32bit userland in the my debian 
7.8 SPARC64 system - and showed numbers with prime.c that proves it
i've rechecked that and came to the same results and switched over to 
NetBSD SPARC64 (a pure 64bit system) that make prime.c the fastest
but that does not realy reduce the pugixml compile times (my host needs 
3sek, NetBSD takes ~3minutes, building cmake need ~10 hours or longer)


then someone said it could be IO - so i put the NetBSD image on a 
ramdisk - helped a little


then "Karel Gardas" got the idea that the compilation process is primary 
memory bound - so asked me to use the stream-benchmark - i've posting 
results on every change
and i still don't know if the numbers im getting from the benchmark are 
relevant in any way (no one realy replies to them) - but they seems to 
be very relevant


then i've tested the branch from tgc-indirect branch - prime.c get a 
little better, stream get slower


the last patch from Richard Henderson gives still unclear results - 
prime.c get a little better, stream get the slowest


the next thing i will do is a complete script based qemu-compilation and 
benchmark run in my NetBSD image - then the human-factor is down to 0% 
and the

only source of suprising/wired results is my host-hardware

is threre any interest in my NetBSD image (or the installation process)? 
(to have a change to get to similar results in the differences)

should i add some other tests?
what is usualy in use for performance tests? still no answer on that 
question


im ready and happy to compile/run all your got/want :)

Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code

[Markus Armbruster]

Eric Blake  writes:

> On 08/24/2015 11:07 AM, Markus Armbruster wrote:
>
>>> You can prevent GTK+ from calling setlocale() by using
>>> gtk_disable_setlocale() before gtk_init(), but note that setlocale() is
>>> needed for gettext.
>> 
>> We can
>> 
>> (A) Internationalize our complete code base
>> 
>> (B) Run in the C locale
>> 
>> Breaks GTK's internationalization.
>> 
>> (C) Run in a mixed locale
>> 
>> Whenever something breaks, we switch another LC_ to the C locale.
>> 
>> Can partially break GTK's internationalization.
>> 
>> I happily concede that (A) would be best.  Until the manpower to pull it
>> off appears, I recommend (B), because it's safer than (C), and avoids
>> inconsistent localization, such as German messages combined with
>> non-German number formatting.
>
> Is it still possible for:
>
> (D) Run in a controlled mixed locale
>GTK runs completely in the locale determined by setlocale() (since it
> never has to display raw JSON)
>We fix our JSON output code to use thread-specific locale
> manipulations to (temporarily) switch to C locale before printing JSON
>
> that way, GTK still shows full German formatting for any localized
> message in the GUI that happens to print numbers, but the JSON output
> (which is independent of the GUI) also behaves correctly as a C-only entity.

Switching back to C locale whenever some unwanted locale-dependency
breaks the code is problematic, because it involves finding all the
places that break, iteratively (euphemism for "we debug one breakage
after the other, adding temporary locale switches as we go).

I'd feel much better about confining GTK in its own thread, and setting
only that thread's locale.

If that's impractical, perhaps we can switch locale just around GTK
code.  Thread-locally, of course.

> I don't know how well mingw supports thread-specific locales (POSIX
> requires it, but we all know that mingw is behind the curve when it
> comes to POSIX...); BSD and glibc should be okay, though.

I have no idea.  We could have configure checking whether we have
thread-local locale, and if not, disable internationalization entirely.

Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code

[Alberto Garcia]

On Tue 25 Aug 2015 09:54:42 AM CEST, Markus Armbruster wrote:

> Switching back to C locale whenever some unwanted locale-dependency
> breaks the code is problematic, because it involves finding all the
> places that break, iteratively (euphemism for "we debug one breakage
> after the other, adding temporary locale switches as we go).
>
> I'd feel much better about confining GTK in its own thread, and
> setting only that thread's locale.

FWIW GTK+ is not thread safe, all GTK+ code must run in the same thread,
so that should already be happening. I assume however that it's the same
thread that runs the monitor, so that might not be a solution in the
end.

Berto

Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

[tu bo]

Hi Christian:

Test case 068(qemu/tests/qemu-iotests/068, which is for loading a saved 
VM state from a qcow2 image)
was broken because s390-virtio-ccw uses the new bootloader of 
s390-ccw.img, instead of s390-zipl.rom.


1. qemu-img create -f qcow2 scratch/t.qcow2 64M
2. [root@r17lp42 qemu-iotests]# ../../s390x-softmmu/qemu-system-s390x
-nodefaults -nographic -monitor stdio -serial none  -hda scratch/t.qcow2
QEMU 2.3.94 monitor - type 'help' for more information
(qemu) [root@r17lp42 qemu-iotests]#
3. I can get error message from s390-ccw.img as below,
Using guessed DASD geometry.
Using ECKD scheme (block size  4096),
CDL
! No zIPL section in IPL2 record. !

in qemu/pc-bios/s390-ccw/bootmap.c
213 static void ipl_eckd_cdl(void)
214 {
215 XEckdMbr *mbr;
216 Ipl2 *ipl2 = (void *)sec;
217 IplVolumeLabel *vlbl = (void *)sec;
218 block_number_t block_nr;
219
220 /* we have just read the block #0 and recognized it as "IPL1" */
*221 sclp_print("CDL\n");*
222
223 memset(sec, FREE_SPACE_FILLER, sizeof(sec));
224 read_block(1, ipl2, "Cannot read IPL2 record at block 1");
225
226 mbr = &ipl2->u.x.mbr;
227 IPL_assert(magic_match(mbr, ZIPL_MAGIC), "*No zIPL section in IPL2 
record.*");

We may have two solutions,
1. providing a very small linux image(assuming name is t.qcow2) for s390x which can 
be IPLed, via "s390x-softmmu/qemu-system-s390x
-nodefaults -nographic -monitor stdio -serial none -hda scratch/t.qcow2"
2. disable test case 068 for s390x

What's your opinion?  thanks


On 08/20/2015 10:57 PM, Alexander Graf wrote:


On 20.08.15 01:20, tu bo wrote:

Hi Alex:

Ping you again just in case you did not get my mail  :-)

On 08/13/2015 03:52 PM, tu bo wrote:

Hi Alex:

I added one disk device for test case 068(qemu/tests/qemu-iotests/068,
which is for for loading a saved VM state from a qcow2 image ),
and got the same problem for s390-virtio-ccw.  Below is my steps:
1. qemu-img create -f qcow2 scratch/t.qcow2 64M
2. [root@r17lp42 qemu-iotests]# ../../s390x-softmmu/qemu-system-s390x
-nodefaults -nographic -monitor stdio -serial none  -hda scratch/t.qcow2
QEMU 2.3.94 monitor - type 'help' for more information
(qemu) [root@r17lp42 qemu-iotests]#

For s390-virtio,  test result is as expected
1. qemu-img create -f qcow2 scratch/t.qcow2 64M
2. [root@r17lp42 qemu-iotests]# qemu-system-s390x -nodefaults
-nographic -monitor stdio -serial none  -hda scratch/t.qcow2
QEMU 2.3.50 monitor - type 'help' for more information
(qemu) info roms
addr=9000 size=0x000ce8 mem=ram
name="/usr/share/qemu/s390-zipl.rom"
(qemu) savevm 0
(qemu)
(qemu) quit
3.[root@r17lp42 qemu-iotests]# qemu-system-s390x -nodefaults
-nographic -monitor stdio -serial none  -hda scratch/t.qcow2 -loadvm 0
QEMU 2.3.50 monitor - type 'help' for more information
(qemu)

For x86-64, test result is as expected,
1. [gavin@oc646435 qemu-iotests]$ qemu-img create -f qcow2
scratch/t.qcow2 64M
2. [gavin@oc646435 qemu-iotests]$
../../x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic
-monitor stdio -serial none  -hda scratch/t.qcow2
QEMU 2.3.94 monitor - type 'help' for more information
(qemu) info roms
fw=genroms/kvmvapic.bin size=0x002400 name="kvmvapic.bin"
addr=fffc size=0x04 mem=rom name="bios-256k.bin"
/rom@etc/acpi/tables size=0x20 name="etc/acpi/tables"
/rom@etc/table-loader size=0x001000 name="etc/table-loader"
/rom@etc/acpi/rsdp size=0x24 name="etc/acpi/rsdp"
(qemu) savevm 0
(qemu)
3. [gavin@oc646435 qemu-iotests]$
../../x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic
-monitor stdio -serial none  -hda scratch/t.qcow2 -loadvm 0
QEMU 2.3.94 monitor - type 'help' for more information
(qemu)

Could you share me why s390-virtio-ccw has different behavior with
s390-virtio & x86_64 for this scenario?  thanks

Because the s390 folks at IBM thought it'd be cool to emit a panic
(read: shut down) in the ccw bootloader when there is a problem? ;)

If this breaks test cases for you, please coordinate with Christian
Borntraeger and Eugene Dvurechenski whether it makes sense to change it.


Alex

Re: [Qemu-devel] [PATCH RFC v3 30/32] qapi: New QMP command query-schema for QMP schema introspection

[Markus Armbruster]

Eric Blake  writes:

> On 08/24/2015 10:55 AM, Markus Armbruster wrote:
>
>> Our motivation for dropping nested structs was to avoid burning the
>> 'name': {} struct member syntax on a trivial and rarely used
>> convenience, and instead make it available for a way to specify member
>> attributes beyond name and type.
>> 
>> Is there a chance we want to define simple union cases with attributes
>> beyond tag value and type?
>
> You may have a valid point there.  It's hard to predict the future, but
> leaving dictionary open for future use is the most extensible approach.
>
> But in the patches I'm currently working on, I had only been adding
> support for anonymous types for the branches of flat unions; I
> intentionally left simple unions to REQUIRE a type name for the branches
> (because of the way we create a wrapper type around the single data
> member for introspection purposes).

I asked only about simple unions, but my question actually applies to
any kind of union.  In fact, we could decide to reserve the {} syntax
for extensions in the longhand syntactical form, and still burn it on
convenience in shorthand, sugared forms.

>> I think we have a better chance to answer that question after we clean
>> non-simple unions.
>
> Well, my proposed cleanup was figuring out a way to explicitly specify
> that for a given enum value, we add no additional members to the wire
> struct.  But there is a possible alternative syntax for that:
>
> { 'union': 'Union', 'base': 'Base', 'discriminator': 'type',
>   'data': { 'branch1': 'AdditionalMembers',
> 'branch2': null } }
>
> which uses 'null' in place of '{}' for the explicitly empty case, while
> still requiring a type name for all other branches.

Let's revisit this once we've figured out how to clean up union syntax.

>  I still think that
> requiring a user to explicitly list all branches of a union is a nice
> fail-safe (if the enum is extended, we are then reminded to update the
> union to match) that we don't currently have.

Missing case reminders are obviously useful for code switching over an
enumeration.  They're less useful for data.  A forgotten case in code
compiles fine, then fails (often catastrophically) at run time.  A
forgotten case in data simply won't compile (assuming a statically
checked language).

 Both Abort and ChardevDummy exist only because you need a type to
 declare a simple union case.  I'd like to explore cleaning up the
 convoluted union syntax first.  If we then still have a need for
 empty structs, we can consider optimizing them.
>>>
>>> And that's where my patches were headed - by allowing a dict instead of
>>> a type name for the branches of a flat union, the syntax for flat unions
>>> becomes simpler, and allows us to sanely represent a
>>> "no-additional-members" variant without needing 'Abort' as an empty type.
>> 
>> Empty cases in flat unions are not a problem: simply don't mention the
>> tag value.
>
> But that's opposite of the direction I want to move, where we require
> all branches to be listed, but have a clean way to document the branches
> that add no additional members to the variant object.

Let's figure out how to clean up union syntax first, and how to do empty
cases second.

>> I'd like to explore doing unions in schema syntax the way we represent
>> them internally and in introspection.  Basically get rid of the "need to
>> inherit the common members from a base" nonsense.
>
> I've already posted patches that would allow:
>
> { 'union': 'Union', 'base': { ... }, 'discriminator': 'type',
>   'data': { ... } }
>
> that is, allowing the base fields to be specified inline as an anonymous
> struct rather than having to create a one-off named struct for that task.
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02346.html

In my opinion, the whole 'base' business is a hack to inject additional
common members into a union.  If I remember correctly, Kevin did that
just to keep his flat union work minimally invasive.  Considering what
it took us to do introspection the not minimally invasive way, I can't
fault him for taking a shortcut.

In my recent KVM Forum talk, I showed the QAPI schema and introspection
value for SchemaInfo.  The former is a flat union with a struct base,
i.e. two types connected by a (non-trivial) inheritance relation.  The
latter is simpler: a single, straightforward variant record.  That's
what I'd like to have in the schema, too.

https://events.linuxfoundation.org/sites/events/files/slides/armbru-qemu-introspection.pdf

> But there's still the question of whether we want to always tie the
> union branches to an explicitly named enum, or whether it is nice to
> preserve the current simple union semantics that an implicit enum is
> created to cover all branches when an explicit enum type is not named.
> Conversely, I still want to get to the point that even a simple union
> can optionally document th

Re: [Qemu-devel] [PATCH 10/10] machine: Set MachineClass::name automatically

[Marcel Apfelbaum]

On 08/21/2015 12:54 AM, Eduardo Habkost wrote:

Now all TYPE_MACHINE subclasses use MACHINE_TYPE_NAME to generate the
class name. So instead of requiring each subclass to set
MachineClass::name manually, we can now set it automatically at the
TYPE_MACHINE class_base_init() function.

Signed-off-by: Eduardo Habkost 
---
  hw/arm/vexpress.c  | 2 --
  hw/arm/virt.c  | 1 -
  hw/core/machine.c  | 3 +++
  hw/ppc/mac_newworld.c  | 1 -
  hw/ppc/spapr.c | 4 
  hw/s390x/s390-virtio.c | 1 -
  vl.c   | 1 -
  7 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index a86979d..55aed2b 100644
--- a/hw/arm/vexpress.c
+++ b/hw/arm/vexpress.c
@@ -758,7 +758,6 @@ static void vexpress_a9_class_init(ObjectClass *oc, void 
*data)
  MachineClass *mc = MACHINE_CLASS(oc);
  VexpressMachineClass *vmc = VEXPRESS_MACHINE_CLASS(oc);

-mc->name = TYPE_VEXPRESS_A9_MACHINE;
  mc->desc = "ARM Versatile Express for Cortex-A9";

  vmc->daughterboard = &a9_daughterboard;;
@@ -769,7 +768,6 @@ static void vexpress_a15_class_init(ObjectClass *oc, void 
*data)
  MachineClass *mc = MACHINE_CLASS(oc);
  VexpressMachineClass *vmc = VEXPRESS_MACHINE_CLASS(oc);

-mc->name = TYPE_VEXPRESS_A15_MACHINE;
  mc->desc = "ARM Versatile Express for Cortex-A15";

  vmc->daughterboard = &a15_daughterboard;
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 5ba4b80..af985f6 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -960,7 +960,6 @@ static void virt_class_init(ObjectClass *oc, void *data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);

-mc->name = VIRT_MACHINE_NAME;
  mc->desc = "ARM Virtual Machine",
  mc->init = machvirt_init;
  mc->max_cpus = 8;
diff --git a/hw/core/machine.c b/hw/core/machine.c
index e50c4b7..a889d7a 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -305,8 +305,11 @@ static void machine_class_init(ObjectClass *oc, void *data)
  static void machine_class_base_init(ObjectClass *oc, void *data)
  {
  if (!object_class_is_abstract(oc)) {
+MachineClass *mc = MACHINE_CLASS(oc);
  const char *cname = object_class_get_name(oc);
  assert(g_str_has_suffix(cname, TYPE_MACHINE_SUFFIX));
+mc->name = g_strndup(cname,
+strlen(cname) - strlen(TYPE_MACHINE_SUFFIX));
  }
  }

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index a6b8209..70e7431 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -508,7 +508,6 @@ static void core99_machine_class_init(ObjectClass *oc, void 
*data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);

-mc->name = "mac99";
  mc->desc = "Mac99 based PowerMAC";
  mc->init = ppc_core99_init;
  mc->max_cpus = MAX_CPUS;
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 012b6ed..05926a3 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1919,7 +1919,6 @@ static void spapr_machine_2_1_class_init(ObjectClass *oc, 
void *data)
  { /* end of list */ }
  };

-mc->name = "pseries-2.1";
  mc->desc = "pSeries Logical Partition (PAPR compliant) v2.1";
  mc->compat_props = compat_props;
  }
@@ -1939,7 +1938,6 @@ static void spapr_machine_2_2_class_init(ObjectClass *oc, 
void *data)
  };
  MachineClass *mc = MACHINE_CLASS(oc);

-mc->name = "pseries-2.2";
  mc->desc = "pSeries Logical Partition (PAPR compliant) v2.2";
  mc->compat_props = compat_props;
  }
@@ -1959,7 +1957,6 @@ static void spapr_machine_2_3_class_init(ObjectClass *oc, 
void *data)
  };
  MachineClass *mc = MACHINE_CLASS(oc);

-mc->name = "pseries-2.3";
  mc->desc = "pSeries Logical Partition (PAPR compliant) v2.3";
  mc->compat_props = compat_props;
  }
@@ -1975,7 +1972,6 @@ static void spapr_machine_2_4_class_init(ObjectClass *oc, 
void *data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);

-mc->name = "pseries-2.4";
  mc->desc = "pSeries Logical Partition (PAPR compliant) v2.4";
  mc->alias = "pseries";
  mc->is_default = 1;
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index 43d6ccb..35c0ce2 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -334,7 +334,6 @@ static void s390_machine_class_init(ObjectClass *oc, void 
*data)
  MachineClass *mc = MACHINE_CLASS(oc);
  NMIClass *nc = NMI_CLASS(oc);

-mc->name = S390_MACHINE;
  mc->alias = "s390";
  mc->desc = "VirtIO based S390 machine";
  mc->init = s390_init;
diff --git a/vl.c b/vl.c
index b7ddfeb..870ee48 100644
--- a/vl.c
+++ b/vl.c
@@ -1432,7 +1432,6 @@ static void qemu_machine_class_init(ObjectClass *oc, void 
*data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);
  QEMUMachine *qm = data;
-mc->name = qm->name;
  mc->desc = qm->desc;
  mc->init = qm->init;
  mc->kvm_type = qm->kvm_type;



Nice!

Please forget the possible stupid question, but what happens with
*all* other machine types? Why don't we have 

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Marcel Apfelbaum]

On 08/24/2015 12:54 PM, Markus Armbruster wrote:

John Snow  writes:


On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:

* Eduardo Habkost (ehabk...@redhat.com) wrote:

Migration with q35 was not possible before commit
04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
an ich9-ahci device, that was marked as unmigratable. So all q35 machines
before pc-q35-2.4 were unmigratable, and there's no point in keeping
compatibility code for them.

Remove all old pc-q35 machine classes and keep only pc-q35-2.4.


But doesn't that mean that anyone who has a machine configured with one
of those machine types will suddenly find it wont start?

Dave



To some extent, all versions of this board prior to 2.4 should be
considered unsupported and we should discourage their use anyway.

If you really want, I suppose we could just alias them to 2.4 ...


I'd very much prefer an honest "won't start" over a silent change of the
machine type.

+1

Thanks,
Marcel



If we really want to bend over backwards for existing uses of these
machine types, we could make them error out with "use pc-q35-2.5
instead".  Since I don't think they exist outside testing, I wouldn't
bother.

Re: [Qemu-devel] [PATCH 01/10] machine: MACHINE_TYPE_NAME macro

[Marcel Apfelbaum]

On 08/21/2015 12:54 AM, Eduardo Habkost wrote:

The macro will be useful to ensure the machine class names follow the
right format to make machine class lookup by class name work correctly.

Signed-off-by: Eduardo Habkost 
---
  include/hw/boards.h | 6 ++
  vl.c| 2 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 3f84afd..178517c 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -40,6 +40,12 @@ void memory_region_allocate_system_memory(MemoryRegion *mr, 
Object *owner,
  int qemu_register_machine(QEMUMachine *m);

  #define TYPE_MACHINE_SUFFIX "-machine"
+
+/* Machine class name that needs to be used for class-name-based machine
+ * type lookup to work.
+ */
+#define MACHINE_TYPE_NAME(machinename) (machinename TYPE_MACHINE_SUFFIX)
+
  #define TYPE_MACHINE "machine"
  #undef MACHINE  /* BSD defines it and QEMU does not use it */
  #define MACHINE(obj) \
diff --git a/vl.c b/vl.c
index 584ca88..b7ddfeb 100644
--- a/vl.c
+++ b/vl.c
@@ -1447,7 +1447,7 @@ static void qemu_machine_class_init(ObjectClass *oc, void 
*data)

  int qemu_register_machine(QEMUMachine *m)
  {
-char *name = g_strconcat(m->name, TYPE_MACHINE_SUFFIX, NULL);
+char *name = g_strdup_printf(MACHINE_TYPE_NAME("%s"), m->name);
  TypeInfo ti = {
  .name   = name,
  .parent = TYPE_MACHINE,



Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH 09/10] machine: Ensure all TYPE_MACHINE subclasses have the right suffix

[Marcel Apfelbaum]

On 08/21/2015 12:54 AM, Eduardo Habkost wrote:

Now that all non-abstract TYPE_MACHINE subclasses have the -machine
suffix, add an assert to ensure this will be always true.

Signed-off-by: Eduardo Habkost 
---
  hw/core/machine.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index ac4654e..e50c4b7 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -302,6 +302,14 @@ static void machine_class_init(ObjectClass *oc, void *data)
  mc->default_ram_size = 128 * M_BYTE;
  }

+static void machine_class_base_init(ObjectClass *oc, void *data)
+{
+if (!object_class_is_abstract(oc)) {
+const char *cname = object_class_get_name(oc);
+assert(g_str_has_suffix(cname, TYPE_MACHINE_SUFFIX));
+}
+}
+
  static void machine_initfn(Object *obj)
  {
  MachineState *ms = MACHINE(obj);
@@ -472,6 +480,7 @@ static const TypeInfo machine_info = {
  .abstract = true,
  .class_size = sizeof(MachineClass),
  .class_init= machine_class_init,
+.class_base_init = machine_class_base_init,
  .instance_size = sizeof(MachineState),
  .instance_init = machine_initfn,
  .instance_finalize = machine_finalize,



Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH for-2.5] piix: Document coreboot-specific RAM size config register

[Marcel Apfelbaum]

On 08/07/2015 10:15 PM, Eduardo Habkost wrote:

The existing i440fx initialization code sets a PCI config register that
isn't documented anywhere in the Intel 440FX datasheet. Register 0x57 is
DRAMC (DRAM Control) and has nothing to do with the RAM size.

This was implemented in commit ec5f92ce6ac8ec09056be77e03c941be188648fa
because old coreboot code tried to read registers 0x5a-0x5f,0x56,0x57 to
get the RAM size from QEMU, but I couldn't find out why coreboot did
that. I assume it was a mistake, and the original code was supposed to
be reading the DRB[0-7] registers (offsets 0x60-0x67).

Document that coreboot-specific register offset in a macro and a
comment, for future reference.

Cc: Ed Swierk 
Cc: Richard Smith 
Signed-off-by: Eduardo Habkost 
---
References to coreboot commits:
* Original commit adding code reading register offsets
   0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x56, 0x57 to Intel 440bx code in
   coreboot:
   cb8eab482ff09ec256456312ef2d6e7710123551
* Commit adding the same register offsets to QEMU-specific
   coreboot code:
   9cf642bad3fdd2205ffdd83a3222a39855b1ceff
* coreboot commit replacing the weird register offsets with
   code that actually reads the DRB7 register, in the I440BX code:
   1a9c892d58c746aef0cb530481c214e63a6a6871
* coreboot commit replacing the weird register offets with
   code reading the CMOS in QEMU-specific code:
   7339f36961917814ed12d5a4e6f1fe19418b8aca
---
  hw/pci-host/piix.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index ad55f99..1cb25f3 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -117,6 +117,11 @@ struct PCII440FXState {
  #define I440FX_PAM_SIZE 7
  #define I440FX_SMRAM0x72

+/* Older coreboot versions (4.0 and older) read a config register that doesn't
+ * exist in real hardware, to get the RAM size from QEMU.
+ */
+#define I440FX_COREBOOT_RAM_SIZE 0x57
+
  static void piix3_set_irq(void *opaque, int pirq, int level);
  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
  static void piix3_write_config_xen(PCIDevice *dev,
@@ -394,7 +399,7 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
  if (ram_size > 255) {
  ram_size = 255;
  }
-d->config[0x57] = ram_size;
+d->config[I440FX_COREBOOT_RAM_SIZE] = ram_size;

Thanks! Another magic number has now an actual meaning.

Reviewed-by: Marcel Apfelbaum 


Thanks,
Marcel



  i440fx_update_memory_mappings(f);

Re: [Qemu-devel] [PATCH v2 1/4] pc: Remove redundant arguments from xen_hvm_init()

[Marcel Apfelbaum]

On 08/17/2015 09:42 PM, Eduardo Habkost wrote:

Remove arguments that can be found in PCMachineState.

Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* Change prototype on xen-hvm-stub.c too
---
  hw/i386/pc_piix.c|  4 +---
  hw/i386/pc_q35.c |  4 +---
  include/hw/xen/xen.h |  4 ++--
  xen-hvm-stub.c   |  3 +--
  xen-hvm.c| 25 -
  5 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9558467..2b7afc8 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -134,9 +134,7 @@ static void pc_init1(MachineState *machine)
  pcms->below_4g_mem_size = machine->ram_size;
  }

-if (xen_enabled() && xen_hvm_init(&pcms->below_4g_mem_size,
-  &pcms->above_4g_mem_size,
-  &ram_memory) != 0) {
+if (xen_enabled() && xen_hvm_init(pcms, &ram_memory) != 0) {
  fprintf(stderr, "xen hardware virtual machine initialisation 
failed\n");
  exit(1);
  }
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c07d65b..36dd6a4 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -125,9 +125,7 @@ static void pc_q35_init(MachineState *machine)
  pcms->below_4g_mem_size = machine->ram_size;
  }

-if (xen_enabled() && xen_hvm_init(&pcms->below_4g_mem_size,
-  &pcms->above_4g_mem_size,
-  &ram_memory) != 0) {
+if (xen_enabled() && xen_hvm_init(pcms, &ram_memory) != 0) {
  fprintf(stderr, "xen hardware virtual machine initialisation 
failed\n");
  exit(1);
  }
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 4356af4..e90931a 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -10,6 +10,7 @@

  #include "hw/irq.h"
  #include "qemu-common.h"
+#include "qemu/typedefs.h"

  /* xen-machine.c */
  enum xen_mode {
@@ -38,8 +39,7 @@ qemu_irq *xen_interrupt_controller_init(void);
  void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);

  #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
-int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
- MemoryRegion **ram_memory);
+int xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory);
  void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
 struct MemoryRegion *mr);
  void xen_modified_memory(ram_addr_t start, ram_addr_t length);
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index 46867d8..6a39425 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -47,8 +47,7 @@ void xen_modified_memory(ram_addr_t start, ram_addr_t length)
  {
  }

-int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
- MemoryRegion **ram_memory)
+int xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
  {
  return 0;
  }
diff --git a/xen-hvm.c b/xen-hvm.c
index 0408462..55bce3a 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -180,8 +180,7 @@ qemu_irq *xen_interrupt_controller_init(void)

  /* Memory Ops */

-static void xen_ram_init(ram_addr_t *below_4g_mem_size,
- ram_addr_t *above_4g_mem_size,
+static void xen_ram_init(PCMachineState *pcms,
   ram_addr_t ram_size, MemoryRegion **ram_memory_p)
  {
  MemoryRegion *sysmem = get_system_memory();
@@ -198,20 +197,20 @@ static void xen_ram_init(ram_addr_t *below_4g_mem_size,
  }

  if (ram_size >= user_lowmem) {
-*above_4g_mem_size = ram_size - user_lowmem;
-*below_4g_mem_size = user_lowmem;
+pcms->above_4g_mem_size = ram_size - user_lowmem;
+pcms->below_4g_mem_size = user_lowmem;
  } else {
-*above_4g_mem_size = 0;
-*below_4g_mem_size = ram_size;
+pcms->above_4g_mem_size = 0;
+pcms->below_4g_mem_size = ram_size;
  }
-if (!*above_4g_mem_size) {
+if (!pcms->above_4g_mem_size) {
  block_len = ram_size;
  } else {
  /*
   * Xen does not allocate the memory continuously, it keeps a
   * hole of the size computed above or passed in.
   */
-block_len = (1ULL << 32) + *above_4g_mem_size;
+block_len = (1ULL << 32) + pcms->above_4g_mem_size;
  }
  memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len,
 &error_abort);
@@ -229,12 +228,12 @@ static void xen_ram_init(ram_addr_t *below_4g_mem_size,
   */
  memory_region_init_alias(&ram_lo, NULL, "xen.ram.lo",
   &ram_memory, 0xc,
- *below_4g_mem_size - 0xc);
+ pcms->below_4g_mem_size - 0xc);
  memory_region_add_subregion(sysmem, 0xc, &ram_lo);
-if (*above_4g_mem_size > 0) {
+if (pcms->above_4g_mem_size > 0) {
  memory_region_init_alias(&ram_hi, NULL, "xen.ram.hi",

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Wed, Aug 19, 2015 at 09:30:20AM -0700, Eduardo Habkost wrote:
> On Wed, Aug 19, 2015 at 10:55:26AM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > Migration with q35 was not possible before commit
> > > 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally 
> > > creates
> > > an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > > before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > compatibility code for them.
> > > 
> > > Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > 
> > But doesn't that mean that anyone who has a machine configured with one
> > of those machine types will suddenly find it wont start?
> 
> Yes, and they will have to update their configuration to use pc-q35-2.4
> or newer.

That seems easily avoidable: just make pc-q35-X alias pc-q35-2.4 for X < 2.4.

> -- 
> Eduardo

Re: [Qemu-devel] SMP and qemu scheduler, HELP

[Peter Maydell]

On 25 August 2015 at 10:29, françois Guerret
 wrote:
> I want to execute a realtime software which executes periodically the same
> loop.
> On multicore target, I set one periodic loop per core.
>
> I need the time to be synchronized between the cores at least with the
> granularity of a loop period.
> For instance I want to prevent core 0 to execute three time its loop while
> core 1 executes its own once.
>
> Moreover I want to use *time* (icount time) to synchornize the loops (hence
> a barrier using an active waiting
> is definitly not a good solution). Indeed I need the icount time necessary
> to execute the loop to be more or less constant.

I think it is unlikely that QEMU will ever provide emulation
with that degree of fidelity and lock-step between different
emulated CPUs. You would be better to make sure your code
doesn't rely on such fine detail of timing synchronization
between the code executed on different cores.

thanks
-- PMM

Re: [Qemu-devel] SMP and qemu scheduler, HELP

[françois Guerret]

Hello,
Thanks for your concern.
I want to execute a realtime software which executes periodically the same 
loop.On multicore target, I set one periodic loop per core.
I need the time to be synchronized between the cores at least with the 
granularity of a loop period.For instance I want to prevent core 0 to execute 
three time its loop while core 1 executes its own once.
Moreover I want to use *time* (icount time) to synchornize the loops (hence a 
barrier using an active waitingis definitly not a good solution). Indeed I need 
the icount time necessary to execute the loop to be more or less constant.
I hope these explanations will enable you to help me.
Thanks in advance
Francois

> From: peter.mayd...@linaro.org
> Date: Mon, 24 Aug 2015 16:52:04 +0100
> Subject: Re: [Qemu-devel] SMP and qemu scheduler, HELP
> To: francois.guer...@hotmail.fr
> CC: qemu-devel@nongnu.org
> 
> On 24 August 2015 at 11:03, françois Guerret
>  wrote:
> > Hello,
> >
> > I use qemu to emulate a SMP multicore processor and I am looking for a way :
> >  * either to ask qemu scheduler to execute an other core. For that I need a
> > kind of
> > *yield()* syscall that I could insert into user code and which would be
> > catched by
> >   QEMU scheduler.
> >  * or to give an option to QEMU to control the sheduling period. I would
> > like to be
> >  able to tell qemu that I need every core to be executed at least every
> > 1 ms
> >  (in icount time mode) for instance.
> 
> 
> It would be interesting if you could explain why you want these features.
> 
> thanks
> -- PMM
  

Re: [Qemu-devel] [PATCH v2 for 2.5 0/3] Move target- and device specific code from monitor

[Denis V. Lunev]

On 08/12/2015 02:50 PM, Denis V. Lunev wrote:

The monivation of this set is simple. Recently we have proposed patch
to monitor.c with specific x86 APIC HMP commands. The patchset was denied
with the main motivation "No more arch specific code in monitor.c"
This patchset is the first step to move arch specific code from
monitor.c targets.

So, monitor.c already contains a lot of generic code, as well as the target
specifics code and eventually monitor.c volume will only grow. This trend leads
to a variety of fouling code ifdeffery(and combinations thereof),
poor readability, and entanglement of architecture of the project.
If someone wants to improve processing logic commands at the monitor,
it isn't necessarily must differentiate amongst the implementation of some ARM
or x86_64 specific commands, because the project already has separation of
target specific code on directories.

The presented solution is not the best, but it is quite simple
(PATCH doesn't add more code!) and decides the above mentioned issue.
Subsequently it will not prevent the introduction of more advanced mechanism
that can more effectively resolve the issue.

There is a issue with the placement of code for multiple architectures
(isn't for everyone), but this code is very small. This patch is a step towards
solving the issue associated with maintaining the purity of the code and
structure of the project, which solves not all, but doing a little better
than it is.

Changes from v1:
- ported to new head

Signed-off-by: Pavel Butsykin 
Signed-off-by: Denis V. Lunev 
CC: Luiz Capitulino 
CC: Paolo Bonzini 
CC: Peter Maydell 


ping v2

Re: [Qemu-devel] [PATCH 5/6] virtio-pci: introduce pio notification capability for modern device

[Michael S. Tsirkin]

On Fri, Aug 21, 2015 at 05:05:49PM +0800, Jason Wang wrote:
> We used to use mmio for notification. This could be slow on some arch
> (e.g on x86 without EPT). So this patch introduces pio bar and a pio
> notification cap for modern device. This ability is enabled through
> property "modern-pio-notify" for virtio pci devices and was disabled
> by default. Management can enable when it thinks it was needed.
> 
> Benchmarks shows almost no obvious difference with legacy device.
> Thanks Wenli Quan  for the benchmarking.
> 
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 

I don't really care much about non-EPT hosts, but if you propose
a patch to optimize them, it should be accompanied by numbers
showing the performance difference.

> ---
>  hw/virtio/virtio-pci.c | 122 
> ++---
>  hw/virtio/virtio-pci.h |  10 
>  2 files changed, 115 insertions(+), 17 deletions(-)
> 
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index fbd1f1f..e399565 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -210,7 +210,9 @@ static int 
> virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy,
>  EventNotifier *notifier = virtio_queue_get_host_notifier(vq);
>  bool legacy = !(proxy->flags & VIRTIO_PCI_FLAG_DISABLE_LEGACY);
>  bool modern = !(proxy->flags & VIRTIO_PCI_FLAG_DISABLE_MODERN);
> +bool modern_pio = proxy->flags & VIRTIO_PCI_FLAG_MODERN_PIO_NOTIFY;
>  MemoryRegion *modern_mr = &proxy->notify.mr;
> +MemoryRegion *modern_notify_mr = &proxy->notify_pio.mr;
>  MemoryRegion *legacy_mr = &proxy->bar;
>  hwaddr modern_addr = QEMU_VIRTIO_PCI_QUEUE_MEM_MULT *
>   virtio_get_queue_index(vq);
> @@ -228,6 +230,10 @@ static int 
> virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy,
>  if (modern) {
>  memory_region_add_eventfd(modern_mr, modern_addr, 0,
>false, n, notifier);
> +if (modern_pio) {
> +memory_region_add_eventfd(modern_notify_mr, 0, 2,
> +  true, n, notifier);
> +}
>  }
>  if (legacy) {
>  memory_region_add_eventfd(legacy_mr, legacy_addr, 2,
> @@ -237,6 +243,10 @@ static int 
> virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy,
>  if (modern) {
>  memory_region_del_eventfd(modern_mr, modern_addr, 0,
>false, n, notifier);
> +if (modern_pio) {
> +memory_region_del_eventfd(modern_notify_mr, 0, 2,
> +  true, n, notifier);
> +}
>  }
>  if (legacy) {
>  memory_region_del_eventfd(legacy_mr, legacy_addr, 2,
> @@ -1344,6 +1354,17 @@ static void virtio_pci_notify_write(void *opaque, 
> hwaddr addr,
>  }
>  }
>  
> +static void virtio_pci_notify_write_pio(void *opaque, hwaddr addr,
> +uint64_t val, unsigned size)
> +{
> +VirtIODevice *vdev = opaque;
> +unsigned queue = val;
> +
> +if (queue < VIRTIO_QUEUE_MAX) {
> +virtio_queue_notify(vdev, queue);
> +}
> +}
> +
>  static uint64_t virtio_pci_isr_read(void *opaque, hwaddr addr,
>  unsigned size)
>  {
> @@ -1437,6 +1458,16 @@ static void 
> virtio_pci_modern_regions_init(VirtIOPCIProxy *proxy)
>  },
>  .endianness = DEVICE_LITTLE_ENDIAN,
>  };
> +static const MemoryRegionOps notify_pio_ops = {
> +.read = virtio_pci_notify_read,
> +.write = virtio_pci_notify_write_pio,
> +.impl = {
> +.min_access_size = 1,
> +.max_access_size = 4,
> +},
> +.endianness = DEVICE_LITTLE_ENDIAN,
> +};
> +
>  
>  memory_region_init_io(&proxy->common.mr, OBJECT(proxy),
>&common_ops,
> @@ -1461,30 +1492,60 @@ static void 
> virtio_pci_modern_regions_init(VirtIOPCIProxy *proxy)
>virtio_bus_get_device(&proxy->bus),
>"virtio-pci-notify",
>proxy->notify.size);
> +
> +memory_region_init_io(&proxy->notify_pio.mr, OBJECT(proxy),
> +  ¬ify_pio_ops,
> +  virtio_bus_get_device(&proxy->bus),
> +  "virtio-pci-notify-pio",
> +  proxy->notify.size);
>  }
>  
>  static void virtio_pci_modern_region_map(VirtIOPCIProxy *proxy,
>   VirtIOPCIRegion *region,
> - struct virtio_pci_cap *cap)
> + struct virtio_pci_cap *cap,
> + MemoryRegion *mr,
> + uint8_t bar)
>  {
> -memory_region_add_subregion(&proxy->modern_bar,
> - 

[Qemu-devel] [PATCH 1/3] qemu-file: improve qemu_put_compression_data

[Liang Li]

There are some flaws in qemu_put_compression_data so that it can't not operate
on an normal QEMUFile, improve it so as to use it later.

Signed-off-by: Liang Li 
---
 migration/qemu-file.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index 6bb3dc1..59967b6 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -567,7 +567,9 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const 
uint8_t *p, size_t size,
 ssize_t blen = IO_BUF_SIZE - f->buf_index - sizeof(int32_t);
 
 if (blen < compressBound(size)) {
-return 0;
+if (f->ops->writev_buffer || f->ops->put_buffer) {
+qemu_fflush(f);
+}
 }
 if (compress2(f->buf + f->buf_index + sizeof(int32_t), (uLongf *)&blen,
   (Bytef *)p, size, level) != Z_OK) {
@@ -575,7 +577,13 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const 
uint8_t *p, size_t size,
 return 0;
 }
 qemu_put_be32(f, blen);
+if (f->ops->writev_buffer) {
+add_to_iovec(f, f->buf + f->buf_index, blen);
+}
 f->buf_index += blen;
+if (f->buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
+}
 return blen + sizeof(int32_t);
 }
 
-- 
1.9.1

[Qemu-devel] [PATCH 2/3] migration: optimization for one compression thread

[Liang Li]

When the compression thread count is set to 1, the current implementation
is inefficient because of the following reason:
1. Thread synchronization cost;
2. Data copy;
3. No benefit from the separate compression thread;

This patch optimizes the performance for the case of 1 compress thread.
In this case, the compression is done in the migration thread, for some
fast compression algorithm, it can help to improve the performance.

Signed-off-by: Liang Li 
---
 migration/ram.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 7f007e6..0cc4f81 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -318,8 +318,13 @@ void migrate_compress_threads_join(void)
 if (!migrate_use_compression()) {
 return;
 }
-terminate_compression_threads();
+
 thread_count = migrate_compress_threads();
+if (thread_count == 1) {
+return;
+}
+
+terminate_compression_threads();
 for (i = 0; i < thread_count; i++) {
 qemu_thread_join(compress_threads + i);
 qemu_fclose(comp_param[i].file);
@@ -345,9 +350,12 @@ void migrate_compress_threads_create(void)
 if (!migrate_use_compression()) {
 return;
 }
+thread_count = migrate_compress_threads();
+if (thread_count == 1) {
+return;
+}
 quit_comp_thread = false;
 compression_switch = true;
-thread_count = migrate_compress_threads();
 compress_threads = g_new0(QemuThread, thread_count);
 comp_param = g_new0(CompressParam, thread_count);
 comp_done_cond = g_new0(QemuCond, 1);
@@ -782,6 +790,9 @@ static void flush_compressed_data(QEMUFile *f)
 return;
 }
 thread_count = migrate_compress_threads();
+if (thread_count == 1) {
+return;
+}
 for (idx = 0; idx < thread_count; idx++) {
 if (!comp_param[idx].done) {
 qemu_mutex_lock(comp_done_lock);
@@ -883,18 +894,16 @@ static int ram_save_compressed_page(QEMUFile *f, RAMBlock 
*block,
  * out, keeping this order is important, because the 'cont' flag
  * is used to avoid resending the block name.
  */
-if (block != last_sent_block) {
+if (block != last_sent_block || migrate_compress_threads() == 1) {
 flush_compressed_data(f);
 pages = save_zero_page(f, block, offset, p, bytes_transferred);
 if (pages == -1) {
-set_compress_params(&comp_param[0], block, offset);
-/* Use the qemu thread to compress the data to make sure the
- * first page is sent out before other pages
- */
-bytes_xmit = do_compress_ram_page(&comp_param[0]);
-acct_info.norm_pages++;
-qemu_put_qemu_file(f, comp_param[0].file);
+bytes_xmit = save_page_header(f, block, offset |
+  RAM_SAVE_FLAG_COMPRESS_PAGE);
+bytes_xmit += qemu_put_compression_data(f, p, TARGET_PAGE_SIZE,
+migrate_compress_level());
 *bytes_transferred += bytes_xmit;
+acct_info.norm_pages++;
 pages = 1;
 }
 } else {
-- 
1.9.1

[Qemu-devel] [PATCH 0/3] Optimize the performance for single thread (de)compression

[Liang Li]

When the (de)compression thread count is set to 1, the current implementation
is inefficient because of the data copy and thread syncronization cost, a 
separate
single (de)compression thread is useless for performance improvement and will
result in performance degradation.

If (de)compression thread count is set to 1, we skip to use the multiple threads
mechanism. 


Liang Li (3):
  qemu-file: improve qemu_put_compression_data
  migration: optimization for one compression thread
  migration: optimization for one decompression thread

 migration/qemu-file.c | 10 +-
 migration/ram.c   | 46 ++
 2 files changed, 43 insertions(+), 13 deletions(-)

-- 
1.9.1

[Qemu-devel] [PATCH 3/3] migration: optimization for one decompression thread

[Liang Li]

When decompression thread count is set to 1, the current implementation
is inefficient because of the following reason:
1. Thread syncronization cost;
2. Data copy;

This patch optimizes the performance for the case of 1 decompress thread.
In this case, the compression is done in process_incoming_migration_co,
for some fast decompression algorithm, it can help to improve the
performance.

Signed-off-by: Liang Li 
---
 migration/ram.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 0cc4f81..fc91997 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1414,6 +1414,9 @@ void migrate_decompress_threads_create(void)
 int i, thread_count;
 
 thread_count = migrate_decompress_threads();
+if (thread_count == 1) {
+return;
+}
 decompress_threads = g_new0(QemuThread, thread_count);
 decomp_param = g_new0(DecompressParam, thread_count);
 compressed_data_buf = g_malloc0(compressBound(TARGET_PAGE_SIZE));
@@ -1432,8 +1435,11 @@ void migrate_decompress_threads_join(void)
 {
 int i, thread_count;
 
-quit_decomp_thread = true;
 thread_count = migrate_decompress_threads();
+if (thread_count == 1) {
+return;
+}
+quit_decomp_thread = true;
 for (i = 0; i < thread_count; i++) {
 qemu_mutex_lock(&decomp_param[i].mutex);
 qemu_cond_signal(&decomp_param[i].cond);
@@ -1575,7 +1581,14 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
 break;
 }
 qemu_get_buffer(f, compressed_data_buf, len);
-decompress_data_with_multi_threads(compressed_data_buf, host, len);
+if (migrate_decompress_threads() == 1) {
+unsigned long pagesize = TARGET_PAGE_SIZE;
+uncompress((Bytef *)host, &pagesize,
+   (const Bytef *)compressed_data_buf, len);
+} else {
+decompress_data_with_multi_threads(compressed_data_buf,
+   host, len);
+}
 break;
 case RAM_SAVE_FLAG_XBZRLE:
 host = host_from_stream_offset(f, addr, flags);
-- 
1.9.1

[Qemu-devel] [PATCH v2 2/2] armv7m: Use irqchip property instead of direct assignment

[Pavel Fedin]

Implement property instead of direct assignment of cpu->env.irqchip

Signed-off-by: Pavel Fedin 
---
 hw/arm/armv7m.c  | 5 ++---
 target-arm/cpu.c | 6 ++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 19742b7..8905e97 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -170,7 +170,6 @@ qemu_irq *armv7m_init(MemoryRegion *system_memory, int 
mem_size, int num_irq,
   const char *kernel_filename, const char *cpu_model)
 {
 ARMCPU *cpu;
-CPUARMState *env;
 DeviceState *nvic;
 qemu_irq *pic = g_new(qemu_irq, num_irq);
 int image_size;
@@ -188,14 +187,14 @@ qemu_irq *armv7m_init(MemoryRegion *system_memory, int 
mem_size, int num_irq,
 fprintf(stderr, "Unable to find CPU definition\n");
 exit(1);
 }
-env = &cpu->env;
 
 armv7m_bitband_init();
 
 nvic = qdev_create(NULL, "armv7m_nvic");
 qdev_prop_set_uint32(nvic, "num-irq", num_irq);
-env->irqchip = nvic;
 qdev_init_nofail(nvic);
+object_property_set_link(OBJECT(cpu), OBJECT(nvic), "irqchip",
+ &error_abort);
 sysbus_connect_irq(SYS_BUS_DEVICE(nvic), 0,
qdev_get_gpio_in(DEVICE(cpu), ARM_CPU_IRQ));
 for (i = 0; i < num_irq; i++) {
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index cc6c6f3..b9f3010 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -447,6 +447,12 @@ static void arm_cpu_initfn(Object *obj)
 static bool inited;
 uint32_t Aff1, Aff0;
 
+object_property_add_link(obj, "irqchip",
+ "sys-bus-device", (Object **)&cpu->env.irqchip,
+ object_property_allow_set_link,
+ OBJ_PROP_LINK_UNREF_ON_RELEASE,
+ &error_abort);
+
 cs->env_ptr = &cpu->env;
 cpu_exec_init(cs, &error_abort);
 cpu->cp_regs = g_hash_table_new_full(g_int_hash, g_int_equal,
-- 
1.9.5.msysgit.0

[Qemu-devel] [PATCH v2 1/2] cpu_arm: Rename 'nvic' to 'irqchip'

[Pavel Fedin]

This name seems to be more appropriate because ARMv8 also needs a link
with GICv3 for CPU interface to work

Signed-off-by: Pavel Fedin 
---
 hw/arm/armv7m.c |  2 +-
 target-arm/cpu.h|  5 -
 target-arm/helper.c | 12 ++--
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index c6eab6d..19742b7 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -194,7 +194,7 @@ qemu_irq *armv7m_init(MemoryRegion *system_memory, int 
mem_size, int num_irq,
 
 nvic = qdev_create(NULL, "armv7m_nvic");
 qdev_prop_set_uint32(nvic, "num-irq", num_irq);
-env->nvic = nvic;
+env->irqchip = nvic;
 qdev_init_nofail(nvic);
 sysbus_connect_irq(SYS_BUS_DEVICE(nvic), 0,
qdev_get_gpio_in(DEVICE(cpu), ARM_CPU_IRQ));
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 2e680da..7021b87 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -496,7 +496,10 @@ typedef struct CPUARMState {
 uint32_t *dracr;
 } pmsav7;
 
-void *nvic;
+/* Some CPUs have an internal link to their interrupt controller.
+ * Examples are ARMv7m (NVIC) and ARMv8 (GICv3 CPU interface)
+ */
+DeviceState *irqchip;
 const struct arm_boot_info *boot_info;
 } CPUARMState;
 
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1568aa6..104ac4b 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -4785,7 +4785,7 @@ static void do_v7m_exception_exit(CPUARMState *env)
 
 type = env->regs[15];
 if (env->v7m.exception != 0)
-armv7m_nvic_complete_irq(env->nvic, env->v7m.exception);
+armv7m_nvic_complete_irq(env->irqchip, env->v7m.exception);
 
 /* Switch to the target stack.  */
 switch_v7m_sp(env, (type & 4) != 0);
@@ -4841,18 +4841,18 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
one we're raising.  */
 switch (cs->exception_index) {
 case EXCP_UDEF:
-armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_USAGE);
+armv7m_nvic_set_pending(env->irqchip, ARMV7M_EXCP_USAGE);
 return;
 case EXCP_SWI:
 /* The PC already points to the next instruction.  */
-armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_SVC);
+armv7m_nvic_set_pending(env->irqchip, ARMV7M_EXCP_SVC);
 return;
 case EXCP_PREFETCH_ABORT:
 case EXCP_DATA_ABORT:
 /* TODO: if we implemented the MPU registers, this is where we
  * should set the MMFAR, etc from exception.fsr and exception.vaddress.
  */
-armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_MEM);
+armv7m_nvic_set_pending(env->irqchip, ARMV7M_EXCP_MEM);
 return;
 case EXCP_BKPT:
 if (semihosting_enabled()) {
@@ -4865,10 +4865,10 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
 return;
 }
 }
-armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_DEBUG);
+armv7m_nvic_set_pending(env->irqchip, ARMV7M_EXCP_DEBUG);
 return;
 case EXCP_IRQ:
-env->v7m.exception = armv7m_nvic_acknowledge_irq(env->nvic);
+env->v7m.exception = armv7m_nvic_acknowledge_irq(env->irqchip);
 break;
 case EXCP_EXCEPTION_EXIT:
 do_v7m_exception_exit(env);
-- 
1.9.5.msysgit.0

[Qemu-devel] [PATCH v2 0/2] cpu_arm: Implement irqchip property for ARM CPU

[Pavel Fedin]

ARMv7m CPU needs a link to NVIC instance for processing interrupts.
Similarly ARMv8 needs a link to GICv3 for its CPU interface.

This series builds upon existing mechanism for linking irqchip and
CPU, bringing the code up to date and making it reusable. Another small
step towards complete GICv3 implementation.

v1 => v2:
- Set link to nvic after it has been initialized
- Changed object type to "sys-bus-device" because GICv2 and GICv3 do not
  share common ancestors above that.

Pavel Fedin (2):
  cpu_arm: Rename 'nvic' to 'irqchip'
  armv7m: Use irqchip property instead of direct assignment

 hw/arm/armv7m.c |  5 ++---
 target-arm/cpu.c|  6 ++
 target-arm/cpu.h|  5 -
 target-arm/helper.c | 12 ++--
 4 files changed, 18 insertions(+), 10 deletions(-)

-- 
1.9.5.msysgit.0

[Qemu-devel] Should we auto-generate IDs? (was: [PATCH] qdev-monitor.c: Add device id generation)

[Markus Armbruster]

You're proposing to revise a qdev design decision, namely the purpose of
IDs.  This has been discussed before, and IDs remained unchanged.
Perhaps it's time to revisit this issue.  Cc'ing a few more people.

Relevant prior threads:
* [PATCH] qdev: Reject duplicate and anti-social device IDs
  http://thread.gmane.org/gmane.comp.emulators.qemu/71230/focus=72272
* [PATCH 6/6] qdev: Generate IDs for anonymous devices
  http://thread.gmane.org/gmane.comp.emulators.qemu/114853/focus=114858
* [PATCH] qdev: Assign a default device ID when none is provided.
  http://thread.gmane.org/gmane.comp.emulators.qemu/249702
* IDs in QOM (was: [PATCH] util: Emancipate id_wellformed() from QemuOpt
  http://thread.gmane.org/gmane.comp.emulators.qemu/299945/focus=300381

Probably more I can't remember anymore :)

Programmingkid  writes:

> Add device ID generation to each device if an ID isn't given.
>
> Signed-off-by: John Arbuckle 
>
> ---
> This patch can be tested by adding adding usb devices using the monitor.
> Start QEMU with the -usb option. Then go to the monitor and type
> "device_add usb-mouse". The ID of the device will be set to a number.
> Since QEMU will not allow an user to add a device with an ID set to a
> number, there is no chance for ID collisions. 

The second sentence should really be part of your commit message.
The first sentence wouldn't hurt, either.

Another useful addition would be *why* you want generated IDs.  I
believe you do because you need them for device_del.

In prior discussion, we always concluded that device_del should accept
QOM paths.  It still doesn't.

Many things in QEMU have IDs.  They all work pretty much the same:

1. The ID is set by the user.  If the user doesn't, there is none.

   Exception: a few old interfaces set well-known IDs.  If the user uses
   these interfaces, he needs to take care that his own IDs don't clash.

   Example: drive_add picks an ID based on interface type, media type,
   bus and unit number.  blockdev_add doesn't.  Instead, it requires the
   user to pick one.

2. The ID must be well-formed.

   Exception: inconsistently enforced for QOM, see last thread quoted
   above.

3. If the user may need to address the thing, either the ID must be
   mandatory, or there has to be another way to address it.

   Example: netdev-add requires ID.  Rationale: the only way to put it
   to use is referencing it from a device, and that requires an ID.

   Example: device_add doesn't require ID.  If you don't specify one,
   you can't device_del it.  Annoying trap for the unwary.  There are
   *two* other ways to address it: qdev path and QOM path.  qdev path is
   basically too botched to be usable.  QOM path should do just fine,
   but device_del doesn't accept it.  It could.

We could revise rule 1 to always generate IDs, in a way that can't clash
with the user's IDs (impossible unless rule 2 is actually observed).
Rule 3 then becomes moot.

Whatever we do, I want it done consistently.  I don't want different
rules for different kinds of IDs.

Re: [Qemu-devel] [PATCH] qdev-monitor.c: Add device id generation

[Markus Armbruster]

My other reply is about design issues.  This one is about the actual
code.  Until we get rough consensus on the former, the latter doesn't
really matter, but here goes anyway.

Eric Blake  writes:

> On 08/24/2015 12:53 PM, Programmingkid wrote:
>> Add device ID generation to each device if an ID isn't given.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> This patch can be tested by adding adding usb devices using the monitor.
>> Start QEMU with the -usb option. Then go to the monitor and type
>> "device_add usb-mouse". The ID of the device will be set to a number.
>> Since QEMU will not allow an user to add a device with an ID set to a
>> number, there is no chance for ID collisions. 
>>
>>  qdev-monitor.c |   24 ++--
>>  1 files changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/qdev-monitor.c b/qdev-monitor.c
>> index f9e2d62..98267c4 100644
>> --- a/qdev-monitor.c
>> +++ b/qdev-monitor.c
>> @@ -26,6 +26,10 @@
>>  #include "qapi/qmp/qerror.h"
>>  #include "qemu/config-file.h"
>>  #include "qemu/error-report.h"
>> +#include 
>> +
>> +/* USB's max number of devices is 127. This number is 3 digits long. */
>> +#define MAX_NUM_DIGITS_FOR_USB_ID 3

This limit makes no sense to me.

>>  
>>  /*
>>   * Aliases were a bad idea from the start.  Let's keep them
>> @@ -574,17 +578,25 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
>> **errp)
>>  id = qemu_opts_id(opts);
>>  if (id) {
>>  dev->id = id;
>> +} else { /* create an id for a device if none is provided */
>> +static int device_id_count;
>> +
>> +/* Add one for '\0' character */
>> +char *device_id = (char *) malloc(sizeof(char) *
>> +MAX_NUM_DIGITS_FOR_USB_ID + 1);
>> +sprintf(device_id, "%d", device_id_count++);
>
> g_strdup_printf() is a lot nicer about avoiding the risk of arbitrary
> overflow...
>
>> +dev->id = (const char *) device_id;
>> +
>> +/* if device_id_count >= 10^MAX_NUM_DIGITS_FOR_USB_ID */
>> +if (device_id_count >= pow(10, MAX_NUM_DIGITS_FOR_USB_ID)) {
>> +printf("Warning: Maximum number of device ID's generated!\n\a");
>> +printf("Time for you to make your own device ID's.\n");
>
> besides, printf() is probably the wrong way to do error reporting, and
> we don't use \a BEL sequences anywhere else in qemu code.
>
>> +}
>>  }

When device_id_count reaches the limit, you warn.  Next time around, you
overrun the buffer.  Not good.

Eric is right, g_strdup_printf() is easier and safer.

I'd make the count 64 bits, so wrapping becomes vanishingly unlikely.

>>  
>>  if (dev->id) {
>
> This if would now be a dead check if your patch is applied.
>
>>  object_property_add_child(qdev_get_peripheral(), dev->id,
>>OBJECT(dev), NULL);
>> -} else {
>> -static int anon_count;
>> -gchar *name = g_strdup_printf("device[%d]", anon_count++);
>> -object_property_add_child(qdev_get_peripheral_anon(), name,
>> -  OBJECT(dev), NULL);
>> -g_free(name);
>>  }
>
> It looks like your goal was to move this code earlier, but you changed
> enough aspects of it that I'm not sure what the right fix should be.

Drop the conditional, it's both useless and confusing after your patch.

Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code

[Markus Armbruster]

Alberto Garcia  writes:

> On Tue 25 Aug 2015 09:54:42 AM CEST, Markus Armbruster wrote:
>
>> Switching back to C locale whenever some unwanted locale-dependency
>> breaks the code is problematic, because it involves finding all the
>> places that break, iteratively (euphemism for "we debug one breakage
>> after the other, adding temporary locale switches as we go).
>>
>> I'd feel much better about confining GTK in its own thread, and
>> setting only that thread's locale.
>
> FWIW GTK+ is not thread safe, all GTK+ code must run in the same thread,
> so that should already be happening. I assume however that it's the same
> thread that runs the monitor, so that might not be a solution in the
> end.

If we use thread-local locale for the GTK UI, then anything running in
that thread must either not depend on locale, or be properly
internationalized.  Neither holds for the monitor (or pretty much any
non-trivial part of QEMU).

Can we give the GTK UI code its very own thread?

Re: [Qemu-devel] [PATCH v14 30/33] target-tilegx: Handle atomic instructions

[Chen Gang]

On 8/25/15 12:15, Richard Henderson wrote:
> On 08/24/2015 09:17 AM, Richard Henderson wrote:
>> Signed-off-by: Richard Henderson 
>> ---
>> target-tilegx/translate.c | 50 
>> ++-
>> 1 file changed, 49 insertions(+), 1 deletion(-)
>>
>> diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
>> index 210e912..2a0798a 100644
>> --- a/target-tilegx/translate.c
>> +++ b/target-tilegx/translate.c
>> @@ -180,6 +180,19 @@ static void gen_saturate_op(TCGv tdest, TCGv tsrca, 
>> TCGv tsrcb,
>> tcg_temp_free(t0);
>> }
>>
>> +static void gen_atomic_excp(DisasContext *dc, unsigned dest, unsigned srca,
>> + unsigned srcb, TileExcp excp)
>> +{
>> +#ifdef CONFIG_USER_ONLY
>> + TCGv_i32 t = tcg_const_i32((dest << 16) | (srca << 8) | srcb);
>> + tcg_gen_st_i32(t, cpu_env, offsetof(CPUTLGState, excparam));
>> + tcg_temp_free_i32(t);
>> + gen_exception(dc, excp);
>> +#else
>> + gen_exception(dc, TILEGX_EXCP_OPCODE_UNIMPLEMENTED);
>> +#endif
>> +}

Originally, I used set_exception(), not gen_exception().

>
>
> This is broken. While it does work well enough for Hello World, implementing 
> a non-trap instruction with an exception is extremely dicey for TileGX. The 
> issue is that TileGX bundles operate atomically, with no RAW issues between 
> the instructions of the bundle.
>
> Consider a bundle like
>
> { add r0, r0, r1 ; exch r2, r0, r3 }
>
> In Chen's implementation, the writeback to r0 would occur before the 
> exception, and so the exch would happen to the wrong address. In my 
> implementation here, the exception would occur before the writeback, and so 
> the result of the add would be discarded.

We use tmp regs for buffering the r0.

- calculate x1 pipe, and save result to r0 tmp reg.

- exch the original r0 and r3 to r2 tmp reg.

- set exception flag (which will cause exception, later).

- save the result tmp regs to r0 or r2.

- gen exception.

>
> While retaining the current start_exclusive scheme, it would appear that we 
> need to store more data here -- to wit, the contents of the registers not 
> their numbers -- and delay the exception until after writeback.
>
> Even better, of course, would be to not exit the TB at all, and use host 
> atomic instructions... I suppose that multi-threading patch set is still in 
> limbo?
>

I guess, we need not.


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
  

Re: [Qemu-devel] [PATCH v14 30/33] target-tilegx: Handle atomic instructions

[Chen Gang]

> From: xili_gchen_5...@hotmail.com
> To: r...@twiddle.net; qemu-devel@nongnu.org
> CC: w...@tilera.com; cmetc...@ezchip.com; peter.mayd...@linaro.org
> Subject: Re: [Qemu-devel] [PATCH v14 30/33] target-tilegx: Handle atomic 
> instructions
> Date: Tue, 25 Aug 2015 21:11:11 +0800
>
> On 8/25/15 12:15, Richard Henderson wrote:
>> On 08/24/2015 09:17 AM, Richard Henderson wrote:
>>> Signed-off-by: Richard Henderson 
>>> ---
>>> target-tilegx/translate.c | 50 
>>> ++-
>>> 1 file changed, 49 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
>>> index 210e912..2a0798a 100644
>>> --- a/target-tilegx/translate.c
>>> +++ b/target-tilegx/translate.c
>>> @@ -180,6 +180,19 @@ static void gen_saturate_op(TCGv tdest, TCGv tsrca, 
>>> TCGv tsrcb,
>>> tcg_temp_free(t0);
>>> }
>>>
>>> +static void gen_atomic_excp(DisasContext *dc, unsigned dest, unsigned srca,
>>> + unsigned srcb, TileExcp excp)
>>> +{
>>> +#ifdef CONFIG_USER_ONLY
>>> + TCGv_i32 t = tcg_const_i32((dest << 16) | (srca << 8) | srcb);
>>> + tcg_gen_st_i32(t, cpu_env, offsetof(CPUTLGState, excparam));
>>> + tcg_temp_free_i32(t);
>>> + gen_exception(dc, excp);
>>> +#else
>>> + gen_exception(dc, TILEGX_EXCP_OPCODE_UNIMPLEMENTED);
>>> +#endif
>>> +}
>
> Originally, I used set_exception(), not gen_exception().
>
>>
>>
>> This is broken. While it does work well enough for Hello World, implementing 
>> a non-trap instruction with an exception is extremely dicey for TileGX. The 
>> issue is that TileGX bundles operate atomically, with no RAW issues between 
>> the instructions of the bundle.
>>
>> Consider a bundle like
>>
>> { add r0, r0, r1 ; exch r2, r0, r3 }
>>
>> In Chen's implementation, the writeback to r0 would occur before the 
>> exception, and so the exch would happen to the wrong address. In my 
>> implementation here, the exception would occur before the writeback, and so 
>> the result of the add would be discarded.
>
> We use tmp regs for buffering the r0.
>
> - calculate x1 pipe, and save result to r0 tmp reg.
>

Oh, typo, calculate x0 pipe, and save result to r0 tmp reg.

> - exch the original r0 and r3 to r2 tmp reg.
>
> - set exception flag (which will cause exception, later).
>
> - save the result tmp regs to r0 or r2.
>
> - gen exception.
>
>>
>> While retaining the current start_exclusive scheme, it would appear that we 
>> need to store more data here -- to wit, the contents of the registers not 
>> their numbers -- and delay the exception until after writeback.
>>
>> Even better, of course, would be to not exit the TB at all, and use host 
>> atomic instructions... I suppose that multi-threading patch set is still in 
>> limbo?
>>
>
> I guess, we need not.
>
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
>
  

Re: [Qemu-devel] [PATCH] Add another sanity check to smp_parse() function

[Thomas Huth]

On 19/08/15 17:58, Eduardo Habkost wrote:
> On Wed, Jul 22, 2015 at 03:59:50PM +0200, Thomas Huth wrote:
>> The code in smp_parse already checks the topology information for
>> sockets * cores * threads < cpus and bails out with an error in
>> that case. However, it is still possible to supply a bad configuration
>> the other way round, e.g. with:
>>
>>  qemu-system-xxx -smp 4,sockets=1,cores=4,threads=2
>>
>> QEMU then still starts the guest, with topology configuration that
>> is rather incomprehensible and likely not what the user wanted.
>> So let's add another check to refuse such wrong configurations.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  vl.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/vl.c b/vl.c
>> index 5856396..c8d24b1 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -1224,7 +1224,13 @@ static void smp_parse(QemuOpts *opts)
>>  exit(1);
>>  }
>>  
>> -max_cpus = qemu_opt_get_number(opts, "maxcpus", 0);
>> +max_cpus = qemu_opt_get_number(opts, "maxcpus", cpus);
>> +if (sockets * cores * threads > max_cpus) {
>> +fprintf(stderr, "cpu topology: error: "
>> +"sockets (%u) * cores (%u) * threads (%u) > maxcpus 
>> (%u)\n",
>> +sockets, cores, threads, max_cpus);
>> +exit(1);
>> +}
> 
> I am always afraid of breaking existing setups when we do that, because
> there may be existing VMs running with these weird configurations, and
> people won't be able to live-migrate them to a newer QEMU.
> 
> But I think we really have to start refusing to run obviously broken
> configurations one day, or we will never fix this mess, so:
> 
> Reviewed-by: Eduardo Habkost 
> 
> I want to apply this through the x86 tree, but I would like to get some
> Acked-by from other maintainers first.

Ok, thanks!

So *ping* to the other CPU core maintainers here ... could I get some
more ACKs, please?

 Thomas

Re: [Qemu-devel] [PATCH v11 0/5] vGICv3 support

[Ashok Kumar]

On Wed, Aug 19, 2015 at 10:23:21AM +0300, Pavel Fedin wrote:
> This series introduces support for GICv3 by KVM. Software emulation is
> currently not supported.
> 
> v11 => v10
> - Fixed minor issues with checkpatch and comments, reported by Eric Auger
> - Make reusable kvm_gic_supports_attr(), moved to kvm-all.c and renamed
>   as kvm_device_check_attr(). Useful for future live migration.
> 
> v9 => v10
> - Renamed "gicversion" option to "gic-version" (was forgotten in v9)
> - Data pointer in kvm_gic_access() is now void * because in case of
>   vGICv3 this function is expected to operate on 64-bit registers too
>   (GICD_IROUTER for instance)
> 
> v8 => v9
> - Removed all limitations on CPU and IRQ number from the base class
> - Added back missing properties, interface is now the same as in GICv2
> - Refactored reusable parts of vGICv2 code, decreased number of changes
> - Removed GIC type check from kvm_arch_irqchip_create(), no more need to
>   specify GIC type early
> - Fixed up all commit messages / logs
> - Removed 'nvic' field assignment in virt machine (was forgotten in v8)
> - CPU number limitation for 'virt' machine now comes from memory map
>   (how many redistributors can be placed). With current layout it appears
>   to be 126.
> 
> v7 => v8
> - Removed all unused SW emulation code
> - Removed unnecessary attributes from common class
> - Set "unmigratable" flag for GICv3 device
> - Removed unnecessary conditions from kvm_arm_gicv3_realize()
> - Fixed GIC type setting in vexpress model, was done in wrong place
> - Fixed condition style in hw/intc/Makefile.objs
> - Cleaned up virt machine memory map
> 
> v6 => v7
> - Wrap own GIC type definitions on top of KVM ones. Fixed build on
>   non-ARM-Linux hosts
> 
> v5 => v6
> - Fixed various checkpatch.pl style warnings
> - Removed TODO in gicv3_init_irqs_and_mmio(), relevant memory API patch
>   included
> - gicv3_init_irqs_and_mmio() now takes 3 arguments instead of 4. It is more
>   convenient to pass MMIO descriptors as array
> 
> v4 => v5
> - Do not reintroduce several constants shared with GICv2, reuse them instead.
> - Added gicv3_init_irqs_and_mmio() in base class, to be used by both software
>   emulation and KVM code. Avoids code duplication.
> - Do not add NULL msi-parent phandle to PCI device in the FDT
> - Removed a couple of stale things from virt.c
> 
> v3 => v4
> - Fixed stupid build breakage in patch 0002
> - Rebased on top of current master, patch 0003 adjusted according to
>   kvm_irqchip_create() changes
> - Added assertion against uninitialized kernel_irqchip_type
> - Removed kernel_irqchip_type initialization from models which do not
>   use KVM vGIC
> 
> v2 => v3
> - Removed some unrelated and unnecessary changes from virt machine,
>   occasionally slipped in; some of them caused qemu to crash on ARM32.
> - Fixed build for ARM32; vGICv3 code requires definitions which are
>   present only in ARM64 kernel
> 
> v1 => v2
> - Base class included, taken from the series by Shlomo Pongratz:
>   http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg01512.html
>   The code is refactored as little as possible in order to simplify
>   further addition of software emulation:
>   - Minor fixes in code style and comments, according to old reviews
>   - Removed REV_V3 definition because it's currently not used, and it does
> not add any meaning to number 3.
>   - Removed reserved regions for MBI and ITS (except for 'virt' machine
> memory map). These should go to separate classes when implemented.
> - Improved commit messages
> - vGIC patches restructured
> - Use 'gicversion' option instead of virt-v3 machine
> 
> Pavel Fedin (4):
>   intc/gic: Extract some reusable vGIC code
>   arm_kvm: Do not assume particular GIC type in
> kvm_arch_irqchip_create()
>   hw/intc: Initial implementation of vGICv3
>   hw/arm/virt: Add gic-version option to virt machine
> 
> Shlomo Pongratz (1):
>   hw/intc: Implement GIC-500 base class
> 
>  hw/arm/virt.c  | 111 ++-
>  hw/intc/Makefile.objs  |   2 +
>  hw/intc/arm_gic_kvm.c  |  46 +---
>  hw/intc/arm_gicv3_common.c | 140 ++
>  hw/intc/arm_gicv3_kvm.c| 149 
> +
>  hw/intc/vgic_common.h  |  55 ++
>  include/hw/arm/fdt.h   |   2 +-
>  include/hw/arm/virt.h  |   5 +-
>  include/hw/intc/arm_gicv3_common.h |  68 +
>  include/sysemu/kvm.h   |  12 +++
>  kvm-all.c  |  11 +++
>  target-arm/kvm.c   |  10 +--
>  target-arm/kvm_arm.h   |  10 +++
>  target-arm/machine.c   |  18 +
>  14 files changed, 582 insertions(+), 57 deletions(-)
>  create mode 100644 hw/intc/arm_gicv3_common.c
>  create mode 100644 hw/intc/arm_gicv3_kvm.c
>  create mode 100644 hw/intc/vgic_common.h
>  create mode 100644 include/hw

Re: [Qemu-devel] [PATCH v11 5/5] hw/arm/virt: Add gic-version option to virt machine

[Ashok Kumar]

On Wed, Aug 19, 2015 at 10:23:26AM +0300, Pavel Fedin wrote:
> Add gic_version to VirtMachineState, set it to value of the option
> and pass it around where necessary. Instantiate devices and fdt
> nodes according to the choice.
> 
> max_cpus for virt machine increased to 126 (calculated from redistributor
> space available in the memory map). GICv2 compatibility check happens
> inside arm_gic_common_realize().
> 
> ITS regions are added to the memory map too, however currently they
> are not used, just reserved.
> 
> Signed-off-by: Pavel Fedin 
> ---
>  hw/arm/virt.c | 111 
> +-
>  include/hw/arm/fdt.h  |   2 +-
>  include/hw/arm/virt.h |   5 ++-
>  3 files changed, 96 insertions(+), 22 deletions(-)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index d5a8417..e090640 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -50,6 +50,7 @@
>  #include "hw/arm/fdt.h"
>  #include "hw/intc/arm_gic_common.h"
>  #include "kvm_arm.h"
> +#include "qapi/visitor.h"
>  
>  /* Number of external interrupt lines to configure the GIC with */
>  #define NUM_IRQS 256
> @@ -79,6 +80,7 @@ typedef struct {
>  typedef struct {
>  MachineState parent;
>  bool secure;
> +int32_t gic_version;
>  } VirtMachineState;
>  
>  #define TYPE_VIRT_MACHINE   "virt"
> @@ -109,6 +111,9 @@ static const MemMapEntry a15memmap[] = {
>  [VIRT_GIC_DIST] =   { 0x0800, 0x0001 },
>  [VIRT_GIC_CPU] ={ 0x0801, 0x0001 },
>  [VIRT_GIC_V2M] ={ 0x0802, 0x1000 },
> +[VIRT_ITS_CONTROL] ={ 0x0802, 0x0001 },
> +[VIRT_ITS_TRANSLATION] ={ 0x0803, 0x0001 },
> +[VIRT_GIC_REDIST] = { 0x0804, 0x00FC },
>  [VIRT_UART] =   { 0x0900, 0x1000 },
>  [VIRT_RTC] ={ 0x0901, 0x1000 },
>  [VIRT_FW_CFG] = { 0x0902, 0x000a },
> @@ -258,10 +263,13 @@ static void fdt_add_timer_nodes(const VirtBoardInfo 
> *vbi)
>   * they are edge-triggered.
>   */
>  ARMCPU *armcpu;
> +uint32_t max;
>  uint32_t irqflags = GIC_FDT_IRQ_FLAGS_EDGE_LO_HI;
>  
> +/* Argument is 32 bit but 8 bits are reserved for flags */
> +max = (vbi->smp_cpus >= 24) ? 24 : vbi->smp_cpus;
>  irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
> - GIC_FDT_IRQ_PPI_CPU_WIDTH, (1 << vbi->smp_cpus) - 
> 1);
> + GIC_FDT_IRQ_PPI_CPU_WIDTH, (1 << max) - 1);
>  
>  qemu_fdt_add_subnode(vbi->fdt, "/timer");
>  
> @@ -285,6 +293,18 @@ static void fdt_add_cpu_nodes(const VirtBoardInfo *vbi)
>  {
>  int cpu;
>  
> +/*
> + * From Documentation/devicetree/bindings/arm/cpus.txt
> + *  On ARM v8 64-bit systems value should be set to 2,
> + *  that corresponds to the MPIDR_EL1 register size.
> + *  If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
> + *  in the system, #address-cells can be set to 1, since
> + *  MPIDR_EL1[63:32] bits are not used for CPUs
> + *  identification.
> + *
> + *  Now GIC500 doesn't support affinities 2 & 3 so currently
> + *  #address-cells can stay 1 until future GIC
> + */
>  qemu_fdt_add_subnode(vbi->fdt, "/cpus");
>  qemu_fdt_setprop_cell(vbi->fdt, "/cpus", "#address-cells", 0x1);
>  qemu_fdt_setprop_cell(vbi->fdt, "/cpus", "#size-cells", 0x0);
> @@ -321,25 +341,36 @@ static void fdt_add_v2m_gic_node(VirtBoardInfo *vbi)
>  qemu_fdt_setprop_cell(vbi->fdt, "/intc/v2m", "phandle", 
> vbi->v2m_phandle);
>  }
>  
> -static void fdt_add_gic_node(VirtBoardInfo *vbi)
> +static void fdt_add_gic_node(VirtBoardInfo *vbi, int type)
>  {
>  vbi->gic_phandle = qemu_fdt_alloc_phandle(vbi->fdt);
>  qemu_fdt_setprop_cell(vbi->fdt, "/", "interrupt-parent", 
> vbi->gic_phandle);
>  
>  qemu_fdt_add_subnode(vbi->fdt, "/intc");
> -/* 'cortex-a15-gic' means 'GIC v2' */
> -qemu_fdt_setprop_string(vbi->fdt, "/intc", "compatible",
> -"arm,cortex-a15-gic");
>  qemu_fdt_setprop_cell(vbi->fdt, "/intc", "#interrupt-cells", 3);
>  qemu_fdt_setprop(vbi->fdt, "/intc", "interrupt-controller", NULL, 0);
> -qemu_fdt_setprop_sized_cells(vbi->fdt, "/intc", "reg",
> - 2, vbi->memmap[VIRT_GIC_DIST].base,
> - 2, vbi->memmap[VIRT_GIC_DIST].size,
> - 2, vbi->memmap[VIRT_GIC_CPU].base,
> - 2, vbi->memmap[VIRT_GIC_CPU].size);
>  qemu_fdt_setprop_cell(vbi->fdt, "/intc", "#address-cells", 0x2);
>  qemu_fdt_setprop_cell(vbi->fdt, "/intc", "#size-cells", 0x2);
>  qemu_fdt_setprop(vbi->fdt, "/intc", "ranges", NULL, 0);
> +if (type == 3) {
> +qemu_fdt_setprop_string(vbi->fdt, "/intc", "compatible",
> +"arm,gic-v3");
> +qemu_fdt_setprop_sized_cells(vbi->fdt, "/intc

Re: [Qemu-devel] [RFC 2/4] hw/i386: Introduce AMD IOMMU

[Valentine Sinitsyn]

On 25.08.2015 12:25, David kiarie wrote:

On Tue, Aug 25, 2015 at 9:39 AM, Valentine Sinitsyn
 wrote:

Hi,


On 25.08.2015 04:19, David Kiarie wrote:


From: David 

Add AMD IOMMU emulation to Qemu. This is a very basic AMD IOMMU
emulation that only does translation and some basic Event logging.
Guest translation enables nested PCI passthrough

Signed-off-by: David Kiarie 
---
   hw/i386/Makefile.objs |   1 +
   hw/i386/amd_iommu.c   | 993
++
   hw/i386/amd_iommu.h   | 298 +++
   3 files changed, 1292 insertions(+)
   create mode 100644 hw/i386/amd_iommu.c
   create mode 100644 hw/i386/amd_iommu.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index ebd1015..2bae11c 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,6 +3,7 @@ obj-y += multiboot.o
   obj-y += pc.o pc_piix.o pc_q35.o
   obj-y += pc_sysfw.o
   obj-y += intel_iommu.o
+obj-y += amd_iommu.o
   obj-$(CONFIG_XEN) += ../xenpv/ xen/

   obj-y += kvmvapic.o
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
new file mode 100644
index 000..a3a0b20
--- /dev/null
+++ b/hw/i386/amd_iommu.c
@@ -0,0 +1,993 @@
+/*
+ * QEMU emulation of an AMD IOMMU (AMD-Vi)
+ *
+ * Copyright (C) 2011 Eduard - Gabriel Munteanu
+ * Copyright (C) 2015 David Kiarie, 
+ *
+ * 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 "hw/i386/amd_iommu.h"
+
+#define PCI_EXT_CAP_ID_PASID 0x1B
+#define PCI_EXT_CAP_ID_PRI   0x13
+
+#define PCI_SLOT(devfn)  (((devfn) >> 3) & 0x1f)
+#define PCI_FUNC(devfn)  ((devfn) & 0x07)
+
+#define MAX_VA_ADDR  (64UL << 5)
+#define MAX_PH_ADDR  (48UL << 8)
+#define MAX_GVA_ADDR (64UL << 15)
+
+//#define DEBUG_AMD_IOMMU
+#ifdef DEBUG_AMD_IOMMU
+enum {
+DEBUG_GENERAL, DEBUG_CAPAB, DEBUG_MMIO, DEBUG_ELOG,
+DEBUG_CACHE, DEBUG_COMMAND, DEBUG_MMU
+};
+
+#define IOMMU_DBGBIT(x)   (1 << DEBUG_##x)
+static int iommu_dbgflags = IOMMU_DBGBIT(GENERAL) | IOMMU_DBGBIT(MMU) |
IOMMU_DBGBIT(MMIO);
+//| IOMMU_DBGBIT(CAPAB) | IOMMU_DBGBIT(ELOG) | IOMMU_DBGBIT(CACHE) |
IOMMU_DBGBIT(COMMAND);
+
+#define IOMMU_DPRINTF(what, fmt, ...) do { \
+if (iommu_dbgflags & IOMMU_DBGBIT(what)) { \
+fprintf(stderr, "(amd-iommu)%s: " fmt "\n", __func__, \
+## __VA_ARGS__); } \
+} while (0)
+#else
+#define IOMMU_DPRINTF(what, fmt, ...) do {} while (0)
+#endif
+
+/* helper functions - FIXME - provide for reading one byte */
+static uint16_t amd_iommu_readw(AMDIOMMUState *s, hwaddr addr)
+{
+return lduw_le_p(&s->mmior[addr]);
+}
+
+static uint32_t amd_iommu_readl(AMDIOMMUState *s, hwaddr addr)
+{
+return ldl_le_p(&s->mmior[addr]);
+}
+
+static uint64_t amd_iommu_readq(AMDIOMMUState *s, hwaddr addr)
+{
+return ldq_le_p(&s->mmior[addr]);
+}
+
+static void amd_iommu_writew(AMDIOMMUState *s, hwaddr addr, uint16_t val)
+{
+stw_le_p(&s->mmior[addr], val);
+}
+
+static void amd_iommu_writel(AMDIOMMUState *s, hwaddr addr, uint32_t val)
+{
+stl_le_p(&s->mmior[addr], val);
+}
+
+static void amd_iommu_writeq(AMDIOMMUState *s, hwaddr addr, uint64_t val)
+{
+stq_le_p(&s->mmior[addr], val);
+}
+
+/* execute a completion wait command */
+static void amd_iommu_completion_wait(AMDIOMMUState *s, uint8_t *cmd)
+{
+unsigned int addr;
+
+/* completion store */
+if(cmd[0] & COM_COMPLETION_STORE_MASK){
+addr = le64_to_cpu(*(uint64_t*)cmd) & COM_STORE_ADDRESS_MASK;
+if(dma_memory_write(&address_space_memory, addr, cmd + 8, 8)){
+IOMMU_DPRINTF(ELOG, "error: fail to write at address
0%x"PRIx64, addr);
+}
+
+}
+
+/* set completion interrupt */


When I was experimenting with a real IOMMU, it all looked like if both
COM_COMPLETION_STORE_MASK and COM_COMPLETION_BIT are set in the command,
only an interrupt is generated. Could someone comment on this?


Which bit do you mean by COM_COMPLETION_BIT ?Do you mean
'COM_COMPLETION_INTR ? If yes, when would such a scenario occur ?

I was referring to COM_COMPLETION_INTR, sorry for the typo.


I have checked on from the spec, I can't find anything worthwhile and
I don't any of us is running an IOMMU - except you, so I guess you
should tell us what to do...
The spec doesn't say anything about this, I checked it. IIRC, I came 
across this behavior when submitted COMPLETION_WAIT command with 
interrupts off and spin in a while() 

Re: [Qemu-devel] [PATCH for-2.5] piix: Document coreboot-specific RAM size config register

[Thomas Lamprecht]

On 08/17/2015 08:58 PM, Eduardo Habkost wrote:

On Thu, Aug 13, 2015 at 11:30:57AM -0400, Richard Smith wrote:

On 08/09/2015 09:48 PM, Ed Swierk wrote:



References to coreboot commits: * Original commit adding code reading
register offsets 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x56, 0x57 to
Intel 440bx code in coreboot:
cb8eab482ff09ec256456312ef2d6e7710123551

I have vague recollection I may have been responsible for this but it
was so long ago.  I'm having trouble finding the commits in gitweb.
When I put those hashes into the commit search at
review.coreboot.org I get not found.

Those are git commits from the repository at
http://review.coreboot.org/coreboot.git

(I couldn't check if they can be seen in a browser, right now, because
the server is returning HTTP 502 errors)

Server doesn't work for me neither, but here is the commit on the github 
repo:

https://github.com/coreboot/coreboot/commit/cb8eab482ff09ec256456312ef2d6e7710123551

Re: [Qemu-devel] [RFC 2/4] hw/i386: Introduce AMD IOMMU

[Valentine Sinitsyn]

On 25.08.2015 12:41, David kiarie wrote:

On Tue, Aug 25, 2015 at 10:31 AM, Valentine Sinitsyn

[...snip...]

The spec doesn't say anything about this, I checked it. IIRC, I came across
this behavior when submitted COMPLETION_WAIT command with interrupts off and
spin in a while() loop waiting for the mask to be written. The loop never
finished, but everything worked as intended if I removed COM_COMPLETION_INTR
for the command.


Is this behaviour useful in any way ?I'll try to fix this in the next version.
I don't think it's useful. The reason I posted this question was to 
check if this is a bug in silicon or intended behavior. If the latter, 
I'd suggest to emulate it.


Valentine

[Qemu-devel] [PATCH] virtio dataplane: adapt dataplane for virtio Version 1

[Pierre Morel]

Let dataplane allocate different region for the desc/avail/used
ring regions.

Signed-off-by: Pierre Morel 
---
 hw/virtio/dataplane/vring.c |   54 --
 include/hw/virtio/dataplane/vring.h |4 ++-
 2 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/hw/virtio/dataplane/vring.c b/hw/virtio/dataplane/vring.c
index 07fd69c..49d783b 100644
--- a/hw/virtio/dataplane/vring.c
+++ b/hw/virtio/dataplane/vring.c
@@ -67,22 +67,46 @@ static void vring_unmap(void *buffer, bool is_write)
 /* Map the guest's vring to host memory */
 bool vring_setup(Vring *vring, VirtIODevice *vdev, int n)
 {
-hwaddr vring_addr = virtio_queue_get_ring_addr(vdev, n);
-hwaddr vring_size = virtio_queue_get_ring_size(vdev, n);
+hwaddr vring_addr;
+hwaddr vring_size;
 void *vring_ptr;
+struct vring *vr = &vring->vr;
 
 vring->broken = false;
+vr->num = virtio_queue_get_num(vdev, n);
 
-vring_ptr = vring_map(&vring->mr, vring_addr, vring_size, true);
+vring_addr = virtio_queue_get_desc_addr(vdev, n);
+vring_size = virtio_queue_get_desc_size(vdev, n);
+vring_ptr = vring_map(&vring->mr_desc, vring_addr, vring_size, true);
 if (!vring_ptr) {
-error_report("Failed to map vring "
- "addr %#" HWADDR_PRIx " size %" HWADDR_PRIu,
- vring_addr, vring_size);
-vring->broken = true;
-return false;
+error_report("Failed to map vring desc "
+ "addr %#" HWADDR_PRIx " size %" HWADDR_PRIu,
+ vring_addr, vring_size);
+goto out_err_desc;
 }
+vr->desc = vring_ptr;
 
-vring_init(&vring->vr, virtio_queue_get_num(vdev, n), vring_ptr, 4096);
+vring_addr = virtio_queue_get_avail_addr(vdev, n);
+vring_size = virtio_queue_get_avail_size(vdev, n);
+vring_ptr = vring_map(&vring->mr_avail, vring_addr, vring_size, true);
+if (!vring_ptr) {
+error_report("Failed to map vring avail "
+ "addr %#" HWADDR_PRIx " size %" HWADDR_PRIu,
+ vring_addr, vring_size);
+goto out_err_avail;
+}
+vr->avail = vring_ptr;
+
+vring_addr = virtio_queue_get_used_addr(vdev, n);
+vring_size = virtio_queue_get_used_size(vdev, n);
+vring_ptr = vring_map(&vring->mr_used, vring_addr, vring_size, true);
+if (!vring_ptr) {
+error_report("Failed to map vring used "
+ "addr %#" HWADDR_PRIx " size %" HWADDR_PRIu,
+ vring_addr, vring_size);
+goto out_err_used;
+}
+vr->used = vring_ptr;
 
 vring->last_avail_idx = virtio_queue_get_last_avail_idx(vdev, n);
 vring->last_used_idx = vring_get_used_idx(vdev, vring);
@@ -92,6 +116,14 @@ bool vring_setup(Vring *vring, VirtIODevice *vdev, int n)
 trace_vring_setup(virtio_queue_get_ring_addr(vdev, n),
   vring->vr.desc, vring->vr.avail, vring->vr.used);
 return true;
+
+out_err_used:
+memory_region_unref(vring->mr_avail);
+out_err_avail:
+memory_region_unref(vring->mr_desc);
+out_err_desc:
+vring->broken = true;
+return false;
 }
 
 void vring_teardown(Vring *vring, VirtIODevice *vdev, int n)
@@ -99,7 +131,9 @@ void vring_teardown(Vring *vring, VirtIODevice *vdev, int n)
 virtio_queue_set_last_avail_idx(vdev, n, vring->last_avail_idx);
 virtio_queue_invalidate_signalled_used(vdev, n);
 
-memory_region_unref(vring->mr);
+memory_region_unref(vring->mr_desc);
+memory_region_unref(vring->mr_avail);
+memory_region_unref(vring->mr_used);
 }
 
 /* Disable guest->host notifies */
diff --git a/include/hw/virtio/dataplane/vring.h 
b/include/hw/virtio/dataplane/vring.h
index 8d97db9..a596e4c 100644
--- a/include/hw/virtio/dataplane/vring.h
+++ b/include/hw/virtio/dataplane/vring.h
@@ -22,7 +22,9 @@
 #include "hw/virtio/virtio.h"
 
 typedef struct {
-MemoryRegion *mr;   /* memory region containing the vring */
+MemoryRegion *mr_desc;  /* memory region for the vring desc */
+MemoryRegion *mr_avail; /* memory region for the vring avail */
+MemoryRegion *mr_used;  /* memory region for the vring used */
 struct vring vr;/* virtqueue vring mapped to host memory */
 uint16_t last_avail_idx;/* last processed avail ring index */
 uint16_t last_used_idx; /* last processed used ring index */
-- 
1.7.1

Re: [Qemu-devel] [PATCH v6 1/8] scripts: Allow include "stdint.h" in virtio headers

[Thomas Huth]

On 24/08/15 14:03, Gavin Shan wrote:
> This allows to include "stdint.h" in virtio header files. Otherwise,
> scripts/update-linux-headers.sh fails when updating headers from
> Linux 4.2.rc8 kernel. include/uapi/linux/virtio_ring.h starts to
> include "stdint.h" from commit d768f32a ("virtio: Fix typecast of
> pointer in vring_init()").
> 
> Signed-off-by: Gavin Shan 
> ---
>  scripts/update-linux-headers.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
> index f0e830c..2fddf2e 100755
> --- a/scripts/update-linux-headers.sh
> +++ b/scripts/update-linux-headers.sh
> @@ -37,7 +37,8 @@ cp_virtio() {
>  mkdir -p "$to"
>  for f in $virtio; do
>  if
> -grep '#include' "$f" | grep -v -e 'linux/virtio' \
> +grep '#include' "$f" | grep -v -e 'stdint' \
> + -e 'linux/virtio' \
>   -e 'linux/types' \
>   -e 'linux/if_ether' \
>   -e 'sys/' \
> 

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH v11 5/5] hw/arm/virt: Add gic-version option to virt machine

[Pavel Fedin]

 Hello!

> In KVM case instead of assigning GICv2 as default, can we probe the KVM
> for GICv3 presence using KVM_CREATE_DEVICE_TEST and give priority to
> GICv3?

 We could, but i think this would hurt usability. I suggest that when the user 
chooses a
configuration, he/she expects to get something particular. And IMHO it's much 
better to default to
GICv2 (to be backwards-compatible), and just report error in case if this is 
not supported by KVM,
than to default to something, which is different on different machines and 
different kernels.
 Libvirt guys already blame "virt" machine for being too flexible...

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[Qemu-devel] KVM guest gets aborted if blockcommit is called

[Christian Rößner]

Hello,

I wrote this mail to the qemu-discuss mailing list, but today I am unsure, if I 
chose the right list. So I copy and paste this mail here in hope someone can 
respond :-)

I have reproducable problems with some code in qemu-coroutine.c:


void qemu_coroutine_enter(Coroutine *co, void *opaque)
{
Coroutine *self = qemu_coroutine_self();
CoroutineAction ret;

trace_qemu_coroutine_enter(self, co, opaque);

if (co->caller) {
fprintf(stderr, "Co-routine re-entered recursively\n");
abort();   <— This one triggers 4 or 5 out of ten tests to use 
the blockcommit feature
}

Unfortunately a "normal" system administrator like me does not understand the 
error message. I have no idea what causes it nor how to prevent it. Or if this 
is just a bug ;-)

Original mail to qemu-discuss:
-

I spent now full five days to debug a major problem with backing up VMs. I run 
a HP ProLiant Server SE316M1-R2 aka DL160G6) with two Xeon L5520 and 48GB RAM 
tripple channel. On this server I do monitoring and Qemu/libvirt. I run 7 
guests on this server, which runs with Gentoo Linux (hardened; Grsecurity 
patched kernel, PaX, no RBAC).

All guests use raw images as disks (also tested QED and QCOW2). The systems are 
all Gentoo and Ubuntu. All having qemu-guest-agent running.

app-emulation/libvirt-1.2.18-r1::gentoo was built with the following:
USE="caps fuse iscsi libvirtd lvm lxc macvtap nfs nls parted pcap qemu sasl 
systemd udev vepa -apparmor -audit -avahi -firewalld -glusterfs -numa -openvz 
-phyp -policykit -rbd (-selinux) -uml -virt-network -virtualbox 
(-wireshark-plugins) -xen"

app-emulation/qemu-2.4.0::gentoo was built with the following:
USE="aio caps curl fdt filecaps jpeg ncurses nls pin-upstream-blobs png python 
sasl seccomp spice ssh threads tls uuid vhost-net vnc xattr -accessibility 
-alsa -bluetooth -debug -glusterfs -gtk -gtk2 -infiniband -iscsi -lzo -nfs 
-numa -opengl -pulseaudio -rbd -sdl -sdl2 (-selinux) -smartcard -snappy -static 
-static-softmmu -static-user -systemtap -tci -test -usb -usbredir -vde -virtfs 
-vte -xen -xfs" PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64 
-aarch64 (-alpha) (-arm) -cris -lm32 (-m68k) -microblaze -microblazeel (-mips) 
-mips64 -mips64el -mipsel -moxie -or32 (-ppc) (-ppc64) -ppcemb -s390x -sh4 
-sh4eb (-sparc) -sparc64 -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="i386 
x86_64 -aarch64 (-alpha) (-arm) -armeb -cris (-m68k) -microblaze -microblazeel 
(-mips) -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -or32 (-ppc) (-ppc64) 
-ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32"

I wrote a bash script hat shall backup all guests. It works like this:

1. Create external snapshot
2. Copy/rsync away the image
3. blockcommit snapshot
4. blockjob pivot
5. Copy/rsync away the XML description for the guest
6. Remove Snapshot file

I did some test running the script in a cron job. For this I found out that 
copying the image file takes round about 15 minutes. So I did a 30 minute cycle 
for the script.

4 or 5 cycles work perfectly. (1) and (2) are working and when it comes to 
blockcommit, the guest may (random) be aborted and the command fails to 
continue, because the guest is no longer running. Starting the guest again, I 
found two situations:

1. I can directly call blockjob … —pivot, because the last blockcommit that 
failed reached 100%, or
2. Run a blockjob abort action. Re-sync and pivot on command line and that 
might work.

Anyways, blockcommit is not stable here. I tested this on qemu-2.3.0 and 2.4.0

In the logs I only get this:

…
2015-08-24 18:38:13.077+: starting up libvirt version: 1.2.18, qemu 
version: 2.4.0
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name mx.roessner-net.de 
-TESTING -S -machine 
pc-i440fx-2.1,accel=kvm,usb=off -cpu qemu64,+kvm_pv_eoi -m 4096 -realtime 
mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 
d86b82d5-153f-4dd9-aa66-d98c2e65db8c -no-user-config -nodefaults -device sga 
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/mx.roessner-net.de 
-TESTING.monitor,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global 
kvm-pit.lost_tick_policy=discard -no-shutdown -boot order=cd,menu=on,strict=on 
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive 
file=/var/lib/libvirt/images/mx.roessner-net.de 
-TESTING.img,if=none,id=drive-virtio-disk0,format=raw,cache=writeback
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device 
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev 
tap,fd=34,id=hos

Re: [Qemu-devel] [PATCH v6 7/8] sPAPR: Support RTAS call ibm, {open, close}-errinjct

[Thomas Huth]

On 24/08/15 14:03, Gavin Shan wrote:
> This supports RTAS calls "ibm,{open,close}-errinjct" to manupliate
> the token, which is passed to RTAS call "ibm,errinjct" to indicate
> the valid context for error injection. Each VM is permitted to have
> only one token at once and we simply have sequential number for that.
> It's notable that the least bit of the token is reserved to indicate
> if the token has been opened, meaning the valid token should be always
> odd.
> 
> Signed-off-by: Gavin Shan 
> ---
>  hw/ppc/spapr.c |  6 -
>  hw/ppc/spapr_rtas.c| 60 
> ++
>  include/hw/ppc/spapr.h |  9 +++-
>  3 files changed, 73 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 06d000d..591a1a7 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1191,7 +1191,7 @@ static bool version_before_3(void *opaque, int 
> version_id)
>  
>  static const VMStateDescription vmstate_spapr = {
>  .name = "spapr",
> -.version_id = 3,
> +.version_id = 4,
>  .minimum_version_id = 1,
>  .post_load = spapr_post_load,
>  .fields = (VMStateField[]) {
> @@ -1202,6 +1202,10 @@ static const VMStateDescription vmstate_spapr = {
>  VMSTATE_UINT64_TEST(rtc_offset, sPAPRMachineState, version_before_3),
>  
>  VMSTATE_PPC_TIMEBASE_V(tb, sPAPRMachineState, 2),
> +
> +/* Error injection token */
> +VMSTATE_UINT32_V(errinjct_token, sPAPRMachineState, 4),
> +
>  VMSTATE_END_OF_LIST()
>  },
>  };
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index e99e25f..64924c6 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -604,6 +604,62 @@ out:
>  rtas_st(rets, 0, rc);
>  }
>  
> +static void rtas_ibm_open_errinjct(PowerPCCPU *cpu,
> +   sPAPRMachineState *spapr,
> +   uint32_t token, uint32_t nargs,
> +   target_ulong args, uint32_t nret,
> +   target_ulong rets)
> +{
> +int32_t ret;
> +
> +/* Sanity check on number of arguments */
> +if (nargs != 0 || nret != 2) {
> +ret = RTAS_OUT_PARAM_ERROR;
> +goto out;
> +}
> +
> +/* Check if we already had token */
> +if (spapr->errinjct_token & 1) {
> +ret = RTAS_OUT_TOKEN_OPENED;
> +goto out;
> +}
> +
> +/* Grab the token */
> +rtas_st(rets, 0, ++spapr->errinjct_token);
> +ret = RTAS_OUT_SUCCESS;
> +out:
> +rtas_st(rets, 1, ret);
> +}
> +
> +static void rtas_ibm_close_errinjct(PowerPCCPU *cpu,
> +sPAPRMachineState *spapr,
> +uint32_t token, uint32_t nargs,
> +target_ulong args, uint32_t nret,
> +target_ulong rets)
> +{
> +uint32_t open_token;
> +int32_t ret;
> +
> +/* Sanity check on number of arguments */
> +if (nargs != 1 || nret != 1) {
> +ret = RTAS_OUT_PARAM_ERROR;
> +goto out;
> +}
> +
> +/* Match with the passed token */
> +open_token = rtas_ld(args, 0);
> +if (!(spapr->errinjct_token & 1) ||
> +spapr->errinjct_token != open_token) {
> +ret = RTAS_OUT_CLOSE_ERROR;
> +goto out;
> +}
> +
> +spapr->errinjct_token++;
> +ret = RTAS_OUT_SUCCESS;
> +out:
> +rtas_st(rets, 0, ret);
> +}

This basically now looks fine to me! I am just wondering what happens
when the guest opens a token, but then resets the system before it
closes it again?
I.e. shouldn't the errinjct_token be set to 0 back again during the
reset handler?

 Thomas

[Qemu-devel] Creating snapshots with specific runtime options

[Alberto Garcia]

As far as I can see there's no way to create a snapshot and either

  a) inherit the runtime options from the original image
  b) specify a new set of options

This comment in external_snapshot_prepare() before calling bdrv_open()
suggests that the problem is known but the discussion was postponed.

/* TODO Inherit bs->options or only take explicit options with an
 * extended QMP command? */

I would like to retake this and make it possible. I discussed it
briefly with Stefan on IRC and he said that Kevin might have some
ideas.

In principle extending the QMP command sounds as simple as adding
'options': 'BlockdevOptions' to 'blockdev-snapshot-sync', but it's
surely more complicated than that :) Is the 'BlockdevOptions' API even
stable?

Berto

Re: [Qemu-devel] [RFC 2/4] hw/i386: Introduce AMD IOMMU

[Valentine Sinitsyn]

Hi,

On 25.08.2015 04:19, David Kiarie wrote:

From: David 

Add AMD IOMMU emulation to Qemu. This is a very basic AMD IOMMU
emulation that only does translation and some basic Event logging.
Guest translation enables nested PCI passthrough

Signed-off-by: David Kiarie 
---
  hw/i386/Makefile.objs |   1 +
  hw/i386/amd_iommu.c   | 993 ++
  hw/i386/amd_iommu.h   | 298 +++
  3 files changed, 1292 insertions(+)
  create mode 100644 hw/i386/amd_iommu.c
  create mode 100644 hw/i386/amd_iommu.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index ebd1015..2bae11c 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,6 +3,7 @@ obj-y += multiboot.o
  obj-y += pc.o pc_piix.o pc_q35.o
  obj-y += pc_sysfw.o
  obj-y += intel_iommu.o
+obj-y += amd_iommu.o
  obj-$(CONFIG_XEN) += ../xenpv/ xen/

  obj-y += kvmvapic.o
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
new file mode 100644
index 000..a3a0b20
--- /dev/null
+++ b/hw/i386/amd_iommu.c
@@ -0,0 +1,993 @@
+/*
+ * QEMU emulation of an AMD IOMMU (AMD-Vi)
+ *
+ * Copyright (C) 2011 Eduard - Gabriel Munteanu
+ * Copyright (C) 2015 David Kiarie, 
+ *
+ * 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 "hw/i386/amd_iommu.h"
+
+#define PCI_EXT_CAP_ID_PASID 0x1B
+#define PCI_EXT_CAP_ID_PRI   0x13
+
+#define PCI_SLOT(devfn)  (((devfn) >> 3) & 0x1f)
+#define PCI_FUNC(devfn)  ((devfn) & 0x07)
+
+#define MAX_VA_ADDR  (64UL << 5)
+#define MAX_PH_ADDR  (48UL << 8)
+#define MAX_GVA_ADDR (64UL << 15)
+
+//#define DEBUG_AMD_IOMMU
+#ifdef DEBUG_AMD_IOMMU
+enum {
+DEBUG_GENERAL, DEBUG_CAPAB, DEBUG_MMIO, DEBUG_ELOG,
+DEBUG_CACHE, DEBUG_COMMAND, DEBUG_MMU
+};
+
+#define IOMMU_DBGBIT(x)   (1 << DEBUG_##x)
+static int iommu_dbgflags = IOMMU_DBGBIT(GENERAL) | IOMMU_DBGBIT(MMU) | 
IOMMU_DBGBIT(MMIO);
+//| IOMMU_DBGBIT(CAPAB) | IOMMU_DBGBIT(ELOG) | IOMMU_DBGBIT(CACHE) | 
IOMMU_DBGBIT(COMMAND);
+
+#define IOMMU_DPRINTF(what, fmt, ...) do { \
+if (iommu_dbgflags & IOMMU_DBGBIT(what)) { \
+fprintf(stderr, "(amd-iommu)%s: " fmt "\n", __func__, \
+## __VA_ARGS__); } \
+} while (0)
+#else
+#define IOMMU_DPRINTF(what, fmt, ...) do {} while (0)
+#endif
+
+/* helper functions - FIXME - provide for reading one byte */
+static uint16_t amd_iommu_readw(AMDIOMMUState *s, hwaddr addr)
+{
+return lduw_le_p(&s->mmior[addr]);
+}
+
+static uint32_t amd_iommu_readl(AMDIOMMUState *s, hwaddr addr)
+{
+return ldl_le_p(&s->mmior[addr]);
+}
+
+static uint64_t amd_iommu_readq(AMDIOMMUState *s, hwaddr addr)
+{
+return ldq_le_p(&s->mmior[addr]);
+}
+
+static void amd_iommu_writew(AMDIOMMUState *s, hwaddr addr, uint16_t val)
+{
+stw_le_p(&s->mmior[addr], val);
+}
+
+static void amd_iommu_writel(AMDIOMMUState *s, hwaddr addr, uint32_t val)
+{
+stl_le_p(&s->mmior[addr], val);
+}
+
+static void amd_iommu_writeq(AMDIOMMUState *s, hwaddr addr, uint64_t val)
+{
+stq_le_p(&s->mmior[addr], val);
+}
+
+/* execute a completion wait command */
+static void amd_iommu_completion_wait(AMDIOMMUState *s, uint8_t *cmd)
+{
+unsigned int addr;
+
+/* completion store */
+if(cmd[0] & COM_COMPLETION_STORE_MASK){
+addr = le64_to_cpu(*(uint64_t*)cmd) & COM_STORE_ADDRESS_MASK;
+if(dma_memory_write(&address_space_memory, addr, cmd + 8, 8)){
+IOMMU_DPRINTF(ELOG, "error: fail to write at address 0%x"PRIx64, 
addr);
+}
+
+}
+
+/* set completion interrupt */
When I was experimenting with a real IOMMU, it all looked like if both 
COM_COMPLETION_STORE_MASK and COM_COMPLETION_BIT are set in the command, 
only an interrupt is generated. Could someone comment on this?



+if (cmd[0] & COM_COMPLETION_INTR){
+s->mmior[MMIO_STATUS] |= MMIO_STATUS_COMWAIT_INTR;
+}
+}
+
+static void amd_iommu_cmdbuf_exec(AMDIOMMUState *s)
+{
+unsigned type;
+uint8_t cmd[IOMMU_COMMAND_SIZE];
+
+IOMMU_DPRINTF(COMMAND, "");
+memset(cmd, 0, IOMMU_COMMAND_SIZE);
+
+if(dma_memory_read(&address_space_memory, s->cmdbuf + s->cmdbuf_head, cmd, 
IOMMU_COMMAND_SIZE)){
+IOMMU_DPRINTF(COMMAND, "error: fail to access memory at 0x%"PRIx64
+  " + %"PRIu8, s->cmdbuf, s->cmdbuf_head);
+}
+
+type = cmd[CMDBUF_ID_BYTE] >> CMDBUF_ID_RSHIFT;
+
+switch(type){
+

Re: [Qemu-devel] [PATCH v6 6/8] sPAPR: Introduce rtas_ldq()

[Thomas Huth]

On 24/08/15 14:03, Gavin Shan wrote:
> This introduces rtas_ldq() to load 64-bits parameter from continuous
> two 4-bytes memory chunk of RTAS parameter buffer, to simplify the
> code.
> 
> Signed-off-by: Gavin Shan 
> ---
>  hw/ppc/spapr_pci.c | 20 ++--
>  include/hw/ppc/spapr.h |  5 +
>  2 files changed, 15 insertions(+), 10 deletions(-)

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH] include/hw: field 'offset' in struct Property should be ptrdiff_t as int causes overflow

[Markus Armbruster]

Stumbled over this while throwing away old mail.  Andreas, what do you
think?

Ildar Isaev  writes:

> 'offset' field in struct Property is calculated as a diff between two 
> pointers (hw/core/qdev-properties.c:802)
>
> arrayprop->prop.offset = eltptr - (void *)dev;
>
> If offset is declared as int, this subtraction can cause type overflow
> thus leading to the fall of the subsequent assert 
> (hw/core/qdev-properties.c:803)
>
> assert(qdev_get_prop_ptr(dev, &arrayprop->prop) == eltptr);
>
> So ptrdiff_t should be used instead
>
> Signed-off-by: Ildar Isaev 
> ---
>  include/hw/qdev-core.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index 4e673f9..f0e2a73 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -224,7 +224,7 @@ struct BusState {
>  struct Property {
>  const char   *name;
>  PropertyInfo *info;
> -int  offset;
> +ptrdiff_toffset;
>  uint8_t  bitnr;
>  uint8_t  qtype;
>  int64_t  defval;

Re: [Qemu-devel] [PATCH] target-sparc: Store mmu index in TB flags

[Richard Henderson]

On 08/24/2015 11:44 PM, Artyom Tarasenko wrote:

This is very surprising: the patch should have no effect on a sun4u machine.


Er, no, it should.  The primary vector by which I expect improvement is via not 
encoding dmmu.mmu_primary_context into the TB flags.  I.e. ASI_DMMU, which 
sun4u certainly uses.


The fact that the patch _also_ fixes a sun4v problem is secondary.


r~

Re: [Qemu-devel] [PATCH v14 30/33] target-tilegx: Handle atomic instructions

[Richard Henderson]

On 08/25/2015 06:12 AM, Chen Gang wrote:





From: xili_gchen_5...@hotmail.com
To: r...@twiddle.net; qemu-devel@nongnu.org
CC: w...@tilera.com; cmetc...@ezchip.com; peter.mayd...@linaro.org
Subject: Re: [Qemu-devel] [PATCH v14 30/33] target-tilegx: Handle atomic 
instructions
Date: Tue, 25 Aug 2015 21:11:11 +0800

On 8/25/15 12:15, Richard Henderson wrote:

On 08/24/2015 09:17 AM, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
target-tilegx/translate.c | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index 210e912..2a0798a 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -180,6 +180,19 @@ static void gen_saturate_op(TCGv tdest, TCGv tsrca, TCGv 
tsrcb,
tcg_temp_free(t0);
}

+static void gen_atomic_excp(DisasContext *dc, unsigned dest, unsigned srca,
+ unsigned srcb, TileExcp excp)
+{
+#ifdef CONFIG_USER_ONLY
+ TCGv_i32 t = tcg_const_i32((dest << 16) | (srca << 8) | srcb);
+ tcg_gen_st_i32(t, cpu_env, offsetof(CPUTLGState, excparam));
+ tcg_temp_free_i32(t);
+ gen_exception(dc, excp);
+#else
+ gen_exception(dc, TILEGX_EXCP_OPCODE_UNIMPLEMENTED);
+#endif
+}


Originally, I used set_exception(), not gen_exception().




This is broken. While it does work well enough for Hello World, implementing a 
non-trap instruction with an exception is extremely dicey for TileGX. The issue 
is that TileGX bundles operate atomically, with no RAW issues between the 
instructions of the bundle.

Consider a bundle like

{ add r0, r0, r1 ; exch r2, r0, r3 }

In Chen's implementation, the writeback to r0 would occur before the exception, 
and so the exch would happen to the wrong address. In my implementation here, 
the exception would occur before the writeback, and so the result of the add 
would be discarded.


We use tmp regs for buffering the r0.

- calculate x1 pipe, and save result to r0 tmp reg.



Oh, typo, calculate x0 pipe, and save result to r0 tmp reg.


- exch the original r0 and r3 to r2 tmp reg.

- set exception flag (which will cause exception, later).

- save the result tmp regs to r0 or r2.

- gen exception.


Exactly.  Now re-read what I wrote and see if you can spot the problem with 
this.


r~

Re: [Qemu-devel] [PATCH] include/hw: field 'offset' in struct Property should be ptrdiff_t as int causes overflow

[Peter Maydell]

On 25 August 2015 at 15:17, Markus Armbruster  wrote:
> Stumbled over this while throwing away old mail.  Andreas, what do you
> think?

Seems right to me -- I suspect the original properties code was
written with the assumption that the property field would be
inside the device struct (and so offsets are small). The array
properties code breaks that assumption by allocating a separate
lump of memory with the properties in it; so now there's no
guarantee that the two pointers being subtracted will be
within 4G of each other.

Reviewed-by: Peter Maydell 

Arguably for consistency the 'arrayoffset' struct member should
also be a ptrdiff_t, though our current uses of it are such
that it'll always be within int range.

-- PMM

Re: [Qemu-devel] [PULL 00/18] Queued TCG patches

[Peter Maydell]

On 24 August 2015 at 20:36, Richard Henderson  wrote:
> Third time's the charm, right?
>
> This time with the arm crash fixed, and two new patches from
> Laurent that came in just as I was preparing this rebase.
>
>
> r~
>
>
> The following changes since commit a30878e708c2149ce07d709a8b62edd944628449:
>
>   configure: Don't permit SDL or GTK on OSX (2015-08-19 20:29:30 +0100)
>
> are available in the git repository at:
>
>   git://github.com/rth7680/qemu.git tags/pull-tcg-20150824
>
> for you to fetch changes up to b76f21a70748b735d6ac84fec4bb9bdaafa339b1:
>
>   linux-user: remove useless macros GUEST_BASE and RESERVED_VA (2015-08-24 
> 11:14:30 -0700)
>
> 
> queued tcg patches
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v2 06/18] pc: implement NVDIMM device abstract

[Stefan Hajnoczi]

On Fri, Aug 14, 2015 at 10:51:59PM +0800, Xiao Guangrong wrote:
> +static void set_file(Object *obj, const char *str, Error **errp)
> +{
> +PCNVDIMMDevice *nvdimm = PC_NVDIMM(obj);
> +
> +if (nvdimm->file) {
> +g_free(nvdimm->file);
> +}

g_free(NULL) is a nop so it's safe to replace the if with just
g_free(nvdimm->file).

Re: [Qemu-devel] [PATCH] target-sparc: Store mmu index in TB flags

[Dennis Luehring]

Am 25.08.2015 um 16:25 schrieb Richard Henderson:

Er, no, it should.  The primary vector by which I expect improvement is via not
encoding dmmu.mmu_primary_context into the TB flags.  I.e. ASI_DMMU, which
sun4u certainly uses.

The fact that the patch_also_  fixes a sun4v problem is secondary.


please, can you(or someone else) give me a feedback about my 
tests/numbers - and the relevance of them - the stream benchmarks 
results seems to be worser then before
and the compilespeed is just a little bit better - so i don't understand 
(at all) what problems are fixed or what is improved now - the 
compilation test is still 180 times

slower then on my host

Re: [Qemu-devel] qemu-doc.texi: Improve USB documentation... and maybe even QEMU also

[Programmingkid]

On Aug 25, 2015, at 3:43 AM, Markus Armbruster wrote:

> Programmingkid  writes:
> 
>> On Aug 24, 2015, at 12:38 PM, Markus Armbruster wrote:
>> 
>>> Programmingkid  writes:
>>> 
 On Aug 24, 2015, at 5:45 AM, Markus Armbruster wrote:
 
> Copying the USB maintainer.
> 
> Programmingkid  writes:
> 
>> On Aug 8, 2015, at 8:48 AM, Programmingkid wrote:
>> 
>>> 
>>> On Aug 8, 2015, at 2:04 AM, Markus Armbruster wrote:
> 
> USB devices can be connected with the @option{-usbdevice}
> commandline option
> -or the @code{usb_add} monitor command.  Available devices are:
> +or the @code{usb_add} monitor command. Note: some devices may
> only work if
> +added like this: -usb -device . Available devices are:
 
 I'm afraid "may only work" is a bit misleading.  All of them work with
 -device.  Old ones are also supported by -usbdevice for backward
 compatibility.  The whole section should be rewritten to point to
 -device instead of legacy -usbdevice, but that's no reason to hold up
 your patch.
>>> 
>>> I did not know -usbdevice was considered legacy. If that is the
>>> case, then it should probably
>>> be removed from the documentation in favor for -usb -device
>>> .
>> 
>> Right now using "-usb -device mouse" doesn't work.
> 
> You need to say -device usb-mouse.  See docs/qdev-device-use.txt.  Does
> it work for you when you do that?
 
 It does. Thank you for this information. 
>>> 
>>> My pleasure.
>>> 
>> Neither does
>> "-usbdevice usb-audio".
> 
> Yes.  Legacy -usbdevice only supports the devices that predate -device.
> 
>> I think we can all agree that consistency among all the USB devices is
>> a good thing.
>> Should all USB devices be added like this: -usb -device  ? 
> 
> "Should" is perhaps a bit strong.  While -device is the recommended way
> to add a USB device, -usbdevice is still a supported (if legacy) way to
> do it.
> 
> Of course, "supported, but legacy" interfaces such as -usbdevice may
> become deprecated, and then you should really move to newer interfaces,
> because deprecated ones may go away.  Doesn't look terribly probable to
> me for -usbdevice, though.
> 
>> This is an experimental patch of not how QEMU currently works, but how
>> I think it should work.
>> 
>> This documentation adds an "usb_remove" monitor command. This isn't
>> available right now,
>> but a patch could be made to change this. Any suggestions or additions
>> are welcomed.
> 
> Why do you think we need usb_remove in addition to device_del?
 
 Ok. usb_remove isn't needed. Why is it that "device_add usb-kbd" works, but
 "device_del usb-kbd" doesn't work? I am given this error message:
 "Device 'usb-kbd' not found".
>>> 
>>> device_del's argument isn't a driver, it's a device ID.  Try this:
>>> 
>>>   (qemu) device_add usb-mouse,id=mouse0
>>>   (qemu) info usb
>>> Device 0.0, Port 1, Speed 12 Mb/s, Product QEMU USB Mouse
>>>   (qemu) device_del mouse0
>>>   (qemu) info usb
>>>   (qemu) 
>> 
>> The problem is with "info usb". It doesn't print the id you gave it. I
>> will make a patch that
>> will print the id's. 
> 
> Yes, "info usb" doesn't show the qdev ID.  Neither does "info pci".
> "info qom" and "info qtree" do.

It sounds like these info's could use some improving...

Re: [Qemu-devel] [PATCH] qdev-monitor.c: Add device id generation

[Programmingkid]

On Aug 24, 2015, at 6:21 PM, Eric Blake wrote:

> On 08/24/2015 12:53 PM, Programmingkid wrote:
>> Add device ID generation to each device if an ID isn't given.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
> 
>> dev->id = id;
>> +} else { /* create an id for a device if none is provided */
>> +static int device_id_count;
>> +
>> +/* Add one for '\0' character */
>> +char *device_id = (char *) malloc(sizeof(char) *
>> +MAX_NUM_DIGITS_FOR_USB_ID + 1);
>> +sprintf(device_id, "%d", device_id_count++);
> 
> g_strdup_printf() is a lot nicer about avoiding the risk of arbitrary
> overflow...
I prefer to use well known functions that work well, but I guess it shouldn't 
be too
painful to use the g_strdup_printf() function. Do you really think there is a 
possible
overflow condition here?


> 
>> +dev->id = (const char *) device_id;
>> +
>> +/* if device_id_count >= 10^MAX_NUM_DIGITS_FOR_USB_ID */
>> +if (device_id_count >= pow(10, MAX_NUM_DIGITS_FOR_USB_ID)) {
>> +printf("Warning: Maximum number of device ID's generated!\n\a");
>> +printf("Time for you to make your own device ID's.\n");
> 
> besides, printf() is probably the wrong way to do error reporting, and
Why do you believe this? 

> we don't use \a BEL sequences anywhere else in qemu code.
Innovation has to start somewhere :)


> 
>> +}
>> }
>> 
>> if (dev->id) {
> 
> This if would now be a dead check if your patch is applied.
I think you are right. It will be removed.

> 
>> object_property_add_child(qdev_get_peripheral(), dev->id,
>>   OBJECT(dev), NULL);
>> -} else {
>> -static int anon_count;
>> -gchar *name = g_strdup_printf("device[%d]", anon_count++);
>> -object_property_add_child(qdev_get_peripheral_anon(), name,
>> -  OBJECT(dev), NULL);
>> -g_free(name);
>> }
> 
> It looks like your goal was to move this code earlier, but you changed
> enough aspects of it that I'm not sure what the right fix should be.

I didn't want to move the code. It just was in a condition that would never
be true, so I thought why keep it.

> -- 
> Eric Blake   eblake redhat com+1-919-301-3266

Thank you very much for reviewing my patch. 

> Libvirt virtualization library http://libvirt.org

You work with this project? Any chance libvirt could support Mac OS X?

[Qemu-devel] [PULL 19/20] target-arm: Implement missing EL3 TLB invalidate operations

[Peter Maydell]

Implement the remaining stage 1 TLB invalidate operations
visible from EL3.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1439548879-1972-6-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 76 +
 1 file changed, 76 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 6c38d66..00ecda9 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2567,6 +2567,15 @@ static void tlbi_aa64_alle2_write(CPUARMState *env, 
const ARMCPRegInfo *ri,
 tlb_flush_by_mmuidx(cs, ARMMMUIdx_S1E2, -1);
 }
 
+static void tlbi_aa64_alle3_write(CPUARMState *env, const ARMCPRegInfo *ri,
+  uint64_t value)
+{
+ARMCPU *cpu = arm_env_get_cpu(env);
+CPUState *cs = CPU(cpu);
+
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S1E3, -1);
+}
+
 static void tlbi_aa64_alle1is_write(CPUARMState *env, const ARMCPRegInfo *ri,
 uint64_t value)
 {
@@ -2601,6 +2610,16 @@ static void tlbi_aa64_alle2is_write(CPUARMState *env, 
const ARMCPRegInfo *ri,
 }
 }
 
+static void tlbi_aa64_alle3is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+CPUState *other_cs;
+
+CPU_FOREACH(other_cs) {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S1E3, -1);
+}
+}
+
 static void tlbi_aa64_vae1_write(CPUARMState *env, const ARMCPRegInfo *ri,
  uint64_t value)
 {
@@ -2636,6 +2655,20 @@ static void tlbi_aa64_vae2_write(CPUARMState *env, const 
ARMCPRegInfo *ri,
 tlb_flush_page_by_mmuidx(cs, pageaddr, ARMMMUIdx_S1E2, -1);
 }
 
+static void tlbi_aa64_vae3_write(CPUARMState *env, const ARMCPRegInfo *ri,
+ uint64_t value)
+{
+/* Invalidate by VA, EL3
+ * Currently handles both VAE3 and VALE3, since we don't support
+ * flush-last-level-only.
+ */
+ARMCPU *cpu = arm_env_get_cpu(env);
+CPUState *cs = CPU(cpu);
+uint64_t pageaddr = sextract64(value << 12, 0, 56);
+
+tlb_flush_page_by_mmuidx(cs, pageaddr, ARMMMUIdx_S1E3, -1);
+}
+
 static void tlbi_aa64_vae1is_write(CPUARMState *env, const ARMCPRegInfo *ri,
uint64_t value)
 {
@@ -2665,6 +2698,17 @@ static void tlbi_aa64_vae2is_write(CPUARMState *env, 
const ARMCPRegInfo *ri,
 }
 }
 
+static void tlbi_aa64_vae3is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+   uint64_t value)
+{
+CPUState *other_cs;
+uint64_t pageaddr = sextract64(value << 12, 0, 56);
+
+CPU_FOREACH(other_cs) {
+tlb_flush_page_by_mmuidx(other_cs, pageaddr, ARMMMUIdx_S1E3, -1);
+}
+}
+
 static CPAccessResult aa64_zva_access(CPUARMState *env, const ARMCPRegInfo *ri)
 {
 /* We don't implement EL2, so the only control on DC ZVA is the
@@ -2849,10 +2893,18 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 4,
   .access = PL2_W, .type = ARM_CP_NO_RAW,
   .writefn = tlbi_aa64_alle1is_write },
+{ .name = "TLBI_VMALLS12E1IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 6,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle1is_write },
 { .name = "TLBI_ALLE1", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 4,
   .access = PL2_W, .type = ARM_CP_NO_RAW,
   .writefn = tlbi_aa64_alle1_write },
+{ .name = "TLBI_VMALLS12E1", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 6,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle1is_write },
 #ifndef CONFIG_USER_ONLY
 /* 64 bit address translation operations */
 { .name = "AT_S1E1R", .state = ARM_CP_STATE_AA64,
@@ -3317,6 +3369,30 @@ static const ARMCPRegInfo el3_cp_reginfo[] = {
   .opc0 = 3, .opc1 = 6, .crn = 5, .crm = 1, .opc2 = 1,
   .access = PL3_RW, .type = ARM_CP_CONST,
   .resetvalue = 0 },
+{ .name = "TLBI_ALLE3IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 3, .opc2 = 0,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle3is_write },
+{ .name = "TLBI_VAE3IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 3, .opc2 = 1,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vae3is_write },
+{ .name = "TLBI_VALE3IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 3, .opc2 = 5,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vae3is_write },
+{ .name = "TLBI_ALLE3", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 7, .opc2 = 0,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle3_write },
+{ .name = "TLBI_VAE3", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 

[Qemu-devel] [PULL 00/20] target-arm queue

[Peter Maydell]

Here's the ARM queue. I know I have a pile of backed-up code
review to do, but I wanted to get these patches out rather
than accumulating a fifty-patch queue...

thanks
-- PMM

The following changes since commit 34a4450434f1a5daee06fca223afcbb9c8f1ee24:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20150824' into 
staging (2015-08-25 13:34:57 +0100)

are available in the git repository at:


  git://git.linaro.org/people/pmaydell/qemu-arm.git 
tags/pull-target-arm-20150825

for you to fetch changes up to ff4657fa18b08279ce1f79da35a0e9e0b9574dd5:

  target-arm: Implement AArch64 TLBI operations on IPAs (2015-08-25 15:45:10 
+0100)


target-arm queue:
 * add missing EL2/EL3 TLBI operations
 * add missing EL2/EL3 ATS operations
 * add missing EL2/EL3 registers
 * update Xilinx MAINTAINERS info
 * Xilinx: connect the four OCM banks
 * virt: add SMBIOS support


Alistair Francis (3):
  xlnx-zynqmp: Connect the four OCM banks
  MAINTAINERS: Update Xilinx Maintainership
  MAINTAINERS: Add ZynqMP to MAINTAINERS file

Peter Maydell (15):
  target-arm: Add missing MAIR_EL3 and TPIDR_EL3 registers
  target-arm: Implement missing AMAIR registers
  target-arm: Implement missing AFSR registers
  target-arm: Implement missing ACTLR registers
  target-arm: there is no TTBR1 for 32-bit EL2 stage 1 translations
  target-arm: Wire up AArch64 EL2 and EL3 address translation ops
  target-arm: Add CP_ACCESS_TRAP_UNCATEGORIZED_EL2, 3
  target-arm: Enable the AArch32 ATS12NSO ops
  target-arm: Implement AArch32 ATS1H* operations
  cputlb: Add functions for flushing TLB for a single MMU index
  target-arm: Move TLBI ALLE1/ALLE1IS definitions into numeric order
  target-arm: Restrict AArch64 TLB flushes to the MMU indexes they must 
touch
  target-arm: Implement missing EL2 TLBI operations
  target-arm: Implement missing EL3 TLB invalidate operations
  target-arm: Implement AArch64 TLBI operations on IPAs

Wei Huang (2):
  smbios: add smbios 3.0 support
  smbios: implement smbios support for mach-virt

 MAINTAINERS |  27 ++-
 cputlb.c|  97 
 default-configs/arm-softmmu.mak |   1 +
 hw/arm/virt.c   |  26 +++
 hw/arm/xlnx-zynqmp.c|  15 ++
 hw/i386/pc_piix.c   |   3 +-
 hw/i386/pc_q35.c|   3 +-
 hw/smbios/smbios.c  |  84 +--
 include/exec/exec-all.h |  47 
 include/hw/arm/xlnx-zynqmp.h|   6 +
 include/hw/smbios/smbios.h  |  51 +++--
 qemu-options.hx |   2 +-
 target-arm/cpu.h|   3 +
 target-arm/helper.c | 489 +++-
 target-arm/op_helper.c  |   8 +
 15 files changed, 759 insertions(+), 103 deletions(-)

[Qemu-devel] [PULL 18/20] target-arm: Implement missing EL2 TLBI operations

[Peter Maydell]

Implement the missing TLBI operations that exist only
if EL2 is implemented.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1439548879-1972-5-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index c8d07d9..6c38d66 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2591,6 +2591,16 @@ static void tlbi_aa64_alle1is_write(CPUARMState *env, 
const ARMCPRegInfo *ri,
 }
 }
 
+static void tlbi_aa64_alle2is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+CPUState *other_cs;
+
+CPU_FOREACH(other_cs) {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S1E2, -1);
+}
+}
+
 static void tlbi_aa64_vae1_write(CPUARMState *env, const ARMCPRegInfo *ri,
  uint64_t value)
 {
@@ -3146,10 +3156,22 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 1,
   .type = ARM_CP_NO_RAW, .access = PL2_W,
   .writefn = tlbi_aa64_vae2_write },
+{ .name = "TLBI_VALE2", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vae2_write },
+{ .name = "TLBI_ALLE2IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 0,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle2is_write },
 { .name = "TLBI_VAE2IS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 1,
   .type = ARM_CP_NO_RAW, .access = PL2_W,
   .writefn = tlbi_aa64_vae2is_write },
+{ .name = "TLBI_VALE2IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vae2is_write },
 #ifndef CONFIG_USER_ONLY
 /* Unlike the other EL2-related AT operations, these must
  * UNDEF from EL3 if EL2 is not implemented, which is why we
-- 
1.9.1

[Qemu-devel] [PULL 07/20] target-arm: Implement missing ACTLR registers

[Peter Maydell]

We already implemented ACTLR_EL1; add the missing ACTLR_EL2 and
ACTLR_EL3, for consistency.

Since we don't currently have any CPUs that need the EL2/EL3
versions to reset to non-zero values, implement as RAZ/WI.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1438281398-18746-5-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index f6119be..97ca86a 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -3936,13 +3936,22 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 }
 
 if (arm_feature(env, ARM_FEATURE_AUXCR)) {
-ARMCPRegInfo auxcr = {
-.name = "ACTLR_EL1", .state = ARM_CP_STATE_BOTH,
-.opc0 = 3, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 1,
-.access = PL1_RW, .type = ARM_CP_CONST,
-.resetvalue = cpu->reset_auxcr
+ARMCPRegInfo auxcr_reginfo[] = {
+{ .name = "ACTLR_EL1", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 1,
+  .access = PL1_RW, .type = ARM_CP_CONST,
+  .resetvalue = cpu->reset_auxcr },
+{ .name = "ACTLR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 1, .crm = 0, .opc2 = 1,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+{ .name = "ACTLR_EL3", .state = ARM_CP_STATE_AA64,
+  .opc0 = 3, .opc1 = 6, .crn = 1, .crm = 0, .opc2 = 1,
+  .access = PL3_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+REGINFO_SENTINEL
 };
-define_one_arm_cp_reg(cpu, &auxcr);
+define_arm_cp_regs(cpu, auxcr_reginfo);
 }
 
 if (arm_feature(env, ARM_FEATURE_CBAR)) {
-- 
1.9.1

[Qemu-devel] [PULL 06/20] target-arm: Implement missing AFSR registers

[Peter Maydell]

The AFSR registers are implementation dependent auxiliary fault
status registers. We already implemented a RAZ/WI AFSR0_EL1 and
AFSR_EL1; add the missing AFSR{0,1}_EL{2,3} for consistency.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1438281398-18746-4-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 54f99ae..f6119be 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2848,6 +2848,14 @@ static const ARMCPRegInfo el3_no_el2_cp_reginfo[] = {
   .opc1 = 4, .crn = 10, .crm = 3, .opc2 = 1,
   .access = PL2_RW, .type = ARM_CP_CONST,
   .resetvalue = 0 },
+{ .name = "AFSR0_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 1, .opc2 = 0,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+{ .name = "AFSR1_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 1, .opc2 = 1,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
 { .name = "TCR_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 2, .crm = 0, .opc2 = 2,
   .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
@@ -2972,6 +2980,14 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
   .opc1 = 4, .crn = 10, .crm = 3, .opc2 = 1,
   .access = PL2_RW, .type = ARM_CP_CONST,
   .resetvalue = 0 },
+{ .name = "AFSR0_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 1, .opc2 = 0,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+{ .name = "AFSR1_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 1, .opc2 = 1,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
 { .name = "TCR_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 2, .crm = 0, .opc2 = 2,
   .access = PL2_RW, .writefn = vmsa_tcr_el1_write,
@@ -3118,6 +3134,14 @@ static const ARMCPRegInfo el3_cp_reginfo[] = {
   .opc0 = 3, .opc1 = 6, .crn = 10, .crm = 3, .opc2 = 0,
   .access = PL3_RW, .type = ARM_CP_CONST,
   .resetvalue = 0 },
+{ .name = "AFSR0_EL3", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 6, .crn = 5, .crm = 1, .opc2 = 0,
+  .access = PL3_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+{ .name = "AFSR1_EL3", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 6, .crn = 5, .crm = 1, .opc2 = 1,
+  .access = PL3_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
 REGINFO_SENTINEL
 };
 
-- 
1.9.1

[Qemu-devel] [PULL 05/20] target-arm: Implement missing AMAIR registers

[Peter Maydell]

The AMAIR registers are for providing auxiliary implementation
defined memory attributes. We already implemented a RAZ/WI
AMAIR_EL1; add the EL2 and EL3 versions for consistency.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1438281398-18746-3-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 749749e..54f99ae 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2840,6 +2840,14 @@ static const ARMCPRegInfo el3_no_el2_cp_reginfo[] = {
 { .name = "HMAIR1", .state = ARM_CP_STATE_AA32,
   .opc1 = 4, .crn = 10, .crm = 2, .opc2 = 1,
   .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+{ .name = "AMAIR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 10, .crm = 3, .opc2 = 0,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+{ .name = "HMAIR1", .state = ARM_CP_STATE_AA32,
+  .opc1 = 4, .crn = 10, .crm = 3, .opc2 = 1,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
 { .name = "TCR_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 2, .crm = 0, .opc2 = 2,
   .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
@@ -2955,6 +2963,15 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
   .opc1 = 4, .crn = 10, .crm = 2, .opc2 = 1,
   .access = PL2_RW, .type = ARM_CP_ALIAS,
   .fieldoffset = offsetofhigh32(CPUARMState, cp15.mair_el[2]) },
+{ .name = "AMAIR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 10, .crm = 3, .opc2 = 0,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
+/* HAMAIR1 is mapped to AMAIR_EL2[63:32] */
+{ .name = "HMAIR1", .state = ARM_CP_STATE_AA32,
+  .opc1 = 4, .crn = 10, .crm = 3, .opc2 = 1,
+  .access = PL2_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
 { .name = "TCR_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 2, .crm = 0, .opc2 = 2,
   .access = PL2_RW, .writefn = vmsa_tcr_el1_write,
@@ -3097,6 +3114,10 @@ static const ARMCPRegInfo el3_cp_reginfo[] = {
   .opc0 = 3, .opc1 = 6, .crn = 13, .crm = 0, .opc2 = 2,
   .access = PL3_RW, .resetvalue = 0,
   .fieldoffset = offsetof(CPUARMState, cp15.tpidr_el[3]) },
+{ .name = "AMAIR_EL3", .state = ARM_CP_STATE_AA64,
+  .opc0 = 3, .opc1 = 6, .crn = 10, .crm = 3, .opc2 = 0,
+  .access = PL3_RW, .type = ARM_CP_CONST,
+  .resetvalue = 0 },
 REGINFO_SENTINEL
 };
 
-- 
1.9.1

[Qemu-devel] [PULL 10/20] target-arm: Add CP_ACCESS_TRAP_UNCATEGORIZED_EL2, 3

[Peter Maydell]

Some coprocessor register access functions need to be able
to report "trap to EL3 with an 'uncategorized' syndrome";
add the necessary CPAccessResult enum and handling for it.

I don't currently know of any registers that need to trap
to EL2 with the 'uncategorized' syndrome, but adding the
_EL2 enum as well is trivial and fills in what would
otherwise be an odd gap in the handling.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1437751263-21913-4-git-send-email-peter.mayd...@linaro.org
---
 target-arm/cpu.h   | 3 +++
 target-arm/op_helper.c | 8 
 2 files changed, 11 insertions(+)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 2e680da..31825d3 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -1284,6 +1284,9 @@ typedef enum CPAccessResult {
 /* As CP_ACCESS_TRAP, but for traps directly to EL2 or EL3 */
 CP_ACCESS_TRAP_EL2 = 3,
 CP_ACCESS_TRAP_EL3 = 4,
+/* As CP_ACCESS_UNCATEGORIZED, but for traps directly to EL2 or EL3 */
+CP_ACCESS_TRAP_UNCATEGORIZED_EL2 = 5,
+CP_ACCESS_TRAP_UNCATEGORIZED_EL3 = 6,
 } CPAccessResult;
 
 /* Access functions for coprocessor registers. These cannot fail and
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index 663c05d..1425a1d 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -444,6 +444,14 @@ void HELPER(access_check_cp_reg)(CPUARMState *env, void 
*rip, uint32_t syndrome)
 target_el = exception_target_el(env);
 syndrome = syn_uncategorized();
 break;
+case CP_ACCESS_TRAP_UNCATEGORIZED_EL2:
+target_el = 2;
+syndrome = syn_uncategorized();
+break;
+case CP_ACCESS_TRAP_UNCATEGORIZED_EL3:
+target_el = 3;
+syndrome = syn_uncategorized();
+break;
 default:
 g_assert_not_reached();
 }
-- 
1.9.1

[Qemu-devel] [PULL 09/20] target-arm: Wire up AArch64 EL2 and EL3 address translation ops

[Peter Maydell]

Wire up the AArch64 EL2 and EL3 address translation operations
(AT S12E1*, AT S12E0*, AT S1E2*, AT S1E3*), and correct some
errors in the ats_write64() function in previously unused code
that would have done the wrong kind of lookup for accesses from
EL3 when SCR.NS==0.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1437751263-21913-3-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 86d0baf..8603660 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1844,6 +1844,14 @@ static void ats_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 A32_BANKED_CURRENT_REG_SET(env, par, par64);
 }
 
+static CPAccessResult at_s1e2_access(CPUARMState *env, const ARMCPRegInfo *ri)
+{
+if (arm_current_el(env) == 3 && !(env->cp15.scr_el3 & SCR_NS)) {
+return CP_ACCESS_TRAP;
+}
+return CP_ACCESS_OK;
+}
+
 static void ats_write64(CPUARMState *env, const ARMCPRegInfo *ri,
 uint64_t value)
 {
@@ -1871,10 +1879,10 @@ static void ats_write64(CPUARMState *env, const 
ARMCPRegInfo *ri,
 mmu_idx = secure ? ARMMMUIdx_S1SE0 : ARMMMUIdx_S1NSE0;
 break;
 case 4: /* AT S12E1R, AT S12E1W */
-mmu_idx = ARMMMUIdx_S12NSE1;
+mmu_idx = secure ? ARMMMUIdx_S1SE1 : ARMMMUIdx_S12NSE1;
 break;
 case 6: /* AT S12E0R, AT S12E0W */
-mmu_idx = ARMMMUIdx_S12NSE0;
+mmu_idx = secure ? ARMMMUIdx_S1SE0 : ARMMMUIdx_S12NSE0;
 break;
 default:
 g_assert_not_reached();
@@ -2746,6 +2754,25 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "AT_S1E0W", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 8, .opc2 = 3,
   .access = PL1_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+{ .name = "AT_S12E1R", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 8, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+{ .name = "AT_S12E1W", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 8, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+{ .name = "AT_S12E0R", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 8, .opc2 = 6,
+  .access = PL2_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+{ .name = "AT_S12E0W", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 8, .opc2 = 7,
+  .access = PL2_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+/* AT S1E2* are elsewhere as they UNDEF from EL3 if EL2 is not present */
+{ .name = "AT_S1E3R", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 7, .crm = 8, .opc2 = 0,
+  .access = PL3_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+{ .name = "AT_S1E3W", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 7, .crm = 8, .opc2 = 1,
+  .access = PL3_W, .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
 #endif
 /* TLB invalidate last level of translation table walk */
 { .name = "TLBIMVALIS", .cp = 15, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 5,
@@ -3021,6 +3048,18 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
   .type = ARM_CP_NO_RAW, .access = PL2_W,
   .writefn = tlbi_aa64_vaa_write },
 #ifndef CONFIG_USER_ONLY
+/* Unlike the other EL2-related AT operations, these must
+ * UNDEF from EL3 if EL2 is not implemented, which is why we
+ * define them here rather than with the rest of the AT ops.
+ */
+{ .name = "AT_S1E2R", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 7, .crm = 8, .opc2 = 0,
+  .access = PL2_W, .accessfn = at_s1e2_access,
+  .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+{ .name = "AT_S1E2W", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 7, .crm = 8, .opc2 = 1,
+  .access = PL2_W, .accessfn = at_s1e2_access,
+  .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
 { .name = "CNTHCTL_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 14, .crm = 1, .opc2 = 0,
   /* ARMv7 requires bit 0 and 1 to reset to 1. ARMv8 defines the
-- 
1.9.1

[Qemu-devel] [PULL 04/20] target-arm: Add missing MAIR_EL3 and TPIDR_EL3 registers

[Peter Maydell]

Add the AArch64 registers MAIR_EL3 and TPIDR_EL3, which are the only
two which we had implemented the 32-bit Secure equivalents of but
not the 64-bit Secure versions.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1438281398-18746-2-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1568aa6..749749e 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1022,6 +1022,10 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
   .opc0 = 3, .opc1 = 0, .crn = 10, .crm = 2, .opc2 = 0,
   .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.mair_el[1]),
   .resetvalue = 0 },
+{ .name = "MAIR_EL3", .state = ARM_CP_STATE_AA64,
+  .opc0 = 3, .opc1 = 6, .crn = 10, .crm = 2, .opc2 = 0,
+  .access = PL3_RW, .fieldoffset = offsetof(CPUARMState, cp15.mair_el[3]),
+  .resetvalue = 0 },
 /* For non-long-descriptor page tables these are PRRR and NMRR;
  * regardless they still act as reads-as-written for QEMU.
  */
@@ -3089,6 +3093,10 @@ static const ARMCPRegInfo el3_cp_reginfo[] = {
   .opc0 = 3, .opc1 = 6, .crn = 1, .crm = 1, .opc2 = 2,
   .access = PL3_RW, .accessfn = cptr_access, .resetvalue = 0,
   .fieldoffset = offsetof(CPUARMState, cp15.cptr_el[3]) },
+{ .name = "TPIDR_EL3", .state = ARM_CP_STATE_AA64,
+  .opc0 = 3, .opc1 = 6, .crn = 13, .crm = 0, .opc2 = 2,
+  .access = PL3_RW, .resetvalue = 0,
+  .fieldoffset = offsetof(CPUARMState, cp15.tpidr_el[3]) },
 REGINFO_SENTINEL
 };
 
-- 
1.9.1

[Qemu-devel] [PULL 12/20] target-arm: Implement AArch32 ATS1H* operations

[Peter Maydell]

Implement the AArch32 ATS1H* operations which perform
Hyp mode stage 1 translations.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1437751263-21913-6-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 4b2fc090..6c55cc4 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1849,6 +1849,17 @@ static void ats_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 A32_BANKED_CURRENT_REG_SET(env, par, par64);
 }
 
+static void ats1h_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+int access_type = ri->opc2 & 1;
+uint64_t par64;
+
+par64 = do_ats_write(env, value, access_type, ARMMMUIdx_S2NS);
+
+A32_BANKED_CURRENT_REG_SET(env, par, par64);
+}
+
 static CPAccessResult at_s1e2_access(CPUARMState *env, const ARMCPRegInfo *ri)
 {
 if (arm_current_el(env) == 3 && !(env->cp15.scr_el3 & SCR_NS)) {
@@ -3066,6 +3077,17 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 4, .crn = 7, .crm = 8, .opc2 = 1,
   .access = PL2_W, .accessfn = at_s1e2_access,
   .type = ARM_CP_NO_RAW, .writefn = ats_write64 },
+/* The AArch32 ATS1H* operations are CONSTRAINED UNPREDICTABLE
+ * if EL2 is not implemented; we choose to UNDEF. Behaviour at EL3
+ * with SCR.NS == 0 outside Monitor mode is UNPREDICTABLE; we choose
+ * to behave as if SCR.NS was 1.
+ */
+{ .name = "ATS1HR", .cp = 15, .opc1 = 4, .crn = 7, .crm = 8, .opc2 = 0,
+  .access = PL2_W,
+  .writefn = ats1h_write, .type = ARM_CP_NO_RAW },
+{ .name = "ATS1HW", .cp = 15, .opc1 = 4, .crn = 7, .crm = 8, .opc2 = 1,
+  .access = PL2_W,
+  .writefn = ats1h_write, .type = ARM_CP_NO_RAW },
 { .name = "CNTHCTL_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 14, .crm = 1, .opc2 = 0,
   /* ARMv7 requires bit 0 and 1 to reset to 1. ARMv8 defines the
-- 
1.9.1

[Qemu-devel] [PULL 17/20] target-arm: Restrict AArch64 TLB flushes to the MMU indexes they must touch

[Peter Maydell]

Now we have the ability to flush the TLB only for specific MMU indexes,
update the AArch64 TLB maintenance instruction implementations to only
flush the parts of the TLB they need to, rather than doing full flushes.

We take the opportunity to remove some duplicate functions (the per-asid
tlb ops work like the non-per-asid ones because we don't support
flushing a TLB only by ASID) and to bring the function names in line
with the architectural TLBI operation names.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1439548879-1972-4-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 172 +++-
 1 file changed, 129 insertions(+), 43 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index becc6f8..c8d07d9 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2507,65 +2507,151 @@ static CPAccessResult aa64_cacheop_access(CPUARMState 
*env,
  * Page D4-1736 (DDI0487A.b)
  */
 
-static void tlbi_aa64_va_write(CPUARMState *env, const ARMCPRegInfo *ri,
-   uint64_t value)
+static void tlbi_aa64_vmalle1_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
 {
-/* Invalidate by VA (AArch64 version) */
 ARMCPU *cpu = arm_env_get_cpu(env);
-uint64_t pageaddr = sextract64(value << 12, 0, 56);
+CPUState *cs = CPU(cpu);
 
-tlb_flush_page(CPU(cpu), pageaddr);
+if (arm_is_secure_below_el3(env)) {
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S1SE1, ARMMMUIdx_S1SE0, -1);
+} else {
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S12NSE1, ARMMMUIdx_S12NSE0, -1);
+}
 }
 
-static void tlbi_aa64_vaa_write(CPUARMState *env, const ARMCPRegInfo *ri,
-uint64_t value)
+static void tlbi_aa64_vmalle1is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+  uint64_t value)
 {
-/* Invalidate by VA, all ASIDs (AArch64 version) */
-ARMCPU *cpu = arm_env_get_cpu(env);
-uint64_t pageaddr = sextract64(value << 12, 0, 56);
+bool sec = arm_is_secure_below_el3(env);
+CPUState *other_cs;
 
-tlb_flush_page(CPU(cpu), pageaddr);
+CPU_FOREACH(other_cs) {
+if (sec) {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S1SE1, ARMMMUIdx_S1SE0, 
-1);
+} else {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S12NSE1,
+ARMMMUIdx_S12NSE0, -1);
+}
+}
 }
 
-static void tlbi_aa64_asid_write(CPUARMState *env, const ARMCPRegInfo *ri,
- uint64_t value)
+static void tlbi_aa64_alle1_write(CPUARMState *env, const ARMCPRegInfo *ri,
+  uint64_t value)
 {
-/* Invalidate by ASID (AArch64 version) */
+/* Note that the 'ALL' scope must invalidate both stage 1 and
+ * stage 2 translations, whereas most other scopes only invalidate
+ * stage 1 translations.
+ */
 ARMCPU *cpu = arm_env_get_cpu(env);
-int asid = extract64(value, 48, 16);
-tlb_flush(CPU(cpu), asid == 0);
+CPUState *cs = CPU(cpu);
+
+if (arm_is_secure_below_el3(env)) {
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S1SE1, ARMMMUIdx_S1SE0, -1);
+} else {
+if (arm_feature(env, ARM_FEATURE_EL2)) {
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S12NSE1, ARMMMUIdx_S12NSE0,
+ARMMMUIdx_S2NS, -1);
+} else {
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S12NSE1, ARMMMUIdx_S12NSE0, -1);
+}
+}
 }
 
-static void tlbi_aa64_va_is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+static void tlbi_aa64_alle2_write(CPUARMState *env, const ARMCPRegInfo *ri,
   uint64_t value)
 {
+ARMCPU *cpu = arm_env_get_cpu(env);
+CPUState *cs = CPU(cpu);
+
+tlb_flush_by_mmuidx(cs, ARMMMUIdx_S1E2, -1);
+}
+
+static void tlbi_aa64_alle1is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+/* Note that the 'ALL' scope must invalidate both stage 1 and
+ * stage 2 translations, whereas most other scopes only invalidate
+ * stage 1 translations.
+ */
+bool sec = arm_is_secure_below_el3(env);
+bool has_el2 = arm_feature(env, ARM_FEATURE_EL2);
 CPUState *other_cs;
-uint64_t pageaddr = sextract64(value << 12, 0, 56);
 
 CPU_FOREACH(other_cs) {
-tlb_flush_page(other_cs, pageaddr);
+if (sec) {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S1SE1, ARMMMUIdx_S1SE0, 
-1);
+} else if (has_el2) {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S12NSE1,
+ARMMMUIdx_S12NSE0, ARMMMUIdx_S2NS, -1);
+} else {
+tlb_flush_by_mmuidx(other_cs, ARMMMUIdx_S12NSE1,
+ARMMMUIdx_S12NSE0, -1);
+}
 }
 }
 
-static void tlbi_aa64_vaa_is_write(CPUARMState *env, const ARMCPRegInfo *ri,
- 

[Qemu-devel] [PULL 01/20] xlnx-zynqmp: Connect the four OCM banks

[Peter Maydell]

From: Alistair Francis 

The Xilinx EP108 has four separate OCM banks which are located
adjacent to each other. This patch adds the four banks to
the ZynqMP SoC.

Signed-off-by: Alistair Francis 
Reviewed-by: Peter Crosthwaite 
Message-id: 
afa6ba31163a5d541a0bef4b0dc11f2597e0c495.1436813543.git.alistair.fran...@xilinx.com
Signed-off-by: Peter Maydell 
---
 hw/arm/xlnx-zynqmp.c | 15 +++
 include/hw/arm/xlnx-zynqmp.h |  6 ++
 2 files changed, 21 insertions(+)

diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 62ef4ceb..388baef 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -101,6 +101,21 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
 qemu_irq gic_spi[GIC_NUM_SPI_INTR];
 Error *err = NULL;
 
+/* Create the four OCM banks */
+for (i = 0; i < XLNX_ZYNQMP_NUM_OCM_BANKS; i++) {
+char *ocm_name = g_strdup_printf("zynqmp.ocm_ram_bank_%d", i);
+
+memory_region_init_ram(&s->ocm_ram[i], NULL, ocm_name,
+   XLNX_ZYNQMP_OCM_RAM_SIZE, &error_abort);
+vmstate_register_ram_global(&s->ocm_ram[i]);
+memory_region_add_subregion(get_system_memory(),
+XLNX_ZYNQMP_OCM_RAM_0_ADDRESS +
+i * XLNX_ZYNQMP_OCM_RAM_SIZE,
+&s->ocm_ram[i]);
+
+g_free(ocm_name);
+}
+
 qdev_prop_set_uint32(DEVICE(&s->gic), "num-irq", GIC_NUM_SPI_INTR + 32);
 qdev_prop_set_uint32(DEVICE(&s->gic), "revision", 2);
 qdev_prop_set_uint32(DEVICE(&s->gic), "num-cpu", XLNX_ZYNQMP_NUM_APU_CPUS);
diff --git a/include/hw/arm/xlnx-zynqmp.h b/include/hw/arm/xlnx-zynqmp.h
index c379632..6ccb57b 100644
--- a/include/hw/arm/xlnx-zynqmp.h
+++ b/include/hw/arm/xlnx-zynqmp.h
@@ -32,6 +32,10 @@
 #define XLNX_ZYNQMP_NUM_GEMS 4
 #define XLNX_ZYNQMP_NUM_UARTS 2
 
+#define XLNX_ZYNQMP_NUM_OCM_BANKS 4
+#define XLNX_ZYNQMP_OCM_RAM_0_ADDRESS 0xFFFC
+#define XLNX_ZYNQMP_OCM_RAM_SIZE 0x1
+
 #define XLNX_ZYNQMP_GIC_REGIONS 2
 
 /* ZynqMP maps the ARM GIC regions (GICC, GICD ...) at consecutive 64k offsets
@@ -52,6 +56,8 @@ typedef struct XlnxZynqMPState {
 ARMCPU rpu_cpu[XLNX_ZYNQMP_NUM_RPU_CPUS];
 GICState gic;
 MemoryRegion gic_mr[XLNX_ZYNQMP_GIC_REGIONS][XLNX_ZYNQMP_GIC_ALIASES];
+MemoryRegion ocm_ram[XLNX_ZYNQMP_NUM_OCM_BANKS];
+
 CadenceGEMState gem[XLNX_ZYNQMP_NUM_GEMS];
 CadenceUARTState uart[XLNX_ZYNQMP_NUM_UARTS];
 
-- 
1.9.1

[Qemu-devel] [PULL 02/20] MAINTAINERS: Update Xilinx Maintainership

[Peter Maydell]

From: Alistair Francis 

Peter C is leaving Xilinx, so update the maintainer list
to point to Alistair and Edgar from Xilinx and Peter's
personal email address.

Signed-off-by: Alistair Francis 
Reviewed-by: Peter Crosthwaite 
Message-id: 
54b4c070452bac05aa3a9c1d75899bc097fef831.1436486024.git.alistair.fran...@xilinx.com
Signed-off-by: Peter Maydell 
---
 MAINTAINERS | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a059d5d..d0268f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -349,7 +349,8 @@ S: Maintained
 F: hw/*/versatile*
 
 Xilinx Zynq
-M: Peter Crosthwaite 
+M: Alistair Francis 
+M: Peter Crosthwaite 
 S: Maintained
 F: hw/arm/xilinx_zynq.c
 F: hw/misc/zynq_slcr.c
@@ -405,7 +406,7 @@ S: Maintained
 F: hw/microblaze/petalogix_s3adsp1800_mmu.c
 
 petalogix_ml605
-M: Peter Crosthwaite 
+M: Edgar E. Iglesias 
 S: Maintained
 F: hw/microblaze/petalogix_ml605_mmu.c
 
@@ -685,10 +686,17 @@ S: Orphan
 F: hw/scsi/lsi53c895a.c
 
 SSI
-M: Peter Crosthwaite 
+M: Peter Crosthwaite 
 S: Maintained
 F: hw/ssi/*
 F: hw/block/m25p80.c
+X: hw/ssi/xilinx_*
+
+Xilinx SPI
+M: Alistair Francis 
+M: Peter Crosthwaite 
+S: Maintained
+F: hw/ssi/xilinx_*
 
 USB
 M: Gerd Hoffmann 
@@ -777,8 +785,9 @@ F: hw/scsi/megasas.c
 F: hw/scsi/mfi.h
 
 Xilinx EDK
-M: Peter Crosthwaite 
 M: Edgar E. Iglesias 
+M: Alistair Francis 
+M: Peter Crosthwaite 
 S: Maintained
 F: hw/*/xilinx_*
 F: include/hw/xilinx.h
@@ -880,7 +889,7 @@ F: include/hw/cpu/icc_bus.h
 F: hw/cpu/icc_bus.c
 
 Device Tree
-M: Peter Crosthwaite 
+M: Peter Crosthwaite 
 M: Alexander Graf 
 S: Maintained
 F: device_tree.[ch]
-- 
1.9.1

[Qemu-devel] [PULL 11/20] target-arm: Enable the AArch32 ATS12NSO ops

[Peter Maydell]

Apply the correct conditions in the ats_access() function for
the ATS12NSO* address translation operations:
 * succeed at EL2 or EL3
 * normal UNDEF trap from NS EL1
 * trap to EL3 from S EL1 (only possible if EL3 is AArch64)

(This change means they're now available in our EL3-supporting
CPUs when they would previously always UNDEF.)

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1437751263-21913-5-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 8603660..4b2fc090 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1719,12 +1719,17 @@ static void par_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 static CPAccessResult ats_access(CPUARMState *env, const ARMCPRegInfo *ri)
 {
 if (ri->opc2 & 4) {
-/* Other states are only available with TrustZone; in
- * a non-TZ implementation these registers don't exist
- * at all, which is an Uncategorized trap. This underdecoding
- * is safe because the reginfo is NO_RAW.
+/* The ATS12NSO* operations must trap to EL3 if executed in
+ * Secure EL1 (which can only happen if EL3 is AArch64).
+ * They are simply UNDEF if executed from NS EL1.
+ * They function normally from EL2 or EL3.
  */
-return CP_ACCESS_TRAP_UNCATEGORIZED;
+if (arm_current_el(env) == 1) {
+if (arm_is_secure_below_el3(env)) {
+return CP_ACCESS_TRAP_UNCATEGORIZED_EL3;
+}
+return CP_ACCESS_TRAP_UNCATEGORIZED;
+}
 }
 return CP_ACCESS_OK;
 }
@@ -1899,6 +1904,7 @@ static const ARMCPRegInfo vapa_cp_reginfo[] = {
  offsetoflow32(CPUARMState, cp15.par_ns) },
   .writefn = par_write },
 #ifndef CONFIG_USER_ONLY
+/* This underdecoding is safe because the reginfo is NO_RAW. */
 { .name = "ATS", .cp = 15, .crn = 7, .crm = 8, .opc1 = 0, .opc2 = CP_ANY,
   .access = PL1_W, .accessfn = ats_access,
   .writefn = ats_write, .type = ARM_CP_NO_RAW },
-- 
1.9.1

[Qemu-devel] [PULL 03/20] MAINTAINERS: Add ZynqMP to MAINTAINERS file

[Peter Maydell]

From: Alistair Francis 

Add the Xilinx ZynqMP SoC and EP108 machine to the maintainers
file.

Signed-off-by: Alistair Francis 
Reviewed-by: Peter Crosthwaite 
Message-id: 
fed078103a0b02cfb3adadbe8e80e4420d554505.1436486024.git.alistair.fran...@xilinx.com
Signed-off-by: Peter Maydell 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d0268f9..08f356a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -357,6 +357,14 @@ F: hw/misc/zynq_slcr.c
 F: hw/*/cadence_*
 F: hw/ssi/xilinx_spips.c
 
+Xilinx ZynqMP
+M: Alistair Francis 
+M: Peter Crosthwaite 
+S: Maintained
+F: hw/arm/xlnx-zynqmp.c
+F: hw/arm/xlnx-ep108.c
+F: include/hw/arm/xlnx-zynqmp.h
+
 ARM ACPI Subsystem
 M: Shannon Zhao 
 M: Shannon Zhao 
-- 
1.9.1

Re: [Qemu-devel] [PATCH v6 3/8] scripts: Submit changes while updating linux headers

[Peter Maydell]

On 25 August 2015 at 00:58, Gavin Shan  wrote:
> On Mon, Aug 24, 2015 at 03:08:33PM +0100, Peter Maydell wrote:
>>On 24 August 2015 at 13:03, Gavin Shan  wrote:
>>> +cd $to
>>> +name=$(git config --get user.name)
>>> +email=$(git config --get user.email)
>>> +git commit -a -m "$subject" -m "$message" -m "Signed-off-by: $name 
>>> <$email>"
>>
>>Is git commit's --signoff option not present on all the git
>>versions we care about?

> We needn't care about if user.name and user.email are existing or not.
> If they're invalid, the commit log needs to be fixed manually. Or just
> to give explicit message like below to remind users to fix it? Anyway,
> the commit log isn't complete without correct name/email in SOB if
> I'm correct.
>
> name=$(git config --get user.name)
> email=$(git config --get user.email)
> if ! [ "$name" ]; then
> name="FIXME"
> fi
> if ! [ '$(echo "$email" | grep -v -e '@' > /dev/null)' ]; then
> email="FIXME"
> fi

My point is that you appear to be manually reimplementing
the built in git commit function for adding the SOB line,
and you haven't explained why you need to do that.

thanks
-- PMM

[Qemu-devel] [PULL 16/20] target-arm: Move TLBI ALLE1/ALLE1IS definitions into numeric order

[Peter Maydell]

Move the two regdefs for TLBI ALLE1 and TLBI ALLE1IS down so that the
whole set of AArch64 TLBI regdefs is arranged in numeric order.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1439548879-1972-3-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 6c55cc4..becc6f8 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2701,14 +2701,6 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 2,
   .access = PL1_W, .type = ARM_CP_NOP },
 /* TLBI operations */
-{ .name = "TLBI_ALLE1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 4,
-  .access = PL2_W, .type = ARM_CP_NO_RAW,
-  .writefn = tlbiall_write },
-{ .name = "TLBI_ALLE1IS", .state = ARM_CP_STATE_AA64,
-  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 4,
-  .access = PL2_W, .type = ARM_CP_NO_RAW,
-  .writefn = tlbiall_is_write },
 { .name = "TLBI_VMALLE1IS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 0,
   .access = PL1_W, .type = ARM_CP_NO_RAW,
@@ -2757,6 +2749,14 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 7, .opc2 = 7,
   .access = PL1_W, .type = ARM_CP_NO_RAW,
   .writefn = tlbi_aa64_vaa_write },
+{ .name = "TLBI_ALLE1IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbiall_is_write },
+{ .name = "TLBI_ALLE1", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbiall_write },
 #ifndef CONFIG_USER_ONLY
 /* 64 bit address translation operations */
 { .name = "AT_S1E1R", .state = ARM_CP_STATE_AA64,
-- 
1.9.1

[Qemu-devel] [PULL 13/20] smbios: add smbios 3.0 support

[Peter Maydell]

From: Wei Huang 

This patch adds support for SMBIOS 3.0 entry point. When caller invokes
smbios_set_defaults(), it can specify entry point as 2.1 or 3.0. Then
smbios_get_tables() will return the entry point table in right format.

Acked-by: Gabriel Somlo 
Tested-by: Gabriel Somlo 
Tested-by: Leif Lindholm 
Signed-off-by: Wei Huang 
Reviewed-by: Laszlo Ersek 
Message-id: 1439485767-20259-2-git-send-email-...@redhat.com
Signed-off-by: Peter Maydell 
---
 hw/i386/pc_piix.c  |  3 +-
 hw/i386/pc_q35.c   |  3 +-
 hw/smbios/smbios.c | 84 +-
 include/hw/smbios/smbios.h | 51 
 4 files changed, 102 insertions(+), 39 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9558467..b82921d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -173,7 +173,8 @@ static void pc_init1(MachineState *machine)
 MachineClass *mc = MACHINE_GET_CLASS(machine);
 /* These values are guest ABI, do not change */
 smbios_set_defaults("QEMU", "Standard PC (i440FX + PIIX, 1996)",
-mc->name, smbios_legacy_mode, smbios_uuid_encoded);
+mc->name, smbios_legacy_mode, smbios_uuid_encoded,
+SMBIOS_ENTRY_POINT_21);
 }
 
 /* allocate ram and load rom/bios */
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c07d65b..7217cbf 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -165,7 +165,8 @@ static void pc_q35_init(MachineState *machine)
 if (smbios_defaults) {
 /* These values are guest ABI, do not change */
 smbios_set_defaults("QEMU", "Standard PC (Q35 + ICH9, 2009)",
-mc->name, smbios_legacy_mode, smbios_uuid_encoded);
+mc->name, smbios_legacy_mode, smbios_uuid_encoded,
+SMBIOS_ENTRY_POINT_21);
 }
 
 /* allocate ram and load rom/bios */
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index efdbb5d..b81a1d3 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -55,7 +55,9 @@ static uint8_t *smbios_tables;
 static size_t smbios_tables_len;
 static unsigned smbios_table_max;
 static unsigned smbios_table_cnt;
-static struct smbios_entry_point ep;
+static SmbiosEntryPointType smbios_ep_type = SMBIOS_ENTRY_POINT_21;
+
+static SmbiosEntryPoint ep;
 
 static int smbios_type4_count = 0;
 static bool smbios_immutable;
@@ -771,11 +773,12 @@ void smbios_set_cpuid(uint32_t version, uint32_t features)
 
 void smbios_set_defaults(const char *manufacturer, const char *product,
  const char *version, bool legacy_mode,
- bool uuid_encoded)
+ bool uuid_encoded, SmbiosEntryPointType ep_type)
 {
 smbios_have_defaults = true;
 smbios_legacy = legacy_mode;
 smbios_uuid_encoded = uuid_encoded;
+smbios_ep_type = ep_type;
 
 /* drop unwanted version of command-line file blob(s) */
 if (smbios_legacy) {
@@ -808,26 +811,53 @@ void smbios_set_defaults(const char *manufacturer, const 
char *product,
 
 static void smbios_entry_point_setup(void)
 {
-memcpy(ep.anchor_string, "_SM_", 4);
-memcpy(ep.intermediate_anchor_string, "_DMI_", 5);
-ep.length = sizeof(struct smbios_entry_point);
-ep.entry_point_revision = 0; /* formatted_area reserved, per spec v2.1+ */
-memset(ep.formatted_area, 0, 5);
-
-/* compliant with smbios spec v2.8 */
-ep.smbios_major_version = 2;
-ep.smbios_minor_version = 8;
-ep.smbios_bcd_revision = 0x28;
-
-/* set during table construction, but BIOS may override: */
-ep.structure_table_length = cpu_to_le16(smbios_tables_len);
-ep.max_structure_size = cpu_to_le16(smbios_table_max);
-ep.number_of_structures = cpu_to_le16(smbios_table_cnt);
-
-/* BIOS must recalculate: */
-ep.checksum = 0;
-ep.intermediate_checksum = 0;
-ep.structure_table_address = cpu_to_le32(0);
+switch (smbios_ep_type) {
+case SMBIOS_ENTRY_POINT_21:
+memcpy(ep.ep21.anchor_string, "_SM_", 4);
+memcpy(ep.ep21.intermediate_anchor_string, "_DMI_", 5);
+ep.ep21.length = sizeof(struct smbios_21_entry_point);
+ep.ep21.entry_point_revision = 0; /* formatted_area reserved */
+memset(ep.ep21.formatted_area, 0, 5);
+
+/* compliant with smbios spec v2.8 */
+ep.ep21.smbios_major_version = 2;
+ep.ep21.smbios_minor_version = 8;
+ep.ep21.smbios_bcd_revision = 0x28;
+
+/* set during table construction, but BIOS may override: */
+ep.ep21.structure_table_length = cpu_to_le16(smbios_tables_len);
+ep.ep21.max_structure_size = cpu_to_le16(smbios_table_max);
+ep.ep21.number_of_structures = cpu_to_le16(smbios_table_cnt);
+
+/* BIOS must recalculate */
+ep.ep21.checksum = 0;
+ep.ep21.intermediate_checksum = 0;
+ep.ep21.structure_table_address = cpu_t

[Qemu-devel] [PULL 14/20] smbios: implement smbios support for mach-virt

[Peter Maydell]

From: Wei Huang 

This patch generates smbios tables for ARM mach-virt. Also add
CONFIG_SMBIOS=y for ARM default config.

Acked-by: Gabriel Somlo 
Tested-by: Gabriel Somlo 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Shannon Zhao 
Tested-by: Leif Lindholm 
Signed-off-by: Wei Huang 
Message-id: 1439485767-20259-3-git-send-email-...@redhat.com
[PMM: Added missing braces on if ()]
Signed-off-by: Peter Maydell 
---
 default-configs/arm-softmmu.mak |  1 +
 hw/arm/virt.c   | 26 ++
 qemu-options.hx |  2 +-
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 74f1db3..99b41e9 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -102,3 +102,4 @@ CONFIG_XIO3130=y
 CONFIG_IOH3420=y
 CONFIG_I82801B11=y
 CONFIG_ACPI=y
+CONFIG_SMBIOS=y
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index d5a8417..bbd061b 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -50,6 +50,7 @@
 #include "hw/arm/fdt.h"
 #include "hw/intc/arm_gic_common.h"
 #include "kvm_arm.h"
+#include "hw/smbios/smbios.h"
 
 /* Number of external interrupt lines to configure the GIC with */
 #define NUM_IRQS 256
@@ -788,12 +789,37 @@ static void *machvirt_dtb(const struct arm_boot_info 
*binfo, int *fdt_size)
 return board->fdt;
 }
 
+static void virt_build_smbios(VirtGuestInfo *guest_info)
+{
+FWCfgState *fw_cfg = guest_info->fw_cfg;
+uint8_t *smbios_tables, *smbios_anchor;
+size_t smbios_tables_len, smbios_anchor_len;
+
+if (!fw_cfg) {
+return;
+}
+
+smbios_set_defaults("QEMU", "QEMU Virtual Machine",
+"1.0", false, true, SMBIOS_ENTRY_POINT_30);
+
+smbios_get_tables(NULL, 0, &smbios_tables, &smbios_tables_len,
+  &smbios_anchor, &smbios_anchor_len);
+
+if (smbios_anchor) {
+fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-tables",
+smbios_tables, smbios_tables_len);
+fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-anchor",
+smbios_anchor, smbios_anchor_len);
+}
+}
+
 static
 void virt_guest_info_machine_done(Notifier *notifier, void *data)
 {
 VirtGuestInfoState *guest_info_state = container_of(notifier,
   VirtGuestInfoState, 
machine_done);
 virt_acpi_setup(&guest_info_state->info);
+virt_build_smbios(&guest_info_state->info);
 }
 
 static void machvirt_init(MachineState *machine)
diff --git a/qemu-options.hx b/qemu-options.hx
index 77f5853..efce775 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1412,7 +1412,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
 "-smbios 
type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n"
 "   [,asset=str][,part=str][,speed=%d]\n"
 "specify SMBIOS type 17 fields\n",
-QEMU_ARCH_I386)
+QEMU_ARCH_I386 | QEMU_ARCH_ARM)
 STEXI
 @item -smbios file=@var{binary}
 @findex -smbios
-- 
1.9.1

Re: [Qemu-devel] [PATCH v2 07/18] nvdimm: reserve address range for NVDIMM

[Stefan Hajnoczi]

On Fri, Aug 14, 2015 at 10:52:00PM +0800, Xiao Guangrong wrote:
> diff --git a/hw/mem/nvdimm/pc-nvdimm.c b/hw/mem/nvdimm/pc-nvdimm.c
> index a53d235..7a270a8 100644
> --- a/hw/mem/nvdimm/pc-nvdimm.c
> +++ b/hw/mem/nvdimm/pc-nvdimm.c
> @@ -24,6 +24,19 @@
>  
>  #include "hw/mem/pc-nvdimm.h"
>  
> +#define PAGE_SIZE  (1UL << 12)

This macro name is likely to collide with system headers or other code.

Could you use the existing TARGET_PAGE_SIZE constant instead?

[Qemu-devel] [PULL 08/20] target-arm: there is no TTBR1 for 32-bit EL2 stage 1 translations

[Peter Maydell]

For EL2 stage 1 translations, there is no TTBR1. We were already
handling this for 64-bit EL2; add the code to take the 'no TTBR1'
code path for 64-bit EL2 as well.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1437751263-21913-2-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 97ca86a..86d0baf 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -5999,6 +5999,11 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 if (el > 1) {
 ttbr1_valid = false;
 }
+} else {
+/* There is no TTBR1 for EL2 */
+if (el == 2) {
+ttbr1_valid = false;
+}
 }
 
 /* Determine whether this address is in the region controlled by
-- 
1.9.1

[Qemu-devel] [PULL 20/20] target-arm: Implement AArch64 TLBI operations on IPAs

[Peter Maydell]

Implement the AArch64 TLBI operations which take an intermediate
physical address and invalidate stage 2 translations.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1439548879-1972-7-git-send-email-peter.mayd...@linaro.org
---
 target-arm/helper.c | 55 +
 1 file changed, 55 insertions(+)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 00ecda9..7df1f06 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2709,6 +2709,45 @@ static void tlbi_aa64_vae3is_write(CPUARMState *env, 
const ARMCPRegInfo *ri,
 }
 }
 
+static void tlbi_aa64_ipas2e1_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+/* Invalidate by IPA. This has to invalidate any structures that
+ * contain only stage 2 translation information, but does not need
+ * to apply to structures that contain combined stage 1 and stage 2
+ * translation information.
+ * This must NOP if EL2 isn't implemented or SCR_EL3.NS is zero.
+ */
+ARMCPU *cpu = arm_env_get_cpu(env);
+CPUState *cs = CPU(cpu);
+uint64_t pageaddr;
+
+if (!arm_feature(env, ARM_FEATURE_EL2) || !(env->cp15.scr_el3 & SCR_NS)) {
+return;
+}
+
+pageaddr = sextract64(value << 12, 0, 48);
+
+tlb_flush_page_by_mmuidx(cs, pageaddr, ARMMMUIdx_S2NS, -1);
+}
+
+static void tlbi_aa64_ipas2e1is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+  uint64_t value)
+{
+CPUState *other_cs;
+uint64_t pageaddr;
+
+if (!arm_feature(env, ARM_FEATURE_EL2) || !(env->cp15.scr_el3 & SCR_NS)) {
+return;
+}
+
+pageaddr = sextract64(value << 12, 0, 48);
+
+CPU_FOREACH(other_cs) {
+tlb_flush_page_by_mmuidx(other_cs, pageaddr, ARMMMUIdx_S2NS, -1);
+}
+}
+
 static CPAccessResult aa64_zva_access(CPUARMState *env, const ARMCPRegInfo *ri)
 {
 /* We don't implement EL2, so the only control on DC ZVA is the
@@ -2889,6 +2928,14 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 7, .opc2 = 7,
   .access = PL1_W, .type = ARM_CP_NO_RAW,
   .writefn = tlbi_aa64_vae1_write },
+{ .name = "TLBI_IPAS2E1IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 0, .opc2 = 1,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_ipas2e1is_write },
+{ .name = "TLBI_IPAS2LE1IS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 0, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_ipas2e1is_write },
 { .name = "TLBI_ALLE1IS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 4,
   .access = PL2_W, .type = ARM_CP_NO_RAW,
@@ -2897,6 +2944,14 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 6,
   .access = PL2_W, .type = ARM_CP_NO_RAW,
   .writefn = tlbi_aa64_alle1is_write },
+{ .name = "TLBI_IPAS2E1", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 1,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_ipas2e1_write },
+{ .name = "TLBI_IPAS2LE1", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_ipas2e1_write },
 { .name = "TLBI_ALLE1", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 4,
   .access = PL2_W, .type = ARM_CP_NO_RAW,
-- 
1.9.1

Re: [Qemu-devel] Should we auto-generate IDs? (was: [PATCH] qdev-monitor.c: Add device id generation)

[Programmingkid]

On Aug 25, 2015, at 8:38 AM, Markus Armbruster wrote:

> You're proposing to revise a qdev design decision, namely the purpose of
> IDs.  This has been discussed before, and IDs remained unchanged.
> Perhaps it's time to revisit this issue.  Cc'ing a few more people.
> 
> Relevant prior threads:
> * [PATCH] qdev: Reject duplicate and anti-social device IDs
>  http://thread.gmane.org/gmane.comp.emulators.qemu/71230/focus=72272
> * [PATCH 6/6] qdev: Generate IDs for anonymous devices
>  http://thread.gmane.org/gmane.comp.emulators.qemu/114853/focus=114858
> * [PATCH] qdev: Assign a default device ID when none is provided.
>  http://thread.gmane.org/gmane.comp.emulators.qemu/249702
> * IDs in QOM (was: [PATCH] util: Emancipate id_wellformed() from QemuOpt
>  http://thread.gmane.org/gmane.comp.emulators.qemu/299945/focus=300381
> 
> Probably more I can't remember anymore :)
> 
> Programmingkid  writes:
> 
>> Add device ID generation to each device if an ID isn't given.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> This patch can be tested by adding adding usb devices using the monitor.
>> Start QEMU with the -usb option. Then go to the monitor and type
>> "device_add usb-mouse". The ID of the device will be set to a number.
>> Since QEMU will not allow an user to add a device with an ID set to a
>> number, there is no chance for ID collisions. 
> 
> The second sentence should really be part of your commit message.
> The first sentence wouldn't hurt, either.
Ok.

> Another useful addition would be *why* you want generated IDs.  I
> believe you do because you need them for device_del.
Sounds like a good idea.

> 
> In prior discussion, we always concluded that device_del should accept
> QOM paths.  It still doesn't.
> 
> Many things in QEMU have IDs.  They all work pretty much the same:
> 
> 1. The ID is set by the user.  If the user doesn't, there is none.
> 
>   Exception: a few old interfaces set well-known IDs.  If the user uses
>   these interfaces, he needs to take care that his own IDs don't clash.
> 
>   Example: drive_add picks an ID based on interface type, media type,
>   bus and unit number.  blockdev_add doesn't.  Instead, it requires the
>   user to pick one.
> 
> 2. The ID must be well-formed.
> 
>   Exception: inconsistently enforced for QOM, see last thread quoted
>   above.

This is a definite possibility. All USB devices could be given a id like this:
USB. All block devices could be HD. 

> 
> 3. If the user may need to address the thing, either the ID must be
>   mandatory, or there has to be another way to address it.
> 
>   Example: netdev-add requires ID.  Rationale: the only way to put it
>   to use is referencing it from a device, and that requires an ID.
> 
>   Example: device_add doesn't require ID.  If you don't specify one,
>   you can't device_del it.  Annoying trap for the unwary.  There are
>   *two* other ways to address it: qdev path and QOM path.  qdev path is
>   basically too botched to be usable.  QOM path should do just fine,
>   but device_del doesn't accept it.  It could.
After looking up what a QOM path looks like 
(/i440fx/slot[1.0]/bus/piix3/i8042/aux)
I'm thinking that would not be a good idea. It is an awful
lot to type. It isn't as user friendly as using something simple like USB1 or 
HD3. 

> We could revise rule 1 to always generate IDs, in a way that can't clash
> with the user's IDs (impossible unless rule 2 is actually observed).

I think if we follow the rule that only QEMU can give an ID that is only a 
number,
we should be fine. That seems to be the rule now. 

> Rule 3 then becomes moot.
> 
> Whatever we do, I want it done consistently.  I don't want different
> rules for different kinds of IDs.
Agreed. Maybe we should include an easy and consistent way of finding out these 
ID's.

Wow, didn't think this patch to fix USB device removal would have such 
consequences. 

[Qemu-devel] [PULL 15/20] cputlb: Add functions for flushing TLB for a single MMU index

[Peter Maydell]

Guest CPU TLB maintenance operations may be sufficiently
specialized to only need to flush TLB entries corresponding
to a particular MMU index. Implement cputlb functions for
this, to avoid the inefficiency of flushing TLB entries
which we don't need to.

Signed-off-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
Message-id: 1439548879-1972-2-git-send-email-peter.mayd...@linaro.org
---
 cputlb.c| 97 +
 include/exec/exec-all.h | 47 
 2 files changed, 144 insertions(+)

diff --git a/cputlb.c b/cputlb.c
index a506086..4bc6c24 100644
--- a/cputlb.c
+++ b/cputlb.c
@@ -69,6 +69,47 @@ void tlb_flush(CPUState *cpu, int flush_global)
 tlb_flush_count++;
 }
 
+static inline void v_tlb_flush_by_mmuidx(CPUState *cpu, va_list argp)
+{
+CPUArchState *env = cpu->env_ptr;
+
+#if defined(DEBUG_TLB)
+printf("tlb_flush_by_mmuidx:");
+#endif
+/* must reset current TB so that interrupts cannot modify the
+   links while we are modifying them */
+cpu->current_tb = NULL;
+
+for (;;) {
+int mmu_idx = va_arg(argp, int);
+
+if (mmu_idx < 0) {
+break;
+}
+
+#if defined(DEBUG_TLB)
+printf(" %d", mmu_idx);
+#endif
+
+memset(env->tlb_table[mmu_idx], -1, sizeof(env->tlb_table[0]));
+memset(env->tlb_v_table[mmu_idx], -1, sizeof(env->tlb_v_table[0]));
+}
+
+#if defined(DEBUG_TLB)
+printf("\n");
+#endif
+
+memset(cpu->tb_jmp_cache, 0, sizeof(cpu->tb_jmp_cache));
+}
+
+void tlb_flush_by_mmuidx(CPUState *cpu, ...)
+{
+va_list argp;
+va_start(argp, cpu);
+v_tlb_flush_by_mmuidx(cpu, argp);
+va_end(argp);
+}
+
 static inline void tlb_flush_entry(CPUTLBEntry *tlb_entry, target_ulong addr)
 {
 if (addr == (tlb_entry->addr_read &
@@ -121,6 +162,62 @@ void tlb_flush_page(CPUState *cpu, target_ulong addr)
 tb_flush_jmp_cache(cpu, addr);
 }
 
+void tlb_flush_page_by_mmuidx(CPUState *cpu, target_ulong addr, ...)
+{
+CPUArchState *env = cpu->env_ptr;
+int i, k;
+va_list argp;
+
+va_start(argp, addr);
+
+#if defined(DEBUG_TLB)
+printf("tlb_flush_page_by_mmu_idx: " TARGET_FMT_lx, addr);
+#endif
+/* Check if we need to flush due to large pages.  */
+if ((addr & env->tlb_flush_mask) == env->tlb_flush_addr) {
+#if defined(DEBUG_TLB)
+printf(" forced full flush ("
+   TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
+   env->tlb_flush_addr, env->tlb_flush_mask);
+#endif
+v_tlb_flush_by_mmuidx(cpu, argp);
+va_end(argp);
+return;
+}
+/* must reset current TB so that interrupts cannot modify the
+   links while we are modifying them */
+cpu->current_tb = NULL;
+
+addr &= TARGET_PAGE_MASK;
+i = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
+
+for (;;) {
+int mmu_idx = va_arg(argp, int);
+
+if (mmu_idx < 0) {
+break;
+}
+
+#if defined(DEBUG_TLB)
+printf(" %d", mmu_idx);
+#endif
+
+tlb_flush_entry(&env->tlb_table[mmu_idx][i], addr);
+
+/* check whether there are vltb entries that need to be flushed */
+for (k = 0; k < CPU_VTLB_SIZE; k++) {
+tlb_flush_entry(&env->tlb_v_table[mmu_idx][k], addr);
+}
+}
+va_end(argp);
+
+#if defined(DEBUG_TLB)
+printf("\n");
+#endif
+
+tb_flush_jmp_cache(cpu, addr);
+}
+
 /* update the TLBs so that writes to code in the virtual page 'addr'
can be detected */
 void tlb_protect_code(ram_addr_t ram_addr)
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 29775c0..fbc6dcb 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -96,8 +96,46 @@ bool qemu_in_vcpu_thread(void);
 void cpu_reload_memory_map(CPUState *cpu);
 void tcg_cpu_address_space_init(CPUState *cpu, AddressSpace *as);
 /* cputlb.c */
+/**
+ * tlb_flush_page:
+ * @cpu: CPU whose TLB should be flushed
+ * @addr: virtual address of page to be flushed
+ *
+ * Flush one page from the TLB of the specified CPU, for all
+ * MMU indexes.
+ */
 void tlb_flush_page(CPUState *cpu, target_ulong addr);
+/**
+ * tlb_flush:
+ * @cpu: CPU whose TLB should be flushed
+ * @flush_global: ignored
+ *
+ * Flush the entire TLB for the specified CPU.
+ * The flush_global flag is in theory an indicator of whether the whole
+ * TLB should be flushed, or only those entries not marked global.
+ * In practice QEMU does not implement any global/not global flag for
+ * TLB entries, and the argument is ignored.
+ */
 void tlb_flush(CPUState *cpu, int flush_global);
+/**
+ * tlb_flush_page_by_mmuidx:
+ * @cpu: CPU whose TLB should be flushed
+ * @addr: virtual address of page to be flushed
+ * @...: list of MMU indexes to flush, terminated by a negative value
+ *
+ * Flush one page from the TLB of the specified CPU, for the specified
+ * MMU indexes.
+ */
+void tlb_flush_page_by_mmuidx(CPUState *cpu, target_ulong addr, ...);
+/**
+ * tlb_flush_by_mmuidx:

Re: [Qemu-devel] [ARM SMBIOS V4 PATCH 1/2] smbios: add smbios 3.0 support

[Peter Maydell]

On 13 August 2015 at 18:09, Wei Huang  wrote:
> This patch adds support for SMBIOS 3.0 entry point. When caller invokes
> smbios_set_defaults(), it can specify entry point as 2.1 or 3.0. Then
> smbios_get_tables() will return the entry point table in right format.


> -/* SMBIOS entry point (anchor).
> - * BIOS must place this at a 16-bit-aligned address between 0xf and 
> 0xf.
> +/* SMBIOS entry point
> + * BIOS must place this at a 16-bit-aligned address between 0xf
> + * and 0xf.
>   */
> -struct smbios_entry_point {
> +struct smbios_21_entry_point {
>  uint8_t anchor_string[4];
>  uint8_t checksum;
>  uint8_t length;
> @@ -58,6 +52,25 @@ struct smbios_entry_point {
>  uint8_t smbios_bcd_revision;
>  } QEMU_PACKED;

This breaks 'make check' for x86, because tests/bios-tables-test.c
still uses 'struct smbios_entry_point' and no longer compiles
if this patch is applied.

I'm removing these two patches from my target-arm queue.

thanks
-- PMM

[Qemu-devel] [PULL 00/18] target-arm queue

[Peter Maydell]

Here's the ARM queue. I know I have a pile of backed-up code
review to do, but I wanted to get these patches out rather
than accumulating a fifty-patch queue...

This is v2: only change is to drop the two smbios patches.

thanks
-- PMM


The following changes since commit 34a4450434f1a5daee06fca223afcbb9c8f1ee24:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20150824' into 
staging (2015-08-25 13:34:57 +0100)

are available in the git repository at:


  git://git.linaro.org/people/pmaydell/qemu-arm.git 
tags/pull-target-arm-20150825-1

for you to fetch changes up to cea66e91212164e02ad1d245c2371f7e8eb59e7f:

  target-arm: Implement AArch64 TLBI operations on IPAs (2015-08-25 16:18:33 
+0100)


target-arm queue:
 * add missing EL2/EL3 TLBI operations
 * add missing EL2/EL3 ATS operations
 * add missing EL2/EL3 registers
 * update Xilinx MAINTAINERS info
 * Xilinx: connect the four OCM banks


Alistair Francis (3):
  xlnx-zynqmp: Connect the four OCM banks
  MAINTAINERS: Update Xilinx Maintainership
  MAINTAINERS: Add ZynqMP to MAINTAINERS file

Peter Maydell (15):
  target-arm: Add missing MAIR_EL3 and TPIDR_EL3 registers
  target-arm: Implement missing AMAIR registers
  target-arm: Implement missing AFSR registers
  target-arm: Implement missing ACTLR registers
  target-arm: there is no TTBR1 for 32-bit EL2 stage 1 translations
  target-arm: Wire up AArch64 EL2 and EL3 address translation ops
  target-arm: Add CP_ACCESS_TRAP_UNCATEGORIZED_EL2, 3
  target-arm: Enable the AArch32 ATS12NSO ops
  target-arm: Implement AArch32 ATS1H* operations
  cputlb: Add functions for flushing TLB for a single MMU index
  target-arm: Move TLBI ALLE1/ALLE1IS definitions into numeric order
  target-arm: Restrict AArch64 TLB flushes to the MMU indexes they must 
touch
  target-arm: Implement missing EL2 TLBI operations
  target-arm: Implement missing EL3 TLB invalidate operations
  target-arm: Implement AArch64 TLBI operations on IPAs

 MAINTAINERS  |  27 ++-
 cputlb.c |  97 +
 hw/arm/xlnx-zynqmp.c |  15 ++
 include/exec/exec-all.h  |  47 +
 include/hw/arm/xlnx-zynqmp.h |   6 +
 target-arm/cpu.h |   3 +
 target-arm/helper.c  | 489 ++-
 target-arm/op_helper.c   |   8 +
 8 files changed, 629 insertions(+), 63 deletions(-)

Re: [Qemu-devel] [PATCH] qdev-monitor.c: Add device id generation

[Programmingkid]

On Aug 25, 2015, at 8:42 AM, Markus Armbruster wrote:

> My other reply is about design issues.  This one is about the actual
> code.  Until we get rough consensus on the former, the latter doesn't
> really matter, but here goes anyway.
> 
> Eric Blake  writes:
> 
>> On 08/24/2015 12:53 PM, Programmingkid wrote:
>>> Add device ID generation to each device if an ID isn't given.
>>> 
>>> Signed-off-by: John Arbuckle 
>>> 
>>> ---
>>> This patch can be tested by adding adding usb devices using the monitor.
>>> Start QEMU with the -usb option. Then go to the monitor and type
>>> "device_add usb-mouse". The ID of the device will be set to a number.
>>> Since QEMU will not allow an user to add a device with an ID set to a
>>> number, there is no chance for ID collisions. 
>>> 
>>> qdev-monitor.c |   24 ++--
>>> 1 files changed, 18 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/qdev-monitor.c b/qdev-monitor.c
>>> index f9e2d62..98267c4 100644
>>> --- a/qdev-monitor.c
>>> +++ b/qdev-monitor.c
>>> @@ -26,6 +26,10 @@
>>> #include "qapi/qmp/qerror.h"
>>> #include "qemu/config-file.h"
>>> #include "qemu/error-report.h"
>>> +#include 
>>> +
>>> +/* USB's max number of devices is 127. This number is 3 digits long. */
>>> +#define MAX_NUM_DIGITS_FOR_USB_ID 3
> 
> This limit makes no sense to me. 

The limit is used to decide how many characters the device_id string is going 
to have. 
Three digits would be 0 to 999 device ID's would be supported. I can't imagine
anyone spending the time to add that many devices.

> 
>>> 
>>> /*
>>>  * Aliases were a bad idea from the start.  Let's keep them
>>> @@ -574,17 +578,25 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
>>> **errp)
>>> id = qemu_opts_id(opts);
>>> if (id) {
>>> dev->id = id;
>>> +} else { /* create an id for a device if none is provided */
>>> +static int device_id_count;
>>> +
>>> +/* Add one for '\0' character */
>>> +char *device_id = (char *) malloc(sizeof(char) *
>>> +MAX_NUM_DIGITS_FOR_USB_ID + 1);
>>> +sprintf(device_id, "%d", device_id_count++);
>> 
>> g_strdup_printf() is a lot nicer about avoiding the risk of arbitrary
>> overflow...
>>> +dev->id = (const char *) device_id;
>>> +
>>> +/* if device_id_count >= 10^MAX_NUM_DIGITS_FOR_USB_ID */
>>> +if (device_id_count >= pow(10, MAX_NUM_DIGITS_FOR_USB_ID)) {
>>> +printf("Warning: Maximum number of device ID's 
>>> generated!\n\a");
>>> +printf("Time for you to make your own device ID's.\n");
>> 
>> besides, printf() is probably the wrong way to do error reporting, and
>> we don't use \a BEL sequences anywhere else in qemu code.
>> 
>>> +}
>>> }
> 
> When device_id_count reaches the limit, you warn.  Next time around, you
> overrun the buffer.  Not good.

I could change it so next time around, only the warning is displayed. 

> 
> Eric is right, g_strdup_printf() is easier and safer.

If you say so. I have never heard of it myself.

> 
> I'd make the count 64 bits, so wrapping becomes vanishingly unlikely.

That big of a number seems unreasonably big. I can see the advantage of
using such a big number. Can QEMU even handle that many devices?

> 
>>> 
>>> if (dev->id) {
>> 
>> This if would now be a dead check if your patch is applied.
>> 
>>> object_property_add_child(qdev_get_peripheral(), dev->id,
>>>   OBJECT(dev), NULL);
>>> -} else {
>>> -static int anon_count;
>>> -gchar *name = g_strdup_printf("device[%d]", anon_count++);
>>> -object_property_add_child(qdev_get_peripheral_anon(), name,
>>> -  OBJECT(dev), NULL);
>>> -g_free(name);
>>> }
>> 
>> It looks like your goal was to move this code earlier, but you changed
>> enough aspects of it that I'm not sure what the right fix should be.
> 
> Drop the conditional, it's both useless and confusing after your patch.
Ok.

I'm thinking I will wait until the other maintainers and whoever else is 
interested,
say how they feel on the subject of generated ID's for devices before making
a new patch.

Re: [Qemu-devel] [ARM SMBIOS V4 PATCH 1/2] smbios: add smbios 3.0 support

[Leif Lindholm]

On Tue, Aug 25, 2015 at 04:17:42PM +0100, Peter Maydell wrote:
> On 13 August 2015 at 18:09, Wei Huang  wrote:
> > This patch adds support for SMBIOS 3.0 entry point. When caller invokes
> > smbios_set_defaults(), it can specify entry point as 2.1 or 3.0. Then
> > smbios_get_tables() will return the entry point table in right format.
> 
> 
> > -/* SMBIOS entry point (anchor).
> > - * BIOS must place this at a 16-bit-aligned address between 0xf and 
> > 0xf.
> > +/* SMBIOS entry point
> > + * BIOS must place this at a 16-bit-aligned address between 0xf
> > + * and 0xf.
> >   */
> > -struct smbios_entry_point {
> > +struct smbios_21_entry_point {
> >  uint8_t anchor_string[4];
> >  uint8_t checksum;
> >  uint8_t length;
> > @@ -58,6 +52,25 @@ struct smbios_entry_point {
> >  uint8_t smbios_bcd_revision;
> >  } QEMU_PACKED;
> 
> This breaks 'make check' for x86, because tests/bios-tables-test.c
> still uses 'struct smbios_entry_point' and no longer compiles
> if this patch is applied.

Urgh.

> I'm removing these two patches from my target-arm queue.

Fair enough.

Wei - is there actually any particular point in renaming this
structure? In all versions of the specification before 3.0, this was
only known as the "smbios entry point". Only with the introduction of
SMBIOS 3.0 this was retrospectively renamed.

(And personally, I find that renaming a bit counterintuitive, since it
is still a valid 32-bit entry point in SMBIOS3, and was the only entry
point up until and including SMBIOS 2.8.)

/
Leif

Re: [Qemu-devel] [PATCH] qdev-monitor.c: Add device id generation

[Peter Maydell]

On 25 August 2015 at 16:25, Programmingkid  wrote:
> On Aug 25, 2015, at 8:42 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>>
>>> On 08/24/2015 12:53 PM, Programmingkid wrote:
 +/* USB's max number of devices is 127. This number is 3 digits long. */
 +#define MAX_NUM_DIGITS_FOR_USB_ID 3
>>
>> This limit makes no sense to me.
>
> The limit is used to decide how many characters the device_id string is going 
> to have.
> Three digits would be 0 to 999 device ID's would be supported. I can't imagine
> anyone spending the time to add that many devices.

Arbitrary limits are often a bad idea, especially when
they're easy to avoid, as here.

 +/* Add one for '\0' character */
 +char *device_id = (char *) malloc(sizeof(char) *
 +MAX_NUM_DIGITS_FOR_USB_ID + 
 1);
 +sprintf(device_id, "%d", device_id_count++);
>>>
>>> g_strdup_printf() is a lot nicer about avoiding the risk of arbitrary
>>> overflow...

 +dev->id = (const char *) device_id;
 +
 +/* if device_id_count >= 10^MAX_NUM_DIGITS_FOR_USB_ID */
 +if (device_id_count >= pow(10, MAX_NUM_DIGITS_FOR_USB_ID)) {
 +printf("Warning: Maximum number of device ID's 
 generated!\n\a");
 +printf("Time for you to make your own device ID's.\n");
>>>
>>> besides, printf() is probably the wrong way to do error reporting, and
>>> we don't use \a BEL sequences anywhere else in qemu code.
>>>
 +}
 }
>>
>> When device_id_count reaches the limit, you warn.  Next time around, you
>> overrun the buffer.  Not good.
>
> I could change it so next time around, only the warning is displayed.
>
>>
>> Eric is right, g_strdup_printf() is easier and safer.
>
> If you say so. I have never heard of it myself.

It's a glib function. Glib has a lot of useful utility functions
for this kind of thing (and the general idea of "have an
sprintf-alike which allocates the buffer for you" has been
around long before glib came along). Note that HACKING says that
you shouldn't use 'malloc' anyway, but 'malloc and then sprintf
into the buffer' is a particular antipattern that will get picked
up on in code review.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 07/18] nvdimm: reserve address range for NVDIMM

[Stefan Hajnoczi]

On Fri, Aug 14, 2015 at 10:52:00PM +0800, Xiao Guangrong wrote:
> NVDIMM reserves all the free range above 4G to do:
> - Persistent Memory (PMEM) mapping
> - implement NVDIMM ACPI device _DSM method
> 
> Signed-off-by: Xiao Guangrong 
> ---
>  hw/i386/pc.c   | 12 ++--
>  hw/mem/nvdimm/pc-nvdimm.c  | 13 +
>  include/hw/mem/pc-nvdimm.h |  1 +
>  3 files changed, 24 insertions(+), 2 deletions(-)

CCing Igor for memory hotplug-related changes.

> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 7661ea9..41af6ea 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -64,6 +64,7 @@
>  #include "hw/pci/pci_host.h"
>  #include "acpi-build.h"
>  #include "hw/mem/pc-dimm.h"
> +#include "hw/mem/pc-nvdimm.h"
>  #include "qapi/visitor.h"
>  #include "qapi-visit.h"
>  
> @@ -1302,6 +1303,7 @@ FWCfgState *pc_memory_init(MachineState *machine,
>  MemoryRegion *ram_below_4g, *ram_above_4g;
>  FWCfgState *fw_cfg;
>  PCMachineState *pcms = PC_MACHINE(machine);
> +ram_addr_t offset;
>  
>  assert(machine->ram_size == below_4g_mem_size + above_4g_mem_size);
>  
> @@ -1339,6 +1341,8 @@ FWCfgState *pc_memory_init(MachineState *machine,
>  exit(EXIT_FAILURE);
>  }
>  
> +offset = 0x1ULL + above_4g_mem_size;
> +
>  /* initialize hotplug memory address space */
>  if (guest_info->has_reserved_memory &&
>  (machine->ram_size < machine->maxram_size)) {
> @@ -1358,8 +1362,7 @@ FWCfgState *pc_memory_init(MachineState *machine,
>  exit(EXIT_FAILURE);
>  }
>  
> -pcms->hotplug_memory.base =
> -ROUND_UP(0x1ULL + above_4g_mem_size, 1ULL << 30);
> +pcms->hotplug_memory.base = ROUND_UP(offset, 1ULL << 30);
>  
>  if (pcms->enforce_aligned_dimm) {
>  /* size hotplug region assuming 1G page max alignment per slot */
> @@ -1377,8 +1380,13 @@ FWCfgState *pc_memory_init(MachineState *machine,
> "hotplug-memory", hotplug_mem_size);
>  memory_region_add_subregion(system_memory, pcms->hotplug_memory.base,
>  &pcms->hotplug_memory.mr);
> +
> +offset = pcms->hotplug_memory.base + hotplug_mem_size;
>  }
>  
> + /* all the space left above 4G is reserved for NVDIMM. */
> +pc_nvdimm_reserve_range(offset);
> +
>  /* Initialize PC system firmware */
>  pc_system_firmware_init(rom_memory, guest_info->isapc_ram_fw);
>  
> diff --git a/hw/mem/nvdimm/pc-nvdimm.c b/hw/mem/nvdimm/pc-nvdimm.c
> index a53d235..7a270a8 100644
> --- a/hw/mem/nvdimm/pc-nvdimm.c
> +++ b/hw/mem/nvdimm/pc-nvdimm.c
> @@ -24,6 +24,19 @@
>  
>  #include "hw/mem/pc-nvdimm.h"
>  
> +#define PAGE_SIZE  (1UL << 12)
> +
> +static struct nvdimms_info {
> +ram_addr_t current_addr;
> +} nvdimms_info;
> +
> +/* the address range [offset, ~0ULL) is reserved for NVDIMM. */
> +void pc_nvdimm_reserve_range(ram_addr_t offset)
> +{
> +offset = ROUND_UP(offset, PAGE_SIZE);
> +nvdimms_info.current_addr = offset;
> +}
> +
>  static char *get_file(Object *obj, Error **errp)
>  {
>  PCNVDIMMDevice *nvdimm = PC_NVDIMM(obj);
> diff --git a/include/hw/mem/pc-nvdimm.h b/include/hw/mem/pc-nvdimm.h
> index 51152b8..8601e9b 100644
> --- a/include/hw/mem/pc-nvdimm.h
> +++ b/include/hw/mem/pc-nvdimm.h
> @@ -28,4 +28,5 @@ typedef struct PCNVDIMMDevice {
>  #define PC_NVDIMM(obj) \
>  OBJECT_CHECK(PCNVDIMMDevice, (obj), TYPE_PC_NVDIMM)
>  
> +void pc_nvdimm_reserve_range(ram_addr_t offset);
>  #endif
> -- 
> 2.4.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] Created virtio-vsock wiki page

[Stefan Hajnoczi]

I have created a wiki page for virtio-vsock.

It links to my git repos and the draft virtio specification:
http://qemu-project.org/Features/VirtioVsock

I'll expand and update it over the coming days and weeks.

Please let me know if you'd like to see specific information on there
(e.g. step-by-step build & QEMU invocation guide).

Stefan

Re: [Qemu-devel] [PATCH] qdev-monitor.c: Add device id generation

[Programmingkid]

On Aug 25, 2015, at 11:33 AM, Peter Maydell wrote:

> On 25 August 2015 at 16:25, Programmingkid  wrote:
>> On Aug 25, 2015, at 8:42 AM, Markus Armbruster wrote:
>>> Eric Blake  writes:
>>> 
 On 08/24/2015 12:53 PM, Programmingkid wrote:
> +/* USB's max number of devices is 127. This number is 3 digits long. */
> +#define MAX_NUM_DIGITS_FOR_USB_ID 3
>>> 
>>> This limit makes no sense to me.
>> 
>> The limit is used to decide how many characters the device_id string is 
>> going to have.
>> Three digits would be 0 to 999 device ID's would be supported. I can't 
>> imagine
>> anyone spending the time to add that many devices.
> 
> Arbitrary limits are often a bad idea, especially when
> they're easy to avoid, as here.

Knowing QEMU's limits can save the user from crashes and other problems. There 
is
only a finite amount of memory available to QEMU. 

> 
> +/* Add one for '\0' character */
> +char *device_id = (char *) malloc(sizeof(char) *
> +MAX_NUM_DIGITS_FOR_USB_ID + 
> 1);
> +sprintf(device_id, "%d", device_id_count++);
 
 g_strdup_printf() is a lot nicer about avoiding the risk of arbitrary
 overflow...
> 
> +dev->id = (const char *) device_id;
> +
> +/* if device_id_count >= 10^MAX_NUM_DIGITS_FOR_USB_ID */
> +if (device_id_count >= pow(10, MAX_NUM_DIGITS_FOR_USB_ID)) {
> +printf("Warning: Maximum number of device ID's 
> generated!\n\a");
> +printf("Time for you to make your own device ID's.\n");
 
 besides, printf() is probably the wrong way to do error reporting, and
 we don't use \a BEL sequences anywhere else in qemu code.
 
> +}
>}
>>> 
>>> When device_id_count reaches the limit, you warn.  Next time around, you
>>> overrun the buffer.  Not good.
>> 
>> I could change it so next time around, only the warning is displayed.
>> 
>>> 
>>> Eric is right, g_strdup_printf() is easier and safer.
>> 
>> If you say so. I have never heard of it myself.
> 
> It's a glib function. Glib has a lot of useful utility functions
> for this kind of thing (and the general idea of "have an
> sprintf-alike which allocates the buffer for you" has been
> around long before glib came along). Note that HACKING says that
> you shouldn't use 'malloc' anyway, but 'malloc and then sprintf
> into the buffer' is a particular antipattern that will get picked
> up on in code review.

Thank you very much for this info. Once the generated device ID
issue has been hammered down, I will make a new patch that
implements g_malloc and g_strdup_printf(). 

Re: [Qemu-devel] [ARM SMBIOS V4 PATCH 1/2] smbios: add smbios 3.0 support

[Wei Huang]

On 08/25/2015 10:29 AM, Leif Lindholm wrote:
> On Tue, Aug 25, 2015 at 04:17:42PM +0100, Peter Maydell wrote:
>> On 13 August 2015 at 18:09, Wei Huang  wrote:
>>> This patch adds support for SMBIOS 3.0 entry point. When caller invokes
>>> smbios_set_defaults(), it can specify entry point as 2.1 or 3.0. Then
>>> smbios_get_tables() will return the entry point table in right format.
>>
>>
>>> -/* SMBIOS entry point (anchor).
>>> - * BIOS must place this at a 16-bit-aligned address between 0xf and 
>>> 0xf.
>>> +/* SMBIOS entry point
>>> + * BIOS must place this at a 16-bit-aligned address between 0xf
>>> + * and 0xf.
>>>   */
>>> -struct smbios_entry_point {
>>> +struct smbios_21_entry_point {
>>>  uint8_t anchor_string[4];
>>>  uint8_t checksum;
>>>  uint8_t length;
>>> @@ -58,6 +52,25 @@ struct smbios_entry_point {
>>>  uint8_t smbios_bcd_revision;
>>>  } QEMU_PACKED;
>>
>> This breaks 'make check' for x86, because tests/bios-tables-test.c
>> still uses 'struct smbios_entry_point' and no longer compiles
>> if this patch is applied.
> 
> Urgh.
> 
>> I'm removing these two patches from my target-arm queue.
> 
> Fair enough.
> 
> Wei - is there actually any particular point in renaming this
> structure? In all versions of the specification before 3.0, this was
> only known as the "smbios entry point". Only with the introduction of
> SMBIOS 3.0 this was retrospectively renamed.

I can take this suggestion, with clear comment in header file so nobody
will get confused. Peter, please let me know if you object.

The new patches should be out in a short while.

Thanks,
-Wei

> 
> (And personally, I find that renaming a bit counterintuitive, since it
> is still a valid 32-bit entry point in SMBIOS3, and was the only entry
> point up until and including SMBIOS 2.8.)


> 
> /
> Leif
> 

Re: [Qemu-devel] [ARM SMBIOS V4 PATCH 1/2] smbios: add smbios 3.0 support

[Peter Maydell]

On 25 August 2015 at 16:59, Wei Huang  wrote:
> On 08/25/2015 10:29 AM, Leif Lindholm wrote:
>> Wei - is there actually any particular point in renaming this
>> structure? In all versions of the specification before 3.0, this was
>> only known as the "smbios entry point". Only with the introduction of
>> SMBIOS 3.0 this was retrospectively renamed.
>
> I can take this suggestion, with clear comment in header file so nobody
> will get confused. Peter, please let me know if you object.

I don't object (though the opinion of the qemu smbios/acpi
folk is probably more important than mine).

Please make sure you test the x86 platform has not been broken by
this change (preferably more thoroughly than just running
'make check'...).

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 08/18] nvdimm: init backend memory mapping and config data area

[Stefan Hajnoczi]

On Fri, Aug 14, 2015 at 10:52:01PM +0800, Xiao Guangrong wrote:
> The parameter @file is used as backed memory for NVDIMM which is
> divided into two parts if @dataconfig is true:

s/dataconfig/configdata/

> @@ -76,13 +109,87 @@ static void pc_nvdimm_init(Object *obj)
>   set_configdata, NULL);
>  }
>  
> +static uint64_t get_file_size(int fd)
> +{
> +struct stat stat_buf;
> +uint64_t size;
> +
> +if (fstat(fd, &stat_buf) < 0) {
> +return 0;
> +}
> +
> +if (S_ISREG(stat_buf.st_mode)) {
> +return stat_buf.st_size;
> +}
> +
> +if (S_ISBLK(stat_buf.st_mode) && !ioctl(fd, BLKGETSIZE64, &size)) {
> +return size;
> +}

#ifdef __linux__ for ioctl(fd, BLKGETSIZE64, &size)?

There is nothing Linux-specific about emulating NVDIMMs so this code
should compile on all platforms.

> +
> +return 0;
> +}
> +
>  static void pc_nvdimm_realize(DeviceState *dev, Error **errp)
>  {
>  PCNVDIMMDevice *nvdimm = PC_NVDIMM(dev);
> +char name[512];
> +void *buf;
> +ram_addr_t addr;
> +uint64_t size, nvdimm_size, config_size = MIN_CONFIG_DATA_SIZE;
> +int fd;
>  
>  if (!nvdimm->file) {
>  error_setg(errp, "file property is not set");
>  }

Missing return here.

> +
> +fd = open(nvdimm->file, O_RDWR);

Does it make sense to support read-only NVDIMMs?

It could be handy for sharing a read-only file between unprivileged
guests.  The permissions on the file would only allow read, not write.

> +if (fd < 0) {
> +error_setg(errp, "can not open %s", nvdimm->file);

s/can not/cannot/

> +return;
> +}
> +
> +size = get_file_size(fd);
> +buf = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

I guess the user will want to choose between MAP_SHARED and MAP_PRIVATE.
This can be added in the future.

> +if (buf == MAP_FAILED) {
> +error_setg(errp, "can not do mmap on %s", nvdimm->file);
> +goto do_close;
> +}
> +
> +nvdimm->config_data_size = config_size;
> +if (nvdimm->configdata) {
> +/* reserve MIN_CONFIGDATA_AREA_SIZE for configue data. */
> +nvdimm_size = size - config_size;
> +nvdimm->config_data_addr = buf + nvdimm_size;
> +} else {
> +nvdimm_size = size;
> +nvdimm->config_data_addr = NULL;
> +}
> +
> +if ((int64_t)nvdimm_size <= 0) {

The error cases can be detected before mmap(2).  That avoids the int64_t
cast and also avoids nvdimm_size underflow and the bogus
nvdimm->config_data_addr calculation above.

size = get_file_size(fd);
if (size == 0) {
error_setg(errp, "empty file or unable to get file size");
goto do_close;
} else if (nvdimm->configdata && size < config_size) {{
error_setg(errp, "file size is too small to store NVDIMM"
 " configure data");
goto do_close;
}

> +error_setg(errp, "file size is too small to store NVDIMM"
> + " configure data");
> +goto do_unmap;
> +}
> +
> +addr = reserved_range_push(nvdimm_size);
> +if (!addr) {
> +error_setg(errp, "do not have enough space for size %#lx.\n", size);

error_setg() messages must not have a newline at the end.

Please use "%#" PRIx64 instead of "%#lx" so compilation works on 32-bit
hosts where sizeof(long) == 4.

> +goto do_unmap;
> +}
> +
> +nvdimm->device_index = new_device_index();
> +sprintf(name, "NVDIMM-%d", nvdimm->device_index);
> +memory_region_init_ram_ptr(&nvdimm->mr, OBJECT(dev), name, nvdimm_size,
> +   buf);

How is the autogenerated name used?

Why not just use "pc-nvdimm.memory"?

> +vmstate_register_ram(&nvdimm->mr, DEVICE(dev));
> +memory_region_add_subregion(get_system_memory(), addr, &nvdimm->mr);
> +
> +return;

fd is leaked.

[Qemu-devel] [PATCH v2 2/8] s390x: Create QOM device for s390 storage keys

[Cornelia Huck]

From: "Jason J. Herne" 

A new QOM style device is provided to back guest storage keys. A special
version for KVM is created, which handles the storage key access via
KVM_S390_GET_SKEYS and KVM_S390_SET_SKEYS ioctl.

Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 MAINTAINERS |   1 +
 hw/s390x/Makefile.objs  |   2 +
 hw/s390x/s390-skeys-kvm.c   |  75 +
 hw/s390x/s390-skeys.c   | 141 
 include/hw/s390x/storage-keys.h |  55 
 5 files changed, 274 insertions(+)
 create mode 100644 hw/s390x/s390-skeys-kvm.c
 create mode 100644 hw/s390x/s390-skeys.c
 create mode 100644 include/hw/s390x/storage-keys.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a059d5d..c7a90a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -560,6 +560,7 @@ F: hw/s390x/css.[hc]
 F: hw/s390x/sclp*.[hc]
 F: hw/s390x/ipl*.[hc]
 F: hw/s390x/*pci*.[hc]
+F: hw/s390x/s390-skeys*.c
 F: include/hw/s390x/
 F: pc-bios/s390-ccw/
 T: git git://github.com/cohuck/qemu virtio-ccw-upstr
diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
index 27cd75a..527d754 100644
--- a/hw/s390x/Makefile.objs
+++ b/hw/s390x/Makefile.objs
@@ -9,3 +9,5 @@ obj-y += css.o
 obj-y += s390-virtio-ccw.o
 obj-y += virtio-ccw.o
 obj-y += s390-pci-bus.o s390-pci-inst.o
+obj-y += s390-skeys.o
+obj-$(CONFIG_KVM) += s390-skeys-kvm.o
diff --git a/hw/s390x/s390-skeys-kvm.c b/hw/s390x/s390-skeys-kvm.c
new file mode 100644
index 000..682949a
--- /dev/null
+++ b/hw/s390x/s390-skeys-kvm.c
@@ -0,0 +1,75 @@
+/*
+ * s390 storage key device
+ *
+ * Copyright 2015 IBM Corp.
+ * Author(s): Jason J. Herne 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or (at
+ * your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+
+#include "hw/s390x/storage-keys.h"
+#include "sysemu/kvm.h"
+#include "qemu/error-report.h"
+
+static int kvm_s390_skeys_enabled(S390SKeysState *ss)
+{
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+uint8_t single_key;
+int r;
+
+r = skeyclass->get_skeys(ss, 0, 1, &single_key);
+if (r != 0 && r != KVM_S390_GET_SKEYS_NONE) {
+error_report("S390_GET_KEYS error %d\n", r);
+}
+return (r == 0);
+}
+
+static int kvm_s390_skeys_get(S390SKeysState *ss, uint64_t start_gfn,
+  uint64_t count, uint8_t *keys)
+{
+struct kvm_s390_skeys args = {
+.start_gfn = start_gfn,
+.count = count,
+.skeydata_addr = (__u64)keys
+};
+
+return kvm_vm_ioctl(kvm_state, KVM_S390_GET_SKEYS, &args);
+}
+
+static int kvm_s390_skeys_set(S390SKeysState *ss, uint64_t start_gfn,
+  uint64_t count, uint8_t *keys)
+{
+struct kvm_s390_skeys args = {
+.start_gfn = start_gfn,
+.count = count,
+.skeydata_addr = (__u64)keys
+};
+
+return kvm_vm_ioctl(kvm_state, KVM_S390_SET_SKEYS, &args);
+}
+
+static void kvm_s390_skeys_class_init(ObjectClass *oc, void *data)
+{
+S390SKeysClass *skeyclass = S390_SKEYS_CLASS(oc);
+
+skeyclass->skeys_enabled = kvm_s390_skeys_enabled;
+skeyclass->get_skeys = kvm_s390_skeys_get;
+skeyclass->set_skeys = kvm_s390_skeys_set;
+}
+
+static const TypeInfo kvm_s390_skeys_info = {
+.name  = TYPE_KVM_S390_SKEYS,
+.parent= TYPE_S390_SKEYS,
+.instance_size = sizeof(S390SKeysState),
+.class_init= kvm_s390_skeys_class_init,
+.class_size= sizeof(S390SKeysClass),
+};
+
+static void kvm_s390_skeys_register_types(void)
+{
+type_register_static(&kvm_s390_skeys_info);
+}
+
+type_init(kvm_s390_skeys_register_types)
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
new file mode 100644
index 000..77c42ff
--- /dev/null
+++ b/hw/s390x/s390-skeys.c
@@ -0,0 +1,141 @@
+/*
+ * s390 storage key device
+ *
+ * Copyright 2015 IBM Corp.
+ * Author(s): Jason J. Herne 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or (at
+ * your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+
+#include "hw/boards.h"
+#include "hw/s390x/storage-keys.h"
+#include "qemu/error-report.h"
+
+S390SKeysState *s390_get_skeys_device(void)
+{
+S390SKeysState *ss;
+
+ss = S390_SKEYS(object_resolve_path_type("", TYPE_S390_SKEYS, NULL));
+assert(ss);
+return ss;
+}
+
+void s390_skeys_init(void)
+{
+Object *obj;
+
+if (kvm_enabled()) {
+obj = object_new(TYPE_KVM_S390_SKEYS);
+} else {
+obj = object_new(TYPE_QEMU_S390_SKEYS);
+}
+object_property_add_child(qdev_get_machine(), TYPE_S390_SKEYS,
+  obj, NULL);
+object_unref(obj);
+
+qdev_init_nofail(DEVICE(obj));
+}
+
+static void qemu_s390_skeys_init(Object *obj)
+{
+QEMUS390SKeysState *skeys = QEMU_S390_SKEYS(obj);
+MachineState *machine = MACHINE(qdev_get_machine());
+
+sk

[Qemu-devel] [PATCH v2 6/8] s390x: Info skeys sub-command

[Cornelia Huck]

From: "Jason J. Herne" 

Provide an  info skeys hmp sub-command to allow the end user to dump a storage
key for a given address. This is useful for guest operating system developers.

Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hmp-commands.hx |  2 ++
 hw/s390x/s390-skeys.c   | 23 +++
 include/hw/s390x/storage-keys.h |  2 ++
 monitor.c   |  9 +
 4 files changed, 36 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 803ff91..c61468e 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1806,6 +1806,8 @@ show roms
 show the TPM device
 @item info memory-devices
 show the memory devices
+@item info skeys
+Display the value of a storage key (s390 only)
 @end table
 ETEXI
 
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index f6a29ab..0b13d77 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -72,6 +72,29 @@ static void write_keys(QEMUFile *f, uint8_t *keys, uint64_t 
startgfn,
 g_free(buf);
 }
 
+void hmp_info_skeys(Monitor *mon, const QDict *qdict)
+{
+S390SKeysState *ss = s390_get_skeys_device();
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+uint64_t addr = qdict_get_int(qdict, "addr");
+uint8_t key;
+int r;
+
+/* Quick check to see if guest is using storage keys*/
+if (!skeyclass->skeys_enabled(ss)) {
+monitor_printf(mon, "Error: This guest is not using storage keys.\n");
+return;
+}
+
+r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
+if (r < 0) {
+monitor_printf(mon, "Error: %s\n", strerror(-r));
+return;
+}
+
+monitor_printf(mon, "  key: 0x%X\n", key);
+}
+
 void hmp_dump_skeys(Monitor *mon, const QDict *qdict)
 {
 const char *filename = qdict_get_str(qdict, "filename");
diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h
index 0d04f19..18e08d2 100644
--- a/include/hw/s390x/storage-keys.h
+++ b/include/hw/s390x/storage-keys.h
@@ -54,4 +54,6 @@ void s390_skeys_init(void);
 S390SKeysState *s390_get_skeys_device(void);
 
 void hmp_dump_skeys(Monitor *mon, const QDict *qdict);
+void hmp_info_skeys(Monitor *mon, const QDict *qdict);
+
 #endif /* __S390_STORAGE_KEYS_H */
diff --git a/monitor.c b/monitor.c
index 3deba38..451af6f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2881,6 +2881,15 @@ static mon_cmd_t info_cmds[] = {
 .help   = "Show rocker OF-DPA groups",
 .mhandler.cmd = hmp_rocker_of_dpa_groups,
 },
+#if defined(TARGET_S390X)
+{
+.name   = "skeys",
+.args_type  = "addr:l",
+.params = "address",
+.help   = "Display the value of a storage key",
+.mhandler.cmd = hmp_info_skeys,
+},
+#endif
 {
 .name   = NULL,
 },
-- 
2.5.0

[Qemu-devel] [PATCH v2 0/8] s390x: storage key migration

[Cornelia Huck]

Here's the second edition of the storage key migration patches.

Changes from v1:
- have the dump-skeys qmp command use qemu_fopen() and friends
- handle failures of the skeys-obtaining commands by filling the
  stream with zeroes and setting an error flag

Would like to send a pull request soonish.

Cornelia Huck (1):
  s390x: add 2.5 compat s390-ccw-virtio machine

Jason J. Herne (7):
  s390x: Create QOM device for s390 storage keys
  s390x: Enable new s390-storage-keys device
  s390x: Dump storage keys qmp command
  s390x: Dump-skeys hmp support
  s390x: Info skeys sub-command
  s390x: Migrate guest storage keys (initial memory only)
  s390x: Disable storage key migration on old machine type

 MAINTAINERS |   1 +
 hmp-commands.hx |  18 ++
 hw/s390x/Makefile.objs  |   2 +
 hw/s390x/s390-skeys-kvm.c   |  75 +++
 hw/s390x/s390-skeys.c   | 425 
 hw/s390x/s390-virtio-ccw.c  |  39 +++-
 hw/s390x/s390-virtio.c  |  11 +-
 hw/s390x/s390-virtio.h  |   2 +-
 include/hw/s390x/storage-keys.h |  60 ++
 monitor.c   |  20 ++
 qapi-schema.json|  13 ++
 qmp-commands.hx |  25 +++
 target-s390x/cpu.h  |   2 -
 target-s390x/mem_helper.c   |  46 -
 target-s390x/mmu_helper.c   |  28 ++-
 trace-events|   4 +
 16 files changed, 745 insertions(+), 26 deletions(-)
 create mode 100644 hw/s390x/s390-skeys-kvm.c
 create mode 100644 hw/s390x/s390-skeys.c
 create mode 100644 include/hw/s390x/storage-keys.h

-- 
2.5.0

[Qemu-devel] [PATCH v2 1/8] s390x: add 2.5 compat s390-ccw-virtio machine

[Cornelia Huck]

Reviewed-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
Acked-by: Christian Borntraeger 
---
 hw/s390x/s390-virtio-ccw.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 4c51d1a..71df282 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -287,9 +287,7 @@ static void ccw_machine_2_4_class_init(ObjectClass *oc, 
void *data)
 MachineClass *mc = MACHINE_CLASS(oc);
 
 mc->name = "s390-ccw-virtio-2.4";
-mc->alias = "s390-ccw-virtio";
 mc->desc = "VirtIO-ccw based S390 machine v2.4";
-mc->is_default = 1;
 }
 
 static const TypeInfo ccw_machine_2_4_info = {
@@ -298,10 +296,27 @@ static const TypeInfo ccw_machine_2_4_info = {
 .class_init= ccw_machine_2_4_class_init,
 };
 
+static void ccw_machine_2_5_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+
+mc->name = "s390-ccw-virtio-2.5";
+mc->alias = "s390-ccw-virtio";
+mc->desc = "VirtIO-ccw based S390 machine v2.5";
+mc->is_default = 1;
+}
+
+static const TypeInfo ccw_machine_2_5_info = {
+.name  = TYPE_S390_CCW_MACHINE "2.5",
+.parent= TYPE_S390_CCW_MACHINE,
+.class_init= ccw_machine_2_5_class_init,
+};
+
 static void ccw_machine_register_types(void)
 {
 type_register_static(&ccw_machine_info);
 type_register_static(&ccw_machine_2_4_info);
+type_register_static(&ccw_machine_2_5_info);
 }
 
 type_init(ccw_machine_register_types)
-- 
2.5.0

[Qemu-devel] [PATCH v2 8/8] s390x: Disable storage key migration on old machine type

[Cornelia Huck]

From: "Jason J. Herne" 

This code disables storage key migration when an older machine type is
specified.

Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-skeys.c   | 33 ++---
 hw/s390x/s390-virtio-ccw.c  | 12 
 include/hw/s390x/storage-keys.h |  1 +
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index 9d4a79d..392d547 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -363,12 +363,39 @@ static int s390_storage_keys_load(QEMUFile *f, void 
*opaque, int version_id)
 return ret;
 }
 
-static void s390_skeys_instance_init(Object *obj)
+static inline bool s390_skeys_get_migration_enabled(Object *obj, Error **errp)
+{
+S390SKeysState *ss = S390_SKEYS(obj);
+
+return ss->migration_enabled;
+}
+
+static inline void s390_skeys_set_migration_enabled(Object *obj, bool value,
+Error **errp)
 {
 S390SKeysState *ss = S390_SKEYS(obj);
 
-register_savevm(NULL, TYPE_S390_SKEYS, 0, 1, s390_storage_keys_save,
-s390_storage_keys_load, ss);
+/* Prevent double registration of savevm handler */
+if (ss->migration_enabled == value) {
+return;
+}
+
+ss->migration_enabled = value;
+
+if (ss->migration_enabled) {
+register_savevm(NULL, TYPE_S390_SKEYS, 0, 1, s390_storage_keys_save,
+s390_storage_keys_load, ss);
+} else {
+unregister_savevm(DEVICE(ss), TYPE_S390_SKEYS, ss);
+}
+}
+
+static void s390_skeys_instance_init(Object *obj)
+{
+object_property_add_bool(obj, "migration-enabled",
+ s390_skeys_get_migration_enabled,
+ s390_skeys_set_migration_enabled, NULL);
+object_property_set_bool(obj, true, "migration-enabled", NULL);
 }
 
 static void s390_skeys_class_init(ObjectClass *oc, void *data)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 0a057ae..e2a26e9 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -282,12 +282,24 @@ static const TypeInfo ccw_machine_info = {
 },
 };
 
+#define CCW_COMPAT_2_4 \
+{\
+.driver   = TYPE_S390_SKEYS,\
+.property = "migration-enabled",\
+.value= "off",\
+},
+
 static void ccw_machine_2_4_class_init(ObjectClass *oc, void *data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
+static GlobalProperty compat_props[] = {
+CCW_COMPAT_2_4
+{ /* end of list */ }
+};
 
 mc->name = "s390-ccw-virtio-2.4";
 mc->desc = "VirtIO-ccw based S390 machine v2.4";
+mc->compat_props = compat_props;
 }
 
 static const TypeInfo ccw_machine_2_4_info = {
diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h
index 18e08d2..72b850c 100644
--- a/include/hw/s390x/storage-keys.h
+++ b/include/hw/s390x/storage-keys.h
@@ -21,6 +21,7 @@
 
 typedef struct S390SKeysState {
 DeviceState parent_obj;
+bool migration_enabled;
 
 } S390SKeysState;
 
-- 
2.5.0

[Qemu-devel] [PATCH v2 3/8] s390x: Enable new s390-storage-keys device

[Cornelia Huck]

From: "Jason J. Herne" 

s390 guest initialization is modified to make use of new s390-storage-keys
device. Old code that globally allocated storage key array is removed.
The new device enables storage key access for kvm guests.

Cache storage key QOM objects in frequently used helper functions to avoid a
performance hit every time we use one of these functions.

Reviewed-by: Cornelia Huck 
Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio-ccw.c |  8 
 hw/s390x/s390-virtio.c | 11 +--
 hw/s390x/s390-virtio.h |  2 +-
 target-s390x/cpu.h |  2 --
 target-s390x/mem_helper.c  | 46 --
 target-s390x/mmu_helper.c  | 28 +++-
 trace-events   |  4 
 7 files changed, 77 insertions(+), 24 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 71df282..0a057ae 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -19,6 +19,7 @@
 #include "virtio-ccw.h"
 #include "qemu/config-file.h"
 #include "s390-pci-bus.h"
+#include "hw/s390x/storage-keys.h"
 
 #define TYPE_S390_CCW_MACHINE   "s390-ccw-machine"
 
@@ -105,7 +106,6 @@ static void ccw_init(MachineState *machine)
 MemoryRegion *sysmem = get_system_memory();
 MemoryRegion *ram = g_new(MemoryRegion, 1);
 sclpMemoryHotplugDev *mhd = init_sclp_memory_hotplug_dev();
-uint8_t *storage_keys;
 int ret;
 VirtualCssBus *css_bus;
 DeviceState *dev;
@@ -179,11 +179,11 @@ static void ccw_init(MachineState *machine)
 mhd->standby_mem_size = standby_mem_size;
 }
 
-/* allocate storage keys */
-storage_keys = g_malloc0(my_ram_size / TARGET_PAGE_SIZE);
+/* Initialize storage key device */
+s390_skeys_init();
 
 /* init CPUs */
-s390_init_cpus(machine->cpu_model, storage_keys);
+s390_init_cpus(machine->cpu_model);
 
 if (kvm_enabled()) {
 kvm_s390_enable_css_support(s390_cpu_addr2state(0));
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index 1284e77..6cc6b5d 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -38,6 +38,7 @@
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/s390_flic.h"
 #include "hw/s390x/s390-virtio.h"
+#include "hw/s390x/storage-keys.h"
 #include "cpu.h"
 
 //#define DEBUG_S390
@@ -164,7 +165,7 @@ void s390_init_ipl_dev(const char *kernel_filename,
 qdev_init_nofail(dev);
 }
 
-void s390_init_cpus(const char *cpu_model, uint8_t *storage_keys)
+void s390_init_cpus(const char *cpu_model)
 {
 int i;
 
@@ -184,7 +185,6 @@ void s390_init_cpus(const char *cpu_model, uint8_t 
*storage_keys)
 ipi_states[i] = cpu;
 cs->halted = 1;
 cs->exception_index = EXCP_HLT;
-cpu->env.storage_keys = storage_keys;
 }
 }
 
@@ -264,7 +264,6 @@ static void s390_init(MachineState *machine)
 MemoryRegion *sysmem = get_system_memory();
 MemoryRegion *ram = g_new(MemoryRegion, 1);
 int increment_size = 20;
-uint8_t *storage_keys;
 void *virtio_region;
 hwaddr virtio_region_len;
 hwaddr virtio_region_start;
@@ -306,11 +305,11 @@ static void s390_init(MachineState *machine)
 cpu_physical_memory_unmap(virtio_region, virtio_region_len, 1,
   virtio_region_len);
 
-/* allocate storage keys */
-storage_keys = g_malloc0(my_ram_size / TARGET_PAGE_SIZE);
+/* Initialize storage key device */
+s390_skeys_init();
 
 /* init CPUs */
-s390_init_cpus(machine->cpu_model, storage_keys);
+s390_init_cpus(machine->cpu_model);
 
 /* Create VirtIO network adapters */
 s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
diff --git a/hw/s390x/s390-virtio.h b/hw/s390x/s390-virtio.h
index c847853..cf68796 100644
--- a/hw/s390x/s390-virtio.h
+++ b/hw/s390x/s390-virtio.h
@@ -19,7 +19,7 @@
 typedef int (*s390_virtio_fn)(const uint64_t *args);
 void s390_register_virtio_hypercall(uint64_t code, s390_virtio_fn fn);
 
-void s390_init_cpus(const char *cpu_model, uint8_t *storage_keys);
+void s390_init_cpus(const char *cpu_model);
 void s390_init_ipl_dev(const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 63aebf4..b650890 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -143,8 +143,6 @@ typedef struct CPUS390XState {
 uint32_t cpu_num;
 uint32_t machine_type;
 
-uint8_t *storage_keys;
-
 uint64_t tod_offset;
 uint64_t tod_basetime;
 QEMUTimer *tod_timer;
diff --git a/target-s390x/mem_helper.c b/target-s390x/mem_helper.c
index 6f8bd79..84bf198 100644
--- a/target-s390x/mem_helper.c
+++ b/target-s390x/mem_helper.c
@@ -21,6 +21,7 @@
 #include "cpu.h"
 #include "exec/helper-proto.h"
 #include "exec/cpu_ldst.h"
+#include "hw/s390x/sto