RE: QEMU for Qualcomm Hexagon - KVM Forum talk and code available

[Taylor Simpson]

That is correct.

Once you register on developer.qualcomm.com, you can download the Hexagon SDK 
version 3.4.3.  Note that there are different downloads for Linux and Windows 
hosts.

Once you have installed the SDK, look for the document bundle in the following 
location
/tools/HEXAGON_Tools/8.3.02/Documents/Hexagon_Document_Bundle.pdf
That PDF file is a container for a bunch of other documents.  If you want to 
read more about the Hexagon architecture, look at the following
V67 Programmer's Reference Manual
V66 HVX Programmer's Reference Manual
The version on the quic github implements these.  Note that HVX stands for 
Hexagon Vector eXtensions.  It is an optional set of instructions that operate 
on 128-byte vectors.

IIRC, the revng github implements up to V62.  Alessandro or Niccolo can confirm.

Note that the toolchain in that installation generates code for the standalone 
runtime or the RTOS, not Linux that the quic qemu generates.  However, they 
should run on the revng version.  In the coming weeks, we'll work on setting up 
a container to build the toolchain that will generate binaries that will run on 
the quic version.

If anyone has any more questions, I'm happy to answer them.

Taylor


-Original Message-
From: Philippe Mathieu-Daudé 
Sent: Friday, November 1, 2019 1:30 PM
To: Taylor Simpson ; qemu-devel@nongnu.org
Cc: Alessandro Di Federico ; ni...@rev.ng; Niccolò Izzo 

Subject: Re: QEMU for Qualcomm Hexagon - KVM Forum talk and code available



Hi Taylor,

On 10/25/19 6:26 PM, Taylor Simpson wrote:
> We would like inform the you that we will be doing a talk at the KVM
> Forum next week on QEMU for Qualcomm Hexagon.  Alessandro Di Federico,
> Niccolo Izzo, and I have been working independently on implementations
> of the Hexagon target.  We plan to merge the implementations, have a
> community review, and ultimately have Hexagon be an official target in
> QEMU.  Our code is available at the links below.
>
> _https://github.com/revng/qemu-hexagon_
>
> _https://github.com/quic/qemu_
>
> If anyone has any feedback on the code as it stands today or guidance
> on how best to prepare it for review, please let us know.

Is your target the 'Hexagon Series 600', with documentation available here?
https://developer.qualcomm.com/software/hexagon-dsp-sdk/tools

Regards,

Phil.

Re: [PATCH v2] q800: fix I/O memory map

[Philippe Mathieu-Daudé]

On 11/2/19 10:42 PM, Laurent Vivier wrote:

Linux kernel 5.4 will introduce a new memory map for SWIM device.
(aee6bff1c325 ("m68k: mac: Revisit floppy disc controller base addresses"))

Until this release all MMIO are mapped between 0x50f0 and 0x50f4,
but it appears that for real hardware 0x50f0 is not the base address:
the MMIO region spans 0x5000 through 0x6000, and 0x5004 through
0x5400 is repeated images of 0x5000 to 0x5004.

Fixed: 04e7ca8d0f ("hw/m68k: define Macintosh Quadra 800")
Signed-off-by: Laurent Vivier 
---

Notes:
 v2: add some constant definitions
 allocate a bloc of memory to stores all I/O MemoryRegion

  hw/m68k/q800.c | 40 
  1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 2b4842f8c6..822bd13d36 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -60,14 +60,19 @@
  #define MACH_MAC3
  #define Q800_MAC_CPU_ID 2
  
-#define VIA_BASE  0x50f0

-#define SONIC_PROM_BASE   0x50f08000
-#define SONIC_BASE0x50f0a000
-#define SCC_BASE  0x50f0c020
-#define ESP_BASE  0x50f1
-#define ESP_PDMA  0x50f10100
-#define ASC_BASE  0x50F14000
-#define SWIM_BASE 0x50F1E000
+#define IO_BASE   0x5000
+#define IO_SLICE  0x0004
+#define IO_SIZE   0x0400
+
+#define VIA_BASE  (IO_BASE + 0x0)


Good idea.


+#define SONIC_PROM_BASE   (IO_BASE + 0x08000)
+#define SONIC_BASE(IO_BASE + 0x0a000)
+#define SCC_BASE  (IO_BASE + 0x0c020)
+#define ESP_BASE  (IO_BASE + 0x1)
+#define ESP_PDMA  (IO_BASE + 0x10100)
+#define ASC_BASE  (IO_BASE + 0x14000)
+#define SWIM_BASE (IO_BASE + 0x1E000)
+
  #define NUBUS_SUPER_SLOT_BASE 0x6000
  #define NUBUS_SLOT_BASE   0xf000
  
@@ -135,6 +140,9 @@ static void q800_init(MachineState *machine)

  int32_t initrd_size;
  MemoryRegion *rom;
  MemoryRegion *ram;
+MemoryRegion *io;
+const int io_slice_nb = (IO_SIZE / IO_SLICE) - 1;
+int i;
  ram_addr_t ram_size = machine->ram_size;
  const char *kernel_filename = machine->kernel_filename;
  const char *initrd_filename = machine->initrd_filename;
@@ -163,10 +171,26 @@ static void q800_init(MachineState *machine)
  cpu = M68K_CPU(cpu_create(machine->cpu_type));
  qemu_register_reset(main_cpu_reset, cpu);
  
+/* RAM */

  ram = g_malloc(sizeof(*ram));
  memory_region_init_ram(ram, NULL, "m68k_mac.ram", ram_size, &error_abort);
  memory_region_add_subregion(get_system_memory(), 0, ram);
  
+/*

+ * Memory from IO_BASE to IO_BASE + IO_SLICE is repeated
+ * from IO_BASE + IO_SLICE to IO_BASE + IO_SIZE
+ */
+io = g_new(MemoryRegion, io_slice_nb);
+for (i = 0; i < io_slice_nb; i++) {
+char *name = g_strdup_printf("mac_m68k.io[%d]", i + 1);
+
+memory_region_init_alias(io + i, NULL, name, get_system_memory(),


We usually use &io[i], anyway:
Reviewed-by: Philippe Mathieu-Daudé 


+ IO_BASE, IO_SLICE);
+memory_region_add_subregion(get_system_memory(),
+IO_BASE + (i + 1) * IO_SLICE, io + i);
+g_free(name);
+}
+
  /* IRQ Glue */
  
  irq = g_new0(GLUEState, 1);

[PULL 2/2] tests/fw_cfg: Test 'reboot-timeout=-1' special value

[Philippe Mathieu-Daudé]

The special value -1 means "don't reboot" for QEMU/libvirt.
Add a trivial test.

Reviewed-by: Dr. David Alan Gilbert 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/fw_cfg-test.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/tests/fw_cfg-test.c b/tests/fw_cfg-test.c
index 1d3147f821..5dc807ba23 100644
--- a/tests/fw_cfg-test.c
+++ b/tests/fw_cfg-test.c
@@ -194,6 +194,26 @@ static void test_fw_cfg_reboot_timeout(void)
 qtest_quit(s);
 }
 
+static void test_fw_cfg_no_reboot_timeout(void)
+{
+QFWCFG *fw_cfg;
+QTestState *s;
+uint32_t reboot_timeout = 0;
+size_t filesize;
+
+/* Special value -1 means "don't reboot" */
+s = qtest_init("-boot reboot-timeout=-1");
+fw_cfg = pc_fw_cfg_init(s);
+
+filesize = qfw_cfg_get_file(fw_cfg, "etc/boot-fail-wait",
+&reboot_timeout, sizeof(reboot_timeout));
+g_assert_cmpint(filesize, ==, sizeof(reboot_timeout));
+reboot_timeout = le32_to_cpu(reboot_timeout);
+g_assert_cmpint(reboot_timeout, ==, UINT32_MAX);
+pc_fw_cfg_uninit(fw_cfg);
+qtest_quit(s);
+}
+
 static void test_fw_cfg_splash_time(void)
 {
 QFWCFG *fw_cfg;
@@ -233,6 +253,7 @@ int main(int argc, char **argv)
 qtest_add_func("fw_cfg/numa", test_fw_cfg_numa);
 qtest_add_func("fw_cfg/boot_menu", test_fw_cfg_boot_menu);
 qtest_add_func("fw_cfg/reboot_timeout", test_fw_cfg_reboot_timeout);
+qtest_add_func("fw_cfg/no_reboot_timeout", test_fw_cfg_no_reboot_timeout);
 qtest_add_func("fw_cfg/splash_time", test_fw_cfg_splash_time);
 
 return g_test_run();
-- 
2.21.0

[PULL 0/2] fw_cfg for-4.2-soft-freeze patches

[Philippe Mathieu-Daudé]

Hi Peter,

One fw_cfg fix from David Gilbert.

The following changes since commit f3cad9c6dbd4b9877232c44bf2dd877353a73209:

  iotests: Remove 130 from the "auto" group (2019-10-31 11:04:10 +)

are available in the Git repository at:

  https://gitlab.com/philmd/qemu.git tags/fw_cfg-next-pull-request

for you to fetch changes up to eda4e62cc2f5d12fcedcf799a5a3f9eba855ad77:

  tests/fw_cfg: Test 'reboot-timeout=-1' special value (2019-11-01 19:19:24 
+0100)


Fix the fw_cfg reboot-timeout=-1 special value, add a test for it.



Dr. David Alan Gilbert (1):
  fw_cfg: Allow reboot-timeout=-1 again

Philippe Mathieu-Daudé (1):
  tests/fw_cfg: Test 'reboot-timeout=-1' special value

 hw/nvram/fw_cfg.c   |  7 ---
 tests/fw_cfg-test.c | 21 +
 2 files changed, 25 insertions(+), 3 deletions(-)

-- 
2.21.0

[PULL 1/2] fw_cfg: Allow reboot-timeout=-1 again

[Philippe Mathieu-Daudé]

From: "Dr. David Alan Gilbert" 

Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout
to only allow the range 0..65535; however both qemu and libvirt document
the special value -1  to mean don't reboot.
Allow it again.

Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout error checking")
RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20191025165706.177653-1-dgilb...@redhat.com>
Suggested-by: Laszlo Ersek 
Message-Id: <37ac197c-f20e-dd05-ff6a-13a2171c7...@redhat.com>
[PMD: Applied Laszlo's suggestions]
Reviewed-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/nvram/fw_cfg.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index aef1727250..14f8437983 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -237,7 +237,7 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 static void fw_cfg_reboot(FWCfgState *s)
 {
 const char *reboot_timeout = NULL;
-int64_t rt_val = -1;
+uint64_t rt_val = -1;
 uint32_t rt_le32;
 
 /* get user configuration */
@@ -247,10 +247,11 @@ static void fw_cfg_reboot(FWCfgState *s)
 
 if (reboot_timeout) {
 rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
+
 /* validate the input */
-if (rt_val < 0 || rt_val > 0x) {
+if (rt_val > 0x && rt_val != (uint64_t)-1) {
 error_report("reboot timeout is invalid,"
- "it should be a value between 0 and 65535");
+ "it should be a value between -1 and 65535");
 exit(1);
 }
 }
-- 
2.21.0

Re: [PATCH v3] fdc/i8257: implement verify transfer mode

[Hervé Poussineau]

Le 01/11/2019 à 17:55, Sven Schnelle a écrit :

While working on the Tulip driver i tried to write some Teledisk images to
a floppy image which didn't work. Turned out that Teledisk checks the written
data by issuing a READ command to the FDC but running the DMA controller
in VERIFY mode. As we ignored the DMA request in that case, the DMA transfer
never finished, and Teledisk reported an error.

The i8257 spec says about verify transfers:

3) DMA verify, which does not actually involve the transfer of data. When an
8257 channel is in the DMA verify mode, it will respond the same as described
for transfer operations, except that no memory or I/O read/write control signals
will be generated.

Hervé proposed to remove all the dma_mode_ok stuff from fdc to have a more
clear boundary between DMA and FDC, so this patch also does that.

Suggested-by: Hervé Poussineau 
Signed-off-by: Sven Schnelle 
---
  hw/block/fdc.c   | 61 +---
  hw/dma/i8257.c   | 20 ++-
  include/hw/isa/isa.h |  1 -
  3 files changed, 31 insertions(+), 51 deletions(-)


Reviewed-by: Hervé Poussineau 

Re: [PATCH v3 5/6] hppa: Add emulation of Artist graphics

[Mark Cave-Ayland]

On 01/11/2019 21:59, Sven Schnelle wrote:

> On Sat, Oct 26, 2019 at 07:54:40PM +0200, Sven Schnelle wrote:
>> Hi Mark,
>>
>> On Sat, Oct 26, 2019 at 10:35:20AM +0100, Mark Cave-Ayland wrote:
>>
 However, the VRAM in Artist is not really exposed to the Host. Instead,
 there's the Chipset inbetween that can do byte swapping (Colormap is LE,
 VRAM is BE) and Bit-to-Byte/Word/Dword conversion. For example you could
 write 0x55 into that VRAM region, and the chipset would expand that to
 VRAM Bytes: 00 01 00 01 00 01 00 01. And to make it even worse emulation
 wise it can also do different encodings for Read or Write accesses, and
 mask out certain bits of the data. So after trying to convert it to the
 "dirty bitmap" API i decided to just leave it as it is. The CPU load
 used by the display update code is usually < 1%, so it's ok for me.
>>>
>>> Wow that sounds that some interesting hardware(!). Does it make sense to 
>>> model the
>>> behaviour of the chipset separately using a proxy MemoryRegion similar to 
>>> virtio i.e.
>>> introduce an intermediate IO MemoryRegion that does the swapping and then 
>>> forward it
>>> onto the VRAM MemoryRegion?
>>
>> Thanks for the pointer, i'll check whether that would work. For now i
>> think i'll remove the Artist patch from the series, so we can apply the
>> other patches, and i'll re-submit Artist when it's done. I guess the
>> rewrite to use a MemRegion is a bit bigger. But i would to get the other
>> patches in especially the LASI Stuff as both Helge and i have a lot of
>> stuff depending on that.
> 
> I've looked into it again and changed my mind. There are at least the 
> following
> functions that the Artist chip does before a Read/Write is passed to/from 
> VRAM:
> 
> - endianess conversion (actually configurable via some register, but i don't
>   know how and hardwired it depending on CMAP / FB access)
> 
> - The Address passed on the System bus are the X/Y coordinates added to the FB
>   base address in the selected buffer instead of the VRAM offset for pixel 
> data.
>   I think that's configurable via the some registers, but i don't know how.
>   Unfortunately there's absolutely no documentation about Artist available and
>   everything was developed by reverse engineering.
> 
> - bitmap to Byte/Word conversion (not implemented yet for the VRAM window, 
> only
>   for the I/O register window)
> 
> So in my opinion it's way to much effort to squeeze all of that into the 
> memory
> space, and it is not really a Memory range that's just behind a bus bridge.

Hi Sven,

Certainly in some cases it isn't possible to model devices in QEMU exactly as 
real
hardware, although I think that some of the ideas above could be used to 
improve the
implementation without too much extra effort.

Then again from my work on QEMU I completely understand that sometimes this can 
be
difficult with older, more esoteric devices. Ultimately after review that 
decision
has to come from the maintainer(s) for the relevant devices/machines, so I 
guess that
would be Richard and/or Gerd in this case?


ATB,

Mark.

Re: Sparc Solaris 10

[Mark Cave-Ayland]

On 02/11/2019 19:56, Philippe Mathieu-Daudé wrote:

> Cc'ing the SPARC maintainers.
> 
> On 11/1/19 4:49 AM, Zainuddin AR wrote:
>> Hi,
>>
>> I like to find to find out if you have a working qemu on solaris 10 or 11. I 
>> have
>> tried the qemu-sun4vniagara but without networking. Is the networking 
>> support for
>> niagara version available?

I'm not particularly familiar with sun4v, however I'm not aware of any current 
work
in this area. Do you know which network driver is typically used with sun4v?


ATB,

Mark.

Re: [PATCH v3 5/6] hppa: Add emulation of Artist graphics

[Sven Schnelle]

Hi Mark,

On Sun, Nov 03, 2019 at 08:56:43PM +, Mark Cave-Ayland wrote:
> On 01/11/2019 21:59, Sven Schnelle wrote:
> 
> > On Sat, Oct 26, 2019 at 07:54:40PM +0200, Sven Schnelle wrote:
> >> Hi Mark,
> >>
> >> On Sat, Oct 26, 2019 at 10:35:20AM +0100, Mark Cave-Ayland wrote:
> >>
>  However, the VRAM in Artist is not really exposed to the Host. Instead,
>  there's the Chipset inbetween that can do byte swapping (Colormap is LE,
>  VRAM is BE) and Bit-to-Byte/Word/Dword conversion. For example you could
>  write 0x55 into that VRAM region, and the chipset would expand that to
>  VRAM Bytes: 00 01 00 01 00 01 00 01. And to make it even worse emulation
>  wise it can also do different encodings for Read or Write accesses, and
>  mask out certain bits of the data. So after trying to convert it to the
>  "dirty bitmap" API i decided to just leave it as it is. The CPU load
>  used by the display update code is usually < 1%, so it's ok for me.
> >>>
> >>> Wow that sounds that some interesting hardware(!). Does it make sense to 
> >>> model the
> >>> behaviour of the chipset separately using a proxy MemoryRegion similar to 
> >>> virtio i.e.
> >>> introduce an intermediate IO MemoryRegion that does the swapping and then 
> >>> forward it
> >>> onto the VRAM MemoryRegion?
> >>
> >> Thanks for the pointer, i'll check whether that would work. For now i
> >> think i'll remove the Artist patch from the series, so we can apply the
> >> other patches, and i'll re-submit Artist when it's done. I guess the
> >> rewrite to use a MemRegion is a bit bigger. But i would to get the other
> >> patches in especially the LASI Stuff as both Helge and i have a lot of
> >> stuff depending on that.
> > 
> > I've looked into it again and changed my mind. There are at least the 
> > following
> > functions that the Artist chip does before a Read/Write is passed to/from 
> > VRAM:
> > 
> > - endianess conversion (actually configurable via some register, but i don't
> >   know how and hardwired it depending on CMAP / FB access)
> > 
> > - The Address passed on the System bus are the X/Y coordinates added to the 
> > FB
> >   base address in the selected buffer instead of the VRAM offset for pixel 
> > data.
> >   I think that's configurable via the some registers, but i don't know how.
> >   Unfortunately there's absolutely no documentation about Artist available 
> > and
> >   everything was developed by reverse engineering.
> > 
> > - bitmap to Byte/Word conversion (not implemented yet for the VRAM window, 
> > only
> >   for the I/O register window)
> > 
> > So in my opinion it's way to much effort to squeeze all of that into the 
> > memory
> > space, and it is not really a Memory range that's just behind a bus bridge.
> 
> Hi Sven,
> 
> Certainly in some cases it isn't possible to model devices in QEMU exactly as 
> real
> hardware, although I think that some of the ideas above could be used to 
> improve the
> implementation without too much extra effort.
> 
> Then again from my work on QEMU I completely understand that sometimes this 
> can be
> difficult with older, more esoteric devices. Ultimately after review that 
> decision
> has to come from the maintainer(s) for the relevant devices/machines, so I 
> guess that
> would be Richard and/or Gerd in this case?

I think that would be Richard. I rewrote the code to at least use the generic
framebuffer functions now, and added dirty memory tracking. I'm still not happy
with all the endianess conversion that are going on, but without any
Documentation about chip it's impossible to say how the chip really works.

Regards
Sven

[PATCH v4 2/6] hppa: Add support for LASI chip with i82596 NIC

[Sven Schnelle]

From: Helge Deller 

LASI is a built-in multi-I/O chip which supports serial, parallel,
network (Intel i82596 Apricot), sound and other functionalities.
LASI has been used in many HP PARISC machines.
This patch adds the necessary parts to allow Linux and HP-UX to detect
LASI and the network card.

Signed-off-by: Helge Deller 
Signed-off-by: Sven Schnelle 
---
 MAINTAINERS |   2 +
 hw/hppa/Kconfig |   1 +
 hw/hppa/Makefile.objs   |   2 +-
 hw/hppa/hppa_sys.h  |   2 +
 hw/hppa/lasi.c  | 360 ++
 hw/hppa/machine.c   |   8 +-
 hw/hppa/trace-events|   5 +
 hw/net/Kconfig  |   7 +
 hw/net/Makefile.objs|   2 +
 hw/net/i82596.c | 734 
 hw/net/i82596.h |  55 +++
 hw/net/lasi_i82596.c| 188 +
 hw/net/trace-events |  14 +
 include/hw/net/lasi_82596.h |  29 ++
 14 files changed, 1407 insertions(+), 2 deletions(-)
 create mode 100644 hw/hppa/lasi.c
 create mode 100644 hw/net/i82596.c
 create mode 100644 hw/net/i82596.h
 create mode 100644 hw/net/lasi_i82596.c
 create mode 100644 include/hw/net/lasi_82596.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f8abbddab..c4cdd761ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -178,6 +178,8 @@ S: Maintained
 F: target/hppa/
 F: hw/hppa/
 F: disas/hppa.c
+F: hw/net/*i82596*
+F: include/hw/net/lasi_82596.h
 
 LM32 TCG CPUs
 M: Michael Walle 
diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index 6e5d74a825..2a7b38d6d6 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -10,3 +10,4 @@ config DINO
 select IDE_CMD646
 select MC146818RTC
 select LSI_SCSI_PCI
+select LASI_82596
diff --git a/hw/hppa/Makefile.objs b/hw/hppa/Makefile.objs
index 67838f50a3..eac3467d8a 100644
--- a/hw/hppa/Makefile.objs
+++ b/hw/hppa/Makefile.objs
@@ -1 +1 @@
-obj-$(CONFIG_DINO) += pci.o machine.o dino.o
+obj-$(CONFIG_DINO) += pci.o machine.o dino.o lasi.o
diff --git a/hw/hppa/hppa_sys.h b/hw/hppa/hppa_sys.h
index 43d25d21fc..d99b5dd87b 100644
--- a/hw/hppa/hppa_sys.h
+++ b/hw/hppa/hppa_sys.h
@@ -11,6 +11,8 @@
 #include "hppa_hardware.h"
 
 PCIBus *dino_init(MemoryRegion *, qemu_irq *, qemu_irq *);
+DeviceState *lasi_init(MemoryRegion *);
+#define enable_lasi_lan()   0
 
 #define TYPE_DINO_PCI_HOST_BRIDGE "dino-pcihost"
 
diff --git a/hw/hppa/lasi.c b/hw/hppa/lasi.c
new file mode 100644
index 00..51752589f3
--- /dev/null
+++ b/hw/hppa/lasi.c
@@ -0,0 +1,360 @@
+/*
+ * HP-PARISC Lasi chipset emulation.
+ *
+ * (C) 2019 by Helge Deller 
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ * Documentation available at:
+ * https://parisc.wiki.kernel.org/images-parisc/7/79/Lasi_ers.pdf
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "cpu.h"
+#include "trace.h"
+#include "hw/hw.h"
+#include "hw/irq.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/runstate.h"
+#include "hppa_sys.h"
+#include "hw/net/lasi_82596.h"
+#include "hw/char/parallel.h"
+#include "hw/char/serial.h"
+#include "exec/address-spaces.h"
+#include "migration/vmstate.h"
+
+#define TYPE_LASI_CHIP "lasi-chip"
+
+#define LASI_IRR0x00/* RO */
+#define LASI_IMR0x04
+#define LASI_IPR0x08
+#define LASI_ICR0x0c
+#define LASI_IAR0x10
+
+#define LASI_PCR0x0C000 /* LASI Power Control register */
+#define LASI_ERRLOG 0x0C004 /* LASI Error Logging register */
+#define LASI_VER0x0C008 /* LASI Version Control register */
+#define LASI_IORESET0x0C00C /* LASI I/O Reset register */
+#define LASI_AMR0x0C010 /* LASI Arbitration Mask register */
+#define LASI_IO_CONF0x7FFFE /* LASI primary configuration register */
+#define LASI_IO_CONF2   0x7 /* LASI secondary configuration register */
+
+#define LASI_BIT(x) (1ul << (x))
+#define LASI_IRQ_BITS   (LASI_BIT(5) | LASI_BIT(7) | LASI_BIT(8) | LASI_BIT(9) 
\
+| LASI_BIT(13) | LASI_BIT(14) | LASI_BIT(16) | LASI_BIT(17) \
+| LASI_BIT(18) | LASI_BIT(19) | LASI_BIT(20) | LASI_BIT(21) \
+| LASI_BIT(26))
+
+#define ICR_BUS_ERROR_BIT  LASI_BIT(8)  /* bit 8 in ICR */
+#define ICR_TOC_BITLASI_BIT(1)  /* bit 1 in ICR */
+
+#define LASI_CHIP(obj) \
+OBJECT_CHECK(LasiState, (obj), TYPE_LASI_CHIP)
+
+#define LASI_RTC_HPA(LASI_HPA + 0x9000)
+
+typedef struct LasiState {
+PCIHostState parent_obj;
+
+uint32_t irr;
+uint32_t imr;
+uint32_t ipr;
+uint32_t icr;
+uint32_t iar;
+
+uint32_t errlog;
+uint32_t amr;
+uint32_t rtc;
+time_t rtc_ref;
+
+MemoryRegion this_mem;
+} LasiState;
+
+static bool lasi_chip_mem_valid(void *opaque, hwaddr addr,
+unsigned size, bool is_write,
+MemTxAttrs attrs)
+{
+bool ret = false;
+
+switch (addr) {
+case LASI_IRR:
+case LASI_IMR:
+case LASI_IPR:
+case LASI_IC

[PATCH v4 3/6] ps2: accept 'Set Key Make and Break' commands

[Sven Schnelle]

HP-UX sends both the 'Set key make and break (0xfc) and
'Set all key typematic make and break' (0xfa). QEMU response
with 'Resend' as it doesn't handle these commands. HP-UX than
reports an PS/2 max retransmission exceeded error. Add these
commands and just reply with ACK.

Signed-off-by: Sven Schnelle 
---
 hw/input/ps2.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 67f92f6112..0b671b6339 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -49,6 +49,8 @@
 #define KBD_CMD_RESET_DISABLE  0xF5/* reset and disable scanning */
 #define KBD_CMD_RESET_ENABLE   0xF6/* reset and enable scanning */
 #define KBD_CMD_RESET  0xFF/* Reset */
+#define KBD_CMD_SET_MAKE_BREAK  0xFC/* Set Make and Break mode */
+#define KBD_CMD_SET_TYPEMATIC   0xFA/* Set Typematic Make and Break mode */
 
 /* Keyboard Replies */
 #define KBD_REPLY_POR  0xAA/* Power on reset */
@@ -573,6 +575,7 @@ void ps2_write_keyboard(void *opaque, int val)
 case KBD_CMD_SCANCODE:
 case KBD_CMD_SET_LEDS:
 case KBD_CMD_SET_RATE:
+case KBD_CMD_SET_MAKE_BREAK:
 s->common.write_cmd = val;
 ps2_queue(&s->common, KBD_REPLY_ACK);
 break;
@@ -592,11 +595,18 @@ void ps2_write_keyboard(void *opaque, int val)
 KBD_REPLY_ACK,
 KBD_REPLY_POR);
 break;
+case KBD_CMD_SET_TYPEMATIC:
+ps2_queue(&s->common, KBD_REPLY_ACK);
+break;
 default:
 ps2_queue(&s->common, KBD_REPLY_RESEND);
 break;
 }
 break;
+case KBD_CMD_SET_MAKE_BREAK:
+ps2_queue(&s->common, KBD_REPLY_ACK);
+s->common.write_cmd = -1;
+break;
 case KBD_CMD_SCANCODE:
 if (val == 0) {
 if (s->common.queue.count <= PS2_QUEUE_SIZE - 2) {
-- 
2.24.0.rc2

[PATCH v4 0/6] HPPA: i82596, PS/2 and graphics emulation

[Sven Schnelle]

Hi,

these series adds quite a lot to the HPPA emulation in QEMU:
i82596 emulation from Helge, PS/2 and Artist graphics emulation.

See https://parisc.wiki.kernel.org/index.php/Qemu for a few screenshots
of QEMU running a X11/CDE session in HP-UX.

changes in v4:
 - introduce Artist-internal address space
 - rewrite screen update functions to use the generic framebuffer routines
 - use dirty bitmap code to not always redraw the whole screen

Changes in v3:
 - use BIT() macro in gsc_to_pci_forwarding()
 - fix version id in vm state
 - fix an error in the PS/2 KBD_CMD_SET_MAKE_BREAK implementation

Changes in v2:
 - dropped 'hppa: remove ISA region' as that patch requires some more work
 - added shortlog to seabios update
 - use const and MAKE_64BIT_MASK in dino.c

Regards,
Sven

Helge Deller (2):
  hw/hppa/dino.c: Improve emulation of Dino PCI chip
  hppa: Add support for LASI chip with i82596 NIC

Sven Schnelle (4):
  ps2: accept 'Set Key Make and Break' commands
  hppa: add emulation of LASI PS2 controllers
  hppa: Add emulation of Artist graphics
  seabios-hppa: update to latest version

 MAINTAINERS |4 +-
 hw/display/Kconfig  |4 +
 hw/display/Makefile.objs|1 +
 hw/display/artist.c | 1449 +++
 hw/display/trace-events |9 +
 hw/hppa/Kconfig |3 +
 hw/hppa/Makefile.objs   |2 +-
 hw/hppa/dino.c  |   97 ++-
 hw/hppa/hppa_hardware.h |1 +
 hw/hppa/hppa_sys.h  |2 +
 hw/hppa/lasi.c  |  368 +
 hw/hppa/machine.c   |   17 +-
 hw/hppa/trace-events|   10 +
 hw/input/Kconfig|3 +
 hw/input/Makefile.objs  |1 +
 hw/input/lasips2.c  |  289 +++
 hw/input/ps2.c  |   15 +
 hw/input/trace-events   |5 +
 hw/net/Kconfig  |7 +
 hw/net/Makefile.objs|2 +
 hw/net/i82596.c |  734 ++
 hw/net/i82596.h |   55 ++
 hw/net/lasi_i82596.c|  188 +
 hw/net/trace-events |   14 +
 include/hw/input/lasips2.h  |   16 +
 include/hw/input/ps2.h  |1 +
 include/hw/net/lasi_82596.h |   29 +
 pc-bios/hppa-firmware.img   |  Bin 783724 -> 772876 bytes
 roms/seabios-hppa   |2 +-
 29 files changed, 3310 insertions(+), 18 deletions(-)
 create mode 100644 hw/display/artist.c
 create mode 100644 hw/hppa/lasi.c
 create mode 100644 hw/input/lasips2.c
 create mode 100644 hw/net/i82596.c
 create mode 100644 hw/net/i82596.h
 create mode 100644 hw/net/lasi_i82596.c
 create mode 100644 include/hw/input/lasips2.h
 create mode 100644 include/hw/net/lasi_82596.h

-- 
2.24.0.rc2

[PATCH v4 5/6] hppa: Add emulation of Artist graphics

[Sven Schnelle]

This adds emulation of Artist graphics good enough
to get a Text console on both Linux and HP-UX. The
X11 server from HP-UX also works.

Signed-off-by: Sven Schnelle 
---
 hw/display/Kconfig   |4 +
 hw/display/Makefile.objs |1 +
 hw/display/artist.c  | 1449 ++
 hw/display/trace-events  |9 +
 hw/hppa/Kconfig  |1 +
 hw/hppa/hppa_hardware.h  |1 +
 hw/hppa/machine.c|9 +
 7 files changed, 1474 insertions(+)
 create mode 100644 hw/display/artist.c

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index c500d1fc6d..15d59e10dc 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -91,6 +91,10 @@ config TCX
 config CG3
 bool
 
+config ARTIST
+bool
+select FRAMEBUFFER
+
 config VGA
 bool
 
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index f2182e3bef..5f03dfdcc4 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -40,6 +40,7 @@ common-obj-$(CONFIG_SM501) += sm501.o
 common-obj-$(CONFIG_TCX) += tcx.o
 common-obj-$(CONFIG_CG3) += cg3.o
 common-obj-$(CONFIG_NEXTCUBE) += next-fb.o
+common-obj-$(CONFIG_ARTIST) += artist.o
 
 obj-$(CONFIG_VGA) += vga.o
 
diff --git a/hw/display/artist.c b/hw/display/artist.c
new file mode 100644
index 00..1d6c7d5d76
--- /dev/null
+++ b/hw/display/artist.c
@@ -0,0 +1,1449 @@
+/*
+ * QEMU HP Artist Emulation
+ *
+ * Copyright (c) 2019 Sven Schnelle 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "qemu/typedefs.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "hw/sysbus.h"
+#include "hw/loader.h"
+#include "hw/qdev-core.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+#include "ui/console.h"
+#include "trace.h"
+#include "hw/display/framebuffer.h"
+
+#define TYPE_ARTIST "artist"
+#define ARTIST(obj) OBJECT_CHECK(ARTISTState, (obj), TYPE_ARTIST)
+
+#ifdef HOST_WORDS_BIGENDIAN
+#define ROP8OFF(_i) (3 - (_i))
+#else
+#define ROP8OFF
+#endif
+
+struct vram_buffer {
+MemoryRegion mr;
+uint8_t *data;
+int size;
+int width;
+int height;
+};
+
+typedef struct ARTISTState {
+SysBusDevice parent_obj;
+
+QemuConsole *con;
+MemoryRegion vram_mem;
+MemoryRegion mem_as_root;
+MemoryRegion reg;
+MemoryRegionSection fbsection;
+
+void *vram_int_mr;
+AddressSpace as;
+
+struct vram_buffer vram_buffer[16];
+
+uint16_t width;
+uint16_t height;
+uint16_t depth;
+
+uint32_t fg_color;
+uint32_t bg_color;
+
+uint32_t vram_char_y;
+uint32_t vram_bitmask;
+
+uint32_t vram_start;
+uint32_t vram_pos;
+
+uint32_t vram_size;
+
+uint32_t blockmove_source;
+uint32_t blockmove_dest;
+uint32_t blockmove_size;
+
+uint32_t line_size;
+uint32_t line_end;
+uint32_t line_xy;
+uint32_t line_pattern_start;
+uint32_t line_pattern_skip;
+
+uint32_t cursor_pos;
+
+uint32_t cursor_height;
+uint32_t cursor_width;
+
+uint32_t plane_mask;
+
+uint32_t reg_100080;
+uint32_t reg_300200;
+uint32_t reg_300208;
+uint32_t reg_300218;
+
+uint32_t cmap_bm_access;
+uint32_t dst_bm_access;
+uint32_t src_bm_access;
+uint32_t control_plane;
+uint32_t transfer_data;
+uint32_t image_bitmap_op;
+
+uint32_t font_write1;
+uint32_t font_write2;
+uint32_t font_write_pos_y;
+
+int draw_line_pattern;
+} ARTISTState;
+
+typedef enum {
+ARTIST_BUFFER_AP = 1,
+ARTIST_BUFFER_OVERLAY = 2,
+ARTIST_BUFFER_CURSOR1 = 6,
+ARTIST_BUFFER_CURSOR2 = 7,
+ARTIST_BUFFER_ATTRIBUTE = 13,
+ARTIST_BUFFER_CMAP = 15,
+} artist_buffer_t;
+
+typedef enum {
+VRAM_IDX = 0x1004a0,
+VRAM_BITMASK = 0x1005a0,
+VRAM_WRITE_INCR_X = 0x100600,
+VRAM_WRITE_INCR_X2 = 0x100604,
+VRAM_WRITE_INCR_Y = 0x100620,
+VRAM_START = 0x100800,
+BLOCK_MOVE_SIZE = 0x100804,
+BLOCK_MOVE_SOURCE = 0x100808,
+TRANSFER_DATA = 0x100820,
+FONT_WRITE_INCR_Y = 0x1008a0,
+VRAM_START_TRIGGER = 0x100a00,
+VRAM_SIZE_TRIGGER = 0x100a04,
+FONT_WRITE_START = 0x100aa0,
+BLOCK_MOVE_DEST_TRIGGER = 0x100b00,
+BLOCK_MOVE_SIZE_TRIGGER = 0x100b04,
+LINE_XY = 0x100ccc,
+PATTERN_LINE_START = 0x100ecc,
+LINE_SIZE = 0x100e04,
+LINE_END = 0x100e44,
+CMAP_BM_ACCESS = 0x118000,
+DST_BM_ACCESS = 0x118004,
+SRC_BM_ACCESS = 0x118008,
+CONTROL_PLANE = 0x11800c,
+FG_COLOR = 0x118010,
+BG_COLOR = 0x118014,
+PLANE_MASK = 0x118018,
+IMAGE_BITMAP_OP = 0x11801c,
+CURSOR_POS = 0x300100,
+CURSOR_CTRL = 0x300104,
+} artist_reg_t;
+
+typedef enum {
+ARTIST_ROP_CLEAR = 0,
+ARTIST_ROP_COPY = 3,
+ARTIST_ROP_XOR = 6,
+ARTIST_ROP_NOT_DST = 10,
+ARTIST_ROP_SET = 15,
+} artist_rop_t;
+
+#define REG_NAME(_x) case _x: return " "#_x;
+static

[PATCH v4 1/6] hw/hppa/dino.c: Improve emulation of Dino PCI chip

[Sven Schnelle]

From: Helge Deller 

The tests of the dino chip with the Online-diagnostics CD
("ODE DINOTEST") now succeeds.
Additionally add some qemu trace events.

Signed-off-by: Helge Deller 
Signed-off-by: Sven Schnelle 
Reviewed-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS  |  2 +-
 hw/hppa/dino.c   | 97 +---
 hw/hppa/trace-events |  5 +++
 3 files changed, 89 insertions(+), 15 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 92961faa0e..7f8abbddab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -874,7 +874,7 @@ F: hw/*/etraxfs_*.c
 
 HP-PARISC Machines
 --
-Dino
+HP B160L
 M: Richard Henderson 
 R: Helge Deller 
 S: Odd Fixes
diff --git a/hw/hppa/dino.c b/hw/hppa/dino.c
index ab6969b45f..9797a7f0d9 100644
--- a/hw/hppa/dino.c
+++ b/hw/hppa/dino.c
@@ -1,7 +1,7 @@
 /*
- * HP-PARISC Dino PCI chipset emulation.
+ * HP-PARISC Dino PCI chipset emulation, as in B160L and similiar machines
  *
- * (C) 2017 by Helge Deller 
+ * (C) 2017-2019 by Helge Deller 
  *
  * This work is licensed under the GNU GPL license version 2 or later.
  *
@@ -21,6 +21,7 @@
 #include "migration/vmstate.h"
 #include "hppa_sys.h"
 #include "exec/address-spaces.h"
+#include "trace.h"
 
 
 #define TYPE_DINO_PCI_HOST_BRIDGE "dino-pcihost"
@@ -82,11 +83,28 @@
 #define DINO_PCI_HOST_BRIDGE(obj) \
 OBJECT_CHECK(DinoState, (obj), TYPE_DINO_PCI_HOST_BRIDGE)
 
+#define DINO800_REGS ((DINO_TLTIM - DINO_GMASK) / 4)
+static const uint32_t reg800_keep_bits[DINO800_REGS] = {
+MAKE_64BIT_MASK(0, 1),
+MAKE_64BIT_MASK(0, 7),
+MAKE_64BIT_MASK(0, 7),
+MAKE_64BIT_MASK(0, 8),
+MAKE_64BIT_MASK(0, 7),
+MAKE_64BIT_MASK(0, 9),
+MAKE_64BIT_MASK(0, 32),
+MAKE_64BIT_MASK(0, 8),
+MAKE_64BIT_MASK(0, 30),
+MAKE_64BIT_MASK(0, 25),
+MAKE_64BIT_MASK(0, 22),
+MAKE_64BIT_MASK(0, 9),
+};
+
 typedef struct DinoState {
 PCIHostState parent_obj;
 
 /* PCI_CONFIG_ADDR is parent_obj.config_reg, via pci_host_conf_be_ops,
so that we can map PCI_CONFIG_DATA to pci_host_data_be_ops.  */
+uint32_t config_reg_dino; /* keep original copy, including 2 lowest bits */
 
 uint32_t iar0;
 uint32_t iar1;
@@ -94,8 +112,12 @@ typedef struct DinoState {
 uint32_t ipr;
 uint32_t icr;
 uint32_t ilr;
+uint32_t io_fbb_en;
 uint32_t io_addr_en;
 uint32_t io_control;
+uint32_t toc_addr;
+
+uint32_t reg800[DINO800_REGS];
 
 MemoryRegion this_mem;
 MemoryRegion pci_mem;
@@ -106,8 +128,6 @@ typedef struct DinoState {
 MemoryRegion bm_ram_alias;
 MemoryRegion bm_pci_alias;
 MemoryRegion bm_cpu_alias;
-
-MemoryRegion cpu0_eir_mem;
 } DinoState;
 
 /*
@@ -122,6 +142,8 @@ static void gsc_to_pci_forwarding(DinoState *s)
 tmp = extract32(s->io_control, 7, 2);
 enabled = (tmp == 0x01);
 io_addr_en = s->io_addr_en;
+/* Mask out first (=firmware) and last (=Dino) areas. */
+io_addr_en &= ~(BIT(31) | BIT(0));
 
 memory_region_transaction_begin();
 for (i = 1; i < 31; i++) {
@@ -142,6 +164,8 @@ static bool dino_chip_mem_valid(void *opaque, hwaddr addr,
 unsigned size, bool is_write,
 MemTxAttrs attrs)
 {
+bool ret = false;
+
 switch (addr) {
 case DINO_IAR0:
 case DINO_IAR1:
@@ -152,16 +176,22 @@ static bool dino_chip_mem_valid(void *opaque, hwaddr addr,
 case DINO_ICR:
 case DINO_ILR:
 case DINO_IO_CONTROL:
+case DINO_IO_FBB_EN:
 case DINO_IO_ADDR_EN:
 case DINO_PCI_IO_DATA:
-return true;
+case DINO_TOC_ADDR:
+case DINO_GMASK ... DINO_TLTIM:
+ret = true;
+break;
 case DINO_PCI_IO_DATA + 2:
-return size <= 2;
+ret = (size <= 2);
+break;
 case DINO_PCI_IO_DATA + 1:
 case DINO_PCI_IO_DATA + 3:
-return size == 1;
+ret = (size == 1);
 }
-return false;
+trace_dino_chip_mem_valid(addr, ret);
+return ret;
 }
 
 static MemTxResult dino_chip_read_with_attrs(void *opaque, hwaddr addr,
@@ -194,6 +224,9 @@ static MemTxResult dino_chip_read_with_attrs(void *opaque, 
hwaddr addr,
 }
 break;
 
+case DINO_IO_FBB_EN:
+val = s->io_fbb_en;
+break;
 case DINO_IO_ADDR_EN:
 val = s->io_addr_en;
 break;
@@ -227,12 +260,28 @@ static MemTxResult dino_chip_read_with_attrs(void 
*opaque, hwaddr addr,
 case DINO_IRR1:
 val = s->ilr & s->imr & s->icr;
 break;
+case DINO_TOC_ADDR:
+val = s->toc_addr;
+break;
+case DINO_GMASK ... DINO_TLTIM:
+val = s->reg800[(addr - DINO_GMASK) / 4];
+if (addr == DINO_PAMR) {
+val &= ~0x01;  /* LSB is hardwired to 0 */
+}
+if (addr == DINO_MLTIM) {
+val &= ~0x07;  /* 3 LSB are hardwired to 0 */
+}
+if (addr == DINO_BRDG

[PATCH v4 4/6] hppa: add emulation of LASI PS2 controllers

[Sven Schnelle]

Signed-off-by: Sven Schnelle 
---
 hw/hppa/Kconfig|   1 +
 hw/hppa/lasi.c |  10 +-
 hw/input/Kconfig   |   3 +
 hw/input/Makefile.objs |   1 +
 hw/input/lasips2.c | 289 +
 hw/input/ps2.c |   5 +
 hw/input/trace-events  |   5 +
 include/hw/input/lasips2.h |  16 ++
 include/hw/input/ps2.h |   1 +
 9 files changed, 330 insertions(+), 1 deletion(-)
 create mode 100644 hw/input/lasips2.c
 create mode 100644 include/hw/input/lasips2.h

diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index 2a7b38d6d6..7f9be7f25c 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -11,3 +11,4 @@ config DINO
 select MC146818RTC
 select LSI_SCSI_PCI
 select LASI_82596
+select LASIPS2
diff --git a/hw/hppa/lasi.c b/hw/hppa/lasi.c
index 51752589f3..d8d03f95c0 100644
--- a/hw/hppa/lasi.c
+++ b/hw/hppa/lasi.c
@@ -22,6 +22,7 @@
 #include "hw/net/lasi_82596.h"
 #include "hw/char/parallel.h"
 #include "hw/char/serial.h"
+#include "hw/input/lasips2.h"
 #include "exec/address-spaces.h"
 #include "migration/vmstate.h"
 
@@ -324,6 +325,7 @@ DeviceState *lasi_init(MemoryRegion *address_space)
  lpt_irq, parallel_hds[0]);
 
 /* Real time clock (RTC), it's only one 32-bit counter @9000 */
+
 s->rtc = time(NULL);
 s->rtc_ref = 0;
 
@@ -333,8 +335,14 @@ DeviceState *lasi_init(MemoryRegion *address_space)
 lasi_get_irq(LASI_UART_HPA));
 serial_mm_init(address_space, LASI_UART_HPA + 0x800, 0,
 serial_irq, 800 / 16,
-serial_hd(1), DEVICE_NATIVE_ENDIAN);
+serial_hd(0), DEVICE_NATIVE_ENDIAN);
 }
+
+/* PS/2 Keyboard/Mouse */
+qemu_irq ps2kbd_irq = qemu_allocate_irq(lasi_set_irq, s,
+lasi_get_irq(LASI_PS2KBD_HPA));
+lasips2_init(address_space, LASI_PS2KBD_HPA,  ps2kbd_irq);
+
 return dev;
 }
 
diff --git a/hw/input/Kconfig b/hw/input/Kconfig
index 287f08887b..25c77a1b87 100644
--- a/hw/input/Kconfig
+++ b/hw/input/Kconfig
@@ -41,3 +41,6 @@ config VHOST_USER_INPUT
 
 config TSC210X
 bool
+
+config LASIPS2
+select PS2
diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
index a1bc502ed0..f98f635685 100644
--- a/hw/input/Makefile.objs
+++ b/hw/input/Makefile.objs
@@ -15,3 +15,4 @@ common-obj-$(CONFIG_VHOST_USER_INPUT) += vhost-user-input.o
 obj-$(CONFIG_MILKYMIST) += milkymist-softusb.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_keypad.o
 obj-$(CONFIG_TSC210X) += tsc210x.o
+obj-$(CONFIG_LASIPS2) += lasips2.o
diff --git a/hw/input/lasips2.c b/hw/input/lasips2.c
new file mode 100644
index 00..1943671d1e
--- /dev/null
+++ b/hw/input/lasips2.c
@@ -0,0 +1,289 @@
+/*
+ * QEMU HP Lasi PS/2 interface emulation
+ *
+ * Copyright (c) 2019 Sven Schnelle
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/qdev-properties.h"
+#include "hw/hw.h"
+#include "hw/input/ps2.h"
+#include "hw/input/lasips2.h"
+#include "hw/sysbus.h"
+#include "exec/hwaddr.h"
+#include "sysemu/sysemu.h"
+#include "trace.h"
+#include "exec/address-spaces.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+struct LASIPS2State;
+typedef struct LASIPS2Port {
+struct LASIPS2State *parent;
+MemoryRegion reg;
+void *dev;
+uint8_t id;
+uint8_t control;
+uint8_t buf;
+bool loopback_rbne;
+bool irq;
+} LASIPS2Port;
+
+typedef struct LASIPS2State {
+LASIPS2Port kbd;
+LASIPS2Port mouse;
+qemu_irq irq;
+} LASIPS2State;
+
+static const VMStateDescription vmstate_lasips2 = {
+.name = "lasips2",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(kbd.control, LASIPS2State),
+VMSTATE_UINT8(kbd.id, LASIPS2State),
+VMSTATE_BOOL(kbd.irq, LASIPS2State),
+VMSTATE_UINT8(mouse.control, LASIPS2State),
+VMSTATE_UINT8(mouse.id, LAS

Re: [PATCH] mos6522: fix T1 and T2 timers

[Mark Cave-Ayland]

On 02/11/2019 15:49, Laurent Vivier wrote:

> With the Quadra 800 emulation, mos6522 timers processing can consume
> until 70% of the host CPU time with an idle guest (I guess the problem
> should also happen with PowerMac emulation).
> 
> On a recent system, it can be painless (except if you look at top), but
> on an old host like a PowerMac G5 the guest kernel can be terribly slow
> during the boot sequence (for instance, unpacking initramfs can take 15
> seconds rather than only 3 seconds).
> 
> We can avoid this CPU overload by enabling QEMU internal timers only if
> the mos6522 counter interrupts are enabled. Sometime the guest kernel
> wants to read the counters values, but we don't need the timers to
> update the counters.
> 
> With this patch applied, an idle Q800 consumes only 3% of host CPU time
> (and the guest can boot in a decent time).
> 
> Signed-off-by: Laurent Vivier 
> ---
>  hw/misc/mos6522.c | 67 ---
>  1 file changed, 52 insertions(+), 15 deletions(-)
> 
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index 57f13db266..aa3bfe1afd 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -38,8 +38,10 @@
>  
>  /* XXX: implement all timer modes */
>  
> -static void mos6522_timer_update(MOS6522State *s, MOS6522Timer *ti,
> - int64_t current_time);
> +static void mos6522_timer1_update(MOS6522State *s, MOS6522Timer *ti,
> +  int64_t current_time);
> +static void mos6522_timer2_update(MOS6522State *s, MOS6522Timer *ti,
> +  int64_t current_time);
>  
>  static void mos6522_update_irq(MOS6522State *s)
>  {
> @@ -98,7 +100,11 @@ static void set_counter(MOS6522State *s, MOS6522Timer 
> *ti, unsigned int val)
>  trace_mos6522_set_counter(1 + ti->index, val);
>  ti->load_time = get_load_time(s, ti);
>  ti->counter_value = val;
> -mos6522_timer_update(s, ti, ti->load_time);
> +if (ti->index == 0) {
> +mos6522_timer1_update(s, ti, ti->load_time);
> +} else {
> +mos6522_timer2_update(s, ti, ti->load_time);
> +}
>  }
>  
>  static int64_t get_next_irq_time(MOS6522State *s, MOS6522Timer *ti,
> @@ -130,19 +136,34 @@ static int64_t get_next_irq_time(MOS6522State *s, 
> MOS6522Timer *ti,
>  trace_mos6522_get_next_irq_time(ti->latch, d, next_time - d);
>  next_time = muldiv64(next_time, NANOSECONDS_PER_SECOND, ti->frequency) +
>   ti->load_time;
> +
>  if (next_time <= current_time) {
>  next_time = current_time + 1;
>  }
>  return next_time;
>  }
>  
> -static void mos6522_timer_update(MOS6522State *s, MOS6522Timer *ti,
> +static void mos6522_timer1_update(MOS6522State *s, MOS6522Timer *ti,
> + int64_t current_time)
> +{
> +if (!ti->timer) {
> +return;
> +}
> +if ((s->ier & T1_INT) == 0 || (s->acr & T1MODE) != T1MODE_CONT) {
> +timer_del(ti->timer);
> +} else {
> +ti->next_irq_time = get_next_irq_time(s, ti, current_time);
> +timer_mod(ti->timer, ti->next_irq_time);
> +}
> +}
> +
> +static void mos6522_timer2_update(MOS6522State *s, MOS6522Timer *ti,
>   int64_t current_time)
>  {
>  if (!ti->timer) {
>  return;
>  }
> -if (ti->index == 0 && (s->acr & T1MODE) != T1MODE_CONT) {
> +if ((s->ier & T2_INT) == 0) {
>  timer_del(ti->timer);
>  } else {
>  ti->next_irq_time = get_next_irq_time(s, ti, current_time);
> @@ -155,7 +176,7 @@ static void mos6522_timer1(void *opaque)
>  MOS6522State *s = opaque;
>  MOS6522Timer *ti = &s->timers[0];
>  
> -mos6522_timer_update(s, ti, ti->next_irq_time);
> +mos6522_timer1_update(s, ti, ti->next_irq_time);
>  s->ifr |= T1_INT;
>  mos6522_update_irq(s);
>  }
> @@ -165,7 +186,7 @@ static void mos6522_timer2(void *opaque)
>  MOS6522State *s = opaque;
>  MOS6522Timer *ti = &s->timers[1];
>  
> -mos6522_timer_update(s, ti, ti->next_irq_time);
> +mos6522_timer2_update(s, ti, ti->next_irq_time);
>  s->ifr |= T2_INT;
>  mos6522_update_irq(s);
>  }
> @@ -204,7 +225,16 @@ uint64_t mos6522_read(void *opaque, hwaddr addr, 
> unsigned size)
>  {
>  MOS6522State *s = opaque;
>  uint32_t val;
> +int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>  
> +if (now >= s->timers[0].next_irq_time) {
> +mos6522_timer1_update(s, &s->timers[0], now);
> +s->ifr |= T1_INT;
> +}
> +if (now >= s->timers[1].next_irq_time) {
> +mos6522_timer2_update(s, &s->timers[1], now);
> +s->ifr |= T2_INT;
> +}
>  switch (addr) {
>  case VIA_REG_B:
>  val = s->b;
> @@ -299,8 +329,8 @@ void mos6522_write(void *opaque, hwaddr addr, uint64_t 
> val, unsigned size)
>  break;
>  case VIA_REG_T1CL:
>  s->timers[0].latch = (s->timers[0].latch & 0xff00) | val;
> -mos652

Re: [PATCH] mos6522: fix T1 and T2 timers

[David Gibson]

On Sat, Nov 02, 2019 at 04:49:19PM +0100, Laurent Vivier wrote:
> With the Quadra 800 emulation, mos6522 timers processing can consume
> until 70% of the host CPU time with an idle guest (I guess the problem
> should also happen with PowerMac emulation).
> 
> On a recent system, it can be painless (except if you look at top), but
> on an old host like a PowerMac G5 the guest kernel can be terribly slow
> during the boot sequence (for instance, unpacking initramfs can take 15
> seconds rather than only 3 seconds).
> 
> We can avoid this CPU overload by enabling QEMU internal timers only if
> the mos6522 counter interrupts are enabled. Sometime the guest kernel
> wants to read the counters values, but we don't need the timers to
> update the counters.
> 
> With this patch applied, an idle Q800 consumes only 3% of host CPU time
> (and the guest can boot in a decent time).
> 
> Signed-off-by: Laurent Vivier 

Applied to ppc-for-4.2, thanks.

> ---
>  hw/misc/mos6522.c | 67 ---
>  1 file changed, 52 insertions(+), 15 deletions(-)
> 
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index 57f13db266..aa3bfe1afd 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -38,8 +38,10 @@
>  
>  /* XXX: implement all timer modes */
>  
> -static void mos6522_timer_update(MOS6522State *s, MOS6522Timer *ti,
> - int64_t current_time);
> +static void mos6522_timer1_update(MOS6522State *s, MOS6522Timer *ti,
> +  int64_t current_time);
> +static void mos6522_timer2_update(MOS6522State *s, MOS6522Timer *ti,
> +  int64_t current_time);
>  
>  static void mos6522_update_irq(MOS6522State *s)
>  {
> @@ -98,7 +100,11 @@ static void set_counter(MOS6522State *s, MOS6522Timer 
> *ti, unsigned int val)
>  trace_mos6522_set_counter(1 + ti->index, val);
>  ti->load_time = get_load_time(s, ti);
>  ti->counter_value = val;
> -mos6522_timer_update(s, ti, ti->load_time);
> +if (ti->index == 0) {
> +mos6522_timer1_update(s, ti, ti->load_time);
> +} else {
> +mos6522_timer2_update(s, ti, ti->load_time);
> +}
>  }
>  
>  static int64_t get_next_irq_time(MOS6522State *s, MOS6522Timer *ti,
> @@ -130,19 +136,34 @@ static int64_t get_next_irq_time(MOS6522State *s, 
> MOS6522Timer *ti,
>  trace_mos6522_get_next_irq_time(ti->latch, d, next_time - d);
>  next_time = muldiv64(next_time, NANOSECONDS_PER_SECOND, ti->frequency) +
>   ti->load_time;
> +
>  if (next_time <= current_time) {
>  next_time = current_time + 1;
>  }
>  return next_time;
>  }
>  
> -static void mos6522_timer_update(MOS6522State *s, MOS6522Timer *ti,
> +static void mos6522_timer1_update(MOS6522State *s, MOS6522Timer *ti,
> + int64_t current_time)
> +{
> +if (!ti->timer) {
> +return;
> +}
> +if ((s->ier & T1_INT) == 0 || (s->acr & T1MODE) != T1MODE_CONT) {
> +timer_del(ti->timer);
> +} else {
> +ti->next_irq_time = get_next_irq_time(s, ti, current_time);
> +timer_mod(ti->timer, ti->next_irq_time);
> +}
> +}
> +
> +static void mos6522_timer2_update(MOS6522State *s, MOS6522Timer *ti,
>   int64_t current_time)
>  {
>  if (!ti->timer) {
>  return;
>  }
> -if (ti->index == 0 && (s->acr & T1MODE) != T1MODE_CONT) {
> +if ((s->ier & T2_INT) == 0) {
>  timer_del(ti->timer);
>  } else {
>  ti->next_irq_time = get_next_irq_time(s, ti, current_time);
> @@ -155,7 +176,7 @@ static void mos6522_timer1(void *opaque)
>  MOS6522State *s = opaque;
>  MOS6522Timer *ti = &s->timers[0];
>  
> -mos6522_timer_update(s, ti, ti->next_irq_time);
> +mos6522_timer1_update(s, ti, ti->next_irq_time);
>  s->ifr |= T1_INT;
>  mos6522_update_irq(s);
>  }
> @@ -165,7 +186,7 @@ static void mos6522_timer2(void *opaque)
>  MOS6522State *s = opaque;
>  MOS6522Timer *ti = &s->timers[1];
>  
> -mos6522_timer_update(s, ti, ti->next_irq_time);
> +mos6522_timer2_update(s, ti, ti->next_irq_time);
>  s->ifr |= T2_INT;
>  mos6522_update_irq(s);
>  }
> @@ -204,7 +225,16 @@ uint64_t mos6522_read(void *opaque, hwaddr addr, 
> unsigned size)
>  {
>  MOS6522State *s = opaque;
>  uint32_t val;
> +int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>  
> +if (now >= s->timers[0].next_irq_time) {
> +mos6522_timer1_update(s, &s->timers[0], now);
> +s->ifr |= T1_INT;
> +}
> +if (now >= s->timers[1].next_irq_time) {
> +mos6522_timer2_update(s, &s->timers[1], now);
> +s->ifr |= T2_INT;
> +}
>  switch (addr) {
>  case VIA_REG_B:
>  val = s->b;
> @@ -299,8 +329,8 @@ void mos6522_write(void *opaque, hwaddr addr, uint64_t 
> val, unsigned size)
>  break;
>  case VIA_REG_T1CL:
>  s->timers[0].latch = 

[Bug 1851095] Re: [feature request] awareness of instructions that are well emulated

[Shawn Landden]

ok, here is a double precision exponent implementation that works on
arm32 hardware, but fails in qemu with the wrong checksum.
https://github.com/shawnl/zig-libmvec/blob/master/exp.zig

You need to build zig with the above patch-set.

I guess I am starting from a pessimistic perspective, where I have only
ever seen SIMD work with arm64 emulation (which is quite new), and am
sorry for that.

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

Title:
  [feature request] awareness of instructions that are well emulated

Status in QEMU:
  New

Bug description:
  While qemu's scalar emulation tends to be excellent, qemu's SIMD
  emulation tends to be incorrect (except for arm64 from x86_64)--i have
  found this both for mipsel and arm32. Until these code paths are
  audited, which is probably a large job, it would be nice if qemu knew
  its emulation of this class of instructions was not very good, and
  thus it would give up on finding these instructions if a "careful"
  operation is passed.

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

Re: RFC: New device for zero-copy VM memory access

[geoff]

On 2019-11-03 21:10, ge...@hostfission.com wrote:

On 2019-11-01 02:52, Dr. David Alan Gilbert wrote:

* ge...@hostfission.com (ge...@hostfission.com) wrote:



On 2019-11-01 01:52, Peter Maydell wrote:
> On Thu, 31 Oct 2019 at 14:26,  wrote:
> > As the author of Looking Glass, I also have to consider the
> > maintenance
> > and the complexity of implementing the vhost protocol into the
> > project.
> > At this time a complete Porthole client can be implemented in 150
> > lines
> > of C without external dependencies, and most of that is boilerplate
> > socket code. This IMO is a major factor in deciding to avoid
> > vhost-user.
>
> This is essentially a proposal that we should make our project and
> code more complicated so that your project and code can be simpler.
> I hope you can see why this isn't necessarily an argument that will hold
> very much weight for us :-)

Certainly, I do which is why I am still going to see about using 
vhost,
however, a device that uses vhost is likely more complex then the 
device
as it stands right now and as such more maintenance would be involved 
on
your end also. Or have I missed something in that vhost-user can be 
used

directly as a device?


The basic vhost-user stuff isn't actually that hard;  if you aren't
actually shuffling commands over the queues you should find it pretty
simple - so I think your assumption about it being simpler if you 
avoid

it might be wrong.  It might be easier if you use it!


I have been looking into this and I am yet to find some decent
documentation or a simple device example I can use to understand how to
create such a device. Do you know of any reading or examples I can 
obtain

on how to get an initial do nothing device up and running?

-Geoff


Scratch that, the design just solidified for me and I am now making
progress, however it seems that vhost-user can't do what we need here:

1) I dont see any way to recieve notification of socket disconnection, 
in

our use case the client app needs to be able to be (re)connected
dynamically. It might be possible to get this event by registering it on
the chardev manually but this seems like it would be a kludge.

2) I don't see any method of notifying the vhost-user client of the
removal of a shared memory mapping. Again, these may not be persistently
mapped in the guest as we have no control over the buffer allocation, 
and
as such, we need a method to notify the client that the mapping has 
become

invalid.

3) VHOST_USER_SET_MEM_TABLE is a one time request, again this breaks our
usage as we need to change this dynamically at runtime.

Unless there are viable solutions to these problems there is no way that
vhost-user can be used for this kind of a device.

-Geoff





Dave


>
> thanks
> -- PMM

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Feature Recommendations?

[Dinah A Baum]

Hello all,

I am a university student whose Virtualization course has tasked me with
contributing to an open source, virtualization related project. I have a
little more than a month to complete this. I was wondering if you could
recommend a feature you'd like added that could be done in this time frame.

-Thanks,
Dinah

Wiki account

[Esteban Bosse]

Hello,
I would like to have an wiki account.

Preferred user: estebanb

Thank you,
Esteban Bosse

Re: RFC: New device for zero-copy VM memory access

[geoff]

On 2019-11-01 02:52, Dr. David Alan Gilbert wrote:

* ge...@hostfission.com (ge...@hostfission.com) wrote:



On 2019-11-01 01:52, Peter Maydell wrote:
> On Thu, 31 Oct 2019 at 14:26,  wrote:
> > As the author of Looking Glass, I also have to consider the
> > maintenance
> > and the complexity of implementing the vhost protocol into the
> > project.
> > At this time a complete Porthole client can be implemented in 150
> > lines
> > of C without external dependencies, and most of that is boilerplate
> > socket code. This IMO is a major factor in deciding to avoid
> > vhost-user.
>
> This is essentially a proposal that we should make our project and
> code more complicated so that your project and code can be simpler.
> I hope you can see why this isn't necessarily an argument that will hold
> very much weight for us :-)

Certainly, I do which is why I am still going to see about using 
vhost,
however, a device that uses vhost is likely more complex then the 
device
as it stands right now and as such more maintenance would be involved 
on
your end also. Or have I missed something in that vhost-user can be 
used

directly as a device?


The basic vhost-user stuff isn't actually that hard;  if you aren't
actually shuffling commands over the queues you should find it pretty
simple - so I think your assumption about it being simpler if you avoid
it might be wrong.  It might be easier if you use it!


I have been looking into this and I am yet to find some decent
documentation or a simple device example I can use to understand how to
create such a device. Do you know of any reading or examples I can 
obtain

on how to get an initial do nothing device up and running?

-Geoff



Dave


>
> thanks
> -- PMM

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Bug 1851095] [NEW] [feature request] awareness of instructions that are well emulated

[Peter Maydell]

On Sun, 3 Nov 2019 at 04:41, Shawn Landden <1851...@bugs.launchpad.net> wrote:
> While qemu's scalar emulation tends to be excellent, qemu's SIMD
> emulation tends to be incorrect (except for arm64 from x86_64)--i have
> found this both for mipsel and arm32. Until these code paths are
> audited, which is probably a large job, it would be nice if qemu knew
> its emulation of this class of instructions was not very good, and thus
> it would give up on finding these instructions if a "careful" operation
> is passed.

I'm not sure how this could work. If QEMU reports (via ID regs
etc) to the guest that it supports instruction class X when it
does not, that's a bug and we should fix it. If QEMU implements
an instruction but gets it wrong, that's also a bug and we should
fix it. In both cases, we'd need to have specific bug reports,
ideally with reproduce-cases. But we don't really have "known
areas where the emulation is incorrect" that we could somehow
differentiate and disable (except at a very vague level, eg
"probably better not to rely on the x86 emulation").

You might be able by careful selection of the cpu type to avoid
CPUs which implement vector operations. Some architectures
also allow individual CPU features to be disabled with extra
'-foo' qualifiers on the -cpu argument.

For Arm in particular (32 or 64 bit) I believe our implementation
should be correct and am happy to look at bug reports for that.

thanks
-- PMM

[PATCH v6 2/3] riscv: virt: Use Goldfish RTC device

[Anup Patel]

We extend QEMU RISC-V virt machine by adding Goldfish RTC device
to it. This will allow Guest Linux to sync it's local date/time
with Host date/time via RTC device.

Signed-off-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Reviewed-by: Alistair Francis 
---
 hw/riscv/Kconfig|  1 +
 hw/riscv/virt.c | 15 +++
 include/hw/riscv/virt.h |  2 ++
 3 files changed, 18 insertions(+)

diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index b12660b9f8..ff9fbe958a 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -34,6 +34,7 @@ config RISCV_VIRT
 select PCI
 select HART
 select SERIAL
+select GOLDFISH_RTC
 select VIRTIO_MMIO
 select PCI_EXPRESS_GENERIC_BRIDGE
 select PFLASH_CFI01
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index cc8f311e6b..818678a4b2 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -58,6 +58,7 @@ static const struct MemmapEntry {
 [VIRT_DEBUG] =   {0x0, 0x100 },
 [VIRT_MROM] ={ 0x1000,   0x11000 },
 [VIRT_TEST] ={   0x10,0x1000 },
+[VIRT_RTC] = {   0x101000,0x1000 },
 [VIRT_CLINT] =   {  0x200,   0x1 },
 [VIRT_PLIC] ={  0xc00, 0x400 },
 [VIRT_UART0] =   { 0x1000, 0x100 },
@@ -376,6 +377,17 @@ static void create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
 qemu_fdt_setprop_cell(fdt, nodename, "interrupt-parent", plic_phandle);
 qemu_fdt_setprop_cell(fdt, nodename, "interrupts", UART0_IRQ);
 
+nodename = g_strdup_printf("/rtc@%lx",
+(long)memmap[VIRT_RTC].base);
+qemu_fdt_add_subnode(fdt, nodename);
+qemu_fdt_setprop_string(fdt, nodename, "compatible",
+"google,goldfish-rtc");
+qemu_fdt_setprop_cells(fdt, nodename, "reg",
+0x0, memmap[VIRT_RTC].base,
+0x0, memmap[VIRT_RTC].size);
+qemu_fdt_setprop_cell(fdt, nodename, "interrupt-parent", plic_phandle);
+qemu_fdt_setprop_cell(fdt, nodename, "interrupts", RTC_IRQ);
+
 qemu_fdt_add_subnode(fdt, "/chosen");
 qemu_fdt_setprop_string(fdt, "/chosen", "stdout-path", nodename);
 if (cmdline) {
@@ -579,6 +591,9 @@ static void riscv_virt_board_init(MachineState *machine)
 0, qdev_get_gpio_in(DEVICE(s->plic), UART0_IRQ), 399193,
 serial_hd(0), DEVICE_LITTLE_ENDIAN);
 
+sysbus_create_simple("goldfish_rtc", memmap[VIRT_RTC].base,
+qdev_get_gpio_in(DEVICE(s->plic), RTC_IRQ));
+
 virt_flash_create(s);
 
 for (i = 0; i < ARRAY_SIZE(s->flash); i++) {
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index b17048a93a..e69355efaf 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -44,6 +44,7 @@ enum {
 VIRT_DEBUG,
 VIRT_MROM,
 VIRT_TEST,
+VIRT_RTC,
 VIRT_CLINT,
 VIRT_PLIC,
 VIRT_UART0,
@@ -57,6 +58,7 @@ enum {
 
 enum {
 UART0_IRQ = 10,
+RTC_IRQ = 11,
 VIRTIO_IRQ = 1, /* 1 to 8 */
 VIRTIO_COUNT = 8,
 PCIE_IRQ = 0x20, /* 32 to 35 */
-- 
2.17.1

[PATCH v6 3/3] MAINTAINERS: Add maintainer entry for Goldfish RTC

[Anup Patel]

Add myself as Goldfish RTC maintainer until someone else is
willing to maintain it.

Signed-off-by: Anup Patel 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c2a68555ae..f200e985da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -558,6 +558,13 @@ F: include/hw/arm/digic.h
 F: hw/*/digic*
 F: include/hw/*/digic*
 
+Goldfish RTC
+M: Anup Patel 
+L: qemu-ri...@nongnu.org
+S: Maintained
+F: hw/rtc/goldfish_rtc.c
+F: include/hw/rtc/goldfish_rtc.h
+
 Gumstix
 M: Peter Maydell 
 R: Philippe Mathieu-Daud?? 
-- 
2.17.1

[PATCH v6 1/3] hw: rtc: Add Goldfish RTC device

[Anup Patel]

This patch adds model for Google Goldfish virtual platform RTC device.

We will be adding Goldfish RTC device to the QEMU RISC-V virt machine
for providing real date-time to Guest Linux. The corresponding Linux
driver for Goldfish RTC device is already available in upstream Linux.

For now, VM migration support is available but untested for Goldfish RTC
device. It will be hardened in-future when we implement VM migration for
KVM RISC-V.

Signed-off-by: Anup Patel 
Reviewed-by: Alistair Francis 
---
 hw/rtc/Kconfig|   3 +
 hw/rtc/Makefile.objs  |   1 +
 hw/rtc/goldfish_rtc.c | 288 ++
 hw/rtc/trace-events   |   4 +
 include/hw/rtc/goldfish_rtc.h |  46 ++
 5 files changed, 342 insertions(+)
 create mode 100644 hw/rtc/goldfish_rtc.c
 create mode 100644 include/hw/rtc/goldfish_rtc.h

diff --git a/hw/rtc/Kconfig b/hw/rtc/Kconfig
index 45daa8d655..bafe6ac2c9 100644
--- a/hw/rtc/Kconfig
+++ b/hw/rtc/Kconfig
@@ -21,3 +21,6 @@ config MC146818RTC
 
 config SUN4V_RTC
 bool
+
+config GOLDFISH_RTC
+bool
diff --git a/hw/rtc/Makefile.objs b/hw/rtc/Makefile.objs
index 8dc9fcd3a9..aa208d0d10 100644
--- a/hw/rtc/Makefile.objs
+++ b/hw/rtc/Makefile.objs
@@ -11,3 +11,4 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_rtc.o
 obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
 common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_rtc.o
+common-obj-$(CONFIG_GOLDFISH_RTC) += goldfish_rtc.o
diff --git a/hw/rtc/goldfish_rtc.c b/hw/rtc/goldfish_rtc.c
new file mode 100644
index 00..f71f6eaab0
--- /dev/null
+++ b/hw/rtc/goldfish_rtc.c
@@ -0,0 +1,288 @@
+/*
+ * Goldfish virtual platform RTC
+ *
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * For more details on Google Goldfish virtual platform refer:
+ * 
https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT
+ *
+ * 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-common.h"
+#include "hw/rtc/goldfish_rtc.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "qemu/timer.h"
+#include "sysemu/sysemu.h"
+#include "qemu/cutils.h"
+#include "qemu/log.h"
+
+#include "trace.h"
+
+#define RTC_TIME_LOW0x00
+#define RTC_TIME_HIGH   0x04
+#define RTC_ALARM_LOW   0x08
+#define RTC_ALARM_HIGH  0x0c
+#define RTC_IRQ_ENABLED 0x10
+#define RTC_CLEAR_ALARM 0x14
+#define RTC_ALARM_STATUS0x18
+#define RTC_CLEAR_INTERRUPT 0x1c
+
+static void goldfish_rtc_update(GoldfishRTCState *s)
+{
+qemu_set_irq(s->irq, (s->irq_pending & s->irq_enabled) ? 1 : 0);
+}
+
+static void goldfish_rtc_interrupt(void *opaque)
+{
+GoldfishRTCState *s = (GoldfishRTCState *)opaque;
+
+s->alarm_running = 0;
+s->irq_pending = 1;
+goldfish_rtc_update(s);
+}
+
+static uint64_t goldfish_rtc_get_count(GoldfishRTCState *s)
+{
+return s->tick_offset + (uint64_t)qemu_clock_get_ns(rtc_clock);
+}
+
+static void goldfish_rtc_clear_alarm(GoldfishRTCState *s)
+{
+timer_del(s->timer);
+s->alarm_running = 0;
+}
+
+static void goldfish_rtc_set_alarm(GoldfishRTCState *s)
+{
+uint64_t ticks = goldfish_rtc_get_count(s);
+uint64_t event = s->alarm_next;
+
+if (event <= ticks) {
+goldfish_rtc_clear_alarm(s);
+goldfish_rtc_interrupt(s);
+} else {
+/*
+ * We should be setting timer expiry to:
+ * qemu_clock_get_ns(rtc_clock) + (event - ticks)
+ * but this is equivalent to:
+ * event - s->tick_offset
+ */
+timer_mod(s->timer, event - s->tick_offset);
+s->alarm_running = 1;
+}
+}
+
+static uint64_t goldfish_rtc_read(void *opaque, hwaddr offset,
+  unsigned size)
+{
+GoldfishRTCState *s = opaque;
+uint64_t r = 0;
+
+switch (offset) {
+case RTC_TIME_LOW:
+r = goldfish_rtc_get_count(s) & 0x;
+break;
+case RTC_TIME_HIGH:
+r = goldfish_rtc_get_count(s) >> 32;
+break;
+case RTC_ALARM_LOW:
+r = s->alarm_next & 0x;
+break;
+case RTC_ALARM_HIGH:
+r = s->alarm_next >> 32;
+break;
+case RTC_IRQ_ENABLED:
+r = s->irq_enabled;
+break;
+case RTC_ALARM_STATUS:

[PATCH v6 0/3] RTC support for QEMU RISC-V virt machine

[Anup Patel]

This series adds RTC device to QEMU RISC-V virt machine. We have
selected Goldfish RTC device model for this. It's a pretty simple
synthetic device with few MMIO registers and no dependency external
clock. The driver for Goldfish RTC is already available in Linux so
we just need to enable it in Kconfig for RISCV and also update Linux
defconfigs.

We have tested this series with Linux-5.4-rc4 plus defconfig changes
available in 'goldfish_rtc_v2' branch of:
https://github.com/avpatel/linux.git

Changes since v5:
 - Rebased on latest QEMU master
 - Added maintainer entry for Goldfish RTC

Changes since v4:
 - Fixed typo in trace event usage
 - Moved goldfish_rtc.h to correct location

Changes since v3:
 - Address all nit comments from Alistair

Changes since v2:
 - Rebased on RTC code refactoring

Changes since v1:
 - Implemented VMState save/restore callbacks

Anup Patel (3):
  hw: rtc: Add Goldfish RTC device
  riscv: virt: Use Goldfish RTC device
  MAINTAINERS: Add maintainer entry for Goldfish RTC

 MAINTAINERS   |   7 +
 hw/riscv/Kconfig  |   1 +
 hw/riscv/virt.c   |  15 ++
 hw/rtc/Kconfig|   3 +
 hw/rtc/Makefile.objs  |   1 +
 hw/rtc/goldfish_rtc.c | 288 ++
 hw/rtc/trace-events   |   4 +
 include/hw/riscv/virt.h   |   2 +
 include/hw/rtc/goldfish_rtc.h |  46 ++
 9 files changed, 367 insertions(+)
 create mode 100644 hw/rtc/goldfish_rtc.c
 create mode 100644 include/hw/rtc/goldfish_rtc.h

--
2.17.1

Re: [PATCH v5 0/2] RTC support for QEMU RISC-V virt machine

[Anup Patel]

On Sat, Nov 2, 2019 at 4:44 AM Palmer Dabbelt  wrote:
>
> On Fri, 01 Nov 2019 08:40:24 PDT (-0700), a...@brainfault.org wrote:
> > On Tue, Oct 29, 2019 at 6:55 PM Alistair Francis  
> > wrote:
> >>
> >> On Fri, Oct 25, 2019 at 6:28 AM Anup Patel  wrote:
> >> >
> >> > This series adds RTC device to QEMU RISC-V virt machine. We have
> >> > selected Goldfish RTC device model for this. It's a pretty simple
> >> > synthetic device with few MMIO registers and no dependency external
> >> > clock. The driver for Goldfish RTC is already available in Linux so
> >> > we just need to enable it in Kconfig for RISCV and also update Linux
> >> > defconfigs.
> >> >
> >> > We have tested this series with Linux-5.4-rc4 plus defconfig changes
> >> > available in 'goldfish_rtc_v2' branch of:
> >> > https://github.com/avpatel/linux.git
> >>
> >> @Peter Maydell this has been reviewed, do you mind taking this in you
> >> next PR? I don't see a maintainer for hw/rtc.
> >
> > It would be great if this series can be taken for QEMU-4.2
>
> It doesn't look like there's anyone who maintains hw/rtc, so maybe that's why
> this has been going slowly?  I'd happy to PR it, but I don't really have the
> bandwidth to sign up to maintain more stuff right now.

No problem, I will maintain Goldfish RTC emulation until someone else
is willing to maintain it.

Regards,
Anup

>
> >
> > Regards,
> > Anup
> >
> >>
> >> Alistair
> >>
> >> >
> >> > Changes since v4:
> >> >  - Fixed typo in trace event usage
> >> >  - Moved goldfish_rtc.h to correct location
> >> >
> >> > Changes since v3:
> >> >  - Address all nit comments from Alistair
> >> >
> >> > Changes since v2:
> >> >  - Rebased on RTC code refactoring
> >> >
> >> > Changes since v1:
> >> >  - Implemented VMState save/restore callbacks
> >> >
> >> > Anup Patel (2):
> >> >   hw: rtc: Add Goldfish RTC device
> >> >   riscv: virt: Use Goldfish RTC device
> >> >
> >> >  hw/riscv/Kconfig  |   1 +
> >> >  hw/riscv/virt.c   |  15 ++
> >> >  hw/rtc/Kconfig|   3 +
> >> >  hw/rtc/Makefile.objs  |   1 +
> >> >  hw/rtc/goldfish_rtc.c | 288 ++
> >> >  hw/rtc/trace-events   |   4 +
> >> >  include/hw/riscv/virt.h   |   2 +
> >> >  include/hw/rtc/goldfish_rtc.h |  46 ++
> >> >  8 files changed, 360 insertions(+)
> >> >  create mode 100644 hw/rtc/goldfish_rtc.c
> >> >  create mode 100644 include/hw/rtc/goldfish_rtc.h
> >> >
> >> > --
> >> > 2.17.1
> >> >