Re: [Qemu-devel] [PATCH v13 19/25] replay: add BH oneshot event for block layer

[Pavel Dovgalyuk]

> From: Kevin Wolf [mailto:kw...@redhat.com]
> Am 21.02.2019 um 12:05 hat Pavel Dovgalyuk geschrieben:
> > Replay is capable of recording normal BH events, but sometimes
> > there are single use callbacks scheduled with aio_bh_schedule_oneshot
> > function. This patch enables recording and replaying such callbacks.
> > Block layer uses these events for calling the completion function.
> > Replaying these calls makes the execution deterministic.
> >
> > Signed-off-by: Pavel Dovgalyuk 
> 
> Acked-by: Kevin Wolf 

Thanks, Kevin!

Can you also take a look at patches 2, 3, 5?
They affect only RR behavior, but change the block layer too.

Pavel Dovgalyuk

Re: [Qemu-devel] [PATCH] ati-vga: i2c fix

[Gerd Hoffmann]

On Thu, Mar 14, 2019 at 08:11:21PM +0100, BALATON Zoltan wrote:
> On Thu, 14 Mar 2019, Gerd Hoffmann wrote:
> > gets radeonfb going for me, on top of your i2c patches.
> > ---
> > hw/display/ati_int.h  |  1 +
> > hw/display/ati_regs.h |  1 +
> > hw/display/ati.c  | 35 +++
> > 3 files changed, 29 insertions(+), 8 deletions(-)
> > 
> > diff --git a/hw/display/ati_int.h b/hw/display/ati_int.h
> > index 3f4a06f1e1ed..7289db206cd2 100644
> > --- a/hw/display/ati_int.h
> > +++ b/hw/display/ati_int.h
> > @@ -38,6 +38,7 @@ typedef struct ATIVGARegs {
> > uint32_t crtc_ext_cntl;
> > uint32_t dac_cntl;
> > uint32_t gpio_vga_ddc;
> > +uint32_t gpio_dvi_ddc;
> > uint32_t gpio_monid;
> > uint32_t crtc_h_total_disp;
> > uint32_t crtc_h_sync_strt_wid;
> > diff --git a/hw/display/ati_regs.h b/hw/display/ati_regs.h
> > index 90384c886ecb..1ec3498b731c 100644
> > --- a/hw/display/ati_regs.h
> > +++ b/hw/display/ati_regs.h
> > @@ -38,6 +38,7 @@
> > #define CRTC_EXT_CNTL   0x0054
> > #define DAC_CNTL0x0058
> > #define GPIO_VGA_DDC0x0060
> > +#define GPIO_DVI_DDC0x0064
> > #define GPIO_MONID  0x0068
> > #define I2C_CNTL_1  0x0094
> > #define PALETTE_INDEX   0x00b0
> > diff --git a/hw/display/ati.c b/hw/display/ati.c
> > index e2efc6f2225e..ffced39aad9c 100644
> > --- a/hw/display/ati.c
> > +++ b/hw/display/ati.c
> > @@ -272,6 +272,9 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr, 
> > unsigned int size)
> > case GPIO_VGA_DDC:
> > val = s->regs.gpio_vga_ddc;
> > break;
> > +case GPIO_DVI_DDC:
> > +val = s->regs.gpio_dvi_ddc;
> > +break;
> > case GPIO_MONID:
> > val = s->regs.gpio_monid;
> > break;
> > @@ -426,6 +429,22 @@ static inline void ati_reg_write_offs(uint32_t *reg, 
> > int offs,
> > }
> > }
> > 
> > +static uint64_t ati_i2c(bitbang_i2c_interface *i2c,
> > +uint64_t data)
> > +{
> > +bool clk = !(data & BIT(17));
> > +bool out = !(data & BIT(16));
> > +bool in;
> > +
> > +bitbang_i2c_set(i2c, BITBANG_I2C_SCL, clk);
> > +in = bitbang_i2c_set(i2c, BITBANG_I2C_SDA, out);
> > +
> > +data &= 0xf000f;
> > +data |= clk ? BIT(9) : 0;
> > +data |= in  ? BIT(8) : 0;
> > +return data;
> > +}
> > +
> > static void ati_mm_write(void *opaque, hwaddr addr,
> >uint64_t data, unsigned int size)
> > {
> > @@ -512,15 +531,15 @@ static void ati_mm_write(void *opaque, hwaddr addr,
> > if (s->dev_id == PCI_DEVICE_ID_ATI_RAGE128_PF) {
> > break;
> > }
> > -s->regs.gpio_vga_ddc = data & 0xf000f;
> > -if (data & BIT(17)) {
> > -s->regs.gpio_monid |= !!(data & BIT(1)) << 9;
> > -bitbang_i2c_set(s->bbi2c, BITBANG_I2C_SCL, (data & BIT(1)) != 
> > 0);
> > -}
> > -if (data & BIT(16)) {
> > -s->regs.gpio_monid |= bitbang_i2c_set(s->bbi2c, 
> > BITBANG_I2C_SDA,
> > -  data & BIT(0)) << 8;
> > +#if 0
> > +s->regs.gpio_vga_ddc = ati_i2c(s->bbi2c, data);
> > +#endif
> 
> Thanks, I'll try and merge this. What's this #if 0 line?

Avoid the monitor show up on both vga ...

> 
> Regards,
> BALATON Zoltan
> 
> > +break;
> > +case GPIO_DVI_DDC:
> > +if (s->dev_id == PCI_DEVICE_ID_ATI_RAGE128_PF) {
> > +break;
> > }
> > +s->regs.gpio_dvi_ddc = ati_i2c(s->bbi2c, data);

... and dvi.

A more correct model would probably be to create two i2c busses for
that, then hook up the ddc to one of them (possibly depending on a
config option).

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/3] fix: buffer_length is ignored

[Gerd Hoffmann]

  Hi,

> -qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
> +qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 
> ppdo->buffer_length);

I'd just use

ppdo->has_buffer_length ? ppdo->buffer_length : dev->timer_period * 4

here.

cheers,
  Gerd

[Qemu-devel] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

[Launchpad Bug Tracker]

This bug was fixed in the package mesa - 19.0.0-1ubuntu1

---
mesa (19.0.0-1ubuntu1) disco; urgency=medium

  * Merge from Debian. (LP: #1818516)
  * revert-set-full-thread-affinity.diff: Fix qemu crash. (LP: #1815889)

 -- Timo Aaltonen   Thu, 14 Mar 2019 18:48:18 +0200

** Changed in: mesa (Ubuntu Disco)
   Status: Triaged => Fix Released

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

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in Mesa:
  Confirmed
Status in QEMU:
  New
Status in mesa package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Triaged
Status in mesa source package in Disco:
  Fix Released

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

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

Re: [Qemu-devel] [PATCH 2/3] make latency configurable

[Gerd Hoffmann]

  Hi,

>  r = pa_stream_connect_playback (stream, dev, attr,
>  PA_STREAM_INTERPOLATE_TIMING
> -#ifdef PA_STREAM_ADJUST_LATENCY
>  |PA_STREAM_ADJUST_LATENCY
> -#endif

Unrelated change, separate commit please.

Which pulse version added this define, and how old is it?
(should be answered in the commit message).

> -/*
> - * qemu audio tick runs at 100 Hz (by default), so processing
> - * data chunks worth 10 ms of sound should be a good fit.
> - */
> -ba.tlength = pa_usec_to_bytes (10 * 1000, &ss);
> -ba.minreq = pa_usec_to_bytes (5 * 1000, &ss);
> +ba.tlength = pa_usec_to_bytes (ppdo->latency, &ss);
> +ba.minreq = -1;

Please explain this in the commit message.

> -pdo->buffer_length = dev->timer_period * 4;
> +pdo->buffer_length = dev->timer_period * 9 / 2;

Likewise.

> +# @latency: latency you want PulseAudio to archieve in microseconds
> +#   (default 15000)

Is there a good reason to make this configurable?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/3] fix: buffer_length is ignored

[Gerd Hoffmann]

On Fri, Mar 15, 2019 at 08:49:06AM +0100, Martin Schrodt wrote:
> Hi,
> 
> On 3/15/19 8:43 AM, Gerd Hoffmann wrote:
> >   Hi,
> > 
> >> -qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
> >> +qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 
> >> ppdo->buffer_length);
> > 
> > I'd just use
> > 
> > ppdo->has_buffer_length ? ppdo->buffer_length : dev->timer_period * 4
> > 
> > here.
> > 
> > cheers,
> >   Gerd
> > 
> > 
> 
> I made sure the value is present via the new function
> 
> static int qpa_validate_per_direction_opts()
> 
> That way, I can group the setting of all defaults in a single place,
> which is cleaner from my perspective.

But you also set has_buffer_length, so we loose the information whenever
the user has specified a buffer length on the command line or not.

If you want bundle default calculation in one place I'd suggest adding a
get_buffer_length() function where you can place the
"if (has_buffer_length) then { ... } else { ... }" logic.  A simliar
function for the latency can be placed next to it.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/3] fix: buffer_length is ignored

[Martin Schrodt]

Hi,

On 3/15/19 8:43 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>> -qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
>> +qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 
>> ppdo->buffer_length);
> 
> I'd just use
> 
>   ppdo->has_buffer_length ? ppdo->buffer_length : dev->timer_period * 4
> 
> here.
> 
> cheers,
>   Gerd
> 
> 

I made sure the value is present via the new function

static int qpa_validate_per_direction_opts()

That way, I can group the setting of all defaults in a single place,
which is cleaner from my perspective.

Wouldn't you agree?

cheers,
Martin

Re: [Qemu-devel] [PATCH v3 07/23] ui/vnc: Split out authentication_failure

[Gerd Hoffmann]

On Thu, Mar 14, 2019 at 08:26:13PM -0700, Richard Henderson wrote:
> There were 3 copies of this code, one of which used the wrong
> data size for the failure indicator.
> 
> Cc: Gerd Hoffmann 
> Signed-off-by: Richard Henderson 

Reviewed-by: Gerd Hoffmann 

Re: [Qemu-devel] [PATCH v3 08/23] ui/vnc: Use gcrypto_random_bytes for start_auth_vnc

[Gerd Hoffmann]

On Thu, Mar 14, 2019 at 08:26:14PM -0700, Richard Henderson wrote:
> Use a better interface for random numbers than rand().
> Fail gracefully if for some reason we cannot use the crypto system.
> 
> Cc: Gerd Hoffmann 
> Signed-off-by: Richard Henderson 
> ---
> v2: Use qcrypto_random_bytes, not qemu_getrandom, as there is
> no need for deterministic results for this interface.
> v3: Fail gracefully in the event qcrypto_random_bytes fails.

Reviewed-by: Gerd Hoffmann 

Re: [Qemu-devel] [PATCH 0/2] kconfig: add fine-grained dependencies for MSI

[Andrea Bolognani]

On Thu, 2019-03-14 at 15:30 +0100, Paolo Bonzini wrote:
> RISC-V targets did not include PCIe ports before the Kconfig transition,
> and grew them afterwards, but they are nonfunctional because the interrupt
> controller does not support MSI.  This patch restores the situation prior to
> the introduction of Kconfig; in fact, it will automatically drop devices
> that require MSI unless the binary includes an MSI-enabled board.
> 
> Paolo
> 
> Paolo Bonzini (2):
>   kconfig: add CONFIG_MSI
>   kconfig: add dependencies on CONFIG_MSI
> 
>  Kconfig.host  | 3 +++
>  Makefile  | 3 ++-
>  hw/Kconfig| 1 +
>  hw/intc/Kconfig   | 3 +++
>  hw/misc/Kconfig   | 4 ++--
>  hw/net/Kconfig| 4 ++--
>  hw/pci-bridge/Kconfig | 6 +++---
>  hw/pci-host/Kconfig   | 1 +
>  hw/pci/Kconfig| 4 
>  hw/ppc/Kconfig| 1 +
>  hw/rdma/Kconfig   | 3 +++
>  hw/rdma/Makefile.objs | 6 ++
>  hw/s390x/Kconfig  | 1 +
>  13 files changed, 28 insertions(+), 12 deletions(-)
>  create mode 100644 hw/rdma/Kconfig

FWIW

  Tested-by: Andrea Bolognani 

Thanks for addressing this :)

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PATCH v3 12/12] docs/interop/firmware.json: Prefer -machine to if=pflash

[Michal Privoznik]

On 3/14/19 8:01 PM, Markus Armbruster wrote:

Michal Privoznik  writes:


On 3/8/19 2:14 PM, Markus Armbruster wrote:

The previous commit added a way to configure firmware with -blockdev
rather than -drive if=pflash.  Document it as the preferred way.

Signed-off-by: Markus Armbruster 
---
   docs/interop/firmware.json | 20 ++--
   1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
index 28f9bc1591..ff8c2ce5f2 100644
--- a/docs/interop/firmware.json
+++ b/docs/interop/firmware.json
@@ -212,9 +212,13 @@
   #
   # @executable: Identifies the firmware executable. The firmware
   #  executable may be shared by multiple virtual machine
-#  definitions. The corresponding QEMU command line option
-#  is "-drive
-#  
if=pflash,unit=0,readonly=on,file=@executable.@filename,format=@executable.@format".
+#  definitions. The preferred corresponding QEMU command
+#  line options are
+#  -drive 
if=none,id=pflash0,readonly=on,file=@executable.@filename,format=@executable.@format
+#  -machine pflash0=pflash0


I have a question. How is libvirt supposed to query for this? How can
it learn it can use this new, preferred command line?


You can use qom-list-properties to find out whether the machine has
property pflash0.

---> {"execute": "qom-list-properties", "arguments": {"typename": 
"pc-q35-4.0-machine"}}
<--- {"return": [... {"name": "pflash0", ...} ...]}
---> {"execute": "qom-list-properties", "arguments": {"typename": 
"isapc-machine"}}
<--- {"return": [... no such property ...]}



Ah, very well, thank you.

Michal

Re: [Qemu-devel] [PATCH 2/3] make latency configurable

[Martin Schrodt]

Hi,

On 3/15/19 8:53 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>>  r = pa_stream_connect_playback (stream, dev, attr,
>>  PA_STREAM_INTERPOLATE_TIMING
>> -#ifdef PA_STREAM_ADJUST_LATENCY
>>  |PA_STREAM_ADJUST_LATENCY
>> -#endif
> 
> Unrelated change, separate commit please.
> 
> Which pulse version added this define, and how old is it?
> (should be answered in the commit message).

I'll just put it in again. Flag was added in PA 0.9.11 (December 2014),
so we can probably assume that it's there anyway, and if some poor chap
decides to compile against prehistoric PA, it won't break if we leave it in.

> 
>> -/*
>> - * qemu audio tick runs at 100 Hz (by default), so processing
>> - * data chunks worth 10 ms of sound should be a good fit.
>> - */
>> -ba.tlength = pa_usec_to_bytes (10 * 1000, &ss);
>> -ba.minreq = pa_usec_to_bytes (5 * 1000, &ss);
>> +ba.tlength = pa_usec_to_bytes (ppdo->latency, &ss);
>> +ba.minreq = -1;
> 
> Please explain this in the commit message.

Commit messages have been revamped in V2 and V3 of the patch.

> 
>> -pdo->buffer_length = dev->timer_period * 4;
>> +pdo->buffer_length = dev->timer_period * 9 / 2;
> 
> Likewise.

Will clean this up.

> 
>> +# @latency: latency you want PulseAudio to archieve in microseconds
>> +#   (default 15000)
> 
> Is there a good reason to make this configurable?

Yes, to squeeze out some milliseconds of latency, where the emulation is
tuned to do so (properly isolate emulation threads, propably lower
timer-period...)

> 
> cheers,
>   Gerd
> 

Re: [Qemu-devel] [PATCH 1/3] fix: buffer_length is ignored

[Martin Schrodt]

On 3/15/19 9:01 AM, Gerd Hoffmann wrote:
> On Fri, Mar 15, 2019 at 08:49:06AM +0100, Martin Schrodt wrote:
>> Hi,
>>
>> On 3/15/19 8:43 AM, Gerd Hoffmann wrote:
>>>   Hi,
>>>
 -qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
 +qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 
 ppdo->buffer_length);
>>>
>>> I'd just use
>>>
>>> ppdo->has_buffer_length ? ppdo->buffer_length : dev->timer_period * 4
>>>
>>> here.
>>>
>>> cheers,
>>>   Gerd
>>>
>>>
>>
>> I made sure the value is present via the new function
>>
>> static int qpa_validate_per_direction_opts()
>>
>> That way, I can group the setting of all defaults in a single place,
>> which is cleaner from my perspective.
> 
> But you also set has_buffer_length, so we loose the information whenever
> the user has specified a buffer length on the command line or not.
> 
> If you want bundle default calculation in one place I'd suggest adding a
> get_buffer_length() function where you can place the
> "if (has_buffer_length) then { ... } else { ... }" logic.  A simliar
> function for the latency can be placed next to it.
> 

I did so because Zoltans code in audio.c does it the same way.
See audio.c, functions audio_validate_opts() and
audio_validate_per_direction_opts().

I mean I can do a separate function for each, but is it really worth it?

[Qemu-devel] [PATCH] curses ui: always initialize all curses_line fields

[Samuel Thibault]

cchar_t can contain not only attr and chars fields, but also ext_color.
Initialize the whole structure to zero instead of enumerating fields.

Spotted by Coverity: CID 1399711

Signed-off-by: Samuel Thibault 
---
 ui/curses.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/ui/curses.c b/ui/curses.c
index d29098db9f..e99fbe3e24 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -75,9 +75,8 @@ static void curses_update(DisplayChangeListener *dcl,
 if (vga_to_curses[ch].chars[0]) {
 curses_line[x] = vga_to_curses[ch];
 } else {
+curses_line[x] = (cchar_t) {};
 curses_line[x].chars[0] = ch;
-curses_line[x].chars[1] = 0;
-curses_line[x].attr = 0;
 }
 curses_line[x].attr |= at;
 }
-- 
2.20.1

Re: [Qemu-devel] [PATCH v2 04/11] hw/arm/virt: Add virtual ACPI device

[Igor Mammedov]

On Thu, 14 Mar 2019 16:55:36 +
Shameerali Kolothum Thodi  wrote:

> Hi Igor,
> 
> > -Original Message-
> > From: Igor Mammedov [mailto:imamm...@redhat.com]
> > Sent: 12 March 2019 15:48
> > To: Shameerali Kolothum Thodi 
> > Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org;
> > eric.au...@redhat.com; peter.mayd...@linaro.org;
> > shannon.zha...@gmail.com; sa...@linux.intel.com;
> > sebastien.bo...@intel.com; Linuxarm ; xuwei (O)
> > 
> > Subject: Re: [PATCH v2 04/11] hw/arm/virt: Add virtual ACPI device
> > 
> > On Fri, 8 Mar 2019 11:42:11 +
> > Shameer Kolothum  wrote:
> >   
> > > From: Samuel Ortiz 
> > >
> > > This is to provide an acpi device interface for Arm/virt.
> > > This will be used by Arm/Virt to add hotplug support via
> > > ACPI GED device.
> > >
> > > Signed-off-by: Samuel Ortiz 
> > > Signed-off-by: Shameer Kolothum 
> > > ---
> > >  hw/arm/Makefile.objs  |   2 +-
> > >  hw/arm/virt-acpi.c| 111  
> > ++
> > 
> > does it have to be ARM specific?
> > could it be shared with future x86/virt? (if it could then it would be 
> > better to put
> > into hw/acpi/)
> > also considering it implements vitual 'GED' device
> > why not s/virt-acpi/generic-event-device/ ?  
> 
> I think that's a good idea to make it generic and I had a quick go at it.
> 
> But the problem I am facing is as soon as sysbus_create_simple() is called 
> from
> virt_acpi_init(), the realize() function gets called before it sets the 
> VirtAcpiState
> members.

Lets look at it from the other side, what are the reasons to use inherit device
from TYPE_SYS_BUS_DEVICE and use sysbus_create_simple()?

 
> This creates a problem as acpi_memory_hotplug_init() and acpi_ged_init() are
> invoked from the realize() and it needs to have the base address, irq etc set 
> based
> on the platform.
> 
> I tried using the qdev_prop_set_*() as well, but it also fails saying attempt 
> to set
> property after it was realized.
> 
> Not sure what is the best way to solve this other than introducing a global 
> struct to
> hold the configuration.
Globals are frowned upon, we shouldn't do add more.

> 
> Please let me know.
> 
> Thanks,
> Shameer
>  
> >   
> > >  include/hw/arm/virt.h |   1 +
> > >  3 files changed, 113 insertions(+), 1 deletion(-)
> > >  create mode 100644 hw/arm/virt-acpi.c
> > >
> > > diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> > > index fa57c7c..e0db3cd 100644
> > > --- a/hw/arm/Makefile.objs
> > > +++ b/hw/arm/Makefile.objs
> > > @@ -1,6 +1,6 @@
> > >  obj-y += boot.o sysbus-fdt.o
> > >  obj-$(CONFIG_ARM_VIRT) += virt.o
> > > -obj-$(CONFIG_ACPI) += virt-acpi-build.o
> > > +obj-$(CONFIG_ACPI) += virt-acpi-build.o virt-acpi.o
> > >  obj-$(CONFIG_DIGIC) += digic_boards.o
> > >  obj-$(CONFIG_EXYNOS4) += exynos4_boards.o
> > >  obj-$(CONFIG_HIGHBANK) += highbank.o
> > > diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c
> > > new file mode 100644
> > > index 000..df8a02b
> > > --- /dev/null
> > > +++ b/hw/arm/virt-acpi.c
> > > @@ -0,0 +1,111 @@
> > > +/*
> > > + *
> > > + * Copyright (c) 2018 Intel Corporation
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify 
> > > it
> > > + * under the terms and conditions of the GNU General Public License,
> > > + * version 2 or later, as published by the Free Software Foundation.
> > > + *
> > > + * This program is distributed in the hope it will be useful, but WITHOUT
> > > + * ANY WARRANTY; without even the implied warranty of  
> > MERCHANTABILITY or  
> > > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public  
> > License for  
> > > + * more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License 
> > > along  
> > with  
> > > + * this program.  If not, see .
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "qemu/range.h"
> > > +#include "qapi/error.h"
> > > +#include "exec/address-spaces.h"
> > > +
> > > +#include "hw/hw.h"
> > > +#include "hw/hotplug.h"
> > > +#include "hw/sysbus.h"
> > > +#include "hw/arm/virt.h"
> > > +
> > > +#include "hw/acpi/acpi.h"
> > > +
> > > +typedef struct VirtAcpiState {
> > > +SysBusDevice parent_obj;
> > > +} VirtAcpiState;
> > > +
> > > +#define TYPE_VIRT_ACPI "virt-acpi"
> > > +#define VIRT_ACPI(obj) \
> > > +OBJECT_CHECK(VirtAcpiState, (obj), TYPE_VIRT_ACPI)
> > > +
> > > +static const VMStateDescription vmstate_acpi = {
> > > +.name = "virt_acpi",
> > > +.version_id = 1,
> > > +.minimum_version_id = 1,
> > > +};
> > > +
> > > +static void virt_device_plug_cb(HotplugHandler *hotplug_dev,
> > > +DeviceState *dev, Error **errp)
> > > +{
> > > +}
> > > +
> > > +static void virt_device_unplug_request_cb(HotplugHandler *hotplug_dev,
> > > +  DeviceState *dev, Error  
> > **errp)  
> > > +{
> > > +}
> > > +
> > > +static void virt_device_unplug_cb(

[Qemu-devel] [PATCH V4 2/3] audio/paaudio: prolong and make latency configurable

[Martin Schrodt]

The latency of a connection to the PulseAudio server is determined by
the tlength parameter. This was hardcoded to 10ms, which is a bit too
tight on my machine, causing audio on host and guest to malfunction.
A setting of 15ms works fine here. To allow tweaking, I also made the
setting configurable via the new -audiodev config. This allows to squeeze out 
better timings in scenarios where the emulation allows it.

I also removed setting of the minreq parameter to (seemingly arbitrary) half 
the latency, since it showed worse audio quality during my tests. Allowing 
PulseAudio to request smaller chunks helped.

Signed-off-by: Martin Schrodt 
---
 audio/paaudio.c | 12 ++--
 qapi/audio.json |  6 +-
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index ab2a37bbdb..be27c73f09 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -549,12 +549,8 @@ static int qpa_init_out(HWVoiceOut *hw, struct audsettings 
*as,
 ss.channels = as->nchannels;
 ss.rate = as->freq;
 
-/*
- * qemu audio tick runs at 100 Hz (by default), so processing
- * data chunks worth 10 ms of sound should be a good fit.
- */
-ba.tlength = pa_usec_to_bytes (10 * 1000, &ss);
-ba.minreq = pa_usec_to_bytes (5 * 1000, &ss);
+ba.tlength = pa_usec_to_bytes(ppdo->latency, &ss);
+ba.minreq = -1;
 ba.maxlength = -1;
 ba.prebuf = -1;
 
@@ -818,6 +814,10 @@ static int qpa_validate_per_direction_opts(Audiodev *dev,
 pdo->has_buffer_length = true;
 pdo->buffer_length = 46440;
 }
+if (!pdo->has_latency) {
+pdo->has_latency = true;
+pdo->latency = 15000;
+}
 return 1;
 }
 
diff --git a/qapi/audio.json b/qapi/audio.json
index 97aee37288..9fefdf5186 100644
--- a/qapi/audio.json
+++ b/qapi/audio.json
@@ -206,12 +206,16 @@
 #
 # @name: name of the sink/source to use
 #
+# @latency: latency you want PulseAudio to achieve in microseconds
+#   (default 15000)
+#
 # Since: 4.0
 ##
 { 'struct': 'AudiodevPaPerDirectionOptions',
   'base': 'AudiodevPerDirectionOptions',
   'data': {
-'*name': 'str' } }
+'*name': 'str',
+'*latency': 'uint32' } }
 
 ##
 # @AudiodevPaOptions:
-- 
2.21.0

[Qemu-devel] [PATCH V4 0/3] Fixes for PulseAudio driver

[Martin Schrodt]

Version 2 of the series added proper commit messages 
and fixed a typo.

Version 3 fixes coding style problems

Version 4 reintroduces the check, whether PA support adjusting
latency, and sets the default buffer_length to the constant value
that was present beforehand (works well, and testing revealed that 
having a longer buffer does not hurt, so it's propably better to 
not make it artificially short when the user chooses shorter 
timer periods)

Martin Schrodt (3):
  audio/paaudio: fix ignored buffer_length setting
  audio/paaudio: prolong and make latency configurable
  audio/paaudio: fix microphone input being unusable

 audio/paaudio.c | 44 ++--
 qapi/audio.json |  6 +-
 2 files changed, 39 insertions(+), 11 deletions(-)

-- 
2.21.0

[Qemu-devel] [PATCH V4 1/3] audio/paaudio: fix ignored buffer_length setting

[Martin Schrodt]

Audiodev configuration allows to set the length of the buffered data.
The setting was ignored and a constant value used instead.
This patch makes the code apply the setting properly, and uses the
previous default if nothing is supplied.

Signed-off-by: Martin Schrodt 
---
 audio/paaudio.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index 5d410ed73f..ab2a37bbdb 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -577,7 +577,8 @@ static int qpa_init_out(HWVoiceOut *hw, struct audsettings 
*as,
 
 audio_pcm_init_info (&hw->info, &obt_as);
 hw->samples = pa->samples = audio_buffer_samples(
-qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
+qapi_AudiodevPaPerDirectionOptions_base(ppdo),
+&obt_as, ppdo->buffer_length);
 pa->pcm_buf = audio_calloc(__func__, hw->samples, 1 << hw->info.shift);
 pa->rpos = hw->rpos;
 if (!pa->pcm_buf) {
@@ -637,7 +638,8 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 
 audio_pcm_init_info (&hw->info, &obt_as);
 hw->samples = pa->samples = audio_buffer_samples(
-qapi_AudiodevPaPerDirectionOptions_base(ppdo), &obt_as, 46440);
+qapi_AudiodevPaPerDirectionOptions_base(ppdo),
+&obt_as, ppdo->buffer_length);
 pa->pcm_buf = audio_calloc(__func__, hw->samples, 1 << hw->info.shift);
 pa->wpos = hw->wpos;
 if (!pa->pcm_buf) {
@@ -809,7 +811,16 @@ static int qpa_ctl_in (HWVoiceIn *hw, int cmd, ...)
 return 0;
 }
 
-/* common */
+static int qpa_validate_per_direction_opts(Audiodev *dev,
+   AudiodevPaPerDirectionOptions *pdo)
+{
+if (!pdo->has_buffer_length) {
+pdo->has_buffer_length = true;
+pdo->buffer_length = 46440;
+}
+return 1;
+}
+
 static void *qpa_audio_init(Audiodev *dev)
 {
 paaudio *g;
@@ -836,6 +847,13 @@ static void *qpa_audio_init(Audiodev *dev)
 g = g_malloc(sizeof(paaudio));
 server = popts->has_server ? popts->server : NULL;
 
+if (!qpa_validate_per_direction_opts(dev, popts->in)) {
+goto fail;
+}
+if (!qpa_validate_per_direction_opts(dev, popts->out)) {
+goto fail;
+}
+
 g->dev = dev;
 g->mainloop = NULL;
 g->context = NULL;
-- 
2.21.0

[Qemu-devel] [PATCH V4 3/3] audio/paaudio: fix microphone input being unusable

[Martin Schrodt]

The current code does not specify the metrics of the buffers for the
input device. This makes PulseAudio choose very bad defaults, which
causes input to be unusable: Audio put in gets out 30 seconds later.
This patch fixes that and makes the latency configurable as well.

Signed-off-by: Martin Schrodt 
---
 audio/paaudio.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index be27c73f09..45295b4e5e 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -605,6 +605,7 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 {
 int error;
 pa_sample_spec ss;
+pa_buffer_attr ba;
 struct audsettings obt_as = *as;
 PAVoiceIn *pa = (PAVoiceIn *) hw;
 paaudio *g = pa->g = drv_opaque;
@@ -615,6 +616,11 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 ss.channels = as->nchannels;
 ss.rate = as->freq;
 
+ba.fragsize = pa_usec_to_bytes(ppdo->latency, &ss);
+ba.maxlength = -1;
+ba.minreq = -1;
+ba.prebuf = -1;
+
 obt_as.fmt = pa_to_audfmt (ss.format, &obt_as.endianness);
 
 pa->stream = qpa_simple_new (
@@ -624,7 +630,7 @@ static int qpa_init_in(HWVoiceIn *hw, struct audsettings 
*as, void *drv_opaque)
 ppdo->has_name ? ppdo->name : NULL,
 &ss,
 NULL,   /* channel map */
-NULL,   /* buffering attributes */
+&ba,/* buffering attributes */
 &error
 );
 if (!pa->stream) {
-- 
2.21.0

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Alex Bennée]

Peter Maydell  writes:

> On Thu, 14 Mar 2019 at 15:57, Alex Bennée  wrote:
>> Testing in the Cloud
>> 
>>
>> After BuildBot went out-of-service we have been relying heavily on Travis
>> as our primary CI platform. This has been creaking somewhat under the
>> strain and while we have a large test matrix its coverage is fairly
>> Ubuntu/x86 centric. However in recent months we've expanded and we now
>> have:
>>
>>   - Shippable, cross compilers - catches a lot of 32/64 bit isms
>>   - Cirrus, FreeBSD and MacOS builds
>>   - GitLab, Alternative x86/Debian - iotests
>
> Are any of these capable of replacing my ad-hoc collection
> of build test systems for testing merges ? I would quite like
> to be able to do that, because it would make it easier for
> other people to take over the process of handling pull requests
> when I'm away.
>
> I think the main requirements for that would be:
>  * covers full range of hosts[*]
>  * can be asked to do a test build of a merge before
>I push it to master
>  * reliably completes all builds within say 90 minutes
>of being asked to start
>
> [+] I currently test:
>  - windows crossbuilds

We did have this with shippable but had to disable it when the upstream
repo went down. We could re-enable if we can rebuild it and cache our
docker images with Daniel's work.

>  - S390, AArch32, AArch64, PPC64 Linux
>(SPARC currently disabled because of the migration-test flakiness)

We would need to get machines from somewhere. Setting up a headless
SynQuacer should be easy enough and we have qemu-test which is a
ThunderX beast. I guess the IBM guys would have to chime in if they
could find PPC/s390 boxen because I'm guessing spamming the GCC build
farm with our test runners would be a little unfair.

>  - OSX

Currently run on Travis and recently Cirrus

>  - FreeBSD, OpenBSD, NetBSD via the tests/vm setup

We build on FreeBSD on Cirrus - but any x86 box can run the test/vm
setup assuming your just kicking it off with a make vm-test type thing?

>  - various x86-64 configs: from-clean; debug; clang; TCI; no-tcg;
>linux-static (including 'make check-tcg')

This is already covered in our rather large Travis matrix. The trick
will be making it all fast enough.

--
Alex Bennée

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Alex Bennée]

Fam Zheng  writes:

>> On Mar 15, 2019, at 02:22, Peter Maydell  wrote:
>>
>> On Thu, 14 Mar 2019 at 15:57, Alex Bennée  wrote:
>>> Testing in the Cloud
>>> 
>>>
>>> After BuildBot went out-of-service we have been relying heavily on Travis
>>> as our primary CI platform. This has been creaking somewhat under the
>>> strain and while we have a large test matrix its coverage is fairly
>>> Ubuntu/x86 centric. However in recent months we've expanded and we now
>>> have:
>>>
>>>  - Shippable, cross compilers - catches a lot of 32/64 bit isms
>>>  - Cirrus, FreeBSD and MacOS builds
>>>  - GitLab, Alternative x86/Debian - iotests
>>
>> Are any of these capable of replacing my ad-hoc collection
>> of build test systems for testing merges ? I would quite like
>> to be able to do that, because it would make it easier for
>> other people to take over the process of handling pull requests
>> when I'm away.
>>
>> I think the main requirements for that would be:
>> * covers full range of hosts[*]
>> * can be asked to do a test build of a merge before
>>   I push it to master
>> * reliably completes all builds within say 90 minutes
>>   of being asked to start
>>
>> [+] I currently test:
>> - windows crossbuilds
>> - S390, AArch32, AArch64, PPC64 Linux
>>   (SPARC currently disabled because of the migration-test flakiness)
>> - OSX
>> - FreeBSD, OpenBSD, NetBSD via the tests/vm setup
>> - various x86-64 configs: from-clean; debug; clang; TCI; no-tcg;
>>   linux-static (including 'make check-tcg’)
>
> I think the gitlab CI architecture is quite capable of doing what you
> want here. Some efforts will be needed to set up the gitlab-runners in
> each of above environments and I expect tweakings will be needed to
> get the automation smooth, but it is fairly straigtforward and
> managable:
>
> https://docs.gitlab.com/runner/

If only it was that simple. It seems they don't current have arm64
packaged, only armhf:

  https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725

I had installed the gitlab-runner from the Debian repo but it was out
of date and didn't seem to work correctly.

There build system seems... interesting.. in that it requires qemu-arm
to build on any host. I think it is because they are bundling all the
various architecture runners in one package which makes it a bit hard to
follow. Also it's in Go and has *all* the go dependencies which seems to
be a bit of a horror show in the distro packaging department.

However conceptually if we can get over that hurdle it does look as
though it could be quite promising. It's just getting to that point
might require a diversion to get gitlab's multiarch support up to speed.

By the way GitLab offer their additional tiers for free for FLOSS
projects:

  
https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/

so perhaps I should make the application for qemu-project. The main
benefit would be upping the total number of CI minutes we get on the
shared runners.

Shippable also offer a BYON (Bring Your Own Node) solution which we
should be able to plug one of the Packet.net arm64 servers into but it
seems to requite a node license to use so I haven't been able to play
with it yet.

(CCed: Ed from packet.net who runs the Works on ARM program)

--
Alex Bennée

Re: [Qemu-devel] [RFC] arm/cpu: fix soft lockup panic after resuming from stop

[Christoffer Dall]

Hi Steve,

On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
> 
> Personally I think what we need is:
> 
> * Either a patch like the one from Heyi Guo (save/restore CNTVCT_EL0) or
> alternatively hooking up KVM_KVMCLOCK_CTRL to prevent the watchdog
> firing when user space explicitly stops scheduling the guest for a while.

If we save/restore CNTVCT_EL0 and the warning goes away, does the guest
wall clock timekeeping get all confused and does it figure this out
automagically somehow?

Does KVM_KVMCLOCK_CTRL solve that problem?

> 
> * KVM itself saving/restoring CNTVCT_EL0 during suspend/resume so the
> guest doesn't see time pass during a suspend.

This smells like policy to me so I'd much prefer keeping as much
functionality in user space as possible.  If we already have the APIs we
need from KVM, let's use them.

> 
> * Something equivalent to MSR_KVM_WALL_CLOCK_NEW for arm which allows
> the guest to query the wall clock time from the host and provides an
> offset between CNTVCT_EL0 to wall clock time which the KVM can update
> during suspend/resume. This means that during a suspend/resume the guest
> can observe that wall clock time has passed, without having to be
> bothered about CNTVCT_EL0 jumping forwards.
> 

Isn't the proper Arm architectural solution for this to read the
physical counter for wall clock time keeping ?

(Yes that will require a trap on physical counter reads after migration
on current systems, but migration sucks in terms of timekeeping
already.)


Thanks,

Christoffer

[Qemu-devel] [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

[Roger Pau Monne]

Or if it's not possible to honor the hinted address an error is returned
instead. This makes it easier to spot the actual failure, instead of
failing later on when the caller of xen_remap_bucket realizes the
mapping has not been created at the requested address.

Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
try harder to honor the passed address.

Signed-off-by: Roger Pau Monné 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Paul Durrant 
Cc: Igor Druzhinin 
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 
Cc: "Michael S. Tsirkin" 
Cc: Marcel Apfelbaum 
Cc: xen-de...@lists.xenproject.org
---
 hw/i386/xen/xen-mapcache.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 349f72d00c..0e2870b320 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -185,8 +185,14 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 }
 
 if (!dummy) {
+/*
+ * If the caller has requested the mapping at a specific address use
+ * MAP_FIXED to make sure it's honored. Note that with MAP_FIXED at
+ * least FreeBSD will try harder to honor the passed address.
+ */
 vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
-   PROT_READ | PROT_WRITE, 0,
+   PROT_READ | PROT_WRITE,
+   vaddr ? MAP_FIXED : 0,
nb_pfn, pfns, err);
 if (vaddr_base == NULL) {
 perror("xenforeignmemory_map2");
-- 
2.17.2 (Apple Git-113)

Re: [Qemu-devel] [Qemu-arm] [PATCH] Check access permission to ADDVL/ADDPL/RDVL

[Amir CHARIF]

Thanks Eric, happy to join ^^ 

-Message d'origine-
De : Eric Blake  
Envoyé : jeudi 14 mars 2019 18:44
À : Richard Henderson ; Peter Maydell 
; Amir CHARIF 
Cc : qemu-arm ; QEMU Developers 
Objet : Re: [Qemu-devel] [Qemu-arm] [PATCH] Check access permission to 
ADDVL/ADDPL/RDVL

On 3/14/19 12:34 PM, Richard Henderson wrote:
> On 3/14/19 10:21 AM, Peter Maydell wrote:
>> Richard, Amir -- it looks like you both sent exactly the same patch 
>> at pretty much exactly the same time. Any preferences for whose 
>> version I apply ? :-)
>>
>> thanks
>> -- PMM
> 
> Hah.  Bit of miscommunication there.  Might as well apply Amir's and 
> have my
> Reviewed-by: Richard Henderson 

Great minds think alike!

My personal preference, if it counts for anything, is to apply Amir's patch, 
because it's always nice to have first-time contributors added in a release.  
Welcome to the community, Amir!

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

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

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 14 March 2019 19:37
> To: Simon Gaiser ; Jason Andryuk 
> ; Paul Durrant
> 
> Cc: Anthony Perard ; 
> xen-de...@lists.xenproject.org; Stefano Stabellini
> ; qemu-devel@nongnu.org; 
> marma...@invisiblethingslab.com
> Subject: Re: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
> 
> On 14/03/2019 19:22, Simon Gaiser wrote:
> > Jason Andryuk:
> >> On Wed, Mar 13, 2019 at 11:09 AM Paul Durrant  
> >> wrote:
>  -Original Message-
>  From: Jason Andryuk [mailto:jandr...@gmail.com]
>  Sent: 11 March 2019 18:02
>  To: qemu-devel@nongnu.org
>  Cc: xen-de...@lists.xenproject.org; marma...@invisiblethingslab.com; 
>  Simon Gaiser
>  ; Jason Andryuk ; 
>  Stefano Stabellini
>  ; Anthony Perard ; 
>  Paul Durrant
>  
>  Subject: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
> 
>  From: Simon Gaiser 
> 
>  If a pci memory region has a size < XEN_PAGE_SIZE it can get located at
>  an address which is not page aligned.
> >>> IIRC the PCI spec says that the minimum memory region size should be at 
> >>> least 4k. Should we even
> be tolerating BARs smaller than that?
> >>>
> >>>   Paul
> >>>
> >> Hi, Paul.
> >>
> >> Simon found this, so it affects a real device.  Simon, do you recall
> >> which device was affected?
> > Not sure which one it was. Probably the USB controller or the SD host
> > controller. As your example below shows this is not so uncommon.
> 
> The minimum is 128 bytes, not 4k - I've just checked the PCIe spec.
> 
> Xen/Qemu definitely needs to cope with smaller than 4k if we want to be
> spec compliant.

Well, we have a problem for pass-through if the BAR is smaller than 4k in that 
page protection is not going to isolate it. I don't see any other way that to 
trap and emulate such BARs if we want to pass through those devices at all.

  Paul

> 
> ~Andrew

Re: [Qemu-devel] [PULL 17/29] target/riscv: Convert quadrant 1 of RVXC insns to decodetree

[Bastian Koppelmann]

Hi Alistair

On 3/14/19 9:28 PM, Alistair Francis wrote:

On Wed, Mar 13, 2019 at 7:53 AM Palmer Dabbelt  wrote:

From: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
Signed-off-by: Bastian Koppelmann 
Signed-off-by: Peer Adelt 

This commit is the first bad commit in breaking 32-bit boot.

It looks like the jal doesn't jump to the correct address:


IN:
0x8022:  00050433  add s0,a0,zero
0x8026:  000584b3  add s1,a1,zero
0x802a:  2c79  jal ra,670  # 0x82c8


IN:
0x82c8:  0533  add a0,zero,zero
0x82cc:  8082  ret



Oops! Can you point me to the binary to reproduce this?

Cheers,

Bastian

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Alex Bennée]

Daniel P. Berrangé  writes:

> On Thu, Mar 14, 2019 at 03:57:06PM +, Alex Bennée wrote:
>> Docker Images
>> =
>>
>> The addition of docker has unlocked the ability to build a lot more
>> tests as well as compile testing on a much wider range of distros. I
>> think there are two outstanding areas that need improvement
>>
>> Daniel has been looking at building and hosting the images somewhere.
>> This would be useful as it would stop us slamming the distros
>> repositories constantly rebuilding the same images and also help reduce
>> the time to test.
>
> My intent was/still is to make use of quay.io for hosting prebuilt
> images.
>
> As well as avoiding repeated builds for developers it means that
> developers can be gauranteed to actually be testing with the same
> content that the automated CI did. Currently everyone using the
> docker images potentially has slightly different environment as
> it depends on what packages were in the repos when they built
> the image locally. This is very bad for reproducability.
>
> Libvirt uses quay.io for hosting images already and I've been
> looking at creating a script to automate usage of it via their
> REST API. Once done the same script should be usable by QEMU
> too.
>
> The idea would be that we still have docker files in the
> tests/docker/dockerfiles directory, but they would only be used
> for an automated job which triggers builds on quay.io, or for the
> few people who need to make changes to the dockerfiles. The current
> make rules used by developers / CI systems for executing test builds
> would be changed to simply pull the pre-built image off quay.io
> instead of running a docker build again.

Could we just have a script that pulls the quay.io image and tags it as
the appropriate target and then we could do:

  make docker-image-debian-arm64-cross [REBUILD=1]

which would normally pull the quay.io image but if REBUILD=1 would force
a local rebuild?

>> The other area that needs some work is better supporting non-x86 hosts.
>> While Docker's multi-arch story is much better (docker run debian:stable
>> will DTRT on any main architecture) we get stumped by things like
>> Debian's uneven support of cross compilers. For 4.1 I'd like to
>> reorganise the dockerfiles subdirectory into multiarch and arch specific
>> directories so we approach this is a less ad-hoc way. It would also be
>> nice to have the ability to gracefully fallback to linux-user powered
>> images where the host architecture doesn't have what we need.

I suspect we'd never store linux-user powered images on quay.io as there
are niggly differences depending on the users binfmt_misc setup.

--
Alex Bennée

[Qemu-devel] [PATCH 0/2] ui/cocoa: Fix absolute input device grabbing issue on Mojave

[Chen Zhang via Qemu-devel]

On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing the 
cursor in re-entry into the virtual screen area. In some cases, the `window` 
property of NSEvent object is nil, after exit of cursor, meaning that the 
`-locationInWindow` method would return value in screen coordinates. The 
current implementation used raw locations from NSEvent without considering 
whether the value was for the window coordinates or the macOS screen 
coordinates, nor the zooming factor for Zoom-to-Fit in fullscreen mode.

The following patches fixed boundary check methods for cursor in normal and 
fullscreen with/without Zoom-to-Fit in Mojave.

Chen Zhang (2):
  Fix absolute input device grabbing issues on Mojave
  ui/cocoa: fix grabbing issue in fullscreen mode

 ui/cocoa.m | 54 +++---
 1 file changed, 47 insertions(+), 7 deletions(-)

-- 
2.19.2

[Qemu-devel] [PATCH 1/2] Fix absolute input device grabbing issues on Mojave

[Chen Zhang via Qemu-devel]

Signed-off-by: Chen Zhang 
---
 ui/cocoa.m | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 420b2411c1..5d0a6599d9 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -405,6 +405,24 @@ QemuCocoaView *cocoaView;
 return (p.x > -1 && p.x < screen.width && p.y > -1 && p.y < screen.height);
 }
 
+/* Get location of event and convert to virtual screen coordinate */
+- (CGPoint) screenLocationOfEvent:(NSEvent *)ev
+{
+NSWindow *eventWindow = [ev window];
+if (!eventWindow) {
+   return [self.window convertPointFromScreen:[ev locationInWindow]];
+} else if ([self.window isEqual:eventWindow]) {
+return [ev locationInWindow];
+} else {
+return [self.window convertPointFromScreen:[eventWindow 
convertPointToScreen:[ev locationInWindow]]];
+}
+}
+
+- (BOOL) screenContainsPointOfEvent:(NSEvent *)ev
+{
+return [self screenContainsPoint:[self screenLocationOfEvent:ev]];
+}
+
 - (void) hideCursor
 {
 if (!cursor_hide) {
@@ -815,7 +833,9 @@ QemuCocoaView *cocoaView;
 break;
 case NSEventTypeMouseMoved:
 if (isAbsoluteEnabled) {
-if (![self screenContainsPoint:p] || ![[self window] 
isKeyWindow]) {
+BOOL is_key_window = [[self window] isKeyWindow];
+BOOL is_in_screen =  [self screenContainsPointOfEvent: event];
+if (!is_in_screen || !is_key_window) {
 if (isMouseGrabbed) {
 [self ungrabMouse];
 }
@@ -927,9 +947,10 @@ QemuCocoaView *cocoaView;
  * The check on screenContainsPoint is to avoid sending out of 
range values for
  * clicks in the titlebar.
  */
-if ([self screenContainsPoint:p]) {
-qemu_input_queue_abs(dcl->con, INPUT_AXIS_X, p.x, 0, 
screen.width);
-qemu_input_queue_abs(dcl->con, INPUT_AXIS_Y, screen.height 
- p.y, 0, screen.height);
+if ([self screenContainsPointOfEvent:event]) {
+CGPoint loc = [self screenLocationOfEvent: event];
+qemu_input_queue_abs(dcl->con, INPUT_AXIS_X, loc.x, 0, 
screen.width);
+qemu_input_queue_abs(dcl->con, INPUT_AXIS_Y, screen.height 
- loc.y, 0, screen.height);
 }
 } else {
 qemu_input_queue_rel(dcl->con, INPUT_AXIS_X, (int)[event 
deltaX]);
-- 
2.19.2

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Fam Zheng]

> On Mar 15, 2019, at 16:57, Alex Bennée  wrote:
> 
> I had installed the gitlab-runner from the Debian repo but it was out
> of date and didn't seem to work correctly.

If there can be a sidecar x86 box next to the test bot, it can be the 
controller node which runs gitlab-runner, the test script (in .gitlab-ci.yml) 
can then sshs into the actual env to run test commands.

Fam

[Qemu-devel] [PATCH 2/2] ui/cocoa: fix grabbing issue in fullscreen mode

[Chen Zhang via Qemu-devel]

Signed-off-by: Chen Zhang 
---
 ui/cocoa.m | 35 +++
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 5d0a6599d9..8e74f6e283 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -410,11 +410,31 @@ QemuCocoaView *cocoaView;
 {
 NSWindow *eventWindow = [ev window];
 if (!eventWindow) {
-   return [self.window convertPointFromScreen:[ev locationInWindow]];
-} else if ([self.window isEqual:eventWindow]) {
-return [ev locationInWindow];
+if (!isFullscreen) {
+return [[self window] convertPointFromScreen:[ev 
locationInWindow]];
+} else {
+CGPoint loc = [self convertPoint:[[self window] 
convertPointFromScreen:[ev locationInWindow]] fromView:nil];
+if (!stretch_video) {
+return loc;
+}
+loc.x /= cdx;
+loc.y /= cdy;
+return loc;
+}
+} else if ([[self window] isEqual:eventWindow]) {
+if (!isFullscreen) {
+return [ev locationInWindow];
+} else {
+CGPoint loc = [self convertPoint:[ev locationInWindow] 
fromView:nil];
+if (!stretch_video) {
+return loc;
+}
+loc.x /= cdx;
+loc.y /= cdy;
+return loc;
+}
 } else {
-return [self.window convertPointFromScreen:[eventWindow 
convertPointToScreen:[ev locationInWindow]]];
+return [[self window] convertPointFromScreen:[eventWindow 
convertPointToScreen:[ev locationInWindow]]];
 }
 }
 
@@ -722,7 +742,6 @@ QemuCocoaView *cocoaView;
 int keycode = 0;
 bool mouse_event = false;
 static bool switched_to_fullscreen = false;
-NSPoint p = [event locationInWindow];
 
 switch ([event type]) {
 case NSEventTypeFlagsChanged:
@@ -835,7 +854,7 @@ QemuCocoaView *cocoaView;
 if (isAbsoluteEnabled) {
 BOOL is_key_window = [[self window] isKeyWindow];
 BOOL is_in_screen =  [self screenContainsPointOfEvent: event];
-if (!is_in_screen || !is_key_window) {
+if (!is_in_screen || !(is_key_window || isFullscreen)) {
 if (isMouseGrabbed) {
 [self ungrabMouse];
 }
@@ -881,7 +900,7 @@ QemuCocoaView *cocoaView;
 break;
 case NSEventTypeLeftMouseUp:
 mouse_event = true;
-if (!isMouseGrabbed && [self screenContainsPoint:p]) {
+if (!isMouseGrabbed && [self screenContainsPointOfEvent:event]) {
 if([[self window] isKeyWindow]) {
 [self grabMouse];
 }
@@ -944,7 +963,7 @@ QemuCocoaView *cocoaView;
 if (isMouseGrabbed) {
 if (isAbsoluteEnabled) {
 /* Note that the origin for Cocoa mouse coords is bottom left, 
not top left.
- * The check on screenContainsPoint is to avoid sending out of 
range values for
+ * The check on screenContainsPointOfEvent is to avoid sending 
out of range values for
  * clicks in the titlebar.
  */
 if ([self screenContainsPointOfEvent:event]) {
-- 
2.19.2

[Qemu-devel] [PATCH] ci: store Patchew configuration in the tree

[Paolo Bonzini]

Patchew cannot yet retrieve the configuration from the QEMU Git tree, but
this is planned.  In the meanwhile, let's start storing it as YAML
so that the Patchew configuration (currently accessible only to administrators)
is public and documented.

Signed-off-by: Paolo Bonzini 
---
 .patchew.yml | 204 +++
 1 file changed, 204 insertions(+)
 create mode 100644 .patchew.yml

diff --git a/.patchew.yml b/.patchew.yml
new file mode 100644
index 00..54feda823e
--- /dev/null
+++ b/.patchew.yml
@@ -0,0 +1,204 @@
+# Note: this file is still unused.  It serves as a documentation for the
+# Patchew configuration in case patchew.org disappears or has to be
+# reinstalled.
+
+git:
+  push_to: g...@github.com:patchew-project/qemu
+  public_repo: https://github.com/patchew-project/qemu
+  url_template: https://github.com/patchew-project/qemu/tree/%t
+
+email:
+  ENOSPC:
+event: TestingReport
+to: f...@euphon.net
+reply_subject: false
+set_reply_to: false
+subject_template: 'Out of space error for {{ tester }}'
+body_template: |
+  {% if passed %}
+  {{ cancel }}
+  {% endif %}
+
+  {% if 'No space left on device' in log %}
+  Tester {{ tester }} out of space when running {{ test }}
+
+  {{ log | ansi2text }}
+  {% else %}
+  {{ cancel }}
+  {% endif %}
+
+  timeouts:
+event: TestingReport
+to: f...@euphon.net
+body_template: |
+  {% if not is_timeout %} {{ cancel }} {% endif %}
+
+  Test '{{ test }}' timeout, log:
+
+  {{ log | ansi2text }}
+
+  failures:
+event: TestingReport
+reply_to_all: true
+body_template: |
+  {% if passed or not obj.message_id or is_timeout %}
+{{ cancel }}
+  {% endif %}
+  {% if 'No space left on device' in log %}
+{{ cancel }}
+  {% endif %}
+  Patchew URL: https://patchew.org/QEMU/{{ obj.message_id }}/
+
+  {% ansi2text log as logtext %}
+  {% if test == "checkpatch" %}
+  Hi,
+
+  This series seems to have some coding style problems. See output below 
for
+  more information:
+
+  {{ logtext }}
+  {% elif test == "docker-mingw@fedora" or test == "docker-quick@centos7" 
or test == "asan" %}
+  Hi,
+
+  This series failed the {{ test }} build test. Please find the testing 
commands and
+  their output below. If you have Docker installed, you can probably 
reproduce it
+  locally.
+
+  {% lines_between logtext start="^=== TEST SCRIPT BEGIN ===$" stop="^=== 
TEST SCRIPT END ===$" %}
+  {% lines_between logtext start="^=== OUTPUT BEGIN ===$" stop="=== OUTPUT 
END ===$" as output %}
+  {% grep_C output regex="\b(FAIL|XPASS|ERROR|WARN|error:|warning:)" n=3 %}
+  {% elif test == "s390x" or test == "FreeBSD" or test == "ppcle" or test 
== "ppcbe" %}
+  Hi,
+
+  This series failed build test on {{test}} host. Please find the details 
below.
+
+  {% lines_between logtext start="^=== TEST SCRIPT BEGIN ===$" stop="^=== 
TEST SCRIPT END ===$" %}
+  {% lines_between logtext start="^=== OUTPUT BEGIN ===$" stop="=== OUTPUT 
END ===$" as output %}
+  {% grep_C output regex="\b(FAIL|XPASS|ERROR|WARN|error:|warning:)" n=3 %}
+  {% else %}
+  {{ cancel }}
+  {% endif %}
+
+  The full log is available at
+  {{ log_url }}.
+  ---
+  Email generated automatically by Patchew [http://patchew.org/].
+  Please send your feedback to patchew-de...@redhat.com
+
+testing:
+  defaults:
+- timeout: 3600
+
+  requirements:
+docker: |
+  #!/bin/bash
+  docker ps || sudo -n docker ps
+x86-kvm: |
+  #!/bin/bash
+  set -e
+  test "$(uname -m)" = x86_64
+  test -r /dev/kvm
+  if qemu-system-x86_64 --help >/dev/null 2>&1; then
+:
+  elif /usr/libexec/qemu-kvm --help >/dev/null 2>&1; then
+:
+  else
+false
+  fi
+ppcle: |
+  #!/bin/sh
+  test "$(uname -m)" = ppc64le
+ppcbe: |
+  #!/bin/sh
+  test "$(uname -m)" = ppc64
+s390x: |
+  #!/bin/sh
+  test "$(uname -m)" = s390x
+
+  tests:
+asan:
+  requirements: docker
+  script: |
+#!/bin/bash
+time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 
NETWORK=1
+
+docker-clang@ubuntu:
+  requirements: docker
+  script: |
+#!/bin/bash
+time make docker-test-clang@ubuntu SHOW_ENV=1 J=14 NETWORK=1
+
+docker-mingw@fedora:
+  requirements: docker
+  script: |
+#!/bin/bash
+time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
+
+docker-quick@centos7:
+  requirements: docker
+  script: |
+#!/bin/bash
+time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
+
+checkpatch:
+  script: |
+#!/bin/bash
+git rev-parse base > /dev/null || exit 0
+git config --local diff.renamelimit 0
+git config --local diff.renames True
+ 

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

[Paul Durrant]

> -Original Message-
> From: Jason Andryuk [mailto:jandr...@gmail.com]
> Sent: 14 March 2019 18:16
> To: Paul Durrant 
> Cc: qemu-devel@nongnu.org; xen-de...@lists.xenproject.org; 
> marma...@invisiblethingslab.com; Simon
> Gaiser ; Stefano Stabellini 
> ; Anthony Perard
> 
> Subject: Re: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
> 
> On Wed, Mar 13, 2019 at 11:09 AM Paul Durrant  wrote:
> >
> > > -Original Message-
> > > From: Jason Andryuk [mailto:jandr...@gmail.com]
> > > Sent: 11 March 2019 18:02
> > > To: qemu-devel@nongnu.org
> > > Cc: xen-de...@lists.xenproject.org; marma...@invisiblethingslab.com; 
> > > Simon Gaiser
> > > ; Jason Andryuk ; 
> > > Stefano Stabellini
> > > ; Anthony Perard ; 
> > > Paul Durrant
> > > 
> > > Subject: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
> > >
> > > From: Simon Gaiser 
> > >
> > > If a pci memory region has a size < XEN_PAGE_SIZE it can get located at
> > > an address which is not page aligned.
> >
> > IIRC the PCI spec says that the minimum memory region size should be at 
> > least 4k. Should we even be
> tolerating BARs smaller than that?
> >
> >   Paul
> >
> 
> Hi, Paul.
> 
> Simon found this, so it affects a real device.  Simon, do you recall
> which device was affected?
> 
> I think BARs only need to be power-of-two size and aligned, and 4k is
> not a minimum.  16bytes may be a minimum, but I don't know what the
> spec says.
> 
> On an Ivy Bridge system, here are some of the devices with BARs smaller than 
> 4K:
> 00:16.0 Communication controller: Intel Corporation 7 Series/C210
> Series Chipset Family MEI Controller #1 (rev 04)
>Memory at d0735000 (64-bit, non-prefetchable) [disabled] [size=16]
> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
>Memory at d0739000 (32-bit, non-prefetchable) [disabled] [size=1K]
> 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family
> SMBus Controller (rev 04)
>Memory at d0734000 (64-bit, non-prefetchable) [disabled] [size=256]
> 02:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host
> Controller (rev 30)
>Memory at d0503000 (32-bit, non-prefetchable) [disabled] [size=256]
> 
> These examples are all 4K aligned, so this is not an issue on this machine.
> 
> Reviewing the code, I'm now wondering if the following in
> hw/xen/xen_pt.c:xen_pt_region_update is wrong:rc =
> xc_domain_memory_mapping(xen_xc, xen_domid,
>  XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
>  XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
>  XEN_PFN(size + XC_PAGE_SIZE - 1),
>  op);
> 
> If a bar of size 0x100 is at 0xd0500800, then the machine_addr passed
> in would be 0xd0501000 which is past the actual location.  Should the
> call arguments just be XEN_PFN(guest_addr) & XEN_PFN(machine_addr)?
> 
> BARs smaller than a page would also be a problem if BARs for different
> devices shared the same page.

Exactly. We cannot pass them through with any degree of safety (not that 
passthrough of an arbitrary device is a particularly safe thing to do anyway). 
The xen-pt code would instead need to trap those BARs and perform the accesses 
to the real BAR itself. Ultimately though I think we should be retiring the 
xen-pt code in favour of a standalone emulator.

  Paul 

Re: [Qemu-devel] [PATCH] scripts/make-release: Stop shipping u-boot source as a tarball

[Peter Maydell]

On Thu, 14 Mar 2019 at 21:31, Philippe Mathieu-Daudé  wrote:
>
> Hi Peter,
>
> On 3/14/19 4:56 PM, Peter Maydell wrote:
> > In commit d0dead3b6df7f6cd970e we changed to shipping the u-boot
> > sources as a tarball, to work around a problem where they
> > contained a file and directory that had the same name except
> > for case, which was preventing QEMU's source tarball being
> > unpacked on case-insensitive filesystems.
> >
> > In commit f2a3b549e357041f86d7e we updated our u-boot blob
> > and sources to v2019.01, which no longer has this problem,
>
> Is this u-boot commit 610eec7f0593574c03?

Yes.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v7 6/7] vhost-user-blk: Add support to reconnect backend

[Daniel P . Berrangé]

On Thu, Mar 14, 2019 at 03:31:47PM +0300, Yury Kotov wrote:
> Hi,
> 
> 14.03.2019, 14:44, "Daniel P. Berrangé" :
> > On Thu, Mar 14, 2019 at 07:34:03AM -0400, Michael S. Tsirkin wrote:
> >>  On Thu, Mar 14, 2019 at 11:24:22AM +, Daniel P. Berrangé wrote:
> >>  > On Tue, Mar 12, 2019 at 12:49:35PM -0400, Michael S. Tsirkin wrote:
> >>  > > On Thu, Feb 28, 2019 at 04:53:54PM +0800, elohi...@gmail.com wrote:
> >>  > > > From: Xie Yongji 
> >>  > > >
> >>  > > > Since we now support the message VHOST_USER_GET_INFLIGHT_FD
> >>  > > > and VHOST_USER_SET_INFLIGHT_FD. The backend is able to restart
> >>  > > > safely because it can track inflight I/O in shared memory.
> >>  > > > This patch allows qemu to reconnect the backend after
> >>  > > > connection closed.
> >>  > > >
> >>  > > > Signed-off-by: Xie Yongji 
> >>  > > > Signed-off-by: Ni Xun 
> >>  > > > Signed-off-by: Zhang Yu 
> >>  > > > ---
> >>  > > > hw/block/vhost-user-blk.c | 205 +++--
> >>  > > > include/hw/virtio/vhost-user-blk.h | 4 +
> >>  > > > 2 files changed, 167 insertions(+), 42 deletions(-)
> >>  >
> >>  >
> >>  > > > static void vhost_user_blk_device_realize(DeviceState *dev, Error 
> >> **errp)
> >>  > > > {
> >>  > > > VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >>  > > > VHostUserBlk *s = VHOST_USER_BLK(vdev);
> >>  > > > VhostUserState *user;
> >>  > > > - struct vhost_virtqueue *vqs = NULL;
> >>  > > > int i, ret;
> >>  > > > + Error *err = NULL;
> >>  > > >
> >>  > > > if (!s->chardev.chr) {
> >>  > > > error_setg(errp, "vhost-user-blk: chardev is mandatory");
> >>  > > > @@ -312,27 +442,28 @@ static void 
> >> vhost_user_blk_device_realize(DeviceState *dev, Error **errp)
> >>  > > > }
> >>  > > >
> >>  > > > s->inflight = g_new0(struct vhost_inflight, 1);
> >>  > > > -
> >>  > > > - s->dev.nvqs = s->num_queues;
> >>  > > > - s->dev.vqs = g_new(struct vhost_virtqueue, s->dev.nvqs);
> >>  > > > - s->dev.vq_index = 0;
> >>  > > > - s->dev.backend_features = 0;
> >>  > > > - vqs = s->dev.vqs;
> >>  > > > -
> >>  > > > - vhost_dev_set_config_notifier(&s->dev, &blk_ops);
> >>  > > > -
> >>  > > > - ret = vhost_dev_init(&s->dev, s->vhost_user, 
> >> VHOST_BACKEND_TYPE_USER, 0);
> >>  > > > - if (ret < 0) {
> >>  > > > - error_setg(errp, "vhost-user-blk: vhost initialization failed: 
> >> %s",
> >>  > > > - strerror(-ret));
> >>  > > > - goto virtio_err;
> >>  > > > - }
> >>  > > > + s->vqs = g_new(struct vhost_virtqueue, s->num_queues);
> >>  > > > + s->watch = 0;
> >>  > > > + s->should_start = false;
> >>  > > > + s->connected = false;
> >>  > > > +
> >>  > > > + qemu_chr_fe_set_handlers(&s->chardev, NULL, NULL, 
> >> vhost_user_blk_event,
> >>  > > > + NULL, (void *)dev, NULL, true);
> >>  > > > +
> >>  > > > +reconnect:
> >>  > > > + do {
> >>  > > > + if (qemu_chr_fe_wait_connected(&s->chardev, &err) < 0) {
> >>  > > > + error_report_err(err);
> >>  > > > + err = NULL;
> >>  > > > + sleep(1);
> >>  > >
> >>  > > Seems arbitrary. Is this basically waiting until backend will 
> >> reconnect?
> >>  > > Why not block until event on the fd triggers?
> >>  > >
> >>  > > Also, it looks like this will just block forever with no monitor input
> >>  > > and no way for user to figure out what is going on short of
> >>  > > crashing QEMU.
> >>  >
> >>  > FWIW, the current vhost-user-net device does exactly the same thing
> >>  > with calling qemu_chr_fe_wait_connected during its realize() function.
> >>
> >>  Hmm yes. It doesn't sleep for an arbitrary 1 sec so less of an eyesore :)
> >
> > The sleep(1) in this patch simply needs to be removed. I think that
> > probably dates from when it was written against the earlier broken
> > version of qemu_chr_fe_wait_connected(). That would not correctly
> > deal with the "reconnect" flag, and so needing this loop with a sleep
> > in it.
> >
> > In fact the while loop can be removed as well in this code. It just
> > needs to call qemu_chr_fe_wait_connected() once. It is guaranteed
> > to have a connected peer once that returns 0.
> >
> > qemu_chr_fe_wait_connected() only returns -1 if the operating in
> > client mode, and it failed to connect and reconnect is *not*
> > requested. In such case the caller should honour the failure and
> > quit, not loop to retry.
> >
> > The reason vhost-user-net does a loop is because once it has a
> > connection it tries todo a protocol handshake, and if that
> > handshake fails it closes the chardev and tries to connect
> > again. That's not the case in this blk code os the loop is
> > not needed.
> >
> 
> But vhost-user-blk also has a handshake in device realize. What happens if the
> connection is broken during realization? IIUC we have to retry a handshake in
> such case just like vhost-user-net.

I'm just commenting on the current code which does not do that
handshake in the loop afaict. If it needs to do that then the
patch should be updated...


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange 

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Daniel P . Berrangé]

On Thu, Mar 14, 2019 at 06:22:44PM +, Peter Maydell wrote:
> On Thu, 14 Mar 2019 at 15:57, Alex Bennée  wrote:
> > Testing in the Cloud
> > 
> >
> > After BuildBot went out-of-service we have been relying heavily on Travis
> > as our primary CI platform. This has been creaking somewhat under the
> > strain and while we have a large test matrix its coverage is fairly
> > Ubuntu/x86 centric. However in recent months we've expanded and we now
> > have:
> >
> >   - Shippable, cross compilers - catches a lot of 32/64 bit isms
> >   - Cirrus, FreeBSD and MacOS builds
> >   - GitLab, Alternative x86/Debian - iotests
> 
> Are any of these capable of replacing my ad-hoc collection
> of build test systems for testing merges ? I would quite like
> to be able to do that, because it would make it easier for
> other people to take over the process of handling pull requests
> when I'm away.
> 
> I think the main requirements for that would be:
>  * covers full range of hosts[*]
>  * can be asked to do a test build of a merge before
>I push it to master
>  * reliably completes all builds within say 90 minutes
>of being asked to start

Out of all of the systems above, I would personally have a strong preference
for GitLab simply because it is actually based on open source software.
Putting a critical part of QEMU's workflow on to a closed source service
whose infrastructure or terms of service could change at any time, feels
risky to me. With GitLab in the worst case we can spin up an instance on
our own hardware to run our test stack, especially if we are already
providing our own test runners.

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

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Alex Bennée]

Fam Zheng  writes:

>> On Mar 15, 2019, at 16:57, Alex Bennée  wrote:
>>
>> I had installed the gitlab-runner from the Debian repo but it was out
>> of date and didn't seem to work correctly.
>
> If there can be a sidecar x86 box next to the test bot, it can be the
> controller node which runs gitlab-runner, the test script (in
> .gitlab-ci.yml) can then sshs into the actual env to run test
> commands.

Sure although that just adds complexity compared to spinning up a box in
the cloud ;-)

--
Alex Bennée

Re: [Qemu-devel] [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 15 March 2019 08:59
> To: qemu-devel@nongnu.org
> Cc: Roger Pau Monne ; Stefano Stabellini 
> ; Anthony
> Perard ; Paul Durrant ; 
> Igor Druzhinin
> ; Paolo Bonzini ; Richard 
> Henderson ;
> Eduardo Habkost ; Michael S. Tsirkin ; 
> Marcel Apfelbaum
> ; xen-de...@lists.xenproject.org
> Subject: [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint is 
> always honored
> 
> Or if it's not possible to honor the hinted address an error is returned
> instead. This makes it easier to spot the actual failure, instead of
> failing later on when the caller of xen_remap_bucket realizes the
> mapping has not been created at the requested address.
> 
> Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
> try harder to honor the passed address.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Paul Durrant 
> Cc: Igor Druzhinin 
> Cc: Paolo Bonzini 
> Cc: Richard Henderson 
> Cc: Eduardo Habkost 
> Cc: "Michael S. Tsirkin" 
> Cc: Marcel Apfelbaum 
> Cc: xen-de...@lists.xenproject.org
> ---
>  hw/i386/xen/xen-mapcache.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> index 349f72d00c..0e2870b320 100644
> --- a/hw/i386/xen/xen-mapcache.c
> +++ b/hw/i386/xen/xen-mapcache.c
> @@ -185,8 +185,14 @@ static void xen_remap_bucket(MapCacheEntry *entry,
>  }
> 
>  if (!dummy) {
> +/*
> + * If the caller has requested the mapping at a specific address use
> + * MAP_FIXED to make sure it's honored. Note that with MAP_FIXED at
> + * least FreeBSD will try harder to honor the passed address.
> + */
>  vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
> -   PROT_READ | PROT_WRITE, 0,
> +   PROT_READ | PROT_WRITE,
> +   vaddr ? MAP_FIXED : 0,
> nb_pfn, pfns, err);

AFAICT xen_remap_bucket() is always called with a NULL vaddr argument if 
entry->vaddr_base == NULL, and called with vaddr == entry->vaddr_base in the 
other case, so I'd say the vaddr argument is superfluous.
So, I think it would be better to just use entry->vaddr_base in the call above 
and I also wonder whether the mmap() below should only be allowed to happen if 
entry->vaddr_base == NULL.

  Paul

>  if (vaddr_base == NULL) {
>  perror("xenforeignmemory_map2");
> --
> 2.17.2 (Apple Git-113)

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Daniel P . Berrangé]

On Fri, Mar 15, 2019 at 09:34:27AM +, Alex Bennée wrote:
> 
> Daniel P. Berrangé  writes:
> 
> > On Thu, Mar 14, 2019 at 03:57:06PM +, Alex Bennée wrote:
> >> Docker Images
> >> =
> >>
> >> The addition of docker has unlocked the ability to build a lot more
> >> tests as well as compile testing on a much wider range of distros. I
> >> think there are two outstanding areas that need improvement
> >>
> >> Daniel has been looking at building and hosting the images somewhere.
> >> This would be useful as it would stop us slamming the distros
> >> repositories constantly rebuilding the same images and also help reduce
> >> the time to test.
> >
> > My intent was/still is to make use of quay.io for hosting prebuilt
> > images.
> >
> > As well as avoiding repeated builds for developers it means that
> > developers can be gauranteed to actually be testing with the same
> > content that the automated CI did. Currently everyone using the
> > docker images potentially has slightly different environment as
> > it depends on what packages were in the repos when they built
> > the image locally. This is very bad for reproducability.
> >
> > Libvirt uses quay.io for hosting images already and I've been
> > looking at creating a script to automate usage of it via their
> > REST API. Once done the same script should be usable by QEMU
> > too.
> >
> > The idea would be that we still have docker files in the
> > tests/docker/dockerfiles directory, but they would only be used
> > for an automated job which triggers builds on quay.io, or for the
> > few people who need to make changes to the dockerfiles. The current
> > make rules used by developers / CI systems for executing test builds
> > would be changed to simply pull the pre-built image off quay.io
> > instead of running a docker build again.
> 
> Could we just have a script that pulls the quay.io image and tags it as
> the appropriate target and then we could do:
> 
>   make docker-image-debian-arm64-cross [REBUILD=1]
> 
> which would normally pull the quay.io image but if REBUILD=1 would force
> a local rebuild?

Perhaps, I hadn't really got as far as thinking about the make
integration side.

> 
> >> The other area that needs some work is better supporting non-x86 hosts.
> >> While Docker's multi-arch story is much better (docker run debian:stable
> >> will DTRT on any main architecture) we get stumped by things like
> >> Debian's uneven support of cross compilers. For 4.1 I'd like to
> >> reorganise the dockerfiles subdirectory into multiarch and arch specific
> >> directories so we approach this is a less ad-hoc way. It would also be
> >> nice to have the ability to gracefully fallback to linux-user powered
> >> images where the host architecture doesn't have what we need.
> 
> I suspect we'd never store linux-user powered images on quay.io as there
> are niggly differences depending on the users binfmt_misc setup.

Wouldn't we just upload the cross-build images and rely on the user's
host to have registered binfmts needed to execute foreign binaries
in the container ?

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 v6 0/2] Add Arm SBSA Reference Machine

[Hongbo Zhang]

For the Aarch64, there is one machine 'virt', it is primarily meant to
run on KVM and execute virtualization workloads, but we need an
environment as faithful as possible to physical hardware,  to support
firmware and OS development for pysical Aarch64 machines.

This machine comes with:
 - Re-designed memory map.
 - CPU cortex-a57.
 - EL2 and EL3 enabled.
 - GIC version 3.
 - System bus AHCI controller.
 - System bus XHCI controller.
 - CDROM and hard disc on AHCI bus.
 - E1000E ethernet card on PCIE bus.
 - VGA display adaptor on PCIE bus.
 - Only minimal device tree nodes.
And without:
 - virtio deivces.
 - fw_cfg device.
 - ACPI tables.

Arm Trusted Firmware and UEFI porting to this are done accordingly, and
it should supply ACPI tables to load OS, the minimal device tree nodes
supplied from this platform are only to pass the dynamic info reflecting
command line input to firmware, not for loading OS.

v6 changes:
 - rebased to the latest QEMU tree
 - rechecked all the header files included
 - added the newly introduced system bus EHCI controller
 - removed the machine_done callback due to commit 5614ca80
 - updated block comments styles according to checkpatch.pl
 - use Kconfig to add new file
 - use private SBSA* types defination instead of VIRT* in virt.h
   since nobody else using them so they are in the .c file instead
   of a new .h file

v5 changes:
 - removed more lines derived from virt.c
 - designed a new memory map
 - splitted former one patch into two for easier review
 - cancled previous EHCI and new HXCI coming later separately

V4 changes:
 - rebased to v3.0.0
 - removed timer, uart, rtc, *hci device tree nodes
   (others were removerd in v3)
 - other minore codes clean up, mainly unsed header files, comments etc.

V3 changes:
 - rename the platform 'sbsa-ref'
 - move all the codes to a separate file sbsa-ref.c
 - remove paravirtualized fw_cfg device
 - do not supply ACPI tables, since firmware will do it
 - supply only necessary DT nodes
 - and other minor code clean up

In the previous v4 cover letter,
https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg04282.html
I mentioned I had to revert two commits temperarily to run:
 Revert "target/arm: Implement new do_transaction_failed hook"
 Revert "device_tree: Increase FDT_MAX_SIZE to 1 MiB"

Now the 1st one is fixed by Ard Biesheuvel in the edk2 side, and for
the 2nd one, a simple change in firmware side can fix it, so I won't
mention these issues in details in the cover letter any more.

I also put a branch here:
http://git.linaro.org/people/hongbo.zhang/qemu-enterprise.git/log/?h=sbsa-upstream-v6

Hongbo Zhang (2):
  hw/arm: Add arm SBSA reference machine, skeleton part
  hw/arm: Add arm SBSA reference machine, devices part

 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Kconfig  |   3 +
 hw/arm/Makefile.objs|   1 +
 hw/arm/sbsa-ref.c   | 754 
 4 files changed, 759 insertions(+)
 create mode 100644 hw/arm/sbsa-ref.c

-- 
2.7.4

[Qemu-devel] [PATCH v6 2/2] hw/arm: Add arm SBSA reference machine, devices part

[Hongbo Zhang]

Following the previous patch, this patch adds peripheral devices to the
newly introduced SBSA-ref machine.

Signed-off-by: Hongbo Zhang 
---
 hw/arm/sbsa-ref.c | 451 ++
 1 file changed, 451 insertions(+)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index b6d31f2..6b26111 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -21,6 +21,7 @@
 #include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "qemu/units.h"
+#include "sysemu/device_tree.h"
 #include "sysemu/numa.h"
 #include "sysemu/sysemu.h"
 #include "exec/address-spaces.h"
@@ -28,11 +29,28 @@
 #include "kvm_arm.h"
 #include "hw/arm/arm.h"
 #include "hw/boards.h"
+#include "hw/ide/internal.h"
+#include "hw/ide/ahci_internal.h"
 #include "hw/intc/arm_gicv3_common.h"
+#include "hw/loader.h"
+#include "hw/pci-host/gpex.h"
+#include "hw/usb.h"
+#include "net/net.h"
 
 #define RAMLIMIT_GB 8192
 #define RAMLIMIT_BYTES (RAMLIMIT_GB * GiB)
 
+#define NUM_IRQS256
+#define NUM_SMMU_IRQS   4
+#define NUM_SATA_PORTS  6
+
+#define VIRTUAL_PMU_IRQ7
+#define ARCH_GIC_MAINT_IRQ 9
+#define ARCH_TIMER_VIRT_IRQ11
+#define ARCH_TIMER_S_EL1_IRQ   13
+#define ARCH_TIMER_NS_EL1_IRQ  14
+#define ARCH_TIMER_NS_EL2_IRQ  10
+
 enum {
 SBSA_FLASH,
 SBSA_MEM,
@@ -112,6 +130,415 @@ static const int sbsa_ref_irqmap[] = {
 [SBSA_EHCI] = 10,
 };
 
+/*
+ * Firmware on this machine only uses ACPI table to load OS, these limited
+ * device tree nodes are just to let firmware know the info which varies from
+ * command line parameters, so it is not necessary to be fully compatible
+ * with the kernel CPU and NUMA binding rules.
+ */
+static void create_fdt(SBSAMachineState *vms)
+{
+void *fdt = create_device_tree(&vms->fdt_size);
+const MachineState *ms = MACHINE(vms);
+int cpu;
+
+if (!fdt) {
+error_report("create_device_tree() failed");
+exit(1);
+}
+
+vms->fdt = fdt;
+
+qemu_fdt_setprop_string(fdt, "/", "compatible", "linux,sbsa-ref");
+qemu_fdt_setprop_cell(fdt, "/", "#address-cells", 0x2);
+qemu_fdt_setprop_cell(fdt, "/", "#size-cells", 0x2);
+
+if (have_numa_distance) {
+int size = nb_numa_nodes * nb_numa_nodes * 3 * sizeof(uint32_t);
+uint32_t *matrix = g_malloc0(size);
+int idx, i, j;
+
+for (i = 0; i < nb_numa_nodes; i++) {
+for (j = 0; j < nb_numa_nodes; j++) {
+idx = (i * nb_numa_nodes + j) * 3;
+matrix[idx + 0] = cpu_to_be32(i);
+matrix[idx + 1] = cpu_to_be32(j);
+matrix[idx + 2] = cpu_to_be32(numa_info[i].distance[j]);
+}
+}
+
+qemu_fdt_add_subnode(fdt, "/distance-map");
+qemu_fdt_setprop(fdt, "/distance-map", "distance-matrix",
+ matrix, size);
+g_free(matrix);
+}
+
+qemu_fdt_add_subnode(vms->fdt, "/cpus");
+
+for (cpu = vms->smp_cpus - 1; cpu >= 0; cpu--) {
+char *nodename = g_strdup_printf("/cpus/cpu@%d", cpu);
+ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(cpu));
+CPUState *cs = CPU(armcpu);
+
+qemu_fdt_add_subnode(vms->fdt, nodename);
+
+if (ms->possible_cpus->cpus[cs->cpu_index].props.has_node_id) {
+qemu_fdt_setprop_cell(vms->fdt, nodename, "numa-node-id",
+ms->possible_cpus->cpus[cs->cpu_index].props.node_id);
+}
+
+g_free(nodename);
+}
+}
+
+static void create_one_flash(const char *name, hwaddr flashbase,
+ hwaddr flashsize, const char *file,
+ MemoryRegion *sysmem)
+{
+/*
+ * Create and map a single flash device. We use the same
+ * parameters as the flash devices on the Versatile Express board.
+ */
+DriveInfo *dinfo = drive_get_next(IF_PFLASH);
+DeviceState *dev = qdev_create(NULL, "cfi.pflash01");
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+const uint64_t sectorlength = 256 * 1024;
+
+if (dinfo) {
+qdev_prop_set_drive(dev, "drive", blk_by_legacy_dinfo(dinfo),
+&error_abort);
+}
+
+qdev_prop_set_uint32(dev, "num-blocks", flashsize / sectorlength);
+qdev_prop_set_uint64(dev, "sector-length", sectorlength);
+qdev_prop_set_uint8(dev, "width", 4);
+qdev_prop_set_uint8(dev, "device-width", 2);
+qdev_prop_set_bit(dev, "big-endian", false);
+qdev_prop_set_uint16(dev, "id0", 0x89);
+qdev_prop_set_uint16(dev, "id1", 0x18);
+qdev_prop_set_uint16(dev, "id2", 0x00);
+qdev_prop_set_uint16(dev, "id3", 0x00);
+qdev_prop_set_string(dev, "name", name);
+qdev_init_nofail(dev);
+
+memory_region_add_subregion(sysmem, flashbase,
+sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 
0));
+
+if (file) {
+char *fn;
+int image_size;
+
+if (drive_get(IF_PFLASH, 0, 0)) {
+error_report("The contents of the first flash device may

[Qemu-devel] [PATCH v6 1/2] hw/arm: Add arm SBSA reference machine, skeleton part

[Hongbo Zhang]

For the Aarch64, there is one machine 'virt', it is primarily meant to
run on KVM and execute virtualization workloads, but we need an
environment as faithful as possible to physical hardware, for supporting
firmware and OS development for pysical Aarch64 machines.

This patch introduces new machine type 'sbsa-ref' with main features:
 - Based on 'virt' machine type.
 - A new memory map.
 - CPU type cortex-a57.
 - EL2 and EL3 are enabled.
 - GIC version 3.
 - System bus AHCI controller.
 - System bus EHCI controller.
 - CDROM and hard disc on AHCI bus.
 - E1000E ethernet card on PCIE bus.
 - VGA display adaptor on PCIE bus.
 - No virtio deivces.
 - No fw_cfg device.
 - No ACPI table supplied.
 - Only minimal device tree nodes.

Arm Trusted Firmware and UEFI porting to this are done accordingly, and
it should supply ACPI tables to load OS, the minimal device tree nodes
supplied from this platform are only to pass the dynamic info reflecting
command line input to firmware, not for loading OS.

To make the review easier, this task is split into two patches, the
fundamental sceleton part and the peripheral devices part, this patch is
the first part.

Signed-off-by: Hongbo Zhang 
---
 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Kconfig  |   3 +
 hw/arm/Makefile.objs|   1 +
 hw/arm/sbsa-ref.c   | 303 
 4 files changed, 308 insertions(+)
 create mode 100644 hw/arm/sbsa-ref.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 2a7efc1..4fbb6ac 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -144,6 +144,7 @@ CONFIG_IOH3420=y
 CONFIG_I82801B11=y
 CONFIG_ACPI=y
 CONFIG_ARM_VIRT=y
+CONFIG_SBSA_REF=y
 CONFIG_SMBIOS=y
 CONFIG_ASPEED_SOC=y
 CONFIG_SMBUS_EEPROM=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index d298fbd..6654914 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -38,6 +38,9 @@ config PXA2XX
 config REALVIEW
 bool
 
+config SBSA_REF
+bool
+
 config STELLARIS
 bool
 
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index fa57c7c..fa812ec 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -12,6 +12,7 @@ obj-$(CONFIG_NSERIES) += nseries.o
 obj-$(CONFIG_OMAP) += omap_sx1.o palm.o
 obj-$(CONFIG_PXA2XX) += gumstix.o spitz.o tosa.o z2.o
 obj-$(CONFIG_REALVIEW) += realview.o
+obj-$(CONFIG_SBSA_REF) += sbsa-ref.o
 obj-$(CONFIG_STELLARIS) += stellaris.o
 obj-$(CONFIG_STRONGARM) += collie.o
 obj-$(CONFIG_VERSATILE) += vexpress.o versatilepb.o
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
new file mode 100644
index 000..b6d31f2
--- /dev/null
+++ b/hw/arm/sbsa-ref.c
@@ -0,0 +1,303 @@
+/*
+ * ARM SBSA Reference Platform emulation
+ *
+ * Copyright (c) 2018 Linaro Limited
+ * Written by Hongbo Zhang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+#include "qemu/units.h"
+#include "sysemu/numa.h"
+#include "sysemu/sysemu.h"
+#include "exec/address-spaces.h"
+#include "exec/hwaddr.h"
+#include "kvm_arm.h"
+#include "hw/arm/arm.h"
+#include "hw/boards.h"
+#include "hw/intc/arm_gicv3_common.h"
+
+#define RAMLIMIT_GB 8192
+#define RAMLIMIT_BYTES (RAMLIMIT_GB * GiB)
+
+enum {
+SBSA_FLASH,
+SBSA_MEM,
+SBSA_CPUPERIPHS,
+SBSA_GIC_DIST,
+SBSA_GIC_REDIST,
+SBSA_SMMU,
+SBSA_UART,
+SBSA_RTC,
+SBSA_PCIE,
+SBSA_PCIE_MMIO,
+SBSA_PCIE_MMIO_HIGH,
+SBSA_PCIE_PIO,
+SBSA_PCIE_ECAM,
+SBSA_GPIO,
+SBSA_SECURE_UART,
+SBSA_SECURE_MEM,
+SBSA_AHCI,
+SBSA_EHCI,
+};
+
+typedef struct MemMapEntry {
+hwaddr base;
+hwaddr size;
+} MemMapEntry;
+
+typedef struct {
+MachineState parent;
+struct arm_boot_info bootinfo;
+const MemMapEntry *memmap;
+const int *irqmap;
+int smp_cpus;
+void *fdt;
+int fdt_size;
+int psci_conduit;
+} SBSAMachineState;
+
+#define TYPE_SBSA_MACHINE   MACHINE_TYPE_NAME("sbsa-ref")
+#define SBSA_MACHINE(obj) \
+OBJECT_CHECK(SBSAMachineState, (obj), TYPE_SBSA_MACHINE)
+
+static const MemMapEntry sbsa_ref_memmap[] = {
+/* 512M boot ROM */
+[SBSA_FLASH] =  {  0, 0x2000 },
+/* 512M secure memory */
+[SBSA_SECURE_MEM] = { 0x2000, 0x2000 },
+/* Space reserved for CPU peripheral devices */
+[SBSA_CPUPERIPHS] = 

Re: [Qemu-devel] [PATCH] curses ui: always initialize all curses_line fields

[Peter Maydell]

On Fri, 15 Mar 2019 at 08:37, Samuel Thibault
 wrote:
>
> cchar_t can contain not only attr and chars fields, but also ext_color.
> Initialize the whole structure to zero instead of enumerating fields.
>
> Spotted by Coverity: CID 1399711
>
> Signed-off-by: Samuel Thibault 
> ---
>  ui/curses.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/ui/curses.c b/ui/curses.c
> index d29098db9f..e99fbe3e24 100644
> --- a/ui/curses.c
> +++ b/ui/curses.c
> @@ -75,9 +75,8 @@ static void curses_update(DisplayChangeListener *dcl,
>  if (vga_to_curses[ch].chars[0]) {
>  curses_line[x] = vga_to_curses[ch];
>  } else {
> +curses_line[x] = (cchar_t) {};
>  curses_line[x].chars[0] = ch;
> -curses_line[x].chars[1] = 0;
> -curses_line[x].attr = 0;
>  }
>  curses_line[x].attr |= at;

Does this really need the cast ? {} is supposed to be a
universal initializer.

thanks
-- PMM

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Alex Bennée]

Daniel P. Berrangé  writes:

> On Fri, Mar 15, 2019 at 09:34:27AM +, Alex Bennée wrote:
>>
>> Daniel P. Berrangé  writes:
>>
>> > On Thu, Mar 14, 2019 at 03:57:06PM +, Alex Bennée wrote:
>> >> Docker Images
>> >> =
>> >>
>> >> The addition of docker has unlocked the ability to build a lot more
>> >> tests as well as compile testing on a much wider range of distros. I
>> >> think there are two outstanding areas that need improvement
>> >>
>> >> Daniel has been looking at building and hosting the images somewhere.
>> >> This would be useful as it would stop us slamming the distros
>> >> repositories constantly rebuilding the same images and also help reduce
>> >> the time to test.
>> >
>> > My intent was/still is to make use of quay.io for hosting prebuilt
>> > images.
>> >
>> > As well as avoiding repeated builds for developers it means that
>> > developers can be gauranteed to actually be testing with the same
>> > content that the automated CI did. Currently everyone using the
>> > docker images potentially has slightly different environment as
>> > it depends on what packages were in the repos when they built
>> > the image locally. This is very bad for reproducability.
>> >
>> > Libvirt uses quay.io for hosting images already and I've been
>> > looking at creating a script to automate usage of it via their
>> > REST API. Once done the same script should be usable by QEMU
>> > too.
>> >
>> > The idea would be that we still have docker files in the
>> > tests/docker/dockerfiles directory, but they would only be used
>> > for an automated job which triggers builds on quay.io, or for the
>> > few people who need to make changes to the dockerfiles. The current
>> > make rules used by developers / CI systems for executing test builds
>> > would be changed to simply pull the pre-built image off quay.io
>> > instead of running a docker build again.
>>
>> Could we just have a script that pulls the quay.io image and tags it as
>> the appropriate target and then we could do:
>>
>>   make docker-image-debian-arm64-cross [REBUILD=1]
>>
>> which would normally pull the quay.io image but if REBUILD=1 would force
>> a local rebuild?
>
> Perhaps, I hadn't really got as far as thinking about the make
> integration side.
>
>>
>> >> The other area that needs some work is better supporting non-x86 hosts.
>> >> While Docker's multi-arch story is much better (docker run debian:stable
>> >> will DTRT on any main architecture) we get stumped by things like
>> >> Debian's uneven support of cross compilers. For 4.1 I'd like to
>> >> reorganise the dockerfiles subdirectory into multiarch and arch specific
>> >> directories so we approach this is a less ad-hoc way. It would also be
>> >> nice to have the ability to gracefully fallback to linux-user powered
>> >> images where the host architecture doesn't have what we need.
>>
>> I suspect we'd never store linux-user powered images on quay.io as there
>> are niggly differences depending on the users binfmt_misc setup.
>
> Wouldn't we just upload the cross-build images and rely on the user's
> host to have registered binfmts needed to execute foreign binaries
> in the container ?

That's true - a linux-user powered image is really just a native arch
image with the addition of qemu. We already have the tooling to upload a
local QEMU into the image as-per the current binfmt_misc settings
(docker.py update).

--
Alex Bennée

Re: [Qemu-devel] [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne
> Sent: 15 March 2019 10:10
> To: Paul Durrant 
> Cc: qemu-devel@nongnu.org; Stefano Stabellini ; 
> Anthony Perard
> ; Igor Druzhinin ; 
> Paolo Bonzini
> ; Richard Henderson ; Eduardo Habkost 
> ;
> Michael S. Tsirkin ; Marcel Apfelbaum 
> ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address 
> hint is always honored
> 
> On Fri, Mar 15, 2019 at 10:54:42AM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Roger Pau Monne [mailto:roger@citrix.com]
> > > Sent: 15 March 2019 08:59
> > > To: qemu-devel@nongnu.org
> > > Cc: Roger Pau Monne ; Stefano Stabellini 
> > > ; Anthony
> > > Perard ; Paul Durrant 
> > > ; Igor Druzhinin
> > > ; Paolo Bonzini ; Richard 
> > > Henderson
> ;
> > > Eduardo Habkost ; Michael S. Tsirkin 
> > > ; Marcel Apfelbaum
> > > ; xen-de...@lists.xenproject.org
> > > Subject: [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address 
> > > hint is always honored
> > >
> > > Or if it's not possible to honor the hinted address an error is returned
> > > instead. This makes it easier to spot the actual failure, instead of
> > > failing later on when the caller of xen_remap_bucket realizes the
> > > mapping has not been created at the requested address.
> > >
> > > Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
> > > try harder to honor the passed address.
> > >
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Cc: Stefano Stabellini 
> > > Cc: Anthony Perard 
> > > Cc: Paul Durrant 
> > > Cc: Igor Druzhinin 
> > > Cc: Paolo Bonzini 
> > > Cc: Richard Henderson 
> > > Cc: Eduardo Habkost 
> > > Cc: "Michael S. Tsirkin" 
> > > Cc: Marcel Apfelbaum 
> > > Cc: xen-de...@lists.xenproject.org
> > > ---
> > >  hw/i386/xen/xen-mapcache.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> > > index 349f72d00c..0e2870b320 100644
> > > --- a/hw/i386/xen/xen-mapcache.c
> > > +++ b/hw/i386/xen/xen-mapcache.c
> > > @@ -185,8 +185,14 @@ static void xen_remap_bucket(MapCacheEntry *entry,
> > >  }
> > >
> > >  if (!dummy) {
> > > +/*
> > > + * If the caller has requested the mapping at a specific address 
> > > use
> > > + * MAP_FIXED to make sure it's honored. Note that with MAP_FIXED 
> > > at
> > > + * least FreeBSD will try harder to honor the passed address.
> > > + */
> > >  vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
> > > -   PROT_READ | PROT_WRITE, 0,
> > > +   PROT_READ | PROT_WRITE,
> > > +   vaddr ? MAP_FIXED : 0,
> > > nb_pfn, pfns, err);
> >
> > AFAICT xen_remap_bucket() is always called with a NULL vaddr argument if 
> > entry->vaddr_base == NULL,
> and called with vaddr == entry->vaddr_base in the other case, so I'd say the 
> vaddr argument is
> superfluous.
> > So, I think it would be better to just use entry->vaddr_base in the call 
> > above and I also wonder
> whether the mmap() below should only be allowed to happen if 
> entry->vaddr_base == NULL.
> 
> The suggested changes above look reasonable to me (note I'm not
> familiar with qemu Xen mapcache), however they should be separate
> patch(es) IMO, since they are not directly related to the MAP_FIXED
> issue this patch attempts to fix.
> 
> I would prefer to keep this patch as-is if possible, so that it's
> easier and safer for me to backport in order to fix qemu in Xen 4.11
> for FreeBSD.

I think it does indeed DTRT as-is. Let's see what Anthony says.

  Paul

> 
> Thanks, Roger.

Re: [Qemu-devel] [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

[Roger Pau Monné]

On Fri, Mar 15, 2019 at 10:54:42AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne [mailto:roger@citrix.com]
> > Sent: 15 March 2019 08:59
> > To: qemu-devel@nongnu.org
> > Cc: Roger Pau Monne ; Stefano Stabellini 
> > ; Anthony
> > Perard ; Paul Durrant ; 
> > Igor Druzhinin
> > ; Paolo Bonzini ; Richard 
> > Henderson ;
> > Eduardo Habkost ; Michael S. Tsirkin 
> > ; Marcel Apfelbaum
> > ; xen-de...@lists.xenproject.org
> > Subject: [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint 
> > is always honored
> > 
> > Or if it's not possible to honor the hinted address an error is returned
> > instead. This makes it easier to spot the actual failure, instead of
> > failing later on when the caller of xen_remap_bucket realizes the
> > mapping has not been created at the requested address.
> > 
> > Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
> > try harder to honor the passed address.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Anthony Perard 
> > Cc: Paul Durrant 
> > Cc: Igor Druzhinin 
> > Cc: Paolo Bonzini 
> > Cc: Richard Henderson 
> > Cc: Eduardo Habkost 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Marcel Apfelbaum 
> > Cc: xen-de...@lists.xenproject.org
> > ---
> >  hw/i386/xen/xen-mapcache.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> > index 349f72d00c..0e2870b320 100644
> > --- a/hw/i386/xen/xen-mapcache.c
> > +++ b/hw/i386/xen/xen-mapcache.c
> > @@ -185,8 +185,14 @@ static void xen_remap_bucket(MapCacheEntry *entry,
> >  }
> > 
> >  if (!dummy) {
> > +/*
> > + * If the caller has requested the mapping at a specific address 
> > use
> > + * MAP_FIXED to make sure it's honored. Note that with MAP_FIXED at
> > + * least FreeBSD will try harder to honor the passed address.
> > + */
> >  vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
> > -   PROT_READ | PROT_WRITE, 0,
> > +   PROT_READ | PROT_WRITE,
> > +   vaddr ? MAP_FIXED : 0,
> > nb_pfn, pfns, err);
> 
> AFAICT xen_remap_bucket() is always called with a NULL vaddr argument if 
> entry->vaddr_base == NULL, and called with vaddr == entry->vaddr_base in the 
> other case, so I'd say the vaddr argument is superfluous.
> So, I think it would be better to just use entry->vaddr_base in the call 
> above and I also wonder whether the mmap() below should only be allowed to 
> happen if entry->vaddr_base == NULL.

The suggested changes above look reasonable to me (note I'm not
familiar with qemu Xen mapcache), however they should be separate
patch(es) IMO, since they are not directly related to the MAP_FIXED
issue this patch attempts to fix.

I would prefer to keep this patch as-is if possible, so that it's
easier and safer for me to backport in order to fix qemu in Xen 4.11
for FreeBSD.

Thanks, Roger.

[Qemu-devel] [PATCH v5 3/5] RISC-V: Fixes to CSR_* register macros.

[Chih-Min Chao]

From: Jim Wilson 

This adds some missing CSR_* register macros, and documents some as being
priv v1.9.1 specific.

Signed-off-by: Jim Wilson 
Reviewed-by: Alistair Francis 
Message-Id: <20190212230830.9160-1-j...@sifive.com>
---
 target/riscv/cpu_bits.h | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 7afcb24..7180fcc 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -135,16 +135,22 @@
 /* Legacy Counter Setup (priv v1.9.1) */
 #define CSR_MUCOUNTEREN 0x320
 #define CSR_MSCOUNTEREN 0x321
+#define CSR_MHCOUNTEREN 0x322
 
 /* Machine Trap Handling */
 #define CSR_MSCRATCH0x340
 #define CSR_MEPC0x341
 #define CSR_MCAUSE  0x342
-#define CSR_MBADADDR0x343
+#define CSR_MTVAL   0x343
 #define CSR_MIP 0x344
 
+/* Legacy Machine Trap Handling (priv v1.9.1) */
+#define CSR_MBADADDR0x343
+
 /* Supervisor Trap Setup */
 #define CSR_SSTATUS 0x100
+#define CSR_SEDELEG 0x102
+#define CSR_SIDELEG 0x103
 #define CSR_SIE 0x104
 #define CSR_STVEC   0x105
 #define CSR_SCOUNTEREN  0x106
@@ -153,9 +159,12 @@
 #define CSR_SSCRATCH0x140
 #define CSR_SEPC0x141
 #define CSR_SCAUSE  0x142
-#define CSR_SBADADDR0x143
+#define CSR_STVAL   0x143
 #define CSR_SIP 0x144
 
+/* Legacy Supervisor Trap Handling (priv v1.9.1) */
+#define CSR_SBADADDR0x143
+
 /* Supervisor Protection and Translation */
 #define CSR_SPTBR   0x180
 #define CSR_SATP0x180
@@ -282,6 +291,28 @@
 #define CSR_MHPMCOUNTER30H  0xb9e
 #define CSR_MHPMCOUNTER31H  0xb9f
 
+/* Legacy Hypervisor Trap Setup (priv v1.9.1) */
+#define CSR_HSTATUS 0x200
+#define CSR_HEDELEG 0x202
+#define CSR_HIDELEG 0x203
+#define CSR_HIE 0x204
+#define CSR_HTVEC   0x205
+
+/* Legacy Hypervisor Trap Handling (priv v1.9.1) */
+#define CSR_HSCRATCH0x240
+#define CSR_HEPC0x241
+#define CSR_HCAUSE  0x242
+#define CSR_HBADADDR0x243
+#define CSR_HIP 0x244
+
+/* Legacy Machine Protection and Translation (priv v1.9.1) */
+#define CSR_MBASE   0x380
+#define CSR_MBOUND  0x381
+#define CSR_MIBASE  0x382
+#define CSR_MIBOUND 0x383
+#define CSR_MDBASE  0x384
+#define CSR_MDBOUND 0x385
+
 /* mstatus CSR bits */
 #define MSTATUS_UIE 0x0001
 #define MSTATUS_SIE 0x0002
-- 
2.7.4

Re: [Qemu-devel] [PATCH] scripts/make-release: Stop shipping u-boot source as a tarball

[Philippe Mathieu-Daudé]

On 3/15/19 10:46 AM, Peter Maydell wrote:
> On Thu, 14 Mar 2019 at 21:31, Philippe Mathieu-Daudé  
> wrote:
>>
>> Hi Peter,
>>
>> On 3/14/19 4:56 PM, Peter Maydell wrote:
>>> In commit d0dead3b6df7f6cd970e we changed to shipping the u-boot
>>> sources as a tarball, to work around a problem where they
>>> contained a file and directory that had the same name except
>>> for case, which was preventing QEMU's source tarball being
>>> unpacked on case-insensitive filesystems.
>>>
>>> In commit f2a3b549e357041f86d7e we updated our u-boot blob
>>> and sources to v2019.01, which no longer has this problem,
>>
>> Is this u-boot commit 610eec7f0593574c03?
> 
> Yes.

Good.
I checked u-boot range v2017.07..v2019.01 and did not notice other fixes.
I'd appreciate if you add a comment about this u-boot commit :)

Regardless:
Reviewed-by: Philippe Mathieu-Daudé 

Thanks,

Phil.

Re: [Qemu-devel] [PULL 17/29] target/riscv: Convert quadrant 1 of RVXC insns to decodetree

[Palmer Dabbelt]

On Fri, 15 Mar 2019 02:06:07 PDT (-0700), Bastian Koppelmann wrote:

Hi Alistair

On 3/14/19 9:28 PM, Alistair Francis wrote:

On Wed, Mar 13, 2019 at 7:53 AM Palmer Dabbelt  wrote:

From: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
Signed-off-by: Bastian Koppelmann 
Signed-off-by: Peer Adelt 

This commit is the first bad commit in breaking 32-bit boot.

It looks like the jal doesn't jump to the correct address:


IN:
0x8022:  00050433  add s0,a0,zero
0x8026:  000584b3  add s1,a1,zero
0x802a:  2c79  jal ra,670  # 0x82c8


IN:
0x82c8:  0533  add a0,zero,zero
0x82cc:  8082  ret



Oops! Can you point me to the binary to reproduce this?


I think I've traced it down to something simple: in my hello world binary I see

   20401a8c:   2a45jal 20401c3c 

in the objdump, and I see

   IN: _start
   0x20401a8c:  2a45  jal ra,432  # 0x20401c3c

but then QEMU jumps to 0x20401a9d.  I have a feeling it's something wrong with 
gen_jal() that disappeared during the cleanups that we dropped in order to fix 
the build issues.


I'm running

   ./riscv32-softmmu/qemu-system-riscv32 -machine sifive_e -kernel 
~/work/sifive/freedom-e-sdk/software/hello/hello -nographic -d 
in_asm,out_asm,exec,cpu -singlestep |& tee out.log

on the "hifive1" branch of github.com/palmer-dabbelt/qemu, which just has a 
PRCI fixup that I forgot about and haven't sent upstream yet (I'll do that 
after this issue).  The binary should be at


   http://www.dabbelt.com/~palmer/hello.elf

and the debug log at 


   http://www.dabbelt.com/~palmer/out.log

You can build the binary from github.com/sifive/freedom-e-sdk via

  make software PROGRAM=hello TARGET=sifive-hifive1

using the riscv64-unknown-elf-gcc-20181127-x86_64-linux-ubuntu14 toolchain 
binaries from our website (newer ones should work, but probably won't produce 
exactly the same output).


I'll poke around after grabbing some dinner...

[Qemu-devel] [PATCH 1/2] target/mips: Optimize ILVOD. MSA instructions

[Mateja Marjanovic]

From: Mateja Marjanovic 

Optimize set of MSA instructions ILVOD, using directly
tcg registers and performing logic on them insted of
using helpers.
Performance measurement is done by executing the
instructions large number of times on a computer
with Intel Core i7-3770 CPU @ 3.40GHz×8.

 instruction ||before||after   ||
==
 ilvod.b:||   66.97 ms   ||  26.34 ms  ||
 ilvod.h:||   44.75 ms   ||  25.17 ms  ||
 ilvod.w:||   41.27 ms   ||  24.37 ms  ||
 ilvod.d:||   41.75 ms   ||  20.50 ms  ||

Signed-off-by: Mateja Marjanovic 
---
 target/mips/helper.h |   1 -
 target/mips/msa_helper.c |  51 
 target/mips/translate.c  | 119 ++-
 3 files changed, 118 insertions(+), 53 deletions(-)

diff --git a/target/mips/helper.h b/target/mips/helper.h
index a6d687e..d162836 100644
--- a/target/mips/helper.h
+++ b/target/mips/helper.h
@@ -865,7 +865,6 @@ DEF_HELPER_5(msa_pckod_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_ilvl_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_ilvr_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_ilvev_df, void, env, i32, i32, i32, i32)
-DEF_HELPER_5(msa_ilvod_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_vshf_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_srar_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_srlr_df, void, env, i32, i32, i32, i32)
diff --git a/target/mips/msa_helper.c b/target/mips/msa_helper.c
index 9d9dafe..cbcfd57 100644
--- a/target/mips/msa_helper.c
+++ b/target/mips/msa_helper.c
@@ -1363,57 +1363,6 @@ void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t df, 
uint32_t wd,
 }
 }
 
-void helper_msa_ilvod_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
- uint32_t ws, uint32_t wt)
-{
-wr_t *pwd = &(env->active_fpu.fpr[wd].wr);
-wr_t *pws = &(env->active_fpu.fpr[ws].wr);
-wr_t *pwt = &(env->active_fpu.fpr[wt].wr);
-
-switch (df) {
-case DF_BYTE:
-pwd->b[0]  = pwt->b[1];
-pwd->b[1]  = pws->b[1];
-pwd->b[2]  = pwt->b[3];
-pwd->b[3]  = pws->b[3];
-pwd->b[4]  = pwt->b[5];
-pwd->b[5]  = pws->b[5];
-pwd->b[6]  = pwt->b[7];
-pwd->b[7]  = pws->b[7];
-pwd->b[8]  = pwt->b[9];
-pwd->b[9]  = pws->b[9];
-pwd->b[10] = pwt->b[11];
-pwd->b[11] = pws->b[11];
-pwd->b[12] = pwt->b[13];
-pwd->b[13] = pws->b[13];
-pwd->b[14] = pwt->b[15];
-pwd->b[15] = pws->b[15];
-break;
-case DF_HALF:
-pwd->h[0] = pwt->h[1];
-pwd->h[1] = pws->h[1];
-pwd->h[2] = pwt->h[3];
-pwd->h[3] = pws->h[3];
-pwd->h[4] = pwt->h[5];
-pwd->h[5] = pws->h[5];
-pwd->h[6] = pwt->h[7];
-pwd->h[7] = pws->h[7];
-break;
-case DF_WORD:
-pwd->w[0] = pwt->w[1];
-pwd->w[1] = pws->w[1];
-pwd->w[2] = pwt->w[3];
-pwd->w[3] = pws->w[3];
-break;
-case DF_DOUBLE:
-pwd->d[0] = pwt->d[1];
-pwd->d[1] = pws->d[1];
-break;
-default:
-assert(0);
-}
-}
-
 void helper_msa_ilvl_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
 uint32_t ws, uint32_t wt)
 {
diff --git a/target/mips/translate.c b/target/mips/translate.c
index b4a1103..101d2de 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28889,6 +28889,108 @@ static void gen_msa_bit(CPUMIPSState *env, 
DisasContext *ctx)
 tcg_temp_free_i32(tws);
 }
 
+static inline void gen_ilvod_b(CPUMIPSState *env, uint32_t wd,
+   uint32_t ws, uint32_t wt) {
+TCGv_i64 t0 = tcg_temp_new_i64();
+TCGv_i64 t1 = tcg_temp_new_i64();
+
+uint64_t mask = (1ULL << 8) - 1;
+mask |= mask << 16;
+mask |= mask << 32;
+mask <<= 8;
+tcg_gen_movi_i64(t1, 0);
+
+tcg_gen_andi_i64(t0, msa_wr_d[wt * 2], mask);
+tcg_gen_shri_i64(t0, t0, 8);
+tcg_gen_or_i64(t1, t1, t0);
+tcg_gen_andi_i64(t0, msa_wr_d[ws * 2], mask);
+tcg_gen_or_i64(t1, t1, t0);
+
+tcg_gen_mov_i64(msa_wr_d[wd * 2], t1);
+
+tcg_gen_movi_i64(t1, 0);
+
+tcg_gen_andi_i64(t0, msa_wr_d[wt * 2 + 1], mask);
+tcg_gen_shri_i64(t0, t0, 8);
+tcg_gen_or_i64(t1, t1, t0);
+tcg_gen_andi_i64(t0, msa_wr_d[ws * 2 + 1], mask);
+tcg_gen_or_i64(t1, t1, t0);
+
+tcg_gen_mov_i64(msa_wr_d[wd * 2 + 1], t1);
+
+tcg_temp_free_i64(t0);
+tcg_temp_free_i64(t1);
+}
+
+static inline void gen_ilvod_h(CPUMIPSState *env, uint32_t wd,
+   uint32_t ws, uint32_t wt) {
+TCGv_i64 t0 = tcg_temp_new_i64();
+TCGv_i64 t1 = tcg_temp_new_i64();
+
+uint64_t mask = (1ULL << 16) - 1;
+mask |= mask << 32;
+mask <<= 16;
+tcg_gen_movi_i64(t1, 0);
+
+tcg_gen_andi_i64(t0, msa_wr_d[wt * 2], mask);
+tcg_gen_shri_i64(t0, t0, 16);
+tcg_gen_or_i64(t1, t1, t0);
+tcg_gen_andi_i64(t

[Qemu-devel] [PATCH 2/2] target/mips: Optimize ILVEV. MSA instructions

[Mateja Marjanovic]

From: Mateja Marjanovic 

Optimize set of MSA instructions ILVEV, using directly
tcg registers and performing logic on them insted of
using helpers.
Performance measurement is done by executing the
instructions large number of times on a computer
with Intel Core i7-3770 CPU @ 3.40GHz×8.

 instruction ||before||after   ||
==
 ilvev.b ||74.38 ms  ||  38.85 ms  ||
 ilvev.h ||46.78 ms  ||  33.98 ms  ||
 ilvev.w ||45.50 ms  ||  28.93 ms  ||
 ilvev.d ||37.67 ms  ||  23.09 ms  ||

Signed-off-by: Mateja Marjanovic 
---
 target/mips/helper.h |   1 -
 target/mips/msa_helper.c |  52 -
 target/mips/translate.c  | 117 ++-
 3 files changed, 116 insertions(+), 54 deletions(-)

diff --git a/target/mips/helper.h b/target/mips/helper.h
index d162836..2f23b0d 100644
--- a/target/mips/helper.h
+++ b/target/mips/helper.h
@@ -864,7 +864,6 @@ DEF_HELPER_5(msa_pckev_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_pckod_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_ilvl_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_ilvr_df, void, env, i32, i32, i32, i32)
-DEF_HELPER_5(msa_ilvev_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_vshf_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_srar_df, void, env, i32, i32, i32, i32)
 DEF_HELPER_5(msa_srlr_df, void, env, i32, i32, i32, i32)
diff --git a/target/mips/msa_helper.c b/target/mips/msa_helper.c
index cbcfd57..421dced 100644
--- a/target/mips/msa_helper.c
+++ b/target/mips/msa_helper.c
@@ -1311,58 +1311,6 @@ void helper_msa_pckev_df(CPUMIPSState *env, uint32_t df, 
uint32_t wd,
 }
 }
 
-
-void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
- uint32_t ws, uint32_t wt)
-{
-wr_t *pwd = &(env->active_fpu.fpr[wd].wr);
-wr_t *pws = &(env->active_fpu.fpr[ws].wr);
-wr_t *pwt = &(env->active_fpu.fpr[wt].wr);
-
-switch (df) {
-case DF_BYTE:
-pwd->b[15] = pws->b[14];
-pwd->b[14] = pwt->b[14];
-pwd->b[13] = pws->b[12];
-pwd->b[12] = pwt->b[12];
-pwd->b[11] = pws->b[10];
-pwd->b[10] = pwt->b[10];
-pwd->b[9]  = pws->b[8];
-pwd->b[8]  = pwt->b[8];
-pwd->b[7]  = pws->b[6];
-pwd->b[6]  = pwt->b[6];
-pwd->b[5]  = pws->b[4];
-pwd->b[4]  = pwt->b[4];
-pwd->b[3]  = pws->b[2];
-pwd->b[2]  = pwt->b[2];
-pwd->b[1]  = pws->b[0];
-pwd->b[0]  = pwt->b[0];
-break;
-case DF_HALF:
-pwd->h[7] = pws->h[6];
-pwd->h[6] = pwt->h[6];
-pwd->h[5] = pws->h[4];
-pwd->h[4] = pwt->h[4];
-pwd->h[3] = pws->h[2];
-pwd->h[2] = pwt->h[2];
-pwd->h[1] = pws->h[0];
-pwd->h[0] = pwt->h[0];
-break;
-case DF_WORD:
-pwd->w[3] = pws->w[2];
-pwd->w[2] = pwt->w[2];
-pwd->w[1] = pws->w[0];
-pwd->w[0] = pwt->w[0];
-break;
-case DF_DOUBLE:
-pwd->d[1] = pws->d[0];
-pwd->d[0] = pwt->d[0];
-break;
-default:
-assert(0);
-}
-}
-
 void helper_msa_ilvl_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
 uint32_t ws, uint32_t wt)
 {
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 101d2de..1526d24 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28991,6 +28991,106 @@ static inline void gen_ilvod_d(CPUMIPSState *env, 
uint32_t wd,
 tcg_gen_mov_i64(msa_wr_d[wd * 2 + 1], msa_wr_d[ws * 2 + 1]);
 }
 
+static inline void gen_ilvev_b(CPUMIPSState *env, uint32_t wd,
+   uint32_t ws, uint32_t wt) {
+TCGv_i64 t0 = tcg_temp_new_i64();
+TCGv_i64 t1 = tcg_temp_new_i64();
+
+uint64_t mask = (1ULL << 8) - 1;
+mask |= mask << 16;
+mask |= mask << 32;
+tcg_gen_movi_i64(t1, 0);
+
+tcg_gen_andi_i64(t0, msa_wr_d[wt * 2], mask);
+tcg_gen_or_i64(t1, t1, t0);
+tcg_gen_andi_i64(t0, msa_wr_d[ws * 2], mask);
+tcg_gen_shli_i64(t0, t0, 8);
+tcg_gen_or_i64(t1, t1, t0);
+
+tcg_gen_mov_i64(msa_wr_d[wd * 2], t1);
+
+tcg_gen_movi_i64(t1, 0);
+
+tcg_gen_andi_i64(t0, msa_wr_d[wt * 2 + 1], mask);
+tcg_gen_or_i64(t1, t1, t0);
+tcg_gen_andi_i64(t0, msa_wr_d[ws * 2 + 1], mask);
+tcg_gen_shli_i64(t0, t0, 8);
+tcg_gen_or_i64(t1, t1, t0);
+
+tcg_gen_mov_i64(msa_wr_d[wd * 2 + 1], t1);
+
+tcg_temp_free_i64(t0);
+tcg_temp_free_i64(t1);
+}
+
+static inline void gen_ilvev_h(CPUMIPSState *env, uint32_t wd,
+   uint32_t ws, uint32_t wt) {
+TCGv_i64 t0 = tcg_temp_new_i64();
+TCGv_i64 t1 = tcg_temp_new_i64();
+
+uint64_t mask = (1ULL << 16) - 1;
+mask |= mask << 32;
+
+tcg_gen_movi_i64(t1, 0);
+
+tcg_gen_andi_i64(t0, msa_wr_d[wt * 2], mask);
+tcg_gen_or_i64(t1, t1, t0);
+tcg_gen_andi_i64(t0, msa_wr_d[ws * 2], mask);
+tcg_gen_sh

Re: [Qemu-devel] [PATCH v2 04/11] hw/arm/virt: Add virtual ACPI device

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 15 March 2019 08:42
> To: Shameerali Kolothum Thodi 
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org;
> eric.au...@redhat.com; peter.mayd...@linaro.org;
> shannon.zha...@gmail.com; sa...@linux.intel.com;
> sebastien.bo...@intel.com; Linuxarm ; xuwei (O)
> 
> Subject: Re: [PATCH v2 04/11] hw/arm/virt: Add virtual ACPI device
> 
> On Thu, 14 Mar 2019 16:55:36 +
> Shameerali Kolothum Thodi  wrote:
> 
> > Hi Igor,
> >
> > > -Original Message-
> > > From: Igor Mammedov [mailto:imamm...@redhat.com]
> > > Sent: 12 March 2019 15:48
> > > To: Shameerali Kolothum Thodi 
> > > Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org;
> > > eric.au...@redhat.com; peter.mayd...@linaro.org;
> > > shannon.zha...@gmail.com; sa...@linux.intel.com;
> > > sebastien.bo...@intel.com; Linuxarm ; xuwei (O)
> > > 
> > > Subject: Re: [PATCH v2 04/11] hw/arm/virt: Add virtual ACPI device
> > >
> > > On Fri, 8 Mar 2019 11:42:11 +
> > > Shameer Kolothum  wrote:
> > >
> > > > From: Samuel Ortiz 
> > > >
> > > > This is to provide an acpi device interface for Arm/virt.
> > > > This will be used by Arm/Virt to add hotplug support via
> > > > ACPI GED device.
> > > >
> > > > Signed-off-by: Samuel Ortiz 
> > > > Signed-off-by: Shameer Kolothum
> 
> > > > ---
> > > >  hw/arm/Makefile.objs  |   2 +-
> > > >  hw/arm/virt-acpi.c| 111
> > > ++
> > >
> > > does it have to be ARM specific?
> > > could it be shared with future x86/virt? (if it could then it would be 
> > > better to
> put
> > > into hw/acpi/)
> > > also considering it implements vitual 'GED' device
> > > why not s/virt-acpi/generic-event-device/ ?
> >
> > I think that's a good idea to make it generic and I had a quick go at it.
> >
> > But the problem I am facing is as soon as sysbus_create_simple() is called
> from
> > virt_acpi_init(), the realize() function gets called before it sets the
> VirtAcpiState
> > members.
> 
> Lets look at it from the other side, what are the reasons to use inherit 
> device
> from TYPE_SYS_BUS_DEVICE and use sysbus_create_simple()?

Right. I think I can solve this by using qdev_create() and qdev_init_nofail().

Thanks,
Shameer
 
> 
> > This creates a problem as acpi_memory_hotplug_init() and acpi_ged_init()
> are
> > invoked from the realize() and it needs to have the base address, irq etc 
> > set
> based
> > on the platform.
> >
> > I tried using the qdev_prop_set_*() as well, but it also fails saying 
> > attempt to
> set
> > property after it was realized.
> >
> > Not sure what is the best way to solve this other than introducing a global
> struct to
> > hold the configuration.
> Globals are frowned upon, we shouldn't do add more.
> 
> >
> > Please let me know.
> >
> > Thanks,
> > Shameer
> >
> > >
> > > >  include/hw/arm/virt.h |   1 +
> > > >  3 files changed, 113 insertions(+), 1 deletion(-)
> > > >  create mode 100644 hw/arm/virt-acpi.c
> > > >
> > > > diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> > > > index fa57c7c..e0db3cd 100644
> > > > --- a/hw/arm/Makefile.objs
> > > > +++ b/hw/arm/Makefile.objs
> > > > @@ -1,6 +1,6 @@
> > > >  obj-y += boot.o sysbus-fdt.o
> > > >  obj-$(CONFIG_ARM_VIRT) += virt.o
> > > > -obj-$(CONFIG_ACPI) += virt-acpi-build.o
> > > > +obj-$(CONFIG_ACPI) += virt-acpi-build.o virt-acpi.o
> > > >  obj-$(CONFIG_DIGIC) += digic_boards.o
> > > >  obj-$(CONFIG_EXYNOS4) += exynos4_boards.o
> > > >  obj-$(CONFIG_HIGHBANK) += highbank.o
> > > > diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c
> > > > new file mode 100644
> > > > index 000..df8a02b
> > > > --- /dev/null
> > > > +++ b/hw/arm/virt-acpi.c
> > > > @@ -0,0 +1,111 @@
> > > > +/*
> > > > + *
> > > > + * Copyright (c) 2018 Intel Corporation
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or 
> > > > modify it
> > > > + * under the terms and conditions of the GNU General Public License,
> > > > + * version 2 or later, as published by the Free Software Foundation.
> > > > + *
> > > > + * This program is distributed in the hope it will be useful, but 
> > > > WITHOUT
> > > > + * ANY WARRANTY; without even the implied warranty of
> > > MERCHANTABILITY or
> > > > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> > > License for
> > > > + * more details.
> > > > + *
> > > > + * You should have received a copy of the GNU General Public License
> along
> > > with
> > > > + * this program.  If not, see .
> > > > + */
> > > > +
> > > > +#include "qemu/osdep.h"
> > > > +#include "qemu/range.h"
> > > > +#include "qapi/error.h"
> > > > +#include "exec/address-spaces.h"
> > > > +
> > > > +#include "hw/hw.h"
> > > > +#include "hw/hotplug.h"
> > > > +#include "hw/sysbus.h"
> > > > +#include "hw/arm/virt.h"
> > > > +
> > > > +#include "hw/acpi/acpi.h"
> > > > +
> > > > +typedef struct VirtAcpiState {
> > > > +SysBusDevice parent_o

Re: [Qemu-devel] [PULL 0/5] target-arm queue

[Peter Maydell]

On Fri, 15 Mar 2019 at 11:39, Peter Maydell  wrote:
>
>
> A last arm pullreq before rc0. This is mostly bug fixes,
> though you could call adding the missing local timer
> support to bcm2836_control a new feature I suppose --
> in any case it's a small and localised change.
>
> thanks
> -- PMM
>
> The following changes since commit 7074ab12c81a1b2b1e0e1c40983f56b2c5ccc494:
>
>   Merge remote-tracking branch 
> 'remotes/vivier2/tags/trivial-branch-pull-request' into staging (2019-03-14 
> 16:19:37 +)
>
> are available in the Git repository at:
>
>   https://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20190315
>
> for you to fetch changes up to 5de56742a3c91de3d646326bec43a989bba83ca4:
>
>   target/arm: Check access permission to ADDVL/ADDPL/RDVL (2019-03-15 
> 11:12:29 +)
>
> 
> target-arm queue:
>  * Add missing SVE-enabled check to ADDVL/ADDPL/RDVL
>  * virt-acpi-build: use PCIE_MMCFG_BUS to retrieve end_bus_number
>  * virt-acpi-build: Fix SMMUv3 GSIV values
>  * Allow EL0 to write to arch timer registers, not just read them
>  * bcm2836_control: Implement local timer
>

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

Re: [Qemu-devel] [PATCH v13 19/25] replay: add BH oneshot event for block layer

[Kevin Wolf]

Am 15.03.2019 um 08:26 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Am 21.02.2019 um 12:05 hat Pavel Dovgalyuk geschrieben:
> > > Replay is capable of recording normal BH events, but sometimes
> > > there are single use callbacks scheduled with aio_bh_schedule_oneshot
> > > function. This patch enables recording and replaying such callbacks.
> > > Block layer uses these events for calling the completion function.
> > > Replaying these calls makes the execution deterministic.
> > >
> > > Signed-off-by: Pavel Dovgalyuk 
> > 
> > Acked-by: Kevin Wolf 
> 
> Thanks, Kevin!
> 
> Can you also take a look at patches 2, 3, 5?
> They affect only RR behavior, but change the block layer too.

No objection there either (I see most of them more as RR things than
block layer things anyway).

Kevin

[Qemu-devel] [PATCH 0/2] target/mips: Optimize ILVEV and ILVOD MSA instructions

[Mateja Marjanovic]

From: Mateja Marjanovic 

Optimize set of MSA instructions ILVEV and ILVOD,
using directly tcg registers and performing logic
on them insted of using helpers.


Mateja Marjanovic (2):
  target/mips: Optimize ILVOD. MSA instructions
  target/mips: Optimize ILVEV. MSA instructions

 target/mips/helper.h |   2 -
 target/mips/msa_helper.c | 103 -
 target/mips/translate.c  | 236 ++-
 3 files changed, 234 insertions(+), 107 deletions(-)

-- 
2.7.4

Re: [Qemu-devel] AMD SEV's /dev/sev permissions and probing QEMU for capabilities

[Daniel P . Berrangé]

On Fri, Jan 18, 2019 at 12:51:50PM +, Singh, Brijesh wrote:
> 
> On 1/18/19 3:39 AM, Erik Skultety wrote:
> > I proceeded with cloning [1] to systemd and creating an udev rule that I 
> > planned
> > on submitting to systemd upstream - the initial idea was to mimic /dev/kvm 
> > and
> > make it world accessible to which Brijesh from AMD expressed a concern that
> > regular users might deplete the resources (limit on the number of guests
> > allowed by the platform).

[snip]

> > But since the limit is claimed to be around 4, Dan
> 
> 
> FYI, the limit on EPYC is 15.

Do any cRyzen CPUs support SEV, and if so is their limit also 15 ?

Regardless, I'm assuming this limit is liable to change at any time
in future CPU generations, so from the the mgmt app perspective I
think is is important that QEMU / libvirt can both report what this
limit is.

For QEMU I think query-sev-capabilities probably should report the
guest limit.  I guess QEMU would in turn want to ask the kernel,
rather than hardcode info itself. So if this info isn't already
exposed by the kernel we might need work there too.

For libvirt we can then put this in the domain capabilities where
we report SEV support.

This will enable OpenStack and similar apps to plan which host they
place a new VM on, to ensure there is SEV resource available for it
to use.

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 v14 22/25] util/qemu-timer: refactor deadline calculation for external timers

[Pavel Dovgalyuk]

icount-based record/replay uses qemu_clock_deadline_ns_all to measure
the period until vCPU may be interrupted.
This function takes in account the virtual timers, because they belong
to the virtual devices that may generate interrupt request or affect
the virtual machine state.
However, there are a subset of virtual timers, that are marked with
'external' flag. These do not change the virtual machine state and
only based on virtual clock. Calculating the deadling using the external
timers breaks the determinism, because they do not belong to the replayed
part of the virtual machine.
This patch fixes the deadline calculation for this case.

Signed-off-by: Pavel Dovgalyuk 
---
 cpus.c|9 -
 include/qemu/timer.h  |7 +++
 qtest.c   |2 +-
 tests/ptimer-test-stubs.c |2 +-
 tests/ptimer-test.c   |4 ++--
 util/qemu-timer.c |   41 +
 6 files changed, 44 insertions(+), 21 deletions(-)

diff --git a/cpus.c b/cpus.c
index ba4849861d..2cad26f96c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -550,7 +550,7 @@ void qtest_clock_warp(int64_t dest)
 assert(qtest_enabled());
 aio_context = qemu_get_aio_context();
 while (clock < dest) {
-int64_t deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+int64_t deadline = virtual_clock_deadline_ns();
 int64_t warp = qemu_soonest_timeout(dest - clock, deadline);
 
 seqlock_write_lock(&timers_state.vm_clock_seqlock,
@@ -610,7 +610,7 @@ void qemu_start_warp_timer(void)
 
 /* We want to use the earliest deadline from ALL vm_clocks */
 clock = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT);
-deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+deadline = virtual_clock_deadline_ns();
 if (deadline < 0) {
 static bool notified;
 if (!icount_sleep && !notified) {
@@ -1356,7 +1356,7 @@ static int64_t tcg_get_icount_limit(void)
 int64_t deadline;
 
 if (replay_mode != REPLAY_MODE_PLAY) {
-deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+deadline = virtual_clock_deadline_ns();
 
 /* Maintain prior (possibly buggy) behaviour where if no deadline
  * was set (as there is no QEMU_CLOCK_VIRTUAL timer) or it is more than
@@ -1377,8 +1377,7 @@ static void handle_icount_deadline(void)
 {
 assert(qemu_in_vcpu_thread());
 if (use_icount) {
-int64_t deadline =
-qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+int64_t deadline = virtual_clock_deadline_ns();
 
 if (deadline == 0) {
 /* Wake up other AioContexts.  */
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index a86330c987..cfc77450f2 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -176,16 +176,15 @@ bool qemu_clock_expired(QEMUClockType type);
 bool qemu_clock_use_for_deadline(QEMUClockType type);
 
 /**
- * qemu_clock_deadline_ns_all:
- * @type: the clock type
+ * virtual_clock_deadline_ns:
  *
  * Calculate the deadline across all timer lists associated
- * with a clock (as opposed to just the default one)
+ * with virtual clock (excluding external timers)
  * in nanoseconds, or -1 if no timer is set to expire.
  *
  * Returns: time until expiry in nanoseconds or -1
  */
-int64_t qemu_clock_deadline_ns_all(QEMUClockType type);
+int64_t virtual_clock_deadline_ns(void);
 
 /**
  * qemu_clock_get_main_loop_timerlist:
diff --git a/qtest.c b/qtest.c
index 527141785f..8000ee0714 100644
--- a/qtest.c
+++ b/qtest.c
@@ -655,7 +655,7 @@ static void qtest_process_command(CharBackend *chr, gchar 
**words)
 int ret = qemu_strtoi64(words[1], NULL, 0, &ns);
 g_assert(ret == 0);
 } else {
-ns = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+ns = virtual_clock_deadline_ns();
 }
 qtest_clock_warp(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + ns);
 qtest_send_prefix(chr);
diff --git a/tests/ptimer-test-stubs.c b/tests/ptimer-test-stubs.c
index 54b3fd26f6..31b09c88f3 100644
--- a/tests/ptimer-test-stubs.c
+++ b/tests/ptimer-test-stubs.c
@@ -88,7 +88,7 @@ int64_t qemu_clock_get_ns(QEMUClockType type)
 return ptimer_test_time_ns;
 }
 
-int64_t qemu_clock_deadline_ns_all(QEMUClockType type)
+int64_t virtual_clock_deadline_ns(void)
 {
 QEMUTimerList *timer_list = main_loop_tlg.tl[type];
 QEMUTimer *t = timer_list->active_timers.next;
diff --git a/tests/ptimer-test.c b/tests/ptimer-test.c
index b30aad0737..338a4e0c10 100644
--- a/tests/ptimer-test.c
+++ b/tests/ptimer-test.c
@@ -50,13 +50,13 @@ static void ptimer_test_set_qemu_time_ns(int64_t ns)
 
 static void qemu_clock_step(uint64_t ns)
 {
-int64_t deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
+int64_t deadline = virtual_clock_deadline_ns();
 int64_t advanced_time = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + ns;
 
 while (deadline != -1 && deadline <= advanced_time) {
 

Re: [Qemu-devel] [PATCH v14 00/25] Fixing record/replay and adding reverse debugging

[Pavel Dovgalyuk]

Paolo, since we are in soft freeze phase,
what about merging just patches 1-6, 14, 15, 19, 21-23, 25?
They fix icount/rr bugs and make small improvements of these features.

I also just noticed that patch 20 is obsolete. I'll drop it in the next 
iteration.

Pavel Dovgalyuk


> -Original Message-
> From: Pavel Dovgalyuk [mailto:pavel.dovga...@ispras.ru]
> Sent: Friday, March 15, 2019 3:08 PM
> To: qemu-devel@nongnu.org
> Cc: kw...@redhat.com; peter.mayd...@linaro.org; war2jor...@live.com;
> crosthwaite.pe...@gmail.com; boost.li...@gmail.com; 
> artem.k.pisare...@gmail.com;
> quint...@redhat.com; ciro.santi...@gmail.com; jasow...@redhat.com; 
> m...@redhat.com;
> arm...@redhat.com; mre...@redhat.com; maria.klimushenk...@ispras.ru; 
> dovga...@ispras.ru;
> kra...@redhat.com; pavel.dovga...@ispras.ru; thomas.dull...@googlemail.com;
> pbonz...@redhat.com; alex.ben...@linaro.org; dgilb...@redhat.com; 
> r...@twiddle.net
> Subject: [PATCH v14 00/25] Fixing record/replay and adding reverse debugging
> 
> GDB remote protocol supports reverse debugging of the targets.
> It includes 'reverse step' and 'reverse continue' operations.
> The first one finds the previous step of the execution,
> and the second one is intended to stop at the last breakpoint that
> would happen when the program is executed normally.
> 
> Reverse debugging is possible in the replay mode, when at least
> one snapshot was created at the record or replay phase.
> QEMU can use these snapshots for travelling back in time with GDB.
> 
> Running the execution in replay mode allows using GDB reverse debugging
> commands:
>  - reverse-stepi (or rsi): Steps one instruction to the past.
>QEMU loads on of the prior snapshots and proceeds to the desired
>instruction forward. When that step is reaches, execution stops.
>  - reverse-continue (or rc): Runs execution "backwards".
>QEMU tries to find breakpoint or watchpoint by loaded prior snapshot
>and replaying the execution. Then QEMU loads snapshots again and
>replays to the latest breakpoint. When there are no breakpoints in
>the examined section of the execution, QEMU finds one more snapshot
>and tries again. After the first snapshot is processed, execution
>stops at this snapshot.
> 
> The set of patches include the following modifications:
>  - gdbstub update for reverse debugging support
>  - functions that automatically perform reverse step and reverse
>continue operations
>  - hmp/qmp commands for manipulating the replay process
>  - improvement of the snapshotting for saving the execution step
>in the snapshot parameters
>  - other record/replay fixes
> 
> The patches are available in the repository:
> https://github.com/ispras/qemu/tree/rr-190315
> 
> v14 changes:
>  - rebased to the new master
> 
> v13 changes:
>  - rebased to make QAPI stuff applicable
>  - minor reverse step/reverse continue fix
> 
> v12 changes:
>  - style fixes
> 
> v11 changes:
>  - added can_do_io resetting before jumping to the next block in the chain
>  - rebase to the latest master
> 
> v10 changes:
>  - added patch for correct deadline calculation with external timers
>  - updated icount-related documentation in json files
>(suggested by Markus Armbruster)
>  - fixed replay shutdown
>  - renamed some functions and variables to make them consistent with
>the documentation and displayed messages
>  - minor changes
> 
> v9 changes:
>  - moved rr qapi stuff to the separate file (suggested by Markus Armbruster)
>  - minor coding style fixes
> 
> v8 changes:
>  - rebased to the new master
>  - added missing fix for prior rr patch
>  - updated 'since' version number in json-related patches
> 
> v7 changes:
>  - rebased to the new master with upstreamed patches from the series
>  - several improvements in hmp/qmp commands handling (suggested by Markus 
> Armbruster)
>  - fixed record/replay with '-rtc base' option enabled
>  - added document with virtual hardware requirements
> 
> v6 changes:
>  - rebased to the new version of master
>  - fixed build of linux-user configurations
>  - added new clock for slirp and vnc timers
> 
> v5 changes:
>  - multiple fixes of record/replay bugs appeared after QEMU core update
>  - changed reverse debugging to 'since 3.1'
> 
> v4 changes:
>  - changed 'since 2.13' to 'since 3.0' in json (as suggested by Eric Blake)
> 
> v3 changes:
>  - Fixed PS/2 bug with save/load vm, which caused failures of the replay.
>  - Rebased to the new code base.
>  - Minor fixes.
> 
> v2 changes:
>  - documented reverse debugging
>  - fixed start vmstate loading in record mode
>  - documented qcow2 changes (as suggested by Eric Blake)
>  - made icount SnapshotInfo field optional (as suggested by Eric Blake)
>  - renamed qmp commands (as suggested by Eric Blake)
>  - minor changes
> 
> ---
> 
> Pavel Dovgalyuk (24):
>   block: implement bdrv_snapshot_goto for blkreplay
>   replay: disable default snapshot for record/replay
>   replay: update do

Re: [Qemu-devel] [PATCH] curses ui: always initialize all curses_line fields

[Eric Blake]

On 3/15/19 5:06 AM, Peter Maydell wrote:
> On Fri, 15 Mar 2019 at 08:37, Samuel Thibault
>  wrote:
>>
>> cchar_t can contain not only attr and chars fields, but also ext_color.
>> Initialize the whole structure to zero instead of enumerating fields.
>>
>> Spotted by Coverity: CID 1399711
>>
>> Signed-off-by: Samuel Thibault 
>> ---
>>  ui/curses.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/ui/curses.c b/ui/curses.c
>> index d29098db9f..e99fbe3e24 100644
>> --- a/ui/curses.c
>> +++ b/ui/curses.c
>> @@ -75,9 +75,8 @@ static void curses_update(DisplayChangeListener *dcl,
>>  if (vga_to_curses[ch].chars[0]) {
>>  curses_line[x] = vga_to_curses[ch];
>>  } else {
>> +curses_line[x] = (cchar_t) {};
>>  curses_line[x].chars[0] = ch;
>> -curses_line[x].chars[1] = 0;
>> -curses_line[x].attr = 0;
>>  }
>>  curses_line[x].attr |= at;
> 
> Does this really need the cast ? {} is supposed to be a
> universal initializer.

Or is it worth using:

curses_line[x] = (cchar_t) {
  .chars[0] = ch,
};

so that all other fields not mentioned are zero-initialized, without
relying on the {} extension?

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 09/12] pc-bios: document the edk2 firmware images; add firmware descriptors

[Daniel P . Berrangé]

On Wed, Mar 13, 2019 at 10:00:54PM +0100, Laszlo Ersek wrote:
> Update the README file with information on the images added previously,
> and provide firmware descriptor documents that conform to
> "docs/interop/firmware.json".
> 
> Signed-off-by: Laszlo Ersek 
> Reviewed-by: Michal Privoznik 
> Reviewed-by: Michael S. Tsirkin 
> ---
> 
> Notes:
> v2:
> 
> - refer to "edk2-*.fd.xz" rather than "edk2-*.fd" in the README hunk
>   [Dan, Michael, Phil]
> 
> - pick up Michal's and Michael's R-b's
> 
>  pc-bios/descriptors/50-edk2-i386-secure.json   | 34 +++
>  pc-bios/descriptors/50-edk2-x86_64-secure.json | 35 
>  pc-bios/descriptors/60-edk2-aarch64.json   | 31 +
>  pc-bios/descriptors/60-edk2-arm.json   | 31 +
>  pc-bios/descriptors/60-edk2-i386.json  | 33 ++
>  pc-bios/descriptors/60-edk2-x86_64.json| 34 +++
>  pc-bios/README | 11 ++

One day we should rename this directory to just "roms" or something
like that. We use of for lots of stuff unrelated to the x86 pc
machine :-)

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

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

[Pavel Hrdina]

On Tue, Mar 12, 2019 at 08:12:40AM +0100, Gerd Hoffmann wrote:
> From: Kővágó, Zoltán 
> 
> Audio drivers now get an Audiodev * as config paramters, instead of the
> global audio_option structs.  There is some code in audio/audio_legacy.c
> that converts the old environment variables to audiodev options (this
> way backends do not have to worry about legacy options).  It also
> contains a replacement of -audio-help, which prints out the equivalent
> -audiodev based config of the currently specified environment variables.
> 
> Note that backends are not updated and still rely on environment
> variables.
> 
> Also note that (due to moving try-poll from global to backend specific
> option) currently ALSA and OSS will always try poll mode, regardless of
> environment variables or -audiodev options.

Hi,

I'm glad that this is merged now and I wanted to start working on
libvirt patches, but there is one big issue with this command,
it's not introspectable by query-command-line-options.

My guess based on the QEMU code is that it uses the new function that
allows you to use JSON on qemu command line.

Without the introspection libvirt cannot implement the new option in
sensible way (without version check).

Adding Markus to CC so we can figure out how to wire up the
introspection for such command line options.

Pavel


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v14 23/25] replay: fix replay shutdown

[Pavel Dovgalyuk]

This patch fixes shutdown of the replay process, which is terminated with
the assert when shutdown event is read from the log.
replay_finish_event reads new data_kind and therefore the value of data_kind
should be preserved to be valid at qemu_system_shutdown_request call.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/replay/replay.c b/replay/replay.c
index e578958659..8f2e17c8cb 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -49,14 +49,14 @@ bool replay_next_event_is(int event)
 }
 
 while (true) {
-if (event == replay_state.data_kind) {
+unsigned int data_kind = replay_state.data_kind;
+if (event == data_kind) {
 res = true;
 }
-switch (replay_state.data_kind) {
+switch (data_kind) {
 case EVENT_SHUTDOWN ... EVENT_SHUTDOWN_LAST:
 replay_finish_event();
-qemu_system_shutdown_request(replay_state.data_kind -
- EVENT_SHUTDOWN);
+qemu_system_shutdown_request(data_kind - EVENT_SHUTDOWN);
 break;
 default:
 /* clock, time_t, checkpoint and other events */

[Qemu-devel] [PATCH v5 4/5] RISC-V: Add debug support for accessing CSRs.

[Chih-Min Chao]

From: Jim Wilson 

Add a debugger field to CPURISCVState.  Add riscv_csrrw_debug function
to set it.  Disable mode checks when debugger field true.

Signed-off-by: Jim Wilson 
Reviewed-by: Alistair Francis 
Message-Id: <20190212230903.9215-1-j...@sifive.com>
---
 target/riscv/cpu.h |  5 +
 target/riscv/csr.c | 32 +---
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 5c2aebf..4c5de30 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -172,6 +172,9 @@ struct CPURISCVState {
 
 /* physical memory protection */
 pmp_table_t pmp_state;
+
+/* True if in debugger mode.  */
+bool debugger;
 #endif
 
 float_status fp_status;
@@ -293,6 +296,8 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState *env, 
target_ulong *pc,
 
 int riscv_csrrw(CPURISCVState *env, int csrno, target_ulong *ret_value,
 target_ulong new_value, target_ulong write_mask);
+int riscv_csrrw_debug(CPURISCVState *env, int csrno, target_ulong *ret_value,
+  target_ulong new_value, target_ulong write_mask);
 
 static inline void riscv_csr_write(CPURISCVState *env, int csrno,
target_ulong val)
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 960d2b0..9a40b4c 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -46,7 +46,7 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations *ops)
 static int fs(CPURISCVState *env, int csrno)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 #endif
@@ -92,7 +92,7 @@ static int pmp(CPURISCVState *env, int csrno)
 static int read_fflags(CPURISCVState *env, int csrno, target_ulong *val)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 #endif
@@ -103,7 +103,7 @@ static int read_fflags(CPURISCVState *env, int csrno, 
target_ulong *val)
 static int write_fflags(CPURISCVState *env, int csrno, target_ulong val)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 env->mstatus |= MSTATUS_FS;
@@ -115,7 +115,7 @@ static int write_fflags(CPURISCVState *env, int csrno, 
target_ulong val)
 static int read_frm(CPURISCVState *env, int csrno, target_ulong *val)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 #endif
@@ -126,7 +126,7 @@ static int read_frm(CPURISCVState *env, int csrno, 
target_ulong *val)
 static int write_frm(CPURISCVState *env, int csrno, target_ulong val)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 env->mstatus |= MSTATUS_FS;
@@ -138,7 +138,7 @@ static int write_frm(CPURISCVState *env, int csrno, 
target_ulong val)
 static int read_fcsr(CPURISCVState *env, int csrno, target_ulong *val)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 #endif
@@ -150,7 +150,7 @@ static int read_fcsr(CPURISCVState *env, int csrno, 
target_ulong *val)
 static int write_fcsr(CPURISCVState *env, int csrno, target_ulong val)
 {
 #if !defined(CONFIG_USER_ONLY)
-if (!(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
 return -1;
 }
 env->mstatus |= MSTATUS_FS;
@@ -827,6 +827,24 @@ int riscv_csrrw(CPURISCVState *env, int csrno, 
target_ulong *ret_value,
 return 0;
 }
 
+/*
+ * Debugger support.  If not in user mode, set env->debugger before the
+ * riscv_csrrw call and clear it after the call.
+ */
+int riscv_csrrw_debug(CPURISCVState *env, int csrno, target_ulong *ret_value,
+target_ulong new_value, target_ulong write_mask)
+{
+int ret;
+#if !defined(CONFIG_USER_ONLY)
+env->debugger = true;
+#endif
+ret = riscv_csrrw(env, csrno, ret_value, new_value, write_mask);
+#if !defined(CONFIG_USER_ONLY)
+env->debugger = false;
+#endif
+return ret;
+}
+
 /* Control and Status Register function table */
 static riscv_csr_operations csr_ops[CSR_TABLE_SIZE] = {
 /* User Floating-Point CSRs */
-- 
2.7.4

[Qemu-devel] [PATCH v14 25/25] icount: clean up cpu_can_io before jumping to the next block

[Pavel Dovgalyuk]

Most of IO instructions can be executed only at the end of the block in
icount mode. Therefore translator can set cpu_can_io flag when translating
the last instruction.
But when the blocks are chained, then this flag is not reset and may
remain set at the beginning of the next block.
This patch resets the flag before "chaining" the translation blocks.

Signed-off-by: Pavel Dovgalyuk 
---
 accel/tcg/tcg-runtime.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/accel/tcg/tcg-runtime.c b/accel/tcg/tcg-runtime.c
index d0d4484406..5871f5aba2 100644
--- a/accel/tcg/tcg-runtime.c
+++ b/accel/tcg/tcg-runtime.c
@@ -151,6 +151,8 @@ void *HELPER(lookup_tb_ptr)(CPUArchState *env)
 target_ulong cs_base, pc;
 uint32_t flags;
 
+/* We are going to jump to the next block. can_do_io should be reset */
+cpu->can_do_io = !use_icount;
 tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, curr_cflags());
 if (tb == NULL) {
 return tcg_ctx->code_gen_epilogue;

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Peter Maydell]

On Fri, 15 Mar 2019 at 09:05, Alex Bennée  wrote:
>
>
> Peter Maydell  writes:
> > [+] I currently test:
> >  - windows crossbuilds
>
> We did have this with shippable but had to disable it when the upstream
> repo went down. We could re-enable if we can rebuild it and cache our
> docker images with Daniel's work.
>
> >  - S390, AArch32, AArch64, PPC64 Linux
> >(SPARC currently disabled because of the migration-test flakiness)
>
> We would need to get machines from somewhere. Setting up a headless
> SynQuacer should be easy enough and we have qemu-test which is a
> ThunderX beast. I guess the IBM guys would have to chime in if they
> could find PPC/s390 boxen because I'm guessing spamming the GCC build
> farm with our test runners would be a little unfair.

For S390x we have a just-for-QEMU machine already, courtesy of IBM.
We're already doing builds on the GCC build farm machines, so
as long as we don't increase the number of things we're building
that way (ie we don't allow them to be used by random other
submaintainers doing test runs) I don't think it should increase
the load on them. We should definitely check with the cfarm admins
on how allowable buildbot-equivalents are, though. And as you say
with our Linaro hats on we can provide the Arm hosts, so it's just
PPC and SPARC. I should also mention MIPS here which is not in
my set of host builds because I've never found a MIPS box fast
enough.

> >  - FreeBSD, OpenBSD, NetBSD via the tests/vm setup
>
> We build on FreeBSD on Cirrus - but any x86 box can run the test/vm
> setup assuming your just kicking it off with a make vm-test type thing?

Yep.

> >  - various x86-64 configs: from-clean; debug; clang; TCI; no-tcg;
> >linux-static (including 'make check-tcg')
>
> This is already covered in our rather large Travis matrix. The trick
> will be making it all fast enough.

Yes; Travis build time is at least twice the elapsed-time we are
looking for here.

The other nice part about my current setup is that if something
fails on a random odd host architecture I can just ssh in and
run the test by hand to debug it. I'm guessing that any of this
sort of CI setup is going to prohibit that.

thanks
-- PMM

Re: [Qemu-devel] Data bus error with redeonfb on mips_fulong2e

[BALATON Zoltan]

On Fri, 15 Mar 2019, Philippe Mathieu-Daudé wrote:

On 3/14/19 11:08 PM, BALATON Zoltan wrote:

On Thu, 14 Mar 2019, Aleksandar Markovic wrote:

From: BALATON Zoltan 
Subject: Data bus error with redeonfb on mips_fulong2e

Hello,

Trying to debug the Linux kernel oops with radeonfb I've added some more
debug logs and got this:

radeonfb_pci_register BEGIN
pci_host_data: pci_data_read: ati-vga: addr=04 val= len=4
PCI: Enabling device :00:06.0 ( -> 0003)
pci_host_data: pci_data_read: ati-vga: addr=04 val= len=4
pci_host_data: pci_data_write: ati-vga: addr=04 val=0003 len=4
pci_update_mappings: adding bar 0 to pci.mem @ 0x1400
pci_update_mappings: adding bar 1 to io @ 0x4000
pci_update_mappings: adding bar 2 to pci.mem @ 0x1505
pci_host_data: pci_data_read: ati-vga: addr=3c val= len=4
radeonfb_pci_register fb_base_phys=1400
radeonfb_pci_register mmio_base_phys=1505
radeonfb_pci_register request mem regions
radeonfb_pci_register map regions


But wait, Shouldn't this map regions meant to map the PCI BARs at the 
correct address? Why is that not happening?


Regards,
BALATON Zoltan


radeonfb_pci_register mmio_base=90001505
Data bus error, epc == 80418e4c, ra == 80418e4c
(full oops dump in previous message but I couldn't find anything
useful in
there so omitted here)


(qemu) info mtree
memory-region: system
 - (prio 0, i/o): system
   -0fff (prio 0, ram): fulong2e.ram
   1000-1bff (prio 0, i/o): pci.mem
 100a-100b (prio 1, i/o): vga-lowmem
 2400-24ff (prio 1, ram): vga.vram
 2505-25053fff (prio 1, i/o): ati.mmregs
   1fc0-1fc7 (prio 0, rom): fulong2e.bios

The CPU bus is right, there is nothing mapped at 0x0.1505. (IO is
36bit wide on mips64).

I look at the kernel and it doesn't configure the PCI but expect the
display to be there already, so I checked the BIOS you cited in another
thread and ran the same command con the "PMON>" prompt was reached:

(qemu) info mtree
memory-region: system
 - (prio 0, i/o): system
   -0fff (prio 0, ram): fulong2e.ram
   1000-1bff (prio 0, i/o): pci.mem
 100a-100a (prio 2, i/o): alias vga.chain4
@vga.vram -
 100a-100b (prio 1, i/o): vga-lowmem
 1400-14ff (prio 1, ram): vga.vram
 1500-1503 (prio 1, rom): rtl8139.rom
 1504-1504 (prio 1, rom): ati-vga.rom
 1505-15053fff (prio 1, i/o): ati.mmregs

 ^ remapped

 15054000-150540ff (prio 1, i/o): alias rtl8139-mem
@rtl8139 -00ff
   1fc0-1fc7 (prio 0, rom): fulong2e.bios
   1fd0-1fd0 (prio 0, i/o): alias isa_mmio @io
-
   1fe0-1fe000ff (prio 0, i/o): north-bridge-pci-config
   1fe00100-1fe0016f (prio 0, i/o): north-bridge-register
   1fe8-1fef (prio 0, i/o): south-bridge-pci-config
   1ff0-1fff (prio 0, i/o): alias isa_mmio @io
-000f
   bfe00200-bfe002ff (prio 0, i/o): ldma
   bfe00300-bfe003ff (prio 0, i/o): cop

I then traced it to check PMON do the PCI initialization Linux expects:

$ qemu-system-mips64el -M fulong2e -bios pmon_2e.bin \
 -serial stdio -d trace:pci\*
...
PPCIH
...
PCI bus 0 slot 5/6: reg 0x24 = 0x0
18936@1552613792.124336:pci_cfg_read VT82C686B_MC97 05:6 @0x30 -> 0x0
18936@1552613792.124342:pci_cfg_read VT82C686B_MC97 05:6 @0x30 -> 0x0
18936@1552613792.124344:pci_cfg_write VT82C686B_MC97 05:6 @0x30 <-
0xfffe
18936@1552613792.124349:pci_cfg_read VT82C686B_MC97 05:6 @0x30 -> 0x0
18936@1552613792.124354:pci_cfg_read VT82C686B_MC97 05:6 @0x30 -> 0x0
18936@1552613792.124357:pci_cfg_write VT82C686B_MC97 05:6 @0x30 <- 0x0
18936@1552613792.124408:pci_cfg_read ati-vga 06:0 @0x0 -> 0x51591002
18936@1552613792.124414:pci_cfg_read ati-vga 06:0 @0xc -> 0x0
18936@1552613792.124441:pci_cfg_read ati-vga 06:0 @0x8 -> 0x300
18936@1552613792.124446:pci_cfg_read ati-vga 06:0 @0x0 -> 0x51591002
18936@1552613792.124574:pci_cfg_read ati-vga 06:0 @0x4 -> 0x0
18936@1552613792.124580:pci_cfg_read ati-vga 06:0 @0x4 -> 0x0
18936@1552613792.124582:pci_cfg_write ati-vga 06:0 @0x4 <- 0x0
18936@1552613792.124588:pci_cfg_read ati-vga 06:0 @0x3c -> 0x0
18936@1552613792.124593:pci_cfg_read ati-vga 06:0 @0x3c -> 0x0
18936@1552613792.124597:pci_cfg_read ati-vga 06:0 @0x3c -> 0x0
18936@1552613792.124602:pci_cfg_read ati-vga 06:0 @0x3c -> 0x0
18936@1552613792.124604:pci_cfg_write ati-vga 06:0 @0x3c <- 0x0
18936@1552613792.124609:p

Re: [Qemu-devel] [PATCH] ci: store Patchew configuration in the tree

[Alex Bennée]

Paolo Bonzini  writes:

> Patchew cannot yet retrieve the configuration from the QEMU Git tree, but
> this is planned.  In the meanwhile, let's start storing it as YAML
> so that the Patchew configuration (currently accessible only to 
> administrators)
> is public and documented.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  .patchew.yml | 204 +++
>  1 file changed, 204 insertions(+)
>  create mode 100644 .patchew.yml
>
> diff --git a/.patchew.yml b/.patchew.yml
> new file mode 100644
> index 00..54feda823e
> --- /dev/null
> +++ b/.patchew.yml
> @@ -0,0 +1,204 @@
> +# Note: this file is still unused.  It serves as a documentation for the
> +# Patchew configuration in case patchew.org disappears or has to be
> +# reinstalled.
> +
> +git:
> +  push_to: g...@github.com:patchew-project/qemu
> +  public_repo: https://github.com/patchew-project/qemu
> +  url_template: https://github.com/patchew-project/qemu/tree/%t

So this is actually Patchew's copy of the QEMU repo where it keeps its
branches that it builds from the emails? It might be worth making that
clear as it is not git.qemu.org.

> +
> +email:
> +  ENOSPC:
> +event: TestingReport
> +to: f...@euphon.net
> +reply_subject: false
> +set_reply_to: false
> +subject_template: 'Out of space error for {{ tester }}'
> +body_template: |
> +  {% if passed %}
> +  {{ cancel }}
> +  {% endif %}
> +
> +  {% if 'No space left on device' in log %}
> +  Tester {{ tester }} out of space when running {{ test }}
> +
> +  {{ log | ansi2text }}
> +  {% else %}
> +  {{ cancel }}
> +  {% endif %}
> +
> +  timeouts:
> +event: TestingReport
> +to: f...@euphon.net
> +body_template: |
> +  {% if not is_timeout %} {{ cancel }} {% endif %}
> +
> +  Test '{{ test }}' timeout, log:
> +
> +  {{ log | ansi2text }}
> +
> +  failures:
> +event: TestingReport
> +reply_to_all: true
> +body_template: |
> +  {% if passed or not obj.message_id or is_timeout %}
> +{{ cancel }}
> +  {% endif %}
> +  {% if 'No space left on device' in log %}
> +{{ cancel }}
> +  {% endif %}
> +  Patchew URL: https://patchew.org/QEMU/{{ obj.message_id }}/
> +
> +  {% ansi2text log as logtext %}
> +  {% if test == "checkpatch" %}
> +  Hi,
> +
> +  This series seems to have some coding style problems. See output below 
> for
> +  more information:
> +
> +  {{ logtext }}
> +  {% elif test == "docker-mingw@fedora" or test == 
> "docker-quick@centos7" or test == "asan" %}
> +  Hi,
> +
> +  This series failed the {{ test }} build test. Please find the testing 
> commands and
> +  their output below. If you have Docker installed, you can probably 
> reproduce it
> +  locally.
> +
> +  {% lines_between logtext start="^=== TEST SCRIPT BEGIN ===$" 
> stop="^=== TEST SCRIPT END ===$" %}
> +  {% lines_between logtext start="^=== OUTPUT BEGIN ===$" stop="=== 
> OUTPUT END ===$" as output %}
> +  {% grep_C output regex="\b(FAIL|XPASS|ERROR|WARN|error:|warning:)" n=3 
> %}
> +  {% elif test == "s390x" or test == "FreeBSD" or test == "ppcle" or 
> test == "ppcbe" %}
> +  Hi,
> +
> +  This series failed build test on {{test}} host. Please find the 
> details below.
> +
> +  {% lines_between logtext start="^=== TEST SCRIPT BEGIN ===$" 
> stop="^=== TEST SCRIPT END ===$" %}
> +  {% lines_between logtext start="^=== OUTPUT BEGIN ===$" stop="=== 
> OUTPUT END ===$" as output %}
> +  {% grep_C output regex="\b(FAIL|XPASS|ERROR|WARN|error:|warning:)" n=3 
> %}
> +  {% else %}
> +  {{ cancel }}
> +  {% endif %}
> +
> +  The full log is available at
> +  {{ log_url }}.
> +  ---
> +  Email generated automatically by Patchew [http://patchew.org/].
> +  Please send your feedback to patchew-de...@redhat.com
> +
> +testing:
> +  defaults:
> +- timeout: 3600
> +
> +  requirements:
> +docker: |
> +  #!/bin/bash
> +  docker ps || sudo -n docker ps

FWIW the docker.py script now uses "docker version" as the test.

> +x86-kvm: |
> +  #!/bin/bash
> +  set -e
> +  test "$(uname -m)" = x86_64
> +  test -r /dev/kvm
> +  if qemu-system-x86_64 --help >/dev/null 2>&1; then
> +:
> +  elif /usr/libexec/qemu-kvm --help >/dev/null 2>&1; then
> +:
> +  else
> +false
> +  fi
> +ppcle: |
> +  #!/bin/sh
> +  test "$(uname -m)" = ppc64le
> +ppcbe: |
> +  #!/bin/sh
> +  test "$(uname -m)" = ppc64
> +s390x: |
> +  #!/bin/sh
> +  test "$(uname -m)" = s390x
> +
> +  tests:
> +asan:
> +  requirements: docker
> +  script: |
> +#!/bin/bash
> +time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 
> NETWORK=1
> +
> +docker-clang@ubuntu:
> +  requirements: docker
> +  script: |
> +#!/bin/bash
> +time m

Re: [Qemu-devel] [PATCH v7 6/7] vhost-user-blk: Add support to reconnect backend

[Yongji Xie]

On Fri, 15 Mar 2019 at 18:41, Yury Kotov  wrote:
>
> 15.03.2019, 12:46, "Daniel P. Berrangé" :
> > On Thu, Mar 14, 2019 at 03:31:47PM +0300, Yury Kotov wrote:
> >>  Hi,
> >>
> >>  14.03.2019, 14:44, "Daniel P. Berrangé" :
> >>  > On Thu, Mar 14, 2019 at 07:34:03AM -0400, Michael S. Tsirkin wrote:
> >>  >>  On Thu, Mar 14, 2019 at 11:24:22AM +, Daniel P. Berrangé wrote:
> >>  >>  > On Tue, Mar 12, 2019 at 12:49:35PM -0400, Michael S. Tsirkin wrote:
> >>  >>  > > On Thu, Feb 28, 2019 at 04:53:54PM +0800, elohi...@gmail.com 
> >> wrote:
> >>  >>  > > > From: Xie Yongji 
> >>  >>  > > >
> >>  >>  > > > Since we now support the message VHOST_USER_GET_INFLIGHT_FD
> >>  >>  > > > and VHOST_USER_SET_INFLIGHT_FD. The backend is able to restart
> >>  >>  > > > safely because it can track inflight I/O in shared memory.
> >>  >>  > > > This patch allows qemu to reconnect the backend after
> >>  >>  > > > connection closed.
> >>  >>  > > >
> >>  >>  > > > Signed-off-by: Xie Yongji 
> >>  >>  > > > Signed-off-by: Ni Xun 
> >>  >>  > > > Signed-off-by: Zhang Yu 
> >>  >>  > > > ---
> >>  >>  > > > hw/block/vhost-user-blk.c | 205 +++--
> >>  >>  > > > include/hw/virtio/vhost-user-blk.h | 4 +
> >>  >>  > > > 2 files changed, 167 insertions(+), 42 deletions(-)
> >>  >>  >
> >>  >>  >
> >>  >>  > > > static void vhost_user_blk_device_realize(DeviceState *dev, 
> >> Error **errp)
> >>  >>  > > > {
> >>  >>  > > > VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >>  >>  > > > VHostUserBlk *s = VHOST_USER_BLK(vdev);
> >>  >>  > > > VhostUserState *user;
> >>  >>  > > > - struct vhost_virtqueue *vqs = NULL;
> >>  >>  > > > int i, ret;
> >>  >>  > > > + Error *err = NULL;
> >>  >>  > > >
> >>  >>  > > > if (!s->chardev.chr) {
> >>  >>  > > > error_setg(errp, "vhost-user-blk: chardev is mandatory");
> >>  >>  > > > @@ -312,27 +442,28 @@ static void 
> >> vhost_user_blk_device_realize(DeviceState *dev, Error **errp)
> >>  >>  > > > }
> >>  >>  > > >
> >>  >>  > > > s->inflight = g_new0(struct vhost_inflight, 1);
> >>  >>  > > > -
> >>  >>  > > > - s->dev.nvqs = s->num_queues;
> >>  >>  > > > - s->dev.vqs = g_new(struct vhost_virtqueue, s->dev.nvqs);
> >>  >>  > > > - s->dev.vq_index = 0;
> >>  >>  > > > - s->dev.backend_features = 0;
> >>  >>  > > > - vqs = s->dev.vqs;
> >>  >>  > > > -
> >>  >>  > > > - vhost_dev_set_config_notifier(&s->dev, &blk_ops);
> >>  >>  > > > -
> >>  >>  > > > - ret = vhost_dev_init(&s->dev, s->vhost_user, 
> >> VHOST_BACKEND_TYPE_USER, 0);
> >>  >>  > > > - if (ret < 0) {
> >>  >>  > > > - error_setg(errp, "vhost-user-blk: vhost initialization 
> >> failed: %s",
> >>  >>  > > > - strerror(-ret));
> >>  >>  > > > - goto virtio_err;
> >>  >>  > > > - }
> >>  >>  > > > + s->vqs = g_new(struct vhost_virtqueue, s->num_queues);
> >>  >>  > > > + s->watch = 0;
> >>  >>  > > > + s->should_start = false;
> >>  >>  > > > + s->connected = false;
> >>  >>  > > > +
> >>  >>  > > > + qemu_chr_fe_set_handlers(&s->chardev, NULL, NULL, 
> >> vhost_user_blk_event,
> >>  >>  > > > + NULL, (void *)dev, NULL, true);
> >>  >>  > > > +
> >>  >>  > > > +reconnect:
> >>  >>  > > > + do {
> >>  >>  > > > + if (qemu_chr_fe_wait_connected(&s->chardev, &err) < 0) {
> >>  >>  > > > + error_report_err(err);
> >>  >>  > > > + err = NULL;
> >>  >>  > > > + sleep(1);
> >>  >>  > >
> >>  >>  > > Seems arbitrary. Is this basically waiting until backend will 
> >> reconnect?
> >>  >>  > > Why not block until event on the fd triggers?
> >>  >>  > >
> >>  >>  > > Also, it looks like this will just block forever with no monitor 
> >> input
> >>  >>  > > and no way for user to figure out what is going on short of
> >>  >>  > > crashing QEMU.
> >>  >>  >
> >>  >>  > FWIW, the current vhost-user-net device does exactly the same thing
> >>  >>  > with calling qemu_chr_fe_wait_connected during its realize() 
> >> function.
> >>  >>
> >>  >>  Hmm yes. It doesn't sleep for an arbitrary 1 sec so less of an 
> >> eyesore :)
> >>  >
> >>  > The sleep(1) in this patch simply needs to be removed. I think that
> >>  > probably dates from when it was written against the earlier broken
> >>  > version of qemu_chr_fe_wait_connected(). That would not correctly
> >>  > deal with the "reconnect" flag, and so needing this loop with a sleep
> >>  > in it.
> >>  >
> >>  > In fact the while loop can be removed as well in this code. It just
> >>  > needs to call qemu_chr_fe_wait_connected() once. It is guaranteed
> >>  > to have a connected peer once that returns 0.
> >>  >
> >>  > qemu_chr_fe_wait_connected() only returns -1 if the operating in
> >>  > client mode, and it failed to connect and reconnect is *not*
> >>  > requested. In such case the caller should honour the failure and
> >>  > quit, not loop to retry.
> >>  >
> >>  > The reason vhost-user-net does a loop is because once it has a
> >>  > connection it tries todo a protocol handshake, and if that
> >>  > handshake fails it closes the chardev and tries to connect
> >>  > again. That

Re: [Qemu-devel] [PATCH v2 08/12] pc-bios: add edk2 firmware binaries and variable store templates

[Gerd Hoffmann]

  Hi,

> It would be nice if we had a standard dockerfile that was designated
> as the build environment for each of the ROMs (one docker file might
> be suitable for many of the ROMs in fact).

If we manage to pull that off I'm wondering whenever there is a point
in continuing shipping the firmware binaries in git in the first place.

The reason we ship binaries is that building the firmware isn't easy,
due to special requirements, especially for non-native archs, needing
cross compilers for example.

But that point is moot if we can get fully automated firmware builds
going, by using docker and a distro with cross compilers ...

cheers,
  Gerd

[Qemu-devel] [PATCH v14 05/25] replay: don't drain/flush bdrv queue while RR is working

[Pavel Dovgalyuk]

In record/replay mode bdrv queue is controlled by replay mechanism.
It does not allow saving or loading the snapshots
when bdrv queue is not empty. Stopping the VM is not blocked by nonempty
queue, but flushing the queue is still impossible there,
because it may cause deadlocks in replay mode.
This patch disables bdrv_drain_all and bdrv_flush_all in
record/replay mode.

Stopping the machine when the IO requests are not finished is needed
for the debugging. E.g., breakpoint may be set at the specified step,
and forcing the IO requests to finish may break the determinism
of the execution.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 
---
 block/io.c |   28 
 cpus.c |2 --
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c
index 2ba603c7bc..866fd70d96 100644
--- a/block/io.c
+++ b/block/io.c
@@ -32,6 +32,7 @@
 #include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
+#include "sysemu/replay.h"
 
 #define NOT_DONE 0x7fff /* used while emulated sync operation in progress 
*/
 
@@ -538,6 +539,15 @@ void bdrv_drain_all_begin(void)
 return;
 }
 
+/*
+ * bdrv queue is managed by record/replay,
+ * waiting for finishing the I/O requests may
+ * be infinite
+ */
+if (replay_events_enabled()) {
+return;
+}
+
 /* AIO_WAIT_WHILE() with a NULL context can only be called from the main
  * loop AioContext, so make sure we're in the main context. */
 assert(qemu_get_current_aio_context() == qemu_get_aio_context());
@@ -566,6 +576,15 @@ void bdrv_drain_all_end(void)
 {
 BlockDriverState *bs = NULL;
 
+/*
+ * bdrv queue is managed by record/replay,
+ * waiting for finishing the I/O requests may
+ * be endless
+ */
+if (replay_events_enabled()) {
+return;
+}
+
 while ((bs = bdrv_next_all_states(bs))) {
 AioContext *aio_context = bdrv_get_aio_context(bs);
 
@@ -1960,6 +1979,15 @@ int bdrv_flush_all(void)
 BlockDriverState *bs = NULL;
 int result = 0;
 
+/*
+ * bdrv queue is managed by record/replay,
+ * creating new flush request for stopping
+ * the VM may break the determinism
+ */
+if (replay_events_enabled()) {
+return result;
+}
+
 for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
 AioContext *aio_context = bdrv_get_aio_context(bs);
 int ret;
diff --git a/cpus.c b/cpus.c
index e83f72b48b..5ff61fbf53 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1078,7 +1078,6 @@ static int do_vm_stop(RunState state, bool send_stop)
 }
 
 bdrv_drain_all();
-replay_disable_events();
 ret = bdrv_flush_all();
 
 return ret;
@@ -2150,7 +2149,6 @@ int vm_prepare_start(void)
 /* We are sending this now, but the CPUs will be resumed shortly later */
 qapi_event_send_resume();
 
-replay_enable_events();
 cpu_enable_ticks();
 runstate_set(RUN_STATE_RUNNING);
 vm_state_notify(1, RUN_STATE_RUNNING);

[Qemu-devel] [PATCH v14 24/25] replay: rename step-related variables and functions

[Pavel Dovgalyuk]

This patch renames replay_get_current_step() and related variables
to make these names consistent with hmp/qmp commands.

Signed-off-by: Pavel Dovgalyuk 
---
 blockdev.c|2 +-
 include/sysemu/replay.h   |2 +-
 migration/savevm.c|2 +-
 replay/replay-debugging.c |   30 --
 replay/replay-events.c|4 ++--
 replay/replay-internal.c  |   10 +-
 replay/replay-internal.h  |   10 +-
 replay/replay-snapshot.c  |6 +++---
 replay/replay-time.c  |2 +-
 replay/replay.c   |   26 +-
 10 files changed, 48 insertions(+), 46 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 183fd3f7f6..83eb7c1833 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1454,7 +1454,7 @@ static void internal_snapshot_prepare(BlkActionState 
*common,
 sn->date_nsec = tv.tv_usec * 1000;
 sn->vm_clock_nsec = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
 if (replay_mode != REPLAY_MODE_NONE) {
-sn->icount = replay_get_current_step();
+sn->icount = replay_get_current_icount();
 } else {
 sn->icount = -1ULL;
 }
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index b7394a1f5c..057a458463 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -96,7 +96,7 @@ void replay_breakpoint(void);
 /* Processing the instructions */
 
 /*! Returns number of executed instructions. */
-uint64_t replay_get_current_step(void);
+uint64_t replay_get_current_icount(void);
 /*! Returns number of instructions to execute in replay mode. */
 int replay_get_instructions(void);
 /*! Updates instructions counter in replay mode. */
diff --git a/migration/savevm.c b/migration/savevm.c
index 6a0ebacfed..74351fffeb 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2597,7 +2597,7 @@ int save_snapshot(const char *name, Error **errp)
 sn->date_nsec = tv.tv_usec * 1000;
 sn->vm_clock_nsec = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
 if (replay_mode != REPLAY_MODE_NONE) {
-sn->icount = replay_get_current_step();
+sn->icount = replay_get_current_icount();
 } else {
 sn->icount = -1ULL;
 }
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index abb5fe687f..b2275612c7 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -38,7 +38,7 @@ void hmp_info_replay(Monitor *mon, const QDict *qdict)
 monitor_printf(mon,
 "%s execution '%s': instruction count = %"PRId64"\n",
 replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
-replay_get_filename(), replay_get_current_step());
+replay_get_filename(), replay_get_current_icount());
 }
 }
 
@@ -51,7 +51,7 @@ ReplayInfo *qmp_query_replay(Error **errp)
 retval->filename = g_strdup(replay_get_filename());
 retval->has_filename = true;
 }
-retval->icount = replay_get_current_step();
+retval->icount = replay_get_current_icount();
 return retval;
 }
 
@@ -59,7 +59,7 @@ static void replay_break(uint64_t icount, QEMUTimerCB 
callback, void *opaque)
 {
 assert(replay_mode == REPLAY_MODE_PLAY);
 assert(replay_mutex_locked());
-assert(replay_break_icount >= replay_get_current_step());
+assert(replay_break_icount >= replay_get_current_icount());
 assert(callback);
 
 replay_break_icount = icount;
@@ -94,7 +94,7 @@ static void replay_stop_vm(void *opaque)
 void qmp_replay_break(int64_t icount, Error **errp)
 {
 if (replay_mode == REPLAY_MODE_PLAY) {
-if (icount >= replay_get_current_step()) {
+if (icount >= replay_get_current_icount()) {
 replay_break(icount, replay_stop_vm, NULL);
 } else {
 error_setg(errp,
@@ -196,14 +196,14 @@ static void replay_seek(int64_t icount, QEMUTimerCB 
callback, Error **errp)
 
 snapshot = replay_find_nearest_snapshot(icount, &snapshot_icount);
 if (snapshot) {
-if (icount < replay_get_current_step()
-|| replay_get_current_step() < snapshot_icount) {
+if (icount < replay_get_current_icount()
+|| replay_get_current_icount() < snapshot_icount) {
 vm_stop(RUN_STATE_RESTORE_VM);
 load_snapshot(snapshot, errp);
 }
 g_free(snapshot);
 }
-if (replay_get_current_step() <= icount) {
+if (replay_get_current_icount() <= icount) {
 replay_break(icount, callback, NULL);
 vm_start();
 } else {
@@ -242,8 +242,9 @@ bool replay_reverse_step(void)
 
 assert(replay_mode == REPLAY_MODE_PLAY);
 
-if (replay_get_current_step() != 0) {
-replay_seek(replay_get_current_step() - 1, replay_stop_vm_debug, &err);
+if (replay_get_current_icount() != 0) {
+replay_seek(replay_get_current_icount() - 1,
+replay_stop_vm_debug, &err);
 if (err) {
 error_free(err);
 return false;
@@ -283,7 +284,7 @@ static void replay_con

Re: [Qemu-devel] [PATCH v2 08/12] pc-bios: add edk2 firmware binaries and variable store templates

[Daniel P . Berrangé]

On Fri, Mar 15, 2019 at 01:29:31PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > It would be nice if we had a standard dockerfile that was designated
> > as the build environment for each of the ROMs (one docker file might
> > be suitable for many of the ROMs in fact).
> 
> If we manage to pull that off I'm wondering whenever there is a point
> in continuing shipping the firmware binaries in git in the first place.
> 
> The reason we ship binaries is that building the firmware isn't easy,
> due to special requirements, especially for non-native archs, needing
> cross compilers for example.
> 
> But that point is moot if we can get fully automated firmware builds
> going, by using docker and a distro with cross compilers ...

The main problem would be that we target many different operating
systems, but only Linux would be able to run the docker builds.
So people on FreeBSD, macOS etc still need firmware binaries, or
we would be forcing them to use Linux to build part of their system.

There's also possibly complications with non-x86 architctures, as
docker images tend to mostly be focused on x86 hosts.

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 v14 16/25] gdbstub: add reverse step support in replay mode

[Pavel Dovgalyuk]

GDB remote protocol supports two reverse debugging commands:
reverse step and reverse continue.
This patch adds support of the first one to the gdbstub.
Reverse step is intended to step one instruction in the backwards
direction. This is not possible in regular execution.
But replayed execution is deterministic, therefore we can load one of
the prior snapshots and proceed to the desired step. It is equivalent
to stepping one instruction back.
There should be at least one snapshot preceding the debugged part of
the replay log.

Signed-off-by: Pavel Dovgalyuk 
---
 accel/tcg/translator.c|1 +
 cpus.c|   14 +++---
 exec.c|7 +++
 gdbstub.c |   44 +---
 include/sysemu/replay.h   |   11 +++
 replay/replay-debugging.c |   33 +
 stubs/replay.c|5 +
 7 files changed, 109 insertions(+), 6 deletions(-)

diff --git a/accel/tcg/translator.c b/accel/tcg/translator.c
index afd0a49ea6..33a543e82f 100644
--- a/accel/tcg/translator.c
+++ b/accel/tcg/translator.c
@@ -17,6 +17,7 @@
 #include "exec/gen-icount.h"
 #include "exec/log.h"
 #include "exec/translator.h"
+#include "sysemu/replay.h"
 
 /* Pairs with tcg_clear_temp_count.
To be called by #TranslatorOps.{translate_insn,tb_stop} if
diff --git a/cpus.c b/cpus.c
index 5ff61fbf53..44d0b23435 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1104,9 +1104,17 @@ static bool cpu_can_run(CPUState *cpu)
 
 static void cpu_handle_guest_debug(CPUState *cpu)
 {
-gdb_set_stop_cpu(cpu);
-qemu_system_debug_request();
-cpu->stopped = true;
+if (!replay_running_debug()) {
+gdb_set_stop_cpu(cpu);
+qemu_system_debug_request();
+cpu->stopped = true;
+} else {
+if (!cpu->singlestep_enabled) {
+cpu_single_step(cpu, SSTEP_ENABLE);
+} else {
+cpu_single_step(cpu, 0);
+}
+}
 }
 
 #ifdef CONFIG_LINUX
diff --git a/exec.c b/exec.c
index 86a38d3b3b..474d7bbe00 100644
--- a/exec.c
+++ b/exec.c
@@ -2771,6 +2771,13 @@ static void check_watchpoint(int offset, int len, 
MemTxAttrs attrs, int flags)
 QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
 if (cpu_watchpoint_address_matches(wp, vaddr, len)
 && (wp->flags & flags)) {
+if (replay_running_debug()) {
+/*
+ * Don't process the watchpoints when we are
+ * in a reverse debugging operation.
+ */
+return;
+}
 if (flags == BP_MEM_READ) {
 wp->flags |= BP_WATCHPOINT_HIT_READ;
 } else {
diff --git a/gdbstub.c b/gdbstub.c
index bc774ae992..9f987650ae 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -39,6 +39,7 @@
 #include "sysemu/kvm.h"
 #include "exec/semihost.h"
 #include "exec/exec-all.h"
+#include "sysemu/replay.h"
 
 #ifdef CONFIG_USER_ONLY
 #define GDB_ATTACHED "0"
@@ -344,6 +345,20 @@ typedef struct GDBState {
  */
 static int sstep_flags = SSTEP_ENABLE|SSTEP_NOIRQ|SSTEP_NOTIMER;
 
+/* Retrieves flags for single step mode. */
+static int get_sstep_flags(void)
+{
+/*
+ * In replay mode all events written into the log should be replayed.
+ * That is why NOIRQ flag is removed in this mode.
+ */
+if (replay_mode != REPLAY_MODE_NONE) {
+return SSTEP_ENABLE;
+} else {
+return sstep_flags;
+}
+}
+
 static GDBState *gdbserver_state;
 
 bool gdb_has_xml;
@@ -434,7 +449,7 @@ static int gdb_continue_partial(GDBState *s, char 
*newstates)
 CPU_FOREACH(cpu) {
 if (newstates[cpu->cpu_index] == 's') {
 trace_gdbstub_op_stepping(cpu->cpu_index);
-cpu_single_step(cpu, sstep_flags);
+cpu_single_step(cpu, get_sstep_flags());
 }
 }
 s->running_state = 1;
@@ -453,7 +468,7 @@ static int gdb_continue_partial(GDBState *s, char 
*newstates)
 break; /* nothing to do here */
 case 's':
 trace_gdbstub_op_stepping(cpu->cpu_index);
-cpu_single_step(cpu, sstep_flags);
+cpu_single_step(cpu, get_sstep_flags());
 cpu_resume(cpu);
 flag = 1;
 break;
@@ -1414,9 +1429,28 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 addr = strtoull(p, (char **)&p, 16);
 gdb_set_cpu_pc(s, addr);
 }
-cpu_single_step(s->c_cpu, sstep_flags);
+cpu_single_step(s->c_cpu, get_sstep_flags());
 gdb_continue(s);
 return RS_IDLE;
+case 'b':
+/* Backward debugging commands */
+if (replay_mode == REPLAY_MODE_PLAY) {
+switch (*p) {
+case 's':
+if (replay_reverse_step()) {
+gdb_continue(s);
+return RS_IDLE;
+} else {
+put_packet(s, "E14");
+

Re: [Qemu-devel] [PATCH v2 08/12] pc-bios: add edk2 firmware binaries and variable store templates

[Daniel P . Berrangé]

On Thu, Mar 14, 2019 at 07:43:58PM +0100, Philippe Mathieu-Daudé wrote:
> On 3/13/19 10:00 PM, Laszlo Ersek wrote:
> > Add the files built by the last patch: (compressed) binaries, and the
> > cumulative license text that covers them.
> > 
> > Signed-off-by: Laszlo Ersek 
> > ---
> > 
> > Notes:
> > v2:
> > 
> > - capture the compressed build outputs of the last patch; slightly
> >   update the commit message [Dan, Michael, Phil]
> > 
> > - consequently, do not pick up Michal's and Michael's R-b's
> 
> Well I was not explicit in my previous review: I simply checked the
> Licenses match the EDK2 project, but I haven't review the binaries.
> Ideally I'd rather submit the binaries from a CI system or a Docker
> image than your workstation.

I think that point probably applies to all of the binary ROMs
that QEMU is already distributing.

We have make rules that build them from the subdir, but we have
no record of what kind of host they were built on by the maintainer
which is troublesome for reproducability.

It would be nice if we had a standard dockerfile that was designated
as the build environment for each of the ROMs (one docker file might
be suitable for many of the ROMs in fact).

After building in the docker environment, we should capture a list
of all the RPM/Deb packages that were in the docker image, and
commit that to git alongside the binary ROM as a record of the
actual build environment.

We should be able to automate this whole process, so the maintainer
just updates the submodule hash, and then runs "make rom-refresh-edk".
It would run the docker build, capture the package list, and do the
actual git commit with it all.

With all that said, I don't think that needs to block Laszlo's
series. We already have this problem of reproducability with all
the existing ROMs and its thus unreasonable to hold Laszlo to
a different higher standard that what we've already accepted.

I think it is highly desirable as something to priortize though
going forward. Perhaps we can set it as a target for next release
cycle that all future binary ROM refreshes must be done from a
docker env & the installed package set be recorded in git next
to the ROM.

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 v14 18/25] replay: describe reverse debugging in docs/replay.txt

[Pavel Dovgalyuk]

This patch updates the documentation and describes usage of the reverse
debugging in QEMU+GDB.

Signed-off-by: Pavel Dovgalyuk 
---
 docs/replay.txt |   33 +
 1 file changed, 33 insertions(+)

diff --git a/docs/replay.txt b/docs/replay.txt
index ce97c3f72f..47b4f2d9f8 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -293,6 +293,39 @@ for recording and replaying must contain identical number 
of ports in record
 and replay modes, but their backends may differ.
 E.g., '-serial stdio' in record mode, and '-serial null' in replay mode.
 
+Reverse debugging
+-
+
+Reverse debugging allows "executing" the program in reverse direction.
+GDB remote protocol supports "reverse step" and "reverse continue"
+commands. The first one steps single instruction backwards in time,
+and the second one finds the last breakpoint in the past.
+
+Recorded executions may be used to enable reverse debugging. QEMU can't
+execute the code in backwards direction, but can load a snapshot and
+replay forward to find the desired position or breakpoint.
+
+The following GDB commands are supported:
+ - reverse-stepi (or rsi) - step one instruction backwards
+ - reverse-continue (or rc) - find last breakpoint in the past
+
+Reverse step loads the nearest snapshot and replays the execution until
+the required instruction is met.
+
+Reverse continue may include several passes of examining the execution
+between the snapshots. Each of the passes include the following steps:
+ 1. loading the snapshot
+ 2. replaying to examine the breakpoints
+ 3. if breakpoint or watchpoint was met
+- loading the snaphot again
+- replaying to the required breakpoint
+ 4. else
+- proceeding to the p.1 with the earlier snapshot
+
+Therefore usage of the reverse debugging requires at least one snapshot
+created in advance. See the "Snapshotting" section to learn about running
+record/replay and creating the snapshot in these modes.
+
 Replay log format
 -
 

[Qemu-devel] [PATCH v14 14/25] replay: refine replay-time module

[Pavel Dovgalyuk]

This patch removes refactoring artifacts from the replay/replay-time.c

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay-time.c |   36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/replay/replay-time.c b/replay/replay-time.c
index 0df1693337..60f47b73a7 100644
--- a/replay/replay-time.c
+++ b/replay/replay-time.c
@@ -15,18 +15,19 @@
 #include "replay-internal.h"
 #include "qemu/error-report.h"
 
-int64_t replay_save_clock(ReplayClockKind kind, int64_t clock, int64_t 
raw_icount)
+int64_t replay_save_clock(ReplayClockKind kind, int64_t clock,
+  int64_t raw_icount)
 {
-if (replay_file) {
-g_assert(replay_mutex_locked());
+g_assert(replay_file);
+g_assert(replay_mutex_locked());
 
-/* Due to the caller's locking requirements we get the icount from it
- * instead of using replay_save_instructions().
- */
-replay_advance_current_step(raw_icount);
-replay_put_event(EVENT_CLOCK + kind);
-replay_put_qword(clock);
-}
+/*
+ * Due to the caller's locking requirements we get the icount from it
+ * instead of using replay_save_instructions().
+ */
+replay_advance_current_step(raw_icount);
+replay_put_event(EVENT_CLOCK + kind);
+replay_put_qword(clock);
 
 return clock;
 }
@@ -48,20 +49,15 @@ void replay_read_next_clock(ReplayClockKind kind)
 /*! Reads next clock event from the input. */
 int64_t replay_read_clock(ReplayClockKind kind)
 {
+int64_t ret;
 g_assert(replay_file && replay_mutex_locked());
 
 replay_account_executed_instructions();
 
-if (replay_file) {
-int64_t ret;
-if (replay_next_event_is(EVENT_CLOCK + kind)) {
-replay_read_next_clock(kind);
-}
-ret = replay_state.cached_clock[kind];
-
-return ret;
+if (replay_next_event_is(EVENT_CLOCK + kind)) {
+replay_read_next_clock(kind);
 }
+ret = replay_state.cached_clock[kind];
 
-error_report("REPLAY INTERNAL ERROR %d", __LINE__);
-exit(1);
+return ret;
 }

[Qemu-devel] [PATCH v14 11/25] replay: introduce info hmp/qmp command

[Pavel Dovgalyuk]

This patch introduces 'info replay' monitor command and
corresponding qmp request.
These commands request the current record/replay mode, replay log file
name, and the instruction count (number of recorded/replayed
instructions).  The instruction count can be used with the
replay_seek/replay_break commands added in the next two patches.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Dr. David Alan Gilbert 
Acked-by: Markus Armbruster 

--

v2:
 - renamed info_replay qmp into query-replay (suggested by Eric Blake)
v7:
 - added empty line (suggested by Markus Armbruster)
v9:
 - changed 'step' parameter name to 'icount'
 - moved json stuff to replay.json and updated the descriptions
   (suggested by Markus Armbruster)
v10:
 - updated descriptions and messages for rr stuff
---
 hmp-commands-info.hx  |   14 ++
 hmp.h |1 +
 qapi/block-core.json  |3 ++-
 qapi/replay.json  |   39 +++
 replay/Makefile.objs  |3 ++-
 replay/replay-debugging.c |   43 +++
 6 files changed, 101 insertions(+), 2 deletions(-)
 create mode 100644 replay/replay-debugging.c

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index cbee8b944d..7cc0baadba 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -916,6 +916,20 @@ STEXI
 @item info sev
 @findex info sev
 Show SEV information.
+ETEXI
+
+{
+.name   = "replay",
+.args_type  = "",
+.params = "",
+.help   = "show record/replay information",
+.cmd= hmp_info_replay,
+},
+
+STEXI
+@item info replay
+@findex info replay
+Display the record/replay information: mode and the current icount.
 ETEXI
 
 STEXI
diff --git a/hmp.h b/hmp.h
index e0f32f04d3..4ae42d7a2f 100644
--- a/hmp.h
+++ b/hmp.h
@@ -149,5 +149,6 @@ void hmp_hotpluggable_cpus(Monitor *mon, const QDict 
*qdict);
 void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
 void hmp_info_sev(Monitor *mon, const QDict *qdict);
+void hmp_info_replay(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi/block-core.json b/qapi/block-core.json
index ecaf23bc2e..702807a45b 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -28,7 +28,8 @@
 #
 # @icount: Current instruction count. Appears when execution record/replay
 #  is enabled. Used for "time-traveling" to match the moment
-#  in the recorded execution with the snapshots. (since 4.0)
+#  in the recorded execution with the snapshots. This counter may
+#  be obtained through @query-replay command (since 4.0)
 #
 # Since: 1.3
 #
diff --git a/qapi/replay.json b/qapi/replay.json
index 9e13551d20..4206150544 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -24,3 +24,42 @@
 ##
 { 'enum': 'ReplayMode',
   'data': [ 'none', 'record', 'play' ] }
+
+##
+# @ReplayInfo:
+#
+# Record/replay information.
+#
+# @mode: current mode.
+#
+# @filename: name of the record/replay log file.
+#It is present only in record or replay modes, when the log
+#is recorded or replayed.
+#
+# @icount: current number of executed instructions.
+#
+# Since: 4.0
+#
+##
+{ 'struct': 'ReplayInfo',
+  'data': { 'mode': 'ReplayMode', '*filename': 'str', 'icount': 'int' } }
+
+##
+# @query-replay:
+#
+# Retrieve the record/replay information.
+# It includes current instruction count which may be used for
+# @replay-break and @replay-seek commands.
+#
+# Returns: record/replay information.
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "query-replay" }
+# <- { "return": { "mode": "play", "filename": "log.rr", "icount": 220414 } }
+#
+##
+{ 'command': 'query-replay',
+  'returns': 'ReplayInfo' }
diff --git a/replay/Makefile.objs b/replay/Makefile.objs
index cee6539a23..6694e3e2a2 100644
--- a/replay/Makefile.objs
+++ b/replay/Makefile.objs
@@ -6,4 +6,5 @@ common-obj-y += replay-input.o
 common-obj-y += replay-char.o
 common-obj-y += replay-snapshot.o
 common-obj-y += replay-net.o
-common-obj-y += replay-audio.o
\ No newline at end of file
+common-obj-y += replay-audio.o
+common-obj-y += replay-debugging.o
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
new file mode 100644
index 00..51f1c4d82d
--- /dev/null
+++ b/replay/replay-debugging.c
@@ -0,0 +1,43 @@
+/*
+ * replay-debugging.c
+ *
+ * Copyright (c) 2010-2018 Institute for System Programming
+ * of the Russian Academy of Sciences.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "sysemu/replay.h"
+#include "replay-internal.h"
+#include "hmp.h"
+#include "monitor/monitor.h"
+#include "qapi/qapi-commands-replay.h"
+
+void hmp_info_replay(Monitor *mon, const QDict *qdict)
+{
+if (replay_mod

Re: [Qemu-devel] [PULL 17/29] target/riscv: Convert quadrant 1 of RVXC insns to decodetree

[Bastian Koppelmann]

On 3/15/19 1:44 PM, Bastian Koppelmann wrote:


On 3/15/19 1:07 PM, Palmer Dabbelt wrote:
On Fri, Mar 15, 2019 at 4:19 AM Palmer Dabbelt  
wrote:



On Fri, 15 Mar 2019 02:06:07 PDT (-0700), Bastian Koppelmann wrote:

Hi Alistair

On 3/14/19 9:28 PM, Alistair Francis wrote:

On Wed, Mar 13, 2019 at 7:53 AM Palmer Dabbelt 

wrote:

From: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
Signed-off-by: Bastian Koppelmann 
Signed-off-by: Peer Adelt 

This commit is the first bad commit in breaking 32-bit boot.

It looks like the jal doesn't jump to the correct address:


IN:
0x8022:  00050433  add s0,a0,zero
0x8026:  000584b3  add s1,a1,zero
0x802a:  2c79  jal ra,670  #

0x82c8


IN:
0x82c8:  0533  add a0,zero,zero
0x82cc:  8082  ret


Oops! Can you point me to the binary to reproduce this?
I think I've traced it down to something simple: in my hello world 
binary

I see

 20401a8c:   2a45    jal 20401c3c 

in the objdump, and I see

 IN: _start
 0x20401a8c:  2a45  jal ra,432  #
0x20401c3c

but then QEMU jumps to 0x20401a9d.  I have a feeling it's something 
wrong

with
gen_jal() that disappeared during the cleanups that we dropped in 
order to

fix
the build issues.

I'm running

 ./riscv32-softmmu/qemu-system-riscv32 -machine sifive_e -kernel
~/work/sifive/freedom-e-sdk/software/hello/hello -nographic -d
in_asm,out_asm,exec,cpu -singlestep |& tee out.log

on the "hifive1" branch of github.com/palmer-dabbelt/qemu, which 
just has

a
PRCI fixup that I forgot about and haven't sent upstream yet (I'll 
do that

after this issue).  The binary should be at

 http://www.dabbelt.com/~palmer/hello.elf

and the debug log at

 http://www.dabbelt.com/~palmer/out.log

You can build the binary from github.com/sifive/freedom-e-sdk via

    make software PROGRAM=hello TARGET=sifive-hifive1

using the riscv64-unknown-elf-gcc-20181127-x86_64-linux-ubuntu14 
toolchain

binaries from our website (newer ones should work, but probably won't
produce
exactly the same output).

I'll poke around after grabbing some dinner...


OK, I'm pretty sure this is it:

c_jal_addiw   001 .  .  . 01 @ci #Note: parse rd and/or imm
manually


Thanks for the digging. Yes this bug was fixed in the patches we 
dropped :/. Heres the fix:


diff --git a/target/riscv/insn_trans/trans_rvc.inc.c 
b/target/riscv/insn_trans/trans_rvc.inc.c

index bcdf64d3b7..5241a8414e 100644
--- a/target/riscv/insn_trans/trans_rvc.inc.c
+++ b/target/riscv/insn_trans/trans_rvc.inc.c
@@ -88,7 +88,9 @@ static bool trans_c_jal_addiw(DisasContext *ctx, 
arg_c_jal_addiw *a)

 {
 #ifdef TARGET_RISCV32
 /* C.JAL */
-    arg_jal arg = { .rd = 1, .imm = a->imm };
+    arg_c_j tmp;
+    extract_cj(&tmp, ctx->opcode);

Sorry, it's decode_insn16_extract_cj()

[Qemu-devel] [PATCH v14 12/25] replay: introduce breakpoint at the specified step

[Pavel Dovgalyuk]

This patch introduces replay_break, replay_delete_break
qmp and hmp commands.
These commands allow stopping at the specified instruction.
It may be useful for debugging when there are some known
events that should be investigated.
replay_break command has one argument - number of instructions
executed since the start of the replay.
replay_delete_break removes previously set breakpoint.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Markus Armbruster 

--

v2:
 - renamed replay_break qmp command into replay-break
   (suggested by Eric Blake)
v7:
 - introduces replay_delete_break command
v9:
 - changed 'step' parameter name to 'icount'
 - moved json stuff to replay.json and updated the description
   (suggested by Markus Armbruster)
v10:
 - updated descriptions (suggested by Markus Armbruster)
---
 hmp-commands.hx   |   34 ++
 hmp.h |2 +
 qapi/replay.json  |   36 +++
 replay/replay-debugging.c |   86 +
 replay/replay-internal.h  |4 ++
 replay/replay.c   |   17 +
 6 files changed, 179 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 9b4035965c..1eb07e7bcc 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1911,6 +1911,40 @@ ETEXI
 STEXI
 @item qom-set @var{path} @var{property} @var{value}
 Set QOM property @var{property} of object at location @var{path} to value 
@var{value}
+ETEXI
+
+{
+.name   = "replay_break",
+.args_type  = "icount:i",
+.params = "icount",
+.help   = "set breakpoint at the specified instruction count",
+.cmd= hmp_replay_break,
+},
+
+STEXI
+@item replay_break @var{icount}
+@findex replay_break
+Set replay breakpoint at instruction count @var{icount}.
+Execution stops when the specified instruction is reached.
+There can be at most one breakpoint. When breakpoint is set, any prior
+one is removed.  The breakpoint may be set only in replay mode and only
+"in the future", i.e. at instruction counts greater than the current one.
+The current instruction count can be observed with 'info replay'.
+ETEXI
+
+{
+.name   = "replay_delete_break",
+.args_type  = "",
+.params = "",
+.help   = "removes replay breakpoint",
+.cmd= hmp_replay_delete_break,
+},
+
+STEXI
+@item replay_delete_break
+@findex replay_delete_break
+Remove replay breakpoint which was previously set with replay_break.
+The command is ignored when there are no replay breakpoints.
 ETEXI
 
 {
diff --git a/hmp.h b/hmp.h
index 4ae42d7a2f..5f1e27a5a4 100644
--- a/hmp.h
+++ b/hmp.h
@@ -150,5 +150,7 @@ void hmp_info_vm_generation_id(Monitor *mon, const QDict 
*qdict);
 void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
 void hmp_info_sev(Monitor *mon, const QDict *qdict);
 void hmp_info_replay(Monitor *mon, const QDict *qdict);
+void hmp_replay_break(Monitor *mon, const QDict *qdict);
+void hmp_replay_delete_break(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi/replay.json b/qapi/replay.json
index 4206150544..84c148cc4e 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -63,3 +63,39 @@
 ##
 { 'command': 'query-replay',
   'returns': 'ReplayInfo' }
+
+##
+# @replay-break:
+#
+# Set replay breakpoint at instruction count @icount.
+# Execution stops when the specified instruction is reached.
+# There can be at most one breakpoint. When breakpoint is set, any prior
+# one is removed.  The breakpoint may be set only in replay mode and only
+# "in the future", i.e. at instruction counts greater than the current one.
+# The current instruction count can be observed with @query-replay.
+#
+# @icount: instruction count to stop at
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "replay-break", "data": { "icount": 220414 } }
+#
+##
+{ 'command': 'replay-break', 'data': { 'icount': 'int' } }
+
+##
+# @replay-delete-break:
+#
+# Remove replay breakpoint which was set with @replay-break.
+# The command is ignored when there are no replay breakpoints.
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "replay-delete-break" }
+#
+##
+{ 'command': 'replay-delete-break' }
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index 51f1c4d82d..a94685e437 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -16,6 +16,8 @@
 #include "hmp.h"
 #include "monitor/monitor.h"
 #include "qapi/qapi-commands-replay.h"
+#include "qapi/qmp/qdict.h"
+#include "qemu/timer.h"
 
 void hmp_info_replay(Monitor *mon, const QDict *qdict)
 {
@@ -41,3 +43,87 @@ ReplayInfo *qmp_query_replay(Error **errp)
 retval->icount = replay_get_current_step();
 return retval;
 }
+
+static void replay_break(uint64_t icount, QEMUTimerCB callback, void *opaque)
+{
+assert(replay_mode == REPLAY_MODE_PLAY);
+assert(replay_mutex_locked());
+assert(replay_break_icount >= replay_get_current_step());
+assert

[Qemu-devel] [PATCH v14 10/25] qapi: introduce replay.json for record/replay-related stuff

[Pavel Dovgalyuk]

This patch adds replay.json file. It will be
used for adding record/replay-related data structures and commands.

Signed-off-by: Pavel Dovgalyuk 
Reviewed-by: Markus Armbruster 

--

v10:
 - minor changes
v13:
 - rebased to the new QAPI files
---
 MAINTAINERS |1 +
 include/sysemu/replay.h |2 +-
 qapi/Makefile.objs  |2 +-
 qapi/misc.json  |   18 --
 qapi/qapi-schema.json   |1 +
 qapi/replay.json|   26 ++
 6 files changed, 30 insertions(+), 20 deletions(-)
 create mode 100644 qapi/replay.json

diff --git a/MAINTAINERS b/MAINTAINERS
index 0e7baa9aa2..46972af469 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2186,6 +2186,7 @@ F: net/filter-replay.c
 F: include/sysemu/replay.h
 F: docs/replay.txt
 F: stubs/replay.c
+F: qapi/replay.json
 
 IOVA Tree
 M: Peter Xu 
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index b3f593f2f0..3fe14b5f57 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -13,7 +13,7 @@
  */
 
 #include "sysemu.h"
-#include "qapi/qapi-types-misc.h"
+#include "qapi/qapi-types-replay.h"
 #include "qapi/qapi-types-ui.h"
 
 /* replay clock kinds */
diff --git a/qapi/Makefile.objs b/qapi/Makefile.objs
index 729e5185c5..ee77aac9b9 100644
--- a/qapi/Makefile.objs
+++ b/qapi/Makefile.objs
@@ -6,7 +6,7 @@ util-obj-y += qmp-event.o
 util-obj-y += qapi-util.o
 
 QAPI_COMMON_MODULES = audio authz block-core block char common crypto
-QAPI_COMMON_MODULES += introspect job migration misc net rdma rocker
+QAPI_COMMON_MODULES += introspect job migration misc net rdma replay rocker
 QAPI_COMMON_MODULES += run-state sockets tpm trace transaction ui
 QAPI_TARGET_MODULES = target
 QAPI_MODULES = $(QAPI_COMMON_MODULES) $(QAPI_TARGET_MODULES)
diff --git a/qapi/misc.json b/qapi/misc.json
index 8b3ca4fdd3..00cf0e0bba 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -2876,24 +2876,6 @@
 { 'event': 'ACPI_DEVICE_OST',
  'data': { 'info': 'ACPIOSTInfo' } }
 
-##
-# @ReplayMode:
-#
-# Mode of the replay subsystem.
-#
-# @none: normal execution mode. Replay or record are not enabled.
-#
-# @record: record mode. All non-deterministic data is written into the
-#  replay log.
-#
-# @play: replay mode. Non-deterministic data required for system execution
-#is read from the log.
-#
-# Since: 2.5
-##
-{ 'enum': 'ReplayMode',
-  'data': [ 'none', 'record', 'play' ] }
-
 ##
 # @xen-load-devices-state:
 #
diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
index 4bd1223637..3bd5bc1320 100644
--- a/qapi/qapi-schema.json
+++ b/qapi/qapi-schema.json
@@ -97,6 +97,7 @@
 { 'include': 'transaction.json' }
 { 'include': 'trace.json' }
 { 'include': 'introspect.json' }
+{ 'include': 'replay.json' }
 { 'include': 'misc.json' }
 { 'include': 'target.json' }
 { 'include': 'audio.json' }
diff --git a/qapi/replay.json b/qapi/replay.json
new file mode 100644
index 00..9e13551d20
--- /dev/null
+++ b/qapi/replay.json
@@ -0,0 +1,26 @@
+# -*- Mode: Python -*-
+#
+
+##
+# = Record/replay
+##
+
+{ 'include': 'common.json' }
+
+##
+# @ReplayMode:
+#
+# Mode of the replay subsystem.
+#
+# @none: normal execution mode. Replay or record are not enabled.
+#
+# @record: record mode. All non-deterministic data is written into the
+#  replay log.
+#
+# @play: replay mode. Non-deterministic data required for system execution
+#is read from the log.
+#
+# Since: 2.5
+##
+{ 'enum': 'ReplayMode',
+  'data': [ 'none', 'record', 'play' ] }

Re: [Qemu-devel] Data bus error with redeonfb on mips_fulong2e

[BALATON Zoltan]

On Fri, 15 Mar 2019, Philippe Mathieu-Daudé wrote:

$ fgrep 'pci_cfg_write ati-vga' trace.log
...
23023@1552615560.106226:pci_cfg_write ati-vga 06:0 @0x10 <- 0x408
23023@1552615560.106337:pci_cfg_write ati-vga 06:0 @0x18 <- 0x505
23023@1552615560.106823:pci_cfg_write ati-vga 06:0 @0x30 <- 0x5040001
23023@1552615560.107271:pci_cfg_write ati-vga 06:0 @0x14 <- 0xa101
23023@1552615560.119752:pci_cfg_write ati-vga 06:0 @0x4 <- 0x147


Linux seems to do:

2239@1552652004.544147:pci_cfg_write ati-vga 06:0 @0x10 <- 0x1408
2239@1552652004.547172:pci_cfg_write ati-vga 06:0 @0x18 <- 0x1505
2239@1552652004.547840:pci_cfg_write ati-vga 06:0 @0x14 <- 0x4001
2239@1552652005.123332:pci_cfg_write ati-vga 06:0 @0x3c <- 0x0
2239@1552652005.125489:pci_cfg_write ati-vga 06:0 @0x4 <- 0x3

Not sure where the difference comes from and why this fails.

Regards,
BALATON Zoltan

[Qemu-devel] [PATCH v14 02/25] block: implement bdrv_snapshot_goto for blkreplay

[Pavel Dovgalyuk]

From: Pavel Dovgalyuk 

This patch enables making snapshots with blkreplay used in
block devices.
This function is required to make bdrv_snapshot_goto without
calling .bdrv_open which is not implemented.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 
---
 block/blkreplay.c |8 
 1 file changed, 8 insertions(+)

diff --git a/block/blkreplay.c b/block/blkreplay.c
index b5d9efdeca..142dfe3157 100644
--- a/block/blkreplay.c
+++ b/block/blkreplay.c
@@ -126,6 +126,12 @@ static int coroutine_fn 
blkreplay_co_flush(BlockDriverState *bs)
 return ret;
 }
 
+static int blkreplay_snapshot_goto(BlockDriverState *bs,
+   const char *snapshot_id)
+{
+return bdrv_snapshot_goto(bs->file->bs, snapshot_id, NULL);
+}
+
 static BlockDriver bdrv_blkreplay = {
 .format_name= "blkreplay",
 .instance_size  = 0,
@@ -140,6 +146,8 @@ static BlockDriver bdrv_blkreplay = {
 .bdrv_co_pwrite_zeroes  = blkreplay_co_pwrite_zeroes,
 .bdrv_co_pdiscard   = blkreplay_co_pdiscard,
 .bdrv_co_flush  = blkreplay_co_flush,
+
+.bdrv_snapshot_goto = blkreplay_snapshot_goto,
 };
 
 static void bdrv_blkreplay_init(void)

[Qemu-devel] [PATCH v14 07/25] qcow2: introduce icount field for snapshots

[Pavel Dovgalyuk]

This patch introduces the icount field for saving within the snapshot.
It is required for navigation between the snapshots in record/replay mode.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 

--

v2:
 - documented format changes in docs/interop/qcow2.txt
   (suggested by Eric Blake)
v10:
 - updated the documentation
---
 block/qcow2-snapshot.c |7 +++
 block/qcow2.h  |2 ++
 docs/interop/qcow2.txt |4 
 3 files changed, 13 insertions(+)

diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index a6ffae89a6..52b535425a 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -103,6 +103,12 @@ int qcow2_read_snapshots(BlockDriverState *bs)
 sn->disk_size = bs->total_sectors * BDRV_SECTOR_SIZE;
 }
 
+if (extra_data_size >= 24) {
+sn->icount = be64_to_cpu(extra.icount);
+} else {
+sn->icount = -1ULL;
+}
+
 /* Read snapshot ID */
 sn->id_str = g_malloc(id_str_size + 1);
 ret = bdrv_pread(bs->file, offset, sn->id_str, id_str_size);
@@ -209,6 +215,7 @@ static int qcow2_write_snapshots(BlockDriverState *bs)
 memset(&extra, 0, sizeof(extra));
 extra.vm_state_size_large = cpu_to_be64(sn->vm_state_size);
 extra.disk_size = cpu_to_be64(sn->disk_size);
+extra.icount = cpu_to_be64(sn->icount);
 
 id_str_size = strlen(sn->id_str);
 name_size = strlen(sn->name);
diff --git a/block/qcow2.h b/block/qcow2.h
index fdee297f33..7838dcbcea 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -160,6 +160,7 @@ typedef struct QEMU_PACKED QCowSnapshotHeader {
 typedef struct QEMU_PACKED QCowSnapshotExtraData {
 uint64_t vm_state_size_large;
 uint64_t disk_size;
+uint64_t icount;
 } QCowSnapshotExtraData;
 
 
@@ -173,6 +174,7 @@ typedef struct QCowSnapshot {
 uint32_t date_sec;
 uint32_t date_nsec;
 uint64_t vm_clock_nsec;
+uint64_t icount;
 } QCowSnapshot;
 
 struct Qcow2Cache;
diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index af5711e533..aa9d447cda 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -584,6 +584,10 @@ Snapshot table entry:
 
 Byte 48 - 55:   Virtual disk size of the snapshot in bytes
 
+Byte 56 - 63:   icount value which corresponds to
+the record/replay instruction count
+when the snapshot was taken
+
 Version 3 images must include extra data at least up to
 byte 55.
 

Re: [Qemu-devel] [PATCHv2] curses ui: always initialize all curses_line fields

[Peter Maydell]

On Fri, 15 Mar 2019 at 13:09, Samuel Thibault
 wrote:
>
> cchar_t can contain not only attr and chars fields, but also ext_color.
> Initialize the whole structure to zero instead of enumerating fields.
>
> Spotted by Coverity: CID 1399711
>
> Signed-off-by: Samuel Thibault 
> ---
>  ui/curses.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/ui/curses.c b/ui/curses.c
> index d29098db9f..cc6d6da684 100644
> --- a/ui/curses.c
> +++ b/ui/curses.c
> @@ -75,9 +75,9 @@ static void curses_update(DisplayChangeListener *dcl,
>  if (vga_to_curses[ch].chars[0]) {
>  curses_line[x] = vga_to_curses[ch];
>  } else {
> -curses_line[x].chars[0] = ch;
> -curses_line[x].chars[1] = 0;
> -curses_line[x].attr = 0;
> +curses_line[x] = (cchar_t) {
> +.chars[0] = ch,
> +};
>  }
>  curses_line[x].attr |= at;
>  }

Reviewed-by: Peter Maydell 

thanks
-- PMM

[Qemu-devel] [PATCH v14 04/25] replay: update docs for record/replay with block devices

[Pavel Dovgalyuk]

This patch updates the description of the command lines for using
record/replay with attached block devices.

Signed-off-by: Pavel Dovgalyuk 
---
 docs/replay.txt |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/docs/replay.txt b/docs/replay.txt
index ee6aee9861..ce97c3f72f 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -27,7 +27,7 @@ Usage of the record/replay:
  * First, record the execution with the following command line:
 qemu-system-i386 \
  -icount shift=7,rr=record,rrfile=replay.bin \
- -drive file=disk.qcow2,if=none,id=img-direct \
+ -drive file=disk.qcow2,if=none,snapshot,id=img-direct \
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
  -device ide-hd,drive=img-blkreplay \
  -netdev user,id=net1 -device rtl8139,netdev=net1 \
@@ -35,7 +35,7 @@ Usage of the record/replay:
  * After recording, you can replay it by using another command line:
 qemu-system-i386 \
  -icount shift=7,rr=replay,rrfile=replay.bin \
- -drive file=disk.qcow2,if=none,id=img-direct \
+ -drive file=disk.qcow2,if=none,snapshot,id=img-direct \
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
  -device ide-hd,drive=img-blkreplay \
  -netdev user,id=net1 -device rtl8139,netdev=net1 \
@@ -223,7 +223,7 @@ Block devices record/replay module intercepts calls of
 bdrv coroutine functions at the top of block drivers stack.
 To record and replay block operations the drive must be configured
 as following:
- -drive file=disk.qcow2,if=none,id=img-direct
+ -drive file=disk.qcow2,if=none,snapshot,id=img-direct
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay
  -device ide-hd,drive=img-blkreplay
 
@@ -252,6 +252,12 @@ This snapshot is created at start of recording and 
restored at start
 of replaying. It also can be loaded while replaying to roll back
 the execution.
 
+'snapshot' flag of the disk image must be removed to save the snapshots
+in the overlay (or original image) instead of using the temporary overlay.
+ -drive file=disk.ovl,if=none,id=img-direct
+ -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay
+ -device ide-hd,drive=img-blkreplay
+
 Use QEMU monitor to create additional snapshots. 'savevm ' command
 created the snapshot and 'loadvm ' restores it. To prevent corruption
 of the original disk image, use overlay files linked to the original images.

Re: [Qemu-devel] [PATCH v7 6/7] vhost-user-blk: Add support to reconnect backend

[Yury Kotov]

15.03.2019, 12:46, "Daniel P. Berrangé" :
> On Thu, Mar 14, 2019 at 03:31:47PM +0300, Yury Kotov wrote:
>>  Hi,
>>
>>  14.03.2019, 14:44, "Daniel P. Berrangé" :
>>  > On Thu, Mar 14, 2019 at 07:34:03AM -0400, Michael S. Tsirkin wrote:
>>  >>  On Thu, Mar 14, 2019 at 11:24:22AM +, Daniel P. Berrangé wrote:
>>  >>  > On Tue, Mar 12, 2019 at 12:49:35PM -0400, Michael S. Tsirkin wrote:
>>  >>  > > On Thu, Feb 28, 2019 at 04:53:54PM +0800, elohi...@gmail.com wrote:
>>  >>  > > > From: Xie Yongji 
>>  >>  > > >
>>  >>  > > > Since we now support the message VHOST_USER_GET_INFLIGHT_FD
>>  >>  > > > and VHOST_USER_SET_INFLIGHT_FD. The backend is able to restart
>>  >>  > > > safely because it can track inflight I/O in shared memory.
>>  >>  > > > This patch allows qemu to reconnect the backend after
>>  >>  > > > connection closed.
>>  >>  > > >
>>  >>  > > > Signed-off-by: Xie Yongji 
>>  >>  > > > Signed-off-by: Ni Xun 
>>  >>  > > > Signed-off-by: Zhang Yu 
>>  >>  > > > ---
>>  >>  > > > hw/block/vhost-user-blk.c | 205 +++--
>>  >>  > > > include/hw/virtio/vhost-user-blk.h | 4 +
>>  >>  > > > 2 files changed, 167 insertions(+), 42 deletions(-)
>>  >>  >
>>  >>  >
>>  >>  > > > static void vhost_user_blk_device_realize(DeviceState *dev, Error 
>> **errp)
>>  >>  > > > {
>>  >>  > > > VirtIODevice *vdev = VIRTIO_DEVICE(dev);
>>  >>  > > > VHostUserBlk *s = VHOST_USER_BLK(vdev);
>>  >>  > > > VhostUserState *user;
>>  >>  > > > - struct vhost_virtqueue *vqs = NULL;
>>  >>  > > > int i, ret;
>>  >>  > > > + Error *err = NULL;
>>  >>  > > >
>>  >>  > > > if (!s->chardev.chr) {
>>  >>  > > > error_setg(errp, "vhost-user-blk: chardev is mandatory");
>>  >>  > > > @@ -312,27 +442,28 @@ static void 
>> vhost_user_blk_device_realize(DeviceState *dev, Error **errp)
>>  >>  > > > }
>>  >>  > > >
>>  >>  > > > s->inflight = g_new0(struct vhost_inflight, 1);
>>  >>  > > > -
>>  >>  > > > - s->dev.nvqs = s->num_queues;
>>  >>  > > > - s->dev.vqs = g_new(struct vhost_virtqueue, s->dev.nvqs);
>>  >>  > > > - s->dev.vq_index = 0;
>>  >>  > > > - s->dev.backend_features = 0;
>>  >>  > > > - vqs = s->dev.vqs;
>>  >>  > > > -
>>  >>  > > > - vhost_dev_set_config_notifier(&s->dev, &blk_ops);
>>  >>  > > > -
>>  >>  > > > - ret = vhost_dev_init(&s->dev, s->vhost_user, 
>> VHOST_BACKEND_TYPE_USER, 0);
>>  >>  > > > - if (ret < 0) {
>>  >>  > > > - error_setg(errp, "vhost-user-blk: vhost initialization failed: 
>> %s",
>>  >>  > > > - strerror(-ret));
>>  >>  > > > - goto virtio_err;
>>  >>  > > > - }
>>  >>  > > > + s->vqs = g_new(struct vhost_virtqueue, s->num_queues);
>>  >>  > > > + s->watch = 0;
>>  >>  > > > + s->should_start = false;
>>  >>  > > > + s->connected = false;
>>  >>  > > > +
>>  >>  > > > + qemu_chr_fe_set_handlers(&s->chardev, NULL, NULL, 
>> vhost_user_blk_event,
>>  >>  > > > + NULL, (void *)dev, NULL, true);
>>  >>  > > > +
>>  >>  > > > +reconnect:
>>  >>  > > > + do {
>>  >>  > > > + if (qemu_chr_fe_wait_connected(&s->chardev, &err) < 0) {
>>  >>  > > > + error_report_err(err);
>>  >>  > > > + err = NULL;
>>  >>  > > > + sleep(1);
>>  >>  > >
>>  >>  > > Seems arbitrary. Is this basically waiting until backend will 
>> reconnect?
>>  >>  > > Why not block until event on the fd triggers?
>>  >>  > >
>>  >>  > > Also, it looks like this will just block forever with no monitor 
>> input
>>  >>  > > and no way for user to figure out what is going on short of
>>  >>  > > crashing QEMU.
>>  >>  >
>>  >>  > FWIW, the current vhost-user-net device does exactly the same thing
>>  >>  > with calling qemu_chr_fe_wait_connected during its realize() function.
>>  >>
>>  >>  Hmm yes. It doesn't sleep for an arbitrary 1 sec so less of an eyesore 
>> :)
>>  >
>>  > The sleep(1) in this patch simply needs to be removed. I think that
>>  > probably dates from when it was written against the earlier broken
>>  > version of qemu_chr_fe_wait_connected(). That would not correctly
>>  > deal with the "reconnect" flag, and so needing this loop with a sleep
>>  > in it.
>>  >
>>  > In fact the while loop can be removed as well in this code. It just
>>  > needs to call qemu_chr_fe_wait_connected() once. It is guaranteed
>>  > to have a connected peer once that returns 0.
>>  >
>>  > qemu_chr_fe_wait_connected() only returns -1 if the operating in
>>  > client mode, and it failed to connect and reconnect is *not*
>>  > requested. In such case the caller should honour the failure and
>>  > quit, not loop to retry.
>>  >
>>  > The reason vhost-user-net does a loop is because once it has a
>>  > connection it tries todo a protocol handshake, and if that
>>  > handshake fails it closes the chardev and tries to connect
>>  > again. That's not the case in this blk code os the loop is
>>  > not needed.
>>  >
>>
>>  But vhost-user-blk also has a handshake in device realize. What happens if 
>> the
>>  connection is broken during realization? IIUC we have to retry a handshake 
>> in
>>  such case just like vhost-user-

[Qemu-devel] [PATCH v14 13/25] replay: implement replay-seek command

[Pavel Dovgalyuk]

This patch adds hmp/qmp commands replay_seek/replay-seek that proceed
the execution to the specified instruction count.
The command automatically loads nearest snapshot and replays the execution
to find the desired instruction count.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Markus Armbruster 

--

v2:
 - renamed replay_seek qmp command into replay-seek
   (suggested by Eric Blake)
v7:
 - small fixes related to Markus Armbruster's review
v9:
 - changed 'step' parameter name to 'icount'
 - moved json stuff to replay.json and updated the description
   (suggested by Markus Armbruster)
v10:
 - updated the descriptions
---
 hmp-commands.hx   |   19 +
 hmp.h |1 
 qapi/replay.json  |   20 ++
 replay/replay-debugging.c |   92 +
 4 files changed, 132 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 1eb07e7bcc..88a2d32110 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1945,6 +1945,25 @@ STEXI
 @findex replay_delete_break
 Remove replay breakpoint which was previously set with replay_break.
 The command is ignored when there are no replay breakpoints.
+ETEXI
+
+{
+.name   = "replay_seek",
+.args_type  = "icount:i",
+.params = "icount",
+.help   = "replay execution to the specified instruction count",
+.cmd= hmp_replay_seek,
+},
+
+STEXI
+@item replay_seek @var{icount}
+@findex replay_seek
+Automatically proceed to the instruction count @var{icount}, when
+replaying the execution. The command automatically loads nearest
+snapshot and replays the execution to find the desired instruction.
+When there is no preceding snapshot or the execution is not replayed,
+then the command fails.
+icount for the reference may be observed with 'info replay' command.
 ETEXI
 
 {
diff --git a/hmp.h b/hmp.h
index 5f1e27a5a4..7dec5d2f07 100644
--- a/hmp.h
+++ b/hmp.h
@@ -152,5 +152,6 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict);
 void hmp_info_replay(Monitor *mon, const QDict *qdict);
 void hmp_replay_break(Monitor *mon, const QDict *qdict);
 void hmp_replay_delete_break(Monitor *mon, const QDict *qdict);
+void hmp_replay_seek(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi/replay.json b/qapi/replay.json
index 84c148cc4e..550fb2e6cf 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -99,3 +99,23 @@
 #
 ##
 { 'command': 'replay-delete-break' }
+
+##
+# @replay-seek:
+#
+# Automatically proceed to the instruction count @icount, when
+# replaying the execution. The command automatically loads nearest
+# snapshot and replays the execution to find the desired instruction.
+# When there is no preceding snapshot or the execution is not replayed,
+# then the command fails.
+# icount for the reference may be obtained with @query-replay command.
+#
+# @icount: target instruction count
+#
+# Since: 4.0
+#
+# Example:
+#
+# -> { "execute": "replay-seek", "data": { "icount": 220414 } }
+##
+{ 'command': 'replay-seek', 'data': { 'icount': 'int' } }
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index a94685e437..e3821ab1ba 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -18,6 +18,8 @@
 #include "qapi/qapi-commands-replay.h"
 #include "qapi/qmp/qdict.h"
 #include "qemu/timer.h"
+#include "block/snapshot.h"
+#include "migration/snapshot.h"
 
 void hmp_info_replay(Monitor *mon, const QDict *qdict)
 {
@@ -127,3 +129,93 @@ void hmp_replay_delete_break(Monitor *mon, const QDict 
*qdict)
 return;
 }
 }
+
+static char *replay_find_nearest_snapshot(int64_t icount,
+  int64_t *snapshot_icount)
+{
+BlockDriverState *bs;
+QEMUSnapshotInfo *sn_tab;
+QEMUSnapshotInfo *nearest = NULL;
+char *ret = NULL;
+int nb_sns, i;
+AioContext *aio_context;
+
+*snapshot_icount = -1;
+
+bs = bdrv_all_find_vmstate_bs();
+if (!bs) {
+goto fail;
+}
+aio_context = bdrv_get_aio_context(bs);
+
+aio_context_acquire(aio_context);
+nb_sns = bdrv_snapshot_list(bs, &sn_tab);
+aio_context_release(aio_context);
+
+for (i = 0; i < nb_sns; i++) {
+if (bdrv_all_find_snapshot(sn_tab[i].name, &bs) == 0) {
+if (sn_tab[i].icount != -1ULL
+&& sn_tab[i].icount <= icount
+&& (!nearest || nearest->icount < sn_tab[i].icount)) {
+nearest = &sn_tab[i];
+}
+}
+}
+if (nearest) {
+ret = g_strdup(nearest->name);
+*snapshot_icount = nearest->icount;
+}
+g_free(sn_tab);
+
+fail:
+return ret;
+}
+
+static void replay_seek(int64_t icount, QEMUTimerCB callback, Error **errp)
+{
+char *snapshot = NULL;
+int64_t snapshot_icount;
+
+if (replay_mode != REPLAY_MODE_PLAY) {
+error_setg(errp, "replay must be enabled to seek");
+return;
+}
+if (!replay_snapshot) {
+err

[Qemu-devel] [PATCH v14 08/25] migration: introduce icount field for snapshots

[Pavel Dovgalyuk]

Saving icount as a parameters of the snapshot allows navigation between
them in the execution replay scenario.
This information can be used for finding a specific snapshot for proceeding
the recorded execution to the specific moment of the time.
E.g., 'reverse step' action (introduced in one of the following patches)
needs to load the nearest snapshot which is prior to the current moment
of time .

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Markus Armbruster 

--

v2:
 - made icount in SnapshotInfo optional (suggested by Eric Blake)
v7:
 - added more comments for icount member (suggested by Markus Armbruster)
v9:
 - updated icount comment
v10:
 - updated icount comment again
---
 block/qapi.c |   18 ++
 block/qcow2-snapshot.c   |2 ++
 blockdev.c   |   10 ++
 include/block/snapshot.h |1 +
 migration/savevm.c   |5 +
 qapi/block-core.json |7 ++-
 qapi/block.json  |3 ++-
 7 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/block/qapi.c b/block/qapi.c
index 21edab34fc..d2cdd99946 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -212,6 +212,8 @@ int bdrv_query_snapshot_info_list(BlockDriverState *bs,
 info->date_nsec = sn_tab[i].date_nsec;
 info->vm_clock_sec  = sn_tab[i].vm_clock_nsec / 10;
 info->vm_clock_nsec = sn_tab[i].vm_clock_nsec % 10;
+info->icount= sn_tab[i].icount;
+info->has_icount= sn_tab[i].icount != -1ULL;
 
 info_list = g_new0(SnapshotInfoList, 1);
 info_list->value = info;
@@ -664,14 +666,15 @@ void bdrv_snapshot_dump(fprintf_function func_fprintf, 
void *f,
 QEMUSnapshotInfo *sn)
 {
 char buf1[128], date_buf[128], clock_buf[128];
+char icount_buf[128] = {0};
 struct tm tm;
 time_t ti;
 int64_t secs;
 
 if (!sn) {
 func_fprintf(f,
- "%-10s%-20s%7s%20s%15s",
- "ID", "TAG", "VM SIZE", "DATE", "VM CLOCK");
+ "%-10s%-18s%7s%20s%13s%11s",
+ "ID", "TAG", "VM SIZE", "DATE", "VM CLOCK", "ICOUNT");
 } else {
 ti = sn->date_sec;
 localtime_r(&ti, &tm);
@@ -684,13 +687,18 @@ void bdrv_snapshot_dump(fprintf_function func_fprintf, 
void *f,
  (int)((secs / 60) % 60),
  (int)(secs % 60),
  (int)((sn->vm_clock_nsec / 100) % 1000));
+if (sn->icount != -1ULL) {
+snprintf(icount_buf, sizeof(icount_buf),
+"%"PRId64, sn->icount);
+}
 func_fprintf(f,
- "%-10s%-20s%7s%20s%15s",
+ "%-10s%-18s%7s%20s%13s%11s",
  sn->id_str, sn->name,
  get_human_readable_size(buf1, sizeof(buf1),
  sn->vm_state_size),
  date_buf,
- clock_buf);
+ clock_buf,
+ icount_buf);
 }
 }
 
@@ -858,6 +866,8 @@ void bdrv_image_info_dump(fprintf_function func_fprintf, 
void *f,
 .date_nsec = elem->value->date_nsec,
 .vm_clock_nsec = elem->value->vm_clock_sec * 10ULL +
  elem->value->vm_clock_nsec,
+.icount = elem->value->has_icount ?
+  elem->value->icount : -1ULL,
 };
 
 pstrcpy(sn.id_str, sizeof(sn.id_str), elem->value->id);
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 52b535425a..e358a7581c 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -378,6 +378,7 @@ int qcow2_snapshot_create(BlockDriverState *bs, 
QEMUSnapshotInfo *sn_info)
 sn->date_sec = sn_info->date_sec;
 sn->date_nsec = sn_info->date_nsec;
 sn->vm_clock_nsec = sn_info->vm_clock_nsec;
+sn->icount = sn_info->icount;
 
 /* Allocate the L1 table of the snapshot and copy the current one there. */
 l1_table_offset = qcow2_alloc_clusters(bs, s->l1_size * sizeof(uint64_t));
@@ -709,6 +710,7 @@ int qcow2_snapshot_list(BlockDriverState *bs, 
QEMUSnapshotInfo **psn_tab)
 sn_info->date_sec = sn->date_sec;
 sn_info->date_nsec = sn->date_nsec;
 sn_info->vm_clock_nsec = sn->vm_clock_nsec;
+sn_info->icount = sn->icount;
 }
 *psn_tab = sn_tab;
 return s->nb_snapshots;
diff --git a/blockdev.c b/blockdev.c
index 53df2eb875..183fd3f7f6 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -57,6 +57,7 @@
 #include "block/trace.h"
 #include "sysemu/arch_init.h"
 #include "sysemu/qtest.h"
+#include "sysemu/replay.h"
 #include "qemu/cutils.h"
 #include "qemu/help_option.h"
 #include "qemu/throttle-options.h"
@@ -1241,6 +1242,10 @@ SnapshotInfo 
*qmp_blockdev_snapshot_delete_internal_sync(const char *device,
 info->vm_state_size = sn.vm_state_size;
 info->vm_clock_nsec = sn.vm_clock_nsec % 10;
 info->vm_clock_sec = 

Re: [Qemu-devel] [PULL 17/29] target/riscv: Convert quadrant 1 of RVXC insns to decodetree

[Bastian Koppelmann]

On 3/15/19 1:07 PM, Palmer Dabbelt wrote:

On Fri, Mar 15, 2019 at 4:19 AM Palmer Dabbelt  wrote:


On Fri, 15 Mar 2019 02:06:07 PDT (-0700), Bastian Koppelmann wrote:

Hi Alistair

On 3/14/19 9:28 PM, Alistair Francis wrote:

On Wed, Mar 13, 2019 at 7:53 AM Palmer Dabbelt 

wrote:

From: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
Signed-off-by: Bastian Koppelmann 
Signed-off-by: Peer Adelt 

This commit is the first bad commit in breaking 32-bit boot.

It looks like the jal doesn't jump to the correct address:


IN:
0x8022:  00050433  add s0,a0,zero
0x8026:  000584b3  add s1,a1,zero
0x802a:  2c79  jal ra,670  #

0x82c8


IN:
0x82c8:  0533  add a0,zero,zero
0x82cc:  8082  ret


Oops! Can you point me to the binary to reproduce this?

I think I've traced it down to something simple: in my hello world binary
I see

 20401a8c:   2a45jal 20401c3c 

in the objdump, and I see

 IN: _start
 0x20401a8c:  2a45  jal ra,432  #
0x20401c3c

but then QEMU jumps to 0x20401a9d.  I have a feeling it's something wrong
with
gen_jal() that disappeared during the cleanups that we dropped in order to
fix
the build issues.

I'm running

 ./riscv32-softmmu/qemu-system-riscv32 -machine sifive_e -kernel
~/work/sifive/freedom-e-sdk/software/hello/hello -nographic -d
in_asm,out_asm,exec,cpu -singlestep |& tee out.log

on the "hifive1" branch of github.com/palmer-dabbelt/qemu, which just has
a
PRCI fixup that I forgot about and haven't sent upstream yet (I'll do that
after this issue).  The binary should be at

 http://www.dabbelt.com/~palmer/hello.elf

and the debug log at

 http://www.dabbelt.com/~palmer/out.log

You can build the binary from github.com/sifive/freedom-e-sdk via

make software PROGRAM=hello TARGET=sifive-hifive1

using the riscv64-unknown-elf-gcc-20181127-x86_64-linux-ubuntu14 toolchain
binaries from our website (newer ones should work, but probably won't
produce
exactly the same output).

I'll poke around after grabbing some dinner...


OK, I'm pretty sure this is it:

c_jal_addiw   001 .  .  . 01 @ci #Note: parse rd and/or imm
manually


Thanks for the digging. Yes this bug was fixed in the patches we dropped 
:/. Heres the fix:


diff --git a/target/riscv/insn_trans/trans_rvc.inc.c 
b/target/riscv/insn_trans/trans_rvc.inc.c

index bcdf64d3b7..5241a8414e 100644
--- a/target/riscv/insn_trans/trans_rvc.inc.c
+++ b/target/riscv/insn_trans/trans_rvc.inc.c
@@ -88,7 +88,9 @@ static bool trans_c_jal_addiw(DisasContext *ctx, 
arg_c_jal_addiw *a)

 {
 #ifdef TARGET_RISCV32
 /* C.JAL */
-    arg_jal arg = { .rd = 1, .imm = a->imm };
+    arg_c_j tmp;
+    extract_cj(&tmp, ctx->opcode);
+    arg_jal arg = { .rd = 1, .imm = tmp.imm };
 return trans_jal(ctx, &arg);
 #else
 /* C.ADDIW */

I'll send a patch as soon as I have checked the other cases that require 
manual parsing.


Cheers,

Bastian

[Qemu-devel] [PATCH v14 20/25] replay: init rtc after enabling the replay

[Pavel Dovgalyuk]

This patch postpones the call of 'configure_rtc' function. This call
uses host clock to configure the rtc, but host clock access should be
recorded when using icount record/replay mode. Therefore now rtc
is configured after switching record/replay mode on.

Signed-off-by: Pavel Dovgalyuk 
---
 vl.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/vl.c b/vl.c
index cb79be41ce..7d3153ece2 100644
--- a/vl.c
+++ b/vl.c
@@ -2996,6 +2996,7 @@ int main(int argc, char **argv, char **envp)
 DisplayState *ds;
 QemuOpts *opts, *machine_opts;
 QemuOpts *icount_opts = NULL, *accel_opts = NULL;
+QemuOpts *rtc_opts = NULL;
 QemuOptsList *olist;
 int optind;
 const char *optarg;
@@ -3775,9 +3776,9 @@ int main(int argc, char **argv, char **envp)
 old_param = 1;
 break;
 case QEMU_OPTION_rtc:
-opts = qemu_opts_parse_noisily(qemu_find_opts("rtc"), optarg,
-   false);
-if (!opts) {
+rtc_opts = qemu_opts_parse_noisily(qemu_find_opts("rtc"),
+   optarg, false);
+if (!rtc_opts) {
 exit(1);
 }
 break;
@@ -3985,6 +3986,9 @@ int main(int argc, char **argv, char **envp)
 user_register_global_props();
 
 replay_configure(icount_opts);
+if (rtc_opts) {
+configure_rtc(rtc_opts);
+}
 
 if (incoming && !preconfig_exit_requested) {
 error_report("'preconfig' and 'incoming' options are "

[Qemu-devel] [PATCH v5 0/5] RISC-V: Add gdb xml files and gdbstub support

[Chih-Min Chao]

This is the 5th version of the patch set, based on the Jim's previous work,
 http://lists.nongnu.org/archive/html/qemu-riscv/2019-02/msg00059.html

v4 -> v5:
   - rebase 7074ab1
   - update the register xml files to gdb 8.3 
   - refine the fpu control registers, fflags/frm/fcsr index calculation
   - fix the csr offset calculcation because of tne regnum field in fpu
 xml file introducing one useless number

Jim Wilson (5):
  RISC-V: Add 32-bit gdb xml files.
  RISC-V: Add 64-bit gdb xml files.
  RISC-V: Fixes to CSR_* register macros.
  RISC-V: Add debug support for accessing CSRs.
  RISC-V: Add hooks to use the gdb xml files.

 configure   |   2 +
 gdb-xml/riscv-32bit-cpu.xml |  47 ++
 gdb-xml/riscv-32bit-csr.xml | 250 +++
 gdb-xml/riscv-32bit-fpu.xml |  50 +++
 gdb-xml/riscv-64bit-cpu.xml |  47 ++
 gdb-xml/riscv-64bit-csr.xml | 250 +++
 gdb-xml/riscv-64bit-fpu.xml |  56 +++
 target/riscv/cpu.c  |   9 +-
 target/riscv/cpu.h  |   7 +
 target/riscv/cpu_bits.h |  35 -
 target/riscv/csr.c  |  32 +++-
 target/riscv/gdbstub.c  | 350 ++--
 12 files changed, 1114 insertions(+), 21 deletions(-)
 create mode 100644 gdb-xml/riscv-32bit-cpu.xml
 create mode 100644 gdb-xml/riscv-32bit-csr.xml
 create mode 100644 gdb-xml/riscv-32bit-fpu.xml
 create mode 100644 gdb-xml/riscv-64bit-cpu.xml
 create mode 100644 gdb-xml/riscv-64bit-csr.xml
 create mode 100644 gdb-xml/riscv-64bit-fpu.xml

-- 
2.7.4

[Qemu-devel] [PATCH v14 19/25] replay: add BH oneshot event for block layer

[Pavel Dovgalyuk]

Replay is capable of recording normal BH events, but sometimes
there are single use callbacks scheduled with aio_bh_schedule_oneshot
function. This patch enables recording and replaying such callbacks.
Block layer uses these events for calling the completion function.
Replaying these calls makes the execution deterministic.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Kevin Wolf 

--

v6:
 - moved stub function to the separate file for fixing linux-user build
v10:
 - replaced all block layer aio_bh_schedule_oneshot calls
---
 block/block-backend.c|8 +---
 block/io.c   |4 ++--
 block/iscsi.c|5 +++--
 block/nfs.c  |5 +++--
 block/null.c |4 +++-
 block/nvme.c |6 --
 block/rbd.c  |5 +++--
 block/vxhs.c |5 +++--
 include/sysemu/replay.h  |3 +++
 replay/replay-events.c   |   16 
 replay/replay-internal.h |1 +
 replay/replay.c  |2 +-
 stubs/Makefile.objs  |1 +
 stubs/replay-user.c  |9 +
 14 files changed, 57 insertions(+), 17 deletions(-)
 create mode 100644 stubs/replay-user.c

diff --git a/block/block-backend.c b/block/block-backend.c
index edad02a0f2..5b200bc660 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -17,6 +17,7 @@
 #include "block/throttle-groups.h"
 #include "sysemu/blockdev.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/replay.h"
 #include "qapi/error.h"
 #include "qapi/qapi-events-block.h"
 #include "qemu/id.h"
@@ -1284,7 +1285,8 @@ BlockAIOCB *blk_abort_aio_request(BlockBackend *blk,
 acb->blk = blk;
 acb->ret = ret;
 
-aio_bh_schedule_oneshot(blk_get_aio_context(blk), error_callback_bh, acb);
+replay_bh_schedule_oneshot_event(blk_get_aio_context(blk),
+ error_callback_bh, acb);
 return &acb->common;
 }
 
@@ -1340,8 +1342,8 @@ static BlockAIOCB *blk_aio_prwv(BlockBackend *blk, 
int64_t offset, int bytes,
 
 acb->has_returned = true;
 if (acb->rwco.ret != NOT_DONE) {
-aio_bh_schedule_oneshot(blk_get_aio_context(blk),
-blk_aio_complete_bh, acb);
+replay_bh_schedule_oneshot_event(blk_get_aio_context(blk),
+ blk_aio_complete_bh, acb);
 }
 
 return &acb->common;
diff --git a/block/io.c b/block/io.c
index 866fd70d96..d2308655fd 100644
--- a/block/io.c
+++ b/block/io.c
@@ -340,8 +340,8 @@ static void coroutine_fn 
bdrv_co_yield_to_drain(BlockDriverState *bs,
 if (bs) {
 bdrv_inc_in_flight(bs);
 }
-aio_bh_schedule_oneshot(bdrv_get_aio_context(bs),
-bdrv_co_drain_bh_cb, &data);
+replay_bh_schedule_oneshot_event(bdrv_get_aio_context(bs),
+ bdrv_co_drain_bh_cb, &data);
 
 qemu_coroutine_yield();
 /* If we are resumed from some other event (such as an aio completion or a
diff --git a/block/iscsi.c b/block/iscsi.c
index f31c612d53..f896793a57 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -38,6 +38,7 @@
 #include "qemu/iov.h"
 #include "qemu/option.h"
 #include "qemu/uuid.h"
+#include "sysemu/replay.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-misc.h"
 #include "qapi/qmp/qdict.h"
@@ -279,8 +280,8 @@ iscsi_co_generic_cb(struct iscsi_context *iscsi, int status,
 
 out:
 if (iTask->co) {
-aio_bh_schedule_oneshot(iTask->iscsilun->aio_context,
- iscsi_co_generic_bh_cb, iTask);
+replay_bh_schedule_oneshot_event(iTask->iscsilun->aio_context,
+ iscsi_co_generic_bh_cb, iTask);
 } else {
 iTask->complete = 1;
 }
diff --git a/block/nfs.c b/block/nfs.c
index 531903610b..f9b5eafa9c 100644
--- a/block/nfs.c
+++ b/block/nfs.c
@@ -36,6 +36,7 @@
 #include "qemu/uri.h"
 #include "qemu/cutils.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/replay.h"
 #include "qapi/qapi-visit-block-core.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qstring.h"
@@ -256,8 +257,8 @@ nfs_co_generic_cb(int ret, struct nfs_context *nfs, void 
*data,
 if (task->ret < 0) {
 error_report("NFS Error: %s", nfs_get_error(nfs));
 }
-aio_bh_schedule_oneshot(task->client->aio_context,
-nfs_co_generic_bh_cb, task);
+replay_bh_schedule_oneshot_event(task->client->aio_context,
+ nfs_co_generic_bh_cb, task);
 }
 
 static int coroutine_fn nfs_co_preadv(BlockDriverState *bs, uint64_t offset,
diff --git a/block/null.c b/block/null.c
index a322929478..5701b4b945 100644
--- a/block/null.c
+++ b/block/null.c
@@ -16,6 +16,7 @@
 #include "qapi/qmp/qstring.h"
 #include "qemu/option.h"
 #include "block/block_int.h"
+#include "sysemu/replay.h"
 
 #define NULL_OPT_LATENCY "latency-ns"
 #define NULL_OPT_ZEROES  "read-zeroes"
@@ -178,7 +179,8 @@ static inline BlockAIOCB *null_aio_common(BlockDriverState 
*bs,

Re: [Qemu-devel] Data bus error with redeonfb on mips_fulong2e

[BALATON Zoltan]

Hello,

On Fri, 15 Mar 2019, Philippe Mathieu-Daudé wrote:

Hi Zoltan,

On 3/14/19 11:08 PM, BALATON Zoltan wrote:

On Thu, 14 Mar 2019, Aleksandar Markovic wrote:

From: BALATON Zoltan 
Subject: Data bus error with redeonfb on mips_fulong2e

Hello,

Trying to debug the Linux kernel oops with radeonfb I've added some more
debug logs and got this:

radeonfb_pci_register BEGIN
pci_host_data: pci_data_read: ati-vga: addr=04 val= len=4
PCI: Enabling device :00:06.0 ( -> 0003)
pci_host_data: pci_data_read: ati-vga: addr=04 val= len=4
pci_host_data: pci_data_write: ati-vga: addr=04 val=0003 len=4
pci_update_mappings: adding bar 0 to pci.mem @ 0x1400
pci_update_mappings: adding bar 1 to io @ 0x4000
pci_update_mappings: adding bar 2 to pci.mem @ 0x1505
pci_host_data: pci_data_read: ati-vga: addr=3c val= len=4
radeonfb_pci_register fb_base_phys=1400
radeonfb_pci_register mmio_base_phys=1505
radeonfb_pci_register request mem regions
radeonfb_pci_register map regions
radeonfb_pci_register mmio_base=90001505
Data bus error, epc == 80418e4c, ra == 80418e4c
(full oops dump in previous message but I couldn't find anything
useful in
there so omitted here)


(qemu) info mtree
memory-region: system
 - (prio 0, i/o): system
   -0fff (prio 0, ram): fulong2e.ram
   1000-1bff (prio 0, i/o): pci.mem
 100a-100b (prio 1, i/o): vga-lowmem
 2400-24ff (prio 1, ram): vga.vram
 2505-25053fff (prio 1, i/o): ati.mmregs
   1fc0-1fc7 (prio 0, rom): fulong2e.bios

The CPU bus is right, there is nothing mapped at 0x0.1505. (IO is
36bit wide on mips64).

I look at the kernel and it doesn't configure the PCI but expect the
display to be there already, so I checked the BIOS you cited in another
thread and ran the same command con the "PMON>" prompt was reached:

(qemu) info mtree
memory-region: system
 - (prio 0, i/o): system
   -0fff (prio 0, ram): fulong2e.ram
   1000-1bff (prio 0, i/o): pci.mem
 100a-100a (prio 2, i/o): alias vga.chain4
@vga.vram -
 100a-100b (prio 1, i/o): vga-lowmem
 1400-14ff (prio 1, ram): vga.vram
 1500-1503 (prio 1, rom): rtl8139.rom
 1504-1504 (prio 1, rom): ati-vga.rom
 1505-15053fff (prio 1, i/o): ati.mmregs

 ^ remapped


Thanks a lot for finding this. Indeed this makes sense that we may need to 
do further init of hardware normally done by firmware if we load kernel 
with -kernel option but I haven't thought about that. This explains the 
error we get.



$ fgrep 'pci_cfg_write ati-vga' trace.log
...
23023@1552615560.106226:pci_cfg_write ati-vga 06:0 @0x10 <- 0x408
23023@1552615560.106337:pci_cfg_write ati-vga 06:0 @0x18 <- 0x505
23023@1552615560.106823:pci_cfg_write ati-vga 06:0 @0x30 <- 0x5040001
23023@1552615560.107271:pci_cfg_write ati-vga 06:0 @0x14 <- 0xa101
23023@1552615560.119752:pci_cfg_write ati-vga 06:0 @0x4 <- 0x147

PCI_BASE_ADDRESS_0 = 0x408
PCI_BASE_ADDRESS_2 = 0x505
PCI_ROM_ADDRESS= 0x5040001
PCI_BASE_ADDRESS_1 = 0xa101
PCI_COMMAND= IO|MEMORY|MASTER|PARITY|SERR

I dunno where we have to plug that.


Maybe in  mips_fulong2e.c:main_cpu_reset() where it has a comment:
/* TODO: 2E reset stuff */ within the if (loaderparams.kernel_filename) so 
we only do it when kernel is loaded via -kernel? Can someone come up with 
a patch?



BTW you should:

/* GPU */
-dev = DEVICE(pci_create(pci_bus, -1, "ati-vga"));
+dev = DEVICE(pci_create(pci_bus, PCI_DEVFN(6, 0), "ati-vga"));


I was trying to find info on where the hardware has the ati-vga chip but 
could not find any logs showing this on-line. Now I've noticed there are 
some defines at the beginning of mips_fulong2e.c I haven't found before:


/* PCI SLOT in fulong 2e */
#define FULONG2E_VIA_SLOT5
#define FULONG2E_ATI_SLOT6
#define FULONG2E_RTL8139_SLOT7

so that's probably correct and we could use this define.

Thank you,
BALATON Zoltan

[Qemu-devel] [PATCH v14 06/25] replay: finish record/replay before closing the disks

[Pavel Dovgalyuk]

After recent updates block devices cannot be closed on qemu exit.
This happens due to the block request polling when replay is not finished.
Therefore now we stop execution recording before closing the block devices.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay.c |2 ++
 vl.c|1 +
 2 files changed, 3 insertions(+)

diff --git a/replay/replay.c b/replay/replay.c
index 8b172b2d1b..b75820a1c1 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -385,6 +385,8 @@ void replay_finish(void)
 g_free(replay_snapshot);
 replay_snapshot = NULL;
 
+replay_mode = REPLAY_MODE_NONE;
+
 replay_finish_events();
 }
 
diff --git a/vl.c b/vl.c
index ace6230b05..cb79be41ce 100644
--- a/vl.c
+++ b/vl.c
@@ -4603,6 +4603,7 @@ int main(int argc, char **argv, char **envp)
 
 /* No more vcpu or device emulation activity beyond this point */
 vm_shutdown();
+replay_finish();
 
 job_cancel_sync_all();
 bdrv_close_all();

[Qemu-devel] [PATCH v14 01/25] replay: add missing fix for internal function

[Pavel Dovgalyuk]

From: pbonz...@redhat.com 

This is a fix which was missed by patch
74c0b816adfc6aa1b01b4426fdf385e32e35cbac, which added current_step
parameter to the replay_advance_current_step function.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay-internal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/replay/replay-internal.c b/replay/replay-internal.c
index 8f87e9b957..7e6de03182 100644
--- a/replay/replay-internal.c
+++ b/replay/replay-internal.c
@@ -229,7 +229,7 @@ void replay_mutex_unlock(void)
 
 void replay_advance_current_step(uint64_t current_step)
 {
-int diff = (int)(replay_get_current_step() - replay_state.current_step);
+int diff = (int)(current_step - replay_state.current_step);
 
 /* Time can only go forward */
 assert(diff >= 0);

[Qemu-devel] [PATCH v14 09/25] replay: provide an accessor for rr filename

[Pavel Dovgalyuk]

This patch adds an accessor function for the name of the record/replay
log file. Adding an accessor instead of making variable global,
prevents accidental modification of this variable by other modules.

Signed-off-by: Pavel Dovgalyuk 
---
 include/sysemu/replay.h |2 ++
 replay/replay.c |5 +
 2 files changed, 7 insertions(+)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 3a7c58e423..b3f593f2f0 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -71,6 +71,8 @@ void replay_start(void);
 void replay_finish(void);
 /*! Adds replay blocker with the specified error description */
 void replay_add_blocker(Error *reason);
+/* Returns name of the replay log file */
+const char *replay_get_filename(void);
 
 /* Processing the instructions */
 
diff --git a/replay/replay.c b/replay/replay.c
index b75820a1c1..aa534116b5 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -394,3 +394,8 @@ void replay_add_blocker(Error *reason)
 {
 replay_blockers = g_slist_prepend(replay_blockers, reason);
 }
+
+const char *replay_get_filename(void)
+{
+return replay_filename;
+}

Re: [Qemu-devel] [PATCHv2] curses ui: add missing iconv_close calls

[Peter Maydell]

On Thu, 14 Mar 2019 at 17:26, Samuel Thibault
 wrote:
>
> The iconv_t are opened but never closed.
>
> Spotted by Coverity: CID 1399708
> Spotted by Coverity: CID 1399709
> Spotted by Coverity: CID 1399713
>
> Signed-off-by: Samuel Thibault 

Reviewed-by: Peter Maydell 

thanks
-- PMM

[Qemu-devel] [PATCH v14 17/25] gdbstub: add reverse continue support in replay mode

[Pavel Dovgalyuk]

This patch adds support of the reverse continue operation for gdbstub.
Reverse continue finds the last breakpoint that would happen in normal
execution from the beginning to the current moment.
Implementation of the reverse continue replays the execution twice:
to find the breakpoints that were hit and to seek to the last breakpoint.
Reverse continue loads the previous snapshot and tries to find the breakpoint
since that moment. If there are no such breakpoints, it proceeds to
the earlier snapshot, and so on. When no breakpoints or watchpoints were
hit at all, execution stops at the beginning of the replay log.

Signed-off-by: Pavel Dovgalyuk 
---
 cpus.c|5 +++
 exec.c|1 +
 gdbstub.c |   10 ++
 include/sysemu/replay.h   |8 +
 replay/replay-debugging.c |   71 +
 stubs/replay.c|5 +++
 6 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/cpus.c b/cpus.c
index 44d0b23435..ba4849861d 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1110,6 +1110,11 @@ static void cpu_handle_guest_debug(CPUState *cpu)
 cpu->stopped = true;
 } else {
 if (!cpu->singlestep_enabled) {
+/*
+ * Report about the breakpoint and
+ * make a single step to skip it
+ */
+replay_breakpoint();
 cpu_single_step(cpu, SSTEP_ENABLE);
 } else {
 cpu_single_step(cpu, 0);
diff --git a/exec.c b/exec.c
index 474d7bbe00..4f4351650a 100644
--- a/exec.c
+++ b/exec.c
@@ -2776,6 +2776,7 @@ static void check_watchpoint(int offset, int len, 
MemTxAttrs attrs, int flags)
  * Don't process the watchpoints when we are
  * in a reverse debugging operation.
  */
+replay_breakpoint();
 return;
 }
 if (flags == BP_MEM_READ) {
diff --git a/gdbstub.c b/gdbstub.c
index 9f987650ae..6e2dd9371f 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1444,6 +1444,14 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 put_packet(s, "E14");
 break;
 }
+case 'c':
+if (replay_reverse_continue()) {
+gdb_continue(s);
+return RS_IDLE;
+} else {
+put_packet(s, "E14");
+break;
+}
 default:
 goto unknown_command;
 }
@@ -1754,7 +1762,7 @@ static int gdb_handle_packet(GDBState *s, const char 
*line_buf)
 pstrcat(buf, sizeof(buf), ";multiprocess+");
 
 if (replay_mode == REPLAY_MODE_PLAY) {
-pstrcat(buf, sizeof(buf), ";ReverseStep+");
+pstrcat(buf, sizeof(buf), ";ReverseStep+;ReverseContinue+");
 }
 
 put_packet(s, buf);
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 533003f2b0..1d18c9b6ea 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -79,11 +79,19 @@ const char *replay_get_filename(void);
  * Returns true on success.
  */
 bool replay_reverse_step(void);
+/*
+ * Start searching the last breakpoint/watchpoint.
+ * Used by gdbstub for backwards debugging.
+ * Returns true if the process successfully started.
+ */
+bool replay_reverse_continue(void);
 /*
  * Returns true if replay module is processing
  * reverse_continue or reverse_step request
  */
 bool replay_running_debug(void);
+/* Called in reverse debugging mode to collect breakpoint information */
+void replay_breakpoint(void);
 
 /* Processing the instructions */
 
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index 3d94859b8f..abb5fe687f 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -22,6 +22,8 @@
 #include "migration/snapshot.h"
 
 static bool replay_is_debugging;
+static int64_t replay_last_breakpoint;
+static int64_t replay_last_snapshot;
 
 bool replay_running_debug(void)
 {
@@ -252,3 +254,72 @@ bool replay_reverse_step(void)
 
 return false;
 }
+
+static void replay_continue_end(void)
+{
+replay_is_debugging = false;
+vm_stop(RUN_STATE_DEBUG);
+replay_delete_break();
+}
+
+static void replay_continue_stop(void *opaque)
+{
+Error *err = NULL;
+if (replay_last_breakpoint != -1LL) {
+replay_seek(replay_last_breakpoint, replay_stop_vm_debug, &err);
+if (err) {
+error_free(err);
+replay_continue_end();
+}
+return;
+}
+/*
+ * No breakpoints since the last snapshot.
+ * Find previous snapshot and try again.
+ */
+if (replay_last_snapshot != 0) {
+replay_seek(replay_last_snapshot - 1, replay_continue_stop, &err);
+if (err) {
+error_free(err);
+replay_continue_end();
+}
+replay_last_snapshot = replay_get_current_step();
+ 

[Qemu-devel] [PATCH v14 21/25] replay: document development rules

[Pavel Dovgalyuk]

This patch introduces docs/devel/replay.txt which describes the rules
that should be followed to make virtual devices usable in record/replay mode.

Signed-off-by: Pavel Dovgalyuk 

--

v9: fixed external virtual clock description (reported by Artem Pisarenko)
---
 docs/devel/replay.txt |   46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 docs/devel/replay.txt

diff --git a/docs/devel/replay.txt b/docs/devel/replay.txt
new file mode 100644
index 00..e641c35add
--- /dev/null
+++ b/docs/devel/replay.txt
@@ -0,0 +1,46 @@
+Record/replay mechanism, that could be enabled through icount mode, expects
+the virtual devices to satisfy the following requirements.
+
+The main idea behind this document is that everything that affects
+the guest state during execution in icount mode should be deterministic.
+
+Timers
+==
+
+All virtual devices should use virtual clock for timers that change the guest
+state. Virtual clock is deterministic, therefore such timers are deterministic
+too.
+
+Virtual devices can also use realtime clock for the events that do not change
+the guest state directly. When the clock ticking should depend on VM execution
+speed, use virtual clock with EXTERNAL attribute. It is not deterministic,
+but its speed depends on the guest execution. This clock is used by
+the virtual devices (e.g., slirp routing device) that lie outside the
+replayed guest.
+
+Bottom halves
+=
+
+Bottom half callbacks, that affect the guest state, should be invoked through
+replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions.
+Their invocations are saved in record mode and synchronized with the existing
+log in replay mode.
+
+Saving/restoring the VM state
+=
+
+All fields in the device state structure (including virtual timers)
+should be restored by loadvm to the same values they had before savevm.
+
+Avoid accessing other devices' state, because the order of saving/restoring
+is not defined. It means that you should not call functions like
+'update_irq' in post_load callback. Save everything explicitly to avoid
+the dependencies that may make restoring the VM state non-deterministic.
+
+Stopping the VM
+===
+
+Stopping the guest should not interfere with its state (with the exception
+of the network connections, that could be broken by the remote timeouts).
+VM can be stopped at any moment of replay by the user. Restarting the VM
+after that stop should not break the replay by the unneeded guest state change.

[Qemu-devel] [PATCH 2/2] keymaps: regenerate keymaps

[Gerd Hoffmann]

Pick up the config updates.  Also add a few keys to the maps which
got a QKeyCode assigned since the last time we generated the maps
(Hiragana_Katakana, Muhenkan).  Sync will xkbcommon updates.

Signed-off-by: Gerd Hoffmann 
---
 pc-bios/keymaps/ar| 53 +++
 pc-bios/keymaps/bepo  | 10 ++--
 pc-bios/keymaps/cz| 10 ++--
 pc-bios/keymaps/da| 10 ++--
 pc-bios/keymaps/de| 39 +++
 pc-bios/keymaps/de-ch | 10 ++--
 pc-bios/keymaps/en-gb | 10 ++--
 pc-bios/keymaps/en-us | 10 ++--
 pc-bios/keymaps/es| 10 ++--
 pc-bios/keymaps/et| 10 ++--
 pc-bios/keymaps/fi| 10 ++--
 pc-bios/keymaps/fo| 10 ++--
 pc-bios/keymaps/fr| 36 +
 pc-bios/keymaps/fr-be | 10 ++--
 pc-bios/keymaps/fr-ca | 10 ++--
 pc-bios/keymaps/fr-ch | 10 ++--
 pc-bios/keymaps/hr| 10 ++--
 pc-bios/keymaps/hu| 10 ++--
 pc-bios/keymaps/is| 10 ++--
 pc-bios/keymaps/it| 10 ++--
 pc-bios/keymaps/ja| 10 ++--
 pc-bios/keymaps/lt| 10 ++--
 pc-bios/keymaps/lv| 10 ++--
 pc-bios/keymaps/mk| 10 ++--
 pc-bios/keymaps/nl| 10 ++--
 pc-bios/keymaps/no| 10 ++--
 pc-bios/keymaps/pl| 10 ++--
 pc-bios/keymaps/pt| 10 ++--
 pc-bios/keymaps/pt-br | 10 ++--
 pc-bios/keymaps/ru| 10 ++--
 pc-bios/keymaps/th| 10 ++--
 pc-bios/keymaps/tr| 10 ++--
 32 files changed, 321 insertions(+), 97 deletions(-)

diff --git a/pc-bios/keymaps/ar b/pc-bios/keymaps/ar
index a763c9a02713..f62b297c54f4 100644
--- a/pc-bios/keymaps/ar
+++ b/pc-bios/keymaps/ar
@@ -36,50 +36,65 @@ Escape 0x01
 # evdev 2 (0x2), QKeyCode "1", number 0x2
 1 0x02
 exclam 0x02 shift
+Arabic_1 0x02 altgr
 
 # evdev 3 (0x3), QKeyCode "2", number 0x3
 2 0x03
 at 0x03 shift
+Arabic_2 0x03 altgr
 
 # evdev 4 (0x4), QKeyCode "3", number 0x4
 3 0x04
 numbersign 0x04 shift
+Arabic_3 0x04 altgr
 
 # evdev 5 (0x5), QKeyCode "4", number 0x5
 4 0x05
 dollar 0x05 shift
+Arabic_4 0x05 altgr
 
 # evdev 6 (0x6), QKeyCode "5", number 0x6
 5 0x06
 percent 0x06 shift
+Arabic_5 0x06 altgr
+U2030 0x06 shift altgr
 
 # evdev 7 (0x7), QKeyCode "6", number 0x7
 6 0x07
 asciicircum 0x07 shift
+Arabic_6 0x07 altgr
 
 # evdev 8 (0x8), QKeyCode "7", number 0x8
 7 0x08
 ampersand 0x08 shift
+Arabic_7 0x08 altgr
 
 # evdev 9 (0x9), QKeyCode "8", number 0x9
 8 0x09
 asterisk 0x09 shift
+Arabic_8 0x09 altgr
 
 # evdev 10 (0xa), QKeyCode "9", number 0xa
 9 0x0a
 parenright 0x0a shift
+Arabic_9 0x0a altgr
 
 # evdev 11 (0xb), QKeyCode "0", number 0xb
 0 0x0b
 parenleft 0x0b shift
+Arabic_0 0x0b altgr
 
 # evdev 12 (0xc), QKeyCode "minus", number 0xc
 minus 0x0c
 underscore 0x0c shift
+endash 0x0c altgr
+U2011 0x0c shift altgr
 
 # evdev 13 (0xd), QKeyCode "equal", number 0xd
 equal 0x0d
 plus 0x0d shift
+notequal 0x0d altgr
+approxeq 0x0d shift altgr
 
 # evdev 14 (0xe), QKeyCode "backspace", number 0xe
 BackSpace 0x0e
@@ -91,18 +106,22 @@ ISO_Left_Tab 0x0f shift
 # evdev 16 (0x10), QKeyCode "q", number 0x10
 Arabic_dad 0x10
 Arabic_fatha 0x10 shift
+U2066 0x10 shift altgr
 
 # evdev 17 (0x11), QKeyCode "w", number 0x11
 Arabic_sad 0x11
 Arabic_fathatan 0x11 shift
+U2067 0x11 shift altgr
 
 # evdev 18 (0x12), QKeyCode "e", number 0x12
 Arabic_theh 0x12
 Arabic_damma 0x12 shift
+U2068 0x12 shift altgr
 
 # evdev 19 (0x13), QKeyCode "r", number 0x13
 Arabic_qaf 0x13
 Arabic_dammatan 0x13 shift
+U2069 0x13 shift altgr
 
 # evdev 20 (0x14), QKeyCode "t", number 0x14
 Arabic_feh 0x14
@@ -112,14 +131,17 @@ Arabic_veh 0x14 altgr
 # evdev 21 (0x15), QKeyCode "y", number 0x15
 Arabic_ghain 0x15
 Arabic_hamzaunderalef 0x15 shift
+U202A 0x15 shift altgr
 
 # evdev 22 (0x16), QKeyCode "u", number 0x16
 Arabic_ain 0x16
 grave 0x16 shift
+U202B 0x16 shift altgr
 
 # evdev 23 (0x17), QKeyCode "i", number 0x17
 Arabic_ha 0x17
 division 0x17 shift
+U202C 0x17 shift altgr
 
 # evdev 24 (0x18), QKeyCode "o", number 0x18
 Arabic_khah 0x18
@@ -128,15 +150,18 @@ multiply 0x18 shift
 # evdev 25 (0x19), QKeyCode "p", number 0x19
 Arabic_hah 0x19
 Arabic_semicolon 0x19 shift
+U200E 0x19 shift altgr
 
 # evdev 26 (0x1a), QKeyCode "bracket_left", number 0x1a
 Arabic_jeem 0x1a
 less 0x1a shift
 Arabic_tcheh 0x1a altgr
+U200F 0x1a shift altgr
 
 # evdev 27 (0x1b), QKeyCode "bracket_right", number 0x1b
 Arabic_dal 0x1b
 greater 0x1b shift
+U061C 0x1b shift altgr
 
 # evdev 28 (0x1c), QKeyCode "ret", number 0x1c
 Return 0x1c
@@ -177,6 +202,7 @@ Arabic_tatweel 0x24 shift
 # evdev 37 (0x25), QKeyCode "k", number 0x25
 Arabic_noon 0x25
 Arabic_comma 0x25 shift
+U066B 0x25 altgr
 
 # evdev 38 (0x26), QKeyCode "l", number 0x26
 Arabic_meem 0x26
@@ -190,27 +216,35 @@ Arabic_gaf 0x27 altgr
 # evdev 40 (0x28), QKeyCode "apostrophe", number 0x28
 Arabic_tah 0x28
 quotedbl 0x28 shift
+U27E9 0x28 altgr
+U200D 0x28 shift altgr
 
 # evdev 41 (0x29), QKeyCode "grave_accent", number 0x29
 Arabic_thal 0x29