[RFC 4/8] Got GPU init working. Stops at probing display

[aaron . zakhrov]

From: Aaron Dominick 

---
 hw/display/ati.c  |   9 +-
 hw/display/r300.c | 571 +-
 hw/display/r300.h |  77 ++-
 3 files changed, 544 insertions(+), 113 deletions(-)

diff --git a/hw/display/ati.c b/hw/display/ati.c
index db3b254316..1d36233163 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -44,7 +44,7 @@ enum { VGA_MODE, EXT_MODE };
 
 static void ati_vga_switch_mode(ATIVGAState *s)
 {
-DPRINTF("%d -> %d\n",
+qemu_log("%d -> %d\n",
 s->mode, !!(s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN));
 if (s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN) {
 /* Extended mode enabled */
@@ -88,7 +88,7 @@ static void ati_vga_switch_mode(ATIVGAState *s)
 qemu_log_mask(LOG_UNIMP, "Unsupported bpp value\n");
 }
 assert(bpp != 0);
-DPRINTF("Switching to %dx%d %d %d @ %x\n", h, v, stride, bpp, 
offs);
+qemu_log("Switching to %dx%d %d %d @ %x\n", h, v, stride, bpp, 
offs);
 vbe_ioport_write_index(&s->vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(&s->vga, 0, VBE_DISPI_DISABLED);
 s->vga.big_endian_fb = (s->regs.config_cntl & APER_0_ENDIAN ||
@@ -111,14 +111,14 @@ static void ati_vga_switch_mode(ATIVGAState *s)
 vbe_ioport_write_data(&s->vga, 0, stride);
 stride *= bypp;
 if (offs % stride) {
-DPRINTF("CRTC offset is not multiple of pitch\n");
+qemu_log("CRTC offset is not multiple of pitch\n");
 vbe_ioport_write_index(&s->vga, 0,
VBE_DISPI_INDEX_X_OFFSET);
 vbe_ioport_write_data(&s->vga, 0, offs % stride / bypp);
 }
 vbe_ioport_write_index(&s->vga, 0, VBE_DISPI_INDEX_Y_OFFSET);
 vbe_ioport_write_data(&s->vga, 0, offs / stride);
-DPRINTF("VBE offset (%d,%d), vbe_start_addr=%x\n",
+qemu_log("VBE offset (%d,%d), vbe_start_addr=%x\n",
 s->vga.vbe_regs[VBE_DISPI_INDEX_X_OFFSET],
 s->vga.vbe_regs[VBE_DISPI_INDEX_Y_OFFSET],
 s->vga.vbe_start_addr);
@@ -129,6 +129,7 @@ static void ati_vga_switch_mode(ATIVGAState *s)
 s->mode = VGA_MODE;
 vbe_ioport_write_index(&s->vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(&s->vga, 0, VBE_DISPI_DISABLED);
+qemu_log("VGA MODE %d \n",s->mode);
 }
 }
 
diff --git a/hw/display/r300.c b/hw/display/r300.c
index 074dbf5b2d..5bd71142a8 100644
--- a/hw/display/r300.c
+++ b/hw/display/r300.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 #include "r300.h"
 #include "r300_reg.h"
+#include "r100d.h"
 #include "radeon_reg.h"
 #include "vga-access.h"
 #include "hw/qdev-properties.h"
@@ -38,18 +39,20 @@ static const struct {
 uint16_t dev_id;
 } r300_model_aliases[] = {
 { "radeon9500", PCI_DEVICE_ID_ATI_RADEON_9500_PRO },
+{ "radeon9700", PCI_DEVICE_ID_ATI_RADEON_9700 }
 };
 
 enum { VGA_MODE, EXT_MODE };
 
 static void r300_vga_switch_mode(RADVGAState *s)
 {
-DPRINTF("%d -> %d\n",
-s->mode, !!(s->regs.crtc_gen_cntl & RADEON_CRTC_EXT_DISP_EN));
-if (s->regs.crtc_gen_cntl & RADEON_CRTC_EXT_DISP_EN) {
+qemu_log(" R300 %d -> %d\n",
+s->mode, !(s->regs.crtc_gen_cntl & RADEON_CRTC_EN));
+qemu_log("R300 RADEON_CRTC_EXT_DISP_EN = %08x CRTC_GEN_CNTL = %08x 
",RADEON_CRTC_EN,s->regs.crtc_gen_cntl);
+if (s->regs.crtc_gen_cntl & ~RADEON_CRTC_EN) {
 /* Extended mode enabled */
 s->mode = EXT_MODE;
-if (s->regs.crtc_gen_cntl & RADEON_CRTC2_EN) {
+if (s->regs.crtc_gen_cntl & ~RADEON_CRTC_EN) {
 /* CRT controller enabled, use CRTC values */
 /* FIXME Should these be the same as VGA CRTC regs? */
 uint32_t offs = s->regs.crtc_offset & 0x07ff;
@@ -65,32 +68,32 @@ static void r300_vga_switch_mode(RADVGAState *s)
 }
 h = ((s->regs.crtc_h_total_disp >> 16) + 1) * 8;
 v = (s->regs.crtc_v_total_disp >> 16) + 1;
-// switch (s->regs.crtc_gen_cntl & RADEON_CRTC_CUR_MODE_MASK) {
-// // case RADEON_CRTC_PIX_WIDTH_4BPP:
-// // bpp = 4;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_8BPP:
-// // bpp = 8;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_15BPP:
-// // bpp = 15;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_16BPP:
-// // bpp = 16;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_24BPP:
-// // bpp = 24;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_32BPP:
-// // bpp = 32;
-// // break;
-// default:
-// qemu_log_mask(L

[RFC 7/8] R300 fixes

[aaron . zakhrov]

From: Aaron Dominick 

---
 hw/display/r300.c | 9 +
 hw/display/r300.h | 6 ++
 2 files changed, 15 insertions(+)

diff --git a/hw/display/r300.c b/hw/display/r300.c
index 653474c3aa..074dbf5b2d 100644
--- a/hw/display/r300.c
+++ b/hw/display/r300.c
@@ -878,6 +878,15 @@ static void r300_mm_write(void *opaque, hwaddr addr,
 case RADEON_DEFAULT_SC_BOTTOM_RIGHT:
 s->regs.default_sc_bottom_right = data & 0x3fff3fff;
 break;
+case R300_GB_ENABLE:
+s->regs.r300_gb_enable = data;
+break;
+case R300_GB_TILE_CONFIG:
+s->regs.r300_gb_tile_config = data;
+break;
+case R300_GB_FIFO_SIZE:
+s->regs.r300_gb_fifo_size = data;
+break;
 default:
 break;
 }
diff --git a/hw/display/r300.h b/hw/display/r300.h
index a9e1db32be..19e3d97f8a 100644
--- a/hw/display/r300.h
+++ b/hw/display/r300.h
@@ -83,6 +83,12 @@ typedef struct RADVGARegs{
   uint32_t default_sc_bottom_right;
   uint32_t mc_status;
 
+  //R300 GB Registers
+  uint32_t r300_gb_enable;
+  uint32_t r300_gb_tile_config;
+  uint32_t r300_gb_fifo_size;
+
+
 //Color Buffer RB3D
   uint32_t r300_rb3d_aaresolve_ctl;
   uint32_t r300_rb3d_aaresolve_offset;
-- 
2.24.0

[RFC 6/8] Fix MC STATUS resgister

[aaron . zakhrov]

From: Aaron Dominick 

---
 hw/display/r300.c | 15 ---
 hw/display/r300.h |  1 +
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/display/r300.c b/hw/display/r300.c
index 94e90b7a95..653474c3aa 100644
--- a/hw/display/r300.c
+++ b/hw/display/r300.c
@@ -278,6 +278,10 @@ static uint64_t r300_mm_read(void *opaque, hwaddr addr, 
unsigned int size)
 uint64_t val = 0;
 
 switch (addr) {
+case RADEON_MC_STATUS:
+val = s->regs.mc_status;
+break;
+
 case RADEON_MM_INDEX:
 val = s->regs.mm_index;
 break;
@@ -358,9 +362,9 @@ static uint64_t r300_mm_read(void *opaque, hwaddr addr, 
unsigned int size)
 case RADEON_CONFIG_REG_APER_SIZE:
 val = memory_region_size(&s->mm);
 break;
-case RADEON_MC_STATUS:
-val = 5;
-break;
+// case RADEON_MC_STATUS:
+// val = 5;
+// break;
 case RADEON_RBBM_STATUS:
 val = 64; /* free CMDFIFO entries */
 break;
@@ -512,6 +516,10 @@ static void r300_mm_write(void *opaque, hwaddr addr,
 trace_ati_mm_write(size, addr, r300_reg_name(addr & ~3ULL), data);
 }
 switch (addr) {
+  case RADEON_MC_STATUS:
+s->regs.mc_status = R300_MC_IDLE;
+s->regs.mc_status = data;
+break;
   case RADEON_RBBM_STATUS:
 s->regs.rbbm_status = data|= RADEON_RBBM_FIFOCNT_MASK;
 break;
@@ -946,6 +954,7 @@ static void r300_vga_realize(PCIDevice *dev, Error **errp)
 static void r300_vga_reset(DeviceState *dev)
 {
 RADVGAState *s = RAD_VGA(dev);
+s->regs.mc_status = R300_MC_IDLE;
 
 timer_del(&s->vblank_timer);
 r300_vga_update_irq(s);
diff --git a/hw/display/r300.h b/hw/display/r300.h
index 60f572647f..a9e1db32be 100644
--- a/hw/display/r300.h
+++ b/hw/display/r300.h
@@ -81,6 +81,7 @@ typedef struct RADVGARegs{
   uint32_t default_pitch;
   uint32_t default_tile;
   uint32_t default_sc_bottom_right;
+  uint32_t mc_status;
 
 //Color Buffer RB3D
   uint32_t r300_rb3d_aaresolve_ctl;
-- 
2.24.0

[RFC 3/8] R300 fixes

[aaron . zakhrov]

From: Aaron Dominick 

---
 hw/display/r300.c | 9 +
 hw/display/r300.h | 6 ++
 2 files changed, 15 insertions(+)

diff --git a/hw/display/r300.c b/hw/display/r300.c
index 653474c3aa..074dbf5b2d 100644
--- a/hw/display/r300.c
+++ b/hw/display/r300.c
@@ -878,6 +878,15 @@ static void r300_mm_write(void *opaque, hwaddr addr,
 case RADEON_DEFAULT_SC_BOTTOM_RIGHT:
 s->regs.default_sc_bottom_right = data & 0x3fff3fff;
 break;
+case R300_GB_ENABLE:
+s->regs.r300_gb_enable = data;
+break;
+case R300_GB_TILE_CONFIG:
+s->regs.r300_gb_tile_config = data;
+break;
+case R300_GB_FIFO_SIZE:
+s->regs.r300_gb_fifo_size = data;
+break;
 default:
 break;
 }
diff --git a/hw/display/r300.h b/hw/display/r300.h
index a9e1db32be..19e3d97f8a 100644
--- a/hw/display/r300.h
+++ b/hw/display/r300.h
@@ -83,6 +83,12 @@ typedef struct RADVGARegs{
   uint32_t default_sc_bottom_right;
   uint32_t mc_status;
 
+  //R300 GB Registers
+  uint32_t r300_gb_enable;
+  uint32_t r300_gb_tile_config;
+  uint32_t r300_gb_fifo_size;
+
+
 //Color Buffer RB3D
   uint32_t r300_rb3d_aaresolve_ctl;
   uint32_t r300_rb3d_aaresolve_offset;
-- 
2.24.0

[RFC 8/8] Got GPU init working. Stops at probing display

[aaron . zakhrov]

From: Aaron Dominick 

---
 hw/display/ati.c  |   9 +-
 hw/display/r300.c | 571 +-
 hw/display/r300.h |  77 ++-
 3 files changed, 544 insertions(+), 113 deletions(-)

diff --git a/hw/display/ati.c b/hw/display/ati.c
index db3b254316..1d36233163 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -44,7 +44,7 @@ enum { VGA_MODE, EXT_MODE };
 
 static void ati_vga_switch_mode(ATIVGAState *s)
 {
-DPRINTF("%d -> %d\n",
+qemu_log("%d -> %d\n",
 s->mode, !!(s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN));
 if (s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN) {
 /* Extended mode enabled */
@@ -88,7 +88,7 @@ static void ati_vga_switch_mode(ATIVGAState *s)
 qemu_log_mask(LOG_UNIMP, "Unsupported bpp value\n");
 }
 assert(bpp != 0);
-DPRINTF("Switching to %dx%d %d %d @ %x\n", h, v, stride, bpp, 
offs);
+qemu_log("Switching to %dx%d %d %d @ %x\n", h, v, stride, bpp, 
offs);
 vbe_ioport_write_index(&s->vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(&s->vga, 0, VBE_DISPI_DISABLED);
 s->vga.big_endian_fb = (s->regs.config_cntl & APER_0_ENDIAN ||
@@ -111,14 +111,14 @@ static void ati_vga_switch_mode(ATIVGAState *s)
 vbe_ioport_write_data(&s->vga, 0, stride);
 stride *= bypp;
 if (offs % stride) {
-DPRINTF("CRTC offset is not multiple of pitch\n");
+qemu_log("CRTC offset is not multiple of pitch\n");
 vbe_ioport_write_index(&s->vga, 0,
VBE_DISPI_INDEX_X_OFFSET);
 vbe_ioport_write_data(&s->vga, 0, offs % stride / bypp);
 }
 vbe_ioport_write_index(&s->vga, 0, VBE_DISPI_INDEX_Y_OFFSET);
 vbe_ioport_write_data(&s->vga, 0, offs / stride);
-DPRINTF("VBE offset (%d,%d), vbe_start_addr=%x\n",
+qemu_log("VBE offset (%d,%d), vbe_start_addr=%x\n",
 s->vga.vbe_regs[VBE_DISPI_INDEX_X_OFFSET],
 s->vga.vbe_regs[VBE_DISPI_INDEX_Y_OFFSET],
 s->vga.vbe_start_addr);
@@ -129,6 +129,7 @@ static void ati_vga_switch_mode(ATIVGAState *s)
 s->mode = VGA_MODE;
 vbe_ioport_write_index(&s->vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(&s->vga, 0, VBE_DISPI_DISABLED);
+qemu_log("VGA MODE %d \n",s->mode);
 }
 }
 
diff --git a/hw/display/r300.c b/hw/display/r300.c
index 074dbf5b2d..5bd71142a8 100644
--- a/hw/display/r300.c
+++ b/hw/display/r300.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 #include "r300.h"
 #include "r300_reg.h"
+#include "r100d.h"
 #include "radeon_reg.h"
 #include "vga-access.h"
 #include "hw/qdev-properties.h"
@@ -38,18 +39,20 @@ static const struct {
 uint16_t dev_id;
 } r300_model_aliases[] = {
 { "radeon9500", PCI_DEVICE_ID_ATI_RADEON_9500_PRO },
+{ "radeon9700", PCI_DEVICE_ID_ATI_RADEON_9700 }
 };
 
 enum { VGA_MODE, EXT_MODE };
 
 static void r300_vga_switch_mode(RADVGAState *s)
 {
-DPRINTF("%d -> %d\n",
-s->mode, !!(s->regs.crtc_gen_cntl & RADEON_CRTC_EXT_DISP_EN));
-if (s->regs.crtc_gen_cntl & RADEON_CRTC_EXT_DISP_EN) {
+qemu_log(" R300 %d -> %d\n",
+s->mode, !(s->regs.crtc_gen_cntl & RADEON_CRTC_EN));
+qemu_log("R300 RADEON_CRTC_EXT_DISP_EN = %08x CRTC_GEN_CNTL = %08x 
",RADEON_CRTC_EN,s->regs.crtc_gen_cntl);
+if (s->regs.crtc_gen_cntl & ~RADEON_CRTC_EN) {
 /* Extended mode enabled */
 s->mode = EXT_MODE;
-if (s->regs.crtc_gen_cntl & RADEON_CRTC2_EN) {
+if (s->regs.crtc_gen_cntl & ~RADEON_CRTC_EN) {
 /* CRT controller enabled, use CRTC values */
 /* FIXME Should these be the same as VGA CRTC regs? */
 uint32_t offs = s->regs.crtc_offset & 0x07ff;
@@ -65,32 +68,32 @@ static void r300_vga_switch_mode(RADVGAState *s)
 }
 h = ((s->regs.crtc_h_total_disp >> 16) + 1) * 8;
 v = (s->regs.crtc_v_total_disp >> 16) + 1;
-// switch (s->regs.crtc_gen_cntl & RADEON_CRTC_CUR_MODE_MASK) {
-// // case RADEON_CRTC_PIX_WIDTH_4BPP:
-// // bpp = 4;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_8BPP:
-// // bpp = 8;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_15BPP:
-// // bpp = 15;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_16BPP:
-// // bpp = 16;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_24BPP:
-// // bpp = 24;
-// // break;
-// // case RADEON_CRTC_PIX_WIDTH_32BPP:
-// // bpp = 32;
-// // break;
-// default:
-// qemu_log_mask(L

[RFC 2/8] Fix MC STATUS resgister

[aaron . zakhrov]

From: Aaron Dominick 

---
 hw/display/r300.c | 15 ---
 hw/display/r300.h |  1 +
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/display/r300.c b/hw/display/r300.c
index 94e90b7a95..653474c3aa 100644
--- a/hw/display/r300.c
+++ b/hw/display/r300.c
@@ -278,6 +278,10 @@ static uint64_t r300_mm_read(void *opaque, hwaddr addr, 
unsigned int size)
 uint64_t val = 0;
 
 switch (addr) {
+case RADEON_MC_STATUS:
+val = s->regs.mc_status;
+break;
+
 case RADEON_MM_INDEX:
 val = s->regs.mm_index;
 break;
@@ -358,9 +362,9 @@ static uint64_t r300_mm_read(void *opaque, hwaddr addr, 
unsigned int size)
 case RADEON_CONFIG_REG_APER_SIZE:
 val = memory_region_size(&s->mm);
 break;
-case RADEON_MC_STATUS:
-val = 5;
-break;
+// case RADEON_MC_STATUS:
+// val = 5;
+// break;
 case RADEON_RBBM_STATUS:
 val = 64; /* free CMDFIFO entries */
 break;
@@ -512,6 +516,10 @@ static void r300_mm_write(void *opaque, hwaddr addr,
 trace_ati_mm_write(size, addr, r300_reg_name(addr & ~3ULL), data);
 }
 switch (addr) {
+  case RADEON_MC_STATUS:
+s->regs.mc_status = R300_MC_IDLE;
+s->regs.mc_status = data;
+break;
   case RADEON_RBBM_STATUS:
 s->regs.rbbm_status = data|= RADEON_RBBM_FIFOCNT_MASK;
 break;
@@ -946,6 +954,7 @@ static void r300_vga_realize(PCIDevice *dev, Error **errp)
 static void r300_vga_reset(DeviceState *dev)
 {
 RADVGAState *s = RAD_VGA(dev);
+s->regs.mc_status = R300_MC_IDLE;
 
 timer_del(&s->vblank_timer);
 r300_vga_update_irq(s);
diff --git a/hw/display/r300.h b/hw/display/r300.h
index 60f572647f..a9e1db32be 100644
--- a/hw/display/r300.h
+++ b/hw/display/r300.h
@@ -81,6 +81,7 @@ typedef struct RADVGARegs{
   uint32_t default_pitch;
   uint32_t default_tile;
   uint32_t default_sc_bottom_right;
+  uint32_t mc_status;
 
 //Color Buffer RB3D
   uint32_t r300_rb3d_aaresolve_ctl;
-- 
2.24.0

Re: [PATCH v4 6/6] s390x: kvm: Make kvm_sclp_service_call void

[Thomas Huth]

On 27/11/2019 18.50, Janosch Frank wrote:

It defaults to returning 0 anyway and that return value is not
necessary, as 0 is also the default rc that the caller would return.

While doing that we can simplify the logic a bit and return early if
we inject a PGM exception. Also we always set a 0 cc, so let's not
base it on the rc of the sclp emulation functions.

Signed-off-by: Janosch Frank 
---
  target/s390x/kvm.c | 12 +---
  1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 0c9d14b4b1..08bb1edca0 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -1159,13 +1159,13 @@ void kvm_s390_access_exception(S390CPU *cpu, uint16_t 
code, uint64_t te_code)
  kvm_s390_vcpu_interrupt(cpu, &irq);
  }
  
-static int kvm_sclp_service_call(S390CPU *cpu, struct kvm_run *run,

+static void kvm_sclp_service_call(S390CPU *cpu, struct kvm_run *run,
   uint16_t ipbh0)
  {
  CPUS390XState *env = &cpu->env;
  uint64_t sccb;
  uint32_t code;
-int r = 0;
+int r;
  
  sccb = env->regs[ipbh0 & 0xf];

  code = env->regs[(ipbh0 & 0xf0) >> 4];
@@ -1173,11 +1173,9 @@ static int kvm_sclp_service_call(S390CPU *cpu, struct 
kvm_run *run,
  r = sclp_service_call(env, sccb, code);
  if (r < 0) {
  kvm_s390_program_interrupt(cpu, -r);
-} else {
-setcc(cpu, r);
+return;
  }
-
-return 0;
+setcc(cpu, 0);


I think I'd also slightly prefer setcc(cpu, r) here ... but anyway:

Reviewed-by: Thomas Huth 

[PATCH] Add a parameter 'offset' for HostMemoryBackendFile

[Jason Zeng]

In cloud environment, when using DRAM-emulated-PMEM DAX device (by kernel
parameter 'memmap=nn!ss') to mmap guest memory, multiple VMs may need to
share the same DAX device. This is because we can't dynamically create
multiple namespaces in one DRAM-emulated-PMEM region. It is also hard to
figure out how many 'memmap=nn!ss' regions need to be created at kernel
boot time.

This patch introduces a parameter 'offset' for HostMemoryBackendFile to
specify the offset in the file this HostMemoryBackendFile will mmap to,
so that different HostMemoryBackendFiles can mmap to different address
ranges of the backing file.

Signed-off-by: Jason Zeng 
---
 backends/hostmem-file.c   | 46 ++-
 exec.c| 20 ++---
 hw/core/numa.c|  2 +-
 include/exec/memory.h |  1 +
 include/exec/ram_addr.h   |  4 ++--
 include/qemu/mmap-alloc.h |  1 +
 memory.c  |  6 +++--
 util/mmap-alloc.c |  5 +++--
 util/oslib-posix.c|  2 +-
 9 files changed, 70 insertions(+), 17 deletions(-)

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index be64020746..1fe814d52e 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -34,6 +34,7 @@ struct HostMemoryBackendFile {
 HostMemoryBackend parent_obj;
 
 char *mem_path;
+uint64_t offset;
 uint64_t align;
 bool discard_data;
 bool is_pmem;
@@ -57,6 +58,10 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
**errp)
 error_setg(errp, "mem-path property not set");
 return;
 }
+if (fb->align && fb->offset && (fb->offset % fb->align)) {
+error_setg(errp, "offset doesn't match align");
+return;
+}
 
 backend->force_prealloc = mem_prealloc;
 name = host_memory_backend_get_name(backend);
@@ -65,7 +70,7 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
**errp)
  backend->size, fb->align,
  (backend->share ? RAM_SHARED : 0) |
  (fb->is_pmem ? RAM_PMEM : 0),
- fb->mem_path, errp);
+ fb->mem_path, fb->offset, errp);
 g_free(name);
 #endif
 }
@@ -137,6 +142,41 @@ static void file_memory_backend_set_align(Object *o, 
Visitor *v,
 error_propagate(errp, local_err);
 }
 
+static void file_memory_backend_get_offset(Object *o, Visitor *v,
+   const char *name, void *opaque,
+   Error **errp)
+{
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
+uint64_t val = fb->offset;
+
+visit_type_size(v, name, &val, errp);
+}
+
+static void file_memory_backend_set_offset(Object *o, Visitor *v,
+   const char *name, void *opaque,
+   Error **errp)
+{
+HostMemoryBackend *backend = MEMORY_BACKEND(o);
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
+Error *local_err = NULL;
+uint64_t val;
+
+if (host_memory_backend_mr_inited(backend)) {
+error_setg(&local_err, "cannot change property '%s' of %s",
+   name, object_get_typename(o));
+goto out;
+}
+
+visit_type_size(v, name, &val, &local_err);
+if (local_err) {
+goto out;
+}
+fb->offset = val;
+
+ out:
+error_propagate(errp, local_err);
+}
+
 static bool file_memory_backend_get_pmem(Object *o, Error **errp)
 {
 return MEMORY_BACKEND_FILE(o)->is_pmem;
@@ -197,6 +237,10 @@ file_backend_class_init(ObjectClass *oc, void *data)
 object_class_property_add_str(oc, "mem-path",
 get_mem_path, set_mem_path,
 &error_abort);
+object_class_property_add(oc, "offset", "uint64",
+file_memory_backend_get_offset,
+file_memory_backend_set_offset,
+NULL, NULL, &error_abort);
 object_class_property_add(oc, "align", "int",
 file_memory_backend_get_align,
 file_memory_backend_set_align,
diff --git a/exec.c b/exec.c
index ffdb518535..7018ef343f 100644
--- a/exec.c
+++ b/exec.c
@@ -1838,6 +1838,7 @@ static int file_ram_open(const char *path,
 static void *file_ram_alloc(RAMBlock *block,
 ram_addr_t memory,
 int fd,
+off_t offset,
 bool truncate,
 Error **errp)
 {
@@ -1889,7 +1890,7 @@ static void *file_ram_alloc(RAMBlock *block,
 perror("ftruncate");
 }
 
-area = qemu_ram_mmap(fd, memory, block->mr->align,
+area = qemu_ram_mmap(fd, memory, block->mr->align, offset,
  block->flags & RAM_SHARED, block->flags & RAM_PMEM);
 if (area == MAP_FAILED) {
 error_setg_errno(errp, errno,
@@ -2277,7 +2278,7 @@ static void ram_block_add(RAMBlock *new_block, Error 
**errp, bool shared)

Re: [PATCH v4 3/6] s390x: Move initial reset

[Janosch Frank]

On 11/28/19 8:00 AM, Thomas Huth wrote:
> On 27/11/2019 18.50, Janosch Frank wrote:
>> Let's move the intial reset into the reset handler and cleanup
>> afterwards.
>>
>> Signed-off-by: Janosch Frank 
>> Reviewed-by: David Hildenbrand 
>> ---
>>   target/s390x/cpu-qom.h |  2 +-
>>   target/s390x/cpu.c | 44 --
>>   target/s390x/cpu.h |  2 +-
>>   target/s390x/sigp.c|  2 +-
>>   4 files changed, 20 insertions(+), 30 deletions(-)
>>
>> diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
>> index f3b71bac67..6f0a12042e 100644
>> --- a/target/s390x/cpu-qom.h
>> +++ b/target/s390x/cpu-qom.h
>> @@ -36,6 +36,7 @@ typedef struct S390CPUDef S390CPUDef;
>>   
>>   typedef enum cpu_reset_type {
>>   S390_CPU_RESET_NORMAL,
>> +S390_CPU_RESET_INITIAL,
>>   } cpu_reset_type;
>>   
>>   /**
>> @@ -62,7 +63,6 @@ typedef struct S390CPUClass {
>>   void (*parent_reset)(CPUState *cpu);
>>   void (*load_normal)(CPUState *cpu);
>>   void (*reset)(CPUState *cpu, cpu_reset_type type);
>> -void (*initial_cpu_reset)(CPUState *cpu);
>>   } S390CPUClass;
>>   
>>   typedef struct S390CPU S390CPU;
>> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
>> index 67d6fbfa44..55e2d1fe7b 100644
>> --- a/target/s390x/cpu.c
>> +++ b/target/s390x/cpu.c
>> @@ -94,6 +94,23 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
>> type)
>>   s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
>>   
>>   switch (type) {
>> +case S390_CPU_RESET_INITIAL:
>> +/* initial reset does not clear everything! */
>> +memset(&env->start_initial_reset_fields, 0,
>> +   offsetof(CPUS390XState, end_reset_fields) -
>> +   offsetof(CPUS390XState, start_initial_reset_fields));
>> +
>> +/* architectured initial value for Breaking-Event-Address register 
>> */
>> +env->gbea = 1;
>> +
>> +/* architectured initial values for CR 0 and 14 */
>> +env->cregs[0] = CR0_RESET;
>> +env->cregs[14] = CR14_RESET;
>> +
>> +/* tininess for underflow is detected before rounding */
>> +set_float_detect_tininess(float_tininess_before_rounding,
>> +  &env->fpu_status);
>> +   /* fall through */
>>   case S390_CPU_RESET_NORMAL:
>>   env->pfault_token = -1UL;
>>   env->bpbc = false;
>> @@ -101,32 +118,6 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
>> type)
>>   default:
>>   g_assert_not_reached();
>>   }
>> -}
>> -
>> -/* S390CPUClass::initial_reset() */
>> -static void s390_cpu_initial_reset(CPUState *s)
>> -{
>> -S390CPU *cpu = S390_CPU(s);
>> -CPUS390XState *env = &cpu->env;
>> -
>> -s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
>> -/* initial reset does not clear everything! */
>> -memset(&env->start_initial_reset_fields, 0,
>> -offsetof(CPUS390XState, end_reset_fields) -
>> -offsetof(CPUS390XState, start_initial_reset_fields));
>> -
>> -/* architectured initial values for CR 0 and 14 */
>> -env->cregs[0] = CR0_RESET;
>> -env->cregs[14] = CR14_RESET;
>> -
>> -/* architectured initial value for Breaking-Event-Address register */
>> -env->gbea = 1;
>> -
>> -env->pfault_token = -1UL;
>> -
>> -/* tininess for underflow is detected before rounding */
>> -set_float_detect_tininess(float_tininess_before_rounding,
>> -  &env->fpu_status);
>>   
>>   /* Reset state inside the kernel that we cannot access yet from QEMU. 
>> */
>>   if (kvm_enabled()) {
> 
> You're doing the if (kvm_enabled()) now also for S390_CPU_RESET_NORMAL 
> ... is that OK? It's doing an KVM_S390_INITIAL_RESET ioctl(), so that 
> sounds suspicious to me. Don't you have to add a check for type != 
> S390_CPU_RESET_NORMAL here?
> 
>   Thomas

Yes, I need to fence the NORMAL case again.

> 
> 




signature.asc
Description: OpenPGP digital signature

RE: [PATCH v6] backends/cryptodev: drop local_err from cryptodev_backend_complete()

[Gonglei (Arei)]

CCing qemu-triv...@nongnu.org

Reviewed-by: Gonglei 


Regards,
-Gonglei

> -Original Message-
> From: Vladimir Sementsov-Ogievskiy [mailto:vsement...@virtuozzo.com]
> Sent: Thursday, November 28, 2019 3:46 AM
> To: qemu-devel@nongnu.org
> Cc: Gonglei (Arei) ; marcandre.lur...@gmail.com;
> phi...@redhat.com; vsement...@virtuozzo.com
> Subject: [PATCH v6] backends/cryptodev: drop local_err from
> cryptodev_backend_complete()
> 
> No reason for local_err here, use errp directly instead.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Marc-André Lureau 
> ---
> 
> v6: add r-b by Philippe and Marc-André
> 
>  backends/cryptodev.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/backends/cryptodev.c b/backends/cryptodev.c index
> 3c071eab95..5a9735684e 100644
> --- a/backends/cryptodev.c
> +++ b/backends/cryptodev.c
> @@ -176,19 +176,10 @@ cryptodev_backend_complete(UserCreatable *uc,
> Error **errp)  {
>  CryptoDevBackend *backend = CRYPTODEV_BACKEND(uc);
>  CryptoDevBackendClass *bc = CRYPTODEV_BACKEND_GET_CLASS(uc);
> -Error *local_err = NULL;
> 
>  if (bc->init) {
> -bc->init(backend, &local_err);
> -if (local_err) {
> -goto out;
> -}
> +bc->init(backend, errp);
>  }
> -
> -return;
> -
> -out:
> -error_propagate(errp, local_err);
>  }
> 
>  void cryptodev_backend_set_used(CryptoDevBackend *backend, bool used)
> --
> 2.21.0

Re: [PATCH v4 4/6] s390x: Move clear reset

[Thomas Huth]

On 27/11/2019 18.50, Janosch Frank wrote:

Let's also move the clear reset function into the reset handler.

Signed-off-by: Janosch Frank 
---
  target/s390x/cpu-qom.h |  1 +
  target/s390x/cpu.c | 58 +-
  2 files changed, 18 insertions(+), 41 deletions(-)


I really wonder why we had so much duplicated code here before and 
nobody dared to clean it up in all those years... Thanks for doing that now!


Reviewed-by: Thomas Huth 

Re: [PATCH v4 3/6] s390x: Move initial reset

[Thomas Huth]

On 27/11/2019 18.50, Janosch Frank wrote:

Let's move the intial reset into the reset handler and cleanup
afterwards.

Signed-off-by: Janosch Frank 
Reviewed-by: David Hildenbrand 
---
  target/s390x/cpu-qom.h |  2 +-
  target/s390x/cpu.c | 44 --
  target/s390x/cpu.h |  2 +-
  target/s390x/sigp.c|  2 +-
  4 files changed, 20 insertions(+), 30 deletions(-)

diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
index f3b71bac67..6f0a12042e 100644
--- a/target/s390x/cpu-qom.h
+++ b/target/s390x/cpu-qom.h
@@ -36,6 +36,7 @@ typedef struct S390CPUDef S390CPUDef;
  
  typedef enum cpu_reset_type {

  S390_CPU_RESET_NORMAL,
+S390_CPU_RESET_INITIAL,
  } cpu_reset_type;
  
  /**

@@ -62,7 +63,6 @@ typedef struct S390CPUClass {
  void (*parent_reset)(CPUState *cpu);
  void (*load_normal)(CPUState *cpu);
  void (*reset)(CPUState *cpu, cpu_reset_type type);
-void (*initial_cpu_reset)(CPUState *cpu);
  } S390CPUClass;
  
  typedef struct S390CPU S390CPU;

diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 67d6fbfa44..55e2d1fe7b 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -94,6 +94,23 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
  s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
  
  switch (type) {

+case S390_CPU_RESET_INITIAL:
+/* initial reset does not clear everything! */
+memset(&env->start_initial_reset_fields, 0,
+   offsetof(CPUS390XState, end_reset_fields) -
+   offsetof(CPUS390XState, start_initial_reset_fields));
+
+/* architectured initial value for Breaking-Event-Address register */
+env->gbea = 1;
+
+/* architectured initial values for CR 0 and 14 */
+env->cregs[0] = CR0_RESET;
+env->cregs[14] = CR14_RESET;
+
+/* tininess for underflow is detected before rounding */
+set_float_detect_tininess(float_tininess_before_rounding,
+  &env->fpu_status);
+   /* fall through */
  case S390_CPU_RESET_NORMAL:
  env->pfault_token = -1UL;
  env->bpbc = false;
@@ -101,32 +118,6 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
type)
  default:
  g_assert_not_reached();
  }
-}
-
-/* S390CPUClass::initial_reset() */
-static void s390_cpu_initial_reset(CPUState *s)
-{
-S390CPU *cpu = S390_CPU(s);
-CPUS390XState *env = &cpu->env;
-
-s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
-/* initial reset does not clear everything! */
-memset(&env->start_initial_reset_fields, 0,
-offsetof(CPUS390XState, end_reset_fields) -
-offsetof(CPUS390XState, start_initial_reset_fields));
-
-/* architectured initial values for CR 0 and 14 */
-env->cregs[0] = CR0_RESET;
-env->cregs[14] = CR14_RESET;
-
-/* architectured initial value for Breaking-Event-Address register */
-env->gbea = 1;
-
-env->pfault_token = -1UL;
-
-/* tininess for underflow is detected before rounding */
-set_float_detect_tininess(float_tininess_before_rounding,
-  &env->fpu_status);
  
  /* Reset state inside the kernel that we cannot access yet from QEMU. */

  if (kvm_enabled()) {


You're doing the if (kvm_enabled()) now also for S390_CPU_RESET_NORMAL 
... is that OK? It's doing an KVM_S390_INITIAL_RESET ioctl(), so that 
sounds suspicious to me. Don't you have to add a check for type != 
S390_CPU_RESET_NORMAL here?


 Thomas

Re: [RFC 00/10] R300 QEMU device V2

[Aaron Zakhrov]

I tested my code with the vgabios-ati.bin rom file and it seems to get
passed the earlier issue I had.
I have cleaned up my code and have sent a new patch series. The new one is
pretty big but it contains only the necessary header files and it should be
a little easier to review

On Wed, Nov 27, 2019 at 10:02 PM Daniel P. Berrangé 
wrote:

> On Wed, Nov 27, 2019 at 05:12:10PM +0100, Gerd Hoffmann wrote:
> >   Hi,
> >
> > > It does become a slight usability issue, as any users need to go and
> find
> > > the suitable BIOS in order to use the device. No downstream OS vendors
> are
> > > going to be able to distribute this BIOS either
> > >
> > > I don't know if we have hit this problem before & if we have any
> > > general policies about it ?
> >
> > Booting from lsi scsi adapter used to work with a vendor bios only
> > loong ago.  Fixed by adding an lsi driver to seabios.
> >
> > Building a r300 vgabios shouldn't be too hard, we already have
> > support in seavgabios for the other ati variants emulated by qemu.
>
> That sounds reasonable, so it is fine to add r300 to QEMU without the BIOS.
>
> 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 :|
>
>

[RFC 0/1] ATI R300 emulated grpahics card V2

[aaron . zakhrov]

From: Aaron Dominick 

This is the cleaned up patchset to my previous RFC patch set.
I could not reliably clean up my previous commits so I deleted my fork and 
started from scratch.
The patch looks like a lot of changes but most of it is just register 
definitions copied from the kernel radeon DRM tree.
What I have implemented so far seems to get a Linux guest to load the DRM and 
KMS drivers but it cannot find any CRTCs.
dmesg also says that while the GART is allocated, it cannot bind any pages to 
it.


Aaron Dominick (1):
  Cleaned up Work tree. The radeon_reg.h r300_reg.h and r500_reg.h files
are from the kernel drm tree. They contain the register definitions
for the R300 GPU

 hw/display/Kconfig   |9 +-
 hw/display/Makefile.objs |2 +
 hw/display/r100d.h   |  869 +
 hw/display/r300.c| 1087 +++
 hw/display/r300.h|  269 +++
 hw/display/r300_2d.c |  190 ++
 hw/display/r300_debug.c  |  272 +++
 hw/display/r300_reg.h| 1789 ++
 hw/display/r300d.h   |  343 
 hw/display/r500_reg.h|  801 
 hw/display/radeon_reg.h  | 3725 ++
 11 files changed, 9355 insertions(+), 1 deletion(-)
 create mode 100644 hw/display/r100d.h
 create mode 100644 hw/display/r300.c
 create mode 100644 hw/display/r300.h
 create mode 100644 hw/display/r300_2d.c
 create mode 100644 hw/display/r300_debug.c
 create mode 100644 hw/display/r300_reg.h
 create mode 100644 hw/display/r300d.h
 create mode 100644 hw/display/r500_reg.h
 create mode 100644 hw/display/radeon_reg.h

--
2.24.0

Re: [PATCH v4 2/6] s390x: Move reset normal to shared reset handler

[Thomas Huth]

On 27/11/2019 18.50, Janosch Frank wrote:

Let's start moving the cpu reset functions into a single function with
a switch/case, so we can use fallthroughs and share more code between
resets.


Nit: I'd add a "later" in above sentence, since you don't use 
fallthroughs yet.



This patch introduces the reset function by renaming cpu_reset() and
cleaning up leftovers.


Hmm, which leftovers? I can mainly see the renaming here...


Signed-off-by: Janosch Frank 
Reviewed-by: David Hildenbrand 
---
  target/s390x/cpu-qom.h |  6 +-
  target/s390x/cpu.c | 19 +--
  target/s390x/cpu.h |  2 +-
  target/s390x/sigp.c|  2 +-
  4 files changed, 20 insertions(+), 9 deletions(-)


Anyway,
Reviewed-by: Thomas Huth 

Re: [PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them

[Cameron Esfahani via]

I added some asserts to our internal version of QEMU.  It's a few months off of 
master and, specifically, doesn't have fd13f23b8c95311eff74426921557eee592b0ed3.

With the previous version of hvf_inject_interrupts(), before our fix, the code 
looked like the following:

> if (env->interrupt_injected != -1) {
> vector = env->interrupt_injected;
> intr_type = VMCS_INTR_T_SWINTR;
> } else if (env->exception_injected != -1) {


What we were seeing was, under heavy loads, running many concurrent macOS VMs, 
that we would get spurious interrupts.  Tracking it down, we discovered that 
VMCS_INTR_T_SWINTR was getting injected when VMCS_INTR_T_HWINTR was expected.

If I take our proposed patch code, which built on top of master from a few days 
ago, and has fd13f23b8c95311eff74426921557eee592b0ed3,  and add an assert, like 
the following:

> if (env->interrupt_injected != -1) {
> /* Type and vector are both saved in interrupt_injected. */
> vector = env->interrupt_injected & VMCS_IDT_VEC_VECNUM;
> intr_type = env->interrupt_injected & VMCS_IDT_VEC_TYPE;
> if (VMCS_INTR_T_SWINTR != intr_type) {
> printf("VMCS_INTR_T_SWINTR (%x) != intr_type (%llx)\n", 
> VMCS_INTR_T_SWINTR, intr_type);
> assert(VMCS_INTR_T_SWINTR == intr_type);
> }
> } else if (env->exception_nr != -1) {


Then we will see the assert trigger and get the following output:

> VMCS_INTR_T_SWINTR (400) != intr_type (0)
> Assertion failed: (VMCS_INTR_T_SWINTR == intr_type), function 
> hvf_inject_interrupts, file qemu_upstream/target/i386/hvf/x86hvf.c, line 362.


So, as far as I can see, the proposed changes are still necessary.

Cameron Esfahani
di...@apple.com

"Americans are very skilled at creating a custom meaning from something that's 
mass-produced."

Ann Powers


> On Nov 26, 2019, at 12:04 PM, Cameron Esfahani via  
> wrote:
> 
> Our test case was booting many concurrent macOS VMs under heavy system load.  
> I don't know if I could create one to replicate that.
> 
> Cameron Esfahani
> di...@apple.com
> 
> "In the elder days of Art, Builders wrought with greatest care each minute 
> and unseen part; For the gods see everywhere."
> 
> "The Builders", H. W. Longfellow
> 
> 
> 
>> On Nov 25, 2019, at 2:26 AM, Paolo Bonzini  wrote:
>> 
>> On 24/11/19 21:05, Cameron Esfahani wrote:
>>> Save away type as well as vector in hvf_store_events() so we can
>>> correctly reinject both in hvf_inject_interrupts().
>>> 
>>> Make sure to clear ins_len and has_error_code when ins_len isn't
>>> valid and error_code isn't set.
>> 
>> Do you have a testcase for this?  (I could guess it's about the INT1
>> instruction).
>> 
>> Paolo
>> 
> 
> 

[PATCH 3/4] target/arm: Prepare generic timer for per-platform CNTFRQ

[Andrew Jeffery]

The ASPEED AST2600 clocks the generic timer at the rate of HPLL. On
recent firmwares this is at 1125MHz, which is considerably quicker than
the assumed 62.5MHz of the current generic timer implementation. The
delta between the value as read from CNTFRQ and the true rate of the
underlying QEMUTimer leads to sticky behaviour in AST2600 guests.

Add a feature-gated property exposing CNTFRQ for ARM CPUs providing the
generic timer. This allows platforms to configure CNTFRQ (and the
associated QEMUTimer) to the appropriate frequency prior to starting the
guest.

As the platform can now determine the rate of CNTFRQ we're exposed to
limitations of QEMUTimer that didn't previously materialise: In the
course of emulation we need to arbitrarily and accurately convert
between guest ticks and time, but we're constrained by QEMUTimer's use
of an integer scaling factor. Its effect is QEMUTimer cannot exactly
capture the period of frequencies that do not cleanly divide
NANOSECONDS_PER_SECOND for scaling ticks to time. As such, provide an
equally inaccurate scaling factor for scaling time to ticks so at least
an self-consistent inverse relationship holds.

Signed-off-by: Andrew Jeffery 
---
 target/arm/cpu.c| 43 +--
 target/arm/cpu.h| 18 ++
 target/arm/helper.c |  9 -
 3 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 5698a74061bb..f186019a77fd 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -974,10 +974,12 @@ static void arm_cpu_initfn(Object *obj)
 if (tcg_enabled()) {
 cpu->psci_version = 2; /* TCG implements PSCI 0.2 */
 }
-
-cpu->gt_cntfrq = NANOSECONDS_PER_SECOND / GTIMER_SCALE;
 }
 
+static Property arm_cpu_gt_cntfrq_property =
+DEFINE_PROP_UINT64("cntfrq", ARMCPU, gt_cntfrq,
+   NANOSECONDS_PER_SECOND / GTIMER_SCALE);
+
 static Property arm_cpu_reset_cbar_property =
 DEFINE_PROP_UINT64("reset-cbar", ARMCPU, reset_cbar, 0);
 
@@ -1174,6 +1176,11 @@ void arm_cpu_post_init(Object *obj)
 
 qdev_property_add_static(DEVICE(obj), &arm_cpu_cfgend_property,
  &error_abort);
+
+if (arm_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER)) {
+qdev_property_add_static(DEVICE(cpu), &arm_cpu_gt_cntfrq_property,
+ &error_abort);
+}
 }
 
 static void arm_cpu_finalizefn(Object *obj)
@@ -1253,14 +1260,30 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 }
 }
 
-cpu->gt_timer[GTIMER_PHYS] = timer_new(QEMU_CLOCK_VIRTUAL, GTIMER_SCALE,
-   arm_gt_ptimer_cb, cpu);
-cpu->gt_timer[GTIMER_VIRT] = timer_new(QEMU_CLOCK_VIRTUAL, GTIMER_SCALE,
-   arm_gt_vtimer_cb, cpu);
-cpu->gt_timer[GTIMER_HYP] = timer_new(QEMU_CLOCK_VIRTUAL, GTIMER_SCALE,
-  arm_gt_htimer_cb, cpu);
-cpu->gt_timer[GTIMER_SEC] = timer_new(QEMU_CLOCK_VIRTUAL, GTIMER_SCALE,
-  arm_gt_stimer_cb, cpu);
+
+{
+uint64_t scale;
+
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+if (!cpu->gt_cntfrq) {
+error_setg(errp, "Invalid CNTFRQ: %"PRId64"Hz",
+   cpu->gt_cntfrq);
+return;
+}
+scale = gt_cntfrq_period_ns(cpu);
+} else {
+scale = GTIMER_SCALE;
+}
+
+cpu->gt_timer[GTIMER_PHYS] = timer_new(QEMU_CLOCK_VIRTUAL, scale,
+   arm_gt_ptimer_cb, cpu);
+cpu->gt_timer[GTIMER_VIRT] = timer_new(QEMU_CLOCK_VIRTUAL, scale,
+   arm_gt_vtimer_cb, cpu);
+cpu->gt_timer[GTIMER_HYP] = timer_new(QEMU_CLOCK_VIRTUAL, scale,
+  arm_gt_htimer_cb, cpu);
+cpu->gt_timer[GTIMER_SEC] = timer_new(QEMU_CLOCK_VIRTUAL, scale,
+  arm_gt_stimer_cb, cpu);
+}
 #endif
 
 cpu_exec_realizefn(cs, &local_err);
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 666c03871fdf..0bcd13dcac81 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -939,6 +939,24 @@ struct ARMCPU {
 
 static inline unsigned int gt_cntfrq_period_ns(ARMCPU *cpu)
 {
+/*
+ * The exact approach to calculating guest ticks is:
+ *
+ * muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL), cpu->gt_cntfrq,
+ *  NANOSECONDS_PER_SECOND);
+ *
+ * We don't do that. Rather we intentionally use integer division
+ * truncation below and in the caller for the conversion of host monotonic
+ * time to guest ticks to provide the exact inverse for the semantics of
+ * the QEMUTimer scale factor. QEMUTimer's scale facter is an integer, so
+ * it loses precision when representing f

[PATCH 0/4] Expose GT CNTFRQ as a CPU property to support AST2600

[Andrew Jeffery]

Hello,

This is a belated follow-up from a few of my earlier attempts to fix up the
ARM generic timer for correct behaviour on the ASPEED AST2600 SoC. The AST2600
clocks the generic timer at the rate of HPLL, which is configured to 1125MHz.
This is significantly quicker than the currently hard-coded generic timer rate
of 62.5MHz and so we see "sticky" behaviour in the guest.

Please review.

Andrew

Andrew Jeffery (4):
  target/arm: Remove redundant scaling of nexttick
  target/arm: Abstract the generic timer frequency
  target/arm: Prepare generic timer for per-platform CNTFRQ
  ast2600: Configure CNTFRQ at 1125MHz

 hw/arm/aspeed_ast2600.c |  3 +++
 target/arm/cpu.c| 41 +
 target/arm/cpu.h| 28 
 target/arm/helper.c | 24 ++--
 4 files changed, 82 insertions(+), 14 deletions(-)

-- 
2.20.1

[PATCH 2/4] target/arm: Abstract the generic timer frequency

[Andrew Jeffery]

Prepare for SoCs such as the ASPEED AST2600 whose firmware configures
CNTFRQ to values significantly larger than the static 62.5MHz value
currently derived from GTIMER_SCALE. As the OS potentially derives its
timer periods from the CNTFRQ value the lack of support for running
QEMUTimers at the appropriate rate leads to sticky behaviour in the
guest.

Substitute the GTIMER_SCALE constant with use of a helper to derive the
period from gt_cntfrq stored in struct ARMCPU. Initially set gt_cntfrq
to the frequency associated with GTIMER_SCALE so current behaviour is
maintained.

Signed-off-by: Andrew Jeffery 
---
 target/arm/cpu.c|  2 ++
 target/arm/cpu.h| 10 ++
 target/arm/helper.c | 10 +++---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 7a4ac9339bf9..5698a74061bb 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -974,6 +974,8 @@ static void arm_cpu_initfn(Object *obj)
 if (tcg_enabled()) {
 cpu->psci_version = 2; /* TCG implements PSCI 0.2 */
 }
+
+cpu->gt_cntfrq = NANOSECONDS_PER_SECOND / GTIMER_SCALE;
 }
 
 static Property arm_cpu_reset_cbar_property =
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 83a809d4bac4..666c03871fdf 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -932,8 +932,18 @@ struct ARMCPU {
  */
 DECLARE_BITMAP(sve_vq_map, ARM_MAX_VQ);
 DECLARE_BITMAP(sve_vq_init, ARM_MAX_VQ);
+
+/* Generic timer counter frequency, in Hz */
+uint64_t gt_cntfrq;
 };
 
+static inline unsigned int gt_cntfrq_period_ns(ARMCPU *cpu)
+{
+/* XXX: Could include qemu/timer.h to get NANOSECONDS_PER_SECOND? */
+const unsigned int ns_per_s = 1000 * 1000 * 1000;
+return ns_per_s > cpu->gt_cntfrq ? ns_per_s / cpu->gt_cntfrq : 1;
+}
+
 void arm_cpu_post_init(Object *obj);
 
 uint64_t arm_cpu_mp_affinity(int idx, uint8_t clustersz);
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 65c4441a3896..1cc0551081a0 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -2409,7 +2409,9 @@ static CPAccessResult gt_stimer_access(CPUARMState *env,
 
 static uint64_t gt_get_countervalue(CPUARMState *env)
 {
-return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) / GTIMER_SCALE;
+ARMCPU *cpu = env_archcpu(env);
+
+return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) / gt_cntfrq_period_ns(cpu);
 }
 
 static void gt_recalc_timer(ARMCPU *cpu, int timeridx)
@@ -2445,7 +2447,7 @@ static void gt_recalc_timer(ARMCPU *cpu, int timeridx)
  * set the timer for as far in the future as possible. When the
  * timer expires we will reset the timer for any remaining period.
  */
-if (nexttick > INT64_MAX / GTIMER_SCALE) {
+if (nexttick > INT64_MAX / gt_cntfrq_period_ns(cpu)) {
 timer_mod_ns(cpu->gt_timer[timeridx], INT64_MAX);
 } else {
 timer_mod(cpu->gt_timer[timeridx], nexttick);
@@ -2874,11 +2876,13 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
 
 static uint64_t gt_virt_cnt_read(CPUARMState *env, const ARMCPRegInfo *ri)
 {
+ARMCPU *cpu = env_archcpu(env);
+
 /* Currently we have no support for QEMUTimer in linux-user so we
  * can't call gt_get_countervalue(env), instead we directly
  * call the lower level functions.
  */
-return cpu_get_clock() / GTIMER_SCALE;
+return cpu_get_clock() / gt_cntfrq_period(cpu);
 }
 
 static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
-- 
2.20.1

[PATCH 4/4] ast2600: Configure CNTFRQ at 1125MHz

[Andrew Jeffery]

This matches the configuration set by u-boot on the AST2600.

Signed-off-by: Andrew Jeffery 
---
 hw/arm/aspeed_ast2600.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 931887ac681f..5aecc3b3caec 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -259,6 +259,9 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 object_property_set_int(OBJECT(&s->cpu[i]), aspeed_calc_affinity(i),
 "mp-affinity", &error_abort);
 
+object_property_set_int(OBJECT(&s->cpu[i]), 112500, "cntfrq",
+&error_abort);
+
 /*
  * TODO: the secondary CPUs are started and a boot helper
  * is needed when using -kernel
-- 
2.20.1

[PATCH 1/4] target/arm: Remove redundant scaling of nexttick

[Andrew Jeffery]

The corner-case codepath was adjusting nexttick such that overflow
wouldn't occur when timer_mod() scaled the value back up. Remove a use
of GTIMER_SCALE and avoid unnecessary operations by calling
timer_mod_ns() directly.

Signed-off-by: Andrew Jeffery 
---
 target/arm/helper.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index a089fb5a6909..65c4441a3896 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -2446,9 +2446,10 @@ static void gt_recalc_timer(ARMCPU *cpu, int timeridx)
  * timer expires we will reset the timer for any remaining period.
  */
 if (nexttick > INT64_MAX / GTIMER_SCALE) {
-nexttick = INT64_MAX / GTIMER_SCALE;
+timer_mod_ns(cpu->gt_timer[timeridx], INT64_MAX);
+} else {
+timer_mod(cpu->gt_timer[timeridx], nexttick);
 }
-timer_mod(cpu->gt_timer[timeridx], nexttick);
 trace_arm_gt_recalc(timeridx, irqstate, nexttick);
 } else {
 /* Timer disabled: ISTATUS and timer output always clear */
-- 
2.20.1

Re: [PATCH v18 3/8] numa: Extend CLI to provide memory side cache information

[Tao Xu]

On 11/28/2019 10:46 AM, Tao Xu wrote:

On 11/27/2019 5:56 PM, Markus Armbruster wrote:

Tao Xu  writes:


From: Liu Jingqi 

Add -numa hmat-cache option to provide Memory Side Cache Information.
These memory attributes help to build Memory Side Cache Information
Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).


Please mention this requires -machine hmat=on.


OK I will add these for 3 related patches.



Reviewed-by: Igor Mammedov 
Reviewed-by: Daniel Black 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 

[...]

diff --git a/qapi/machine.json b/qapi/machine.json
index c741649d7b..3d0ba226a9 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -428,10 +428,12 @@
  #
  # @hmat-lb: memory latency and bandwidth information (Since: 5.0)
  #
+# @hmat-cache: memory side cache information (Since: 5.0)
+#
  # Since: 2.1
  ##
  { 'enum': 'NumaOptionsType',
-  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
+  'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] }
  ##
  # @NumaOptions:
@@ -447,7 +449,8 @@
  'node': 'NumaNodeOptions',
  'dist': 'NumaDistOptions',
  'cpu': 'NumaCpuOptions',
-    'hmat-lb': 'NumaHmatLBOptions' }}
+    'hmat-lb': 'NumaHmatLBOptions',
+    'hmat-cache': 'NumaHmatCacheOptions' }}
  ##
  # @NumaNodeOptions:
@@ -647,6 +650,77 @@
  '*latency': 'uint64',
  '*bandwidth': 'size' }}
+##
+# @HmatCacheAssociativity:
+#
+# Cache associativity in the Memory Side Cache
+# Information Structure of HMAT
+#
+# For more information of @HmatCacheAssociativity see
+# the chapter 5.2.27.5: Table 5-147 of ACPI 6.3 spec.


   # Cache associativity in the Memory Side Cache Information Structure
   # of HMAT
   #
   # For more information of @HmatCacheAssociativity, see chapter
   # 5.2.27.5: Table 5-147 of ACPI 6.3 spec.


+#
+# @none: None


What does cache associativity @none mean?  A none-associative cache?  I
guess it makes sense to people familiar with the ACPI spec...



This means this proximity domain has no memory cache, thus none for 
Cache associativity, I will add more description about this.


Read again about ACPI spec, there is no description about 'none'. In
linux kernel HMAT code, this is handle as "other", maybe means not 
provided. I will also add a check when level is none, the associativity, 
policy and line_size should be none or 0.

Re: [RFC net-next 00/18] virtio_net XDP offload

[Jason Wang]

On 2019/11/28 上午11:32, Alexei Starovoitov wrote:

On Tue, Nov 26, 2019 at 12:35:14PM -0800, Jakub Kicinski wrote:

I'd appreciate if others could chime in.

The performance improvements are quite appealing.
In general offloading from higher layers into lower layers is necessary long 
term.

But the approach taken by patches 15 and 17 is a dead end. I don't see how it
can ever catch up with the pace of bpf development.



This applies for any hardware offloading features, isn't it?



  As presented this approach
works for the most basic programs and simple maps. No line info, no BTF, no
debuggability. There are no tail_calls either.



If I understand correctly, neither of above were implemented in NFP. We 
can collaborate to find solution for all of those.




  I don't think I've seen a single
production XDP program that doesn't use tail calls.



It looks to me we can manage to add this support.



Static and dynamic linking
is coming. Wraping one bpf feature at a time with virtio api is never going to
be complete.



It's a common problem for hardware that want to implement eBPF 
offloading, not a virtio specific one.




How FDs are going to be passed back? OBJ_GET_INFO_BY_FD ?
OBJ_PIN/GET ? Where bpffs is going to live ?



If we want pinning work in the case of virt, it should live in both host 
and guest probably.




  Any realistic XDP application will
be using a lot more than single self contained XDP prog with hash and array
maps.



It's possible if we want to use XDP offloading to accelerate VNF which 
often has simple logic.




It feels that the whole sys_bpf needs to be forwarded as a whole from
guest into host. In case of true hw offload the host is managing HW. So it
doesn't forward syscalls into the driver. The offload from guest into host is
different. BPF can be seen as a resource that host provides and guest kernel
plus qemu would be forwarding requests between guest user space and host
kernel. Like sys_bpf(BPF_MAP_CREATE) can passthrough into the host directly.
The FD that hosts sees would need a corresponding mirror FD in the guest. There
are still questions about bpffs paths, but the main issue of
one-feature-at-a-time will be addressed in such approach.



We try to follow what NFP did by starting from a fraction of the whole 
eBPF features. It would be very hard to have all eBPF features 
implemented from the start.  It would be helpful to clarify what's the 
minimal set of features that you want to have from the start.




There could be other
solutions, of course.




Suggestions are welcomed.

Thanks

Re: [PATCH v6 00/20] ppc/pnv: add XIVE support for KVM guests

[David Gibson]

On Mon, Nov 25, 2019 at 07:58:00AM +0100, Cédric Le Goater wrote:
> Hello,
> 
> The QEMU PowerNV machine emulates a baremetal OpenPOWER system and
> acts as an hypervisor (L0). Supporting emulation of KVM to run guests
> (L1) requires a few more extensions, among which guest support for the
> XIVE interrupt controller on POWER9 processor.
> 
> The following changes extend the XIVE models with the new XiveFabric
> and XivePresenter interfaces to provide support for XIVE escalations
> and interrupt resend. This mechanism is used by XIVE to notify the
> hypervisor that a vCPU is not dispatched on a HW thread. Tested on a
> QEMU PowerNV machine and a simple QEMU pseries guest doing network on
> a local bridge.
> 
> The XIVE interrupt controller offers a way to increase the XIVE
> resources per chip by configuring multiple XIVE blocks on a chip. This
> is not currently supported by the model. However, some configurations,
> such as OPAL/skiboot, use one block-per-chip configuration with some
> optimizations. One of them is to override the hardwired chip ID by the
> block id in the PowerBUS operations and for CAM line compares. This
> patchset improves the support for this setup. Tested with 4 chips.
> 
> A series from Suraj adding guest support in the Radix MMU model of the
> QEMU PowerNV machine is still required and will be send later. The
> whole patchset can be found under :
> 
>   https://github.com/legoater/qemu/tree/powernv-4.2

I now have all of this applied to the ppc-for-5.0 branch.

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


signature.asc
Description: PGP signature

Re: [PATCH v6 16/20] ppc/xive: Introduce a xive_tctx_ipb_update() helper

[David Gibson]

On Wed, Nov 27, 2019 at 09:50:50AM +0100, Greg Kurz wrote:
65;5802;1c> On Mon, 25 Nov 2019 07:58:16 +0100
> Cédric Le Goater  wrote:
> 
> > We will use it to resend missed interrupts when a vCPU context is
> > pushed on a HW thread.
> > 
> > Signed-off-by: Cédric Le Goater 
> > ---
> >  include/hw/ppc/xive.h |  1 +
> >  hw/intc/xive.c| 21 +++--
> >  2 files changed, 12 insertions(+), 10 deletions(-)
> > 
> > diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> > index 24315480e7c2..9c0bf2c301e2 100644
> > --- a/include/hw/ppc/xive.h
> > +++ b/include/hw/ppc/xive.h
> > @@ -469,6 +469,7 @@ void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor 
> > *mon);
> >  Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, Error **errp);
> >  void xive_tctx_reset(XiveTCTX *tctx);
> >  void xive_tctx_destroy(XiveTCTX *tctx);
> > +void xive_tctx_ipb_update(XiveTCTX *tctx, uint8_t ring, uint8_t ipb);
> >  
> >  /*
> >   * KVM XIVE device helpers
> > diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> > index 4bff3abdc3eb..7047e45daca1 100644
> > --- a/hw/intc/xive.c
> > +++ b/hw/intc/xive.c
> > @@ -47,12 +47,6 @@ static uint8_t ipb_to_pipr(uint8_t ibp)
> >  return ibp ? clz32((uint32_t)ibp << 24) : 0xff;
> >  }
> >  
> > -static void ipb_update(uint8_t *regs, uint8_t priority)
> > -{
> > -regs[TM_IPB] |= priority_to_ipb(priority);
> > -regs[TM_PIPR] = ipb_to_pipr(regs[TM_IPB]);
> > -}
> > -
> >  static uint8_t exception_mask(uint8_t ring)
> >  {
> >  switch (ring) {
> > @@ -135,6 +129,15 @@ static void xive_tctx_set_cppr(XiveTCTX *tctx, uint8_t 
> > ring, uint8_t cppr)
> >  xive_tctx_notify(tctx, ring);
> >  }
> >  
> > +void xive_tctx_ipb_update(XiveTCTX *tctx, uint8_t ring, uint8_t ipb)
> > +{
> > +uint8_t *regs = &tctx->regs[ring];
> > +
> > +regs[TM_IPB] |= ipb;
> > +regs[TM_PIPR] = ipb_to_pipr(regs[TM_IPB]);
> > +xive_tctx_notify(tctx, ring);
> > +}
> > +
> 
> Maybe rename the helper to xive_tctx_update_ipb_and_notify() to
> make it clear this raises an irq in the end ?

I'm actually happy enough with the name as is.  I think it's
reasonable for "update" on a register which has active effects on the
real hardware to implicitly have the same effects in the qemu model.

Applied to ppc-for-5.0.

> 
> This can be done as follow-up though and the rest looks good, so:
> 
> Reviewed-by: Greg Kurz 
> 
> >  static inline uint32_t xive_tctx_word2(uint8_t *ring)
> >  {
> >  return *((uint32_t *) &ring[TM_WORD2]);
> > @@ -336,8 +339,7 @@ static void xive_tm_set_os_cppr(XivePresenter *xptr, 
> > XiveTCTX *tctx,
> >  static void xive_tm_set_os_pending(XivePresenter *xptr, XiveTCTX *tctx,
> > hwaddr offset, uint64_t value, unsigned 
> > size)
> >  {
> > -ipb_update(&tctx->regs[TM_QW1_OS], value & 0xff);
> > -xive_tctx_notify(tctx, TM_QW1_OS);
> > +xive_tctx_ipb_update(tctx, TM_QW1_OS, priority_to_ipb(value & 0xff));
> >  }
> >  
> >  static void xive_os_cam_decode(uint32_t cam, uint8_t *nvt_blk,
> > @@ -1429,8 +1431,7 @@ static bool xive_presenter_notify(uint8_t format,
> >  
> >  /* handle CPU exception delivery */
> >  if (count) {
> > -ipb_update(&match.tctx->regs[match.ring], priority);
> > -xive_tctx_notify(match.tctx, match.ring);
> > +xive_tctx_ipb_update(match.tctx, match.ring, 
> > priority_to_ipb(priority));
> >  }
> >  
> >  return !!count;
> 

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


signature.asc
Description: PGP signature

Re: [PATCH v6 13/20] ppc/pnv: Clarify how the TIMA is accessed on a multichip system

[David Gibson]

On Wed, Nov 27, 2019 at 07:57:31AM +0100, Cédric Le Goater wrote:
> On 27/11/2019 06:23, David Gibson wrote:
> > On Mon, Nov 25, 2019 at 07:58:13AM +0100, Cédric Le Goater wrote:
> >> The TIMA region gives access to the thread interrupt context registers
> >> of a CPU. It is mapped at the same address on all chips and can be
> >> accessed by any CPU of the system. To identify the chip from which the
> >> access is being done, the PowerBUS uses a 'chip' field in the
> >> load/store messages. QEMU does not model these messages, instead, we
> >> extract the chip id from the CPU PIR and do a lookup at the machine
> >> level to fetch the targeted interrupt controller.
> >>
> >> Introduce pnv_get_chip() and pnv_xive_tm_get_xive() helpers to clarify
> >> this process in pnv_xive_get_tctx(). The latter will be removed in the
> >> subsequent patches but the same principle will be kept.
> >>
> >> Signed-off-by: Cédric Le Goater 
> >> ---
> >>  include/hw/ppc/pnv.h |  3 +++
> >>  hw/intc/pnv_xive.c   | 40 +++-
> >>  hw/ppc/pnv.c | 14 ++
> >>  3 files changed, 40 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> >> index a58cfea3f2fd..3a7bc3c57e0d 100644
> >> --- a/include/hw/ppc/pnv.h
> >> +++ b/include/hw/ppc/pnv.h
> >> @@ -103,6 +103,7 @@ typedef struct Pnv9Chip {
> >>   * A SMT8 fused core is a pair of SMT4 cores.
> >>   */
> >>  #define PNV9_PIR2FUSEDCORE(pir) (((pir) >> 3) & 0xf)
> >> +#define PNV9_PIR2CHIP(pir)  (((pir) >> 8) & 0x7f)
> >>  
> >>  typedef struct PnvChipClass {
> >>  /*< private >*/
> >> @@ -197,6 +198,8 @@ static inline bool pnv_is_power9(PnvMachineState *pnv)
> >>  return pnv_chip_is_power9(pnv->chips[0]);
> >>  }
> >>  
> >> +PnvChip *pnv_get_chip(uint32_t chip_id);
> >> +
> >>  #define PNV_FDT_ADDR  0x0100
> >>  #define PNV_TIMEBASE_FREQ 51200ULL
> >>  
> >> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> >> index 95e9de312cd9..db9d9c11a8f4 100644
> >> --- a/hw/intc/pnv_xive.c
> >> +++ b/hw/intc/pnv_xive.c
> >> @@ -439,31 +439,37 @@ static int pnv_xive_match_nvt(XivePresenter *xptr, 
> >> uint8_t format,
> >>  return count;
> >>  }
> >>  
> >> +/*
> >> + * The TIMA MMIO space is shared among the chips and to identify the
> >> + * chip from which the access is being done, we extract the chip id
> >> + * from the PIR.
> >> + */
> >> +static PnvXive *pnv_xive_tm_get_xive(PowerPCCPU *cpu)
> >> +{
> >> +int pir = ppc_cpu_pir(cpu);
> >> +PnvChip *chip;
> >> +PnvXive *xive;
> >> +
> >> +chip = pnv_get_chip(PNV9_PIR2CHIP(pir));
> >> +assert(chip);
> >> +xive = &PNV9_CHIP(chip)->xive;
> >> +
> >> +if (!pnv_xive_is_cpu_enabled(xive, cpu)) {
> >> +xive_error(xive, "IC: CPU %x is not enabled", pir);
> >> +}
> >> +return xive;
> >> +}
> >> +
> >>  static XiveTCTX *pnv_xive_get_tctx(XiveRouter *xrtr, CPUState *cs)
> >>  {
> >>  PowerPCCPU *cpu = POWERPC_CPU(cs);
> >> -XiveTCTX *tctx = XIVE_TCTX(pnv_cpu_state(cpu)->intc);
> >> -PnvXive *xive = NULL;
> >> -CPUPPCState *env = &cpu->env;
> >> -int pir = env->spr_cb[SPR_PIR].default_value;
> >> +PnvXive *xive = pnv_xive_tm_get_xive(cpu);
> >>  
> >> -/*
> >> - * Perform an extra check on the HW thread enablement.
> >> - *
> >> - * The TIMA is shared among the chips and to identify the chip
> >> - * from which the access is being done, we extract the chip id
> >> - * from the PIR.
> >> - */
> >> -xive = pnv_xive_get_ic((pir >> 8) & 0xf);
> >>  if (!xive) {
> >>  return NULL;
> >>  }
> >>  
> >> -if (!(xive->regs[PC_THREAD_EN_REG0 >> 3] & PPC_BIT(pir & 0x3f))) {
> > 
> > I'm not seeing any code which will replace this check on the thread
> > enabled register.  Is that really what you intend?
> 
> it is calling pnv_xive_tm_get_xive() which calls pnv_xive_is_cpu_enabled()
> which does the same check in better.

Ah, yes of course, thanks.

Applied to ppc-for-5.0.

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


signature.asc
Description: PGP signature

Re: [PATCH v6 15/20] ppc/xive: Remove the get_tctx() XiveRouter handler

[David Gibson]

On Mon, Nov 25, 2019 at 07:58:15AM +0100, Cédric Le Goater wrote:
> It is now unused.
> 
> Reviewed-by: Greg Kurz 
> Signed-off-by: Cédric Le Goater 

14..15 applied to ppc-for-5.0.

> ---
>  include/hw/ppc/xive.h |  2 --
>  hw/intc/pnv_xive.c| 13 -
>  hw/intc/spapr_xive.c  |  8 
>  hw/intc/xive.c|  7 ---
>  4 files changed, 30 deletions(-)
> 
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index dcf897451589..24315480e7c2 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -351,7 +351,6 @@ typedef struct XiveRouterClass {
> XiveNVT *nvt);
>  int (*write_nvt)(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
>   XiveNVT *nvt, uint8_t word_number);
> -XiveTCTX *(*get_tctx)(XiveRouter *xrtr, CPUState *cs);
>  } XiveRouterClass;
>  
>  int xive_router_get_eas(XiveRouter *xrtr, uint8_t eas_blk, uint32_t eas_idx,
> @@ -364,7 +363,6 @@ int xive_router_get_nvt(XiveRouter *xrtr, uint8_t 
> nvt_blk, uint32_t nvt_idx,
>  XiveNVT *nvt);
>  int xive_router_write_nvt(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t 
> nvt_idx,
>XiveNVT *nvt, uint8_t word_number);
> -XiveTCTX *xive_router_get_tctx(XiveRouter *xrtr, CPUState *cs);
>  void xive_router_notify(XiveNotifier *xn, uint32_t lisn);
>  
>  /*
> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> index c14a2d186960..216ebc150a41 100644
> --- a/hw/intc/pnv_xive.c
> +++ b/hw/intc/pnv_xive.c
> @@ -460,18 +460,6 @@ static PnvXive *pnv_xive_tm_get_xive(PowerPCCPU *cpu)
>  return xive;
>  }
>  
> -static XiveTCTX *pnv_xive_get_tctx(XiveRouter *xrtr, CPUState *cs)
> -{
> -PowerPCCPU *cpu = POWERPC_CPU(cs);
> -PnvXive *xive = pnv_xive_tm_get_xive(cpu);
> -
> -if (!xive) {
> -return NULL;
> -}
> -
> -return XIVE_TCTX(pnv_cpu_state(cpu)->intc);
> -}
> -
>  /*
>   * The internal sources (IPIs) of the interrupt controller have no
>   * knowledge of the XIVE chip on which they reside. Encode the block
> @@ -1900,7 +1888,6 @@ static void pnv_xive_class_init(ObjectClass *klass, 
> void *data)
>  xrc->write_end = pnv_xive_write_end;
>  xrc->get_nvt = pnv_xive_get_nvt;
>  xrc->write_nvt = pnv_xive_write_nvt;
> -xrc->get_tctx = pnv_xive_get_tctx;
>  
>  xnc->notify = pnv_xive_notify;
>  xpc->match_nvt  = pnv_xive_match_nvt;
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 6292da58f62c..1542cef91878 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -427,13 +427,6 @@ static int spapr_xive_write_nvt(XiveRouter *xrtr, 
> uint8_t nvt_blk,
>  g_assert_not_reached();
>  }
>  
> -static XiveTCTX *spapr_xive_get_tctx(XiveRouter *xrtr, CPUState *cs)
> -{
> -PowerPCCPU *cpu = POWERPC_CPU(cs);
> -
> -return spapr_cpu_state(cpu)->tctx;
> -}
> -
>  static int spapr_xive_match_nvt(XivePresenter *xptr, uint8_t format,
>  uint8_t nvt_blk, uint32_t nvt_idx,
>  bool cam_ignore, uint8_t priority,
> @@ -771,7 +764,6 @@ static void spapr_xive_class_init(ObjectClass *klass, 
> void *data)
>  xrc->write_end = spapr_xive_write_end;
>  xrc->get_nvt = spapr_xive_get_nvt;
>  xrc->write_nvt = spapr_xive_write_nvt;
> -xrc->get_tctx = spapr_xive_get_tctx;
>  
>  sicc->activate = spapr_xive_activate;
>  sicc->deactivate = spapr_xive_deactivate;
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 0ca7099f4e55..4bff3abdc3eb 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -1317,13 +1317,6 @@ int xive_router_write_nvt(XiveRouter *xrtr, uint8_t 
> nvt_blk, uint32_t nvt_idx,
> return xrc->write_nvt(xrtr, nvt_blk, nvt_idx, nvt, word_number);
>  }
>  
> -XiveTCTX *xive_router_get_tctx(XiveRouter *xrtr, CPUState *cs)
> -{
> -XiveRouterClass *xrc = XIVE_ROUTER_GET_CLASS(xrtr);
> -
> -return xrc->get_tctx(xrtr, cs);
> -}
> -
>  /*
>   * Encode the HW CAM line in the block group mode format :
>   *

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


signature.asc
Description: PGP signature

Re: [RFC net-next 00/18] virtio_net XDP offload

[Jason Wang]

On 2019/11/28 上午3:49, Jakub Kicinski wrote:

On Wed, 27 Nov 2019 10:59:37 +0800, Jason Wang wrote:

On 2019/11/27 上午4:35, Jakub Kicinski wrote:

On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:

Note: This RFC has been sent to netdev as well as qemu-devel lists

This series introduces XDP offloading from virtio_net. It is based on
the following work by Jason Wang:
https://netdevconf.info/0x13/session.html?xdp-offload-with-virtio-net

Current XDP performance in virtio-net is far from what we can achieve
on host. Several major factors cause the difference:
- Cost of virtualization
- Cost of virtio (populating virtqueue and context switching)
- Cost of vhost, it needs more optimization
- Cost of data copy
Because of above reasons there is a need of offloading XDP program to
host. This set is an attempt to implement XDP offload from the guest.

This turns the guest kernel into a uAPI proxy.

BPF uAPI calls related to the "offloaded" BPF objects are forwarded
to the hypervisor, they pop up in QEMU which makes the requested call
to the hypervisor kernel. Today it's the Linux kernel tomorrow it may
be someone's proprietary "SmartNIC" implementation.

Why can't those calls be forwarded at the higher layer? Why do they
have to go through the guest kernel?


I think doing forwarding at higher layer have the following issues:

- Need a dedicated library (probably libbpf) but application may choose
   to do eBPF syscall directly
- Depends on guest agent to work

This can be said about any user space functionality.



Yes but the feature may have too much unnecessary dependencies: 
dedicated library, guest agent, host agent etc. This can only work for 
some specific setups and will lead vendor specific implementations.






- Can't work for virtio-net hardware, since it still requires a hardware
interface for carrying  offloading information

The HW virtio-net presumably still has a PF and hopefully reprs for
VFs, so why can't it attach the program there?



Then you still need a interface for carrying such information? It will 
work like assuming we had a virtio-net VF with reprs:


libbpf(guest) -> guest agent -> host agent -> libbpf(host) -> BPF 
syscall -> VF reprs/PF drvier -> VF/PF reprs -> virtio-net VF


Still need a vendor specific way for passing eBPF commands from driver 
to reprs/PF, and possibility, it could still be a virtio interface there.


In this proposal it will work out of box as simple as:

libbpf(guest) -> guest kernel -> virtio-net driver -> virtio-net VF

If the request comes from host (e.g flow offloading, configuration etc), 
VF reprs make perfect fit. But if the request comes from guest, having 
much longer journey looks quite like a burden (dependencies, bugs etc) .


What's more important, we can not assume the how virtio-net HW is 
structured, it could even not a SRIOV or PCI card.






- Implement at the level of kernel may help for future extension like
   BPF object pinning and eBPF helper etc.

No idea what you mean by this.



My understanding is, we should narrow the gap between non-offloaded eBPF 
program and offloaded eBPF program. Making maps or progs to be visible 
to kernel may help to persist a unified API e.g object pinning through 
sysfs, tracepoint, debug etc.






Basically, this series is trying to have an implementation of
transporting eBPF through virtio, so it's not necessarily a guest to
host but driver and device. For device, it could be either a virtual one
(as done in qemu) or a real hardware.

SmartNIC with a multi-core 64bit ARM CPUs is as much of a host as
is the x86 hypervisor side. This set turns the kernel into a uAPI
forwarder.



Not necessarily, as what has been done by NFP, driver filter out the 
features that is not supported, and the bpf object is still visible in 
the kernel (and see above comment).





3 years ago my answer to this proposal would have been very different.
Today after all the CPU bugs it seems like the SmartNICs (which are
just another CPU running proprietary code) may just take off..



That's interesting but vendor may choose to use FPGA other than SoC in 
this case. Anyhow discussion like this is somehow out of the scope of 
the series.




If kernel performs no significant work (or "adds value", pardon the
expression), and problem can easily be solved otherwise we shouldn't
do the work of maintaining the mechanism.

My understanding is that it should not be much difference compared to
other offloading technology.

I presume you mean TC offloads? In virtualization there is inherently a
hypervisor which will receive the request, be it an IO hub/SmartNIC or
the traditional hypervisor on the same CPU.

The ACL/routing offloads differ significantly, because it's either the
driver that does all the HW register poking directly or the complexity
of programming a rule into a HW table is quite low.

Same is true for the NFP BPF offload, BTW, the driver does all the
heavy lifting and compiles the final machine code image.



Y

Re: [PATCH v3 6/7] docs: gpio: Add GPIO Aggregator/Repeater documentation

[Ulrich Hecht]

> On November 27, 2019 at 9:42 AM Geert Uytterhoeven  
> wrote:
> 
> 
> Document the GPIO Aggregator/Repeater, and the three typical use-cases.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v3:
>   - New.
> ---
>  .../admin-guide/gpio/gpio-aggregator.rst  | 111 ++
>  Documentation/admin-guide/gpio/index.rst  |   1 +
>  2 files changed, 112 insertions(+)
>  create mode 100644 Documentation/admin-guide/gpio/gpio-aggregator.rst
> 
> diff --git a/Documentation/admin-guide/gpio/gpio-aggregator.rst 
> b/Documentation/admin-guide/gpio/gpio-aggregator.rst
> new file mode 100644
> index ..826146e260253299
> --- /dev/null
> +++ b/Documentation/admin-guide/gpio/gpio-aggregator.rst
> @@ -0,0 +1,111 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +GPIO Aggregator/Repeater
> +
> +
> +The GPIO Aggregator/Repeater allows to aggregate GPIOs, and expose them as a
> +new gpio_chip.  This supports the following use cases.
> +
> +
> +Aggregating GPIOs using Sysfs
> +-
> +
> +GPIO controllers are exported to userspace using /dev/gpiochip* character
> +devices.  Access control to these devices is provided by standard UNIX file
> +system permissions, on an all-or-nothing basis: either a GPIO controller is
> +accessible for a user, or it is not.
> +
> +The GPIO Aggregator allows access control for individual GPIOs, by 
> aggregating
> +them into a new gpio_chip, which can be assigned to a group or user using
> +standard UNIX file ownership and permissions.  Furthermore, this simplifies 
> and
> +hardens exporting GPIOs to a virtual machine, as the VM can just grab the 
> full
> +GPIO controller, and no longer needs to care about which GPIOs to grab and
> +which not, reducing the attack surface.
> +
> +Aggregated GPIO controllers are instantiated and destroyed by writing to
> +write-only attribute files in sysfs.
> +
> +/sys/bus/platform/drivers/gpio-aggregator/
> +
> + "new_device" ...
> + Userspace may ask the kernel to instantiate an aggregated GPIO
> + controller by writing a string describing the GPIOs to
> + aggregate to the "new_device" file, using the format
> +
> + .. code-block:: none
> +
> + [] [ ] ...
> +
> + Where:
> +
> + "" ...
> + is a GPIO line name,
> +
> + "" ...
> + is a GPIO chip label or name, and
> +
> + "" ...
> + is a comma-separated list of GPIO offsets and/or
> + GPIO offset ranges denoted by dashes.
> +
> + Example: Instantiate a new GPIO aggregator by aggregating GPIO
> + 19 of "e6052000.gpio" and GPIOs 20-21 of "gpiochip2" into a new
> + gpio_chip:
> +
> + .. code-block:: bash
> +
> + echo 'e6052000.gpio 19 gpiochip2 20-21' > new_device
> +
> + "delete_device" ...
> + Userspace may ask the kernel to destroy an aggregated GPIO
> + controller after use by writing its device name to the
> + "delete_device" file.
> +
> + Example: Destroy the previously-created aggregated GPIO
> + controller "gpio-aggregator.0":
> +
> + .. code-block:: bash
> +
> + echo gpio-aggregator.0 > delete_device
> +
> +
> +GPIO Repeater in Device Tree
> +
> +
> +A GPIO Repeater is a node in a Device Tree representing a repeater for one or
> +more GPIOs, possibly including physical signal property translation (e.g.
> +polarity inversion).  This allows to model e.g. inverters in DT.
> +
> +See Documentation/devicetree/bindings/gpio/gpio-repeater.yaml
> +
> +
> +Generic GPIO Driver
> +---
> +
> +The GPIO Aggregator can also be used as a generic driver for a simple
> +GPIO-operated device described in DT, without a dedicated in-kernel driver.
> +This is not unlike e.g. spidev, which allows to communicated with an SPI 
> device
> +from userspace.
> +
> +Binding a device to the GPIO Aggregator is performed either by modifying the
> +gpio-aggregator driver, or by writing to the "driver_override" file in Sysfs.
> +
> +Example: If "frobnicator" is a GPIO-operated device described in DT, using 
> its
> +own compatible value::
> +
> +frobnicator {
> +compatible = "myvendor,frobnicator";
> +
> +gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>,
> +<&gpio2 20 GPIO_ACTIVE_LOW>;
> +};
> +
> +it can be bound to the GPIO Aggregator by either:
> +
> +1. Adding its compatible value to ``gpio_aggregator_dt_ids[]``,
> +2. Binding manually using "driver_override":
> +
> +.. code-block:: bash
> +
> +echo gpio-aggregator > 
> /sys/bus/platform/devices/frobnicator/driver_override
> +echo frobnicator > /sys/bus/platform/drivers/gpio-aggregator/bind
> diff --git a/Documentat

Re: [PATCH v3 3/7] gpiolib: Add support for GPIO line table lookup

[Ulrich Hecht]

> On November 27, 2019 at 9:42 AM Geert Uytterhoeven  
> wrote:
> 
> 
> Currently GPIOs can only be referred to by GPIO controller and offset in
> GPIO lookup tables.
> 
> Add support for looking them up by line name.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> If this is rejected, the GPIO Aggregator documentation and code must be
> updated.
> 
> v3:
>   - New.
> ---
>  drivers/gpio/gpiolib.c   | 12 
>  include/linux/gpio/machine.h |  2 +-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index d24a3d79dcfe69ad..cb608512ad6bbded 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -4475,6 +4475,18 @@ static struct gpio_desc *gpiod_find(struct device 
> *dev, const char *con_id,
>   if (p->con_id && (!con_id || strcmp(p->con_id, con_id)))
>   continue;
>  
> + if (p->chip_hwnum == (u16)-1) {
> + desc = gpio_name_to_desc(p->chip_label);
> + if (desc) {
> + *flags = p->flags;
> + return desc;
> + }
> +
> + dev_warn(dev, "cannot find GPIO line %s, deferring\n",
> +  p->chip_label);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
>   chip = find_chip_by_name(p->chip_label);
>  
>   if (!chip) {
> diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> index 1ebe5be05d5f81fa..84c1c097e55eefaf 100644
> --- a/include/linux/gpio/machine.h
> +++ b/include/linux/gpio/machine.h
> @@ -31,7 +31,7 @@ enum gpio_lookup_flags {
>   */
>  struct gpiod_lookup {
>   const char *chip_label;
> - u16 chip_hwnum;
> + u16 chip_hwnum; /* if -1, chip_label is named line */

The magic number "-1" might deserve a #define.

>   const char *con_id;
>   unsigned int idx;
>   unsigned long flags;
> -- 
> 2.17.1
>

With or without #define,
Reviewed-by: Ulrich Hecht 

CU
Uli

Re: [PATCH v3 5/7] gpio: Add GPIO Aggregator/Repeater driver

[Ulrich Hecht]

Thank you for this series!

> On November 27, 2019 at 9:42 AM Geert Uytterhoeven  
> wrote:
> 
> 
> GPIO controllers are exported to userspace using /dev/gpiochip*
> character devices.  Access control to these devices is provided by
> standard UNIX file system permissions, on an all-or-nothing basis:
> either a GPIO controller is accessible for a user, or it is not.
> Currently no mechanism exists to control access to individual GPIOs.
> 
> Hence add a GPIO driver to aggregate existing GPIOs, and expose them as
> a new gpiochip.
> 
> This supports the following use cases:
>   1. Aggregating GPIOs using Sysfs
>  This is useful for implementing access control, and assigning a set
>  of GPIOs to a specific user or virtual machine.
> 
>   2. GPIO Repeater in Device Tree
>  This supports modelling e.g. GPIO inverters in DT.
> 
>   3. Generic GPIO Driver
>  This provides userspace access to a simple GPIO-operated device
>  described in DT, cfr. e.g. spidev for SPI-operated devices.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v3:
>   - Absorb GPIO forwarder,
>   - Integrate GPIO Repeater and Generic GPIO driver functionality,
>   - Use the aggregator parameters to create a GPIO lookup table instead
> of an array of GPIO descriptors, which allows to simplify the code:
>   1. This removes the need for calling gpio_name_to_desc(),
>  gpiochip_find(), gpiochip_get_desc(), and gpiod_request(),
>   2. This allows the platform device to always use
>  devm_gpiod_get_index(), regardless of the origin of the GPIOs,
>   - Move parameter parsing from platform device probe to sysfs attribute
> store, removing the need for platform data passing,
>   - Use more devm_*() functions to simplify cleanup,
>   - Add pr_fmt(),
>   - General refactoring.
> 
> v2:
>   - Add missing initialization of i in gpio_virt_agg_probe(),
>   - Update for removed .need_valid_mask field and changed
> .init_valid_mask() signature,
>   - Drop "virtual", rename to gpio-aggregator,
>   - Drop bogus FIXME related to gpiod_set_transitory() expectations,
>   - Use new GPIO Forwarder Helper,
>   - Lift limit on the maximum number of GPIOs,
>   - Improve parsing:
>   - add support for specifying GPIOs by line name,
>   - add support for specifying GPIO chips by ID,
>   - add support for GPIO offset ranges,
>   - names and offset specifiers must be separated by whitespace,
>   - GPIO offsets must separated by spaces,
>   - Use str_has_prefix() and kstrtouint().
> ---
>  drivers/gpio/Kconfig   |  13 +
>  drivers/gpio/Makefile  |   1 +
>  drivers/gpio/gpio-aggregator.c | 587 +
>  3 files changed, 601 insertions(+)
>  create mode 100644 drivers/gpio/gpio-aggregator.c
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 8adffd42f8cb0559..36b6b57a6b05e906 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1507,6 +1507,19 @@ config GPIO_VIPERBOARD
>  
>  endmenu
>  
> +config GPIO_AGGREGATOR
> + tristate "GPIO Aggregator/Repeater"
> + help
> +   Say yes here to enable the GPIO Aggregator and repeater, which

Inconsistent capitalization (Aggregator vs. repeater).

> +   provides a way to aggregate and/or repeat existing GPIOs into a new
> +   GPIO device.
> +   This can serve the following purposes:
> + 1. Assign a collection of GPIOs to a user, or export them to a
> +virtual machine,
> + 2. Support GPIOs that are connected to a physical inverter,
> + 3. Provide a generic driver for a GPIO-operated device, to be
> +   controlled from userspace using the GPIO chardev interface.
> +
>  config GPIO_MOCKUP
>   tristate "GPIO Testing Driver"
>   select IRQ_SIM
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 34eb8b2b12dd656c..f9971eeb1f32335f 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_GPIO_74XX_MMIO)+= 
> gpio-74xx-mmio.o
>  obj-$(CONFIG_GPIO_ADNP)  += gpio-adnp.o
>  obj-$(CONFIG_GPIO_ADP5520)   += gpio-adp5520.o
>  obj-$(CONFIG_GPIO_ADP5588)   += gpio-adp5588.o
> +obj-$(CONFIG_GPIO_AGGREGATOR)+= gpio-aggregator.o
>  obj-$(CONFIG_GPIO_ALTERA_A10SR)  += gpio-altera-a10sr.o
>  obj-$(CONFIG_GPIO_ALTERA)+= gpio-altera.o
>  obj-$(CONFIG_GPIO_AMD8111)   += gpio-amd8111.o
> diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
> new file mode 100644
> index ..873578c6f9683db8
> --- /dev/null
> +++ b/drivers/gpio/gpio-aggregator.c
> @@ -0,0 +1,587 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// GPIO Aggregator and Repeater
> +//
> +// Copyright (C) 2019 Glider bvba
> +
> +#define DRV_NAME   "gpio-aggregator"
> +#define pr_fmt(fmt)  DRV_NAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#inc

Re: [PATCH v3 4/7] dt-bindings: gpio: Add gpio-repeater bindings

[Ulrich Hecht]

> On November 27, 2019 at 9:42 AM Geert Uytterhoeven  
> wrote:
> 
> 
> Add Device Tree bindings for a GPIO repeater, with optional translation
> of physical signal properties.  This is useful for describing explicitly
> the presence of e.g. an inverter on a GPIO line, and was inspired by the
> non-YAML gpio-inverter bindings by Harish Jenny K N
> [1].
> 
> Note that this is different from a GPIO Nexus Node[2], which cannot do
> physical signal property translation.
> 
> While an inverter can be described implicitly by exchanging the
> GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags, this has its limitations.
> Each GPIO line has only a single GPIO_ACTIVE_* flag, but applies to both
> th provider and consumer sides:
>   1. The GPIO provider (controller) looks at the flags to know the
>  polarity, so it can translate between logical (active/not active)
>  and physical (high/low) signal levels.
>   2. While the signal polarity is usually fixed on the GPIO consumer
>  side (e.g. an LED is tied to either the supply voltage or GND),
>  it may be configurable on some devices, and both sides need to
>  agree.  Hence the GPIO_ACTIVE_* flag as seen by the consumer must
>  match the actual polarity.
>  There exists a similar issue with interrupt flags, where both the
>  interrupt controller and the device generating the interrupt need
>  to agree, which breaks in the presence of a physical inverter not
>  described in DT (see e.g. [3]).
> 
> [1] "[PATCH V4 2/2] gpio: inverter: document the inverter bindings"
> 
> https://lore.kernel.org/linux-gpio/1561699236-18620-3-git-send-email-harish_kand...@mentor.com/
> 
> [2] Devicetree Specification v0.3-rc2, Section 2.5
> 
> https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3-rc2
> 
> [3] "[PATCH] wlcore/wl18xx: Add invert-irq OF property for physically
> inverted IRQ"
> 
> https://lore.kernel.org/linux-renesas-soc/20190607172958.20745-1-ero...@de.adit-jv.com/
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v3:
>   - New.
> ---
>  .../bindings/gpio/gpio-repeater.yaml  | 53 +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-repeater.yaml
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-repeater.yaml 
> b/Documentation/devicetree/bindings/gpio/gpio-repeater.yaml
> new file mode 100644
> index ..efdee0c3be43f731
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-repeater.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/gpio-repeater.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO Repeater
> +
> +maintainers:
> +  - Harish Jenny K N 
> +  - Geert Uytterhoeven 
> +
> +description:
> +  This represents a repeater for one or more GPIOs, possibly including 
> physical
> +  signal property translation (e.g. polarity inversion).
> +
> +properties:
> +  compatible:
> +const: gpio-repeater
> +
> +  "#gpio-cells":
> +const: 2
> +
> +  gpio-controller: true
> +
> +  gpios:
> +description:
> +  Phandle and specifier, one for each repeated GPIO.
> +
> +  gpio-line-names:
> +description:
> +  Strings defining the names of the GPIO lines going out of the GPIO
> +  controller.
> +
> +required:
> +  - compatible
> +  - "#gpio-cells"
> +  - gpio-controller
> +  - gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  # Device node describing a polarity inverter for a single GPIO
> +  - |
> +#include 
> +
> +inverter: gpio-repeater {
> +compatible = "gpio-repeater";
> +#gpio-cells = <2>;
> +gpio-controller;
> +gpios = <&gpio 95 GPIO_ACTIVE_LOW>;
> +};
> -- 
> 2.17.1
>

Reviewed-by: Ulrich Hecht 

CU
Uli

Re: [PATCH v3 1/7] gpiolib: Add GPIOCHIP_NAME definition

[Ulrich Hecht]

> On November 27, 2019 at 9:42 AM Geert Uytterhoeven  
> wrote:
> 
> 
> The string literal "gpiochip" is used in several places.
> Add a definition for it, and use it everywhere, to make sure everything
> stays in sync.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v3:
>   - New.
> ---
>  drivers/gpio/gpiolib-sysfs.c | 7 +++
>  drivers/gpio/gpiolib.c   | 4 ++--
>  drivers/gpio/gpiolib.h   | 2 ++
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
> index fbf6b1a0a4fae6ce..23e3d335cd543d53 100644
> --- a/drivers/gpio/gpiolib-sysfs.c
> +++ b/drivers/gpio/gpiolib-sysfs.c
> @@ -762,10 +762,9 @@ int gpiochip_sysfs_register(struct gpio_device *gdev)
>   parent = &gdev->dev;
>  
>   /* use chip->base for the ID; it's already known to be unique */
> - dev = device_create_with_groups(&gpio_class, parent,
> - MKDEV(0, 0),
> - chip, gpiochip_groups,
> - "gpiochip%d", chip->base);
> + dev = device_create_with_groups(&gpio_class, parent, MKDEV(0, 0), chip,
> + gpiochip_groups, GPIOCHIP_NAME "%d",
> + chip->base);
>   if (IS_ERR(dev))
>   return PTR_ERR(dev);
>  
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index dce0b31f4125a6b3..c9e47620d2434983 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1419,7 +1419,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, 
> void *data,
>   ret = gdev->id;
>   goto err_free_gdev;
>   }
> - dev_set_name(&gdev->dev, "gpiochip%d", gdev->id);
> + dev_set_name(&gdev->dev, GPIOCHIP_NAME "%d", gdev->id);
>   device_initialize(&gdev->dev);
>   dev_set_drvdata(&gdev->dev, gdev);
>   if (chip->parent && chip->parent->driver)
> @@ -5105,7 +5105,7 @@ static int __init gpiolib_dev_init(void)
>   return ret;
>   }
>  
> - ret = alloc_chrdev_region(&gpio_devt, 0, GPIO_DEV_MAX, "gpiochip");
> + ret = alloc_chrdev_region(&gpio_devt, 0, GPIO_DEV_MAX, GPIOCHIP_NAME);
>   if (ret < 0) {
>   pr_err("gpiolib: failed to allocate char dev region\n");
>   bus_unregister(&gpio_bus_type);
> diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
> index ca9bc1e4803c2979..a4a759920faa48ab 100644
> --- a/drivers/gpio/gpiolib.h
> +++ b/drivers/gpio/gpiolib.h
> @@ -16,6 +16,8 @@
>  #include 
>  #include 
>  
> +#define GPIOCHIP_NAME"gpiochip"
> +
>  /**
>   * struct gpio_device - internal state container for GPIO devices
>   * @id: numerical ID number for the GPIO chip
> -- 
> 2.17.1
>

Reviewed-by: Ulrich Hecht 

CU
Uli

Re: [PATCH v3 2/7] gpiolib: Add support for gpiochipN-based table lookup

[Ulrich Hecht]

> On November 27, 2019 at 9:42 AM Geert Uytterhoeven  
> wrote:
> 
> 
> Currently GPIO controllers can only be referred to by label in GPIO
> lookup tables.
> 
> Add support for looking them up by "gpiochipN" name, with "N" either the
> corresponding GPIO device's ID number, or the GPIO controller's first
> GPIO number.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> If this is rejected, the GPIO Aggregator documentation must be updated.
> 
> The second variant is currently used by the legacy sysfs interface only,
> so perhaps the chip->base check should be dropped?
> 
> v3:
>   - New.
> ---
>  drivers/gpio/gpiolib.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index c9e47620d2434983..d24a3d79dcfe69ad 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1746,9 +1746,29 @@ static int gpiochip_match_name(struct gpio_chip *chip, 
> void *data)
>   return !strcmp(chip->label, name);
>  }
>  
> +static int gpiochip_match_id(struct gpio_chip *chip, void *data)
> +{
> + int id = (uintptr_t)data;
> +
> + return id == chip->base || id == chip->gpiodev->id;
> +}
> +
>  static struct gpio_chip *find_chip_by_name(const char *name)
>  {
> - return gpiochip_find((void *)name, gpiochip_match_name);
> + struct gpio_chip *chip;
> + int id;
> +
> + chip = gpiochip_find((void *)name, gpiochip_match_name);
> + if (chip)
> + return chip;
> +
> + if (!str_has_prefix(name, GPIOCHIP_NAME))
> + return NULL;
> +
> + if (kstrtoint(name + strlen(GPIOCHIP_NAME), 10, &id))
> + return NULL;
> +
> + return gpiochip_find((void *)(uintptr_t)id, gpiochip_match_id);
>  }
>  
>  #ifdef CONFIG_GPIOLIB_IRQCHIP
> -- 
> 2.17.1
>

Reviewed-by: Ulrich Hecht 

CU
Uli

Re: [RFC net-next 00/18] virtio_net XDP offload

[Alexei Starovoitov]

On Tue, Nov 26, 2019 at 12:35:14PM -0800, Jakub Kicinski wrote:
> 
> I'd appreciate if others could chime in.

The performance improvements are quite appealing.
In general offloading from higher layers into lower layers is necessary long 
term.

But the approach taken by patches 15 and 17 is a dead end. I don't see how it
can ever catch up with the pace of bpf development. As presented this approach
works for the most basic programs and simple maps. No line info, no BTF, no
debuggability. There are no tail_calls either. I don't think I've seen a single
production XDP program that doesn't use tail calls. Static and dynamic linking
is coming. Wraping one bpf feature at a time with virtio api is never going to
be complete. How FDs are going to be passed back? OBJ_GET_INFO_BY_FD ?
OBJ_PIN/GET ? Where bpffs is going to live ? Any realistic XDP application will
be using a lot more than single self contained XDP prog with hash and array
maps. It feels that the whole sys_bpf needs to be forwarded as a whole from
guest into host. In case of true hw offload the host is managing HW. So it
doesn't forward syscalls into the driver. The offload from guest into host is
different. BPF can be seen as a resource that host provides and guest kernel
plus qemu would be forwarding requests between guest user space and host
kernel. Like sys_bpf(BPF_MAP_CREATE) can passthrough into the host directly.
The FD that hosts sees would need a corresponding mirror FD in the guest. There
are still questions about bpffs paths, but the main issue of
one-feature-at-a-time will be addressed in such approach. There could be other
solutions, of course.

RE: [PATCH V2 0/4] Introduce Advanced Watch Dog module

[Zhang, Chen]

> -Original Message-
> From: Markus Armbruster 
> Sent: Wednesday, November 27, 2019 11:49 PM
> To: Zhang, Chen 
> Cc: Jason Wang ; Paolo Bonzini
> ; Philippe Mathieu-Daudé ;
> qemu-dev ; Zhang Chen 
> Subject: Re: [PATCH V2 0/4] Introduce Advanced Watch Dog module
> 
> "Zhang, Chen"  writes:
> 
> > Hi~ All~
> >
> > Ping Anyone have time to review this series? I need more comments~
> 
> Any takers?

Hi Markus,

Thank you for your attention.
This is a very simple module to complete the tasks related to error detection 
and automatic processing.
I have write the detail reason why we need it in real environment on the commit 
log.
Here is the latest patch:
https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg02872.html

Thanks
Zhang Chen

Re: [RFC net-next 15/18] virtio_net: implement XDP prog offload functionality

[Prashant Bhole]

On 11/28/19 5:42 AM, Michael S. Tsirkin wrote:

On Tue, Nov 26, 2019 at 07:07:41PM +0900, Prashant Bhole wrote:

From: Jason Wang 

This patch implements bpf_prog_offload_ops callbacks and adds handling
for XDP_SETUP_PROG_HW. Handling of XDP_SETUP_PROG_HW involves setting
up struct virtio_net_ctrl_ebpf_prog and appending program instructions
to it. This control buffer is sent to Qemu with class
VIRTIO_NET_CTRL_EBPF and command VIRTIO_NET_BPF_CMD_SET_OFFLOAD.
The expected behavior from Qemu is that it should try to load the
program in host os and report the status.


That's not great e.g. for migration: different hosts might have
a different idea about what's allowed.
Device capabilities should be preferably exported through
feature bits or config space such that it's easy to
intercept and limit these as needed.


These things are mentioned in the TODO section of cover letter.
Having offload feature enabled should be a migration blocker.
A feature bit in virtio for offloading capability needs to be added.



Also, how are we going to handle e.g. endian-ness here?


For now I feel we should block offloading in case of cross endian
virtualization. Further to support cross endian-ness, the requests for 
offloading a map or program should include metadata such as BTF info.

Qemu needs to handle the conversion.





It also adds restriction to have either driver or offloaded program
at a time.


I'm not sure I understand what does the above say.
virtnet_xdp_offload_check?
Please add code comments so we remember what to do and when.


This restriction can be removed later after proper testing.


What kind of testing is missing here?


This restriction mentioned above is about having multiple programs
attached to the same device. It can be possible to have a program
attached in driver mode and other in offload mode, but in current code
only one mode at a time is supported because I wasn't aware whether
bpf tooling supports the case. I will add a comment or remove the
restriction in the next revision.




Signed-off-by: Jason Wang 
Co-developed-by: Prashant Bhole 
Signed-off-by: Prashant Bhole 


Any UAPI changes need to be copied to virtio-...@lists.oasis-open.org
(subscriber only) list please.


Sure.

Thanks.

Re: [PATCH v18 3/8] numa: Extend CLI to provide memory side cache information

[Tao Xu]

On 11/27/2019 5:56 PM, Markus Armbruster wrote:

Tao Xu  writes:


From: Liu Jingqi 

Add -numa hmat-cache option to provide Memory Side Cache Information.
These memory attributes help to build Memory Side Cache Information
Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).


Please mention this requires -machine hmat=on.


OK I will add these for 3 related patches.



Reviewed-by: Igor Mammedov 
Reviewed-by: Daniel Black 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 

[...]

diff --git a/qapi/machine.json b/qapi/machine.json
index c741649d7b..3d0ba226a9 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -428,10 +428,12 @@
  #
  # @hmat-lb: memory latency and bandwidth information (Since: 5.0)
  #
+# @hmat-cache: memory side cache information (Since: 5.0)
+#
  # Since: 2.1
  ##
  { 'enum': 'NumaOptionsType',
-  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
+  'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] }
  
  ##

  # @NumaOptions:
@@ -447,7 +449,8 @@
  'node': 'NumaNodeOptions',
  'dist': 'NumaDistOptions',
  'cpu': 'NumaCpuOptions',
-'hmat-lb': 'NumaHmatLBOptions' }}
+'hmat-lb': 'NumaHmatLBOptions',
+'hmat-cache': 'NumaHmatCacheOptions' }}
  
  ##

  # @NumaNodeOptions:
@@ -647,6 +650,77 @@
  '*latency': 'uint64',
  '*bandwidth': 'size' }}
  
+##

+# @HmatCacheAssociativity:
+#
+# Cache associativity in the Memory Side Cache
+# Information Structure of HMAT
+#
+# For more information of @HmatCacheAssociativity see
+# the chapter 5.2.27.5: Table 5-147 of ACPI 6.3 spec.


   # Cache associativity in the Memory Side Cache Information Structure
   # of HMAT
   #
   # For more information of @HmatCacheAssociativity, see chapter
   # 5.2.27.5: Table 5-147 of ACPI 6.3 spec.


+#
+# @none: None


What does cache associativity @none mean?  A none-associative cache?  I
guess it makes sense to people familiar with the ACPI spec...



This means this proximity domain has no memory cache, thus none for 
Cache associativity, I will add more description about this.

+#
+# @direct: Direct Mapped
+#
+# @complex: Complex Cache Indexing (implementation specific)
+#
+# Since: 5.0
+##
+{ 'enum': 'HmatCacheAssociativity',
+  'data': [ 'none', 'direct', 'complex' ] }
+
+##
+# @HmatCacheWritePolicy:
+#
+# Cache write policy in the Memory Side Cache
+# Information Structure of HMAT
+#
+# For more information of @HmatCacheWritePolicy see
+# the chapter 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.


Break lines around column 70, please.


+#
+# @none: None


What does cache write policy @none mean?


This means this proximity domain has no memory cache, thus none for 
cache write policy.



+#
+# @write-back: Write Back (WB)
+#
+# @write-through: Write Through (WT)
+#
+# Since: 5.0
+##
+{ 'enum': 'HmatCacheWritePolicy',
+  'data': [ 'none', 'write-back', 'write-through' ] }
+
+##
+# @NumaHmatCacheOptions:
+#
+# Set the memory side cache information for a given memory domain.
+#
+# For more information of @NumaHmatCacheOptions see
+# the chapter 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
+#
+# @node-id: the memory proximity domain to which the memory belongs.
+#
+# @size: the size of memory side cache in bytes.
+#
+# @level: the cache level described in this structure.
+#
+# @assoc: the cache associativity, none/direct-mapped/complex(complex cache 
indexing).
+#
+# @policy: the write policy, none/write-back/write-through.
+#
+# @line: the cache Line size in bytes.
+#
+# Since: 5.0
+##
+{ 'struct': 'NumaHmatCacheOptions',
+  'data': {
+   'node-id': 'uint32',


Ignorant question: you use 'uint16' for other "proximity domains".  Is
'uint32' intentional here?



Yes, because ACPI 6.3 spec define the domain as 4 byte(32 bit), and for 
HmatCacheOptions we directly use this QAPI struct when building HMAT. 
But for other "proximity domains" we use local variable (such as 
"uint32_t initiator")

[NOTFORMERGE PATCH 10/10] hw/avr: Remove the 'sample' board

[Philippe Mathieu-Daudé]

We introduce real world boards with proper schematics,
let's remove this.

Signed-off-by: Philippe Mathieu-Daudé 
---
Patch meant to squash on 'target/avr: Add example board configuration'
---
 hw/avr/sample.c  | 282 ---
 hw/avr/Makefile.objs |   1 -
 2 files changed, 283 deletions(-)
 delete mode 100644 hw/avr/sample.c

diff --git a/hw/avr/sample.c b/hw/avr/sample.c
deleted file mode 100644
index 2295ec1b79..00
--- a/hw/avr/sample.c
+++ /dev/null
@@ -1,282 +0,0 @@
-/*
- * QEMU AVR CPU
- *
- * Copyright (c) 2019 Michael Rolnik
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see
- * 
- */
-
-/*
- *  NOTE:
- *  This is not a real AVR board, this is an example!
- *  The CPU is an approximation of an ATmega2560, but is missing various
- *  built-in peripherals.
- *
- *  This example board loads provided binary file into flash memory and
- *  executes it from 0x address in the code memory space.
- *
- *  Currently used for AVR CPU validation
- *
- */
-
-#include "qemu/osdep.h"
-#include "qapi/error.h"
-#include "qemu-common.h"
-#include "cpu.h"
-#include "hw/hw.h"
-#include "sysemu/sysemu.h"
-#include "sysemu/qtest.h"
-#include "ui/console.h"
-#include "hw/boards.h"
-#include "hw/loader.h"
-#include "qemu/error-report.h"
-#include "exec/address-spaces.h"
-#include "include/hw/sysbus.h"
-#include "include/hw/char/avr_usart.h"
-#include "include/hw/timer/avr_timer16.h"
-#include "include/hw/misc/avr_mask.h"
-#include "elf.h"
-#include "hw/misc/unimp.h"
-
-#define SIZE_FLASH 0x0004
-#define SIZE_SRAM 0x2000
-/*
- * Size of additional "external" memory, as if the AVR were configured to use
- * an external RAM chip.
- * Note that the configuration registers that normally enable this feature are
- * unimplemented.
- */
-#define SIZE_EXMEM 0x
-
-/* Offsets of peripherals in emulated memory space (i.e. not host addresses)  
*/
-#define PRR0_BASE 0x64
-#define PRR1_BASE 0x65
-#define USART_BASE 0xc0
-#define TIMER1_BASE 0x80
-#define TIMER1_IMSK_BASE 0x6f
-#define TIMER1_IFR_BASE 0x36
-
-/* Interrupt numbers used by peripherals */
-#define USART_RXC_IRQ 24
-#define USART_DRE_IRQ 25
-#define USART_TXC_IRQ 26
-
-#define TIMER1_CAPT_IRQ 15
-#define TIMER1_COMPA_IRQ 16
-#define TIMER1_COMPB_IRQ 17
-#define TIMER1_COMPC_IRQ 18
-#define TIMER1_OVF_IRQ 19
-
-/*  Power reduction */
-#define PRR1_BIT_PRTIM5 0x05/*  Timer/Counter5  */
-#define PRR1_BIT_PRTIM4 0x04/*  Timer/Counter4  */
-#define PRR1_BIT_PRTIM3 0x03/*  Timer/Counter3  */
-#define PRR1_BIT_PRUSART3   0x02/*  USART3  */
-#define PRR1_BIT_PRUSART2   0x01/*  USART2  */
-#define PRR1_BIT_PRUSART1   0x00/*  USART1  */
-
-#define PRR0_BIT_PRTWI  0x06/*  TWI */
-#define PRR0_BIT_PRTIM2 0x05/*  Timer/Counter2  */
-#define PRR0_BIT_PRTIM0 0x04/*  Timer/Counter0  */
-#define PRR0_BIT_PRTIM1 0x03/*  Timer/Counter1  */
-#define PRR0_BIT_PRSPI  0x02/*  Serial Peripheral Interface */
-#define PRR0_BIT_PRUSART0   0x01/*  USART0  */
-#define PRR0_BIT_PRADC  0x00/*  ADC */
-
-typedef struct {
-MachineClass parent;
-} SampleMachineClass;
-
-typedef struct {
-MachineState parent;
-MemoryRegion *ram;
-MemoryRegion *flash;
-AVRUsartState *usart0;
-AVRTimer16State *timer1;
-AVRMaskState *prr[2];
-} SampleMachineState;
-
-#define TYPE_SAMPLE_MACHINE MACHINE_TYPE_NAME("sample")
-
-#define SAMPLE_MACHINE(obj) \
-OBJECT_CHECK(SampleMachineState, obj, TYPE_SAMPLE_MACHINE)
-#define SAMPLE_MACHINE_GET_CLASS(obj) \
-OBJECT_GET_CLASS(SampleMachineClass, obj, TYPE_SAMPLE_MACHINE)
-#define SAMPLE_MACHINE_CLASS(klass) \
-OBJECT_CLASS_CHECK(SampleMachineClass, klass, TYPE_SAMPLE_MACHINE)
-
-static void sample_init(MachineState *machine)
-{
-SampleMachineState *sms = SAMPLE_MACHINE(machine);
-MemoryRegion *system_memory = get_system_memory();
-AVRCPU *cpu;
-const char *firmware = NULL;
-const char *filename;
-int bytes_loaded;
-SysBusDevice *busdev;
-DeviceState *cpudev;
-
-system_memory = get_system_memory();
-sms->ram = g_new(MemoryRegion, 1);
-sms->flash = g_new(MemoryRegion, 1);
-
-cpu = AVR_CPU(cpu_create(machine->cpu_type));
-cpudev = DEVICE(cpu);
-
-
-memory_region_init_rom(sms->f

[RFC PATCH 09/10] tests/acceptance: Use the ATmega2560 board

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/machine_avr6.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/machine_avr6.py b/tests/acceptance/machine_avr6.py
index 2ef4a9ac2c..abe8d45b65 100644
--- a/tests/acceptance/machine_avr6.py
+++ b/tests/acceptance/machine_avr6.py
@@ -31,7 +31,7 @@ class AVR6Machine(Test):
 def test_freertos(self):
 """
 :avocado: tags=arch:avr
-:avocado: tags=machine:sample
+:avocado: tags=machine:arduino-mega-2560-v3
 """
 """
 
https://github.com/seharris/qemu-avr-tests/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf
@@ -43,7 +43,7 @@ class AVR6Machine(Test):
 rom_hash = '7eb521f511ca8f2622e0a3c5e8dd686efbb911d4'
 rom_path = self.fetch_asset(rom_url, asset_hash=rom_hash)
 
-self.vm.set_machine('sample')
+self.vm.set_machine('arduino-mega-2560-v3')
 self.vm.add_args('-bios', rom_path)
 self.vm.add_args('-nographic')
 self.vm.launch()
-- 
2.21.0

[PATCH 08/10] tests/acceptance: Keep multilines comment consistent with other tests

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/acceptance/machine_avr6.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/machine_avr6.py b/tests/acceptance/machine_avr6.py
index ba1f47dd70..2ef4a9ac2c 100644
--- a/tests/acceptance/machine_avr6.py
+++ b/tests/acceptance/machine_avr6.py
@@ -37,9 +37,9 @@ class AVR6Machine(Test):
 
https://github.com/seharris/qemu-avr-tests/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf
 constantly prints out 
'ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWX'
 """
-rom_url = 'https://github.com/seharris/qemu-avr-tests'
-rom_sha1= '36c3e67b8755dcf37e06af6730ef5d477b8ed16d'
-rom_url += '/raw/' + rom_sha1 + 
'/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf'
+rom_url = ('https://github.com/seharris/qemu-avr-tests'
+   '/raw/36c3e67b8755dcf/free-rtos/Demo'
+   '/AVR_ATMega2560_GCC/demo.elf')
 rom_hash = '7eb521f511ca8f2622e0a3c5e8dd686efbb911d4'
 rom_path = self.fetch_asset(rom_url, asset_hash=rom_hash)
 
-- 
2.21.0

[RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Philippe Mathieu-Daudé]

Add famous ATmega MCUs:

- middle range: ATmega168 and ATmega328
- high range: ATmega1280 and ATmega2560

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/avr/atmega.h  |  58 +++
 hw/avr/atmega.c  | 379 +++
 hw/avr/Makefile.objs |   1 +
 3 files changed, 438 insertions(+)
 create mode 100644 hw/avr/atmega.h
 create mode 100644 hw/avr/atmega.c

diff --git a/hw/avr/atmega.h b/hw/avr/atmega.h
new file mode 100644
index 00..d22d90a962
--- /dev/null
+++ b/hw/avr/atmega.h
@@ -0,0 +1,58 @@
+/*
+ * QEMU ATmega MCU
+ *
+ * Copyright (c) 2019 Philippe Mathieu-Daudé
+ *
+ * This work is licensed under the terms of the GNU GPLv2 or later.
+ * See the COPYING file in the top-level directory.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef HW_AVR_ATMEGA_H
+#define HW_AVR_ATMEGA_H
+
+#include "hw/char/avr_usart.h"
+#include "hw/char/avr_usart.h"
+#include "hw/timer/avr_timer16.h"
+#include "hw/misc/avr_mask.h"
+#include "target/avr/cpu.h"
+
+#define TYPE_ATMEGA "ATmega"
+#define TYPE_ATMEGA168  "ATmega168"
+#define TYPE_ATMEGA328  "ATmega328"
+#define TYPE_ATMEGA1280 "ATmega1280"
+#define TYPE_ATMEGA2560 "ATmega2560"
+#define ATMEGA(obj) OBJECT_CHECK(AtmegaState, (obj), TYPE_ATMEGA)
+
+#define USART_MAX 4
+#define TIMER_MAX 6
+
+typedef struct AtmegaState {
+/*< private >*/
+SysBusDevice parent_obj;
+/*< public >*/
+
+AVRCPU cpu;
+MemoryRegion flash;
+MemoryRegion eeprom;
+MemoryRegion sram;
+DeviceState *io;
+AVRMaskState pwr[2];
+AVRUsartState usart[USART_MAX];
+AVRTimer16State timer[TIMER_MAX];
+uint64_t xtal_freq_hz;
+} AtmegaState;
+
+typedef struct AtmegaInfo AtmegaInfo;
+
+typedef struct AtmegaClass {
+SysBusDeviceClass parent_class;
+const AtmegaInfo *info;
+} AtmegaClass;
+
+#define ATMEGA_CLASS(klass) \
+OBJECT_CLASS_CHECK(AtmegaClass, (klass), TYPE_ATMEGA)
+#define ATMEGA_GET_CLASS(obj) \
+OBJECT_GET_CLASS(AtmegaClass, (obj), TYPE_ATMEGA)
+
+#endif /* HW_AVR_ATMEGA_H */
diff --git a/hw/avr/atmega.c b/hw/avr/atmega.c
new file mode 100644
index 00..1f1b1246ef
--- /dev/null
+++ b/hw/avr/atmega.c
@@ -0,0 +1,379 @@
+/*
+ * QEMU ATmega MCU
+ *
+ * Copyright (c) 2019 Philippe Mathieu-Daudé
+ *
+ * This work is licensed under the terms of the GNU GPLv2 or later.
+ * See the COPYING file in the top-level directory.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/module.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "exec/memory.h"
+#include "exec/address-spaces.h"
+#include "sysemu/sysemu.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "hw/boards.h" /* FIXME memory_region_allocate_system_memory for sram 
*/
+#include "hw/misc/unimp.h"
+#include "atmega.h"
+
+enum AtmegaIrq {
+USART0_RXC_IRQ, USART0_DRE_IRQ, USART0_TXC_IRQ,
+USART1_RXC_IRQ, USART1_DRE_IRQ, USART1_TXC_IRQ,
+USART2_RXC_IRQ, USART2_DRE_IRQ, USART2_TXC_IRQ,
+USART3_RXC_IRQ, USART3_DRE_IRQ, USART3_TXC_IRQ,
+TIMER0_CAPT_IRQ, TIMER0_COMPA_IRQ, TIMER0_COMPB_IRQ,
+TIMER0_COMPC_IRQ, TIMER0_OVF_IRQ,
+TIMER1_CAPT_IRQ, TIMER1_COMPA_IRQ, TIMER1_COMPB_IRQ,
+TIMER1_COMPC_IRQ, TIMER1_OVF_IRQ,
+TIMER2_CAPT_IRQ, TIMER2_COMPA_IRQ, TIMER2_COMPB_IRQ,
+TIMER2_COMPC_IRQ, TIMER2_OVF_IRQ,
+TIMER3_CAPT_IRQ, TIMER3_COMPA_IRQ, TIMER3_COMPB_IRQ,
+TIMER3_COMPC_IRQ, TIMER3_OVF_IRQ,
+TIMER4_CAPT_IRQ, TIMER4_COMPA_IRQ, TIMER4_COMPB_IRQ,
+TIMER4_COMPC_IRQ, TIMER4_OVF_IRQ,
+TIMER5_CAPT_IRQ, TIMER5_COMPA_IRQ, TIMER5_COMPB_IRQ,
+TIMER5_COMPC_IRQ, TIMER5_OVF_IRQ,
+};
+#define IRQ_MAX 64
+
+#define USART_RXC_IRQ(n)(3 * n + USART0_RXC_IRQ)
+#define USART_DRE_IRQ(n)(3 * n + USART0_DRE_IRQ)
+#define USART_TXC_IRQ(n)(3 * n + USART0_TXC_IRQ)
+#define TIMER_CAPT_IRQ(n)   (5 * n + TIMER0_CAPT_IRQ)
+#define TIMER_COMPA_IRQ(n)  (5 * n + TIMER0_COMPA_IRQ)
+#define TIMER_COMPB_IRQ(n)  (5 * n + TIMER0_COMPB_IRQ)
+#define TIMER_COMPC_IRQ(n)  (5 * n + TIMER0_COMPC_IRQ)
+#define TIMER_OVF_IRQ(n)(5 * n + TIMER0_OVF_IRQ)
+
+static const uint8_t irq168_328[IRQ_MAX] = {
+[TIMER2_COMPA_IRQ]  = 8,
+[TIMER2_COMPB_IRQ]  = 9,
+[TIMER2_OVF_IRQ]= 10,
+[TIMER1_CAPT_IRQ]   = 11,
+[TIMER1_COMPA_IRQ]  = 12,
+[TIMER1_COMPB_IRQ]  = 13,
+[TIMER1_OVF_IRQ]= 14,
+[TIMER0_COMPA_IRQ]  = 15,
+[TIMER0_COMPB_IRQ]  = 16,
+[TIMER0_OVF_IRQ]= 17,
+[USART0_RXC_IRQ]= 19,
+[USART0_DRE_IRQ]= 20,
+[USART0_TXC_IRQ]= 21,
+}, irq1280_2560[IRQ_MAX] = {
+[TIMER2_COMPA_IRQ]  = 14,
+[TIMER2_COMPB_IRQ]  = 15,
+[TIMER2_OVF_IRQ]= 16,
+[TIMER1_CAPT_IRQ]   = 17,
+[TIMER1_COMPA_IRQ]  = 18,
+[TIMER1_COMPB_IRQ]  = 19,
+[TIMER1_COMPC_IRQ]  = 20,
+[TIMER1_OVF_IRQ]= 21,
+[TIMER0_COMPA_IRQ]  = 22,
+[TIMER0_

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Philippe Mathieu-Daudé]

On Thu, Nov 28, 2019 at 2:50 AM Philippe Mathieu-Daudé  wrote:
>
> Add famous ATmega MCUs:
>
> - middle range: ATmega168 and ATmega328
> - high range: ATmega1280 and ATmega2560
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/avr/atmega.h  |  58 +++
>  hw/avr/atmega.c  | 379 +++
>  hw/avr/Makefile.objs |   1 +
>  3 files changed, 438 insertions(+)
>  create mode 100644 hw/avr/atmega.h
>  create mode 100644 hw/avr/atmega.c
>
> diff --git a/hw/avr/atmega.h b/hw/avr/atmega.h
> new file mode 100644
> index 00..d22d90a962
> --- /dev/null
> +++ b/hw/avr/atmega.h
> @@ -0,0 +1,58 @@
> +/*
> + * QEMU ATmega MCU
> + *
> + * Copyright (c) 2019 Philippe Mathieu-Daudé
> + *
> + * This work is licensed under the terms of the GNU GPLv2 or later.
> + * See the COPYING file in the top-level directory.
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef HW_AVR_ATMEGA_H
> +#define HW_AVR_ATMEGA_H
> +
> +#include "hw/char/avr_usart.h"
> +#include "hw/char/avr_usart.h"

Oops duplicated header.

> +#include "hw/timer/avr_timer16.h"
> +#include "hw/misc/avr_mask.h"
> +#include "target/avr/cpu.h"
[...]

[RFC PATCH 07/10] hw/avr: Add few Arduino boards

[Philippe Mathieu-Daudé]

Add famous Arduino boards:

- Arduino Duemilanove
- Arduino Mega

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/avr/arduino.c | 173 +++
 hw/avr/Makefile.objs |   1 +
 2 files changed, 174 insertions(+)
 create mode 100644 hw/avr/arduino.c

diff --git a/hw/avr/arduino.c b/hw/avr/arduino.c
new file mode 100644
index 00..191193d614
--- /dev/null
+++ b/hw/avr/arduino.c
@@ -0,0 +1,173 @@
+/*
+ * QEMU Arduino boards
+ *
+ * Copyright (c) 2019 Philippe Mathieu-Daudé
+ *
+ * This work is licensed under the terms of the GNU GPLv2 or later.
+ * See the COPYING file in the top-level directory.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+/* TODO: Implement the use of EXTRAM */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "elf.h"
+#include "atmega.h"
+
+typedef struct ArduinoBoardConfig {
+const char *name;
+const char *desc;
+const char *alias;
+const char *mcu_type;
+uint64_t xtal_hz;
+size_t extram_size;
+bool is_default;
+} ArduinoBoardConfig;
+
+static const ArduinoBoardConfig arduino_boards[] = {
+{
+/* https://www.arduino.cc/en/Main/ArduinoBoardDuemilanove */
+.name   = MACHINE_TYPE_NAME("arduino-duemilanove"),
+.desc   = "Arduino Duemilanove (ATmega168)",
+.alias  = "2009",
+.mcu_type= TYPE_ATMEGA168,
+.xtal_hz= 16 * 1000 * 1000,
+}, {
+/* https://store.arduino.cc/arduino-uno-rev3 */
+.name   = MACHINE_TYPE_NAME("arduino-uno"),
+.desc   = "Arduino Duemilanove (ATmega328P)",
+.alias  = "UNO",
+.mcu_type= TYPE_ATMEGA328,
+.xtal_hz= 16 * 1000 * 1000,
+}, {
+/* https://www.arduino.cc/en/Main/ArduinoBoardMega */
+.name   = MACHINE_TYPE_NAME("arduino-mega"),
+.desc   = "Arduino Mega (ATmega1280)",
+.alias  = "MEGA",
+.mcu_type= TYPE_ATMEGA1280,
+.xtal_hz= 16 * 1000 * 1000,
+}, {
+/* https://store.arduino.cc/arduino-mega-2560-rev3 */
+.name   = MACHINE_TYPE_NAME("arduino-mega-2560-v3"),
+.desc   = "Arduino Mega 2560 (ATmega2560)",
+.alias  = "MEGA2560",
+.mcu_type= TYPE_ATMEGA2560,
+.xtal_hz= 16 * 1000 * 1000, /* CSTCE16M0V53-R0 */
+.is_default = true,
+},
+};
+
+typedef struct ArduinoMachineState {
+/*< private >*/
+MachineState parent_obj;
+/*< public >*/
+AtmegaState mcu;
+MemoryRegion extram;
+} ArduinoMachineState;
+
+typedef struct ArduinoMachineClass {
+/*< private >*/
+MachineClass parent_class;
+/*< public >*/
+const ArduinoBoardConfig *config;
+} ArduinoMachineClass;
+
+#define TYPE_ARDUINO_MACHINE \
+MACHINE_TYPE_NAME("arduino")
+#define ARDUINO_MACHINE(obj) \
+OBJECT_CHECK(ArduinoMachineState, (obj), TYPE_ARDUINO_MACHINE)
+#define ARDUINO_MACHINE_CLASS(klass) \
+OBJECT_CLASS_CHECK(ArduinoMachineClass, (klass), TYPE_ARDUINO_MACHINE)
+#define ARDUINO_MACHINE_GET_CLASS(obj) \
+OBJECT_GET_CLASS(ArduinoMachineClass, (obj), TYPE_ARDUINO_MACHINE)
+
+static void load_firmware(const char *firmware, uint64_t flash_size)
+{
+const char *filename;
+int bytes_loaded;
+
+/* Load firmware (contents of flash) trying to auto-detect format */
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, firmware);
+if (filename == NULL) {
+error_report("Unable to find %s", firmware);
+exit(1);
+}
+
+bytes_loaded = load_elf(filename, NULL, NULL, NULL, NULL, NULL, NULL,
+0, EM_NONE, 0, 0);
+if (bytes_loaded < 0) {
+bytes_loaded = load_image_targphys(filename, OFFSET_CODE, flash_size);
+}
+if (bytes_loaded < 0) {
+error_report("Unable to load firmware image %s as ELF or raw binary",
+ firmware);
+exit(1);
+}
+}
+
+static void arduino_machine_init(MachineState *machine)
+{
+ArduinoMachineClass *amc = ARDUINO_MACHINE_GET_CLASS(machine);
+ArduinoMachineState *ams = ARDUINO_MACHINE(machine);
+
+sysbus_init_child_obj(OBJECT(machine), "mcu", &ams->mcu, sizeof(ams->mcu),
+  amc->config->mcu_type);
+object_property_set_uint(OBJECT(&ams->mcu), amc->config->xtal_hz,
+ "xtal-frequency-hz", &error_abort);
+object_property_set_bool(OBJECT(&ams->mcu), true, "realized",
+ &error_abort);
+
+if (machine->firmware) {
+load_firmware(machine->firmware, memory_region_size(&ams->mcu.flash));
+}
+}
+
+static void arduino_machine_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+ArduinoMachineClass *amc = ARDUINO_MACHINE_CLASS(oc);
+const ArduinoBoardConfig *cfg = data;
+
+mc->desc = cfg->desc;
+mc->alias = cfg->alias;
+mc->i

[NOTFORMERGE PATCH 04/10] target/avr: Fix IRQ count

[Philippe Mathieu-Daudé]

Fix a SEGV when using IRQ#57 by expanding to 64 IRQs.
64 is a magic number.

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/avr/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/avr/cpu.c b/target/avr/cpu.c
index 52ec21dd16..8198f9d49c 100644
--- a/target/avr/cpu.c
+++ b/target/avr/cpu.c
@@ -129,7 +129,7 @@ static void avr_cpu_initfn(Object *obj)
 
 #ifndef CONFIG_USER_ONLY
 /* Set the number of interrupts supported by the CPU. */
-qdev_init_gpio_in(DEVICE(cpu), avr_cpu_set_int, 57);
+qdev_init_gpio_in(DEVICE(cpu), avr_cpu_set_int, 64);
 #endif
 }
 
-- 
2.21.0

[PATCH 02/10] target/avr: Remove unused include

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/avr/helper.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/avr/helper.c b/target/avr/helper.c
index f1939bd5a7..75946209b8 100644
--- a/target/avr/helper.c
+++ b/target/avr/helper.c
@@ -21,7 +21,6 @@
 #include "qemu/osdep.h"
 
 #include "cpu.h"
-#include "hw/irq.h"
 #include "hw/sysbus.h"
 #include "sysemu/sysemu.h"
 #include "exec/exec-all.h"
-- 
2.21.0

[PATCH 03/10] target/avr: Add missing definitions

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/avr/cpu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/avr/cpu.h b/target/avr/cpu.h
index a3e615a1eb..c1448a865f 100644
--- a/target/avr/cpu.h
+++ b/target/avr/cpu.h
@@ -26,6 +26,8 @@
 
 #define TCG_GUEST_DEFAULT_MO 0
 
+#define AVR_CPU_TYPE_SUFFIX "-" TYPE_AVR_CPU
+#define AVR_CPU_TYPE_NAME(name) (name AVR_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_AVR_CPU
 
 /*
-- 
2.21.0

[RFC PATCH 05/10] hw/char/avr: Reduce USART I/O size

[Philippe Mathieu-Daudé]

Per the datasheet the USART uses 6 consecutive 8-bit registers.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/char/avr_usart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
index d039689c56..ba17bdd470 100644
--- a/hw/char/avr_usart.c
+++ b/hw/char/avr_usart.c
@@ -284,7 +284,7 @@ static void avr_usart_init(Object *obj)
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->rxc_irq);
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->dre_irq);
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->txc_irq);
-memory_region_init_io(&s->mmio, obj, &avr_usart_ops, s, TYPE_AVR_USART, 8);
+memory_region_init_io(&s->mmio, obj, &avr_usart_ops, s, TYPE_AVR_USART, 6);
 sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
 qdev_init_gpio_in(DEVICE(s), avr_usart_pr, 1);
 s->enabled = true;
-- 
2.21.0

[RFC PATCH 00/10] hw/avr: Introduce the Arduino board

[Philippe Mathieu-Daudé]

Hi Michael,

I complained I'd rather have QEMU model real hardware, with
documentation (schematics).
Since your series is almost ready to get merged, I prefered to
spend some time now to write down what I wanted. This is mostly
a rewrite of your board, but matching the Arduino boards.

Some bug slipped in (uart interrupt not raised) but I'm too tired
to find it, and since I won't have time to look at it the next
days, I prefer to send this now.

The first part of the series are quick review notes, which you
should squash in your previous patches.

I still have in my TODO before merge:
- Fix the USART IRQ bug
- Split "Add limited support for USART and 16 bit timer peripherals"
  in 3 patches: USART/Timer16/INTC

And TODO after merge is:
- Extract Timer8 common parts from Timer16
- Add GPIOs
- Connect LED to GPIO on Arduino

Thank you for having insisted with this during so long!

Regards,

Phil.

Based-on: <20191127175257.23480-1-mrol...@gmail.com>
https://www.mail-archive.com/qemu-devel@nongnu.org/msg661553.html

Philippe Mathieu-Daudé (10):
  hw/avr: Kludge to fix build failure
  target/avr: Remove unused include
  target/avr: Add missing definitions
  target/avr: Fix IRQ count
  hw/char/avr: Reduce USART I/O size
  hw/avr: Add ATmega microcontrollers
  hw/avr: Add few Arduino boards
  tests/acceptance: Keep multilines comment consistent with other tests
  tests/acceptance: Use the ATmega2560 board
  hw/avr: Remove the 'sample' board

 hw/avr/atmega.h  |  58 +
 include/hw/char/avr_usart.h  |   2 +
 target/avr/cpu.h |   2 +
 hw/avr/arduino.c | 173 ++
 hw/avr/atmega.c  | 379 +++
 hw/avr/sample.c  | 282 ---
 hw/char/avr_usart.c  |   2 +-
 target/avr/cpu.c |   2 +-
 target/avr/helper.c  |   1 -
 hw/avr/Makefile.objs |   3 +-
 tests/acceptance/machine_avr6.py |  10 +-
 11 files changed, 623 insertions(+), 291 deletions(-)
 create mode 100644 hw/avr/atmega.h
 create mode 100644 hw/avr/arduino.c
 create mode 100644 hw/avr/atmega.c
 delete mode 100644 hw/avr/sample.c

-- 
2.21.0

[NOTFORMERGE PATCH 01/10] hw/avr: Kludge to fix build failure

[Philippe Mathieu-Daudé]

Incomplete rename between Michael v36/v37

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/char/avr_usart.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/hw/char/avr_usart.h b/include/hw/char/avr_usart.h
index 8e9ee88bbd..87f3f54cf8 100644
--- a/include/hw/char/avr_usart.h
+++ b/include/hw/char/avr_usart.h
@@ -94,4 +94,6 @@ typedef struct {
 qemu_irq dre_irq;
 } AVRUsartState;
 
+typedef AVRUsartState AvrUsartState;
+
 #endif /* HW_AVR_USART_H */
-- 
2.21.0

RE: Network connection with COLO VM

[Zhang, Chen]

> -Original Message-
> From: Dr. David Alan Gilbert 
> Sent: Wednesday, November 27, 2019 6:51 PM
> To: Daniel Cho ; Zhang, Chen
> ; lukasstra...@web.de
> Cc: qemu-devel@nongnu.org
> Subject: Re: Network connection with COLO VM
> 
> * Daniel Cho (daniel...@qnap.com) wrote:
> > Hello everyone,
> >
> > Could we ssh to colo VM (means PVM & SVM are starting)?
> >
> 
> Lets cc in Zhang Chen and Lukas Straub.

Thanks Dave.

> 
> > SSH will connect to colo VM for a while, but it will disconnect with
> > error
> > *client_loop: send disconnect: Broken pipe*
> >
> > It seems to colo VM could not keep network session.
> >
> > Does it be a known issue?
> 
> That sounds like the COLO proxy is getting upset; it's supposed to compare
> packets sent by the primary and secondary and only send one to the outside
> - you shouldn't be talking directly to the guest, but always via the proxy.  
> See
> docs/colo-proxy.txt
> 

Hi Daniel,

I have try ssh to COLO guest with 8 hours, not occurred this issue.
Please check your network/qemu configuration.
But I found another problem maybe related this issue, if no network 
communication for a period of time(maybe 10min), the first message send to 
guest have a chance with delay(maybe 1-5 sec), I will try to fix it when I have 
time.

Thanks
Zhang Chen

> Dave
> 
> > Best Regard,
> > Daniel Cho
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH 4/4] qom/object: Use common get/set uint helpers

[Alexey Kardashevskiy]

On 26/11/2019 20:39, Felipe Franciosi wrote:
> 
> 
>> On Nov 26, 2019, at 8:39 AM, Marc-André Lureau  
>> wrote:
>>
>> Hi
> 
> Heya, thanks for the review.
> 
>>
>> On Mon, Nov 25, 2019 at 7:37 PM Felipe Franciosi  wrote:
>>>
>>> Several objects implemented their own uint property getters and setters,
>>> despite them being straightforward (without any checks/validations on
>>> the values themselves) and identical across objects. This makes use of
>>> an enhanced API for object_property_add_uintXX_ptr() which offers
>>> default setters.
>>>
>>> Some of these setters used to update the value even if the type visit
>>> failed (eg. because the value being set overflowed over the given type).
>>> The new setter introduces a check for these errors, not updating the
>>> value if an error occurred. The error is propagated.
>>>
>>> Signed-off-by: Felipe Franciosi 
>>
>>
>> Some comments below, otherwise:
>> Reviewed-by: Marc-André Lureau 
>>
>>> ---
>>> hw/acpi/ich9.c   |  93 +++
>>> hw/isa/lpc_ich9.c|  14 +-
>>> hw/misc/edu.c|  12 +
>>> hw/pci-host/q35.c|  14 ++
>>> hw/ppc/spapr.c   |  17 ++--
>>> hw/vfio/pci-quirks.c |  18 ++--
>>> memory.c |  15 +--
>>> target/arm/cpu.c |  21 +
>>> target/i386/sev.c| 102 +++
>>> 9 files changed, 29 insertions(+), 277 deletions(-)
>>>
>>> diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
>>> index 94dc5147ce..aa3c7a59ab 100644
>>> --- a/hw/acpi/ich9.c
>>> +++ b/hw/acpi/ich9.c
>>> @@ -357,81 +357,6 @@ static void ich9_pm_set_cpu_hotplug_legacy(Object 
>>> *obj, bool value,
>>> s->pm.cpu_hotplug_legacy = value;
>>> }
>>>
>>> -static void ich9_pm_get_disable_s3(Object *obj, Visitor *v, const char 
>>> *name,
>>> -   void *opaque, Error **errp)
>>> -{
>>> -ICH9LPCPMRegs *pm = opaque;
>>> -uint8_t value = pm->disable_s3;
>>> -
>>> -visit_type_uint8(v, name, &value, errp);
>>> -}
>>> -
>>> -static void ich9_pm_set_disable_s3(Object *obj, Visitor *v, const char 
>>> *name,
>>> -   void *opaque, Error **errp)
>>> -{
>>> -ICH9LPCPMRegs *pm = opaque;
>>> -Error *local_err = NULL;
>>> -uint8_t value;
>>> -
>>> -visit_type_uint8(v, name, &value, &local_err);
>>> -if (local_err) {
>>> -goto out;
>>> -}
>>> -pm->disable_s3 = value;
>>> -out:
>>> -error_propagate(errp, local_err);
>>> -}
>>> -
>>> -static void ich9_pm_get_disable_s4(Object *obj, Visitor *v, const char 
>>> *name,
>>> -   void *opaque, Error **errp)
>>> -{
>>> -ICH9LPCPMRegs *pm = opaque;
>>> -uint8_t value = pm->disable_s4;
>>> -
>>> -visit_type_uint8(v, name, &value, errp);
>>> -}
>>> -
>>> -static void ich9_pm_set_disable_s4(Object *obj, Visitor *v, const char 
>>> *name,
>>> -   void *opaque, Error **errp)
>>> -{
>>> -ICH9LPCPMRegs *pm = opaque;
>>> -Error *local_err = NULL;
>>> -uint8_t value;
>>> -
>>> -visit_type_uint8(v, name, &value, &local_err);
>>> -if (local_err) {
>>> -goto out;
>>> -}
>>> -pm->disable_s4 = value;
>>> -out:
>>> -error_propagate(errp, local_err);
>>> -}
>>> -
>>> -static void ich9_pm_get_s4_val(Object *obj, Visitor *v, const char *name,
>>> -   void *opaque, Error **errp)
>>> -{
>>> -ICH9LPCPMRegs *pm = opaque;
>>> -uint8_t value = pm->s4_val;
>>> -
>>> -visit_type_uint8(v, name, &value, errp);
>>> -}
>>> -
>>> -static void ich9_pm_set_s4_val(Object *obj, Visitor *v, const char *name,
>>> -   void *opaque, Error **errp)
>>> -{
>>> -ICH9LPCPMRegs *pm = opaque;
>>> -Error *local_err = NULL;
>>> -uint8_t value;
>>> -
>>> -visit_type_uint8(v, name, &value, &local_err);
>>> -if (local_err) {
>>> -goto out;
>>> -}
>>> -pm->s4_val = value;
>>> -out:
>>> -error_propagate(errp, local_err);
>>> -}
>>> -
>>> static bool ich9_pm_get_enable_tco(Object *obj, Error **errp)
>>> {
>>> ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
>>> @@ -468,18 +393,12 @@ void ich9_pm_add_properties(Object *obj, 
>>> ICH9LPCPMRegs *pm, Error **errp)
>>>  ich9_pm_get_cpu_hotplug_legacy,
>>>  ich9_pm_set_cpu_hotplug_legacy,
>>>  NULL);
>>> -object_property_add(obj, ACPI_PM_PROP_S3_DISABLED, "uint8",
>>> -ich9_pm_get_disable_s3,
>>> -ich9_pm_set_disable_s3,
>>> -NULL, pm, NULL);
>>> -object_property_add(obj, ACPI_PM_PROP_S4_DISABLED, "uint8",
>>> -ich9_pm_get_disable_s4,
>>> -ich9_pm_set_disable_s4,
>>> -NULL, pm, NULL);
>>> -object_property_add(obj, ACPI_PM_PROP_S4_VAL, "uint8",
>>> -ich9_pm_g

Re: [PATCH v36 17/17] target/avr: Update MAINTAINERS file

[Eduardo Habkost]

On Tue, Nov 26, 2019 at 12:49:40AM +0100, Aleksandar Markovic wrote:
> On Sunday, November 24, 2019, Michael Rolnik  wrote:
> 
> > Include AVR maintaners in MAINTAINERS file
> >
> > Signed-off-by: Michael Rolnik 
> > ---
> >  MAINTAINERS | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5e5e3e52d6..ad2d9dd04a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -163,6 +163,15 @@ S: Maintained
> >  F: hw/arm/smmu*
> >  F: include/hw/arm/smmu*
> >
> > +AVR TCG CPUs
> > +M: Michael Rolnik 
> > +S: Maintained
> > +F: target/avr/
> > +F: hw/misc/avr_mask.c
> > +F: hw/char/avr_usart.c
> > +F: hw/timer/avr_timer16.c
> > +F: hw/avr/
> > +
> 
> 
> If Cleber and Eduardo don't object, please add file:
> 
> tests/acceptance/machine_avr6.py
> 
> to the list. This means that the file would have a sort of "dual"
> maintainrship: Cleber and Eduardo would take care of Python/Avocado/test
> harness aspects, while you and Sarah would take care of AVR aspects.

No objections.  Thanks!

> 
> Cleber and Eduardo, please note that AVR target will be significantly
> different than others, since these CPUs are not meant to work with Linux
> kernel, and there are other idiosyncracies where AVR folks would be really
> needed. There is also a case of MIPS-specific Avocado test where, at least
> from my point of view, dual maintainership worked well, so I think this one
> would work well too.
> 
> With or without that file addition:
> 
> Reviewed-by: Aleksandar Markovic 

-- 
Eduardo

Re: [RFC net-next 00/18] virtio_net XDP offload

[Jakub Kicinski]

On Wed, 27 Nov 2019 15:32:17 -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 26, 2019 at 12:35:14PM -0800, Jakub Kicinski wrote:
> > On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:  
> > > Note: This RFC has been sent to netdev as well as qemu-devel lists
> > > 
> > > This series introduces XDP offloading from virtio_net. It is based on
> > > the following work by Jason Wang:
> > > https://netdevconf.info/0x13/session.html?xdp-offload-with-virtio-net
> > > 
> > > Current XDP performance in virtio-net is far from what we can achieve
> > > on host. Several major factors cause the difference:
> > > - Cost of virtualization
> > > - Cost of virtio (populating virtqueue and context switching)
> > > - Cost of vhost, it needs more optimization
> > > - Cost of data copy
> > > Because of above reasons there is a need of offloading XDP program to
> > > host. This set is an attempt to implement XDP offload from the guest.  
> > 
> > This turns the guest kernel into a uAPI proxy.
> > 
> > BPF uAPI calls related to the "offloaded" BPF objects are forwarded 
> > to the hypervisor, they pop up in QEMU which makes the requested call
> > to the hypervisor kernel. Today it's the Linux kernel tomorrow it may 
> > be someone's proprietary "SmartNIC" implementation.
> > 
> > Why can't those calls be forwarded at the higher layer? Why do they
> > have to go through the guest kernel?  
> 
> Well everyone is writing these programs and attaching them to NICs.

Who's everyone?

> For better or worse that's how userspace is written.

HW offload requires modifying the user space, too. The offload is not
transparent. Do you know that?

> Yes, in the simple case where everything is passed through, it could
> instead be passed through some other channel just as well, but then
> userspace would need significant changes just to make it work with
> virtio.

There is a recently spawned effort to create an "XDP daemon" or
otherwise a control application which would among other things link
separate XDP apps to share a NIC attachment point.

Making use of cloud APIs would make a perfect addition to that.

Obviously if one asks a kernel guy to solve a problem one'll get kernel
code as an answer. And writing higher layer code requires companies to
actually organize their teams and have "full stack" strategies.

We've seen this story already with net_failover wart. At least that
time we weren't risking building a proxy to someone's proprietary FW.

> > If kernel performs no significant work (or "adds value", pardon the
> > expression), and problem can easily be solved otherwise we shouldn't 
> > do the work of maintaining the mechanism.
> > 
> > The approach of kernel generating actual machine code which is then
> > loaded into a sandbox on the hypervisor/SmartNIC is another story.  
> 
> But that's transparent to guest userspace. Making userspace care whether
> it's a SmartNIC or a software device breaks part of virtualization's
> appeal, which is that it looks like a hardware box to the guest.

It's not hardware unless you JITed machine code for it, it's just
someone else's software.

I'm not arguing with the appeal. I'm arguing the risk/benefit ratio
doesn't justify opening this can of worms.

> > I'd appreciate if others could chime in.  

Re: [PATCH 1/2] analyze-migration.py: fix find() type error

[Eduardo Habkost]

On Wed, Nov 27, 2019 at 02:10:37PM +0400, Marc-André Lureau wrote:
> Traceback (most recent call last):
>   File "../scripts/analyze-migration.py", line 611, in 
> dump.read(desc_only = True)
>   File "../scripts/analyze-migration.py", line 513, in read
> self.load_vmsd_json(file)
>   File "../scripts/analyze-migration.py", line 556, in load_vmsd_json
> vmsd_json = file.read_migration_debug_json()
>   File "../scripts/analyze-migration.py", line 89, in 
> read_migration_debug_json
> nulpos = data.rfind("\0")
> TypeError: argument should be integer or bytes-like object, not 'str'
> 
> Signed-off-by: Marc-André Lureau 

Thanks!  I'm queueing this, but I'm hoping we don't have a -rc4
and 4.2.0 gets released next week.

-- 
Eduardo

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

[Caroline Concatto]

Hi Alex,

So, it works in some machines and others not. Mainly in machines with RHEL OS 
that we found the problem.
What is the OS you are using?

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

Title:
  ELF loader fails to load shared object on ThunderX2 running RHEL7

Status in QEMU:
  Incomplete

Bug description:
  Simple test:
  hello.c

  include 

  int main(int argc, char* argv[])
  {
{
  printf("Hello World... \n");
}
return 0;
  }

  when compiled with :
  *Compiler 
  
https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-allinea-studio/download
  Arm-Compiler-for-HPC_19.3_RHEL_7_aarch64.tar   

  *Running:
  1) with -armpl
   armclang -armpl hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out
  2) without flag
  armclang hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out

  •With Docker image:
 CentOS Linux release 7.7.1908 (AltArch)

  *Two different machines:
 AArch64, Taishan. tsv110, Kunpeng 920, ARMv8.2-A
 AArch64, Taishan 2280, Cortex-A72, ARMv8-A

  *QEMU 4.0
   qemu-aarch64 version 4.1.91 (v4.2.0-rc1)

  
  Results:

  
   Taishan 2280 Cortex-A72 
Running 
  1)with -armpl flag with and without the docker
WORKS-> Hello World...
 -> ldd a.out
  ldd a.out 
  linux-vdso.so.1 =>  (0xbc6a2000) 
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xbc544000) 
  libm.so.6 => /lib64/libm.so.6 (0xbc493000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xbc472000) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xbbfd3000) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xbbef5000) 
  librt.so.1 => /lib64/librt.so.1 (0xbbed4000) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xbbe9f000) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xb3306000) 
  libc.so.6 => /lib64/libc.so.6 (0xb318) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xb2f3) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xb2eff000) 
  libdl.so.2 => /lib64/libdl.so.2 (0xb2ede000) 
  /lib/ld-linux-aarch64.so.1 (0xbc674000)
 

  Running 
  2) without -armpl flag with and without the docker
 WORKS -> Hello World...
   -> ldd a.out
  ldd a.out
   linux-vdso.so.1 =>  (0xa6895000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xa6846000) 
  libc.so.6 => /lib64/libc.so.6 (0xa66c) 
  /lib/ld-linux-aarch64.so.1 (0xa6867000)
  

  Taishan - tsv110  Kunpeng 920
 For Running 

  1)with -armpl flag with and without the docker
 DOES NOT WORK -> with and without Docker
   -> It shows : qemu:handle_cpu_signal received signal 
outside vCPU
   context @ pc=0xaaa8844a
   -> ldd a.out 
  ldd a.out 
  linux-vdso.so.1 =>  (0xad4b)
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xad37) 
  libm.so.6 => /lib64/libm.so.6 (0xad2a) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xad27) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xacdd) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xaccf) 
  librt.so.1 => /lib64/librt.so.1 (0xaccc) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xacc8) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xa40e) 
  libc.so.6 => /lib64/libc.so.6 (0xa3f5) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xa3d0) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xa3cc)
  libdl.so.2 => 

Re: [PATCH v6] 9pfs: well form error hint helpers

[Greg Kurz]

On Wed, 27 Nov 2019 22:15:49 +0300
Vladimir Sementsov-Ogievskiy  wrote:

> Make error_append_security_model_hint and
> error_append_socket_sockfd_hint hint append helpers well formed:
> rename errp to errp_in, as it is IN-parameter here (which is unusual
> for errp).
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Acked-by: Greg Kurz 
> ---
> 
> v6: add Greg's a-b
> 

I've already pushed that to my 9p-next branch:

https://github.com/gkurz/qemu/commits/9p-next


>  hw/9pfs/9p-local.c | 4 ++--
>  hw/9pfs/9p-proxy.c | 5 +++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index 4708c0bd89..76fa1858b7 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -1473,9 +1473,9 @@ static void local_cleanup(FsContext *ctx)
>  g_free(data);
>  }
>  
> -static void error_append_security_model_hint(Error **errp)
> +static void error_append_security_model_hint(Error **errp_in)
>  {
> -error_append_hint(errp, "Valid options are: security_model="
> +error_append_hint(errp_in, "Valid options are: security_model="
>"[passthrough|mapped-xattr|mapped-file|none]\n");
>  }
>  
> diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c
> index 97ab9c58a5..9e29abc3ef 100644
> --- a/hw/9pfs/9p-proxy.c
> +++ b/hw/9pfs/9p-proxy.c
> @@ -1114,9 +1114,10 @@ static int connect_namedsocket(const char *path, Error 
> **errp)
>  return sockfd;
>  }
>  
> -static void error_append_socket_sockfd_hint(Error **errp)
> +static void error_append_socket_sockfd_hint(Error **errp_in)
>  {
> -error_append_hint(errp, "Either specify socket=/some/path where 
> /some/path"
> +error_append_hint(errp_in,
> +  "Either specify socket=/some/path where /some/path"
>" points to a listening AF_UNIX socket or sock_fd=fd"
>" where fd is a file descriptor to a connected AF_UNIX"
>" socket\n");

Re: [PATCH-for-4.2] hw/mips: Deprecate the r4k machine

[Philippe Mathieu-Daudé]

On 11/27/19 10:31 PM, Aleksandar Markovic wrote:

On Wed, Nov 27, 2019 at 10:17 PM Philippe Mathieu-Daudé
 wrote:


Hi Aleksandar,

On 11/27/19 7:47 PM, Aleksandar Markovic wrote:

On Mon, Nov 25, 2019 at 11:41 AM Philippe Mathieu-Daudé
 wrote:


The r4k machine was introduced in 2005 (6af0bf9c7) and its last
logical change was in 2005 (9542611a6). After we can count 164
maintenance commits (QEMU API changes) with the exception of
1 fix in 2015 (memory leak, commit 3ad9fd5a).

This machine was introduced as a proof of concept to run a MIPS
CPU. 2 years later, the Malta machine was add (commit 5856de80)
modeling a real platform.



Since you queued this patch, do you mind adding Aurelien comment to the
patch description, as it appears important information:

'''
The Linux kernel support for this machine has been dropped more
than 10 years ago in this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=302922e5f6901eb6f29c58539631f71b3d9746b8
'''

I was not sure when sending the patch, but as an improvement, we can
also remove Aurelien and Aleksandar Rikalo from the MAINTAINERS section.

And I assume we can also add (which was explicit in your previous patch):
Acked-by: Aurelien Jarno 

If you want I can resend this patch with all that amended.



No need to resend, I'll fix the things while applying.


Thank you very much, very appreciated!

Re: [PATCH v6] ppc: well form kvmppc_hint_smt_possible error hint helper

[Greg Kurz]

On Wed, 27 Nov 2019 22:14:34 +0300
Vladimir Sementsov-Ogievskiy  wrote:

> Make kvmppc_hint_smt_possible hint append helper well formed:
> rename errp to errp_in, as it is IN-parameter here (which is unusual
> for errp), rename function to be kvmppc_error_append_*_hint.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Reviewed-by: Marc-André Lureau 
> ---
> 

Reviewed-by: Greg Kurz 

> v6: keep kvmppc_ function prefix
> add r-b by Marc-André
> 
>  target/ppc/kvm_ppc.h | 4 ++--
>  hw/ppc/spapr.c   | 2 +-
>  target/ppc/kvm.c | 6 +++---
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
> index 98bd7d5da6..47b08a4030 100644
> --- a/target/ppc/kvm_ppc.h
> +++ b/target/ppc/kvm_ppc.h
> @@ -28,7 +28,7 @@ void kvmppc_set_papr(PowerPCCPU *cpu);
>  int kvmppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr);
>  void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy);
>  int kvmppc_smt_threads(void);
> -void kvmppc_hint_smt_possible(Error **errp);
> +void kvmppc_error_append_smt_possible_hint(Error **errp_in);
>  int kvmppc_set_smt_threads(int smt);
>  int kvmppc_clear_tsr_bits(PowerPCCPU *cpu, uint32_t tsr_bits);
>  int kvmppc_or_tsr_bits(PowerPCCPU *cpu, uint32_t tsr_bits);
> @@ -164,7 +164,7 @@ static inline int kvmppc_smt_threads(void)
>  return 1;
>  }
>  
> -static inline void kvmppc_hint_smt_possible(Error **errp)
> +static inline void kvmppc_error_append_smt_possible_hint(Error **errp_in)
>  {
>  return;
>  }
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index e076f6023c..1b87eb0ffd 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2564,7 +2564,7 @@ static void spapr_set_vsmt_mode(SpaprMachineState 
> *spapr, Error **errp)
>" requires the use of VSMT mode %d.\n",
>smp_threads, kvm_smt, spapr->vsmt);
>  }
> -kvmppc_hint_smt_possible(&local_err);
> +kvmppc_error_append_smt_possible_hint(&local_err);
>  goto out;
>  }
>  }
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index c77f9848ec..7406d18945 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2076,7 +2076,7 @@ int kvmppc_set_smt_threads(int smt)
>  return ret;
>  }
>  
> -void kvmppc_hint_smt_possible(Error **errp)
> +void kvmppc_error_append_smt_possible_hint(Error **errp_in)
>  {
>  int i;
>  GString *g;
> @@ -2091,10 +2091,10 @@ void kvmppc_hint_smt_possible(Error **errp)
>  }
>  }
>  s = g_string_free(g, false);
> -error_append_hint(errp, "%s.\n", s);
> +error_append_hint(errp_in, "%s.\n", s);
>  g_free(s);
>  } else {
> -error_append_hint(errp,
> +error_append_hint(errp_in,
>"This KVM seems to be too old to support VSMT.\n");
>  }
>  }

Re: [PATCH v37 02/17] target/avr: Add instruction helpers

[Philippe Mathieu-Daudé]

On 11/27/19 6:52 PM, Michael Rolnik wrote:

Stubs for unimplemented instructions and helpers for instructions that need to 
interact with QEMU.
SPM and WDR are unimplemented because they require emulation of complex 
peripherals.
The implementation of SLEEP is very limited due to the lack of peripherals to 
generate wake interrupts.
Memory access instructions are implemented here because some address ranges 
actually refer to CPU registers.

Signed-off-by: Michael Rolnik 
Tested-by: Philippe Mathieu-Daudé 
---
  target/avr/helper.h |  29 
  target/avr/helper.c | 354 
  2 files changed, 383 insertions(+)
  create mode 100644 target/avr/helper.h
  create mode 100644 target/avr/helper.c

diff --git a/target/avr/helper.h b/target/avr/helper.h
new file mode 100644
index 00..bf087504a8
--- /dev/null
+++ b/target/avr/helper.h
@@ -0,0 +1,29 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+DEF_HELPER_1(wdr, void, env)
+DEF_HELPER_1(debug, void, env)
+DEF_HELPER_1(break, void, env)
+DEF_HELPER_1(sleep, void, env)
+DEF_HELPER_1(unsupported, void, env)
+DEF_HELPER_3(outb, void, env, i32, i32)
+DEF_HELPER_2(inb, tl, env, i32)
+DEF_HELPER_3(fullwr, void, env, i32, i32)
+DEF_HELPER_2(fullrd, tl, env, i32)
diff --git a/target/avr/helper.c b/target/avr/helper.c
new file mode 100644
index 00..f1939bd5a7
--- /dev/null
+++ b/target/avr/helper.c
@@ -0,0 +1,354 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+
+#include "cpu.h"
+#include "hw/irq.h"


Nitpicking again, the previous include doesn't seem used.


+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h"
+#include "exec/exec-all.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-proto.h"
+#include "exec/ioport.h"
+#include "qemu/host-utils.h"
+#include "qemu/error-report.h"
+
+bool avr_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
+{
+bool ret = false;
+CPUClass *cc = CPU_GET_CLASS(cs);
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = &cpu->env;
+
+if (interrupt_request & CPU_INTERRUPT_RESET) {
+if (cpu_interrupts_enabled(env)) {
+cs->exception_index = EXCP_RESET;
+cc->do_interrupt(cs);
+
+cs->interrupt_request &= ~CPU_INTERRUPT_RESET;
+
+ret = true;
+}
+}
+if (interrupt_request & CPU_INTERRUPT_HARD) {
+if (cpu_interrupts_enabled(env) && env->intsrc != 0) {
+int index = ctz32(env->intsrc);
+cs->exception_index = EXCP_INT(index);
+cc->do_interrupt(cs);
+
+env->intsrc &= env->intsrc - 1; /* clear the interrupt */
+cs->interrupt_request &= ~CPU_INTERRUPT_HARD;
+
+ret = true;
+}
+}
+return ret;
+}
+
+void avr_cpu_do_interrupt(CPUState *cs)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = &cpu->env;
+
+uint32_t ret = env->pc_w;
+int vector = 0;
+int size = avr_feature(env, AVR_FEATURE_JMP_CALL) ? 2 : 1;
+int base = 0;
+
+if (cs->exception_index == EXCP_RESET) {
+vector = 0;
+} else if (env->intsrc != 0) {
+vector = ctz32(env->intsrc) + 1;
+}
+
+if (avr_feature(env, AVR_FEATURE_3_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+cpu_stb_data(env, env->sp--, (ret & 0xff) >> 16);
+} else if (avr_feature(env, AVR_FEATURE_2_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env-

Re: [PATCH v37 01/17] target/avr: Add outward facing interfaces and core CPU logic

[Philippe Mathieu-Daudé]

Hi Michael,

On 11/27/19 6:52 PM, Michael Rolnik wrote:

This includes:
- CPU data structures
- object model classes and functions
- migration functions
- GDB hooks

Co-developed-by: Michael Rolnik 
Co-developed-by: Sarah Harris 
Signed-off-by: Michael Rolnik 
Signed-off-by: Sarah Harris 
Signed-off-by: Michael Rolnik 
Acked-by: Igor Mammedov 
Tested-by: Philippe Mathieu-Daudé 
---
  target/avr/cpu-param.h |  37 +++
  target/avr/cpu-qom.h   |  54 
  target/avr/cpu.h   | 253 ++
  target/avr/cpu.c   | 576 +
  target/avr/gdbstub.c   |  85 ++
  target/avr/machine.c   | 121 +
  gdb-xml/avr-cpu.xml|  49 
  7 files changed, 1175 insertions(+)
  create mode 100644 target/avr/cpu-param.h
  create mode 100644 target/avr/cpu-qom.h
  create mode 100644 target/avr/cpu.h
  create mode 100644 target/avr/cpu.c
  create mode 100644 target/avr/gdbstub.c
  create mode 100644 target/avr/machine.c
  create mode 100644 gdb-xml/avr-cpu.xml

diff --git a/target/avr/cpu-param.h b/target/avr/cpu-param.h
new file mode 100644
index 00..ccd1ea3429
--- /dev/null
+++ b/target/avr/cpu-param.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#ifndef AVR_CPU_PARAM_H
+#define AVR_CPU_PARAM_H 1
+
+#define TARGET_LONG_BITS 32
+/*
+ * TARGET_PAGE_BITS cannot be more than 8 bits because
+ * 1.  all IO registers occupy [0x .. 0x00ff] address range, and they
+ * should be implemented as a device and not memory
+ * 2.  SRAM starts at the address 0x0100
+ */
+#define TARGET_PAGE_BITS 8
+#define TARGET_PHYS_ADDR_SPACE_BITS 24
+#define TARGET_VIRT_ADDR_SPACE_BITS 24
+#define NB_MMU_MODES 2
+
+
+#endif
diff --git a/target/avr/cpu-qom.h b/target/avr/cpu-qom.h
new file mode 100644
index 00..e28b58c897
--- /dev/null
+++ b/target/avr/cpu-qom.h
@@ -0,0 +1,54 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#ifndef QEMU_AVR_QOM_H
+#define QEMU_AVR_QOM_H
+
+#include "hw/core/cpu.h"
+
+#define TYPE_AVR_CPU "avr-cpu"
+
+#define AVR_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(AVRCPUClass, (klass), TYPE_AVR_CPU)
+#define AVR_CPU(obj) \
+OBJECT_CHECK(AVRCPU, (obj), TYPE_AVR_CPU)
+#define AVR_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(AVRCPUClass, (obj), TYPE_AVR_CPU)
+
+/**
+ *  AVRCPUClass:
+ *  @parent_realize: The parent class' realize handler.
+ *  @parent_reset: The parent class' reset handler.
+ *  @vr: Version Register value.
+ *
+ *  A AVR CPU model.
+ */
+typedef struct AVRCPUClass {
+/*< private >*/
+CPUClass parent_class;
+/*< public >*/
+DeviceRealize parent_realize;
+void (*parent_reset)(CPUState *cpu);
+} AVRCPUClass;
+
+typedef struct AVRCPU AVRCPU;
+
+
+#endif /* !defined (QEMU_AVR_CPU_QOM_H) */
diff --git a/target/avr/cpu.h b/target/avr/cpu.h
new file mode 100644
index 00..9ea5260165
--- /dev/null
+++ b/target/avr/cpu.h
@@ -0,0 +1,253 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU 

[PATCH 1/2] exec: flush CPU TB cache in breakpoint_invalidate

[Max Filippov]

When a breakpoint is inserted at location for which there's currently no
virtual to physical translation no action is taken on CPU TB cache. If a
TB for that virtual address already exists but is not visible ATM the
breakpoint won't be hit next time an instruction at that address will be
executed.

Flush entire CPU TB cache in breakpoint_invalidate to force
re-translation of all TBs for the breakpoint address.

This change fixes the following scenario:
- linux user application is running
- a breakpoint is inserted from QEMU gdbstub for a user address that is
  not currently present in the target CPU TLB
- an instruction at that address is executed, but the external debugger
  doesn't get control.

Signed-off-by: Max Filippov 
---
Changes RFC->v1:
- do tb_flush in breakpoint_invalidate unconditionally

 exec.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/exec.c b/exec.c
index ffdb5185353b..1709b760edc1 100644
--- a/exec.c
+++ b/exec.c
@@ -1017,14 +1017,13 @@ void tb_invalidate_phys_addr(AddressSpace *as, hwaddr 
addr, MemTxAttrs attrs)
 
 static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
 {
-MemTxAttrs attrs;
-hwaddr phys = cpu_get_phys_page_attrs_debug(cpu, pc, &attrs);
-int asidx = cpu_asidx_from_attrs(cpu, attrs);
-if (phys != -1) {
-/* Locks grabbed by tb_invalidate_phys_addr */
-tb_invalidate_phys_addr(cpu->cpu_ases[asidx].as,
-phys | (pc & ~TARGET_PAGE_MASK), attrs);
-}
+/*
+ * There may not be a virtual to physical translation for the pc
+ * right now, but there may exist cached TB for this pc.
+ * Flush the whole TB cache to force re-translation of such TBs.
+ * This is heavyweight, but we're debugging anyway.
+ */
+tb_flush(cpu);
 }
 #endif
 
-- 
2.20.1

[PATCH 2/2] exec: drop tb_invalidate_phys_addr

[Max Filippov]

The only remaining user of tb_invalidate_phys_addr is target/xtensa
instruction breakpoint code and it is better to use tb_flush there.

Drop tb_invalidate_phys_addr implementations and declarations.
Use tb_flush in xtensa IBREAK helpers.

Signed-off-by: Max Filippov 
---
 exec.c | 29 ++---
 include/exec/exec-all.h|  3 ---
 target/xtensa/dbg_helper.c | 19 +++
 3 files changed, 5 insertions(+), 46 deletions(-)

diff --git a/exec.c b/exec.c
index 1709b760edc1..4d20fc005520 100644
--- a/exec.c
+++ b/exec.c
@@ -983,38 +983,13 @@ const char *parse_cpu_option(const char *cpu_option)
 }
 
 #if defined(CONFIG_USER_ONLY)
-void tb_invalidate_phys_addr(target_ulong addr)
+static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
 {
 mmap_lock();
-tb_invalidate_phys_page_range(addr, addr + 1);
+tb_invalidate_phys_page_range(pc, pc + 1);
 mmap_unlock();
 }
-
-static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
-{
-tb_invalidate_phys_addr(pc);
-}
 #else
-void tb_invalidate_phys_addr(AddressSpace *as, hwaddr addr, MemTxAttrs attrs)
-{
-ram_addr_t ram_addr;
-MemoryRegion *mr;
-hwaddr l = 1;
-
-if (!tcg_enabled()) {
-return;
-}
-
-RCU_READ_LOCK_GUARD();
-mr = address_space_translate(as, addr, &addr, &l, false, attrs);
-if (!(memory_region_is_ram(mr)
-  || memory_region_is_romd(mr))) {
-return;
-}
-ram_addr = memory_region_get_ram_addr(mr) + addr;
-tb_invalidate_phys_page_range(ram_addr, ram_addr + 1);
-}
-
 static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
 {
 /*
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index d85e610e85b9..585fe7ff430c 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -449,10 +449,7 @@ static inline uint32_t curr_cflags(void)
 
 /* TranslationBlock invalidate API */
 #if defined(CONFIG_USER_ONLY)
-void tb_invalidate_phys_addr(target_ulong addr);
 void tb_invalidate_phys_range(target_ulong start, target_ulong end);
-#else
-void tb_invalidate_phys_addr(AddressSpace *as, hwaddr addr, MemTxAttrs attrs);
 #endif
 void tb_flush(CPUState *cpu);
 void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr);
diff --git a/target/xtensa/dbg_helper.c b/target/xtensa/dbg_helper.c
index be1f81107b43..2481dc326fba 100644
--- a/target/xtensa/dbg_helper.c
+++ b/target/xtensa/dbg_helper.c
@@ -33,19 +33,6 @@
 #include "exec/exec-all.h"
 #include "exec/address-spaces.h"
 
-static void tb_invalidate_virtual_addr(CPUXtensaState *env, uint32_t vaddr)
-{
-uint32_t paddr;
-uint32_t page_size;
-unsigned access;
-int ret = xtensa_get_physical_addr(env, false, vaddr, 2, 0,
-   &paddr, &page_size, &access);
-if (ret == 0) {
-tb_invalidate_phys_addr(&address_space_memory, paddr,
-MEMTXATTRS_UNSPECIFIED);
-}
-}
-
 void HELPER(wsr_ibreakenable)(CPUXtensaState *env, uint32_t v)
 {
 uint32_t change = v ^ env->sregs[IBREAKENABLE];
@@ -53,7 +40,8 @@ void HELPER(wsr_ibreakenable)(CPUXtensaState *env, uint32_t v)
 
 for (i = 0; i < env->config->nibreak; ++i) {
 if (change & (1 << i)) {
-tb_invalidate_virtual_addr(env, env->sregs[IBREAKA + i]);
+tb_flush(env_cpu(env));
+break;
 }
 }
 env->sregs[IBREAKENABLE] = v & ((1 << env->config->nibreak) - 1);
@@ -62,8 +50,7 @@ void HELPER(wsr_ibreakenable)(CPUXtensaState *env, uint32_t v)
 void HELPER(wsr_ibreaka)(CPUXtensaState *env, uint32_t i, uint32_t v)
 {
 if (env->sregs[IBREAKENABLE] & (1 << i) && env->sregs[IBREAKA + i] != v) {
-tb_invalidate_virtual_addr(env, env->sregs[IBREAKA + i]);
-tb_invalidate_virtual_addr(env, v);
+tb_flush(env_cpu(env));
 }
 env->sregs[IBREAKA + i] = v;
 }
-- 
2.20.1

[PATCH 0/2] flush CPU TB cache in breakpoint_invalidate

[Max Filippov]

Hello,

this series changes breakpoint_invalidate to unconditionally do
tb_flush and then changes remaining users of tb_invalidate_phys_addr
to do the same and removes tb_invalidate_phys_addr.

Changes RFC->v1:
- do tb_flush in breakpoint_invalidate unconditionally
- add tb_invalidate_phys_addr cleanup.

Max Filippov (2):
  exec: flush CPU TB cache in breakpoint_invalidate
  exec: drop tb_invalidate_phys_addr

 exec.c | 44 --
 include/exec/exec-all.h|  3 ---
 target/xtensa/dbg_helper.c | 19 +++-
 3 files changed, 12 insertions(+), 54 deletions(-)

-- 
2.20.1

Re: [PATCH-for-4.2] hw/mips: Deprecate the r4k machine

[Aleksandar Markovic]

On Wed, Nov 27, 2019 at 10:17 PM Philippe Mathieu-Daudé
 wrote:
>
> Hi Aleksandar,
>
> On 11/27/19 7:47 PM, Aleksandar Markovic wrote:
> > On Mon, Nov 25, 2019 at 11:41 AM Philippe Mathieu-Daudé
> >  wrote:
> >>
> >> The r4k machine was introduced in 2005 (6af0bf9c7) and its last
> >> logical change was in 2005 (9542611a6). After we can count 164
> >> maintenance commits (QEMU API changes) with the exception of
> >> 1 fix in 2015 (memory leak, commit 3ad9fd5a).
> >>
> >> This machine was introduced as a proof of concept to run a MIPS
> >> CPU. 2 years later, the Malta machine was add (commit 5856de80)
> >> modeling a real platform.
> >>
>
> Since you queued this patch, do you mind adding Aurelien comment to the
> patch description, as it appears important information:
>
> '''
> The Linux kernel support for this machine has been dropped more
> than 10 years ago in this commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=302922e5f6901eb6f29c58539631f71b3d9746b8
> '''
>
> I was not sure when sending the patch, but as an improvement, we can
> also remove Aurelien and Aleksandar Rikalo from the MAINTAINERS section.
>
> And I assume we can also add (which was explicit in your previous patch):
> Acked-by: Aurelien Jarno 
>
> If you want I can resend this patch with all that amended.
>

No need to resend, I'll fix the things while applying.

> >> Note also this machine has no specification except 5 lines in
> >> the header of this file:
> >>
> >>   * emulates a simple machine with ISA-like bus.
> >>   * ISA IO space mapped to the 0x1400 (PHYS) and
> >>   * ISA memory at the 0x1000 (PHYS, 16Mb in size).
> >>   * All peripherial devices are attached to this "bus" with
> >>   * the standard PC ISA addresses.
> >>
> >> It is time to deprecate this obsolete machine. Users are
> >> recommended to use the Malta board, which hardware is well
> >> documented.
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >> ---
> >>   qemu-deprecated.texi | 5 +
> >>   hw/mips/mips_r4k.c   | 1 +
> >>   MAINTAINERS  | 2 +-
> >>   3 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >
> > Applied to MIPS queue.
> >
> >> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> >> index 4b4b7425ac..05265b43c8 100644
> >> --- a/qemu-deprecated.texi
> >> +++ b/qemu-deprecated.texi
> >> @@ -266,6 +266,11 @@ The 'scsi-disk' device is deprecated. Users should 
> >> use 'scsi-hd' or
> >>
> >>   @section System emulator machines
> >>
> >> +@subsection mips r4k platform (since 4.2)
> >> +
> >> +This machine type is very old and unmaintained. Users should use the 
> >> 'malta'
> >> +machine type instead.
> >> +
> >>   @subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0)
> >>
> >>   These machine types are very old and likely can not be used for live 
> >> migration
> >> diff --git a/hw/mips/mips_r4k.c b/hw/mips/mips_r4k.c
> >> index 70024235ae..0b79ad26cb 100644
> >> --- a/hw/mips/mips_r4k.c
> >> +++ b/hw/mips/mips_r4k.c
> >> @@ -294,6 +294,7 @@ void mips_r4k_init(MachineState *machine)
> >>
> >>   static void mips_machine_init(MachineClass *mc)
> >>   {
> >> +mc->deprecation_reason = "use malta machine type instead";
> >>   mc->desc = "mips r4k platform";
> >>   mc->init = mips_r4k_init;
> >>   mc->block_default_type = IF_IDE;
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 5e5e3e52d6..3b3a88e264 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -972,7 +972,7 @@ F: hw/net/mipsnet.c
> >>   R4000
> >>   M: Aurelien Jarno 
> >>   R: Aleksandar Rikalo 
> >> -S: Maintained
> >> +S: Obsolete
> >>   F: hw/mips/mips_r4k.c
> >>
> >>   Fulong 2E
> >> --
> >> 2.21.0
> >>
> >>
> >
>

Re: [PATCH-for-4.2] hw/mips: Deprecate the r4k machine

[Aleksandar Markovic]

On Wed, Nov 27, 2019 at 10:17 PM Philippe Mathieu-Daudé
 wrote:
>
> Hi Aleksandar,
>
> On 11/27/19 7:47 PM, Aleksandar Markovic wrote:
> > On Mon, Nov 25, 2019 at 11:41 AM Philippe Mathieu-Daudé
> >  wrote:
> >>
> >> The r4k machine was introduced in 2005 (6af0bf9c7) and its last
> >> logical change was in 2005 (9542611a6). After we can count 164
> >> maintenance commits (QEMU API changes) with the exception of
> >> 1 fix in 2015 (memory leak, commit 3ad9fd5a).
> >>
> >> This machine was introduced as a proof of concept to run a MIPS
> >> CPU. 2 years later, the Malta machine was add (commit 5856de80)
> >> modeling a real platform.
> >>
>
> Since you queued this patch, do you mind adding Aurelien comment to the
> patch description, as it appears important information:
>
> '''
> The Linux kernel support for this machine has been dropped more
> than 10 years ago in this commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=302922e5f6901eb6f29c58539631f71b3d9746b8
> '''
>

Sure.

> I was not sure when sending the patch, but as an improvement, we can
> also remove Aurelien and Aleksandar Rikalo from the MAINTAINERS section.
>

I would leave that section intact please. They are currently formally
in charge of this machine, and if they have been so by now for so long
time, let them be the same even during deprecation period.

I would of course remove the patch related to R4000 maintainership fro
my separate series covering chang in the maintainership, since it
really loses any sense.

> And I assume we can also add (which was explicit in your previous patch):
> Acked-by: Aurelien Jarno 
>

OK.

> If you want I can resend this patch with all that amended.
>
> >> Note also this machine has no specification except 5 lines in
> >> the header of this file:
> >>
> >>   * emulates a simple machine with ISA-like bus.
> >>   * ISA IO space mapped to the 0x1400 (PHYS) and
> >>   * ISA memory at the 0x1000 (PHYS, 16Mb in size).
> >>   * All peripherial devices are attached to this "bus" with
> >>   * the standard PC ISA addresses.
> >>
> >> It is time to deprecate this obsolete machine. Users are
> >> recommended to use the Malta board, which hardware is well
> >> documented.
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >> ---
> >>   qemu-deprecated.texi | 5 +
> >>   hw/mips/mips_r4k.c   | 1 +
> >>   MAINTAINERS  | 2 +-
> >>   3 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >
> > Applied to MIPS queue.
> >
> >> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> >> index 4b4b7425ac..05265b43c8 100644
> >> --- a/qemu-deprecated.texi
> >> +++ b/qemu-deprecated.texi
> >> @@ -266,6 +266,11 @@ The 'scsi-disk' device is deprecated. Users should 
> >> use 'scsi-hd' or
> >>
> >>   @section System emulator machines
> >>
> >> +@subsection mips r4k platform (since 4.2)
> >> +
> >> +This machine type is very old and unmaintained. Users should use the 
> >> 'malta'
> >> +machine type instead.
> >> +
> >>   @subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0)
> >>
> >>   These machine types are very old and likely can not be used for live 
> >> migration
> >> diff --git a/hw/mips/mips_r4k.c b/hw/mips/mips_r4k.c
> >> index 70024235ae..0b79ad26cb 100644
> >> --- a/hw/mips/mips_r4k.c
> >> +++ b/hw/mips/mips_r4k.c
> >> @@ -294,6 +294,7 @@ void mips_r4k_init(MachineState *machine)
> >>
> >>   static void mips_machine_init(MachineClass *mc)
> >>   {
> >> +mc->deprecation_reason = "use malta machine type instead";
> >>   mc->desc = "mips r4k platform";
> >>   mc->init = mips_r4k_init;
> >>   mc->block_default_type = IF_IDE;
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 5e5e3e52d6..3b3a88e264 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -972,7 +972,7 @@ F: hw/net/mipsnet.c
> >>   R4000
> >>   M: Aurelien Jarno 
> >>   R: Aleksandar Rikalo 
> >> -S: Maintained
> >> +S: Obsolete
> >>   F: hw/mips/mips_r4k.c
> >>
> >>   Fulong 2E
> >> --
> >> 2.21.0
> >>
> >>
> >
>

Re: [PATCH 1/4] block/quorum.c: stable children names

[Lukas Straub]

On Tue, 26 Nov 2019 15:21:37 +0100
Alberto Garcia  wrote:

> On Thu 21 Nov 2019 07:34:45 PM CET, Lukas Straub wrote:
> >> > diff --git a/block/quorum.c b/block/quorum.c
> >> > index df68adcfaa..6100d4108a 100644
> >> > --- a/block/quorum.c
> >> > +++ b/block/quorum.c
> >> > @@ -1054,6 +1054,12 @@ static void quorum_del_child(BlockDriverState 
> >> > *bs, BdrvChild *child,
> >> >   /* We know now that num_children > threshold, so blkverify must be 
> >> > false */
> >> >   assert(!s->is_blkverify);
> >> >
> >> > +unsigned child_id;
> >> > +sscanf(child->name, "children.%u", &child_id);
> >>
> >> sscanf() cannot detect overflow. Do we trust our input enough to
> >> ignore this shortfall in the interface, or should we be using saner
> >> interfaces like qemu_strtoul()?  For that matter, why do we have to
> >> reparse something; is it not already available somewhere in numerical
> >> form?
> >
> > Yes, I wondered about that too, but found no other way. But the input
> > is trusted, AFAIK the only way to add child nodes is trough
> > quorum_add_child above and quorum_open and there already are adequate
> > checks there.
>
> I also don't see any other way to get that value, unless we change
> BDRVQuorumState to store that information (e.g. instead of children
> being a list of pointers BdrvChild ** it could be a list of {pointer,
> index}, or something like that).
>
> There's another (more convoluted) alternative if we don't want to parse
> child->name. Since we only want to know if the child number equals
> s->next_child_index - 1, we can do it the other way around:
>
>snprintf(str, 32, "children.%u", s->next_child_index - 1);
>
> and then compare str and child->name.
>
> Berto

Hi,
I will do it your way, then it's also more consistent with the name
creation in quorum_add and quorum_open.

Regards,
Lukas Straub

Re: [PATCH] travis.yml: Run tcg tests with tci

[Philippe Mathieu-Daudé]

On 11/27/19 7:38 PM, Alex Bennée wrote:

Thomas Huth  writes:


So far we only have compile coverage for tci. But since commit
2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation
for INDEX_op_ld16u_i64") has been included, we can also run the
x86 TCG tests with tci, so let's enable them in Travis now.

Signed-off-by: Thomas Huth 
---
  .travis.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index c09b6a0014..b0b634d484 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -218,7 +218,7 @@ matrix:
  # We manually include builds which we disable "make check" for


this comment is out of date now (or rather has been for a while)


  - env:
  - CONFIG="--enable-debug --enable-tcg-interpreter"


Perhaps as linux-user doesn't add much to testing the TCG we could limit
by MAIN_SOFTMMU_TARGETS here?


Good idea.


-- TEST_CMD=""
+- TEST_CMD="make run-tcg-tests-x86_64-softmmu V=1"


How about "make check-qtest check-tcg"

Which will exercise the moderate boot code tests of various
architectures as well as x86_64 (if we include the --disable-docker
configure stanza)


Another good idea!

  
  
  # We don't need to exercise every backend with every front-end

Re: [PATCH 0/4] colo: Introduce resource agent and high-level test

[Lukas Straub]

On Fri, 22 Nov 2019 09:46:46 +
"Dr. David Alan Gilbert"  wrote:

> * Lukas Straub (lukasstra...@web.de) wrote:
> > Hello Everyone,
> > These patches introduce a resource agent for use with the Pacemaker CRM and 
> > a
> > high-level test utilizing it for testing qemu COLO.
> >
> > The resource agent manages qemu COLO including continuous replication.
> >
> > Currently the second test case (where the peer qemu is frozen) fails on 
> > primary
> > failover, because qemu hangs while removing the replication related block 
> > nodes.
> > Note that this also happens in real world test when cutting power to the 
> > peer
> > host, so this needs to be fixed.
>
> Do you understand why that happens? Is this it's trying to finish a
> read/write to the dead partner?
>
> Dave

I haven't looked into it too closely yet, but it's often hanging in bdrv_flush()
while removing the replication blockdev and of course thats probably because the
nbd client waits for a reply. So I tried with the workaround below, which will
actively kill the TCP connection and with it the test passes, though I haven't
tested it in real world yet.

A proper solution to this would probably be a "force" parameter for 
blockdev-del,
which skips all flushing and aborts all inflight io. Or we could add a timeout
to the nbd client.

Regards,
Lukas Straub

diff --git a/scripts/colo-resource-agent/colo b/scripts/colo-resource-agent/colo
index 5fd9cfc0b5..62210af2a1 100755
--- a/scripts/colo-resource-agent/colo
+++ b/scripts/colo-resource-agent/colo
@@ -935,6 +935,7 @@ def qemu_colo_notify():
and HOSTNAME == str.strip(OCF_RESKEY_CRM_meta_notify_master_uname):
 fd = qmp_open()
 peer = qmp_get_nbd_remote(fd)
+os.system("sudo ss -K dst %s dport = %s" % (peer, NBD_PORT))
 if peer == str.strip(OCF_RESKEY_CRM_meta_notify_stop_uname):
 if qmp_check_resync(fd) != None:
 qmp_cancel_resync(fd)

Re: [PATCH-for-4.2] hw/mips: Deprecate the r4k machine

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 11/27/19 7:47 PM, Aleksandar Markovic wrote:

On Mon, Nov 25, 2019 at 11:41 AM Philippe Mathieu-Daudé
 wrote:


The r4k machine was introduced in 2005 (6af0bf9c7) and its last
logical change was in 2005 (9542611a6). After we can count 164
maintenance commits (QEMU API changes) with the exception of
1 fix in 2015 (memory leak, commit 3ad9fd5a).

This machine was introduced as a proof of concept to run a MIPS
CPU. 2 years later, the Malta machine was add (commit 5856de80)
modeling a real platform.



Since you queued this patch, do you mind adding Aurelien comment to the 
patch description, as it appears important information:


'''
The Linux kernel support for this machine has been dropped more
than 10 years ago in this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=302922e5f6901eb6f29c58539631f71b3d9746b8
'''

I was not sure when sending the patch, but as an improvement, we can 
also remove Aurelien and Aleksandar Rikalo from the MAINTAINERS section.


And I assume we can also add (which was explicit in your previous patch):
Acked-by: Aurelien Jarno 

If you want I can resend this patch with all that amended.


Note also this machine has no specification except 5 lines in
the header of this file:

  * emulates a simple machine with ISA-like bus.
  * ISA IO space mapped to the 0x1400 (PHYS) and
  * ISA memory at the 0x1000 (PHYS, 16Mb in size).
  * All peripherial devices are attached to this "bus" with
  * the standard PC ISA addresses.

It is time to deprecate this obsolete machine. Users are
recommended to use the Malta board, which hardware is well
documented.

Signed-off-by: Philippe Mathieu-Daudé 
---
  qemu-deprecated.texi | 5 +
  hw/mips/mips_r4k.c   | 1 +
  MAINTAINERS  | 2 +-
  3 files changed, 7 insertions(+), 1 deletion(-)



Applied to MIPS queue.


diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 4b4b7425ac..05265b43c8 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -266,6 +266,11 @@ The 'scsi-disk' device is deprecated. Users should use 
'scsi-hd' or

  @section System emulator machines

+@subsection mips r4k platform (since 4.2)
+
+This machine type is very old and unmaintained. Users should use the 'malta'
+machine type instead.
+
  @subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0)

  These machine types are very old and likely can not be used for live migration
diff --git a/hw/mips/mips_r4k.c b/hw/mips/mips_r4k.c
index 70024235ae..0b79ad26cb 100644
--- a/hw/mips/mips_r4k.c
+++ b/hw/mips/mips_r4k.c
@@ -294,6 +294,7 @@ void mips_r4k_init(MachineState *machine)

  static void mips_machine_init(MachineClass *mc)
  {
+mc->deprecation_reason = "use malta machine type instead";
  mc->desc = "mips r4k platform";
  mc->init = mips_r4k_init;
  mc->block_default_type = IF_IDE;
diff --git a/MAINTAINERS b/MAINTAINERS
index 5e5e3e52d6..3b3a88e264 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -972,7 +972,7 @@ F: hw/net/mipsnet.c
  R4000
  M: Aurelien Jarno 
  R: Aleksandar Rikalo 
-S: Maintained
+S: Obsolete
  F: hw/mips/mips_r4k.c

  Fulong 2E
--
2.21.0

Re: [libvirt] [PATCH-for-4.2] hw/mips: Deprecate the r4k machine

[Philippe Mathieu-Daudé]

On 11/27/19 8:40 PM, Aleksandar Markovic wrote:

On Mon, Nov 25, 2019 at 4:40 PM Daniel P. Berrangé  wrote:


On Mon, Nov 25, 2019 at 03:45:35PM +0100, Aleksandar Markovic wrote:

On Monday, November 25, 2019, Philippe Mathieu-Daudé 
wrote:


The r4k machine was introduced in 2005 (6af0bf9c7) and its last
logical change was in 2005 (9542611a6). After we can count 164
maintenance commits (QEMU API changes) with the exception of
1 fix in 2015 (memory leak, commit 3ad9fd5a).



Please don't start any deprecation process. This requires certain
consultation within my company. Rest assured that everyone's opinion will
be taken into account while doing consiltation.


The idea of having a deprecation process is precisely to
allow time for people like to provide feedback before any
deletion takes place. So this is not a reason to delay
starting of deprecation.



What you said is fine, Daniel, I understand the idea, and it should be
that way. But I didn't ask for some lengthy negotiation, or waiting
for someone for months, but I just wanted to check within company if
all relevant people (that do not read QEMU devel list very often)
agree - since we, naturally, do various in-house setups with QEMU for
MIPS, that's all. This could count as the discussion on the patch, not
as a part of that loong "deprecated" state...


Thank you Aleksandar for clearing that with MIPS so quickly!


The process lasts for 2 releases before we delete anything:

   https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features

When we start the clock now, it is deprecated when 5.0 releases
in April 2020, and still deprecated with 5.1 in August 2020.

The code won't be deleted until Sep 2020 when 5.2 dev cycle opens,
and there's still time to undelete it right up until the 5.2 feature
freeze in late Oct 2020. That's 11 months away, which is plenty of
time for feedback IMHO.

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

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  wrote:
>
> This series of patches adds 8bit AVR cores to QEMU.
> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully tested 
> yet.
> However I was able to execute simple code with functions. e.g fibonacci 
> calculation.
> This series of patches include a non real, sample board.
> No fuses support yet. PC is set to 0 at reset.
>

I have a couple of general remarks, so I am responding to the cover
letter, not individual patches.

1) The licenses for Sarah devices differ than the rest - shouldn't all
licenses be harmonized?

2) There is an architectural problem with peripherals. It is possible
that they evolve over time, so, for example, USART could not be the
same for older and newer CPUs (in principle, newer peripheral is
expected to be o sort of "superset" of the older). How do you solve
that problem? Right now, it may not looks serious to you, but if you
don;t think about that right now, from the outset, soon the code will
become so entangled, ti woudl be almost very difficult to fix it.
Please think about that, how would you solve it, is there a way to
pass the information on the currently emulated CPU to the code
covering a peripheral, and provide a different behaviour?

> Following are examples of possible usages, assuming program.elf is compiled 
> for AVR cpu
> 1.  Continious non interrupted execution
> run `qemu-system-avr -kernel program.elf`
> 2.  Continious non interrupted execution with serial output into telnet window
> run `qemu-system-avr -kernel program.elf -serial tcp::5678,server,nowait 
> -nographic `
> run `telent localhost 5678`
> 3.  Continious non interrupted execution with serial output into stdout
> run `qemu-system-avr -kernel program.elf -serial stdio`
> 4.  Debugging wit GDB debugger
> run `qemu-system-avr -kernel program.elf -s -S`
> run `avr-gdb program.elf` and then within GDB shell `target remote :1234`
> 5.  Print out executed instructions
> run `qemu-system-avr -kernel program.elf -d in_asm`
>

Thank you so much for these examples!

Aleksandar


>
> the patches include the following
> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> 2. CPU features which allow define the following 8bit AVR cores
>  avr1
>  avr2 avr25
>  avr3 avr31 avr35
>  avr4
>  avr5 avr51
>  avr6
>  xmega2 xmega4 xmega5 xmega6 xmega7
> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
> execute simple code
> 4. encoding for all AVR instructions
> 5. interrupt handling
> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> 7. a decoder which given an opcode decides what istruction it is
> 8. translation of AVR instruction into TCG
> 9. all features together
>
> changes since v3
> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) 
> for faster address manipulaton
> 2. ffs changed to ctz32
> 3. duplicate code removed at avr_cpu_do_interrupt
> 4. using andc instead of not + and
> 5. fixing V flag calculation in varios instructions
> 6. freeing local variables in PUSH
> 7. tcg_const_local_i32 -> tcg_const_i32
> 8. using sextract32 instead of my implementation
> 9. fixing BLD instruction
> 10.xor(r) instead of 0xff - r at COM
> 11.fixing MULS/MULSU not to modify inputs' content
> 12.using SUB for NEG
> 13.fixing tcg_gen_qemu_ld/st call in XCH
>
> changes since v4
> 1. target is now defined as big endian in order to optimize push_ret/pop_ret
> 2. all style warnings are fixed
> 3. adding cpu_set/get_sreg functions
> 4. simplifying gen_goto_tb as there is no real paging
> 5. env->pc -> env->pc_w
> 6. making flag dump more compact
> 7. more spacing
> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> 9. removing avr_set_feature
> 10. SPL/SPH set bug fix
> 11. switching stb_phys to cpu_stb_data
> 12. cleaning up avr_decode
> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> 14. saving CPU features (savevm)
>
> changes since v5
> 1. BLD bug fix
> 2. decoder generator is added
>
> chages since v6
> 1. using cpu_get_sreg/cpu_set_sreg in 
> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
> 2. configure the target as little endian because otherwise GDB does not work
> 3. fixing and testing gen_push_ret/gen_pop_ret
>
> changes since v7
> 1. folding back v6
> 2. logging at helper_outb and helper_inb are done for non supported yet 
> registers only
> 3. MAINTAINERS updated
>
> changes since v8
> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
> 2. making linux compilable
> 3. testing on
> a. Mac, Apple LLVM version 7.0.0
> b. Ubuntu 12.04, gcc 4.9.2
> c. Fedora 23, gcc 5.3.1
> 4. folding back some patches
> 5. translation bug fixes for ORI, CPI, XOR instructions
> 6. propper handling of cpu register writes though memory
>
> changes since v9
> 1. removing forward declarations of static functions
> 2. disabling debug prints
> 3. switching to case range instead of 

Re: [RFC net-next 15/18] virtio_net: implement XDP prog offload functionality

[Michael S. Tsirkin]

On Tue, Nov 26, 2019 at 07:07:41PM +0900, Prashant Bhole wrote:
> From: Jason Wang 
> 
> This patch implements bpf_prog_offload_ops callbacks and adds handling
> for XDP_SETUP_PROG_HW. Handling of XDP_SETUP_PROG_HW involves setting
> up struct virtio_net_ctrl_ebpf_prog and appending program instructions
> to it. This control buffer is sent to Qemu with class
> VIRTIO_NET_CTRL_EBPF and command VIRTIO_NET_BPF_CMD_SET_OFFLOAD.
> The expected behavior from Qemu is that it should try to load the
> program in host os and report the status.

That's not great e.g. for migration: different hosts might have
a different idea about what's allowed.
Device capabilities should be preferably exported through
feature bits or config space such that it's easy to
intercept and limit these as needed.

Also, how are we going to handle e.g. endian-ness here?

> 
> It also adds restriction to have either driver or offloaded program
> at a time.

I'm not sure I understand what does the above say.
virtnet_xdp_offload_check?
Please add code comments so we remember what to do and when.

> This restriction can be removed later after proper testing.

What kind of testing is missing here?

> Signed-off-by: Jason Wang 
> Co-developed-by: Prashant Bhole 
> Signed-off-by: Prashant Bhole 

Any UAPI changes need to be copied to virtio-...@lists.oasis-open.org
(subscriber only) list please.

> ---
>  drivers/net/virtio_net.c| 114 +++-
>  include/uapi/linux/virtio_net.h |  27 
>  2 files changed, 139 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index a1088d0114f2..dddfbb2a2075 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -169,6 +169,7 @@ struct control_buf {
>   u8 allmulti;
>   __virtio16 vid;
>   __virtio64 offloads;
> + struct virtio_net_ctrl_ebpf_prog prog_ctrl;
>  };
>  
>  struct virtnet_info {
> @@ -272,6 +273,8 @@ struct virtnet_bpf_bound_prog {
>   struct bpf_insn insnsi[0];
>  };
>  
> +#define VIRTNET_EA(extack, msg)  NL_SET_ERR_MSG_MOD((extack), msg)
> +
>  /* Converting between virtqueue no. and kernel tx/rx queue no.
>   * 0:rx0 1:tx0 2:rx1 3:tx1 ... 2N:rxN 2N+1:txN 2N+2:cvq
>   */
> @@ -2427,6 +2430,11 @@ static int virtnet_xdp_set(struct net_device *dev, 
> struct netdev_bpf *bpf)
>   if (!xdp_attachment_flags_ok(&vi->xdp, bpf))
>   return -EBUSY;
>  
> + if (rtnl_dereference(vi->offload_xdp_prog)) {
> + VIRTNET_EA(bpf->extack, "program already attached in offload 
> mode");
> + return -EINVAL;
> + }
> +
>   if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)
>   && (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
>   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6) ||
> @@ -2528,17 +2536,114 @@ static int virtnet_bpf_verify_insn(struct 
> bpf_verifier_env *env, int insn_idx,
>  
>  static void virtnet_bpf_destroy_prog(struct bpf_prog *prog)
>  {
> + struct virtnet_bpf_bound_prog *state;
> +
> + state = prog->aux->offload->dev_priv;
> + list_del(&state->list);
> + kfree(state);
> +}
> +
> +static int virtnet_xdp_offload_check(struct virtnet_info *vi,
> +  struct netdev_bpf *bpf)
> +{
> + if (!bpf->prog)
> + return 0;
> +
> + if (!bpf->prog->aux->offload) {
> + VIRTNET_EA(bpf->extack, "xdpoffload of non-bound program");
> + return -EINVAL;
> + }
> + if (bpf->prog->aux->offload->netdev != vi->dev) {
> + VIRTNET_EA(bpf->extack, "program bound to different dev");
> + return -EINVAL;
> + }
> +
> + if (rtnl_dereference(vi->xdp_prog)) {
> + VIRTNET_EA(bpf->extack, "program already attached in driver 
> mode");
> + return -EINVAL;
> + }
> +
> + return 0;
>  }
>  
>  static int virtnet_xdp_set_offload(struct virtnet_info *vi,
>  struct netdev_bpf *bpf)
>  {
> - return -EBUSY;
> + struct virtio_net_ctrl_ebpf_prog *ctrl;
> + struct virtnet_bpf_bound_prog *bound_prog = NULL;
> + struct virtio_device *vdev = vi->vdev;
> + struct bpf_prog *prog = bpf->prog;
> + void *ctrl_buf = NULL;
> + struct scatterlist sg;
> + int prog_len;
> + int err = 0;
> +
> + if (!xdp_attachment_flags_ok(&vi->xdp_hw, bpf))
> + return -EBUSY;
> +
> + if (prog) {
> + if (prog->type != BPF_PROG_TYPE_XDP)
> + return -EOPNOTSUPP;
> + bound_prog = prog->aux->offload->dev_priv;
> + prog_len = prog->len * sizeof(bound_prog->insnsi[0]);
> +
> + ctrl_buf = kmalloc(GFP_KERNEL, sizeof(*ctrl) + prog_len);
> + if (!ctrl_buf)
> + return -ENOMEM;
> + ctrl = ctrl_buf;
> + ctrl->cmd = cpu_to_virtio32(vi->vdev,
> + VIRTI

Re: [RFC net-next 00/18] virtio_net XDP offload

[Michael S. Tsirkin]

On Tue, Nov 26, 2019 at 12:35:14PM -0800, Jakub Kicinski wrote:
> On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:
> > Note: This RFC has been sent to netdev as well as qemu-devel lists
> > 
> > This series introduces XDP offloading from virtio_net. It is based on
> > the following work by Jason Wang:
> > https://netdevconf.info/0x13/session.html?xdp-offload-with-virtio-net
> > 
> > Current XDP performance in virtio-net is far from what we can achieve
> > on host. Several major factors cause the difference:
> > - Cost of virtualization
> > - Cost of virtio (populating virtqueue and context switching)
> > - Cost of vhost, it needs more optimization
> > - Cost of data copy
> > Because of above reasons there is a need of offloading XDP program to
> > host. This set is an attempt to implement XDP offload from the guest.
> 
> This turns the guest kernel into a uAPI proxy.
> 
> BPF uAPI calls related to the "offloaded" BPF objects are forwarded 
> to the hypervisor, they pop up in QEMU which makes the requested call
> to the hypervisor kernel. Today it's the Linux kernel tomorrow it may 
> be someone's proprietary "SmartNIC" implementation.
> 
> Why can't those calls be forwarded at the higher layer? Why do they
> have to go through the guest kernel?

Well everyone is writing these programs and attaching them to NICs.

For better or worse that's how userspace is written.

Yes, in the simple case where everything is passed through, it could
instead be passed through some other channel just as well, but then
userspace would need significant changes just to make it work with
virtio.



> If kernel performs no significant work (or "adds value", pardon the
> expression), and problem can easily be solved otherwise we shouldn't 
> do the work of maintaining the mechanism.
> 
> The approach of kernel generating actual machine code which is then
> loaded into a sandbox on the hypervisor/SmartNIC is another story.

But that's transparent to guest userspace. Making userspace care whether
it's a SmartNIC or a software device breaks part of virtualization's
appeal, which is that it looks like a hardware box to the guest.

> I'd appreciate if others could chime in.

Re: [PATCH for-5.0 v2 0/3] benchmark util

[Vladimir Sementsov-Ogievskiy]

27.11.2019 22:58, Aleksandar Markovic wrote:
> On Tue, Nov 26, 2019 at 4:49 PM Vladimir Sementsov-Ogievskiy
>  wrote:
>>
>> Hi all!
>>
>> Here is simple benchmarking utility, to generate performance
>> comparison tables, like the following:
>>
>> --  -  -  -
>>  backup-1   backup-2   mirror
>> ssd -> ssd  0.43 +- 0.00   4.48 +- 0.06   4.38 +- 0.02
>> ssd -> hdd  10.60 +- 0.08  10.69 +- 0.18  10.57 +- 0.05
>> ssd -> nbd  33.81 +- 0.37  10.67 +- 0.17  10.07 +- 0.07
>> --  -  -  -
>>
>> This is a v2, as v1 was inside
>>   "[RFC 00/24] backup performance: block_status + async"
>>
>> I'll use this benchmark in other series, hope someone
>> will like it.
>>
> 
> Vladimir,
> 
> I really like this idea, even though I am interested in benchmarks of
> different nature. Certainly a beautiful and handy tool for doing
> detection of performance regressions (and also confirmation of
> performance optimizations).

Hi Aleksandar!

Glad you are interested!

> 
> Did you run the tool on the previous QEMU versions, to detect change
> in numbers between QEMU versions? Do you have the results of the same
> benchmark for QEMU 2.12, 3.0, 4.0,... ?

No, I don't really interested in such comparisons, my goal is to measure
backup performance in context of my backup/block-copy series.

But such statistics may be simply generated, just make several git work-trees
per release you interested in, fill test_envs variable (together with other
variables) in python/bench-example.py (patch 03), and run it.

> 
> What are units used in the table? Seconds, minutes? Hopefully, not hours?

Seconds of course, I'm not so patient :)
Also, if you are interested, 1000M raw images filled with ones used to make
this benchmark table. However, it's in cover-letter only as example.

backup-1 and mirror are upstream. backup-2 is our downstream. nbd gain of
backup-2 is related to async requests. ssd gain for backup-1 is related to
copy offloading (wow, it works!).

> 
> Yours,
> Aleksandar
> 
>> Vladimir Sementsov-Ogievskiy (3):
>>python: add simplebench.py
>>python: add qemu/bench_block_job.py
>>python: add example usage of simplebench
>>
>>   python/bench-example.py|  80 +
>>   python/qemu/bench_block_job.py | 115 +
>>   python/simplebench.py  | 128 +
>>   3 files changed, 323 insertions(+)
>>   create mode 100644 python/bench-example.py
>>   create mode 100755 python/qemu/bench_block_job.py
>>   create mode 100644 python/simplebench.py
>>
>> --
>> 2.18.0
>>
>>


-- 
Best regards,
Vladimir

Re: [PATCH v6] nbd: well form nbd_iter_channel_error errp handler

[Vladimir Sementsov-Ogievskiy]

27.11.2019 22:49, Eric Blake wrote:
> [adding Markus]
> 
> On 11/27/19 1:08 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Make nbd_iter_channel_error errp handler well formed:
>> rename local_err to errp_in, as it is IN-parameter here (which is
>> unusual for Error**).
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> Reviewed-by: Eric Blake 
>> ---
>>
>> v6: fix commit message
>>  add Eric's r-b
> 
> I'm surprised that you aren't including Markus on a lot of these patches - 
> even though you've posted a lot of them as separate threads to make them 
> easier for individual maintainers to pick up, it would also be possible for 
> Markus to pick up a bunch of them at once through his error tree.

Oops, you are right, I'm sorry :(

If it helps, all patches Eric saying about are 21 patches from myself,
with v6 tag, sent during last two hours.

Sorry that I didn't answer to
   https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg03105.html
before sending them, and I don't want do it now, to not move v5 above v6.

Week passed since my proposal at that link, so having one against (Eric)
and two for (Kevin and Greg), I decided to follow my plan now.

> 
> At any rate, I'll queue this one through my NBD tree for 5.0 if it does not 
> make it through Markus' error tree or the trivial tree sooner.
> 
> 

Thanks!

-- 
Best regards,
Vladimir

Re: [PATCH v36 11/17] target/avr: Add limited support for USART and 16 bit timer peripherals

[Aleksandar Markovic]

On Wed, Nov 27, 2019 at 7:43 PM Aleksandar Markovic
 wrote:
>
> > > +/* Offsets of registers. */
> > > +#define USART_DR   0x06
> > > +#define USART_CSRA  0x00
> > > +#define USART_CSRB  0x01
> > > +#define USART_CSRC  0x02
> > > +#define USART_BRRH 0x05
> > > +#define USART_BRRL 0x04
> > > +
> > > +/* Relevant bits in regiters. */
> > > +#define USART_CSRA_RXC(1 << 7)
> > > +#define USART_CSRA_TXC(1 << 6)
> > > +#define USART_CSRA_DRE(1 << 5)
> > > +#define USART_CSRA_MPCM   (1 << 0)
> > > +
> > > +#define USART_CSRB_RXCIE  (1 << 7)
> > > +#define USART_CSRB_TXCIE  (1 << 6)
> > > +#define USART_CSRB_DREIE  (1 << 5)
> > > +#define USART_CSRB_RXEN   (1 << 4)
> > > +#define USART_CSRB_TXEN   (1 << 3)
> > > +#define USART_CSRB_CSZ2   (1 << 2)
> > > +#define USART_CSRB_RXB8   (1 << 1)
> > > +#define USART_CSRB_TXB8   (1 << 0)
> > > +
> > > +#define USART_CSRC_MSEL1  (1 << 7)
> > > +#define USART_CSRC_MSEL0  (1 << 6)
> > > +#define USART_CSRC_PM1(1 << 5)
> > > +#define USART_CSRC_PM0(1 << 4)
> > > +#define USART_CSRC_CSZ1   (1 << 2)
> > > +#define USART_CSRC_CSZ0   (1 << 1)
> >
> > The previous definitions can go into hw/char/avr_usart.c.
> >
>
> Why?

Seriously, Philippe, why move this from their perfect cosy place in the header?

If the answer is "because most of others in QEMU do", I don't know...
I wouldn't consider that a legitimate reason - at least not in this
particular case.

Aleksandar

Re: [PATCH for-5.0 v2 0/3] benchmark util

[Aleksandar Markovic]

On Tue, Nov 26, 2019 at 4:49 PM Vladimir Sementsov-Ogievskiy
 wrote:
>
> Hi all!
>
> Here is simple benchmarking utility, to generate performance
> comparison tables, like the following:
>
> --  -  -  -
> backup-1   backup-2   mirror
> ssd -> ssd  0.43 +- 0.00   4.48 +- 0.06   4.38 +- 0.02
> ssd -> hdd  10.60 +- 0.08  10.69 +- 0.18  10.57 +- 0.05
> ssd -> nbd  33.81 +- 0.37  10.67 +- 0.17  10.07 +- 0.07
> --  -  -  -
>
> This is a v2, as v1 was inside
>  "[RFC 00/24] backup performance: block_status + async"
>
> I'll use this benchmark in other series, hope someone
> will like it.
>

Vladimir,

I really like this idea, even though I am interested in benchmarks of
different nature. Certainly a beautiful and handy tool for doing
detection of performance regressions (and also confirmation of
performance optimizations).

Did you run the tool on the previous QEMU versions, to detect change
in numbers between QEMU versions? Do you have the results of the same
benchmark for QEMU 2.12, 3.0, 4.0,... ?

What are units used in the table? Seconds, minutes? Hopefully, not hours?

Yours,
Aleksandar

> Vladimir Sementsov-Ogievskiy (3):
>   python: add simplebench.py
>   python: add qemu/bench_block_job.py
>   python: add example usage of simplebench
>
>  python/bench-example.py|  80 +
>  python/qemu/bench_block_job.py | 115 +
>  python/simplebench.py  | 128 +
>  3 files changed, 323 insertions(+)
>  create mode 100644 python/bench-example.py
>  create mode 100755 python/qemu/bench_block_job.py
>  create mode 100644 python/simplebench.py
>
> --
> 2.18.0
>
>

[PATCH v6] hw/vfio/ap: drop local_err from vfio_ap_realize

[Vladimir Sementsov-Ogievskiy]

No reason for local_err here, use errp directly instead.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

v6: keep return code checking [Cornelia]

 hw/vfio/ap.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
index da6a20669d..8fbaa724c2 100644
--- a/hw/vfio/ap.c
+++ b/hw/vfio/ap.c
@@ -89,14 +89,13 @@ static void vfio_ap_realize(DeviceState *dev, Error **errp)
 {
 int ret;
 char *mdevid;
-Error *local_err = NULL;
 VFIOGroup *vfio_group;
 APDevice *apdev = AP_DEVICE(dev);
 VFIOAPDevice *vapdev = VFIO_AP_DEVICE(apdev);
 
-vfio_group = vfio_ap_get_group(vapdev, &local_err);
+vfio_group = vfio_ap_get_group(vapdev, errp);
 if (!vfio_group) {
-goto out_err;
+return;
 }
 
 vapdev->vdev.ops = &vfio_ap_ops;
@@ -113,7 +112,7 @@ static void vfio_ap_realize(DeviceState *dev, Error **errp)
  */
 vapdev->vdev.balloon_allowed = true;
 
-ret = vfio_get_device(vfio_group, mdevid, &vapdev->vdev, &local_err);
+ret = vfio_get_device(vfio_group, mdevid, &vapdev->vdev, errp);
 if (ret) {
 goto out_get_dev_err;
 }
@@ -123,8 +122,6 @@ static void vfio_ap_realize(DeviceState *dev, Error **errp)
 out_get_dev_err:
 vfio_ap_put_device(vapdev);
 vfio_put_group(vfio_group);
-out_err:
-error_propagate(errp, local_err);
 }
 
 static void vfio_ap_unrealize(DeviceState *dev, Error **errp)
-- 
2.21.0

Re: [PATCH v6] nbd: well form nbd_iter_channel_error errp handler

[Eric Blake]

[adding Markus]

On 11/27/19 1:08 PM, Vladimir Sementsov-Ogievskiy wrote:

Make nbd_iter_channel_error errp handler well formed:
rename local_err to errp_in, as it is IN-parameter here (which is
unusual for Error**).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
---

v6: fix commit message
 add Eric's r-b


I'm surprised that you aren't including Markus on a lot of these patches 
- even though you've posted a lot of them as separate threads to make 
them easier for individual maintainers to pick up, it would also be 
possible for Markus to pick up a bunch of them at once through his error 
tree.


At any rate, I'll queue this one through my NBD tree for 5.0 if it does 
not make it through Markus' error tree or the trivial tree sooner.



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

Re: [RFC net-next 00/18] virtio_net XDP offload

[Jakub Kicinski]

On Wed, 27 Nov 2019 10:59:37 +0800, Jason Wang wrote:
> On 2019/11/27 上午4:35, Jakub Kicinski wrote:
> > On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:  
> >> Note: This RFC has been sent to netdev as well as qemu-devel lists
> >>
> >> This series introduces XDP offloading from virtio_net. It is based on
> >> the following work by Jason Wang:
> >> https://netdevconf.info/0x13/session.html?xdp-offload-with-virtio-net
> >>
> >> Current XDP performance in virtio-net is far from what we can achieve
> >> on host. Several major factors cause the difference:
> >> - Cost of virtualization
> >> - Cost of virtio (populating virtqueue and context switching)
> >> - Cost of vhost, it needs more optimization
> >> - Cost of data copy
> >> Because of above reasons there is a need of offloading XDP program to
> >> host. This set is an attempt to implement XDP offload from the guest.  
> > This turns the guest kernel into a uAPI proxy.
> >
> > BPF uAPI calls related to the "offloaded" BPF objects are forwarded
> > to the hypervisor, they pop up in QEMU which makes the requested call
> > to the hypervisor kernel. Today it's the Linux kernel tomorrow it may
> > be someone's proprietary "SmartNIC" implementation.
> >
> > Why can't those calls be forwarded at the higher layer? Why do they
> > have to go through the guest kernel?  
> 
> 
> I think doing forwarding at higher layer have the following issues:
> 
> - Need a dedicated library (probably libbpf) but application may choose 
>   to do eBPF syscall directly
> - Depends on guest agent to work

This can be said about any user space functionality.

> - Can't work for virtio-net hardware, since it still requires a hardware 
> interface for carrying  offloading information

The HW virtio-net presumably still has a PF and hopefully reprs for
VFs, so why can't it attach the program there?

> - Implement at the level of kernel may help for future extension like 
>   BPF object pinning and eBPF helper etc.

No idea what you mean by this.

> Basically, this series is trying to have an implementation of 
> transporting eBPF through virtio, so it's not necessarily a guest to 
> host but driver and device. For device, it could be either a virtual one 
> (as done in qemu) or a real hardware.

SmartNIC with a multi-core 64bit ARM CPUs is as much of a host as 
is the x86 hypervisor side. This set turns the kernel into a uAPI
forwarder.

3 years ago my answer to this proposal would have been very different.
Today after all the CPU bugs it seems like the SmartNICs (which are 
just another CPU running proprietary code) may just take off..

> > If kernel performs no significant work (or "adds value", pardon the
> > expression), and problem can easily be solved otherwise we shouldn't
> > do the work of maintaining the mechanism.  
> 
> My understanding is that it should not be much difference compared to 
> other offloading technology.

I presume you mean TC offloads? In virtualization there is inherently a
hypervisor which will receive the request, be it an IO hub/SmartNIC or
the traditional hypervisor on the same CPU.

The ACL/routing offloads differ significantly, because it's either the 
driver that does all the HW register poking directly or the complexity
of programming a rule into a HW table is quite low.

Same is true for the NFP BPF offload, BTW, the driver does all the
heavy lifting and compiles the final machine code image.

You can't say verifying and JITing BPF code into machine code entirely
in the hypervisor is similarly simple.

So no, there is a huge difference.

> > The approach of kernel generating actual machine code which is then
> > loaded into a sandbox on the hypervisor/SmartNIC is another story.  
> 
> We've considered such way, but actual machine code is not as portable as 
> eBPF bytecode consider we may want:
> 
> - Support migration
> - Further offload the program to smart NIC (e.g through macvtap 
>   passthrough mode etc).

You can re-JIT or JIT for SmartNIC..? Having the BPF bytecode does not
guarantee migration either, if the environment is expected to be
running different version of HW and SW. But yes, JITing in the guest
kernel when you don't know what to JIT for may be hard, I was just
saying that I don't mean to discourage people from implementing
sandboxes which run JITed code on SmartNICs. My criticism is (as
always?) against turning the kernel into a one-to-one uAPI forwarder
into unknown platform code.

For cloud use cases I believe the higher layer should solve this.

[PATCH v6] backends/cryptodev: drop local_err from cryptodev_backend_complete()

[Vladimir Sementsov-Ogievskiy]

No reason for local_err here, use errp directly instead.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Marc-André Lureau 
---

v6: add r-b by Philippe and Marc-André

 backends/cryptodev.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/backends/cryptodev.c b/backends/cryptodev.c
index 3c071eab95..5a9735684e 100644
--- a/backends/cryptodev.c
+++ b/backends/cryptodev.c
@@ -176,19 +176,10 @@ cryptodev_backend_complete(UserCreatable *uc, Error 
**errp)
 {
 CryptoDevBackend *backend = CRYPTODEV_BACKEND(uc);
 CryptoDevBackendClass *bc = CRYPTODEV_BACKEND_GET_CLASS(uc);
-Error *local_err = NULL;
 
 if (bc->init) {
-bc->init(backend, &local_err);
-if (local_err) {
-goto out;
-}
+bc->init(backend, errp);
 }
-
-return;
-
-out:
-error_propagate(errp, local_err);
 }
 
 void cryptodev_backend_set_used(CryptoDevBackend *backend, bool used)
-- 
2.21.0

[PATCH v6] include/qom/object.h: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Philippe Mathieu-Daudé 
---

v6: add r-b by Philippe

 include/qom/object.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index 128d00c77f..716f6f655d 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1635,9 +1635,9 @@ void object_class_property_add_uint32_ptr(ObjectClass 
*klass, const char *name,
  * property of type 'uint64'.
  */
 void object_property_add_uint64_ptr(Object *obj, const char *name,
-const uint64_t *v, Error **Errp);
+const uint64_t *v, Error **errp);
 void object_class_property_add_uint64_ptr(ObjectClass *klass, const char *name,
-  const uint64_t *v, Error **Errp);
+  const uint64_t *v, Error **errp);
 
 /**
  * object_property_add_alias:
-- 
2.21.0

Re: [libvirt] [PATCH-for-4.2] hw/mips: Deprecate the r4k machine

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 4:40 PM Daniel P. Berrangé  wrote:
>
> On Mon, Nov 25, 2019 at 03:45:35PM +0100, Aleksandar Markovic wrote:
> > On Monday, November 25, 2019, Philippe Mathieu-Daudé 
> > wrote:
> >
> > > The r4k machine was introduced in 2005 (6af0bf9c7) and its last
> > > logical change was in 2005 (9542611a6). After we can count 164
> > > maintenance commits (QEMU API changes) with the exception of
> > > 1 fix in 2015 (memory leak, commit 3ad9fd5a).
> > >
> > >
> > Please don't start any deprecation process. This requires certain
> > consultation within my company. Rest assured that everyone's opinion will
> > be taken into account while doing consiltation.
>
> The idea of having a deprecation process is precisely to
> allow time for people like to provide feedback before any
> deletion takes place. So this is not a reason to delay
> starting of deprecation.
>

What you said is fine, Daniel, I understand the idea, and it should be
that way. But I didn't ask for some lengthy negotiation, or waiting
for someone for months, but I just wanted to check within company if
all relevant people (that do not read QEMU devel list very often)
agree - since we, naturally, do various in-house setups with QEMU for
MIPS, that's all. This could count as the discussion on the patch, not
as a part of that loong "deprecated" state...

All is well,
Aleksandar


> The process lasts for 2 releases before we delete anything:
>
>   https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
>
> When we start the clock now, it is deprecated when 5.0 releases
> in April 2020, and still deprecated with 5.1 in August 2020.
>
> The code won't be deleted until Sep 2020 when 5.2 dev cycle opens,
> and there's still time to undelete it right up until the 5.2 feature
> freeze in late Oct 2020. That's 11 months away, which is plenty of
> time for feedback IMHO.
>
> 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 :|
>

[PATCH v6] hw/usb: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 hw/usb/dev-network.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 5de6213cc4..b81a8abe83 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1342,7 +1342,7 @@ static NetClientInfo net_usbnet_info = {
 .cleanup = usbnet_cleanup,
 };
 
-static void usb_net_realize(USBDevice *dev, Error **errrp)
+static void usb_net_realize(USBDevice *dev, Error **errp)
 {
 USBNetState *s = USB_NET(dev);
 
-- 
2.21.0

[PATCH v6] hw/tpm: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Stefan Berger 
---

v6: add Stefan's r-b

 hw/tpm/tpm_emulator.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
index 22f9113432..10d587ed40 100644
--- a/hw/tpm/tpm_emulator.c
+++ b/hw/tpm/tpm_emulator.c
@@ -155,7 +155,7 @@ static int tpm_emulator_unix_tx_bufs(TPMEmulator *tpm_emu,
  const uint8_t *in, uint32_t in_len,
  uint8_t *out, uint32_t out_len,
  bool *selftest_done,
- Error **err)
+ Error **errp)
 {
 ssize_t ret;
 bool is_selftest = false;
@@ -165,20 +165,20 @@ static int tpm_emulator_unix_tx_bufs(TPMEmulator *tpm_emu,
 is_selftest = tpm_util_is_selftest(in, in_len);
 }
 
-ret = qio_channel_write_all(tpm_emu->data_ioc, (char *)in, in_len, err);
+ret = qio_channel_write_all(tpm_emu->data_ioc, (char *)in, in_len, errp);
 if (ret != 0) {
 return -1;
 }
 
 ret = qio_channel_read_all(tpm_emu->data_ioc, (char *)out,
-  sizeof(struct tpm_resp_hdr), err);
+  sizeof(struct tpm_resp_hdr), errp);
 if (ret != 0) {
 return -1;
 }
 
 ret = qio_channel_read_all(tpm_emu->data_ioc,
   (char *)out + sizeof(struct tpm_resp_hdr),
-  tpm_cmd_get_size(out) - sizeof(struct tpm_resp_hdr), err);
+  tpm_cmd_get_size(out) - sizeof(struct tpm_resp_hdr), errp);
 if (ret != 0) {
 return -1;
 }
-- 
2.21.0

[PATCH v6] hw/sd: drop extra whitespace in sdhci_sysbus_realize() header

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
---

v6: improve patch subject
 (was [RFC v5 016/126] hw/sd: rename Error ** parameter to more common errp)
 add Eric's r-b

 hw/sd/sdhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 88404d0e9d..18c0c052ce 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1459,7 +1459,7 @@ static void sdhci_sysbus_finalize(Object *obj)
 sdhci_uninitfn(s);
 }
 
-static void sdhci_sysbus_realize(DeviceState *dev, Error ** errp)
+static void sdhci_sysbus_realize(DeviceState *dev, Error **errp)
 {
 SDHCIState *s = SYSBUS_SDHCI(dev);
 SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
-- 
2.21.0

[PATCH v6] hw/s390x: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Cornelia Huck 
---

v6: add Cornelia's r-b

 hw/s390x/event-facility.c | 2 +-
 hw/s390x/s390-stattrib.c  | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index 66205697ae..dc733ee2af 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -439,7 +439,7 @@ static void sclp_event_set_allow_all_mask_sizes(Object 
*obj, bool value,
 ef->allow_all_mask_sizes = value;
 }
 
-static bool sclp_event_get_allow_all_mask_sizes(Object *obj, Error **e)
+static bool sclp_event_get_allow_all_mask_sizes(Object *obj, Error **errp)
 {
 SCLPEventFacility *ef = (SCLPEventFacility *)obj;
 
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index bf5ac014c4..58121b9f68 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -352,7 +352,8 @@ static void s390_stattrib_class_init(ObjectClass *oc, void 
*data)
 dc->realize = s390_stattrib_realize;
 }
 
-static inline bool s390_stattrib_get_migration_enabled(Object *obj, Error **e)
+static inline bool s390_stattrib_get_migration_enabled(Object *obj,
+   Error **errp)
 {
 S390StAttribState *s = S390_STATTRIB(obj);
 
-- 
2.21.0

[PATCH v6] monitor/qmp-cmds: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 monitor/qmp-cmds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/monitor/qmp-cmds.c b/monitor/qmp-cmds.c
index 0880341a2d..c6faa3eaf0 100644
--- a/monitor/qmp-cmds.c
+++ b/monitor/qmp-cmds.c
@@ -109,7 +109,7 @@ void qmp_system_reset(Error **errp)
 qemu_system_reset_request(SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET);
 }
 
-void qmp_system_powerdown(Error **erp)
+void qmp_system_powerdown(Error **errp)
 {
 qemu_system_powerdown_request();
 }
-- 
2.21.0

[PATCH v6] qga: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 qga/commands-posix.c |  2 +-
 qga/commands-win32.c |  2 +-
 qga/commands.c   | 12 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 1c1a165dae..3bd7b54c08 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -2781,7 +2781,7 @@ static double ga_get_login_time(struct utmpx *user_info)
 return seconds + useconds;
 }
 
-GuestUserList *qmp_guest_get_users(Error **err)
+GuestUserList *qmp_guest_get_users(Error **errp)
 {
 GHashTable *cache = NULL;
 GuestUserList *head = NULL, *cur_item = NULL;
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 55ba5b263a..2461fd19bf 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -1946,7 +1946,7 @@ typedef struct _GA_WTSINFOA {
 
 } GA_WTSINFOA;
 
-GuestUserList *qmp_guest_get_users(Error **err)
+GuestUserList *qmp_guest_get_users(Error **errp)
 {
 #define QGA_NANOSECONDS 1000
 
diff --git a/qga/commands.c b/qga/commands.c
index 0c7d1385c2..43c323cead 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -143,7 +143,7 @@ static GuestExecInfo *guest_exec_info_find(int64_t 
pid_numeric)
 return NULL;
 }
 
-GuestExecStatus *qmp_guest_exec_status(int64_t pid, Error **err)
+GuestExecStatus *qmp_guest_exec_status(int64_t pid, Error **errp)
 {
 GuestExecInfo *gei;
 GuestExecStatus *ges;
@@ -152,7 +152,7 @@ GuestExecStatus *qmp_guest_exec_status(int64_t pid, Error 
**err)
 
 gei = guest_exec_info_find(pid);
 if (gei == NULL) {
-error_setg(err, QERR_INVALID_PARAMETER, "pid");
+error_setg(errp, QERR_INVALID_PARAMETER, "pid");
 return NULL;
 }
 
@@ -385,7 +385,7 @@ GuestExec *qmp_guest_exec(const char *path,
bool has_env, strList *env,
bool has_input_data, const char *input_data,
bool has_capture_output, bool capture_output,
-   Error **err)
+   Error **errp)
 {
 GPid pid;
 GuestExec *ge = NULL;
@@ -405,7 +405,7 @@ GuestExec *qmp_guest_exec(const char *path,
 arglist.next = has_arg ? arg : NULL;
 
 if (has_input_data) {
-input = qbase64_decode(input_data, -1, &ninput, err);
+input = qbase64_decode(input_data, -1, &ninput, errp);
 if (!input) {
 return NULL;
 }
@@ -424,7 +424,7 @@ GuestExec *qmp_guest_exec(const char *path,
 guest_exec_task_setup, NULL, &pid, has_input_data ? &in_fd : NULL,
 has_output ? &out_fd : NULL, has_output ? &err_fd : NULL, &gerr);
 if (!ret) {
-error_setg(err, QERR_QGA_COMMAND_FAILED, gerr->message);
+error_setg(errp, QERR_QGA_COMMAND_FAILED, gerr->message);
 g_error_free(gerr);
 goto done;
 }
@@ -499,7 +499,7 @@ int ga_parse_whence(GuestFileWhence *whence, Error **errp)
 return -1;
 }
 
-GuestHostName *qmp_guest_get_host_name(Error **err)
+GuestHostName *qmp_guest_get_host_name(Error **errp)
 {
 GuestHostName *result = NULL;
 gchar const *hostname = g_get_host_name();
-- 
2.21.0

Re: [PATCH v36 11/17] target/avr: Add limited support for USART and 16 bit timer peripherals

[Aleksandar Markovic]

On Wed, Nov 27, 2019 at 7:48 PM Michael Rolnik  wrote:
>
> too late :)
>

There will be opportunities in future versions. Whaaat, did you really
think you would get away with only 37 versions? ;-)

[PATCH v6] hw/i386/amd_iommu: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 hw/i386/amd_iommu.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index d55dbf07fc..b1175e52c7 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1533,7 +1533,7 @@ static void amdvi_reset(DeviceState *dev)
 amdvi_init(s);
 }
 
-static void amdvi_realize(DeviceState *dev, Error **err)
+static void amdvi_realize(DeviceState *dev, Error **errp)
 {
 int ret = 0;
 AMDVIState *s = AMD_IOMMU_DEVICE(dev);
@@ -1549,21 +1549,21 @@ static void amdvi_realize(DeviceState *dev, Error **err)
 /* This device should take care of IOMMU PCI properties */
 x86_iommu->type = TYPE_AMD;
 qdev_set_parent_bus(DEVICE(&s->pci), &bus->qbus);
-object_property_set_bool(OBJECT(&s->pci), true, "realized", err);
+object_property_set_bool(OBJECT(&s->pci), true, "realized", errp);
 ret = pci_add_capability(&s->pci.dev, AMDVI_CAPAB_ID_SEC, 0,
- AMDVI_CAPAB_SIZE, err);
+ AMDVI_CAPAB_SIZE, errp);
 if (ret < 0) {
 return;
 }
 s->capab_offset = ret;
 
 ret = pci_add_capability(&s->pci.dev, PCI_CAP_ID_MSI, 0,
- AMDVI_CAPAB_REG_SIZE, err);
+ AMDVI_CAPAB_REG_SIZE, errp);
 if (ret < 0) {
 return;
 }
 ret = pci_add_capability(&s->pci.dev, PCI_CAP_ID_HT, 0,
- AMDVI_CAPAB_REG_SIZE, err);
+ AMDVI_CAPAB_REG_SIZE, errp);
 if (ret < 0) {
 return;
 }
@@ -1578,8 +1578,8 @@ static void amdvi_realize(DeviceState *dev, Error **err)
 sysbus_init_mmio(SYS_BUS_DEVICE(s), &s->mmio);
 sysbus_mmio_map(SYS_BUS_DEVICE(s), 0, AMDVI_BASE_ADDR);
 pci_setup_iommu(bus, amdvi_host_dma_iommu, s);
-s->devid = object_property_get_int(OBJECT(&s->pci), "addr", err);
-msi_init(&s->pci.dev, 0, 1, true, false, err);
+s->devid = object_property_get_int(OBJECT(&s->pci), "addr", errp);
+msi_init(&s->pci.dev, 0, 1, true, false, errp);
 amdvi_init(s);
 }
 
-- 
2.21.0

[PATCH v6] block/snapshot: rename Error ** parameter to more common errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
---

v6: merge corresponding header change here, so, v6 is merge of
  [RFC v5 011/126] block/snapshot: rename Error ** parameter to more common errp
  and
  [RFC v5 019/126] include/block/snapshot.h: rename Error ** parameter to more 
common errp
  both has Eric's r-b, so I keep Eric's r-b for the merge

 include/block/snapshot.h | 2 +-
 block/snapshot.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/block/snapshot.h b/include/block/snapshot.h
index b5d5084a12..2bfcd57578 100644
--- a/include/block/snapshot.h
+++ b/include/block/snapshot.h
@@ -78,7 +78,7 @@ int bdrv_snapshot_load_tmp_by_id_or_name(BlockDriverState *bs,
 
 bool bdrv_all_can_snapshot(BlockDriverState **first_bad_bs);
 int bdrv_all_delete_snapshot(const char *name, BlockDriverState **first_bsd_bs,
- Error **err);
+ Error **errp);
 int bdrv_all_goto_snapshot(const char *name, BlockDriverState **first_bad_bs,
Error **errp);
 int bdrv_all_find_snapshot(const char *name, BlockDriverState **first_bad_bs);
diff --git a/block/snapshot.c b/block/snapshot.c
index 8081616ae9..bd9fb01817 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -426,7 +426,7 @@ fail:
 }
 
 int bdrv_all_delete_snapshot(const char *name, BlockDriverState **first_bad_bs,
- Error **err)
+ Error **errp)
 {
 int ret = 0;
 BlockDriverState *bs;
@@ -441,7 +441,7 @@ int bdrv_all_delete_snapshot(const char *name, 
BlockDriverState **first_bad_bs,
 bdrv_snapshot_find(bs, snapshot, name) >= 0)
 {
 ret = bdrv_snapshot_delete(bs, snapshot->id_str,
-   snapshot->name, err);
+   snapshot->name, errp);
 }
 aio_context_release(ctx);
 if (ret < 0) {
-- 
2.21.0

[PATCH v6] hw/core/qdev: cleanup Error ** variables

[Vladimir Sementsov-Ogievskiy]

Rename Error ** parameter in check_only_migratable to common errp.

In device_set_realized:

 - Move "if (local_err != NULL)" closer to error setters.

 - Drop 'Error **local_errp': it doesn't save any LoCs, but it's very
   unusual.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
Reviewed-by: Marc-André Lureau 
---

v6: enhance grammar in comment [Eric]
add r-b by Eric and Marc-André

 hw/core/qdev.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index cf1ba28fe3..82d3ee590a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -820,12 +820,12 @@ static bool device_get_realized(Object *obj, Error **errp)
 return dev->realized;
 }
 
-static bool check_only_migratable(Object *obj, Error **err)
+static bool check_only_migratable(Object *obj, Error **errp)
 {
 DeviceClass *dc = DEVICE_GET_CLASS(obj);
 
 if (!vmstate_check_only_migratable(dc->vmsd)) {
-error_setg(err, "Device %s is not migratable, but "
+error_setg(errp, "Device %s is not migratable, but "
"--only-migratable was specified",
object_get_typename(obj));
 return false;
@@ -874,10 +874,9 @@ static void device_set_realized(Object *obj, bool value, 
Error **errp)
 
 if (dc->realize) {
 dc->realize(dev, &local_err);
-}
-
-if (local_err != NULL) {
-goto fail;
+if (local_err != NULL) {
+goto fail;
+}
 }
 
 DEVICE_LISTENER_CALL(realize, Forward, dev);
@@ -918,27 +917,26 @@ static void device_set_realized(Object *obj, bool value, 
Error **errp)
}
 
 } else if (!value && dev->realized) {
-Error **local_errp = NULL;
+/* We want local_err to track only the first error */
 QLIST_FOREACH(bus, &dev->child_bus, sibling) {
-local_errp = local_err ? NULL : &local_err;
 object_property_set_bool(OBJECT(bus), false, "realized",
- local_errp);
+ local_err ? NULL : &local_err);
 }
 if (qdev_get_vmsd(dev)) {
 vmstate_unregister(dev, qdev_get_vmsd(dev), dev);
 }
 if (dc->unrealize) {
-local_errp = local_err ? NULL : &local_err;
-dc->unrealize(dev, local_errp);
+dc->unrealize(dev, local_err ? NULL : &local_err);
 }
 dev->pending_deleted_event = true;
 DEVICE_LISTENER_CALL(unrealize, Reverse, dev);
-}
 
-if (local_err != NULL) {
-goto fail;
+if (local_err != NULL) {
+goto fail;
+}
 }
 
+assert(local_err == NULL);
 dev->realized = value;
 return;
 
@@ -976,7 +974,7 @@ static bool device_get_hotpluggable(Object *obj, Error 
**errp)
 qbus_is_hotpluggable(dev->parent_bus));
 }
 
-static bool device_get_hotplugged(Object *obj, Error **err)
+static bool device_get_hotplugged(Object *obj, Error **errp)
 {
 DeviceState *dev = DEVICE(obj);
 
-- 
2.21.0

Re: [RFC] exec: flush CPU TB cache when breakpoint address translation fails

[Max Filippov]

On Wed, Nov 27, 2019 at 11:06 AM Alex Bennée  wrote:
> Max Filippov  writes:
>
> > When a breakpoint is inserted at location for which there's currently no
> > virtual to physical translation no action is taken on CPU TB cache. If a
> > TB for that virtual address already exists but is not visible ATM the
> > breakpoint won't be hit next time an instruction at that address will be
> > executed.
>
> So the userspace has run once but is currently paged out?

Yes, but not necessarily paged out, just not in the CPU TLB.
Or it has run to completion and when you start it next time
it gets loaded to the same physical pages.

-- 
Thanks.
-- Max

[PATCH v6] 9pfs: well form error hint helpers

[Vladimir Sementsov-Ogievskiy]

Make error_append_security_model_hint and
error_append_socket_sockfd_hint hint append helpers well formed:
rename errp to errp_in, as it is IN-parameter here (which is unusual
for errp).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Acked-by: Greg Kurz 
---

v6: add Greg's a-b

 hw/9pfs/9p-local.c | 4 ++--
 hw/9pfs/9p-proxy.c | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index 4708c0bd89..76fa1858b7 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -1473,9 +1473,9 @@ static void local_cleanup(FsContext *ctx)
 g_free(data);
 }
 
-static void error_append_security_model_hint(Error **errp)
+static void error_append_security_model_hint(Error **errp_in)
 {
-error_append_hint(errp, "Valid options are: security_model="
+error_append_hint(errp_in, "Valid options are: security_model="
   "[passthrough|mapped-xattr|mapped-file|none]\n");
 }
 
diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c
index 97ab9c58a5..9e29abc3ef 100644
--- a/hw/9pfs/9p-proxy.c
+++ b/hw/9pfs/9p-proxy.c
@@ -1114,9 +1114,10 @@ static int connect_namedsocket(const char *path, Error 
**errp)
 return sockfd;
 }
 
-static void error_append_socket_sockfd_hint(Error **errp)
+static void error_append_socket_sockfd_hint(Error **errp_in)
 {
-error_append_hint(errp, "Either specify socket=/some/path where /some/path"
+error_append_hint(errp_in,
+  "Either specify socket=/some/path where /some/path"
   " points to a listening AF_UNIX socket or sock_fd=fd"
   " where fd is a file descriptor to a connected AF_UNIX"
   " socket\n");
-- 
2.21.0

[PATCH v6] ppc: well form kvmppc_hint_smt_possible error hint helper

[Vladimir Sementsov-Ogievskiy]

Make kvmppc_hint_smt_possible hint append helper well formed:
rename errp to errp_in, as it is IN-parameter here (which is unusual
for errp), rename function to be kvmppc_error_append_*_hint.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Marc-André Lureau 
---

v6: keep kvmppc_ function prefix
add r-b by Marc-André

 target/ppc/kvm_ppc.h | 4 ++--
 hw/ppc/spapr.c   | 2 +-
 target/ppc/kvm.c | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index 98bd7d5da6..47b08a4030 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -28,7 +28,7 @@ void kvmppc_set_papr(PowerPCCPU *cpu);
 int kvmppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr);
 void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy);
 int kvmppc_smt_threads(void);
-void kvmppc_hint_smt_possible(Error **errp);
+void kvmppc_error_append_smt_possible_hint(Error **errp_in);
 int kvmppc_set_smt_threads(int smt);
 int kvmppc_clear_tsr_bits(PowerPCCPU *cpu, uint32_t tsr_bits);
 int kvmppc_or_tsr_bits(PowerPCCPU *cpu, uint32_t tsr_bits);
@@ -164,7 +164,7 @@ static inline int kvmppc_smt_threads(void)
 return 1;
 }
 
-static inline void kvmppc_hint_smt_possible(Error **errp)
+static inline void kvmppc_error_append_smt_possible_hint(Error **errp_in)
 {
 return;
 }
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index e076f6023c..1b87eb0ffd 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2564,7 +2564,7 @@ static void spapr_set_vsmt_mode(SpaprMachineState *spapr, 
Error **errp)
   " requires the use of VSMT mode %d.\n",
   smp_threads, kvm_smt, spapr->vsmt);
 }
-kvmppc_hint_smt_possible(&local_err);
+kvmppc_error_append_smt_possible_hint(&local_err);
 goto out;
 }
 }
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index c77f9848ec..7406d18945 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2076,7 +2076,7 @@ int kvmppc_set_smt_threads(int smt)
 return ret;
 }
 
-void kvmppc_hint_smt_possible(Error **errp)
+void kvmppc_error_append_smt_possible_hint(Error **errp_in)
 {
 int i;
 GString *g;
@@ -2091,10 +2091,10 @@ void kvmppc_hint_smt_possible(Error **errp)
 }
 }
 s = g_string_free(g, false);
-error_append_hint(errp, "%s.\n", s);
+error_append_hint(errp_in, "%s.\n", s);
 g_free(s);
 } else {
-error_append_hint(errp,
+error_append_hint(errp_in,
   "This KVM seems to be too old to support VSMT.\n");
 }
 }
-- 
2.21.0

[PATCH v6] nbd: well form nbd_iter_channel_error errp handler

[Vladimir Sementsov-Ogievskiy]

Make nbd_iter_channel_error errp handler well formed:
rename local_err to errp_in, as it is IN-parameter here (which is
unusual for Error**).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
---

v6: fix commit message
add Eric's r-b

 block/nbd.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index 5f18f78a94..345bf902e3 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -864,18 +864,18 @@ typedef struct NBDReplyChunkIter {
 } NBDReplyChunkIter;
 
 static void nbd_iter_channel_error(NBDReplyChunkIter *iter,
-   int ret, Error **local_err)
+   int ret, Error **errp_in)
 {
-assert(ret < 0);
+assert(ret < 0 && errp_in && *errp_in);
 
 if (!iter->ret) {
 iter->ret = ret;
-error_propagate(&iter->err, *local_err);
+error_propagate(&iter->err, *errp_in);
 } else {
-error_free(*local_err);
+error_free(*errp_in);
 }
 
-*local_err = NULL;
+*errp_in = NULL;
 }
 
 static void nbd_iter_request_error(NBDReplyChunkIter *iter, int ret)
-- 
2.21.0

Re: [Virtio-fs] [PATCH 4/4] virtiofsd: Implement blocking posix locks

[Vivek Goyal]

On Tue, Nov 26, 2019 at 01:02:29PM +, Dr. David Alan Gilbert wrote:

[..]
> > > > @@ -1950,21 +1948,54 @@ static void lo_setlk(fuse_req_t req, fuse_ino_t 
> > > > ino,
> > > >  
> > > > if (!plock) {
> > > > saverr = ret;
> > > > +   pthread_mutex_unlock(&inode->plock_mutex);
> > > > goto out;
> > > > }
> > > >  
> > > > +   /*
> > > > +* plock is now released when inode is going away. We already 
> > > > have
> > > > +* a reference on inode, so it is guaranteed that plock->fd is
> > > > +* still around even after dropping inode->plock_mutex lock
> > > > +*/
> > > > +   ofd = plock->fd;
> > > > +   pthread_mutex_unlock(&inode->plock_mutex);
> > > > +
> > > > +   /*
> > > > +* If this lock request can block, request caller to wait for
> > > > +* notification. Do not access req after this. Once lock is
> > > > +* available, send a notification instead.
> > > > +*/
> > > > +   if (sleep && lock->l_type != F_UNLCK) {
> > > > +   /*
> > > > +* If notification queue is not enabled, can't support 
> > > > async
> > > > +* locks.
> > > > +*/
> > > > +   if (!se->notify_enabled) {
> > > > +   saverr = EOPNOTSUPP;
> > > > +   goto out;
> > > > +   }
> > > > +   async_lock = true;
> > > > +   unique = req->unique;
> > > > +   fuse_reply_wait(req);
> > > > +   }
> > > > /* TODO: Is it alright to modify flock? */
> > > > lock->l_pid = 0;
> > > > -   ret = fcntl(plock->fd, F_OFD_SETLK, lock);
> > > > +   if (async_lock)
> > > > +   ret = fcntl(ofd, F_OFD_SETLKW, lock);
> > > > +   else
> > > > +   ret = fcntl(ofd, F_OFD_SETLK, lock);
> > > 
> > > What happens if the guest is rebooted after it's asked
> > > for, but not been granted a lock?
> > 
> > I think a regular reboot can't be done till a request is pending, because
> > virtio-fs can't be unmounted and unmount will wait for all pending
> > requests to finish.
> > 
> > Destroying qemu will destroy deamon too.
> > 
> > Are there any other reboot paths I have missed.
> 
> Yes, there are a few other ways the guest can reboot:
>   a) A echo b > /proc/sysrq-trigger

I tried it. Both qemu and virtiofsd hang. virtiofsd wants to stop a 
queue. And that tries to stop thrad pool. But one of the threads in
thread pool is blocked on setlkw. So g_thread_pool_free() hangs.

I am not seeing any option in glib thread pool API to stop or send
signal to threads which are blocked.

Thanks
Vivek

Re: [RFC] exec: flush CPU TB cache when breakpoint address translation fails

[Alex Bennée]

Max Filippov  writes:

> When a breakpoint is inserted at location for which there's currently no
> virtual to physical translation no action is taken on CPU TB cache. If a
> TB for that virtual address already exists but is not visible ATM the
> breakpoint won't be hit next time an instruction at that address will be
> executed.

So the userspace has run once but is currently paged out?

>
> Flush entire CPU TB cache when a breakpoint is set for a virtual address
> that cannot be translated to physical address.
>
> This change fixes the following workflow:
> - linux user application is running
> - a breakpoint is inserted from QEMU gdbstub for a user address that is
>   not currently present in the target CPU TLB
> - an instruction at that address is executed, but the external debugger
>   doesn't get control.
>
> Signed-off-by: Max Filippov 
> ---
>  exec.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/exec.c b/exec.c
> index ffdb5185353b..918945f8097e 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1024,6 +1024,8 @@ static void breakpoint_invalidate(CPUState *cpu, 
> target_ulong pc)
>  /* Locks grabbed by tb_invalidate_phys_addr */
>  tb_invalidate_phys_addr(cpu->cpu_ases[asidx].as,
>  phys | (pc & ~TARGET_PAGE_MASK), attrs);
> +} else {
> +tb_flush(cpu);
>  }
>  }
>  #endif


-- 
Alex Bennée