Re: [Qemu-devel] [PATCH] chardev-socket: remove useless if

[Paolo Bonzini]

On 21/03/2018 04:25, Peter Xu wrote:
> On Tue, Mar 20, 2018 at 04:18:57PM +0100, Paolo Bonzini wrote:
>> This trips Coverity, which believes the subsequent qio_channel_create_watch
>> can dereference a NULL pointer.  In reality, tcp_chr_connect's callers
>> all have s->ioc properly initialized, since they are all rooted at
>> tcp_chr_new_client.
>>
>> Signed-off-by: Paolo Bonzini 
> 
> (maybe replacing with an assertion would be nicer? No big deal.)

It's already asserting, it just raises SIGSEGV instead of SIGABRT. :)

Paolo

Re: [Qemu-devel] [PATCH 4/5] atapi: call ide_set_irq before ide_transfer_start

[Paolo Bonzini]

On 21/03/2018 01:35, John Snow wrote:
>> The ATAPI_INT_REASON_IO interrupt is raised when I/O starts, but in the
>> AHCI case ide_set_irq was actually called at the end of a mutual recursion.
>> Move it early, with the side effect that ide_transfer_start becomes a tail
>> call in ide_atapi_cmd_reply_end.
>>
> Do you know in which spec it specifies that we should interrupt?
> 
> Seems okay, but I wanted to double check the wording in the spec (was
> looking in scsi MMC and ATA8) and couldn't find it quickly.

I have an "Interrupt Reason" field in my copy of the ATA/ATAPI spec:

---
6.4.3 Input/Output (I/O) bit
The Input/Output bit shall be cleared to zero if the transfer is to the
device. The Input/Output bit shall be set to one if the transfer is to
the host. In ATA/ATAPI-7 this bit was documented as the I/O bit.
---

I suppose the commit message needs some improvement---the point is that
since this is a READ, the I/O bit must be set before we start the
transfer.  It can be done after the disk I/O starts, but it must be done
before the PIO transfer starts; in other words, the bug is only there
for AHCI.

Paolo

Re: [Qemu-devel] [PATCH 2/5] ide: push end_transfer callback to ide_transfer_halt

[Paolo Bonzini]

On 20/03/2018 23:11, John Snow wrote:
> Seems sane, with some lingering questions about what the PIO Setup FIS
> is supposed to do to begin with still remaining.

I agree here too.  Smashing the ATA and controller in the same device
makes things tricky, so I tried to make these patches pure code motion,
as much as I could.

Paolo

Re: [Qemu-devel] [PATCH 1/5] ide: push call to end_transfer_func out of start_transfer callback

[Paolo Bonzini]

On 20/03/2018 22:46, John Snow wrote:
>>  }
>> -if (s->bus->dma->ops->start_transfer) {
>> -s->bus->dma->ops->start_transfer(s->bus->dma);
>> +if (!s->bus->dma->ops->start_transfer) {
>> +s->end_transfer_func = end_transfer_func;
>> +return;
>>  }
>> +s->bus->dma->ops->start_transfer(s->bus->dma);
>> +end_transfer_func(s);
> wow, this makes me really uneasy to look at. The assumption now is: "If
> you have a start_transfer method, that method if successful implies that
> the transfer is *COMPLETED*."
> 
> It's implicit here, but I think anyone but the two of us would probably
> not understand that implication. (Or me in three months.) What can we do
> about that? Since AHCI is the only interface that uses this callback, I
> wonder if we can't just rename it to something more obvious.

You are completely right, it should be renamed to pio_transfer.

> Under normal circumstances this function really does just "start" a
> transfer and it's not obvious from context that some adapters have
> synchronous methods to finish the transfer without further PIO pingpong
> with the guest.

Yeah, though it is already doing it---the patch is only unhiding the
mutual recursion by pulling it one level up.

Paolo

Re: [Qemu-devel] Partial NUMA config

[Alexey Kardashevskiy]

On 20/3/18 5:46 pm, Igor Mammedov wrote:
> On Mon, 19 Mar 2018 15:28:50 +1100
> Alexey Kardashevskiy  wrote:
> 
>> On 13/3/18 1:26 pm, Alexey Kardashevskiy wrote:
>>> Hi Igor,
>>>
>>> ec78f8114bc4c1 "numa: use possible_cpus for not mapped CPUs check" added a
>>> warning about "All CPU(s) up to maxcpus should be described in NUMA config,
>>> ability to start up with partial NUMA mappings is obsoleted and will be
>>> removed in future" and this is printed when I add a numa node without
>>> attached CPU like this:
>>>
>>> -numa node,nodeid=0,cpus=0,mem=4G
>>> -numa node,nodeid=1,mem=131072M
> Warning you see is about CPU(s) not assigned to any node
> and it has noting to do with cpu-less node.
> 
> What's the full CLI you are using?

I do not have it handy but it included:
-smp 2 -numa node,nodeid=0,cpus=0,mem=4G -numa node,nodeid=1,mem=131072M

And your explanation about nonassigned CPUs makes sense, thanks!


-- 
Alexey

[Qemu-devel] [Bug 1757323] [NEW] blue screen running windows 10 install DVD on qemu

[piersh]

Public bug reported:

i get a blue screen at the first screen of the windows 10 DVD setup
(Win10_1709_English_x64.iso, available from MS).

The DVD boots fine, and gets to the first dialog: 
http://codewithoutborders.com/posted/qemu1.png
and then if i just wait a minute of so it blue screen's.
either DRIVER IRQL NOT LESS OR EQUAL: 
http://codewithoutborders.com/posted/qemu2.png
or KMODE EXCEPTION NOT HANDLED: http://codewithoutborders.com/posted/qemu3.png


the qemu command-line is:

/usr/bin/qemu-system-x87_64 \
 -boot strict=on \
 -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-generic/monitor.sock,server,nowait
 \
 -chardev spicevmc,id=charchannel0,name=vdagent \
 -cpu 
core2duo,+lahf_lm,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,kvm=off
 \
 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
 -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
 -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 \
 -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2
 \
 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
 -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 \
 -drive 
file=/mnt/ISOs/Win10_1709_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on
 \
 -global kvm-pit.lost_tick_policy=discard \
 -global PIIX4_PM.disable_s3=1 \
 -global PIIX4_PM.disable_s4=1 \
 -m 4096 \
 -machine pc-i440fx-xenial,accel=tcg,usb=off \
 -mon chardev=charmonitor,id=monitor,mode=control \
 -msg timestamp=on \
 -name generic \
 -nodefaults \
 -no-hpet \
 -no-shutdown \
 -no-user-config \
 -realtime mlock=off \
 -rtc base=utc,driftfix=slew \
 -S \
 -smp 2,sockets=2,cores=1,threads=1 \
 -spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
 \
 -uuid 3902a801-42dd-4bf2-8f3a-cbc68f4f8564


$ /usr/bin/qemu-system-x87_64 --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24), Copyright (c) 
2003-2008 Fabrice Bellard

$ uname -a
Linux host 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 Quad CPU   @ 2.66GHz
stepping: 7
microcode   : 0x66
cpu MHz : 2671.406
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti retpoline 
tpr_shadow dtherm
bugs: cpu_meltdown spectre_v1 spectre_v2
bogomips: 5342.81
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

... 3 more times

** 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/1757323

Title:
  blue screen running windows 10 install DVD on qemu

Status in QEMU:
  New

Bug description:
  i get a blue screen at the first screen of the windows 10 DVD setup
  (Win10_1709_English_x64.iso, available from MS).

  The DVD boots fine, and gets to the first dialog: 
http://codewithoutborders.com/posted/qemu1.png
  and then if i just wait a minute of so it blue screen's.
  either DRIVER IRQL NOT LESS OR EQUAL: 
http://codewithoutborders.com/posted/qemu2.png
  or KMODE EXCEPTION NOT HANDLED: http://codewithoutborders.com/posted/qemu3.png


  
  the qemu command-line is:

  /usr/bin/qemu-system-x87_64 \
   -boot strict=on \
   -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-generic/monitor.sock,server,nowait
 \
   -chardev spicevmc,id=charchannel0,name=vdagent \
   -cpu 
core2duo,+lahf_lm,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,kvm=off
 \
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
   -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 
\
   

[Qemu-devel] [Bug 1757323] Re: blue screen running windows 10 install DVD on qemu

[piersh]

i should add: i do NOT get these crashes if I boot the same image on the
host bare-metal.

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

Title:
  blue screen running windows 10 install DVD on qemu

Status in QEMU:
  New

Bug description:
  i get a blue screen at the first screen of the windows 10 DVD setup
  (Win10_1709_English_x64.iso, available from MS).

  The DVD boots fine, and gets to the first dialog: 
http://codewithoutborders.com/posted/qemu1.png
  and then if i just wait a minute of so it blue screen's.
  either DRIVER IRQL NOT LESS OR EQUAL: 
http://codewithoutborders.com/posted/qemu2.png
  or KMODE EXCEPTION NOT HANDLED: http://codewithoutborders.com/posted/qemu3.png


  
  the qemu command-line is:

  /usr/bin/qemu-system-x87_64 \
   -boot strict=on \
   -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-generic/monitor.sock,server,nowait
 \
   -chardev spicevmc,id=charchannel0,name=vdagent \
   -cpu 
core2duo,+lahf_lm,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,kvm=off
 \
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
   -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 
\
   -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2
 \
   -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
   -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
   -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 \
   -drive 
file=/mnt/ISOs/Win10_1709_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on
 \
   -global kvm-pit.lost_tick_policy=discard \
   -global PIIX4_PM.disable_s3=1 \
   -global PIIX4_PM.disable_s4=1 \
   -m 4096 \
   -machine pc-i440fx-xenial,accel=tcg,usb=off \
   -mon chardev=charmonitor,id=monitor,mode=control \
   -msg timestamp=on \
   -name generic \
   -nodefaults \
   -no-hpet \
   -no-shutdown \
   -no-user-config \
   -realtime mlock=off \
   -rtc base=utc,driftfix=slew \
   -S \
   -smp 2,sockets=2,cores=1,threads=1 \
   -spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
 \
   -uuid 3902a801-42dd-4bf2-8f3a-cbc68f4f8564

  
  $ /usr/bin/qemu-system-x87_64 --version
  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24), Copyright (c) 
2003-2008 Fabrice Bellard

  $ uname -a
  Linux host 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 
2018 x86_64 x86_64 x86_64 GNU/Linux

  $ cat /proc/cpuinfo 
  processor : 0
  vendor_id : GenuineIntel
  cpu family: 6
  model : 15
  model name: Intel(R) Core(TM)2 Quad CPU   @ 2.66GHz
  stepping  : 7
  microcode : 0x66
  cpu MHz   : 2671.406
  cache size: 4096 KB
  physical id   : 0
  siblings  : 4
  core id   : 0
  cpu cores : 4
  apicid: 0
  initial apicid: 0
  fpu   : yes
  fpu_exception : yes
  cpuid level   : 10
  wp: yes
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti retpoline 
tpr_shadow dtherm
  bugs  : cpu_meltdown spectre_v1 spectre_v2
  bogomips  : 5342.81
  clflush size  : 64
  cache_alignment   : 64
  address sizes : 36 bits physical, 48 bits virtual
  power management:

  ... 3 more times

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

Re: [Qemu-devel] [PATCH 19/19] mac_newworld: move wiring of macio IRQs to macio_newworld_realize()

[David Gibson]

On Tue, Mar 06, 2018 at 08:31:03PM +, Mark Cave-Ayland wrote:
> Since the macio device has a link to the PIC device, we can now wire up the
> IRQs directly via qdev GPIOs rather than having to use an intermediate array.
> 
> Signed-off-by: Mark Cave-Ayland 

Reviewed-by: David Gibson 

> ---
>  hw/misc/macio/macio.c | 37 ++---
>  hw/ppc/mac_newworld.c | 14 --
>  include/hw/misc/macio/macio.h |  1 -
>  3 files changed, 22 insertions(+), 30 deletions(-)
> 
> diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
> index af1bd46b4b..1aa7bb7c89 100644
> --- a/hw/misc/macio/macio.c
> +++ b/hw/misc/macio/macio.c
> @@ -265,11 +265,10 @@ static void macio_newworld_realize(PCIDevice *d, Error 
> **errp)
>  {
>  MacIOState *s = MACIO(d);
>  NewWorldMacIOState *ns = NEWWORLD_MACIO(d);
> +DeviceState *pic_dev = DEVICE(ns->pic);
>  Error *err = NULL;
>  SysBusDevice *sysbus_dev;
>  MemoryRegion *timer_memory = NULL;
> -int i;
> -int cur_irq = 0;
>  
>  macio_common_realize(d, );
>  if (err) {
> @@ -278,11 +277,14 @@ static void macio_newworld_realize(PCIDevice *d, Error 
> **errp)
>  }
>  
>  sysbus_dev = SYS_BUS_DEVICE(>cuda);
> -sysbus_connect_irq(sysbus_dev, 0, ns->irqs[cur_irq++]);
> +sysbus_connect_irq(sysbus_dev, 0, qdev_get_gpio_in(pic_dev,
> +   NEWWORLD_CUDA_IRQ));
>  
>  sysbus_dev = SYS_BUS_DEVICE(>escc);
> -sysbus_connect_irq(sysbus_dev, 0, ns->irqs[cur_irq++]);
> -sysbus_connect_irq(sysbus_dev, 1, ns->irqs[cur_irq++]);
> +sysbus_connect_irq(sysbus_dev, 0, qdev_get_gpio_in(pic_dev,
> +   NEWWORLD_ESCCB_IRQ));
> +sysbus_connect_irq(sysbus_dev, 1, qdev_get_gpio_in(pic_dev,
> +   NEWWORLD_ESCCA_IRQ));
>  
>  /* OpenPIC */
>  sysbus_dev = SYS_BUS_DEVICE(ns->pic);
> @@ -290,15 +292,22 @@ static void macio_newworld_realize(PCIDevice *d, Error 
> **errp)
>  sysbus_mmio_get_region(sysbus_dev, 0));
>  
>  /* IDE buses */
> -for (i = 0; i < ARRAY_SIZE(ns->ide); i++) {
> -qemu_irq irq0 = ns->irqs[cur_irq++];
> -qemu_irq irq1 = ns->irqs[cur_irq++];
> +macio_realize_ide(s, >ide[0],
> +  qdev_get_gpio_in(pic_dev, NEWWORLD_IDE0_IRQ),
> +  qdev_get_gpio_in(pic_dev, NEWWORLD_IDE0_DMA_IRQ),
> +  0x16, );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
>  
> -macio_realize_ide(s, >ide[i], irq0, irq1, 0x16 + (i * 4), );
> -if (err) {
> -error_propagate(errp, err);
> -return;
> -}
> +macio_realize_ide(s, >ide[1],
> +  qdev_get_gpio_in(pic_dev, NEWWORLD_IDE1_IRQ),
> +  qdev_get_gpio_in(pic_dev, NEWWORLD_IDE1_DMA_IRQ),
> +  0x1a, );
> +if (err) {
> +error_propagate(errp, err);
> +return;
>  }
>  
>  /* Timer */
> @@ -314,8 +323,6 @@ static void macio_newworld_init(Object *obj)
>  NewWorldMacIOState *ns = NEWWORLD_MACIO(obj);
>  int i;
>  
> -qdev_init_gpio_out(DEVICE(obj), ns->irqs, ARRAY_SIZE(ns->irqs));
> -
>  object_property_add_link(obj, "pic", TYPE_OPENPIC,
>   (Object **) >pic,
>   qdev_prop_allow_set_link_before_realize,
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 3cde507065..ae2ce562a4 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -376,20 +376,6 @@ static void ppc_core99_init(MachineState *machine)
>  /* MacIO */
>  macio = NEWWORLD_MACIO(pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO));
>  dev = DEVICE(macio);
> -qdev_connect_gpio_out(dev, 0,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_CUDA_IRQ));
> -qdev_connect_gpio_out(dev, 1,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_ESCCB_IRQ));
> -qdev_connect_gpio_out(dev, 2,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_ESCCA_IRQ));
> -qdev_connect_gpio_out(dev, 3,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_IDE0_IRQ));
> -qdev_connect_gpio_out(dev, 4,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_IDE0_DMA_IRQ));
> -qdev_connect_gpio_out(dev, 5,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_IDE1_IRQ));
> -qdev_connect_gpio_out(dev, 6,
> -qdev_get_gpio_in(pic_dev, NEWWORLD_IDE1_DMA_IRQ));
>  qdev_prop_set_uint64(dev, "frequency", tbfreq);
>  object_property_set_link(OBJECT(macio), OBJECT(pic_dev), "pic",
>   _abort);
> diff --git a/include/hw/misc/macio/macio.h b/include/hw/misc/macio/macio.h
> index 4528282b36..e3b9ef48dd 100644
> --- a/include/hw/misc/macio/macio.h
> +++ b/include/hw/misc/macio/macio.h
> @@ -72,7 

Re: [Qemu-devel] [PATCH 18/19] mac_newworld: remove pics IRQ array and wire up macio to OpenPIC directly

[David Gibson]

On Tue, Mar 06, 2018 at 08:31:02PM +, Mark Cave-Ayland wrote:
> Introduce constants for the pre-defined New World IRQs to help keep things
> readable.
> 
> Signed-off-by: Mark Cave-Ayland 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/mac.h  |  8 
>  hw/ppc/mac_newworld.c | 29 +++--
>  2 files changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
> index 5f5916252a..3819058310 100644
> --- a/hw/ppc/mac.h
> +++ b/hw/ppc/mac.h
> @@ -47,6 +47,14 @@
>  
>  #define ESCC_CLOCK 3686400
>  
> +/* New World IRQs */
> +#define NEWWORLD_CUDA_IRQ  0x19
> +#define NEWWORLD_ESCCB_IRQ 0x24
> +#define NEWWORLD_ESCCA_IRQ 0x25
> +#define NEWWORLD_IDE0_IRQ  0xd
> +#define NEWWORLD_IDE0_DMA_IRQ  0x2
> +#define NEWWORLD_IDE1_IRQ  0xe
> +#define NEWWORLD_IDE1_DMA_IRQ  0x3
>  
>  /* MacIO */
>  #define TYPE_MACIO_IDE "macio-ide"
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 2fcb101982..3cde507065 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -115,7 +115,7 @@ static void ppc_core99_init(MachineState *machine)
>  PowerPCCPU *cpu = NULL;
>  CPUPPCState *env = NULL;
>  char *filename;
> -qemu_irq *pic, **openpic_irqs;
> +qemu_irq **openpic_irqs;
>  int linux_boot, i, j, k;
>  MemoryRegion *ram = g_new(MemoryRegion, 1), *bios = g_new(MemoryRegion, 
> 1);
>  hwaddr kernel_base, initrd_base, cmdline_base = 0;
> @@ -292,8 +292,6 @@ static void ppc_core99_init(MachineState *machine)
>  }
>  }
>  
> -pic = g_new0(qemu_irq, 64);
> -
>  pic_dev = qdev_create(NULL, TYPE_OPENPIC);
>  qdev_prop_set_uint32(pic_dev, "model", OPENPIC_MODEL_KEYLARGO);
>  qdev_init_nofail(pic_dev);
> @@ -305,10 +303,6 @@ static void ppc_core99_init(MachineState *machine)
>  }
>  }
>  
> -for (i = 0; i < 64; i++) {
> -pic[i] = qdev_get_gpio_in(pic_dev, i);
> -}
> -
>  if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>  /* 970 gets a U3 bus */
>  /* Uninorth AGP bus */
> @@ -382,13 +376,20 @@ static void ppc_core99_init(MachineState *machine)
>  /* MacIO */
>  macio = NEWWORLD_MACIO(pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO));
>  dev = DEVICE(macio);
> -qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */
> -qdev_connect_gpio_out(dev, 1, pic[0x24]); /* ESCC-B */
> -qdev_connect_gpio_out(dev, 2, pic[0x25]); /* ESCC-A */
> -qdev_connect_gpio_out(dev, 3, pic[0x0d]); /* IDE */
> -qdev_connect_gpio_out(dev, 4, pic[0x02]); /* IDE DMA */
> -qdev_connect_gpio_out(dev, 5, pic[0x0e]); /* IDE */
> -qdev_connect_gpio_out(dev, 6, pic[0x03]); /* IDE DMA */
> +qdev_connect_gpio_out(dev, 0,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_CUDA_IRQ));
> +qdev_connect_gpio_out(dev, 1,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_ESCCB_IRQ));
> +qdev_connect_gpio_out(dev, 2,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_ESCCA_IRQ));
> +qdev_connect_gpio_out(dev, 3,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_IDE0_IRQ));
> +qdev_connect_gpio_out(dev, 4,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_IDE0_DMA_IRQ));
> +qdev_connect_gpio_out(dev, 5,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_IDE1_IRQ));
> +qdev_connect_gpio_out(dev, 6,
> +qdev_get_gpio_in(pic_dev, NEWWORLD_IDE1_DMA_IRQ));
>  qdev_prop_set_uint64(dev, "frequency", tbfreq);
>  object_property_set_link(OBJECT(macio), OBJECT(pic_dev), "pic",
>   _abort);

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v3 3/4] cryptodev-vhost-user: add crypto session handler

[Zhang, Roy Fan]

Hi Jay,

Excellent work! The patch, although need some minor rework, has improved the 
performance.
Some comments:

1. you need to set up capabilities for virtio_crypto PMD. As in Qemu vhost 
crypto proxy backend only AESCBC and SHA1 are supported (in 
cryptodev_vhost_user_init() definition), I believe in this version these two 
algorithms shall be enough.  Actually for the same reason I suggest you to 
remove all AES_CTR test cases in the virtio_crypto PMD functional test, as they 
will fail when vhost_user crypto backend is used.

You may use driver/crypto/qat/qat_crypto_capabilities.h as example. The const 
capabilities array shall be returned to the application when 
virtio_crypto_dev_info_get() is called.
2. there is a bug in virtio_crypto_queue_setup(), you declared " uint32_t i, 
j;" while i may be used uninitialized later.

Regards,
Fan


> -Original Message-
> From: Jay Zhou [mailto:jianjay.z...@huawei.com]
> Sent: Tuesday, January 16, 2018 2:07 PM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; pbonz...@redhat.com; weidong.hu...@huawei.com;
> stefa...@redhat.com; jianjay.z...@huawei.com;
> pa...@linux.vnet.ibm.com; longpe...@huawei.com; Zeng, Xin
> ; Zhang, Roy Fan ;
> arei.gong...@huawei.com
> Subject: [PATCH v3 3/4] cryptodev-vhost-user: add crypto session handler
> 

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/4] target/ppc: export external HPT via virtual hypervisor

[David Gibson]

On Sat, Mar 17, 2018 at 09:55:28AM +0100, Cédric Le Goater wrote:
> On 03/17/2018 05:15 AM, David Gibson wrote:
> > On Thu, Mar 15, 2018 at 01:33:59PM +, Cédric Le Goater wrote:
> >> commit e57ca75ce3b2 ("target/ppc: Manage external HPT via virtual
> >> hypervisor") exported a set of methods to manipulate the HPT from the
> >> core hash MMU but the base address of the HPT was not part of them and
> >> SPR_SDR1 is still used under some circumstances, which is incorrect
> >> for the sPAPR machines.
> >>
> >> This is not a major change as only the logging should be impacted but
> >> nevertheless, it will help to introduce support for the hash MMU on
> >> POWER9 PowerNV machines.
> >>
> >> Signed-off-by: Cédric Le Goater 
> > 
> > This doesn't make sense.  The whole point of the "virtual hypervisor"
> > is that the hash table doesn't live within the guest address space,
> > and therefore it *has* no meaningful base address.  Basically
> > ppc_hash64_hpt_base() should never be called if vhyp is set.  If it
> > is, that's a bug.
> 
> 
> ppc_hash64_hpt_base() is being called in a couple of places but the
> returned value is only used if the machines is not a pseries :
> 
>   static inline hwaddr ppc_hash64_hpt_mask(PowerPCCPU *cpu)
>   {
>   if (cpu->vhyp) {
>   PPCVirtualHypervisorClass *vhc =
>   PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
>   return vhc->hpt_mask(cpu->vhyp);
>   }
>   
> 
>   const ppc_hash_pte64_t *ppc_hash64_map_hptes(PowerPCCPU *cpu,
>hwaddr ptex, int n)
>   {
>   hwaddr pte_offset = ptex * HASH_PTE_SIZE_64;
>   hwaddr base = ppc_hash64_hpt_base(cpu);
>   hwaddr plen = n * HASH_PTE_SIZE_64;
>   const ppc_hash_pte64_t *hptes;
>   
>   if (cpu->vhyp) {
>   PPCVirtualHypervisorClass *vhc =
>   PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
>   return vhc->map_hptes(cpu->vhyp, ptex, n);
>   }  
>   
>   
> and also :
>   
>   void ppc_hash64_store_hpte(PowerPCCPU *cpu, hwaddr ptex,
>  uint64_t pte0, uint64_t pte1)
>   {
>   hwaddr base = ppc_hash64_hpt_base(cpu);
>   hwaddr offset = ptex * HASH_PTE_SIZE_64;
>   
>   if (cpu->vhyp) {
>   PPCVirtualHypervisorClass *vhc =
>   PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
>   vhc->store_hpte(cpu->vhyp, ptex, pte0, pte1);
>   return;
>   }
>   

Right.. so called, but not really used.  A little ugly, but we get
away with it for now.

> And, in ppc_hash64_htab_lookup(), the HPT base is logged so we need
> some value returned (today, this is SPR_SDR1 which equals zero but 
> that's confusing I think).
> 
> 
> If you don't agree with the hpt_base() op, we can change it to
> something like :

I certainly don't agree with the definition proposed - that can return
either a guest address or a host userspace address depending on
various factors.  That's definitely not a sensible interface.

>   static inline hwaddr ppc_hash64_hpt_base(PowerPCCPU *cpu)
>   {
>   if (cpu->vhyp) {
>   /* Unused on sPAPR machines */
>   return 0;
>   }
>   return ppc_hash64_hpt_reg(cpu) & SDR_64_HTABORG;
>   }
> 
> to be consistent with the other routines. I would like to make sure we
> don't reach ppc_hash64_hpt_reg() on pseries machines. see patch 3/4.

We could do that, since this routine is basically only used for
logging / debugging, the 0 acts as just a placeholder.

The more strictly correct (but a bit more work) option would be to put
an assert(!cpu->vhyp) in there, and fix the code so that we
really don't call ppc_hash64_hpt_base() in the vhyp cases.

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device

[David Gibson]

On Tue, Mar 06, 2018 at 08:31:01PM +, Mark Cave-Ayland wrote:
> Commit 4e46dcdbd3 "PPC: Newworld: Add uninorth token register" added a TODO
> which was to convert the uninorth registers hack to a proper device. Move
> these registers to a new uninorth device, removing the old hacks from
> mac_newworld.c.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/pci-host/trace-events   |  2 ++
>  hw/pci-host/uninorth.c | 58 
> ++
>  hw/ppc/mac_newworld.c  | 41 +
>  hw/ppc/trace-events|  4 ---
>  include/hw/pci-host/uninorth.h | 11 
>  5 files changed, 77 insertions(+), 39 deletions(-)
> 
> diff --git a/hw/pci-host/trace-events b/hw/pci-host/trace-events
> index 341a87a702..dd7a398e96 100644
> --- a/hw/pci-host/trace-events
> +++ b/hw/pci-host/trace-events
> @@ -18,3 +18,5 @@ unin_set_irq(int irq_num, int level) "setting INT %d = %d"
>  unin_get_config_reg(uint32_t reg, uint32_t addr, uint32_t retval) "converted 
> config space accessor 0x%"PRIx32 "/0x%"PRIx32 " -> 0x%"PRIx32
>  unin_data_write(uint64_t addr, unsigned len, uint64_t val) "write addr 
> 0x%"PRIx64 " len %d val 0x%"PRIx64
>  unin_data_read(uint64_t addr, unsigned len, uint64_t val) "read addr 
> 0x%"PRIx64 " len %d val 0x%"PRIx64
> +unin_write(uint64_t addr, uint64_t value) "addr=0x%" PRIx64 " val=0x%"PRIx64
> +unin_read(uint64_t addr, uint64_t value) "addr=0x%" PRIx64 " val=0x%"PRIx64
> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c
> index fada0ffd5f..dbfad01d9d 100644
> --- a/hw/pci-host/uninorth.c
> +++ b/hw/pci-host/uninorth.c
> @@ -519,6 +519,62 @@ static const TypeInfo pci_unin_internal_info = {
>  .class_init= pci_unin_internal_class_init,
>  };
>  
> +/* UniN device */
> +static void unin_write(void *opaque, hwaddr addr, uint64_t value,
> +   unsigned size)
> +{
> +trace_unin_write(addr, value);
> +if (addr == 0x0) {
> +*(int *)opaque = value;
> +}
> +}
> +
> +static uint64_t unin_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +uint32_t value;
> +
> +value = 0;
> +switch (addr) {
> +case 0:
> +value = *(int *)opaque;
> +}
> +
> +trace_unin_read(addr, value);
> +
> +return value;
> +}
> +
> +static const MemoryRegionOps unin_ops = {
> +.read = unin_read,
> +.write = unin_write,
> +.endianness = DEVICE_NATIVE_ENDIAN,

DEVICE_NATIVE_ENDIAN is almost always wrong.  I'm pretty sure it
should be DEVICE_BIG_ENDIAN.  I realize this is just a code motion,
but while you're making a proper device of it, you might as well fix
this to.

> +};
> +
> +static void unin_init(Object *obj)
> +{
> +UNINState *s = UNI_NORTH(obj);
> +SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
> +
> +memory_region_init_io(>mem, obj, _ops, >token, "unin", 
> 0x1000);
> +
> +sysbus_init_mmio(sbd, >mem);
> +}
> +
> +static void unin_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
> +}
> +
> +static const TypeInfo unin_info = {
> +.name  = TYPE_UNI_NORTH,
> +.parent= TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(UNINState),
> +.instance_init = unin_init,
> +.class_init= unin_class_init,
> +};
> +
>  static void unin_register_types(void)
>  {
>  type_register_static(_main_pci_host_info);
> @@ -530,6 +586,8 @@ static void unin_register_types(void)
>  type_register_static(_u3_agp_info);
>  type_register_static(_unin_agp_info);
>  type_register_static(_unin_internal_info);
> +
> +type_register_static(_info);
>  }
>  
>  type_init(unin_register_types)
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index ae0de4e36e..2fcb101982 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -83,36 +83,6 @@
>  
>  #define NDRV_VGA_FILENAME "qemu_vga.ndrv"
>  
> -/* UniN device */
> -static void unin_write(void *opaque, hwaddr addr, uint64_t value,
> -   unsigned size)
> -{
> -trace_mac99_uninorth_write(addr, value);
> -if (addr == 0x0) {
> -*(int*)opaque = value;
> -}
> -}
> -
> -static uint64_t unin_read(void *opaque, hwaddr addr, unsigned size)
> -{
> -uint32_t value;
> -
> -value = 0;
> -switch (addr) {
> -case 0:
> -value = *(int*)opaque;
> -}
> -
> -trace_mac99_uninorth_read(addr, value);
> -
> -return value;
> -}
> -
> -static const MemoryRegionOps unin_ops = {
> -.read = unin_read,
> -.write = unin_write,
> -.endianness = DEVICE_NATIVE_ENDIAN,
> -};
>  
>  static void fw_cfg_boot_set(void *opaque, const char *boot_device,
>  Error **errp)
> @@ -146,7 +116,6 @@ static void ppc_core99_init(MachineState *machine)
>  CPUPPCState *env = NULL;
>  char *filename;
>  qemu_irq *pic, **openpic_irqs;
> -

Re: [Qemu-devel] [PATCH v3 2/4] target/ppc: add basic support for PTCR on POWER9

[David Gibson]

On Thu, Mar 15, 2018 at 01:34:00PM +, Cédric Le Goater wrote:
> The Partition Table Control Register (PTCR) is a hypervisor privileged
> SPR. It contains the host real address of the Partition Table and its
> size.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
> 
>  Changes since v2:
> 
>  - added an assert on MMU model in ppc_store_ptcr()
>  - renamed s/ptas/patbsize/
>  
>  Changes since v1:
> 
>  - renamed partition table definitions to match ISA
>  - moved definitions under mmu-book3s-v3.h
> 
>  target/ppc/cpu.h|  2 ++
>  target/ppc/helper.h |  1 +
>  target/ppc/misc_helper.c| 12 
>  target/ppc/mmu-book3s-v3.h  |  6 ++
>  target/ppc/mmu_helper.c | 29 +
>  target/ppc/translate.c  |  3 +++
>  target/ppc/translate_init.c | 18 ++
>  7 files changed, 71 insertions(+)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 4de0653a3984..7e900cf86a5f 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1314,6 +1314,7 @@ int ppc_cpu_handle_mmu_fault(CPUState *cpu, vaddr 
> address, int size, int rw,
>  
>  #if !defined(CONFIG_USER_ONLY)
>  void ppc_store_sdr1 (CPUPPCState *env, target_ulong value);
> +void ppc_store_ptcr(CPUPPCState *env, target_ulong value);
>  #endif /* !defined(CONFIG_USER_ONLY) */
>  void ppc_store_msr (CPUPPCState *env, target_ulong value);
>  
> @@ -1605,6 +1606,7 @@ void ppc_compat_add_property(Object *obj, const char 
> *name,
>  #define SPR_BOOKE_GIVOR13 (0x1BC)
>  #define SPR_BOOKE_GIVOR14 (0x1BD)
>  #define SPR_TIR   (0x1BE)
> +#define SPR_PTCR  (0x1D0)
>  #define SPR_BOOKE_SPEFSCR (0x200)
>  #define SPR_Exxx_BBEAR(0x201)
>  #define SPR_Exxx_BBTAR(0x202)
> diff --git a/target/ppc/helper.h b/target/ppc/helper.h
> index 5b739179b8b5..19453c68138a 100644
> --- a/target/ppc/helper.h
> +++ b/target/ppc/helper.h
> @@ -709,6 +709,7 @@ DEF_HELPER_FLAGS_1(load_601_rtcu, TCG_CALL_NO_RWG, tl, 
> env)
>  #if !defined(CONFIG_USER_ONLY)
>  #if defined(TARGET_PPC64)
>  DEF_HELPER_FLAGS_1(load_purr, TCG_CALL_NO_RWG, tl, env)
> +DEF_HELPER_2(store_ptcr, void, env, tl)
>  #endif
>  DEF_HELPER_2(store_sdr1, void, env, tl)
>  DEF_HELPER_2(store_pidr, void, env, tl)
> diff --git a/target/ppc/misc_helper.c b/target/ppc/misc_helper.c
> index 0e4217821b8e..8c8cba5cc6f1 100644
> --- a/target/ppc/misc_helper.c
> +++ b/target/ppc/misc_helper.c
> @@ -88,6 +88,18 @@ void helper_store_sdr1(CPUPPCState *env, target_ulong val)
>  }
>  }
>  
> +#if defined(TARGET_PPC64)
> +void helper_store_ptcr(CPUPPCState *env, target_ulong val)
> +{
> +PowerPCCPU *cpu = ppc_env_get_cpu(env);
> +
> +if (env->spr[SPR_PTCR] != val) {
> +ppc_store_ptcr(env, val);
> +tlb_flush(CPU(cpu));
> +}
> +}
> +#endif /* defined(TARGET_PPC64) */
> +
>  void helper_store_pidr(CPUPPCState *env, target_ulong val)
>  {
>  PowerPCCPU *cpu = ppc_env_get_cpu(env);
> diff --git a/target/ppc/mmu-book3s-v3.h b/target/ppc/mmu-book3s-v3.h
> index 56095dab522c..fdf80987d7b2 100644
> --- a/target/ppc/mmu-book3s-v3.h
> +++ b/target/ppc/mmu-book3s-v3.h
> @@ -22,6 +22,12 @@
>  
>  #ifndef CONFIG_USER_ONLY
>  
> +/*
> + * Partition table definitions
> + */
> +#define PTCR_PATB   0x0000ULL /* Partition Table 
> Base */
> +#define PTCR_PATS   0x001FULL /* Partition Table 
> Size */
> +
>  /* Partition Table Entry Fields */
>  #define PATBE1_GR 0x8000
>  
> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
> index 5568d1642b34..03009eee723a 100644
> --- a/target/ppc/mmu_helper.c
> +++ b/target/ppc/mmu_helper.c
> @@ -2028,6 +2028,35 @@ void ppc_store_sdr1(CPUPPCState *env, target_ulong 
> value)
>  env->spr[SPR_SDR1] = value;
>  }
>  
> +#if defined(TARGET_PPC64)
> +void ppc_store_ptcr(CPUPPCState *env, target_ulong value)
> +{
> +PowerPCCPU *cpu = ppc_env_get_cpu(env);
> +target_ulong ptcr_mask = PTCR_PATB | PTCR_PATS;
> +target_ulong patbsize = value & PTCR_PATS;
> +
> +qemu_log_mask(CPU_LOG_MMU, "%s: " TARGET_FMT_lx "\n", __func__, value);
> +
> +assert(!cpu->vhyp);
> +assert(env->mmu_model & POWERPC_MMU_V3);
> +
> +if (value & ~ptcr_mask) {
> +error_report("Invalid bits 0x"TARGET_FMT_lx" set in PTCR",
> + value & ~ptcr_mask);
> +value &= ptcr_mask;
> +}
> +
> +if (patbsize > 24) {
> +error_report("Invalid Partition Table size 0x" TARGET_FMT_lx
> + " stored in PTCR", patbsize);
> +return;
> +}
> +
> +env->spr[SPR_PTCR] = value;
> +}
> +
> +#endif /* defined(TARGET_PPC64) */
> +
>  /* Segment registers load and store */
>  target_ulong helper_load_sr(CPUPPCState *env, target_ulong sr_num)
>  {
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 218665b4080b..172fbf35ae53 100644
> --- 

Re: [Qemu-devel] [PATCH] chardev-socket: remove useless if

[Peter Xu]

On Tue, Mar 20, 2018 at 04:18:57PM +0100, Paolo Bonzini wrote:
> This trips Coverity, which believes the subsequent qio_channel_create_watch
> can dereference a NULL pointer.  In reality, tcp_chr_connect's callers
> all have s->ioc properly initialized, since they are all rooted at
> tcp_chr_new_client.
> 
> Signed-off-by: Paolo Bonzini 

(maybe replacing with an assertion would be nicer? No big deal.)

Reviewed-by: Peter Xu 

-- 
Peter Xu

[Qemu-devel] [PATCH] vhost: add trace for IOTLB miss

[Peter Xu]

Add some trace points for IOTLB translation for vhost. After vhost-user
is setup, the only IO path that QEMU will participate should be the
IOMMU translation, so it'll be good we can track this with explicit
timestamps when needed to see how long time we take to do the
translation, and whether there's anything stuck inside.  It might be
useful for triaging vhost-user problems.

Signed-off-by: Peter Xu 
---
 hw/virtio/trace-events | 1 +
 hw/virtio/vhost.c  | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 742ff0f90b..933eaab133 100644
--- a/hw/virtio/trace-events
+++ b/hw/virtio/trace-events
@@ -5,6 +5,7 @@ vhost_commit(bool started, bool changed) "Started: %d Changed: 
%d"
 vhost_region_add_section(const char *name, uint64_t gpa, uint64_t size, 
uint64_t host) "%s: 0x%"PRIx64"+0x%"PRIx64" @ 0x%"PRIx64
 vhost_region_add_section_abut(const char *name, uint64_t new_size) "%s: 
0x%"PRIx64
 vhost_section(const char *name, int r) "%s:%d"
+vhost_iotlb_miss(void *dev, int step) "%p step %d"
 
 # hw/virtio/virtio.c
 virtqueue_alloc_element(void *elem, size_t sz, unsigned in_num, unsigned 
out_num) "elem %p size %zd in_num %u out_num %u"
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index d8d0ef92e1..aa68f79510 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -839,12 +839,15 @@ int vhost_device_iotlb_miss(struct vhost_dev *dev, 
uint64_t iova, int write)
 
 rcu_read_lock();
 
+trace_vhost_iotlb_miss(dev, 1);
+
 iotlb = address_space_get_iotlb_entry(dev->vdev->dma_as,
   iova, write);
 if (iotlb.target_as != NULL) {
 ret = vhost_memory_region_lookup(dev, iotlb.translated_addr,
  , );
 if (ret) {
+trace_vhost_iotlb_miss(dev, 3);
 error_report("Fail to lookup the translated address "
  "%"PRIx64, iotlb.translated_addr);
 goto out;
@@ -856,10 +859,14 @@ int vhost_device_iotlb_miss(struct vhost_dev *dev, 
uint64_t iova, int write)
 ret = vhost_backend_update_device_iotlb(dev, iova, uaddr,
 len, iotlb.perm);
 if (ret) {
+trace_vhost_iotlb_miss(dev, 4);
 error_report("Fail to update device iotlb");
 goto out;
 }
 }
+
+trace_vhost_iotlb_miss(dev, 2);
+
 out:
 rcu_read_unlock();
 
-- 
2.14.3

Re: [Qemu-devel] [Qemu-block] [PATCH v1 1/1] iotests: fix test case 185

[QingFeng Hao]

在 2018/3/21 11:12, QingFeng Hao 写道:



在 2018/3/20 22:31, Stefan Hajnoczi 写道:

On Tue, Mar 20, 2018 at 11:11:01AM +0100, Kevin Wolf wrote:

Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:



On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:
On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao 
 wrote:
Test case 185 failed since commit 4486e89c219 --- "vl: introduce 
vm_shutdown()".
It's because of the newly introduced function vm_shutdown calls 
bdrv_drain_all,
which is called later by bdrv_close_all. bdrv_drain_all resumes 
the jobs

that doubles the speed and offset is doubled.
Some jobs' status are changed as well.

Thus, let's not call bdrv_drain_all in vm_shutdown.

Signed-off-by: QingFeng Hao 
---
  cpus.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cpus.c b/cpus.c
index 2e6701795b..ae2962508c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1006,8 +1006,9 @@ static int do_vm_stop(RunState state, bool 
send_stop)

  qapi_event_send_stop(_abort);
  }
  }
-
-    bdrv_drain_all();
+    if (send_stop) {
+    bdrv_drain_all();
+    }


Thanks for looking into this bug!

This if statement breaks the contract of the function when send_stop
is false.  Drain ensures that pending I/O completes and that device
emulation finishes before this function returns.  This is important
for live migration, where there must be no more guest-related activity
after vm_stop().

This patch relies on the caller invoking bdrv_close_all() immediately
after do_vm_stop(), which is not documented and could lead to more
bugs in the future.

I suggest a different solution:

Test 185 relies on internal QEMU behavior which can change from time
to time.  Buffer sizes and block job iteration counts are
implementation details that are not part of qapi-schema.json or other
documented behavior.

In fact, the existing test case was already broken in IOThread mode
since iothread_stop_all() -> bdrv_set_aio_context() also includes a
bdrv_drain() with the side-effect of an extra blockjob iteration.

After 4486e89c219 ("vl: introduce vm_shutdown()") both IOThread and
non-IOThread mode perform the drain.  This has caused the test
failure.

Instead of modifying QEMU to keep the same arbitrary internal behavior
as before, please send a patch that updates tests/qemu-iotests/185.out
with the latest output.


Wouldnt it be better if the test actually masks out the values the 
are not
really part of the "agreed upon" behaviour? Wouldnt block_job_offset 
from

common.filter be what we want?


The test case has the following note:

# Note that the reference output intentionally includes the 'offset' 
field in
# BLOCK_JOB_CANCELLED events for all of the following block jobs. 
They are
# predictable and any change in the offsets would hint at a bug in 
the job

# throttling code.

Now the question is if this particular change is okay rather than
hinting at a bug and we should update the reference output or whether we
need to change qemu again.

I think the change isn't really bad, but we are doing more useless work
now than we used to do before, and we're exiting slower because we're
spawning additional I/O that we have to wait for. So the better state
was certainly the old one.


Here is the reason for the additional I/O and how it could be
eliminated:

child_job_drained_begin() pauses and child_job_drained_end() resumes the
job.  Resuming the job cancels the timer (if pending) and enters the
blockjob's coroutine.  This is why draining BlockDriverState forces an
extra iteration of the blockjob.

The current behavior is intended for the case where the job has I/O
pending at child_job_drained_begin() time.  When the I/O completes, the
job will see it must pause and it will yield at a pause point.  It makes
sense for child_job_drained_end() to resume the job so it can start I/O
again.

In our case this behavior doesn't make sense though.  The job already
yielded before child_job_drained_begin() and it doesn't need to resume
at child_job_drained_end() time.  We'd prefer to wait for the timer
expiry.
Thanks for all of your good comments! I think the better way is to 
filter out this case but I am sure if this is a proper way to do it that
adds a yielded field in struct BlockJob to record if it's yielded by 
block_job_do_yield. However, this way can only solve the offset problem 
but not the status. Maybe we need also to change 185.out? I am bit 
confused. thanks
What I did is setting job->yielded in block_job_do_yield and adding the 
check for it in block_job_pause and block_job_resume that if yielded is

true, just return.


We need to distinguish these two cases to avoid resuming the job in the
latter case.  I think this would be the proper way to avoid unnecessary
blockjob activity across drain.

I favor updating the test output though, because the code change adds
complexity and the practical benefit is not obvious to me.

QingFeng, if you decide to 

Re: [Qemu-devel] [Qemu-block] [PATCH v1 1/1] iotests: fix test case 185

[QingFeng Hao]

在 2018/3/20 22:31, Stefan Hajnoczi 写道:

On Tue, Mar 20, 2018 at 11:11:01AM +0100, Kevin Wolf wrote:

Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:



On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:

On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao  wrote:

Test case 185 failed since commit 4486e89c219 --- "vl: introduce vm_shutdown()".
It's because of the newly introduced function vm_shutdown calls bdrv_drain_all,
which is called later by bdrv_close_all. bdrv_drain_all resumes the jobs
that doubles the speed and offset is doubled.
Some jobs' status are changed as well.

Thus, let's not call bdrv_drain_all in vm_shutdown.

Signed-off-by: QingFeng Hao 
---
  cpus.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cpus.c b/cpus.c
index 2e6701795b..ae2962508c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1006,8 +1006,9 @@ static int do_vm_stop(RunState state, bool send_stop)
  qapi_event_send_stop(_abort);
  }
  }
-
-bdrv_drain_all();
+if (send_stop) {
+bdrv_drain_all();
+}


Thanks for looking into this bug!

This if statement breaks the contract of the function when send_stop
is false.  Drain ensures that pending I/O completes and that device
emulation finishes before this function returns.  This is important
for live migration, where there must be no more guest-related activity
after vm_stop().

This patch relies on the caller invoking bdrv_close_all() immediately
after do_vm_stop(), which is not documented and could lead to more
bugs in the future.

I suggest a different solution:

Test 185 relies on internal QEMU behavior which can change from time
to time.  Buffer sizes and block job iteration counts are
implementation details that are not part of qapi-schema.json or other
documented behavior.

In fact, the existing test case was already broken in IOThread mode
since iothread_stop_all() -> bdrv_set_aio_context() also includes a
bdrv_drain() with the side-effect of an extra blockjob iteration.

After 4486e89c219 ("vl: introduce vm_shutdown()") both IOThread and
non-IOThread mode perform the drain.  This has caused the test
failure.

Instead of modifying QEMU to keep the same arbitrary internal behavior
as before, please send a patch that updates tests/qemu-iotests/185.out
with the latest output.


Wouldnt it be better if the test actually masks out the values the are not
really part of the "agreed upon" behaviour? Wouldnt block_job_offset from
common.filter be what we want?


The test case has the following note:

# Note that the reference output intentionally includes the 'offset' field in
# BLOCK_JOB_CANCELLED events for all of the following block jobs. They are
# predictable and any change in the offsets would hint at a bug in the job
# throttling code.

Now the question is if this particular change is okay rather than
hinting at a bug and we should update the reference output or whether we
need to change qemu again.

I think the change isn't really bad, but we are doing more useless work
now than we used to do before, and we're exiting slower because we're
spawning additional I/O that we have to wait for. So the better state
was certainly the old one.


Here is the reason for the additional I/O and how it could be
eliminated:

child_job_drained_begin() pauses and child_job_drained_end() resumes the
job.  Resuming the job cancels the timer (if pending) and enters the
blockjob's coroutine.  This is why draining BlockDriverState forces an
extra iteration of the blockjob.

The current behavior is intended for the case where the job has I/O
pending at child_job_drained_begin() time.  When the I/O completes, the
job will see it must pause and it will yield at a pause point.  It makes
sense for child_job_drained_end() to resume the job so it can start I/O
again.

In our case this behavior doesn't make sense though.  The job already
yielded before child_job_drained_begin() and it doesn't need to resume
at child_job_drained_end() time.  We'd prefer to wait for the timer
expiry.
Thanks for all of your good comments! I think the better way is to 
filter out this case but I am sure if this is a proper way to do it that
adds a yielded field in struct BlockJob to record if it's yielded by 
block_job_do_yield. However, this way can only solve the offset problem 
but not the status. Maybe we need also to change 185.out? I am bit 
confused. thanks


We need to distinguish these two cases to avoid resuming the job in the
latter case.  I think this would be the proper way to avoid unnecessary
blockjob activity across drain.

I favor updating the test output though, because the code change adds
complexity and the practical benefit is not obvious to me.

QingFeng, if you decide to modify blockjobs, please CC Jeffrey Cody
 and I'd also be happy to review the patch

Stefan



--
Regards
QingFeng Hao

Re: [Qemu-devel] [PATCH] postcopy-ram: add a stub for postcopy_request_shared_page

[Fam Zheng]

On Wed, 03/21 04:03, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 09:25:30AM +0800, Fam Zheng wrote:
> > On Tue, 03/20 12:34, no-re...@patchew.org wrote:
> > > /tmp/qemu-test/src/migration/postcopy-ram.c:787:41: error: 'struct 
> > > PostCopyFD' declared inside parameter list will not be visible outside of 
> > > this definition or declaration [-Werror]
> > >  int postcopy_request_shared_page(struct PostCopyFD *pcfd, RAMBlock *rb,
> > >  ^~
> > > /tmp/qemu-test/src/migration/postcopy-ram.c:787:5: error: no previous 
> > > prototype for 'postcopy_request_shared_page' [-Werror=missing-prototypes]
> > >  int postcopy_request_shared_page(struct PostCopyFD *pcfd, RAMBlock *rb,
> > >  ^~~~
> > > cc1: all warnings being treated as errors
> > 
> > Is a "#include ..." line missing?
> > 
> > Fam
> 
> This patch isn't against mainline.

OK! BTW there is a syntax for patchew to attempt a different base than master:

Based-on: 

Re: [Qemu-devel] [PATCH for-2.12] rdma: Fix 32-bit compilation

[Fam Zheng]

On Tue, 03/20 12:30, Marcel Apfelbaum wrote:
> Hi Eric,
> 
> On 19/03/2018 23:53, Eric Blake wrote:
> > Use the correct printf formats, so that a 32-bit compile doesn't
> > spit out lots of warnings about %lx being incompatible with uint64_t.
> > Broken since initial commit ef6d4ccd.
> > 
> > Signed-off-by: Eric Blake 
> > ---
> > 
> > I don't know if 'make vm-build-ubuntu.i368' would catch this (it failed
> > for me for other reasons); I found it via a 32-bit rawhide VM.
> > 
> 
> I couldn't run 'make vm-build-ubuntu.i368' either. (Stuck on "Booting from 
> Hard Disk...")

I tried this now and it works for me. Could you delete "$HOME/.cache/qemu-vm"
and do it again from a git tree, then pastbin the full log?

Fam

Re: [Qemu-devel] [PATCH] postcopy-ram: add a stub for postcopy_request_shared_page

[Michael S. Tsirkin]

On Wed, Mar 21, 2018 at 09:25:30AM +0800, Fam Zheng wrote:
> On Tue, 03/20 12:34, no-re...@patchew.org wrote:
> > /tmp/qemu-test/src/migration/postcopy-ram.c:787:41: error: 'struct 
> > PostCopyFD' declared inside parameter list will not be visible outside of 
> > this definition or declaration [-Werror]
> >  int postcopy_request_shared_page(struct PostCopyFD *pcfd, RAMBlock *rb,
> >  ^~
> > /tmp/qemu-test/src/migration/postcopy-ram.c:787:5: error: no previous 
> > prototype for 'postcopy_request_shared_page' [-Werror=missing-prototypes]
> >  int postcopy_request_shared_page(struct PostCopyFD *pcfd, RAMBlock *rb,
> >  ^~~~
> > cc1: all warnings being treated as errors
> 
> Is a "#include ..." line missing?
> 
> Fam

This patch isn't against mainline.

Re: [Qemu-devel] [PATCH for-2.12] rdma: Fix 32-bit compilation

[Fam Zheng]

On Tue, 03/20 12:30, Marcel Apfelbaum wrote:
> Hi Eric,
> 
> On 19/03/2018 23:53, Eric Blake wrote:
> > Use the correct printf formats, so that a 32-bit compile doesn't
> > spit out lots of warnings about %lx being incompatible with uint64_t.
> > Broken since initial commit ef6d4ccd.
> > 
> > Signed-off-by: Eric Blake 
> > ---
> > 
> > I don't know if 'make vm-build-ubuntu.i368' would catch this (it failed
> > for me for other reasons); I found it via a 32-bit rawhide VM.
> > 
> 
> I couldn't run 'make vm-build-ubuntu.i368' either. (Stuck on "Booting from 
> Hard Disk...")
> 
> I run make docker-test-build@debian-win32-cross to be sure it compiles on 
> 32bit arch,
> however I found out the docker configuration results in 'RDMA support no', so 
> it will not help.

Cc'ing Phil and Alex who know this image better than me. Meanwhile I'll take a
look at why make vm-build-ubuntu.i386 is broken. Thanks.

Fam

Re: [Qemu-devel] [PATCH] postcopy-ram: add a stub for postcopy_request_shared_page

[Fam Zheng]

On Tue, 03/20 12:34, no-re...@patchew.org wrote:
> /tmp/qemu-test/src/migration/postcopy-ram.c:787:41: error: 'struct 
> PostCopyFD' declared inside parameter list will not be visible outside of 
> this definition or declaration [-Werror]
>  int postcopy_request_shared_page(struct PostCopyFD *pcfd, RAMBlock *rb,
>  ^~
> /tmp/qemu-test/src/migration/postcopy-ram.c:787:5: error: no previous 
> prototype for 'postcopy_request_shared_page' [-Werror=missing-prototypes]
>  int postcopy_request_shared_page(struct PostCopyFD *pcfd, RAMBlock *rb,
>  ^~~~
> cc1: all warnings being treated as errors

Is a "#include ..." line missing?

Fam

Re: [Qemu-devel] [PATCH 4/5] atapi: call ide_set_irq before ide_transfer_start

[John Snow]

On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> The ATAPI_INT_REASON_IO interrupt is raised when I/O starts, but in the
> AHCI case ide_set_irq was actually called at the end of a mutual recursion.
> Move it early, with the side effect that ide_transfer_start becomes a tail
> call in ide_atapi_cmd_reply_end.
> 

Do you know in which spec it specifies that we should interrupt?

Seems okay, but I wanted to double check the wording in the spec (was
looking in scsi MMC and ATA8) and couldn't find it quickly.

> Signed-off-by: Paolo Bonzini 
> ---
>  hw/ide/atapi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
> index c0509c8bf5..be99a929cf 100644
> --- a/hw/ide/atapi.c
> +++ b/hw/ide/atapi.c
> @@ -287,6 +287,7 @@ void ide_atapi_cmd_reply_end(IDEState *s)
>  } else {
>  /* a new transfer is needed */
>  s->nsector = (s->nsector & ~7) | ATAPI_INT_REASON_IO;
> +ide_set_irq(s->bus);
>  byte_count_limit = atapi_byte_count_limit(s);
>  trace_ide_atapi_cmd_reply_end_bcl(s, byte_count_limit);
>  size = s->packet_transfer_size;
> @@ -307,10 +308,9 @@ void ide_atapi_cmd_reply_end(IDEState *s)
>  s->packet_transfer_size -= size;
>  s->elementary_transfer_size -= size;
>  s->io_buffer_index += size;
> +trace_ide_atapi_cmd_reply_end_new(s, s->status);
>  ide_transfer_start(s, s->io_buffer + s->io_buffer_index - size,
> size, ide_atapi_cmd_reply_end);
> -ide_set_irq(s->bus);
> -trace_ide_atapi_cmd_reply_end_new(s, s->status);
>  }
>  }
>  }
> 

Re: [Qemu-devel] [PULL 00/25] RISC-V Post-merge spec conformance and cleanup

[Michael Clark]

I had the branch all set up and ready for a PR, including the tag message,
but after dropping the riscv_isa_string fix I noticed it was still in the
tag blurb for the series. I don't think it is worth re-tagging the PR to
add a note that we dropped the change from the series.

These are pretty much all bug fixes that we have had in the riscv tree
since the v8.2 PR from March 8th, although now they all have sign-offs and
all outstanding review feedback has been addressed.

Besides printing hex in the disassembler, this series contains bug fixes
and code cleanup, although printing hex in the disassembler was used for
debugging, so it could be considered a meta bug-fix.

On Tue, Mar 20, 2018 at 3:25 PM, Michael Clark  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The following changes since commit f1a63fcfcd92c88be8942b5ae71aef
> 9749a4f135:
>
>   Update version for v2.12.0-rc0 release (2018-03-20 19:04:22 +)
>
> are available in the git repository at:
>
>   https://github.com/riscv/riscv-qemu.git tags/riscv-qemu-2.12-fixes
>
> for you to fetch changes up to e1a247183ac0816284dfda61423f7030b6686679:
>
>   RISC-V: Remove erroneous comment from translate.c (2018-03-20 14:34:13
> -0700)
>
> - 
> This is a series of spec conformance bug fixes and code cleanups
> that we would like to get in before the QEMU 2.12 release.
>
> * Implements WARL behavior for CSRs that don't support writes
> * Improves specification conformance of the page table walker
>   * Change access checks from ternary operator to if statements
>   * Checks for misaligned PPNs
>   * Disallow M-mode or S-mode from fetching from User pages
>   * Adds reserved PTE flag check: W or W|X
>   * Set READ flag for PTE X flag if mstatus.mxr is in effect
>   * Improves page walker comments and general readability
> * Several trivial code cleanups to hw/riscv
>   * Replacing hard coded constants with reference to enums
> or the machine memory maps.
>   * Remove unnecessary class initialization boilerplate
> * Adds bounds checks when writing device-tree to ROM
> * Updates the cpu model to use a more modern interface
> * Sets mtval/stval to zero on exceptions without addresses
> * Fixes memory allocation bug in riscv_isa_string
>
> v4
>
> * added fix for memory allocation bug in riscv_isa_string
>
> v3
>
> * refactor rcu_read_lock in PTE update to use single unlock
> * mstatus.mxr is in effect regardless of privilege mode
> * remove unnecessary class init from riscv_hart
> * set mtval/stval to zero on exceptions without addresses
>
> v2
>
> * remove unused class boilerplate retains qom parent_obj
> * convert cpu definition towards future model
> * honor mstatus.mxr flag in page table walker
>
> v1
>
> * initial post merge cleanup patch series
>
> - 
> Michael Clark (25):
>   RISC-V: Make virt create_fdt interface consistent
>   RISC-V: Replace hardcoded constants with enum values
>   RISC-V: Make virt board description match spike
>   RISC-V: Use ROM base address and size from memmap
>   RISC-V: Remove identity_translate from load_elf
>   RISC-V: Mark ROM read-only after copying in code
>   RISC-V: Remove unused class definitions
>   RISC-V: Make sure rom has space for fdt
>   RISC-V: Include intruction hex in disassembly
>   RISC-V: Hold rcu_read_lock when accessing memory
>   RISC-V: Improve page table walker spec compliance
>   RISC-V: Update E order and I extension order
>   RISC-V: Make some header guards more specific
>   RISC-V: Make virt header comment title consistent
>   RISC-V: Use memory_region_is_ram in pte update
>   RISC-V: Remove EM_RISCV ELF_MACHINE indirection
>   RISC-V: Hardwire satp to 0 for no-mmu case
>   RISC-V: Remove braces from satp case statement
>   RISC-V: riscv-qemu port supports sv39 and sv48
>   RISC-V: vectored traps are optional
>   RISC-V: No traps on writes to misa,minstret,mcycle
>   RISC-V: Remove support for adhoc X_COP interrupt
>   RISC-V: Convert cpu definition towards future model
>   RISC-V: Clear mtval/stval on exceptions without info
>   RISC-V: Remove erroneous comment from translate.c
>
>  disas/riscv.c   |  39 +++--
>  hw/riscv/riscv_hart.c   |   6 --
>  hw/riscv/sifive_clint.c |   9 +--
>  hw/riscv/sifive_e.c |  34 +--
>  hw/riscv/sifive_u.c |  65 +++--
>  hw/riscv/spike.c|  65 -
>  hw/riscv/virt.c |  77 +
>  include/hw/riscv/sifive_clint.h |   4 ++
>  include/hw/riscv/sifive_e.h |   5 --
>  include/hw/riscv/sifive_u.h |   9 ++-
>  include/hw/riscv/spike.h|  15 ++---
>  include/hw/riscv/virt.h |  17 +++---
>  target/riscv/cpu.c  | 125 

[Qemu-devel] Monitor and serial output window broken with SDL2

[BALATON Zoltan]

Hello,

With SDL2 the monitor and serial output windows behave differently than 
they used to with SDL1.2 in that they are opening in separate windows. 
This is an unexpected change we've discussed before but other than this 
there are actual bugs with SDL2:


1. Scrollback does not work. With SDL1.2 it is possible to scroll the 
monitor (and maybe other output windows as well, I'm not sure about that) 
with Ctrl+PgUp/PgDn but this does not work with SDL2. Without this the 
small monitor window is not really usable.


2. With at least qemu-system-ppc the serial and parallel output are not 
accessible (Ctrl+Alt+3 opens an empty window and Ctrl+Alt+4 does nothing) 
while the serial output seems to be behind the monitor output in the 
window opening with Ctrl+Alt+2 and flashes when I type in this window. 
(This doesn't seem to happen with qemu-system-x86_64, maybe that's why it 
was not catched.)


Could these be fixed please to make SDL2 a viable alternative before 
deprecating SDL1.2?


Thank you,
BALATON Zoltan

[Qemu-devel] [PULL 00/25] RISC-V Post-merge spec conformance and cleanup

[Michael Clark]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The following changes since commit f1a63fcfcd92c88be8942b5ae71aef9749a4f135:

  Update version for v2.12.0-rc0 release (2018-03-20 19:04:22 +)

are available in the git repository at:

  https://github.com/riscv/riscv-qemu.git tags/riscv-qemu-2.12-fixes

for you to fetch changes up to e1a247183ac0816284dfda61423f7030b6686679:

  RISC-V: Remove erroneous comment from translate.c (2018-03-20 14:34:13 -0700)

- 
This is a series of spec conformance bug fixes and code cleanups
that we would like to get in before the QEMU 2.12 release.

* Implements WARL behavior for CSRs that don't support writes
* Improves specification conformance of the page table walker
  * Change access checks from ternary operator to if statements
  * Checks for misaligned PPNs
  * Disallow M-mode or S-mode from fetching from User pages
  * Adds reserved PTE flag check: W or W|X
  * Set READ flag for PTE X flag if mstatus.mxr is in effect
  * Improves page walker comments and general readability
* Several trivial code cleanups to hw/riscv
  * Replacing hard coded constants with reference to enums
or the machine memory maps.
  * Remove unnecessary class initialization boilerplate
* Adds bounds checks when writing device-tree to ROM
* Updates the cpu model to use a more modern interface
* Sets mtval/stval to zero on exceptions without addresses
* Fixes memory allocation bug in riscv_isa_string

v4

* added fix for memory allocation bug in riscv_isa_string

v3

* refactor rcu_read_lock in PTE update to use single unlock
* mstatus.mxr is in effect regardless of privilege mode
* remove unnecessary class init from riscv_hart
* set mtval/stval to zero on exceptions without addresses

v2

* remove unused class boilerplate retains qom parent_obj
* convert cpu definition towards future model
* honor mstatus.mxr flag in page table walker

v1

* initial post merge cleanup patch series

- 
Michael Clark (25):
  RISC-V: Make virt create_fdt interface consistent
  RISC-V: Replace hardcoded constants with enum values
  RISC-V: Make virt board description match spike
  RISC-V: Use ROM base address and size from memmap
  RISC-V: Remove identity_translate from load_elf
  RISC-V: Mark ROM read-only after copying in code
  RISC-V: Remove unused class definitions
  RISC-V: Make sure rom has space for fdt
  RISC-V: Include intruction hex in disassembly
  RISC-V: Hold rcu_read_lock when accessing memory
  RISC-V: Improve page table walker spec compliance
  RISC-V: Update E order and I extension order
  RISC-V: Make some header guards more specific
  RISC-V: Make virt header comment title consistent
  RISC-V: Use memory_region_is_ram in pte update
  RISC-V: Remove EM_RISCV ELF_MACHINE indirection
  RISC-V: Hardwire satp to 0 for no-mmu case
  RISC-V: Remove braces from satp case statement
  RISC-V: riscv-qemu port supports sv39 and sv48
  RISC-V: vectored traps are optional
  RISC-V: No traps on writes to misa,minstret,mcycle
  RISC-V: Remove support for adhoc X_COP interrupt
  RISC-V: Convert cpu definition towards future model
  RISC-V: Clear mtval/stval on exceptions without info
  RISC-V: Remove erroneous comment from translate.c

 disas/riscv.c   |  39 +++--
 hw/riscv/riscv_hart.c   |   6 --
 hw/riscv/sifive_clint.c |   9 +--
 hw/riscv/sifive_e.c |  34 +--
 hw/riscv/sifive_u.c |  65 +++--
 hw/riscv/spike.c|  65 -
 hw/riscv/virt.c |  77 +
 include/hw/riscv/sifive_clint.h |   4 ++
 include/hw/riscv/sifive_e.h |   5 --
 include/hw/riscv/sifive_u.h |   9 ++-
 include/hw/riscv/spike.h|  15 ++---
 include/hw/riscv/virt.h |  17 +++---
 target/riscv/cpu.c  | 125 ++--
 target/riscv/cpu.h  |   6 +-
 target/riscv/cpu_bits.h |   3 -
 target/riscv/helper.c   |  84 ---
 target/riscv/op_helper.c|  52 -
 target/riscv/translate.c|   1 -
 18 files changed, 281 insertions(+), 335 deletions(-)
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQR8mZMOsXzYugc9Xvpr8dezV+8+TwUCWrGJWgAKCRBr8dezV+8+
Tw34AJ9QquvDTCdzOS6k2bfUvCppUaQ3KACghKuKfhjypUM7L5SM9CuvKPovfNc=
=SI2p
-END PGP SIGNATURE-

Re: [Qemu-devel] [PATCH 3/5] ide: do not set s->end_transfer_func to ide_transfer_cancel

[John Snow]

On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> There is code checking s->end_transfer_func and it was not taught
> about ide_transfer_cancel.  We can just use ide_transfer_stop because
> s->end_transfer_func is only ever called in the DRQ phase: after
> ide_transfer_cancel, the value of s->end_transfer_func is only used
> as a marker and never used to actually invoke the function.
> 

I think you're right, but I think it's also pretty non-obvious to a
reader that a callback might be used in this way.

"John, it's your component dude, why don't you fix that?"

Err, I'm afraid of disturbing the delicate balance of spaghetti code.

*cough*

Anyway, a little comment explaining that we don't actually *expect* that
callback to actually get called would probably answer a question or two
before they arise.

> Signed-off-by: Paolo Bonzini 
> ---
>  hw/ide/core.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index c4710a6f55..447d9624df 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -553,10 +553,9 @@ static void ide_cmd_done(IDEState *s)
>  }
>  }
>  
> -static void ide_transfer_halt(IDEState *s,
> -  void(*end_transfer_func)(IDEState *))
> +static void ide_transfer_halt(IDEState *s)
>  {
> -s->end_transfer_func = end_transfer_func;
> +s->end_transfer_func = ide_transfer_stop;
>  s->data_ptr = s->io_buffer;
>  s->data_end = s->io_buffer;
>  s->status &= ~DRQ_STAT;
> @@ -564,7 +563,7 @@ static void ide_transfer_halt(IDEState *s,
>  
>  void ide_transfer_stop(IDEState *s)
>  {
> -ide_transfer_halt(s, ide_transfer_stop);
> +ide_transfer_halt(s);
>  if (s->bus->dma->ops->end_transfer) {
>  s->bus->dma->ops->end_transfer(s->bus->dma);
>  }
> @@ -573,7 +572,7 @@ void ide_transfer_stop(IDEState *s)
>  
>  static void ide_transfer_cancel(IDEState *s)
>  {
> -ide_transfer_halt(s, ide_transfer_cancel);
> +ide_transfer_halt(s);
>  }
>  
>  int64_t ide_get_sector(IDEState *s)
> 

"LGTM"

Re: [Qemu-devel] [PATCH 2/5] ide: push end_transfer callback to ide_transfer_halt

[John Snow]

On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> The callback must be invoked once we get out of the DRQ phase; because
> all end_transfer_funcs end up invoking ide_transfer_stop, call it there.
> While at it, remove the "notify" argument from ide_transfer_halt; the
> code can simply be moved to ide_transfer_stop.
> 
> Old PATA controllers have no end_transfer callback, so there is no change
> there.  For AHCI the end_transfer_func already called ide_transfer_stop
> so the effect is that the PIO FIS is written before the D2H FIS rather
> than after, which is arguably an improvement.
> 

MMK, so this is the "PIO Setup FIS" which I... actually, I was never
sure what role this was supposed to play *exactly*.

"Used by the device to provide the host adapter with sufficient
information regarding a Programmed Input/Output (PIO) data phase to
allow the host adapter to efficiently handle PIO data transfers."

So in a perfect world, the SATA layer generates this *for* the AHCI
adapter, but really both of those models are smooshed into one layer for
us, so we just generate this so the host driver doesn't freak out.

"For PIO data transfers, the device shall send to the host a PIO Setup –
Device to Host FIS just before each and every data transfer FIS that is
required to complete the data transfer. Data transfers from Host to
Device as well as data transfers from Device to Host shall follow this
algorithm."

Well, we don't emulate Data FIS packets and I don't *think* those get
cached in the received FIS data structure area for the AHCI HBA, so we
just skip those.

"Because of the stringent timing constraints in the ATA Standard, the
PIO Setup FIS includes both the starting and ending status values. These
are used by the host adapter to first signal to host software readiness
for PIO write data (BSY bit is cleared to zero and DRQ bit is set to
one), and following the PIO write burst to properly signal host software
by clearing the DRQ bit to zero and possibly setting the BSY bit to one."

This part confuses me. The starting and ending status values? How would
we know the ending status value if this gets sent by the device before a
transfer?

> However, ahci_end_transfer is now called _after_ the DRQ_STAT has been
> cleared, so remove the status check in ahci_end_transfer; it was only
> there to ensure the FIS was not written more than once, and this cannot
> happen anymore.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/ide/ahci.c |  7 ++-
>  hw/ide/core.c | 15 +++
>  2 files changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 937bad55fb..c3c6843b76 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1326,12 +1326,9 @@ out:
>  static void ahci_end_transfer(IDEDMA *dma)
>  {
>  AHCIDevice *ad = DO_UPCAST(AHCIDevice, dma, dma);
> -IDEState *s = >port.ifs[0];
>  
> -if (!(s->status & DRQ_STAT)) {
> -/* done with PIO send/receive */
> -ahci_write_fis_pio(ad, le32_to_cpu(ad->cur_cmd->status));
> -}
> +/* done with PIO send/receive */
> +ahci_write_fis_pio(ad, le32_to_cpu(ad->cur_cmd->status));
>  }
>  
>  static void ahci_start_dma(IDEDMA *dma, IDEState *s,
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 92f4424dc3..c4710a6f55 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -544,7 +544,6 @@ void ide_transfer_start(IDEState *s, uint8_t *buf, int 
> size,
>  }
>  s->bus->dma->ops->start_transfer(s->bus->dma);
>  end_transfer_func(s);
> -s->bus->dma->ops->end_transfer(s->bus->dma);
>  }
>  
>  static void ide_cmd_done(IDEState *s)
> @@ -555,26 +554,26 @@ static void ide_cmd_done(IDEState *s)
>  }
>  
>  static void ide_transfer_halt(IDEState *s,
> -  void(*end_transfer_func)(IDEState *),
> -  bool notify)
> +  void(*end_transfer_func)(IDEState *))
>  {
>  s->end_transfer_func = end_transfer_func;
>  s->data_ptr = s->io_buffer;
>  s->data_end = s->io_buffer;
>  s->status &= ~DRQ_STAT;
> -if (notify) {
> -ide_cmd_done(s);
> -}
>  }
>  
>  void ide_transfer_stop(IDEState *s)
>  {
> -ide_transfer_halt(s, ide_transfer_stop, true);
> +ide_transfer_halt(s, ide_transfer_stop);
> +if (s->bus->dma->ops->end_transfer) {
> +s->bus->dma->ops->end_transfer(s->bus->dma);
> +}
> +ide_cmd_done(s);
>  }
>  
>  static void ide_transfer_cancel(IDEState *s)
>  {
> -ide_transfer_halt(s, ide_transfer_cancel, false);
> +ide_transfer_halt(s, ide_transfer_cancel);
>  }
>  
>  int64_t ide_get_sector(IDEState *s)
> 

Seems sane, with some lingering questions about what the PIO Setup FIS
is supposed to do to begin with still remaining.

Re: [Qemu-devel] [PATCH 1/5] ide: push call to end_transfer_func out of start_transfer callback

[John Snow]

On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> Split the PIO transfer across two callbacks, thus pushing the (possibly
> recursive) call to end_transfer_func up one level and out of the
> AHCI-specific code.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/ide/ahci.c | 7 ++-
>  hw/ide/core.c | 9 ++---
>  include/hw/ide/internal.h | 1 +
>  3 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index e22d7be05f..937bad55fb 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1321,8 +1321,12 @@ out:
>  
>  /* Update number of transferred bytes, destroy sglist */
>  dma_buf_commit(s, size);
> +}
>  
> -s->end_transfer_func(s);
> +static void ahci_end_transfer(IDEDMA *dma)
> +{
> +AHCIDevice *ad = DO_UPCAST(AHCIDevice, dma, dma);
> +IDEState *s = >port.ifs[0];
>  
>  if (!(s->status & DRQ_STAT)) {
>  /* done with PIO send/receive */
> @@ -1444,6 +1448,7 @@ static const IDEDMAOps ahci_dma_ops = {
>  .restart = ahci_restart,
>  .restart_dma = ahci_restart_dma,
>  .start_transfer = ahci_start_transfer,
> +.end_transfer = ahci_end_transfer,
>  .prepare_buf = ahci_dma_prepare_buf,
>  .commit_buf = ahci_commit_buf,
>  .rw_buf = ahci_dma_rw_buf,
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 257b429381..92f4424dc3 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -532,16 +532,19 @@ static void ide_clear_retry(IDEState *s)
>  void ide_transfer_start(IDEState *s, uint8_t *buf, int size,
>  EndTransferFunc *end_transfer_func)
>  {
> -s->end_transfer_func = end_transfer_func;
>  s->data_ptr = buf;
>  s->data_end = buf + size;
>  ide_set_retry(s);
>  if (!(s->status & ERR_STAT)) {
>  s->status |= DRQ_STAT;
>  }
> -if (s->bus->dma->ops->start_transfer) {
> -s->bus->dma->ops->start_transfer(s->bus->dma);
> +if (!s->bus->dma->ops->start_transfer) {
> +s->end_transfer_func = end_transfer_func;
> +return;
>  }
> +s->bus->dma->ops->start_transfer(s->bus->dma);
> +end_transfer_func(s);

wow, this makes me really uneasy to look at. The assumption now is: "If
you have a start_transfer method, that method if successful implies that
the transfer is *COMPLETED*."

It's implicit here, but I think anyone but the two of us would probably
not understand that implication. (Or me in three months.) What can we do
about that? Since AHCI is the only interface that uses this callback, I
wonder if we can't just rename it to something more obvious.

perform_transfer ? do_transfer ?

Under normal circumstances this function really does just "start" a
transfer and it's not obvious from context that some adapters have
synchronous methods to finish the transfer without further PIO pingpong
with the guest.

> +s->bus->dma->ops->end_transfer(s->bus->dma);
>  }
>  
>  static void ide_cmd_done(IDEState *s)
> diff --git a/include/hw/ide/internal.h b/include/hw/ide/internal.h
> index 88212f59df..efaabbd815 100644
> --- a/include/hw/ide/internal.h
> +++ b/include/hw/ide/internal.h
> @@ -445,6 +445,7 @@ struct IDEState {
>  struct IDEDMAOps {
>  DMAStartFunc *start_dma;
>  DMAVoidFunc *start_transfer;
> +DMAVoidFunc *end_transfer;
>  DMAInt32Func *prepare_buf;
>  DMAu32Func *commit_buf;
>  DMAIntFunc *rw_buf;
> 

Technically-OK-but-my-sadness-increased: John Snow 

Re: [Qemu-devel] [patches] Re: [PATCH v4 26/26] RISC-V: Fix riscv_isa_string memory size bug

[Michael Clark]

On Tue, Mar 20, 2018 at 1:51 PM, Philippe Mathieu-Daudé 
wrote:

> Le mar. 20 mars 2018 12:52, Peter Maydell  a
> écrit :
>
>> On 19 March 2018 at 21:18, Michael Clark  wrote:
>> > This version uses a constant size memory buffer sized for
>> > the maximum possible ISA string length. It also uses g_new
>> > instead of g_new0, uses more efficient logic to append
>> > extensions and adds manual zero termination of the string.
>> >
>> > Cc: Palmer Dabbelt 
>> > Cc: Peter Maydell 
>> > Signed-off-by: Michael Clark 
>> > Reviewed-by: Philippe Mathieu-Daudé 
>> > ---
>> >  target/riscv/cpu.c | 12 ++--
>> >  1 file changed, 6 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>> > index 1f25968..c82359f 100644
>> > --- a/target/riscv/cpu.c
>> > +++ b/target/riscv/cpu.c
>> > @@ -360,16 +360,16 @@ static void riscv_cpu_class_init(ObjectClass *c,
>> void *data)
>> >  char *riscv_isa_string(RISCVCPU *cpu)
>> >  {
>> >  int i;
>> > -size_t maxlen = 5 + ctz32(cpu->env.misa);
>> > -char *isa_string = g_new0(char, maxlen);
>> > -snprintf(isa_string, maxlen, "rv%d", TARGET_LONG_BITS);
>> > +const size_t maxlen = sizeof("rv128") + sizeof(riscv_exts) + 1;
>> > +char *isa_str = g_new(char, maxlen);
>> > +char *p = isa_str + snprintf(isa_str, maxlen, "rv%d",
>> TARGET_LONG_BITS);
>> >  for (i = 0; i < sizeof(riscv_exts); i++) {
>> >  if (cpu->env.misa & RV(riscv_exts[i])) {
>> > -isa_string[strlen(isa_string)] = riscv_exts[i] - 'A' + 'a';
>> > -
>> > +*p++ = tolower(riscv_exts[i]);
>>
>> This should be qemu_tolower(). Plain tolower() has an awkward problem
>> where if the 'char' type is signed and you hand tolower() a char that
>> happens to be a negative value you get undefined behaviour. This means
>> you need to cast the argument to 'unsigned char', which is what our
>>
>
> Oh, good to know.
>
> wrapper does. In this specific case the inputs are known constant
>> ASCII, so tolower() happens to be safe,
>
>
> Yep.
>
> but for consistency with
>> the rest of the codebase we should use our wrapper function.
>>
>
> Ok.
>
>
>> >  }
>> >  }
>> > -return isa_string;
>> > +*p = '\0';
>> > +return isa_str;
>> >  }
>> >
>> >  typedef struct RISCVCPUListState {
>>
>> Since this bug is causing the build tests to intermittently fail,
>> I'm going to apply this patch directly to master, with tolower()
>> replaced with qemu_tolower().
>>
>
> Thanks Peter!
>

Okay. I'll drop the patch from my post-merge spec conformance fixes series.

I've addressed all feedback on the post-merge spec conformance series so
i'll make a PR for it...

... these are the extra commits that were erroneously included in the v8.2
pull. They now all have sign-offs... they've been in the riscv tree for a
while and have had a lot of testing...

[Qemu-devel] [PATCH v4 2/3] linux-headers: add unistd.h on all arches

[Michael S. Tsirkin]

This adds unistd.h on ARM64 and MIPS and their dependencies.

Signed-off-by: Michael S. Tsirkin 
---
 linux-headers/asm-arm/bitsperlong.h |   1 +
 linux-headers/asm-arm64/bitsperlong.h   |  24 +
 linux-headers/asm-generic/bitsperlong.h |  16 +
 linux-headers/asm-generic/unistd.h  | 944 
 linux-headers/asm-mips/bitsperlong.h|   9 +
 linux-headers/asm-mips/sgidefs.h|  45 ++
 linux-headers/asm-mips/unistd.h |  44 +-
 linux-headers/asm-powerpc/bitsperlong.h |  13 +
 linux-headers/asm-s390/bitsperlong.h|  14 +
 linux-headers/asm-x86/bitsperlong.h |  14 +
 10 files changed, 1118 insertions(+), 6 deletions(-)
 create mode 100644 linux-headers/asm-arm/bitsperlong.h
 create mode 100644 linux-headers/asm-arm64/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/unistd.h
 create mode 100644 linux-headers/asm-mips/bitsperlong.h
 create mode 100644 linux-headers/asm-mips/sgidefs.h
 create mode 100644 linux-headers/asm-powerpc/bitsperlong.h
 create mode 100644 linux-headers/asm-s390/bitsperlong.h
 create mode 100644 linux-headers/asm-x86/bitsperlong.h

diff --git a/linux-headers/asm-arm/bitsperlong.h 
b/linux-headers/asm-arm/bitsperlong.h
new file mode 100644
index 000..6dc0bb0
--- /dev/null
+++ b/linux-headers/asm-arm/bitsperlong.h
@@ -0,0 +1 @@
+#include 
diff --git a/linux-headers/asm-arm64/bitsperlong.h 
b/linux-headers/asm-arm64/bitsperlong.h
new file mode 100644
index 000..485d60b
--- /dev/null
+++ b/linux-headers/asm-arm64/bitsperlong.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_BITSPERLONG_H
+#define __ASM_BITSPERLONG_H
+
+#define __BITS_PER_LONG 64
+
+#include 
+
+#endif /* __ASM_BITSPERLONG_H */
diff --git a/linux-headers/asm-generic/bitsperlong.h 
b/linux-headers/asm-generic/bitsperlong.h
new file mode 100644
index 000..0aac245
--- /dev/null
+++ b/linux-headers/asm-generic/bitsperlong.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef __ASM_GENERIC_BITS_PER_LONG
+#define __ASM_GENERIC_BITS_PER_LONG
+
+/*
+ * There seems to be no way of detecting this automatically from user
+ * space, so 64 bit architectures should override this in their
+ * bitsperlong.h. In particular, an architecture that supports
+ * both 32 and 64 bit user space must not rely on CONFIG_64BIT
+ * to decide it, but rather check a compiler provided macro.
+ */
+#ifndef __BITS_PER_LONG
+#define __BITS_PER_LONG 32
+#endif
+
+#endif /* __ASM_GENERIC_BITS_PER_LONG */
diff --git a/linux-headers/asm-generic/unistd.h 
b/linux-headers/asm-generic/unistd.h
new file mode 100644
index 000..8b87de0
--- /dev/null
+++ b/linux-headers/asm-generic/unistd.h
@@ -0,0 +1,944 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#include 
+
+/*
+ * This file contains the system call numbers, based on the
+ * layout of the x86-64 architecture, which embeds the
+ * pointer to the syscall in the table.
+ *
+ * As a basic principle, no duplication of functionality
+ * should be added, e.g. we don't use lseek when llseek
+ * is present. New architectures should use this file
+ * and implement the less feature-full calls in user space.
+ */
+
+#ifndef __SYSCALL
+#define __SYSCALL(x, y)
+#endif
+
+#if __BITS_PER_LONG == 32 || defined(__SYSCALL_COMPAT)
+#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _32)
+#else
+#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _64)
+#endif
+
+#ifdef __SYSCALL_COMPAT
+#define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _comp)
+#define __SC_COMP_3264(_nr, _32, _64, _comp) __SYSCALL(_nr, _comp)
+#else
+#define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _sys)
+#define __SC_COMP_3264(_nr, _32, _64, _comp) __SC_3264(_nr, _32, _64)
+#endif
+
+#define __NR_io_setup 0
+__SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup)
+#define __NR_io_destroy 1
+__SYSCALL(__NR_io_destroy, sys_io_destroy)
+#define __NR_io_submit 2
+__SC_COMP(__NR_io_submit, sys_io_submit, compat_sys_io_submit)
+#define __NR_io_cancel 3
+__SYSCALL(__NR_io_cancel, sys_io_cancel)
+#define __NR_io_getevents 4
+__SC_COMP(__NR_io_getevents, sys_io_getevents, compat_sys_io_getevents)
+
+/* fs/xattr.c */
+#define __NR_setxattr 5
+__SYSCALL(__NR_setxattr, sys_setxattr)
+#define 

[Qemu-devel] [PATCH v4 0/3] linux-headers: arch fixups

[Michael S. Tsirkin]

It turns out that we have unistd.h and kvm headers for some
architectures but not others.  We are thus unable to use e.g. usefaultfd
on these systems unless system headers have been updated.

Fix up update-linux-headers.sh to make sure we auto-updates
all architectures which have linux-headers/
(unfortunately this still does not mean "all linux systems").

Tested on x86 only.

Pls consider merging this through the ARM tree.

Michael S. Tsirkin (3):
  update-linux-headers.sh: add unistd.h and kvm on MIPS
  linux-headers: add unistd.h on all arches
  linux-headers: add kvm header for mips

 linux-headers/asm-arm/bitsperlong.h |   1 +
 linux-headers/asm-arm64/bitsperlong.h   |  24 +
 linux-headers/asm-generic/bitsperlong.h |  16 +
 linux-headers/asm-generic/unistd.h  | 944 
 linux-headers/asm-mips/bitsperlong.h|   9 +
 linux-headers/asm-mips/kvm.h|  25 +-
 linux-headers/asm-mips/sgidefs.h|  45 ++
 linux-headers/asm-mips/unistd.h |  44 +-
 linux-headers/asm-powerpc/bitsperlong.h |  13 +
 linux-headers/asm-s390/bitsperlong.h|  14 +
 linux-headers/asm-x86/bitsperlong.h |  14 +
 scripts/update-linux-headers.sh |  22 +-
 12 files changed, 1155 insertions(+), 16 deletions(-)
 create mode 100644 linux-headers/asm-arm/bitsperlong.h
 create mode 100644 linux-headers/asm-arm64/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/unistd.h
 create mode 100644 linux-headers/asm-mips/bitsperlong.h
 create mode 100644 linux-headers/asm-mips/sgidefs.h
 create mode 100644 linux-headers/asm-powerpc/bitsperlong.h
 create mode 100644 linux-headers/asm-s390/bitsperlong.h
 create mode 100644 linux-headers/asm-x86/bitsperlong.h

-- 
MST

[Qemu-devel] [PATCH v4 1/3] update-linux-headers.sh: add unistd.h and kvm on MIPS

[Michael S. Tsirkin]

Rework the update script slightly, add the unistd.h header and its
dependencies on all architectures.

This also removes the IA64 and MIPS from a KVM blacklist:
Linux dropped IA64, and there was never a reason to
exclude MIPS from kvm specifically - it was
excluded due to dependency of its unistd.h on sgidefs.h,
which we also import.

Signed-off-by: Michael S. Tsirkin 
---
 scripts/update-linux-headers.sh | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index d18e2f1..2a4dac8a 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -80,11 +80,6 @@ for arch in $ARCHLIST; do
 continue
 fi
 
-# Blacklist architectures which have KVM headers but are actually dead
-if [ "$arch" = "ia64" -o "$arch" = "mips" ]; then
-continue
-fi
-
 if [ "$arch" = x86 ]; then
 arch_var=SRCARCH
 else
@@ -95,9 +90,18 @@ for arch in $ARCHLIST; do
 
 rm -rf "$output/linux-headers/asm-$arch"
 mkdir -p "$output/linux-headers/asm-$arch"
-for header in kvm.h kvm_para.h unistd.h; do
+for header in unistd.h bitsperlong.h; do
+cp "$tmpdir/include/asm/$header" "$output/linux-headers/asm-$arch"
+done
+
+for header in kvm.h kvm_para.h; do
 cp "$tmpdir/include/asm/$header" "$output/linux-headers/asm-$arch"
 done
+
+if [ $arch = mips ]; then
+cp "$tmpdir/include/asm/sgidefs.h" "$output/linux-headers/asm-mips/"
+fi
+
 if [ $arch = powerpc ]; then
 cp "$tmpdir/include/asm/epapr_hcalls.h" 
"$output/linux-headers/asm-powerpc/"
 fi
@@ -120,6 +124,10 @@ EOF
 cp "$tmpdir/include/asm/unistd_x32.h" "$output/linux-headers/asm-x86/"
 cp "$tmpdir/include/asm/unistd_64.h" "$output/linux-headers/asm-x86/"
 fi
+if [ $arch = s390 ]; then
+cp "$tmpdir/include/asm/unistd_32.h" "$output/linux-headers/asm-arm/"
+cp "$tmpdir/include/asm/unistd_64.h" "$output/linux-headers/asm-arm/"
+fi
 done
 
 rm -rf "$output/linux-headers/linux"
@@ -130,7 +138,7 @@ for header in kvm.h kvm_para.h vfio.h vfio_ccw.h vhost.h \
 done
 rm -rf "$output/linux-headers/asm-generic"
 mkdir -p "$output/linux-headers/asm-generic"
-for header in kvm_para.h; do
+for header in kvm_para.h bitsperlong.h unistd.h; do
 cp "$tmpdir/include/asm-generic/$header" 
"$output/linux-headers/asm-generic"
 done
 if [ -L "$linux/source" ]; then
-- 
MST

Re: [Qemu-devel] [Qemu-arm] [PATCH v3 08/22] target/arm: Support multiple EL change hooks

[Philippe Mathieu-Daudé]

Le 20 mars 2018 9:45 PM, "Aaron Lindsay"  a écrit :

On Mar 18 23:41, Philippe Mathieu-Daudé wrote:
> On 03/16/2018 09:31 PM, Aaron Lindsay wrote:
> > Signed-off-by: Aaron Lindsay 
> > ---
> >  target/arm/cpu.c   | 15 ++-
> >  target/arm/cpu.h   | 23 ---
> >  target/arm/internals.h |  7 ---
> >  3 files changed, 26 insertions(+), 19 deletions(-)
> >
> > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > index 072cbbf..5f782bf 100644
> > --- a/target/arm/cpu.c
> > +++ b/target/arm/cpu.c
> > @@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs)
> >   | CPU_INTERRUPT_EXITTB);
> >  }
> >
> > -void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHook *hook,
> > +void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHookFn *hook,
> >   void *opaque)
> >  {
> > -/* We currently only support registering a single hook function */
> > -assert(!cpu->el_change_hook);
> > -cpu->el_change_hook = hook;
> > -cpu->el_change_hook_opaque = opaque;
> > +ARMELChangeHook *entry;
> > +entry = g_malloc0(sizeof (*entry));
>
> imho g_malloc() is enough.

It seems like the only difference is between initializing it to zero
(g_malloc0) and making it as uninitialized (g_malloc) for coverity. Are
there coding standards for when we should choose which?


Since you initialize all members, bzero is not necessary; until someone add
another member to the structure. So your way is correct and safer, with a
ridiculous performance penalty.



>
> > +
> > +entry->hook = hook;
> > +entry->opaque = opaque;
> > +
> > +QLIST_INSERT_HEAD(>el_change_hooks, entry, node);
> >  }
> >
> >  static void cp_reg_reset(gpointer key, gpointer value, gpointer opaque)
> > @@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev,
Error **errp)
> >  return;
> >  }
> >
> > +QLIST_INIT(>el_change_hooks);
> > +
>
> You missed to fill arm_cpu_unrealizefn() with:
>
> QLIST_FOREACH(...) {
> QLIST_REMOVE(...);
> g_free(...);
> }

Do you mean arm_cpu_finalizefn()?


Yes :)



-Aaron


--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies,
Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

[Qemu-devel] [PATCH v4 3/3] linux-headers: add kvm header for mips

[Michael S. Tsirkin]

kvm header for MIPS was manually excluded from auto-updates.

Update it now to 4.16-rc5.

Signed-off-by: Michael S. Tsirkin 
---
 linux-headers/asm-mips/kvm.h | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/linux-headers/asm-mips/kvm.h b/linux-headers/asm-mips/kvm.h
index 6985eb5..edcf717 100644
--- a/linux-headers/asm-mips/kvm.h
+++ b/linux-headers/asm-mips/kvm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 /*
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
@@ -19,6 +20,10 @@
  * Some parts derived from the x86 version of this file.
  */
 
+#define __KVM_HAVE_READONLY_MEM
+
+#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+
 /*
  * for KVM_GET_REGS and KVM_SET_REGS
  *
@@ -52,9 +57,14 @@ struct kvm_fpu {
  * Register set = 0: GP registers from kvm_regs (see definitions below).
  *
  * Register set = 1: CP0 registers.
- *  bits[15..8]  - Must be zero.
- *  bits[7..3]   - Register 'rd'  index.
- *  bits[2..0]   - Register 'sel' index.
+ *  bits[15..8]  - COP0 register set.
+ *
+ *  COP0 register set = 0: Main CP0 registers.
+ *   bits[7..3]   - Register 'rd'  index.
+ *   bits[2..0]   - Register 'sel' index.
+ *
+ *  COP0 register set = 1: MAARs.
+ *   bits[7..0]   - MAAR index.
  *
  * Register set = 2: KVM specific registers (see definitions below).
  *
@@ -113,6 +123,15 @@ struct kvm_fpu {
 
 
 /*
+ * KVM_REG_MIPS_CP0 - Coprocessor 0 registers.
+ */
+
+#define KVM_REG_MIPS_MAAR  (KVM_REG_MIPS_CP0 | (1 << 8))
+#define KVM_REG_MIPS_CP0_MAAR(n)   (KVM_REG_MIPS_MAAR | \
+KVM_REG_SIZE_U64 | (n))
+
+
+/*
  * KVM_REG_MIPS_KVM - KVM specific control registers.
  */
 
-- 
MST

[Qemu-devel] [PATCH v2 4/4] tpm: CRB: query backend for TPM established flag

[Stefan Berger]

Signed-off-by: Stefan Berger 
---
 hw/tpm/tpm_crb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c
index e8c42f6..ef8b80e 100644
--- a/hw/tpm/tpm_crb.c
+++ b/hw/tpm/tpm_crb.c
@@ -84,6 +84,12 @@ static uint64_t tpm_crb_mmio_read(void *opaque, hwaddr addr,
 unsigned offset = addr & 3;
 uint32_t val = *(uint32_t *)regs >> (8 * offset);
 
+switch (addr) {
+case A_CRB_LOC_STATE:
+val |= !tpm_backend_get_tpm_established_flag(s->tpmbe);
+break;
+}
+
 trace_tpm_crb_mmio_read(addr, size, val);
 
 return val;
-- 
2.5.5

[Qemu-devel] [PATCH v2 3/4] tpm: CRB: reset locAssigned upon relinquishing locality

[Stefan Berger]

Signed-off-by: Stefan Berger 
---
 hw/tpm/tpm_crb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c
index 4bd76b5..e8c42f6 100644
--- a/hw/tpm/tpm_crb.c
+++ b/hw/tpm/tpm_crb.c
@@ -137,6 +137,8 @@ static void tpm_crb_mmio_write(void *opaque, hwaddr addr,
 /* not loc 3 or 4 */
 break;
 case CRB_LOC_CTRL_RELINQUISH:
+ARRAY_FIELD_DP32(s->regs, CRB_LOC_STATE,
+ locAssigned, 0);
 break;
 case CRB_LOC_CTRL_REQUEST_ACCESS:
 ARRAY_FIELD_DP32(s->regs, CRB_LOC_STS,
-- 
2.5.5

[Qemu-devel] [PATCH v2 0/4] tpm: Fix initialization of a few flags of CRB interface

[Stefan Berger]

Fix the initialization of a few flags of the CRB interface. I tested the changes
with UEFI and it works fine. SeaBIOS needs to have the latest patches applied.

   Stefan

Stefan Berger (4):
  tpm: CRB: Set tpmRegValidSts flag to '1' in device reset
  tpm: CRB: set registers to 0 by default
  tpm: CRB: reset locAssigned upon relinquishing locality
  tpm: CRB: query backend for TPM established flag

 hw/tpm/tpm_crb.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

-- 
2.5.5

[Qemu-devel] [PATCH v2 2/4] tpm: CRB: set registers to 0 by default

[Stefan Berger]

Initialize all registers of the CRB device to 0. This clears a few
flags upon a reset.

Signed-off-by: Stefan Berger 
---
 hw/tpm/tpm_crb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c
index 114b66e..4bd76b5 100644
--- a/hw/tpm/tpm_crb.c
+++ b/hw/tpm/tpm_crb.c
@@ -208,6 +208,8 @@ static void tpm_crb_reset(void *dev)
 
 tpm_backend_reset(s->tpmbe);
 
+memset(s->regs, 0, sizeof(s->regs));
+
 ARRAY_FIELD_DP32(s->regs, CRB_LOC_STATE,
  tpmRegValidSts, 1);
 ARRAY_FIELD_DP32(s->regs, CRB_INTF_ID,
-- 
2.5.5

[Qemu-devel] [PATCH v2 1/4] tpm: CRB: Set tpmRegValidSts flag to '1' in device reset

[Stefan Berger]

Fix the initialization of the tpmRegValidSts flag and set it to '1'
during device reset without expecting a write to another register.
This seems to also be the default behavior of real hardware.

Signed-off-by: Stefan Berger 
---
 hw/tpm/tpm_crb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c
index d8917cb..114b66e 100644
--- a/hw/tpm/tpm_crb.c
+++ b/hw/tpm/tpm_crb.c
@@ -145,8 +145,6 @@ static void tpm_crb_mmio_write(void *opaque, hwaddr addr,
  beenSeized, 0);
 ARRAY_FIELD_DP32(s->regs, CRB_LOC_STATE,
  locAssigned, 1);
-ARRAY_FIELD_DP32(s->regs, CRB_LOC_STATE,
- tpmRegValidSts, 1);
 break;
 }
 break;
@@ -210,6 +208,8 @@ static void tpm_crb_reset(void *dev)
 
 tpm_backend_reset(s->tpmbe);
 
+ARRAY_FIELD_DP32(s->regs, CRB_LOC_STATE,
+ tpmRegValidSts, 1);
 ARRAY_FIELD_DP32(s->regs, CRB_INTF_ID,
  InterfaceType, CRB_INTF_TYPE_CRB_ACTIVE);
 ARRAY_FIELD_DP32(s->regs, CRB_INTF_ID,
-- 
2.5.5

Re: [Qemu-devel] [PATCH v4 26/26] RISC-V: Fix riscv_isa_string memory size bug

[Philippe Mathieu-Daudé]

Le mar. 20 mars 2018 12:52, Peter Maydell  a
écrit :

> On 19 March 2018 at 21:18, Michael Clark  wrote:
> > This version uses a constant size memory buffer sized for
> > the maximum possible ISA string length. It also uses g_new
> > instead of g_new0, uses more efficient logic to append
> > extensions and adds manual zero termination of the string.
> >
> > Cc: Palmer Dabbelt 
> > Cc: Peter Maydell 
> > Signed-off-by: Michael Clark 
> > Reviewed-by: Philippe Mathieu-Daudé 
> > ---
> >  target/riscv/cpu.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index 1f25968..c82359f 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -360,16 +360,16 @@ static void riscv_cpu_class_init(ObjectClass *c,
> void *data)
> >  char *riscv_isa_string(RISCVCPU *cpu)
> >  {
> >  int i;
> > -size_t maxlen = 5 + ctz32(cpu->env.misa);
> > -char *isa_string = g_new0(char, maxlen);
> > -snprintf(isa_string, maxlen, "rv%d", TARGET_LONG_BITS);
> > +const size_t maxlen = sizeof("rv128") + sizeof(riscv_exts) + 1;
> > +char *isa_str = g_new(char, maxlen);
> > +char *p = isa_str + snprintf(isa_str, maxlen, "rv%d",
> TARGET_LONG_BITS);
> >  for (i = 0; i < sizeof(riscv_exts); i++) {
> >  if (cpu->env.misa & RV(riscv_exts[i])) {
> > -isa_string[strlen(isa_string)] = riscv_exts[i] - 'A' + 'a';
> > -
> > +*p++ = tolower(riscv_exts[i]);
>
> This should be qemu_tolower(). Plain tolower() has an awkward problem
> where if the 'char' type is signed and you hand tolower() a char that
> happens to be a negative value you get undefined behaviour. This means
> you need to cast the argument to 'unsigned char', which is what our
>

Oh, good to know.

wrapper does. In this specific case the inputs are known constant
> ASCII, so tolower() happens to be safe,


Yep.

but for consistency with
> the rest of the codebase we should use our wrapper function.
>

Ok.


> >  }
> >  }
> > -return isa_string;
> > +*p = '\0';
> > +return isa_str;
> >  }
> >
> >  typedef struct RISCVCPUListState {
>
> Since this bug is causing the build tests to intermittently fail,
> I'm going to apply this patch directly to master, with tolower()
> replaced with qemu_tolower().
>

Thanks Peter!


> thanks
> -- PMM
>
>

Re: [Qemu-devel] [PATCH] sdhci: fix incorrect use of Error *

[Philippe Mathieu-Daudé]

Le 20 mars 2018 4:14 PM, "Paolo Bonzini"  a écrit :

Detected by Coverity (CID 1386072, 1386073, 1386076, 1386077).  local_err
was unused, and this made the static analyzer unhappy


Oops, thanks Paolo!


Signed-off-by: Paolo Bonzini 
---
 hw/sd/sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 1b828b104d..63c44a4ee8 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1474,7 +1474,7 @@ static void sdhci_pci_realize(PCIDevice *dev, Error
**errp)
 Error *local_err = NULL;

 sdhci_initfn(s);
-sdhci_common_realize(s, errp);
+sdhci_common_realize(s, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
@@ -1556,7 +1556,7 @@ static void sdhci_sysbus_realize(DeviceState *dev,
Error ** errp)
 SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
 Error *local_err = NULL;

-sdhci_common_realize(s, errp);
+sdhci_common_realize(s, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
--
2.16.2

Re: [Qemu-devel] [Qemu-arm] [PATCH v3 08/22] target/arm: Support multiple EL change hooks

[Aaron Lindsay]

On Mar 18 23:41, Philippe Mathieu-Daudé wrote:
> On 03/16/2018 09:31 PM, Aaron Lindsay wrote:
> > Signed-off-by: Aaron Lindsay 
> > ---
> >  target/arm/cpu.c   | 15 ++-
> >  target/arm/cpu.h   | 23 ---
> >  target/arm/internals.h |  7 ---
> >  3 files changed, 26 insertions(+), 19 deletions(-)
> > 
> > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > index 072cbbf..5f782bf 100644
> > --- a/target/arm/cpu.c
> > +++ b/target/arm/cpu.c
> > @@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs)
> >   | CPU_INTERRUPT_EXITTB);
> >  }
> >  
> > -void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHook *hook,
> > +void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHookFn *hook,
> >   void *opaque)
> >  {
> > -/* We currently only support registering a single hook function */
> > -assert(!cpu->el_change_hook);
> > -cpu->el_change_hook = hook;
> > -cpu->el_change_hook_opaque = opaque;
> > +ARMELChangeHook *entry;
> > +entry = g_malloc0(sizeof (*entry));
> 
> imho g_malloc() is enough.

It seems like the only difference is between initializing it to zero
(g_malloc0) and making it as uninitialized (g_malloc) for coverity. Are
there coding standards for when we should choose which?

> 
> > +
> > +entry->hook = hook;
> > +entry->opaque = opaque;
> > +
> > +QLIST_INSERT_HEAD(>el_change_hooks, entry, node);
> >  }
> >  
> >  static void cp_reg_reset(gpointer key, gpointer value, gpointer opaque)
> > @@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> > **errp)
> >  return;
> >  }
> >  
> > +QLIST_INIT(>el_change_hooks);
> > +
> 
> You missed to fill arm_cpu_unrealizefn() with:
> 
> QLIST_FOREACH(...) {
> QLIST_REMOVE(...);
> g_free(...);
> }

Do you mean arm_cpu_finalizefn()?

-Aaron

-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

[Qemu-devel] [PULL 1/1] linux-user: init_guest_space: Try to make ARM space+commpage continuous

[Laurent Vivier]

From: Luke Shumaker 

At a fixed distance after the usable memory that init_guest_space maps, for
32-bit ARM targets we also need to map a commpage.  The normal
init_guest_space logic doesn't keep this in mind when searching for an
address range.

If !host_start, then try to find a big continuous segment where we can put
both the usable memory and the commpage; we then munmap that segment and
set current_start to that address; and let the normal code mmap the usable
memory and the commpage separately.  That is: if we don't have hint of
where to start looking for memory, come up with one that is better than
NULL.  Depending on host_size and guest_start, there may or may not be a
gap between the usable memory and the commpage, so this is slightly more
restrictive than it needs to be; but it's only a hint, so that's OK.

We only do that for !host start, because if host_start, then either:
 - we got an address passed in with -B, in which case we don't want to
   interfere with what the user said;
 - or host_start is based off of the ELF image's loaddr.  The check "if
   (host_start && real_start != current_start)" suggests that we really
   want lowest available address that is >= loaddr.  I don't know why that
   is, but I'm trusting that Paul Brook knew what he was doing when he
   wrote the original version of that check in
   c581deda322080e8beb88b2e468d4af54454e4b3 way back in 2010.

Signed-off-by: Luke Shumaker 
Message-Id: <20171228180814.9749-11-luke...@lukeshu.com>
Signed-off-by: Laurent Vivier 
---
 linux-user/elfload.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 4563a3190b..23e34957f9 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1889,6 +1889,55 @@ unsigned long init_guest_space(unsigned long host_start,
 
 /* Otherwise, a non-zero size region of memory needs to be mapped
  * and validated.  */
+
+#if defined(TARGET_ARM) && !defined(TARGET_AARCH64)
+/* On 32-bit ARM, we need to map not just the usable memory, but
+ * also the commpage.  Try to find a suitable place by allocating
+ * a big chunk for all of it.  If host_start, then the naive
+ * strategy probably does good enough.
+ */
+if (!host_start) {
+unsigned long guest_full_size, host_full_size, real_start;
+
+guest_full_size =
+(0x0f00 & qemu_host_page_mask) + qemu_host_page_size;
+host_full_size = guest_full_size - guest_start;
+real_start = (unsigned long)
+mmap(NULL, host_full_size, PROT_NONE, flags, -1, 0);
+if (real_start == (unsigned long)-1) {
+if (host_size < host_full_size - qemu_host_page_size) {
+/* We failed to map a continous segment, but we're
+ * allowed to have a gap between the usable memory and
+ * the commpage where other things can be mapped.
+ * This sparseness gives us more flexibility to find
+ * an address range.
+ */
+goto naive;
+}
+return (unsigned long)-1;
+}
+munmap((void *)real_start, host_full_size);
+if (real_start & ~qemu_host_page_mask) {
+/* The same thing again, but with an extra qemu_host_page_size
+ * so that we can shift around alignment.
+ */
+unsigned long real_size = host_full_size + qemu_host_page_size;
+real_start = (unsigned long)
+mmap(NULL, real_size, PROT_NONE, flags, -1, 0);
+if (real_start == (unsigned long)-1) {
+if (host_size < host_full_size - qemu_host_page_size) {
+goto naive;
+}
+return (unsigned long)-1;
+}
+munmap((void *)real_start, real_size);
+real_start = HOST_PAGE_ALIGN(real_start);
+}
+current_start = real_start;
+}
+ naive:
+#endif
+
 while (1) {
 unsigned long real_start, real_size, aligned_size;
 aligned_size = real_size = host_size;
-- 
2.14.3

[Qemu-devel] [PULL 0/1] Linux user for 2.12 patches

[Laurent Vivier]

The following changes since commit 036793aebfc1dd0ce124fa278d7668d89b5da936:

  Merge remote-tracking branch 
'remotes/ehabkost/tags/machine-next-pull-request' into staging (2018-03-20 
12:56:20 +)

are available in the Git repository at:

  git://github.com/vivier/qemu.git tags/linux-user-for-2.12-pull-request

for you to fetch changes up to 2a53535af471f4bee9d6cb5b363746b8d5ed21dd:

  linux-user: init_guest_space: Try to make ARM space+commpage continuous 
(2018-03-20 18:26:40 +0100)





Luke Shumaker (1):
  linux-user: init_guest_space: Try to make ARM space+commpage
continuous

 linux-user/elfload.c | 49 +
 1 file changed, 49 insertions(+)

-- 
2.14.3

[Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc0 is now available

[Michael Roth]

Hello,

On behalf of the QEMU Team, I'd like to announce the availability of the
first release candidate for the QEMU 2.12 release.  This release is meant
for testing purposes and should not be used in a production environment.

  http://download.qemu-project.org/qemu-2.12.0-rc0.tar.xz
  http://download.qemu-project.org/qemu-2.12.0-rc0.tar.xz.sig

You can help improve the quality of the QEMU 2.12 release by testing this
release and reporting bugs on Launchpad:

  https://bugs.launchpad.net/qemu/

The release plan, as well a documented known issues for release
candidates, are available at:

  http://wiki.qemu.org/Planning/2.12

Please add entries to the ChangeLog for the 2.12 release below:

  http://wiki.qemu.org/ChangeLog/2.12

Re: [Qemu-devel] [PATCH] postcopy-ram: add a stub for postcopy_request_shared_page

[no-reply]

Hi,

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

Type: series
Message-id: 1521556695-35907-1-git-send-email-...@redhat.com
Subject: [Qemu-devel] [PATCH] postcopy-ram: add a stub for 
postcopy_request_shared_page

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
0d3019296b postcopy-ram: add a stub for postcopy_request_shared_page

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-9__ixibw/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-9__ixibw/src'
  GEN 
/var/tmp/patchew-tester-tmp-9__ixibw/src/docker-src.2018-03-20-15.32.02.7184/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-9__ixibw/src/docker-src.2018-03-20-15.32.02.7184/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-9__ixibw/src/docker-src.2018-03-20-15.32.02.7184/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-9__ixibw/src/docker-src.2018-03-20-15.32.02.7184/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-mingw in qemu:fedora 
Packages installed:
PyYAML-3.12-5.fc27.x86_64
SDL-devel-1.2.15-29.fc27.x86_64
bc-1.07.1-3.fc27.x86_64
bison-3.0.4-8.fc27.x86_64
bzip2-1.0.6-24.fc27.x86_64
ccache-3.3.6-1.fc27.x86_64
clang-5.0.1-3.fc27.x86_64
findutils-4.6.0-16.fc27.x86_64
flex-2.6.1-5.fc27.x86_64
gcc-7.3.1-5.fc27.x86_64
gcc-c++-7.3.1-5.fc27.x86_64
gettext-0.19.8.1-12.fc27.x86_64
git-2.14.3-3.fc27.x86_64
glib2-devel-2.54.3-2.fc27.x86_64
hostname-3.18-4.fc27.x86_64
libaio-devel-0.3.110-9.fc27.x86_64
libasan-7.3.1-5.fc27.x86_64
libfdt-devel-1.4.6-1.fc27.x86_64
libubsan-7.3.1-5.fc27.x86_64
llvm-5.0.1-3.fc27.x86_64
make-4.2.1-4.fc27.x86_64
mingw32-SDL-1.2.15-9.fc27.noarch
mingw32-bzip2-1.0.6-9.fc27.noarch
mingw32-curl-7.54.1-2.fc27.noarch
mingw32-glib2-2.54.1-1.fc27.noarch
mingw32-gmp-6.1.2-2.fc27.noarch
mingw32-gnutls-3.5.13-2.fc27.noarch
mingw32-gtk2-2.24.31-4.fc27.noarch
mingw32-gtk3-3.22.16-1.fc27.noarch
mingw32-libjpeg-turbo-1.5.1-3.fc27.noarch
mingw32-libpng-1.6.29-2.fc27.noarch
mingw32-libssh2-1.8.0-3.fc27.noarch
mingw32-libtasn1-4.13-1.fc27.noarch
mingw32-nettle-3.3-3.fc27.noarch
mingw32-pixman-0.34.0-3.fc27.noarch
mingw32-pkg-config-0.28-9.fc27.x86_64
mingw64-SDL-1.2.15-9.fc27.noarch
mingw64-bzip2-1.0.6-9.fc27.noarch
mingw64-curl-7.54.1-2.fc27.noarch
mingw64-glib2-2.54.1-1.fc27.noarch
mingw64-gmp-6.1.2-2.fc27.noarch
mingw64-gnutls-3.5.13-2.fc27.noarch
mingw64-gtk2-2.24.31-4.fc27.noarch
mingw64-gtk3-3.22.16-1.fc27.noarch
mingw64-libjpeg-turbo-1.5.1-3.fc27.noarch
mingw64-libpng-1.6.29-2.fc27.noarch
mingw64-libssh2-1.8.0-3.fc27.noarch
mingw64-libtasn1-4.13-1.fc27.noarch
mingw64-nettle-3.3-3.fc27.noarch
mingw64-pixman-0.34.0-3.fc27.noarch
mingw64-pkg-config-0.28-9.fc27.x86_64
nettle-devel-3.4-1.fc27.x86_64
perl-5.26.1-403.fc27.x86_64
pixman-devel-0.34.0-4.fc27.x86_64
python3-3.6.2-13.fc27.x86_64
sparse-0.5.1-2.fc27.x86_64
tar-1.29-7.fc27.x86_64
which-2.21-4.fc27.x86_64
zlib-devel-1.2.11-4.fc27.x86_64

Environment variables:
TARGET_LIST=
PACKAGES=ccache gettext git tar PyYAML sparse flex bison python3 bzip2 hostname 
glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel gcc gcc-c++ 
llvm clang make perl which bc findutils libaio-devel nettle-devel libasan 
libubsan mingw32-pixman mingw32-glib2 mingw32-gmp mingw32-SDL 
mingw32-pkg-config mingw32-gtk2 mingw32-gtk3 mingw32-gnutls mingw32-nettle 
mingw32-libtasn1 mingw32-libjpeg-turbo mingw32-libpng mingw32-curl 
mingw32-libssh2 mingw32-bzip2 mingw64-pixman mingw64-glib2 mingw64-gmp 
mingw64-SDL mingw64-pkg-config mingw64-gtk2 mingw64-gtk3 mingw64-gnutls 
mingw64-nettle mingw64-libtasn1 mingw64-libjpeg-turbo mingw64-libpng 
mingw64-curl mingw64-libssh2 mingw64-bzip2
J=8
V=
HOSTNAME=e31c6e620e01
DEBUG=
SHOW_ENV=1
PWD=/
HOME=/root
CCACHE_DIR=/var/tmp/ccache
DISTTAG=f27container
QEMU_CONFIGURE_OPTS=--python=/usr/bin/python3
FGC=f27
TEST_DIR=/tmp/qemu-test
SHLVL=1
FEATURES=mingw clang pyyaml asan dtc
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAKEFLAGS= -j8
EXTRA_CONFIGURE_OPTS=

Re: [Qemu-devel] [PATCH v4 2/5] target/i386: Populate AMD Processor Cache Information

[Moger, Babu]

> -Original Message-
> From: Eduardo Habkost 
> Sent: Tuesday, March 20, 2018 12:54 PM
> To: Moger, Babu 
> Cc: pbonz...@redhat.com; r...@twiddle.net; rkrc...@redhat.com;
> Lendacky, Thomas ; Singh, Brijesh
> ; k...@vger.kernel.org; k...@tripleback.net;
> mtosa...@redhat.com; Hook, Gary ; qemu-
> de...@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH v4 2/5] target/i386: Populate AMD
> Processor Cache Information
> 
> On Tue, Mar 20, 2018 at 05:25:52PM +, Moger, Babu wrote:
> > Hi Eduardo, Thanks for the comments. Please see the response inline.
> >
> > > -Original Message-
> > > From: Eduardo Habkost 
> > > Sent: Friday, March 16, 2018 1:00 PM
> > > To: Moger, Babu 
> > > Cc: pbonz...@redhat.com; r...@twiddle.net; rkrc...@redhat.com;
> > > Lendacky, Thomas ; Singh, Brijesh
> > > ; k...@vger.kernel.org; k...@tripleback.net;
> > > mtosa...@redhat.com; Hook, Gary ; qemu-
> > > de...@nongnu.org
> > > Subject: Re: [Qemu-devel] [PATCH v4 2/5] target/i386: Populate AMD
> > > Processor Cache Information
> > >
> > > On Mon, Mar 12, 2018 at 05:00:46PM -0400, Babu Moger wrote:
> > > > From: Stanislav Lanci 
> > > >
> > > > Add information for cpuid 0x801D leaf. Populate cache topology
> > > information
> > > > for different cache types(Data Cache, Instruction Cache, L2 and L3)
> > > supported
> > > > by 0x801D leaf. Please refer Processor Programming Reference
> (PPR)
> > > for AMD
> > > > Family 17h Model for more details.
> > > >
> > > > Signed-off-by: Stanislav Lanci 
> > > > Signed-off-by: Babu Moger 
> > >
> > > The new CPUID leaves don't seem to match the existing AMD cache
> > > information
> > > leaves.  Is this intentional?  Why?
> >
> > It is not intentional. These values are from older family of processors.
> These values have changed from Family 14  or later.
> > The latest one is Family 17. You can see the differences here.
> >  https://support.amd.com/TechDocs/41131.pdf
> >
> https://support.amd.com/TechDocs/55072_AMD_Family_15h_Models_70h-
> 7Fh_BKDG.pdf
> >
> https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-
> 0Fh.pdf
> >
> > Some of these are bugs in our code. For some we need to add checks for
> the family and correct these values.
> > You understand the code much better than me. Correct me if I missed
> something.
> >
> > Note that older family of processors don't support topology extensions.
> 
> If you want to make the cache size/topology look different
> depending on the CPU model/options, this would require more work,
> but it would be an interesting feature.
> 
> The "i386: Helpers to encode cache information consistently"
> patch I sent last week might be a useful starting point for that.

Yes. Looking at your patch.
> 
> If you plan to implement that, please keep in mind that existing
> CPUID cache info needs to be kept on previous machine-types (this
> is implemented by adding QOM properties that can be used to
> enable the old behavior, and by setting them at
> MachineClass::compat_props).

Yes. Will look into it.  This code is new to me.  Let me take a look.
Thanks

> 
> --
> Eduardo

[Qemu-devel] [PATCH] hw/rdma: Implementation of Query QP command

[Yuval Shaia]

Signed-off-by: Yuval Shaia 
---
 hw/rdma/rdma_backend.c   | 12 
 hw/rdma/rdma_backend.h   |  2 ++
 hw/rdma/rdma_rm.c| 18 ++
 hw/rdma/rdma_rm.h|  3 +++
 hw/rdma/vmw/pvrdma_cmd.c | 24 +++-
 5 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index ae7589c190..da2c8671e5 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -646,6 +646,18 @@ int rdma_backend_qp_state_rts(RdmaBackendQP *qp, uint8_t 
qp_type,
 return 0;
 }
 
+int rdma_backend_query_qp(RdmaBackendQP *qp, struct ibv_qp_attr *attr,
+  int attr_mask, struct ibv_qp_init_attr *init_attr)
+{
+if (!qp->ibqp) {
+pr_dbg("QP1\n");
+attr->qp_state = IBV_QPS_RTS;
+return 0;
+}
+
+return ibv_query_qp(qp->ibqp, attr, attr_mask, init_attr);
+}
+
 void rdma_backend_destroy_qp(RdmaBackendQP *qp)
 {
 if (qp->ibqp) {
diff --git a/hw/rdma/rdma_backend.h b/hw/rdma/rdma_backend.h
index 07f6fed768..6d9b45efe8 100644
--- a/hw/rdma/rdma_backend.h
+++ b/hw/rdma/rdma_backend.h
@@ -83,6 +83,8 @@ int rdma_backend_qp_state_rtr(RdmaBackendDev *backend_dev, 
RdmaBackendQP *qp,
   bool use_qkey);
 int rdma_backend_qp_state_rts(RdmaBackendQP *qp, uint8_t qp_type,
   uint32_t sq_psn, uint32_t qkey, bool use_qkey);
+int rdma_backend_query_qp(RdmaBackendQP *qp, struct ibv_qp_attr *attr,
+  int attr_mask, struct ibv_qp_init_attr *init_attr);
 void rdma_backend_destroy_qp(RdmaBackendQP *qp);
 
 void rdma_backend_post_send(RdmaBackendDev *backend_dev,
diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 296e40518e..a4e1de31fd 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -453,6 +453,24 @@ int rdma_rm_modify_qp(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
 return 0;
 }
 
+int rdma_rm_query_qp(RdmaDeviceResources *dev_res, RdmaBackendDev *backend_dev,
+ uint32_t qp_handle, struct ibv_qp_attr *attr,
+ int attr_mask, struct ibv_qp_init_attr *init_attr)
+{
+RdmaRmQP *qp;
+
+pr_dbg("qpn=%d\n", qp_handle);
+
+qp = rdma_rm_get_qp(dev_res, qp_handle);
+if (!qp) {
+return -EINVAL;
+}
+
+pr_dbg("qp_type=%d\n", qp->qp_type);
+
+return rdma_backend_query_qp(>backend_qp, attr, attr_mask, init_attr);
+}
+
 void rdma_rm_dealloc_qp(RdmaDeviceResources *dev_res, uint32_t qp_handle)
 {
 RdmaRmQP *qp;
diff --git a/hw/rdma/rdma_rm.h b/hw/rdma/rdma_rm.h
index be95c1b0f4..0528c1972b 100644
--- a/hw/rdma/rdma_rm.h
+++ b/hw/rdma/rdma_rm.h
@@ -59,6 +59,9 @@ int rdma_rm_modify_qp(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
   union ibv_gid *dgid, uint32_t dqpn,
   enum ibv_qp_state qp_state, uint32_t qkey,
   uint32_t rq_psn, uint32_t sq_psn);
+int rdma_rm_query_qp(RdmaDeviceResources *dev_res, RdmaBackendDev *backend_dev,
+ uint32_t qp_handle, struct ibv_qp_attr *attr,
+ int attr_mask, struct ibv_qp_init_attr *init_attr);
 void rdma_rm_dealloc_qp(RdmaDeviceResources *dev_res, uint32_t qp_handle);
 
 int rdma_rm_alloc_cqe_ctx(RdmaDeviceResources *dev_res, uint32_t *cqe_ctx_id,
diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma/vmw/pvrdma_cmd.c
index 293dfed29f..cf8c50af31 100644
--- a/hw/rdma/vmw/pvrdma_cmd.c
+++ b/hw/rdma/vmw/pvrdma_cmd.c
@@ -515,6 +515,28 @@ static int modify_qp(PVRDMADev *dev, union pvrdma_cmd_req 
*req,
 return rsp->hdr.err;
 }
 
+static int query_qp(PVRDMADev *dev, union pvrdma_cmd_req *req,
+ union pvrdma_cmd_resp *rsp)
+{
+struct pvrdma_cmd_query_qp *cmd = >query_qp;
+struct pvrdma_cmd_query_qp_resp *resp = >query_qp_resp;
+struct ibv_qp_init_attr init_attr;
+
+pr_dbg("qp_handle=%d\n", cmd->qp_handle);
+
+memset(rsp, 0, sizeof(*rsp));
+rsp->hdr.response = cmd->hdr.response;
+rsp->hdr.ack = PVRDMA_CMD_QUERY_QP_RESP;
+
+rsp->hdr.err = rdma_rm_query_qp(>rdma_dev_res, >backend_dev,
+cmd->qp_handle,
+(struct ibv_qp_attr *)>attrs, -1,
+_attr);
+
+pr_dbg("ret=%d\n", rsp->hdr.err);
+return rsp->hdr.err;
+}
+
 static int destroy_qp(PVRDMADev *dev, union pvrdma_cmd_req *req,
   union pvrdma_cmd_resp *rsp)
 {
@@ -636,7 +658,7 @@ static struct cmd_handler cmd_handlers[] = {
 {PVRDMA_CMD_DESTROY_CQ, destroy_cq},
 {PVRDMA_CMD_CREATE_QP, create_qp},
 {PVRDMA_CMD_MODIFY_QP, modify_qp},
-{PVRDMA_CMD_QUERY_QP, NULL},
+{PVRDMA_CMD_QUERY_QP, query_qp},
 {PVRDMA_CMD_DESTROY_QP, destroy_qp},
 {PVRDMA_CMD_CREATE_UC, create_uc},
 {PVRDMA_CMD_DESTROY_UC, destroy_uc},
-- 
2.13.6

Re: [Qemu-devel] [PULL 0/2] hmp queue

[Peter Maydell]

On 20 March 2018 at 12:41, Dr. David Alan Gilbert (git)
<dgilb...@redhat.com> wrote:
> From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
>
> The following changes since commit 4bdc24fa018901892bb8a5bd1808ebd605f4c64d:
>
>   Merge remote-tracking branch 'remotes/ericb/tags/pull-qapi-2018-03-12-v4' 
> into staging (2018-03-20 09:51:49 +)
>
> are available in the Git repository at:
>
>   git://github.com/dagrh/qemu.git tags/pull-hmp-20180320
>
> for you to fetch changes up to 95372184b7acdfd82ee748b6f0c6df1d839982ba:
>
>   hmp: free sev info (2018-03-20 12:32:06 +)
>
> 
> HMP fixes for 2.12
>
> 
> Marc-André Lureau (1):
>   hmp: free sev info
>
> zhangjixiang (1):
>   HMP: Initialize err before using
>

Applied, thanks.

-- PMM

[Qemu-devel] [PATCH v1 2/2] hw/rdma: Add support for Query QP verb to pvrdma device

[Yuval Shaia]

This IB verb is needed by some applications - implement it.

Signed-off-by: Yuval Shaia 
---
 hw/rdma/vmw/pvrdma_cmd.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma/vmw/pvrdma_cmd.c
index 293dfed29f..cf8c50af31 100644
--- a/hw/rdma/vmw/pvrdma_cmd.c
+++ b/hw/rdma/vmw/pvrdma_cmd.c
@@ -515,6 +515,28 @@ static int modify_qp(PVRDMADev *dev, union pvrdma_cmd_req 
*req,
 return rsp->hdr.err;
 }
 
+static int query_qp(PVRDMADev *dev, union pvrdma_cmd_req *req,
+ union pvrdma_cmd_resp *rsp)
+{
+struct pvrdma_cmd_query_qp *cmd = >query_qp;
+struct pvrdma_cmd_query_qp_resp *resp = >query_qp_resp;
+struct ibv_qp_init_attr init_attr;
+
+pr_dbg("qp_handle=%d\n", cmd->qp_handle);
+
+memset(rsp, 0, sizeof(*rsp));
+rsp->hdr.response = cmd->hdr.response;
+rsp->hdr.ack = PVRDMA_CMD_QUERY_QP_RESP;
+
+rsp->hdr.err = rdma_rm_query_qp(>rdma_dev_res, >backend_dev,
+cmd->qp_handle,
+(struct ibv_qp_attr *)>attrs, -1,
+_attr);
+
+pr_dbg("ret=%d\n", rsp->hdr.err);
+return rsp->hdr.err;
+}
+
 static int destroy_qp(PVRDMADev *dev, union pvrdma_cmd_req *req,
   union pvrdma_cmd_resp *rsp)
 {
@@ -636,7 +658,7 @@ static struct cmd_handler cmd_handlers[] = {
 {PVRDMA_CMD_DESTROY_CQ, destroy_cq},
 {PVRDMA_CMD_CREATE_QP, create_qp},
 {PVRDMA_CMD_MODIFY_QP, modify_qp},
-{PVRDMA_CMD_QUERY_QP, NULL},
+{PVRDMA_CMD_QUERY_QP, query_qp},
 {PVRDMA_CMD_DESTROY_QP, destroy_qp},
 {PVRDMA_CMD_CREATE_UC, create_uc},
 {PVRDMA_CMD_DESTROY_UC, destroy_uc},
-- 
2.13.6

[Qemu-devel] [PATCH v1 1/2] hw/rdma: Add Query QP operation

[Yuval Shaia]

This operation is needed by rdma devices - implement it.

Signed-off-by: Yuval Shaia 
---
 hw/rdma/rdma_backend.c | 12 
 hw/rdma/rdma_backend.h |  2 ++
 hw/rdma/rdma_rm.c  | 18 ++
 hw/rdma/rdma_rm.h  |  3 +++
 4 files changed, 35 insertions(+)

diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index ae7589c190..da2c8671e5 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -646,6 +646,18 @@ int rdma_backend_qp_state_rts(RdmaBackendQP *qp, uint8_t 
qp_type,
 return 0;
 }
 
+int rdma_backend_query_qp(RdmaBackendQP *qp, struct ibv_qp_attr *attr,
+  int attr_mask, struct ibv_qp_init_attr *init_attr)
+{
+if (!qp->ibqp) {
+pr_dbg("QP1\n");
+attr->qp_state = IBV_QPS_RTS;
+return 0;
+}
+
+return ibv_query_qp(qp->ibqp, attr, attr_mask, init_attr);
+}
+
 void rdma_backend_destroy_qp(RdmaBackendQP *qp)
 {
 if (qp->ibqp) {
diff --git a/hw/rdma/rdma_backend.h b/hw/rdma/rdma_backend.h
index 07f6fed768..6d9b45efe8 100644
--- a/hw/rdma/rdma_backend.h
+++ b/hw/rdma/rdma_backend.h
@@ -83,6 +83,8 @@ int rdma_backend_qp_state_rtr(RdmaBackendDev *backend_dev, 
RdmaBackendQP *qp,
   bool use_qkey);
 int rdma_backend_qp_state_rts(RdmaBackendQP *qp, uint8_t qp_type,
   uint32_t sq_psn, uint32_t qkey, bool use_qkey);
+int rdma_backend_query_qp(RdmaBackendQP *qp, struct ibv_qp_attr *attr,
+  int attr_mask, struct ibv_qp_init_attr *init_attr);
 void rdma_backend_destroy_qp(RdmaBackendQP *qp);
 
 void rdma_backend_post_send(RdmaBackendDev *backend_dev,
diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 296e40518e..a4e1de31fd 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -453,6 +453,24 @@ int rdma_rm_modify_qp(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
 return 0;
 }
 
+int rdma_rm_query_qp(RdmaDeviceResources *dev_res, RdmaBackendDev *backend_dev,
+ uint32_t qp_handle, struct ibv_qp_attr *attr,
+ int attr_mask, struct ibv_qp_init_attr *init_attr)
+{
+RdmaRmQP *qp;
+
+pr_dbg("qpn=%d\n", qp_handle);
+
+qp = rdma_rm_get_qp(dev_res, qp_handle);
+if (!qp) {
+return -EINVAL;
+}
+
+pr_dbg("qp_type=%d\n", qp->qp_type);
+
+return rdma_backend_query_qp(>backend_qp, attr, attr_mask, init_attr);
+}
+
 void rdma_rm_dealloc_qp(RdmaDeviceResources *dev_res, uint32_t qp_handle)
 {
 RdmaRmQP *qp;
diff --git a/hw/rdma/rdma_rm.h b/hw/rdma/rdma_rm.h
index be95c1b0f4..0528c1972b 100644
--- a/hw/rdma/rdma_rm.h
+++ b/hw/rdma/rdma_rm.h
@@ -59,6 +59,9 @@ int rdma_rm_modify_qp(RdmaDeviceResources *dev_res, 
RdmaBackendDev *backend_dev,
   union ibv_gid *dgid, uint32_t dqpn,
   enum ibv_qp_state qp_state, uint32_t qkey,
   uint32_t rq_psn, uint32_t sq_psn);
+int rdma_rm_query_qp(RdmaDeviceResources *dev_res, RdmaBackendDev *backend_dev,
+ uint32_t qp_handle, struct ibv_qp_attr *attr,
+ int attr_mask, struct ibv_qp_init_attr *init_attr);
 void rdma_rm_dealloc_qp(RdmaDeviceResources *dev_res, uint32_t qp_handle);
 
 int rdma_rm_alloc_cqe_ctx(RdmaDeviceResources *dev_res, uint32_t *cqe_ctx_id,
-- 
2.13.6

[Qemu-devel] ihw/rdma: Implementation of Query QP verb

[Yuval Shaia]

Please review implementation of Query QP verb which is needed by some RDMA
applications.

Patch #1: Implementation in rdma backend layer
Patch #2: Add support to pvrdma device

v0 -> v1:
* Split to two patches, one for rdma and one for pvrdma

[PATCH v1 1/2] hw/rdma: Add Query QP operation
[PATCH v1 2/2] hw/rdma: Add support for Query QP verb to pvrdma

Re: [Qemu-devel] [PATCH 10/10] linux-user: init_guest_space: Try to make ARM space+commpage continuous

[Peter Maydell]

On 20 March 2018 at 18:49, Luke Shumaker  wrote:
> On Fri, 02 Mar 2018 09:13:12 -0500,
> Peter Maydell wrote:
>> On 28 December 2017 at 18:08, Luke Shumaker  wrote:
>> > +guest_full_size =
>> > +(0x0f00 & qemu_host_page_mask) + qemu_host_page_size;
> ^
>> I think this is probably more clearly written as 0x1ULL,
>> since rounding down to the host-page-size then adding the host-page-size
>> gets us the full 32-bit size of the guest address space.
>
> Wait, is that right?  Isn't that only true if qemu_host_page_size is
> at least 8KiB (16 bits), enough to fill the zero in the middle?  Won't
> a typical qemu_host_page_size be only 4KiB?

Yeah, I just got the arithmetic wrong here because I had it
stuck in my head that the commpage was the top page of the
guest address space.

-- PMM

Re: [Qemu-devel] [PATCH for-2.12 12/12] qemu-iotests: Test vhdx image creation with QMP

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

Signed-off-by: Kevin Wolf 
---
  tests/qemu-iotests/213 | 349 +
  tests/qemu-iotests/213.out | 121 
  tests/qemu-iotests/group   |   1 +
  3 files changed, 471 insertions(+)
  create mode 100755 tests/qemu-iotests/213
  create mode 100644 tests/qemu-iotests/213.out




+
+echo
+echo "=== Invalid sizes ==="
+echo
+
+# TODO Negative image sizes aren't handled correctly, but this is a problem
+# with QAPI's implementation of the 'size' type and affects other commands as
+# well. Once this is fixed, we may want to add a test case here.
+
+# 1. 2^64 - 512
+# 2. 2^63 = 8 EB (qemu-img enforces image sizes less than this)
+# 3. 2^63 - 512 (generally valid, but with the crypto header the file will
+#exceed 63 bits)


Same comments as before on whether this comment is slightly stale after 
copy-and-paste.



+# 4. 2^46 + 1 (512 bytes more than maximum image size)


Does this image format require 512-byte alignment?  If so, are you 
missing a test of unaligned sizes?  If not, why not just 1 byte more 
than the maximum?


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

Re: [Qemu-devel] [PATCH v3] os: truncate pidfile on creation

[Eric Blake]

On 03/20/2018 01:11 PM, Florian Larysch wrote:

On Tue, Mar 20, 2018 at 01:00:40PM -0500, Eric Blake wrote:

Here after the --- is a nice place to summarize how v3 differs from
v2, to save reviewers some time.


The triviality of the change didn't seem to warrant that, but in
retrospect, I realize that searching for the sole trivial change when
reviewing a patch is also (or even more of) a burden. I'll keep that in
mind for the future.


Also, if all that is wrong is a typo in the commit message, a
maintainer is often willing to fix that up without you having to
send a new revision


I interpreted your comment on the v2 as a request for me to fix that.
Sorry for the churn.


No problem - it's okay to learn as you go (we were all once new 
contributors), and some things get easier the longer you've been on the 
list to see the balance between saving yourself time and saving 
reviewers/maintainers time.


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

Re: [Qemu-devel] [PATCH 10/10] linux-user: init_guest_space: Try to make ARM space+commpage continuous

[Laurent Vivier]

Le 20/03/2018 à 19:49, Luke Shumaker a écrit :
> On Fri, 02 Mar 2018 09:13:12 -0500,
> Peter Maydell wrote:
>> On 28 December 2017 at 18:08, Luke Shumaker  wrote:
>>> +guest_full_size =
>>> +(0x0f00 & qemu_host_page_mask) + qemu_host_page_size;
> ^
>> I think this is probably more clearly written as 0x1ULL,
>> since rounding down to the host-page-size then adding the host-page-size
>> gets us the full 32-bit size of the guest address space.
> 
> Wait, is that right?  Isn't that only true if qemu_host_page_size is
> at least 8KiB (16 bits), enough to fill the zero in the middle?  Won't
> a typical qemu_host_page_size be only 4KiB?
> 
>> That shows up that there's a potential problem here if the host
>> is 32-bit, because in that case guest_full_size (being only unsigned
>> long) will be 0, and we'll end up trying an mmap with an incorrect size.
>>
>>> +host_full_size = guest_full_size - guest_start;
>>> +real_start = (unsigned long)
>>> +mmap(NULL, host_full_size, PROT_NONE, flags, -1, 0);
>>
>> I think the general approach is right, though. Sorry it took so long
>> for us to get to reviewing this patchset.
> 
> It's all good.  I'm amazed at the amount of traffic qemu-devel gets!
> 
>> Incidentally, this code would be rather less complicated if it didn't
>> have to account for qemu_host_page_size not actually being the host
>> page size (since then you couldn't get a return from mmap() that wasn't
>> aligned properly). Does anybody know why we allow the user to specify
>> it on the command line? (git revision history doesn't help, it just says
>> there's been a -pagesize argument since commit 54936004fddc5 in 2003,
>> right back when mmap emulation was first added...)
> 
> I have no idea, I just assumed that it was a feature useful to people
> far smarter than me.
> 

I'm going to add this patch in my upcoming linux-user pull-request
(currently running regression tests).

Thanks,
Laurent

Re: [Qemu-devel] [PATCH 10/10] linux-user: init_guest_space: Try to make ARM space+commpage continuous

[Luke Shumaker]

On Fri, 02 Mar 2018 09:13:12 -0500,
Peter Maydell wrote:
> On 28 December 2017 at 18:08, Luke Shumaker  wrote:
> > +guest_full_size =
> > +(0x0f00 & qemu_host_page_mask) + qemu_host_page_size;
^
> I think this is probably more clearly written as 0x1ULL,
> since rounding down to the host-page-size then adding the host-page-size
> gets us the full 32-bit size of the guest address space.

Wait, is that right?  Isn't that only true if qemu_host_page_size is
at least 8KiB (16 bits), enough to fill the zero in the middle?  Won't
a typical qemu_host_page_size be only 4KiB?

> That shows up that there's a potential problem here if the host
> is 32-bit, because in that case guest_full_size (being only unsigned
> long) will be 0, and we'll end up trying an mmap with an incorrect size.
> 
> > +host_full_size = guest_full_size - guest_start;
> > +real_start = (unsigned long)
> > +mmap(NULL, host_full_size, PROT_NONE, flags, -1, 0);
> 
> I think the general approach is right, though. Sorry it took so long
> for us to get to reviewing this patchset.

It's all good.  I'm amazed at the amount of traffic qemu-devel gets!

> Incidentally, this code would be rather less complicated if it didn't
> have to account for qemu_host_page_size not actually being the host
> page size (since then you couldn't get a return from mmap() that wasn't
> aligned properly). Does anybody know why we allow the user to specify
> it on the command line? (git revision history doesn't help, it just says
> there's been a -pagesize argument since commit 54936004fddc5 in 2003,
> right back when mmap emulation was first added...)

I have no idea, I just assumed that it was a feature useful to people
far smarter than me.

-- 
Happy hacking,
~ Luke Shumaker

Re: [Qemu-devel] [PATCH for-2.12 11/12] vhdx: Check for 4 GB maximum log size on creation

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

It's unclear what the real maximum is, but we use an uint32_t to store
the log size in vhdx_co_create(), so we should check that the given
value fits in 32 bits.

Signed-off-by: Kevin Wolf 
---
  block/vhdx.c | 4 
  1 file changed, 4 insertions(+)


Reviewed-by: Eric Blake 



diff --git a/block/vhdx.c b/block/vhdx.c
index 0e48179b81..a1a0302799 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -1829,6 +1829,10 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
  if (!vhdx_opts->has_log_size) {
  log_size = DEFAULT_LOG_SIZE;
  } else {
+if (vhdx_opts->log_size > UINT32_MAX) {
+error_setg(errp, "Log size must be smaller than 4 GB");
+return -EINVAL;
+}
  log_size = vhdx_opts->log_size;
  }
  if (log_size < MiB || (log_size % MiB) != 0) {



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

Re: [Qemu-devel] [PATCH for-2.12 10/12] vhdx: Don't use error_setg_errno() with constant errno

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

error_setg_errno() is meant for cases where we got an errno from the OS
that can add useful extra information to an error message. It's
pointless if we pass a constant errno, these cases should use plain
error_setg().


Well, it DOES let you get the libc-specific spelling of the strerror for 
that errno (not all libc report the same string) - but you're right that 
it didn't add much here.




Signed-off-by: Kevin Wolf 
---
  block/vhdx.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)


Reviewed-by: Eric Blake 

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

Re: [Qemu-devel] [PATCH for-2.12 09/12] vhdx: Require power-of-two block size on create

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

Images with a non-power-of-two block size are invalid and cannot be
opened. Reject such block sizes when creating an image.

Signed-off-by: Kevin Wolf 
---
  block/vhdx.c | 4 
  1 file changed, 4 insertions(+)



Reviewed-by: Eric Blake 


diff --git a/block/vhdx.c b/block/vhdx.c
index f1b97f4b49..ca211a3196 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -1877,6 +1877,10 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
  error_setg_errno(errp, EINVAL, "Block size must be a multiple of 1 
MB");
  return -EINVAL;
  }
+if (!is_power_of_2(block_size)) {
+error_setg(errp, "Block size must be a power of two");
+return -EINVAL;
+}
  if (block_size > VHDX_BLOCK_SIZE_MAX) {
  error_setg_errno(errp, EINVAL, "Block size must not exceed %d",
   VHDX_BLOCK_SIZE_MAX);



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

Re: [Qemu-devel] [PATCH for-2.12 08/12] qemu-iotests: Test parallels image creation with QMP

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

Signed-off-by: Kevin Wolf 
---
  tests/qemu-iotests/212 | 326 +
  tests/qemu-iotests/212.out | 111 +++
  tests/qemu-iotests/group   |   1 +
  3 files changed, 438 insertions(+)
  create mode 100755 tests/qemu-iotests/212
  create mode 100644 tests/qemu-iotests/212.out




+echo
+echo "=== Invalid sizes ==="
+echo
+
+# TODO Negative image sizes aren't handled correctly, but this is a problem
+# with QAPI's implementation of the 'size' type and affects other commands as
+# well. Once this is fixed, we may want to add a test case here.
+
+# 1. Misaligned image size
+# 2. 2^64 - 512
+# 3. 2^63 = 8 EB (qemu-img enforces image sizes less than this)
+# 4. 2^63 - 512 (generally valid, but with the crypto header the file will
+#exceed 63 bits)


Is this part of the comment stale copy-and-paste? There's no crypto 
header, and the real max is much smaller...



+# 5. 2^52 (512 bytes more than maximum image size)
+



+echo
+echo "=== Invalid cluster size ==="
+echo
+

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

Re: [Qemu-devel] [PATCH for-2.12 07/12] parallels: Check maximum cluster size on create

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

It's unclear what the real maximum cluster size is for the Parallels
format, but let's at least make sure that we don't get integer
overflows in our .bdrv_co_create implementation.

Signed-off-by: Kevin Wolf 
---
  block/parallels.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/block/parallels.c b/block/parallels.c
index 2da5e56a9d..e4ca018c2e 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -526,6 +526,11 @@ static int coroutine_fn 
parallels_co_create(BlockdevCreateOptions* opts,
  cl_size = DEFAULT_CLUSTER_SIZE;
  }
  
+/* XXX What is the real limit here? This is an insanely large maximum. */

+if (cl_size >= UINT64_MAX / MAX_PARALLELS_IMAGE_FACTOR) {


INT64_MAX is probably a saner starting point for the division...


+error_setg(errp, "Cluster size is too large");
+return -EINVAL;
+}
  if (total_size >= MAX_PARALLELS_IMAGE_FACTOR * cl_size) {


since total_size still has to fit within off_t (63 bits, not 64)


  error_setg(errp, "Image size is too large for this cluster size");
  return -E2BIG;



With that change,
Reviewed-by: Eric Blake 

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

Re: [Qemu-devel] [PATCH for-2.12 06/12] qemu-iotests: Test invalid resize on luks

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

This tests that the .bdrv_truncate implementation for luks doesn't crash
for invalid image sizes.

Signed-off-by: Kevin Wolf 
---
  tests/qemu-iotests/210 | 37 +
  1 file changed, 37 insertions(+)


Missing a change to 210.out?

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

Re: [Qemu-devel] [PATCH v3 1/2] i386/kvm: add support for Hyper-V reenlightenment MSRs

[Eduardo Habkost]

On Tue, Mar 20, 2018 at 06:34:59PM +0100, Vitaly Kuznetsov wrote:
> KVM recently gained support for Hyper-V Reenlightenment MSRs which are
> required to make KVM-on-Hyper-V enable TSC page clocksource to its guests
> when INVTSC is not passed to it (and it is not passed by default in Qemu
> as it effectively blocks migration).
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
> Changes since v2:
> - add hv-reenlightenment CPU property [Roman Kagan, Paolo Bonzini]
> - add a comment to feature_word_info [Roman Kagan]
> ---
>  target/i386/cpu.c  |  4 +++-
>  target/i386/cpu.h  |  4 
>  target/i386/hyperv-proto.h |  9 -
>  target/i386/kvm.c  | 39 ++-
>  target/i386/machine.c  | 24 
>  5 files changed, 77 insertions(+), 3 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 6bb4ce8719..02579f8234 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -407,7 +407,8 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
> {
>  NULL /* hv_vpindex_access */, NULL /* hv_msr_reset_access */,
>  NULL /* hv_msr_stats_access */, NULL /* hv_reftsc_access */,
>  NULL /* hv_msr_idle_access */, NULL /* hv_msr_frequency_access 
> */,
> -NULL, NULL, NULL, NULL,
> +NULL /* hv_msr_debug_access */, NULL /* 
> hv_msr_reenlightenment_access */,
> +NULL, NULL,
>  NULL, NULL, NULL, NULL,
>  NULL, NULL, NULL, NULL,
>  NULL, NULL, NULL, NULL,
> @@ -4764,6 +4765,7 @@ static Property x86_cpu_properties[] = {
>  DEFINE_PROP_BOOL("hv-runtime", X86CPU, hyperv_runtime, false),
>  DEFINE_PROP_BOOL("hv-synic", X86CPU, hyperv_synic, false),
>  DEFINE_PROP_BOOL("hv-stimer", X86CPU, hyperv_stimer, false),
> +DEFINE_PROP_BOOL("hv-reenlightenment", X86CPU, hyperv_reenlightenment, 
> false),

Property is set to false by default, so compatibility is kept.

>  DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
>  DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
>  DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 2e2bab5ff3..98eed72937 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1174,6 +1174,9 @@ typedef struct CPUX86State {
>  uint64_t msr_hv_synic_sint[HV_SINT_COUNT];
>  uint64_t msr_hv_stimer_config[HV_STIMER_COUNT];
>  uint64_t msr_hv_stimer_count[HV_STIMER_COUNT];
> +uint64_t msr_hv_reenlightenment_control;
> +uint64_t msr_hv_tsc_emulation_control;
> +uint64_t msr_hv_tsc_emulation_status;
>  
>  uint64_t msr_rtit_ctrl;
>  uint64_t msr_rtit_status;
> @@ -1296,6 +1299,7 @@ struct X86CPU {
>  bool hyperv_runtime;
>  bool hyperv_synic;
>  bool hyperv_stimer;
> +bool hyperv_reenlightenment;
>  bool check_cpuid;
>  bool enforce_cpuid;
>  bool expose_kvm;
> diff --git a/target/i386/hyperv-proto.h b/target/i386/hyperv-proto.h
> index cb4d7f2b7a..93352ebd2a 100644
> --- a/target/i386/hyperv-proto.h
> +++ b/target/i386/hyperv-proto.h
> @@ -35,7 +35,7 @@
>  #define HV_RESET_AVAILABLE   (1u << 7)
>  #define HV_REFERENCE_TSC_AVAILABLE   (1u << 9)
>  #define HV_ACCESS_FREQUENCY_MSRS (1u << 11)
> -
> +#define HV_ACCESS_REENLIGHTENMENTS_CONTROL  (1u << 13)
>  
>  /*
>   * HV_CPUID_FEATURES.EDX bits
> @@ -129,6 +129,13 @@
>  #define HV_X64_MSR_CRASH_CTL0x4105
>  #define HV_CRASH_CTL_NOTIFY (1ull << 63)
>  
> +/*
> + * Reenlightenment notification MSRs
> + */
> +#define HV_X64_MSR_REENLIGHTENMENT_CONTROL  0x4106
> +#define HV_X64_MSR_TSC_EMULATION_CONTROL0x4107
> +#define HV_X64_MSR_TSC_EMULATION_STATUS 0x4108
> +
>  /*
>   * Hypercall status code
>   */
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index d23fff12f5..7d9f9ca0b1 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -90,6 +90,7 @@ static bool has_msr_hv_runtime;
>  static bool has_msr_hv_synic;
>  static bool has_msr_hv_stimer;
>  static bool has_msr_hv_frequencies;
> +static bool has_msr_hv_reenlightenment;
>  static bool has_msr_xss;
>  static bool has_msr_spec_ctrl;
>  static bool has_msr_smi_count;
> @@ -583,7 +584,8 @@ static bool hyperv_enabled(X86CPU *cpu)
>  cpu->hyperv_vpindex ||
>  cpu->hyperv_runtime ||
>  cpu->hyperv_synic ||
> -cpu->hyperv_stimer);
> +cpu->hyperv_stimer ||
> +cpu->hyperv_reenlightenment);
>  }
>  
>  static int kvm_arch_set_tsc_khz(CPUState *cs)
> @@ -654,6 +656,14 @@ static int hyperv_handle_properties(CPUState *cs)
>  env->features[FEAT_HYPERV_EDX] |= HV_FREQUENCY_MSRS_AVAILABLE;
>  }
>  }
> +if (cpu->hyperv_reenlightenment) {
> +if (!has_msr_hv_reenlightenment) {
> +fprintf(stderr,
> +

[Qemu-devel] [Bug 1740219] Re: static linux-user ARM emulation has several-second startup time

[LukeShu]

Everything except for the final patch (which has the actual fix) is now
applied on the master branch.

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

Title:
  static linux-user ARM emulation has several-second startup time

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Incomplete

Bug description:
  static linux-user emulation has several-second startup time

  My problem: I'm a Parabola packager, and I'm updating our
  qemu-user-static package from 2.8 to 2.11.  With my new
  statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true`
  went from taking 0.006s to 3s!  This does not happen with the normal
  dynamically linked 2.11, or the old static 2.8.

  What happens is it gets stuck in
  `linux-user/elfload.c:init_guest_space()`.  What `init_guest_space`
  does is map 2 parts of the address space: `[base, base+guest_size]`
  and `[base+0x, base+0x+page_size]`; where it must find
  an acceptable `base`.  Its strategy is to `mmap(NULL, guest_size,
  ...)` decide where the first range is, and then check if that
  +0x is also available.  If it isn't, then it starts trying
  `mmap(base, ...)` for the entire address space from low-address to
  high-address.

  "Normally," it finds an accaptable `base` within the first 2 tries.
  With a static 2.11, it's taking thousands of tries.

  

  Now, from my understanding, there are 2 factors working together to
  cause that in static 2.11 but not the other builds:

   - 2.11 increased the default `guest_size` from 0xf700 to 0x
   - PIE (and thus ASLR) is disabled for static builds

  For some reason that I don't understand, with the smaller
  `guest_size` the initial `mmap(NULL, guest_size, ...)` usually
  returns an acceptable address range; but larger `guest_size` makes it
  consistently return a block of memory that butts right up against
  another already mapped chunk of memory.  This isn't just true on the
  older builds, it's true with the 2.11 builds if I use the `-R` flag to
  shrink the `guest_size` back down to 0xf700.  That is with
  linux-hardened 4.13.13 on x86-64.

  So then, it it falls back to crawling the entire address space; so it
  tries base=0x1000.  With ASLR, that probably succeeds.  But with
  ASLR being disabled on static builds, the text segment is at
  0x6000; which is does not leave room for the needed
  0x1000-size block before it.  So then it tries base=0x2000.
  And so on, more than 6000 times until it finally gets to and passes
  the text segment; calling mmap more than 12000 times.

  

  I'm not sure what the fix is.  Perhaps try to mmap a continuous chunk
  of size 0x1000, then munmap it and then mmap the 2 chunks that we
  actually need.  The disadvantage to that is that it does not support
  the sparse address space that the current algorithm supports for
  `guest_size < 0x`.  If `guest_size < 0x` *and* the big
  mmap fails, then it could fall back to a sparse search; though I'm not
  sure the current algorithm is a good choice for it, as we see in this
  bug.  Perhaps it should inspect /proc/self/maps to try to find a
  suitable range before ever calling mmap?

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

Re: [Qemu-devel] [PATCH for-2.12 05/12] luks: Turn another invalid assertion into check

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

Commit e39e959e fixed an invalid assertion in the .bdrv_length
implementation, but left a similar assertion in place for
.bdrv_truncate. Instead of crashing when the user requests a too large
image size, fail gracefully.

A file size of exactly INT64_MAX caused failure before, but is actually
legal.

Signed-off-by: Kevin Wolf 
---
  block/crypto.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)


Reviewed-by: Eric Blake 

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

Re: [Qemu-devel] [PATCH for-2.12 04/12] qemu-iotests: Enable 025 for luks

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

We want to test resizing even for luks. The only change that is needed
is to explicitly zero out new space for luks because it's undefined.

Signed-off-by: Kevin Wolf 
---
  tests/qemu-iotests/025 | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)



Reviewed-by: Eric Blake 

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

Re: [Qemu-devel] [PATCH for-2.12 03/12] qemu-iotests: Test vdi image creation with QMP

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

Signed-off-by: Kevin Wolf 
---
  tests/qemu-iotests/211 | 256 +
  tests/qemu-iotests/211.out |  98 +
  tests/qemu-iotests/group   |   1 +
  3 files changed, 355 insertions(+)
  create mode 100755 tests/qemu-iotests/211
  create mode 100644 tests/qemu-iotests/211.out




+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+status=1   # failure is the default!


More of the useless boilerplate we've been meaning to clean up.  Oh well.



+# TODO Negative image sizes aren't handled correctly, but this is a problem
+# with QAPI's implementation of the 'size' type and affects other commands as
+# well. Once this is fixed, we may want to add a test case here.
+
+# 1. 2^64 - 512
+# 2. 2^63 = 8 EB (qemu-img enforces image sizes less than this)
+# 3. 2^63 - 512 (generally valid, but with the crypto header the file will
+#exceed 63 bits)
+# 4. 0x1f800 (maximum image size for VDI)
+# 5. (one byte more than maximum image size for VDI)


You list 5 cases...


+
+run_qemu -blockdev driver=file,filename="$TEST_IMG",node-name=node0 <

...but only four x-blockdev-create.  Why?

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

Re: [Qemu-devel] [PATCH] migration: Fix rate limiting issue on RDMA migration

[Juan Quintela]

Lidong Chen  wrote:
> RDMA migration implement save_page function for QEMUFile, but
> ram_control_save_page do not increase bytes_xfer. So when doing
> RDMA migration, it will use whole bandwidth.
>
> Signed-off-by: Lidong Chen 

Reviewed-by: Juan Quintela 

This part of the code is a mess.

To answer David:
- pos: Where we need to write that bit of stuff
- bytex_xfer: how much have we written

WHen we are doing snapshots on qcow2, we store memory in a contiguous
piece of memory, so we can "overwrite" that "page" if a new verion
cames. Nothing else (except the block) uses te "pos" parameter, so we
can't not trust on it.

And that  has been for a fast look at the code, that I got really
confused (again).



> ---
>  migration/qemu-file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/qemu-file.c b/migration/qemu-file.c
> index 2ab2bf3..217609d 100644
> --- a/migration/qemu-file.c
> +++ b/migration/qemu-file.c
> @@ -253,7 +253,7 @@ size_t ram_control_save_page(QEMUFile *f, ram_addr_t 
> block_offset,
>  if (f->hooks && f->hooks->save_page) {
>  int ret = f->hooks->save_page(f, f->opaque, block_offset,
>offset, size, bytes_sent);
> -
> +f->bytes_xfer += size;
>  if (ret != RAM_SAVE_CONTROL_DELAYED) {
>  if (bytes_sent && *bytes_sent > 0) {
>  qemu_update_position(f, *bytes_sent);

Re: [Qemu-devel] [PATCH for-2.12 02/12] vdi: Fix build with CONFIG_VDI_DEBUG

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

Use qemu_uuid_unparse() instead of uuid_unparse() to make vdi.c compile
again when CONFIG_VDI_DEBUG is set. In order to prevent future bitrot,
replace '#ifdef CONFIG_VDI_DEBUG' by 'if (VDI_DEBUG)' so that the
compiler always sees the code.

Signed-off-by: Kevin Wolf 
---
  block/vdi.c | 22 ++
  1 file changed, 10 insertions(+), 12 deletions(-)



Reviewed-by: Eric Blake 

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

Re: [Qemu-devel] [PATCH v2 1/2] i386/kvm: add support for Hyper-V reenlightenment MSRs

[Eduardo Habkost]

On Mon, Mar 19, 2018 at 06:29:08PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan  writes:
> 
> > On Fri, Mar 16, 2018 at 06:00:19PM +0100, Vitaly Kuznetsov wrote:
> >> KVM recently gained support for Hyper-V Reenlightenment MSRs which are
> >> required to make KVM-on-Hyper-V enable TSC page clocksource to its guests
> >> when INVTSC is not passed to it (and it is not passed by default in Qemu
> >> as it effectively blocks migration).
> >> 
> >> Signed-off-by: Vitaly Kuznetsov 
> >> ---
> >> Changes since v1:
> >> - add vmstate_msr_hyperv_reenlightenment subsection to vmstate_x86_cpu
> >>   [Paolo Bonzini]
> >> ---
[...]
> >> +
> >> +if (has_msr_hv_reenlightenment) {
> >> +env->features[FEAT_HYPERV_EAX] |=
> >> +HV_ACCESS_REENLIGHTENMENTS_CONTROL;
> >> +}
> >
> > Can you please add a matching comment to the definition of
> > feature_word_info[FEAT_HYPERV_EAX].feat_names[]?
> >
> 
> Sure, missed that.
> 
> > Also there appears to be no cpu property to turn this on/off, does it?
> > It's enabled based only on the support in the KVM it's running against.
> > So I guess we may have a problem migrating between the hosts with
> > different KVM versions, one supporting it and the other not.
> 
> Currently nested workloads don't migrate so I decided to take the
> opportunity and squeeze the new feature in without adding a new
> hv_reenlightenment cpu property (which would have to be added to libvirt
> at least).
> 
> > (This is also a problem with has_msr_hv_frequencies, and is in general a
> > long-standing issue of hv_* properties being done differently from the
> > rest of CPUID features.)
> 
> Suggestions? (To be honest I don't really like us adding new hv_*
> property for every new Hyper-V feature we support. I doubt anyone needs
> 'partial' Hyper-V emulation. It would be nice to have a single versioned
> 'hv' feature implying everything. We may then forbid migrations to older
> hv versions. But I don't really know the history of why we decided to go
> with a separate hv_* for every feature we add).

You will need "partial" emulation if you want to support
live-migration to/from a host where the KVM or QEMU don't support
all the features from the current host.

Is this something the current Hyper-V code already supports, or
it's something known to be broken?

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3 0/2] linux-headers: unistd.h fixups

[Peter Maydell]

On 20 March 2018 at 18:05, Michael S. Tsirkin  wrote:
> Cc MIPS maintainers.
> Can we drop the MIPS blacklist for kvm?
> Could you guys pls check?

My guess is that MIPS got blacklisted in 1842bdfdbac2ec4
because Marc-André didn't want to deal with the fact that
the mips unistd.h includes another header that would also
need to be synced. Marc-André, I don't suppose you can
remember your reasoning from three years back? :-)

thanks
-- PMM

Re: [Qemu-devel] [PATCH v3] os: truncate pidfile on creation

[Florian Larysch]

On Tue, Mar 20, 2018 at 01:00:40PM -0500, Eric Blake wrote:
> Here after the --- is a nice place to summarize how v3 differs from
> v2, to save reviewers some time. 

The triviality of the change didn't seem to warrant that, but in
retrospect, I realize that searching for the sole trivial change when
reviewing a patch is also (or even more of) a burden. I'll keep that in
mind for the future.

> Also, if all that is wrong is a typo in the commit message, a
> maintainer is often willing to fix that up without you having to
> send a new revision

I interpreted your comment on the v2 as a request for me to fix that.
Sorry for the churn.

Florian

Re: [Qemu-devel] [PATCH v3] RISC-V: Fix riscv_isa_string memory size bug

[Michael Clark]

On Mon, Mar 19, 2018 at 9:43 PM, Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 03/20/2018 02:35 AM, Michael Clark wrote:
> > FYI - I also have an experimental branch containing a RISC-V TCG back-end
> > that I started on during the RISC-V Hackathon in Portland last week:
> >
> > - https://github.com/michaeljclark/riscv-qemu/tree/wip-riscv-tcg-backend
>
> Cool.
>
> > I'm able to run a very simple x86_64 hello world program on RISC-V,
> > avoiding all of the usual libc startup. However, it may be some time
> before
> > I submit a patch series for this branch. So far the RISC-V TCG backend
> > doesn't implement softmmu, have bigendian byteswapping in its load/store
> > implementation ...
>
> Before you work too hard on this last, ping me.  I've been intending to
> change
> TCG such that hosts that do not support byte-swapping memory operations do
> not
> need to handle them specially.  Instead, we'd expand a "normal" byte swap
> from
> a temporary after a load (and similarly before a store).
>

Okay. I'll leave the byte swapping out for now. The first priority is to
test the basic codegen with little endian front-ends e.g. riscv -> riscv
and x86 -> riscv, and the second priority is to implement softmmu. I still
have some bugs as its pretty new code, but as I mentioned, the bones are
there. i.e. we have relocs and instruction encoders for riscv.


> I expect this to improve the state of affairs for i386 (without movbe),
> where
> we are currently extremely limited in the available registers.
>

Okay, so this would move byte swapping into TCG generic code instead of the
TCG backend, unless the backend explicitly supports load/store with byte
swap?

Re: [Qemu-devel] [PATCH v3 0/2] linux-headers: unistd.h fixups

[Michael S. Tsirkin]

Cc MIPS maintainers.
Can we drop the MIPS blacklist for kvm?
Could you guys pls check?

On Tue, Mar 20, 2018 at 07:52:51PM +0200, Michael S. Tsirkin wrote:
> It turns out that we have unistd.h for some architectures but not
> others.  We are thus unable to use e.g. usefaultfd on these systems.
> 
> Fix up update-linux-headers.sh to make sure we
> get it for all architectures which have linux-headers/
> (unfortunately this still does not mean "all linux systems").
> 
> Tested on x86 only.
> 
> Pls consider merging this through the migration tree.
> 
> Michael S. Tsirkin (2):
>   update-linux-headers.sh: add unistd.h
>   linux-headers: add asm-generic/unistd.h
> 
>  linux-headers/asm-arm/bitsperlong.h |   1 +
>  linux-headers/asm-arm64/bitsperlong.h   |  24 +
>  linux-headers/asm-generic/bitsperlong.h |  16 +
>  linux-headers/asm-generic/unistd.h  | 944 
> 
>  linux-headers/asm-mips/bitsperlong.h|   9 +
>  linux-headers/asm-mips/unistd.h |  44 +-
>  linux-headers/asm-powerpc/bitsperlong.h |  13 +
>  linux-headers/asm-s390/bitsperlong.h|  14 +
>  linux-headers/asm-x86/bitsperlong.h |  14 +
>  scripts/update-linux-headers.sh |  20 +-
>  10 files changed, 1086 insertions(+), 13 deletions(-)
>  create mode 100644 linux-headers/asm-arm/bitsperlong.h
>  create mode 100644 linux-headers/asm-arm64/bitsperlong.h
>  create mode 100644 linux-headers/asm-generic/bitsperlong.h
>  create mode 100644 linux-headers/asm-generic/unistd.h
>  create mode 100644 linux-headers/asm-mips/bitsperlong.h
>  create mode 100644 linux-headers/asm-powerpc/bitsperlong.h
>  create mode 100644 linux-headers/asm-s390/bitsperlong.h
>  create mode 100644 linux-headers/asm-x86/bitsperlong.h
> 
> -- 
> MST
> 

Re: [Qemu-devel] [PATCH for-2.12 01/12] vdi: Change 'static' create option to 'preallocation' in QMP

[Eric Blake]

On 03/20/2018 12:36 PM, Kevin Wolf wrote:

What static=on really does is what we call metadata preallocation for
other block drivers. While we can still change the QMP interface, make
it more consistent by using 'preallocation' for VDI, too.


The x- naming of the command means we don't HAVE to get this patch in 
for 2.12, but I agree that sooner is better than later and that doing 
this in 2.12 is worth the effort.




This doesn't implement any new functionality, so the only supported
preallocation modes are 'off' and 'metadata' for now.

Signed-off-by: Kevin Wolf 
---
  qapi/block-core.json |  6 ++
  block/vdi.c  | 24 ++--
  2 files changed, 24 insertions(+), 6 deletions(-)




+++ b/qapi/block-core.json
@@ -3834,16 +3834,14 @@
  #
  # @file Node to create the image format on
  # @size Size of the virtual disk in bytes
-# @static   Whether to create a statically (true) or
-#   dynamically (false) allocated image
-#   (default: false, i.e. dynamic)
+# @preallocationPreallocation mode for the new image (default: off)


Do we want to document that 'full' is not supported yet?  Or is just 
relying on the error message good enough?


Reviewed-by: Eric Blake 

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

Re: [Qemu-devel] [PULL v3 00/51] virtio, vhost, pci, pc: features, cleanups

[Peter Maydell]

On 20 March 2018 at 14:42, Michael S. Tsirkin  wrote:
> Note: only patch 39/51 is attached.
> The rest are unchanged from v2.
>
> The following changes since commit 026aaf47c02b79036feb830206cfebb2a726510d:
>
>   Merge remote-tracking branch 
> 'remotes/ehabkost/tags/python-next-pull-request' into staging (2018-03-13 
> 16:26:44 +)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to 1dc61e7b37d339c42ec9bd7a7eec1ef2c22f351c:
>
>   postcopy shared docs (2018-03-20 16:40:37 +0200)
>
> 
> virtio,vhost,pci,pc: features, cleanups
>
> SRAT tables for DIMM devices
> new virtio net flags for speed/duplex
> post-copy migration support in vhost
> cleanups in pci
>
> Signed-off-by: Michael S. Tsirkin 
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v2 1/3] update-linux-headers.sh: add unistd.h

[Paolo Bonzini]

On 20/03/2018 18:29, Michael S. Tsirkin wrote:
>> For MIPS, KVM is supposed to be properly supported these days, right?
>> That sounds like we should not be blacklisting them either, but instead
>> sorting out whatever issues it was that made us exclude them.
>
> I agree but I'd rather someone else looked at this.

Yeah, this doesn't look like the best time to change that.

Thanks,

Paolo

Re: [Qemu-devel] [PATCH 4/5] migration/block: limit the number of parallel I/O requests

[Juan Quintela]

Peter Lieven  wrote:
> the current implementation submits up to 512 I/O requests in parallel
> which is much to high especially for a background task.
> This patch adds a maximum limit of 16 I/O requests that can
> be submitted in parallel to avoid monopolizing the I/O device.
>
> Signed-off-by: Peter Lieven 

Reviewed-by: Juan Quintela 

PD.  I can't see a trivial way to change things without refactoring the
whole code.

> ---
>  migration/block.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/migration/block.c b/migration/block.c
> index 41b95d1..ce939e2 100644
> --- a/migration/block.c
> +++ b/migration/block.c
> @@ -37,6 +37,7 @@
>  #define MAX_IS_ALLOCATED_SEARCH (65536 * BDRV_SECTOR_SIZE)
>  
>  #define MAX_IO_BUFFERS 512
> +#define MAX_PARALLEL_IO 16
>  
>  //#define DEBUG_BLK_MIGRATION
>  
> @@ -775,6 +776,7 @@ static int block_save_iterate(QEMUFile *f, void *opaque)
>  while ((block_mig_state.submitted +
>  block_mig_state.read_done) * BLOCK_SIZE <
> qemu_file_get_rate_limit(f) &&
> +   block_mig_state.submitted < MAX_PARALLEL_IO &&
> (block_mig_state.submitted + block_mig_state.read_done) <
> MAX_IO_BUFFERS) {
>  blk_mig_unlock();

Re: [Qemu-devel] [PATCH 5/5] migration/block: compare only read blocks against the rate limiter

[Juan Quintela]

Peter Lieven  wrote:
> only read_done blocks are in the queued to be flushed to the migration
> stream. submitted blocks are still in flight.
>
> Signed-off-by: Peter Lieven 

Reviewed-by: Juan Quintela 


> ---
>  migration/block.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/migration/block.c b/migration/block.c
> index ce939e2..4e950c2 100644
> --- a/migration/block.c
> +++ b/migration/block.c
> @@ -773,8 +773,7 @@ static int block_save_iterate(QEMUFile *f, void *opaque)
>  
>  /* control the rate of transfer */
>  blk_mig_lock();
> -while ((block_mig_state.submitted +
> -block_mig_state.read_done) * BLOCK_SIZE <
> +while (block_mig_state.read_done * BLOCK_SIZE <
> qemu_file_get_rate_limit(f) &&
> block_mig_state.submitted < MAX_PARALLEL_IO &&
> (block_mig_state.submitted + block_mig_state.read_done) <

Re: [Qemu-devel] [PATCH v3 4/7] s390x/kvm: interface to interpret AP instructions

[Tony Krowiak]

On 03/15/2018 07:24 PM, Tony Krowiak wrote:

The VFIO AP device exploits interpretive execution of AP
instructions (APIE). APIE is enabled by setting a device attribute
via the KVM_SET_DEVICE_ATTR ioctl.

Signed-off-by: Tony Krowiak 
---
  target/s390x/kvm.c   |   16 
  target/s390x/kvm_s390x.h |2 ++
  2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 33e5ec3..2812e28 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -277,6 +277,22 @@ static void kvm_s390_init_dea_kw(void)
  }
  }

+int kvm_s390_set_interpret_ap(uint8_t enable)
+{
+struct kvm_device_attr attribute = {
+.group = KVM_S390_VM_CRYPTO,
+.attr  = KVM_S390_VM_CRYPTO_INTERPRET_AP,
+.addr = 1,
+};
+
+if (!kvm_vm_check_attr(kvm_state, KVM_S390_VM_CRYPTO,
+   KVM_S390_VM_CRYPTO_INTERPRET_AP)) {
+return -EOPNOTSUPP;
+}
+
+return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, );
+}
I proposed removing the KVM_S390_VM_CRYPTO_INTERPRET_AP device attribute 
from the kernel in
Message ID <1347ed2e-7bdb-e455-971a-cf60899e3...@linux.vnet.ibm.com> on 
the kernel mailing list
and proposed setting interpretive execution for AP instructions via the 
mdev open callback. That

would eliminate the need for this patch.

+
  void kvm_s390_crypto_reset(void)
  {
  if (s390_has_feat(S390_FEAT_MSA_EXT_3)) {
diff --git a/target/s390x/kvm_s390x.h b/target/s390x/kvm_s390x.h
index 34ee7e7..0d6c6e7 100644
--- a/target/s390x/kvm_s390x.h
+++ b/target/s390x/kvm_s390x.h
@@ -40,4 +40,6 @@ void kvm_s390_crypto_reset(void);
  void kvm_s390_restart_interrupt(S390CPU *cpu);
  void kvm_s390_stop_interrupt(S390CPU *cpu);

+int kvm_s390_set_interpret_ap(uint8_t enable);
+
  #endif /* KVM_S390X_H */

Re: [Qemu-devel] [PATCH v3] os: truncate pidfile on creation

[Eric Blake]

On 03/20/2018 12:33 PM, Florian Larysch wrote:

qemu_create_pidfile does not truncate the pidfile when it creates it,
but rather overwrites its contents with the new pid. This works fine as
long as the length of the pid doesn't decrease, but this might happen in
case of wraparounds, causing pidfiles to contain trailing garbage which
breaks operations such as 'kill $(cat pidfile)'.

Instead, always truncate the file before writing it.

Note that the order is important here: We cannot simply use O_TRUNC in
the open() call because another qemu process might truncate the pidfile
of a process that is still running before reaching the lockf() barrier.

The Windows version suffers from a similar problem, but as it does not
provide effective mutual exclusion anyway (because the file handle is
closed immediately after writing to it), adopting this behavior still
seems to be an improvement, as it at least prevents garbled pidfiles.

Signed-off-by: Florian Larysch 
---


Here after the --- is a nice place to summarize how v3 differs from v2, 
to save reviewers some time.  In this particular case, it looks like all 
you did was correct a commit message typo in v2; at which point, since I 
gave Reviewed-by on v2, you could have pasted that into your amended v3 
commit message to make it obvious that you didn't change the code.  At 
any rate, my R-b still stands.


Also, if all that is wrong is a typo in the commit message, a maintainer 
is often willing to fix that up without you having to send a new 
revision, especially since the maintainer has to edit the commit message 
anyways to add their Signed-off-by.  But you are also correct that a new 
revision CAN save a maintainer time, in part because adding S-o-b can be 
done by machine alone, so it is not a worthless exercise on your part to 
send a respin just for typos.



  os-posix.c | 6 ++
  os-win32.c | 2 +-
  2 files changed, 7 insertions(+), 1 deletion(-)



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

Re: [Qemu-devel] [PATCH v4 2/5] target/i386: Populate AMD Processor Cache Information

[Eduardo Habkost]

On Tue, Mar 20, 2018 at 05:25:52PM +, Moger, Babu wrote:
> Hi Eduardo, Thanks for the comments. Please see the response inline.
> 
> > -Original Message-
> > From: Eduardo Habkost 
> > Sent: Friday, March 16, 2018 1:00 PM
> > To: Moger, Babu 
> > Cc: pbonz...@redhat.com; r...@twiddle.net; rkrc...@redhat.com;
> > Lendacky, Thomas ; Singh, Brijesh
> > ; k...@vger.kernel.org; k...@tripleback.net;
> > mtosa...@redhat.com; Hook, Gary ; qemu-
> > de...@nongnu.org
> > Subject: Re: [Qemu-devel] [PATCH v4 2/5] target/i386: Populate AMD
> > Processor Cache Information
> > 
> > On Mon, Mar 12, 2018 at 05:00:46PM -0400, Babu Moger wrote:
> > > From: Stanislav Lanci 
> > >
> > > Add information for cpuid 0x801D leaf. Populate cache topology
> > information
> > > for different cache types(Data Cache, Instruction Cache, L2 and L3)
> > supported
> > > by 0x801D leaf. Please refer Processor Programming Reference (PPR)
> > for AMD
> > > Family 17h Model for more details.
> > >
> > > Signed-off-by: Stanislav Lanci 
> > > Signed-off-by: Babu Moger 
> > 
> > The new CPUID leaves don't seem to match the existing AMD cache
> > information
> > leaves.  Is this intentional?  Why?
> 
> It is not intentional. These values are from older family of processors. 
> These values have changed from Family 14  or later.
> The latest one is Family 17. You can see the differences here.
>  https://support.amd.com/TechDocs/41131.pdf
> https://support.amd.com/TechDocs/55072_AMD_Family_15h_Models_70h-7Fh_BKDG.pdf
> https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
> 
> Some of these are bugs in our code. For some we need to add checks for the 
> family and correct these values.
> You understand the code much better than me. Correct me if I missed 
> something. 
> 
> Note that older family of processors don't support topology extensions.  

If you want to make the cache size/topology look different
depending on the CPU model/options, this would require more work,
but it would be an interesting feature.

The "i386: Helpers to encode cache information consistently"
patch I sent last week might be a useful starting point for that.

If you plan to implement that, please keep in mind that existing
CPUID cache info needs to be kept on previous machine-types (this
is implemented by adding QOM properties that can be used to
enable the old behavior, and by setting them at
MachineClass::compat_props).

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 3/3] postcopy: drop unnecessary conditions

[Michael S. Tsirkin]

On Tue, Mar 20, 2018 at 07:17:35PM +0200, Michael S. Tsirkin wrote:
> We have our own copy of unistd so there is no
> need to check for symbols present there.
> 
> Signed-off-by: Michael S. Tsirkin 

Self-Nack

pls ignore - we do not have unistd.h on all systems unfortunately.

Will send v3 without this patch and with more tweaks.

> ---
>  migration/postcopy-ram.c | 4 +---
>  tests/migration-test.c   | 2 +-
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
> index efd7793..027c02c 100644
> --- a/migration/postcopy-ram.c
> +++ b/migration/postcopy-ram.c
> @@ -86,7 +86,7 @@ int postcopy_notify(enum PostcopyNotifyReason reason, Error 
> **errp)
>  #include  /* for __u64 */
>  #endif
>  
> -#if defined(__linux__) && defined(__NR_userfaultfd) && 
> defined(CONFIG_EVENTFD)
> +#if defined(__linux__) && defined(CONFIG_EVENTFD)
>  #include 
>  #include 
>  
> @@ -97,7 +97,6 @@ int postcopy_notify(enum PostcopyNotifyReason reason, Error 
> **errp)
>   *
>   * Returns: true on success
>   *
> - * __NR_userfaultfd - should be checked before
>   *  @features: out parameter will contain uffdio_api.features provided by 
> kernel
>   *  in case of success
>   */
> @@ -107,7 +106,6 @@ static bool receive_ufd_features(uint64_t *features)
>  int ufd;
>  bool ret = true;
>  
> -/* if we are here __NR_userfaultfd should exists */
>  ufd = syscall(__NR_userfaultfd, O_CLOEXEC);
>  if (ufd == -1) {
>  error_report("%s: syscall __NR_userfaultfd failed: %s", __func__,
> diff --git a/tests/migration-test.c b/tests/migration-test.c
> index 422bf1a..e5dcedb 100644
> --- a/tests/migration-test.c
> +++ b/tests/migration-test.c
> @@ -32,7 +32,7 @@ bool got_stop;
>  #include 
>  #endif
>  
> -#if defined(__linux__) && defined(__NR_userfaultfd) && 
> defined(CONFIG_EVENTFD)
> +#if defined(__linux__) && defined(CONFIG_EVENTFD)
>  #include 
>  #include 
>  #include 
> -- 
> MST
> 

Re: [Qemu-devel] [PATCH for-2.12] qcow2: Reset free_cluster_index when allocating a new refcount block

[Eric Blake]

On 03/20/2018 08:55 AM, Alberto Garcia wrote:

When we try to allocate new clusters we first look for available ones
starting from s->free_cluster_index and once we find them we increase
their reference counts. Before we get to call update_refcount() to do
this last step s->free_cluster_index is already pointing to the next
cluster after the ones we are trying to allocate.


> During update_refcount() it may happen however that we also need to
> allocate a new refcount block in order to store the refcounts of these
> new clusters

Your changes to test 121 covers this...

> (and to complicate things further that may also require
> us to grow the refcount table).

...but not this.  Is it worth also trying to cover this case in the 
testsuite as well?  Probably made easier if you use a refcount_order of 
6 instead of the default of 4, so that it is easier to make the refcount 
table spill into a second cluster because refcount blocks have fewer 
entries.



This can be reproduced easily:

  qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
  qemu-io -c 'write 0 124k' hd.qcow2

After this the image has 132608 bytes (256 clusters), and the refcount
block is full. If we write 512 more bytes it should allocate two new
clusters: the data cluster itself and a new refcount block.

  qemu-io -c 'write 124k 512' hd.qcow2


Nice test case!  And yes, 512-byte clusters are easier for proving when 
we have inefficient allocation strategies.



What this patch does is reset s->free_cluster_index to its previous
value when alloc_refcount_block() returns -EAGAIN. This way the caller
will try to allocate again the original clusters if they are still
free.

The output of iotest 026 also needs to be updated because now that
images have no holes some tests fail at a different point and the
number of leaked clusters is different.

Signed-off-by: Alberto Garcia 
---
  block/qcow2-refcount.c |  7 +++
  tests/qemu-iotests/026.out |  6 +++---
  tests/qemu-iotests/121 | 20 
  tests/qemu-iotests/121.out | 10 ++
  4 files changed, 40 insertions(+), 3 deletions(-)


Long-standing bug, but it IS a bug fix, so I think it is safe for 2.12.



+/* If the caller needs to restart the search for free clusters,
+ * try the same ones first to see if they're still free. */
+if (ret == -EAGAIN) {
+if (s->free_cluster_index > (start >> s->cluster_bits)) {
+s->free_cluster_index = (start >> s->cluster_bits);
+}


Is there any harm in making this assignment unconditional, instead of 
only doing it when free_cluster_index has grown larger than start?  [And 
unrelated, but it might be nice to do a followup cleanup to track 
free_cluster_offset by bytes instead of having to shift 
free_cluster_index everywhere]


At any rate, my comments can be deferred to later if desired, so

Reviewed-by: Eric Blake 

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

[Qemu-devel] [PATCH v3 2/2] linux-headers: add asm-generic/unistd.h

[Michael S. Tsirkin]

ARM64 and MIPS depend on asm-generic/unistd.h for syscall numbers.
This adds asm-generic/unistd.h and it's dependencies.

Signed-off-by: Michael S. Tsirkin 
---
 linux-headers/asm-arm/bitsperlong.h |   1 +
 linux-headers/asm-arm64/bitsperlong.h   |  24 +
 linux-headers/asm-generic/bitsperlong.h |  16 +
 linux-headers/asm-generic/unistd.h  | 944 
 linux-headers/asm-mips/bitsperlong.h|   9 +
 linux-headers/asm-mips/unistd.h |  44 +-
 linux-headers/asm-powerpc/bitsperlong.h |  13 +
 linux-headers/asm-s390/bitsperlong.h|  14 +
 linux-headers/asm-x86/bitsperlong.h |  14 +
 9 files changed, 1073 insertions(+), 6 deletions(-)
 create mode 100644 linux-headers/asm-arm/bitsperlong.h
 create mode 100644 linux-headers/asm-arm64/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/unistd.h
 create mode 100644 linux-headers/asm-mips/bitsperlong.h
 create mode 100644 linux-headers/asm-powerpc/bitsperlong.h
 create mode 100644 linux-headers/asm-s390/bitsperlong.h
 create mode 100644 linux-headers/asm-x86/bitsperlong.h

diff --git a/linux-headers/asm-arm/bitsperlong.h 
b/linux-headers/asm-arm/bitsperlong.h
new file mode 100644
index 000..6dc0bb0
--- /dev/null
+++ b/linux-headers/asm-arm/bitsperlong.h
@@ -0,0 +1 @@
+#include 
diff --git a/linux-headers/asm-arm64/bitsperlong.h 
b/linux-headers/asm-arm64/bitsperlong.h
new file mode 100644
index 000..485d60b
--- /dev/null
+++ b/linux-headers/asm-arm64/bitsperlong.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_BITSPERLONG_H
+#define __ASM_BITSPERLONG_H
+
+#define __BITS_PER_LONG 64
+
+#include 
+
+#endif /* __ASM_BITSPERLONG_H */
diff --git a/linux-headers/asm-generic/bitsperlong.h 
b/linux-headers/asm-generic/bitsperlong.h
new file mode 100644
index 000..0aac245
--- /dev/null
+++ b/linux-headers/asm-generic/bitsperlong.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef __ASM_GENERIC_BITS_PER_LONG
+#define __ASM_GENERIC_BITS_PER_LONG
+
+/*
+ * There seems to be no way of detecting this automatically from user
+ * space, so 64 bit architectures should override this in their
+ * bitsperlong.h. In particular, an architecture that supports
+ * both 32 and 64 bit user space must not rely on CONFIG_64BIT
+ * to decide it, but rather check a compiler provided macro.
+ */
+#ifndef __BITS_PER_LONG
+#define __BITS_PER_LONG 32
+#endif
+
+#endif /* __ASM_GENERIC_BITS_PER_LONG */
diff --git a/linux-headers/asm-generic/unistd.h 
b/linux-headers/asm-generic/unistd.h
new file mode 100644
index 000..8b87de0
--- /dev/null
+++ b/linux-headers/asm-generic/unistd.h
@@ -0,0 +1,944 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#include 
+
+/*
+ * This file contains the system call numbers, based on the
+ * layout of the x86-64 architecture, which embeds the
+ * pointer to the syscall in the table.
+ *
+ * As a basic principle, no duplication of functionality
+ * should be added, e.g. we don't use lseek when llseek
+ * is present. New architectures should use this file
+ * and implement the less feature-full calls in user space.
+ */
+
+#ifndef __SYSCALL
+#define __SYSCALL(x, y)
+#endif
+
+#if __BITS_PER_LONG == 32 || defined(__SYSCALL_COMPAT)
+#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _32)
+#else
+#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _64)
+#endif
+
+#ifdef __SYSCALL_COMPAT
+#define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _comp)
+#define __SC_COMP_3264(_nr, _32, _64, _comp) __SYSCALL(_nr, _comp)
+#else
+#define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _sys)
+#define __SC_COMP_3264(_nr, _32, _64, _comp) __SC_3264(_nr, _32, _64)
+#endif
+
+#define __NR_io_setup 0
+__SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup)
+#define __NR_io_destroy 1
+__SYSCALL(__NR_io_destroy, sys_io_destroy)
+#define __NR_io_submit 2
+__SC_COMP(__NR_io_submit, sys_io_submit, compat_sys_io_submit)
+#define __NR_io_cancel 3
+__SYSCALL(__NR_io_cancel, sys_io_cancel)
+#define __NR_io_getevents 4
+__SC_COMP(__NR_io_getevents, sys_io_getevents, compat_sys_io_getevents)
+
+/* fs/xattr.c */
+#define __NR_setxattr 5
+__SYSCALL(__NR_setxattr, sys_setxattr)
+#define __NR_lsetxattr 6
+__SYSCALL(__NR_lsetxattr, 

Re: [Qemu-devel] Moving seabios-hppa git submodule to use a qemu.org mirror

[Paolo Bonzini]

On 19/03/2018 20:06, Jeff Cody wrote:
> On Mon, Mar 19, 2018 at 01:19:36PM +, Peter Maydell wrote:
>> On 21 February 2018 at 05:27, Jeff Cody  wrote:
>>> On Tue, Feb 20, 2018 at 06:43:22PM +, Peter Maydell wrote:
 I just noticed that we seem to have acquired another git
 submodule that isn't pointing to a qemu.org git url:

 [submodule "roms/seabios-hppa"]
 path = roms/seabios-hppa
 url = git://github.com/hdeller/seabios-hppa.git

 Jeff, could we set up so we can mirror this repo on qemu.org?
 Then we can send a patch to update the .gitmodules to point to it.

>>>
>>> Yes, of course... Although Paolo has suggested making it a branch of the
>>> existing SeaBIOS repo instead.  But I can go ahead and get the clone setup,
>>> in case we go that route.
>>
>> Hi; can we get the mirror set up for seabios-hppa, and also for
>> the other new repo:
>>  git://github.com/zbalaton/u-boot-sam460ex
>>
>> please?
>>
>> (I've just sent a patch which moves the qemu-palcode module
>> to the already-existing mirror.)
>>
>> thanks
>> -- PMM
> 
> 
> Hi,
> 
> Both of these mirrors have been created, and are set to automatically
> refresh like the other mirrors on qemu.org:
> 
> git://git.qemu.org/u-boot-sam460ex.git
> https://git.qemu.org/git/u-boot-sam460ex.git
> 
> 
> git://git.qemu.org/seabios-hppa.git
> https://git.qemu.org/git/seabios-hppa.git
> 
> 
> Let me know if there are any issues.
> 
> 
> Paolo or Stefan,
> 
> If you create the repos for each of these under the qemu user on github,
> I'll also enable pushing of these two mirrors to github (like we do with
> other mirrors).

Done.

Paolo

[Qemu-devel] [PATCH v3 0/2] linux-headers: unistd.h fixups

[Michael S. Tsirkin]

It turns out that we have unistd.h for some architectures but not
others.  We are thus unable to use e.g. usefaultfd on these systems.

Fix up update-linux-headers.sh to make sure we
get it for all architectures which have linux-headers/
(unfortunately this still does not mean "all linux systems").

Tested on x86 only.

Pls consider merging this through the migration tree.

Michael S. Tsirkin (2):
  update-linux-headers.sh: add unistd.h
  linux-headers: add asm-generic/unistd.h

 linux-headers/asm-arm/bitsperlong.h |   1 +
 linux-headers/asm-arm64/bitsperlong.h   |  24 +
 linux-headers/asm-generic/bitsperlong.h |  16 +
 linux-headers/asm-generic/unistd.h  | 944 
 linux-headers/asm-mips/bitsperlong.h|   9 +
 linux-headers/asm-mips/unistd.h |  44 +-
 linux-headers/asm-powerpc/bitsperlong.h |  13 +
 linux-headers/asm-s390/bitsperlong.h|  14 +
 linux-headers/asm-x86/bitsperlong.h |  14 +
 scripts/update-linux-headers.sh |  20 +-
 10 files changed, 1086 insertions(+), 13 deletions(-)
 create mode 100644 linux-headers/asm-arm/bitsperlong.h
 create mode 100644 linux-headers/asm-arm64/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/bitsperlong.h
 create mode 100644 linux-headers/asm-generic/unistd.h
 create mode 100644 linux-headers/asm-mips/bitsperlong.h
 create mode 100644 linux-headers/asm-powerpc/bitsperlong.h
 create mode 100644 linux-headers/asm-s390/bitsperlong.h
 create mode 100644 linux-headers/asm-x86/bitsperlong.h

-- 
MST

[Qemu-devel] [PATCH v3 1/2] update-linux-headers.sh: add unistd.h

[Michael S. Tsirkin]

Rework the update script slightly, add the unistd.h header and its
dependencies on all architectures.

This also removes the IA64 from a KVM blacklist (Linux dropped this
architecture for KVM), and adds a comment so we remember to try and
un-blacklist KVM on MIPS.

Signed-off-by: Michael S. Tsirkin 
---
 scripts/update-linux-headers.sh | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index d18e2f1..0999ccf 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -80,11 +80,6 @@ for arch in $ARCHLIST; do
 continue
 fi
 
-# Blacklist architectures which have KVM headers but are actually dead
-if [ "$arch" = "ia64" -o "$arch" = "mips" ]; then
-continue
-fi
-
 if [ "$arch" = x86 ]; then
 arch_var=SRCARCH
 else
@@ -95,9 +90,20 @@ for arch in $ARCHLIST; do
 
 rm -rf "$output/linux-headers/asm-$arch"
 mkdir -p "$output/linux-headers/asm-$arch"
-for header in kvm.h kvm_para.h unistd.h; do
+for header in unistd.h bitsperlong.h; do
 cp "$tmpdir/include/asm/$header" "$output/linux-headers/asm-$arch"
 done
+
+# Below blacklists KVM on MIPS since we did this historically, even though
+# KVM on MIPS is supposed to be properly supported these days.
+# TODO: we should not be blacklisting it, but instead sorting out whatever
+# issues it has that made us exclude it.
+if [ "$arch" != "mips" ]; then
+for header in kvm.h kvm_para.h; do
+cp "$tmpdir/include/asm/$header" "$output/linux-headers/asm-$arch"
+done
+fi
+
 if [ $arch = powerpc ]; then
 cp "$tmpdir/include/asm/epapr_hcalls.h" 
"$output/linux-headers/asm-powerpc/"
 fi
@@ -130,7 +136,7 @@ for header in kvm.h kvm_para.h vfio.h vfio_ccw.h vhost.h \
 done
 rm -rf "$output/linux-headers/asm-generic"
 mkdir -p "$output/linux-headers/asm-generic"
-for header in kvm_para.h; do
+for header in kvm_para.h bitsperlong.h unistd.h; do
 cp "$tmpdir/include/asm-generic/$header" 
"$output/linux-headers/asm-generic"
 done
 if [ -L "$linux/source" ]; then
-- 
MST

[Qemu-devel] [PATCH for-2.12 08/12] qemu-iotests: Test parallels image creation with QMP

[Kevin Wolf]

Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/212 | 326 +
 tests/qemu-iotests/212.out | 111 +++
 tests/qemu-iotests/group   |   1 +
 3 files changed, 438 insertions(+)
 create mode 100755 tests/qemu-iotests/212
 create mode 100644 tests/qemu-iotests/212.out

diff --git a/tests/qemu-iotests/212 b/tests/qemu-iotests/212
new file mode 100755
index 00..112a8420ce
--- /dev/null
+++ b/tests/qemu-iotests/212
@@ -0,0 +1,326 @@
+#!/bin/bash
+#
+# Test parallels and file image creation
+#
+# Copyright (C) 2018 Red Hat, Inc.
+#
+# 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 .
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+status=1   # failure is the default!
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt parallels
+_supported_proto file
+_supported_os Linux
+
+function do_run_qemu()
+{
+echo Testing: "$@"
+$QEMU -nographic -qmp stdio -serial none "$@"
+echo
+}
+
+function run_qemu()
+{
+do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qmp \
+  | _filter_qemu | _filter_imgfmt \
+  | _filter_actual_image_size
+}
+
+echo
+echo "=== Successful image creation (defaults) ==="
+echo
+
+size=$((128 * 1024 * 1024))
+
+run_qemu <

[Qemu-devel] [PATCH for-2.12 09/12] vhdx: Require power-of-two block size on create

[Kevin Wolf]

Images with a non-power-of-two block size are invalid and cannot be
opened. Reject such block sizes when creating an image.

Signed-off-by: Kevin Wolf 
---
 block/vhdx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/block/vhdx.c b/block/vhdx.c
index f1b97f4b49..ca211a3196 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -1877,6 +1877,10 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
 error_setg_errno(errp, EINVAL, "Block size must be a multiple of 1 
MB");
 return -EINVAL;
 }
+if (!is_power_of_2(block_size)) {
+error_setg(errp, "Block size must be a power of two");
+return -EINVAL;
+}
 if (block_size > VHDX_BLOCK_SIZE_MAX) {
 error_setg_errno(errp, EINVAL, "Block size must not exceed %d",
  VHDX_BLOCK_SIZE_MAX);
-- 
2.13.6

Re: [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

[Michael S. Tsirkin]

On Tue, Mar 20, 2018 at 05:34:01PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > > Using <> for system include files and "" for local include files is a
> > > convention, and as far as I know most projects adhere to that
> > > convention. So does QEMU currently. Such conventions are not only
> > > important for humans, but also for tools. There are more tools than the
> > > C preprocessor which handle <> and "" differently. For example the GNU
> > > compiler uses -MD or -MMD to automatically generate dependency rules for
> > > make. While -MD generates dependencies to all include files, -MMD does
> > > so only for user include files, but not for system include files. "user"
> > > and "system" means the different forms how include statements are
> > > written. QEMU still seems to use -MMD:
> > > 
> > > rules.mak:QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(@D)/$(*F).d
> > 
> > To my knowledge, and according to my limited testing,
> > system headers in this context means
> > the default ones not supplied with -I.
> 
> GCC's definition of system header is here:
> 
>   https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
> 
> 
> Regards,
> Daniel

Proves my point, does it not?  You will note that it does not refer to
include <> anywhere.

2.8 System Headers
The header files declaring interfaces to the operating system and runtime 
libraries often cannot be written in strictly conforming C. Therefore, GCC 
gives code found in system headers special treatment. All warnings, other than 
those generated by ‘#warning’ (see Diagnostics), are suppressed while GCC is 
processing a system header. Macros defined in a system header are immune to a 
few warnings wherever they are expanded. This immunity is granted on an ad-hoc 
basis, when we find that a warning generates lots of false positives because of 
code in macros defined in system headers.

Normally, only the headers found in specific directories are considered 
system headers. These directories are determined when GCC is compiled. There 
are, however, two ways to make normal headers into system headers:

Header files found in directories added to the search path with the 
-isystem and -idirafter command-line options are treated as system headers for 
the purposes of diagnostics.
There is also a directive, #pragma GCC system_header, which tells GCC to 
consider the rest of the current include file a system header, no matter where 
it was found. Code that comes before the ‘#pragma’ in the file is not affected. 
#pragma GCC system_header has no effect in the primary source file.


Conclusion: #include <> is ignored for purposes of determining whether a header 
is
a system one or not.


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

[Qemu-devel] [PATCH for-2.12 06/12] qemu-iotests: Test invalid resize on luks

[Kevin Wolf]

This tests that the .bdrv_truncate implementation for luks doesn't crash
for invalid image sizes.

Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/210 | 37 +
 1 file changed, 37 insertions(+)

diff --git a/tests/qemu-iotests/210 b/tests/qemu-iotests/210
index 96a5213e77..e607c0d296 100755
--- a/tests/qemu-iotests/210
+++ b/tests/qemu-iotests/210
@@ -204,6 +204,43 @@ run_qemu -blockdev 
driver=file,filename="$TEST_IMG_FILE",node-name=node0 \
 { "execute": "quit" }
 EOF
 
+echo
+echo "=== Resize image with invalid sizes ==="
+echo
+
+run_qemu -blockdev driver=file,filename="$TEST_IMG_FILE",node-name=node0 \
+ -blockdev driver=luks,file=node0,key-secret=keysec0,node-name=node1 \
+ -object secret,id=keysec0,data="foo" <

[Qemu-devel] [PATCH for-2.12 03/12] qemu-iotests: Test vdi image creation with QMP

[Kevin Wolf]

Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/211 | 256 +
 tests/qemu-iotests/211.out |  98 +
 tests/qemu-iotests/group   |   1 +
 3 files changed, 355 insertions(+)
 create mode 100755 tests/qemu-iotests/211
 create mode 100644 tests/qemu-iotests/211.out

diff --git a/tests/qemu-iotests/211 b/tests/qemu-iotests/211
new file mode 100755
index 00..6bf1ca784c
--- /dev/null
+++ b/tests/qemu-iotests/211
@@ -0,0 +1,256 @@
+#!/bin/bash
+#
+# Test VDI and file image creation
+#
+# Copyright (C) 2018 Red Hat, Inc.
+#
+# 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 .
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+status=1   # failure is the default!
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt vdi
+_supported_proto file
+_supported_os Linux
+
+function do_run_qemu()
+{
+echo Testing: "$@"
+$QEMU -nographic -qmp stdio -serial none "$@"
+echo
+}
+
+function run_qemu()
+{
+do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qmp \
+  | _filter_qemu | _filter_imgfmt \
+  | _filter_actual_image_size
+}
+
+echo
+echo "=== Successful image creation (defaults) ==="
+echo
+
+size=$((128 * 1024 * 1024))
+
+run_qemu <

Re: [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

[Daniel P . Berrangé]

On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> 
> Very large projects often split in sub projects, maybe one of them
> describing the API. Then that API headers are similar to system headers
> and can be included using <>, although they still belong to the same
> larger project. Do we have a stable QEMU API described in a (small)
> number of include files which typically do not change? If yes, then
> those include files could be included using <> because we don't need
> them in dependency lists or in static code analysis reports.

QEMU doesn't have anything we'd call a stable API at the source level,
anything is subject to change at any time, and often does.

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

[Qemu-devel] [PATCH for-2.12 10/12] vhdx: Don't use error_setg_errno() with constant errno

[Kevin Wolf]

error_setg_errno() is meant for cases where we got an errno from the OS
that can add useful extra information to an error message. It's
pointless if we pass a constant errno, these cases should use plain
error_setg().

Signed-off-by: Kevin Wolf 
---
 block/vhdx.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/block/vhdx.c b/block/vhdx.c
index ca211a3196..0e48179b81 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -1822,7 +1822,7 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
 /* Validate options and set default values */
 image_size = vhdx_opts->size;
 if (image_size > VHDX_MAX_IMAGE_SIZE) {
-error_setg_errno(errp, EINVAL, "Image size too large; max of 64TB");
+error_setg(errp, "Image size too large; max of 64TB");
 return -EINVAL;
 }
 
@@ -1832,7 +1832,7 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
 log_size = vhdx_opts->log_size;
 }
 if (log_size < MiB || (log_size % MiB) != 0) {
-error_setg_errno(errp, EINVAL, "Log size must be a multiple of 1 MB");
+error_setg(errp, "Log size must be a multiple of 1 MB");
 return -EINVAL;
 }
 
@@ -1874,7 +1874,7 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
 }
 
 if (block_size < MiB || (block_size % MiB) != 0) {
-error_setg_errno(errp, EINVAL, "Block size must be a multiple of 1 
MB");
+error_setg(errp, "Block size must be a multiple of 1 MB");
 return -EINVAL;
 }
 if (!is_power_of_2(block_size)) {
@@ -1882,8 +1882,7 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
 return -EINVAL;
 }
 if (block_size > VHDX_BLOCK_SIZE_MAX) {
-error_setg_errno(errp, EINVAL, "Block size must not exceed %d",
- VHDX_BLOCK_SIZE_MAX);
+error_setg(errp, "Block size must not exceed %d", VHDX_BLOCK_SIZE_MAX);
 return -EINVAL;
 }
 
-- 
2.13.6

[Qemu-devel] [PATCH for-2.12 12/12] qemu-iotests: Test vhdx image creation with QMP

[Kevin Wolf]

Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/213 | 349 +
 tests/qemu-iotests/213.out | 121 
 tests/qemu-iotests/group   |   1 +
 3 files changed, 471 insertions(+)
 create mode 100755 tests/qemu-iotests/213
 create mode 100644 tests/qemu-iotests/213.out

diff --git a/tests/qemu-iotests/213 b/tests/qemu-iotests/213
new file mode 100755
index 00..7e44accb06
--- /dev/null
+++ b/tests/qemu-iotests/213
@@ -0,0 +1,349 @@
+#!/bin/bash
+#
+# Test vhdx and file image creation
+#
+# Copyright (C) 2018 Red Hat, Inc.
+#
+# 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 .
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+status=1   # failure is the default!
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt vhdx
+_supported_proto file
+_supported_os Linux
+
+function do_run_qemu()
+{
+echo Testing: "$@"
+$QEMU -nographic -qmp stdio -serial none "$@"
+echo
+}
+
+function run_qemu()
+{
+do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qmp \
+  | _filter_qemu | _filter_imgfmt \
+  | _filter_actual_image_size
+}
+
+echo
+echo "=== Successful image creation (defaults) ==="
+echo
+
+size=$((128 * 1024 * 1024))
+
+run_qemu <

[Qemu-devel] [PATCH for-2.12 00/12] block: Follow-up for .bdrv_co_create (part 1)

[Kevin Wolf]

This series adds qemu-iotests for a few more block drivers (yet more to
come in another series) and fixes a few things that previous review and
these tests brought up.

The only major design change is that I converted the vdi block driver
from a boolean 'static' create option to the standard 'preallocation'
one that other drivers are using. This seems like a good move to make
while the interface isn't stable yet.

Kevin Wolf (12):
  vdi: Change 'static' create option to 'preallocation' in QMP
  vdi: Fix build with CONFIG_VDI_DEBUG
  qemu-iotests: Test vdi image creation with QMP
  qemu-iotests: Enable 025 for luks
  luks: Turn another invalid assertion into check
  qemu-iotests: Test invalid resize on luks
  parallels: Check maximum cluster size on create
  qemu-iotests: Test parallels image creation with QMP
  vhdx: Require power-of-two block size on create
  vhdx: Don't use error_setg_errno() with constant errno
  vhdx: Check for 4 GB maximum log size on creation
  qemu-iotests: Test vhdx image creation with QMP

 qapi/block-core.json   |   6 +-
 block/crypto.c |   6 +-
 block/parallels.c  |   5 +
 block/vdi.c|  46 --
 block/vhdx.c   |  17 ++-
 tests/qemu-iotests/025 |   9 +-
 tests/qemu-iotests/210 |  37 +
 tests/qemu-iotests/211 | 256 +
 tests/qemu-iotests/211.out |  98 +
 tests/qemu-iotests/212 | 326 ++
 tests/qemu-iotests/212.out | 111 ++
 tests/qemu-iotests/213 | 349 +
 tests/qemu-iotests/213.out | 121 
 tests/qemu-iotests/group   |   3 +
 14 files changed, 1365 insertions(+), 25 deletions(-)
 create mode 100755 tests/qemu-iotests/211
 create mode 100644 tests/qemu-iotests/211.out
 create mode 100755 tests/qemu-iotests/212
 create mode 100644 tests/qemu-iotests/212.out
 create mode 100755 tests/qemu-iotests/213
 create mode 100644 tests/qemu-iotests/213.out

-- 
2.13.6

[Qemu-devel] [PATCH for-2.12 07/12] parallels: Check maximum cluster size on create

[Kevin Wolf]

It's unclear what the real maximum cluster size is for the Parallels
format, but let's at least make sure that we don't get integer
overflows in our .bdrv_co_create implementation.

Signed-off-by: Kevin Wolf 
---
 block/parallels.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/block/parallels.c b/block/parallels.c
index 2da5e56a9d..e4ca018c2e 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -526,6 +526,11 @@ static int coroutine_fn 
parallels_co_create(BlockdevCreateOptions* opts,
 cl_size = DEFAULT_CLUSTER_SIZE;
 }
 
+/* XXX What is the real limit here? This is an insanely large maximum. */
+if (cl_size >= UINT64_MAX / MAX_PARALLELS_IMAGE_FACTOR) {
+error_setg(errp, "Cluster size is too large");
+return -EINVAL;
+}
 if (total_size >= MAX_PARALLELS_IMAGE_FACTOR * cl_size) {
 error_setg(errp, "Image size is too large for this cluster size");
 return -E2BIG;
-- 
2.13.6