Re: [PATCH v2 2/2] s390x/cpumodel: Introduce dynamic feature groups

[Christian Borntraeger]

On 25.11.19 18:20, David Hildenbrand wrote:
> 
> As soon as dynamic feature groups are used, the CPU model becomes
> migration-unsafe. Upper layers can expand these models to migration-safe
> and static variants, allowing them to be migrated.

I really dislike that. I am trying to get rid of the unsafe variants (e.g. now
defaulting to host-model instead of host-passthrough). I do not want to give
users new ways of hurting themselves.

Unless I misunderstood Eduardo, I think his versioning approach is actually 
better
in regard to migration, no?
I z terms, you can still say -cpu z13  which is just an alias to z13v1 z13v2 
etc.
Assuming that the version is checked this will be safe.

Re: [PATCH 0/4] fix & merge block_status_above and is_allocated_above

[Vladimir Sementsov-Ogievskiy]

25.11.2019 18:46, Kevin Wolf wrote:
> Am 25.11.2019 um 11:08 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Ping?
>>
>> Hi! Why so silent? Postpone this to 5.0? This is fixing the same
>> problem with block commit, like Kevin's series, just commit not to mid
>> but to base..
> 
> To be honest, I think by now we've found so many problems around short
> backing files, each with a non-trivial fix, that I don't think we can
> have a reasonably complete fix in -rc3 without risking breaking
> everything. None of the problems are new, in fact I think they have
> existed since day one of resize/commit, and nobody has reported problems
> before, so they can't be hitting a large number of users.
> 
> So, reluctantly, I have to admit that both series and whatever we'll add
> on top are probably better kept for 5.0 (and 4.2.1) rather than added
> very late into 4.2.
> 

OK, I agree.


-- 
Best regards,
Vladimir

Re: [PATCH 1/4] block/io: fix bdrv_co_block_status_above

[Vladimir Sementsov-Ogievskiy]

25.11.2019 19:00, Kevin Wolf wrote:
> Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> bdrv_co_block_status_above has several problems with handling short
>> backing files:
>>
>> 1. With want_zeros=true, it may return ret with BDRV_BLOCK_ZERO but
>> without BDRV_BLOCK_ALLOCATED flag, when actually short backing file
>> which produces these after-EOF zeros is inside requested backing
>> sequesnce.
> 
> s/sequesnce/sequence/
> 
>>
>> 2. With want_zeros=false, it will just stop inside requested region, if
>> we have unallocated region in top node when underlying backing is
>> short.
> 
> I honestly don't understand this one. Can you rephrase/explain in more
> detail what you mean by "stop inside [the] requested region"?

Hmm, yes, bad description. I mean, it may return pnum=0 prior to actual EOF,
because of EOF of short backing file.

> 
>> Fix these things, making logic about short backing files clearer.
>>
>> Note that 154 output changed, because now bdrv_block_status_above don't
>> merge unallocated zeros with zeros after EOF (which are actually
>> "allocated" in POV of read from backing-chain top) and is_zero() just
>> don't understand that the whole head or tail is zero. We may update
>> is_zero to call bdrv_block_status_above several times, or add flag to
>> bdrv_block_status_above that we are not interested in ALLOCATED flag,
>> so ranges with different ALLOCATED status may be merged, but actually,
>> it seems that we'd better don't care about this corner case.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   block/io.c | 41 --
>>   tests/qemu-iotests/154.out |  4 ++--
>>   2 files changed, 32 insertions(+), 13 deletions(-)
>>
>> diff --git a/block/io.c b/block/io.c
>> index f75777f5ea..4d7fa99bd2 100644
>> --- a/block/io.c
>> +++ b/block/io.c
>> @@ -2434,25 +2434,44 @@ static int coroutine_fn 
>> bdrv_co_block_status_above(BlockDriverState *bs,
>>   ret = bdrv_co_block_status(p, want_zero, offset, bytes, pnum, map,
>>  file);
>>   if (ret < 0) {
>> -break;
>> +return ret;
>>   }
>> -if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
>> +if (*pnum == 0) {
>> +if (first) {
>> +return ret;
>> +}
>> +
>>   /*
>> - * Reading beyond the end of the file continues to read
>> - * zeroes, but we can only widen the result to the
>> - * unallocated length we learned from an earlier
>> - * iteration.
>> + * Reads from bs for selected region will return zeroes, 
>> produced
>> + * because current level is short. We should consider it as
>> + * allocated.
> 
> "the selected region"
> "the current level"
> 
>> + * TODO: Should we report p as file here?
> 
> I think that would make sense.
> 
>>*/
>> +assert(ret & BDRV_BLOCK_EOF);
> 
> Can this assertion be moved above the if (first)?

it may correspond to requested bytes==0.. But we can check it separately
before for loop and move this assertion.

> 
>>   *pnum = bytes;
>> +return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;
>>   }
>> -if (ret & (BDRV_BLOCK_ZERO | BDRV_BLOCK_DATA)) {
>> -break;
>> +if (ret & BDRV_BLOCK_ALLOCATED) {
>> +/* We've found the node and the status, we must return. */
>> +
>> +if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
>> +/*
>> + * This level also responsible for reads after EOF inside
>> + * unallocated region in previous level.
> 
> "is also responsible"
> "the unallocated region in the previous level"
> 
>> + */
>> +*pnum = bytes;
>> +}
>> +
>> +return ret;
>>   }
>> -/* [offset, pnum] unallocated on this layer, which could be only
>> - * the first part of [offset, bytes].  */
> 
> Any reason for deleting this comment? I think it's still valid.

Hmm, I decided that it's obvious and shorter comment is enough.
I can leave it, of course.

> 
>> -bytes = MIN(bytes, *pnum);
>> +
>> +/* Proceed to backing */
>> +assert(*pnum <= bytes);
>> +bytes = *pnum;
>>   first = false;
>>   }
>> +
>>   return ret;
>>   }
> 
> Kevin
> 


-- 
Best regards,
Vladimir

RE: [RFC v2 09/22] vfio/pci: add iommu_context notifier for pasid alloc/free

[Liu, Yi L]

Hi David,

> From: David Gibson < da...@gibson.dropbear.id.au>
> Sent: Wednesday, November 20, 2019 12:28 PM
> To: Liu, Yi L 
> Subject: Re: [RFC v2 09/22] vfio/pci: add iommu_context notifier for pasid 
> alloc/free
> 
> On Wed, Nov 06, 2019 at 12:14:50PM +, Liu, Yi L wrote:
> > > From: David Gibson [mailto:da...@gibson.dropbear.id.au]
> > > Sent: Tuesday, October 29, 2019 8:16 PM
> > > To: Liu, Yi L 
> > > Subject: Re: [RFC v2 09/22] vfio/pci: add iommu_context notifier for pasid
> alloc/free
> > >
> > > On Thu, Oct 24, 2019 at 08:34:30AM -0400, Liu Yi L wrote:
> > > > This patch adds pasid alloc/free notifiers for vfio-pci. It is
> > > > supposed to be fired by vIOMMU. VFIO then sends PASID allocation
> > > > or free request to host.
> > > >
> > > > Cc: Kevin Tian 
> > > > Cc: Jacob Pan 
> > > > Cc: Peter Xu 
> > > > Cc: Eric Auger 
> > > > Cc: Yi Sun 
> > > > Cc: David Gibson 
> > > > Signed-off-by: Liu Yi L 
> > > > ---
> > > >  hw/vfio/common.c |  9 ++
> > > >  hw/vfio/pci.c| 81
[...]
> > > > +
> > > > +static void vfio_iommu_pasid_alloc_notify(IOMMUCTXNotifier *n,
> > > > +  IOMMUCTXEventData 
> > > > *event_data)
> > > > +{
> > > > +VFIOIOMMUContext *giommu_ctx = container_of(n, VFIOIOMMUContext,
> n);
> > > > +VFIOContainer *container = giommu_ctx->container;
> > > > +IOMMUCTXPASIDReqDesc *pasid_req =
> > > > +  (IOMMUCTXPASIDReqDesc *) 
> > > > event_data->data;
> > > > +struct vfio_iommu_type1_pasid_request req;
> > > > +unsigned long argsz;
> > > > +int pasid;
> > > > +
> > > > +argsz = sizeof(req);
> > > > +req.argsz = argsz;
> > > > +req.flag = VFIO_IOMMU_PASID_ALLOC;
> > > > +req.min_pasid = pasid_req->min_pasid;
> > > > +req.max_pasid = pasid_req->max_pasid;
> > > > +
> > > > +pasid = ioctl(container->fd, VFIO_IOMMU_PASID_REQUEST, );
> > > > +if (pasid < 0) {
> > > > +error_report("%s: %d, alloc failed", __func__, -errno);
> > > > +}
> > > > +pasid_req->alloc_result = pasid;
> > >
> > > Altering the event data from the notifier doesn't make sense.  By
> > > definition there can be multiple notifiers on the chain, so in that
> > > case which one is responsible for updating the writable field?
> >
> > I guess you mean multiple pasid_alloc nofitiers. right?
> >
> > It works for VT-d now, as Intel vIOMMU maintains the IOMMUContext
> > per-bdf. And there will be only 1 pasid_alloc notifier in the chain. But, I
> > agree it is not good if other module just share an IOMMUConext across
> > devices. Definitely, it would have multiple pasid_alloc notifiers.
> 
> Right.
> 
> > How about enforcing IOMMUContext layer to only invoke one successful
> > pasid_alloc/free notifier if PASID_ALLOC/FREE event comes? pasid
> > alloc/free are really special as it requires feedback. And a potential
> > benefit is that the pasid_alloc/free will not be affected by hot plug
> > scenario. There will be always a notifier to work for pasid_alloc/free
> > work unless all passthru devices are hot plugged. How do you think? Or
> > if any other idea?
> 
> Hrm, that still doesn't seem right to me.  I don't think a notifier is
> really the right mechanism for something that needs to return values.
> This seems like something where you need to find a _single_
> responsible object and call a method / callback on that specifically.

Agreed. For alloc/free operations, we need an explicit calling instead
of notifier which is usally to be a chain notification.

> But it seems to me there's a more fundamental problem here.  AIUI the
> idea is that a single IOMMUContext could hold multiple devices.  But
> if the devices are responsible for assigning their own pasid values
> (by passing that decisionon to the host through vfio) then that really
> can't work.
>
> I'm assuming it's impossible from the hardware side to virtualize the
> pasids (so that we could assign them from qemu without host
> intervention).

Actually, this is possible. On Intel platform, we've introduced ENQCMD
to do PASID translation which essentially supports PASID virtualization.
You may get more details in section 3.3. This is also why we want to have
host's intervention in PASID alloc/free.

https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

> If so, then the pasid allocation really has to be a Context level, not
> device level operation.  We'd have to wire the VFIO backend up to the
> context itself, not a device... I'm not immediately sure how to do
> that, though.

I think for the pasid alloc/free, we want it to be a vfio container
operation. right? However, we cannot expose vfio container out of vfio
or we don't want to do such thing. Then I'm wondering if we can have
a PASIDObject which is allocated per container creation, and registered
to vIOMMU. The PASIDObject can provide pasid alloc/free ops. vIOMMU can
consume the 

Re: [QUESTION] What is the best license option for new files introduced in QEMU?

[Thomas Huth]

On 25/11/2019 18.49, Aleksandar Markovic wrote:

I read LICENSE file, but I read also recent contributions, and it is
not clear to me what version of GPL is best/recommended for new file
just being introduced to QEMU:

* GPL 2.0
* GPL 2.0 (or later at your option)
* GPL 2.1
* GPL 2.1 (or later at your option)

or something else. (The rest od wording of license preamble is clear
to me.) Please somebody explsin snd clarify.


There is no GPL v2.1, you likely mixed that up with LGPL v2.1

For new files, you've got to choose a license that is compatible with 
GPL v2.0 (or later at your option). So LGPL v2.1 is fine, too.


 Thomas

[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(>vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(>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(>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(>vga, 0,
VBE_DISPI_INDEX_X_OFFSET);
 vbe_ioport_write_data(>vga, 0, offs % stride / bypp);
 }
 vbe_ioport_write_index(>vga, 0, VBE_DISPI_INDEX_Y_OFFSET);
 vbe_ioport_write_data(>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(>vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(>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(LOG_UNIMP, "Unsupported bpp 

[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(>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(>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 0/8] ATI R300 emulated graphics card

[aaron . zakhrov]

From: Aaron Dominick 

Hello,
I thought of working on an emulated R300 GPU for QEMU video acceleration on 
vintage operating systems (Windows 9x-XP)
The following patch series contains the initial QEMU device and some register 
read/write operations.
Testing it on an OpenSUSE Linux guest and the kernel correctly detects the card 
and loads the radeon DRM driver.
It gets as far as the CRTC probing before crashing with an error that there is 
not enough bandwidth.
I know next to nothing about hardware emulation and would like to know if what 
I have got so far is on the right track.


Aaron Dominick (8):
  Add Radeon kernel headers. Will clean up later
  Fix MC STATUS resgister
  R300 fixes
  Got GPU init working. Stops at probing display
  Add Radeon kernel headers. Will clean up later
  Fix MC STATUS resgister
  R300 fixes
  Got GPU init working. Stops at probing display

-- 
2.24.0

[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(>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(>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 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(>vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(>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(>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(>vga, 0,
VBE_DISPI_INDEX_X_OFFSET);
 vbe_ioport_write_data(>vga, 0, offs % stride / bypp);
 }
 vbe_ioport_write_index(>vga, 0, VBE_DISPI_INDEX_Y_OFFSET);
 vbe_ioport_write_data(>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(>vga, 0, VBE_DISPI_INDEX_ENABLE);
 vbe_ioport_write_data(>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(LOG_UNIMP, "Unsupported bpp 

[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 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

Re: [PATCH v0 1/2] qdev-properties-system: extend set_pionter for unrealized devices

[Denis Plotnikov]

On 25.11.2019 18:30, Eduardo Habkost wrote:
> On Fri, Nov 22, 2019 at 11:36:30AM +, Denis Plotnikov wrote:
>>
>> On 18.11.2019 21:54, Eduardo Habkost wrote:
>>> On Sun, Nov 10, 2019 at 10:03:09PM +0300, Denis Plotnikov wrote:
 Some device's property can be changed if the device has been already
 realized. For example, it could be "drive" property of a scsi disk device.

 So far, set_pointer could operate only on a relized device. The patch
 extends its interface for operation on an unrealized device.

 Signed-off-by: Denis Plotnikov 
 ---
hw/core/qdev-properties-system.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)

 diff --git a/hw/core/qdev-properties-system.c 
 b/hw/core/qdev-properties-system.c
 index ba412dd2ca..c534590dcd 100644
 --- a/hw/core/qdev-properties-system.c
 +++ b/hw/core/qdev-properties-system.c
 @@ -38,9 +38,14 @@ static void get_pointer(Object *obj, Visitor *v, 
 Property *prop,
}

static void set_pointer(Object *obj, Visitor *v, Property *prop,
 -void (*parse)(DeviceState *dev, const char *str,
 -  void **ptr, const char *propname,
 -  Error **errp),
 +void (*parse_realized)(DeviceState *dev,
 +   const char *str, void 
 **ptr,
 +   const char *propname,
 +   Error **errp),
 +void (*parse_unrealized)(DeviceState *dev,
 + const char *str, void 
 **ptr,
 + const char *propname,
 + Error **errp),
const char *name, Error **errp)
>>> Wouldn't it be simpler to just add a PropertyInfo::allow_set_after_realize
>>> bool field, and call the same setter function?  Then you can
>>> simply change do_parse_drive() to check if realized is true.
>> May be, but I thought It would be more clear to have a separate callback
>> for all the devices supporting the property setting when realized.
>> Also the "drive" property setting on realized and non-realized device a
>> little bit different: in the realized case the setter function expects
>> to get
>> BlockDriverState only, when in the unrealized case the setter can accept
>> both BlockBackend and BlockDriverState. Also, in the unrealized case the
>> setter function doesn't expect to have a device with an empty BlockBackend.
>> I decided that extending do_parse_drive would make it more complex for
>> understanding. That's why I made two separate functions for both cases.
> I understand you might want two separate functions in the
> specific case of drive.  You can still call different
> functions after checking dev->realized inside do_parse_drive().
>
> My point was that you don't need to make set_pointer() require
> two separate function pointers just to propagate 1 bit of
> information that is already available in DeviceState.  In patch
> 2/2 you had to create 4 different copies of parse_drive*()
> because of this.
Yes, that's true. I wanted to suggest a more general way to deal with a 
device on realized and non-realized state.
I may be too much and not necessary. May be we should wait for a 
feedback from the block maintainers?
>
>
>> I'd like to mention that I have a few concerns about
>> do_parse_drive_realized (please see the next patch from the series) and
>> I'd like them to be reviewed as well. After that, may be it would be
>> better to go the way you suggested.
> In the case if your questions in patch 2/2, I'm afraid I don't
> know the answers and we need help from the block maintainers.
Anyway, thanks for taking a glance.
>

[PULL 3/8] vfio/pci: Split vfio_intx_update()

[David Gibson]

This splits the vfio_intx_update() function into one part doing the actual
reconnection with the KVM irqchip (vfio_intx_update(), now taking an
argument with the new routing) and vfio_intx_routing_notifier() which
handles calls to the pci device intx routing notifier and calling
vfio_intx_update() when necessary.  This will make adding support for the
irqchip change notifier easier.

Cc: Alex Williamson 
Cc: Alexey Kardashevskiy 

Signed-off-by: David Gibson 
Tested-by: Alex Williamson 
Reviewed-by: Alex Williamson 
Reviewed-by: Greg Kurz 
Acked-by: Alex Williamson 
---
 hw/vfio/pci.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 0c55883bba..521289aa7d 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -216,30 +216,18 @@ static void vfio_intx_disable_kvm(VFIOPCIDevice *vdev)
 #endif
 }
 
-static void vfio_intx_update(PCIDevice *pdev)
+static void vfio_intx_update(VFIOPCIDevice *vdev, PCIINTxRoute *route)
 {
-VFIOPCIDevice *vdev = PCI_VFIO(pdev);
-PCIINTxRoute route;
 Error *err = NULL;
 
-if (vdev->interrupt != VFIO_INT_INTx) {
-return;
-}
-
-route = pci_device_route_intx_to_irq(>pdev, vdev->intx.pin);
-
-if (!pci_intx_route_changed(>intx.route, )) {
-return; /* Nothing changed */
-}
-
 trace_vfio_intx_update(vdev->vbasedev.name,
-   vdev->intx.route.irq, route.irq);
+   vdev->intx.route.irq, route->irq);
 
 vfio_intx_disable_kvm(vdev);
 
-vdev->intx.route = route;
+vdev->intx.route = *route;
 
-if (route.mode != PCI_INTX_ENABLED) {
+if (route->mode != PCI_INTX_ENABLED) {
 return;
 }
 
@@ -252,6 +240,22 @@ static void vfio_intx_update(PCIDevice *pdev)
 vfio_intx_eoi(>vbasedev);
 }
 
+static void vfio_intx_routing_notifier(PCIDevice *pdev)
+{
+VFIOPCIDevice *vdev = PCI_VFIO(pdev);
+PCIINTxRoute route;
+
+if (vdev->interrupt != VFIO_INT_INTx) {
+return;
+}
+
+route = pci_device_route_intx_to_irq(>pdev, vdev->intx.pin);
+
+if (pci_intx_route_changed(>intx.route, )) {
+vfio_intx_update(vdev, );
+}
+}
+
 static int vfio_intx_enable(VFIOPCIDevice *vdev, Error **errp)
 {
 uint8_t pin = vfio_pci_read_config(>pdev, PCI_INTERRUPT_PIN, 1);
@@ -2967,7 +2971,8 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
 if (vfio_pci_read_config(>pdev, PCI_INTERRUPT_PIN, 1)) {
 vdev->intx.mmap_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL,
   vfio_intx_mmap_enable, vdev);
-pci_device_set_intx_routing_notifier(>pdev, vfio_intx_update);
+pci_device_set_intx_routing_notifier(>pdev,
+ vfio_intx_routing_notifier);
 ret = vfio_intx_enable(vdev, errp);
 if (ret) {
 goto out_teardown;
-- 
2.23.0

[PULL 1/8] pseries: fix migration-test and pxe-test

[David Gibson]

From: Laurent Vivier 

Commit 29cb4187497d ("spapr: Set VSMT to smp_threads by default")
has introduced a new default value for VSMT that is not supported
by old kernels (before 4.13 kernel) and this breaks "make check"
on these kernels.

To fix that, explicitly set in the involved tests the value that was
used as the default value before the change.

Cc: Greg Kurz 
Signed-off-by: Laurent Vivier 
Message-Id: <20191120142539.236279-1-lviv...@redhat.com>
Acked-by: Thomas Huth 
Reviewed-by: Juan Quintela 
Tested-by: Greg Kurz 
Signed-off-by: David Gibson 
---
 tests/migration-test.c | 4 ++--
 tests/pxe-test.c   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/migration-test.c b/tests/migration-test.c
index ac780dffda..ebd77a581a 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -614,7 +614,7 @@ static int test_migrate_start(QTestState **from, QTestState 
**to,
 end_address = S390_TEST_MEM_END;
 } else if (strcmp(arch, "ppc64") == 0) {
 extra_opts = use_shmem ? get_shmem_opts("256M", shmem_path) : NULL;
-cmd_src = g_strdup_printf("-machine accel=%s -m 256M -nodefaults"
+cmd_src = g_strdup_printf("-machine accel=%s,vsmt=8 -m 256M 
-nodefaults"
   " -name source,debug-threads=on"
   " -serial file:%s/src_serial"
   " -prom-env 'use-nvramrc?=true' -prom-env "
@@ -623,7 +623,7 @@ static int test_migrate_start(QTestState **from, QTestState 
**to,
   "until' %s %s",  accel, tmpfs, end_address,
   start_address, extra_opts ? extra_opts : "",
   opts_src);
-cmd_dst = g_strdup_printf("-machine accel=%s -m 256M"
+cmd_dst = g_strdup_printf("-machine accel=%s,vsmt=8 -m 256M"
   " -name target,debug-threads=on"
   " -serial file:%s/dest_serial"
   " -incoming %s %s %s",
diff --git a/tests/pxe-test.c b/tests/pxe-test.c
index 948b0fbdc7..aaae54f755 100644
--- a/tests/pxe-test.c
+++ b/tests/pxe-test.c
@@ -46,15 +46,15 @@ static testdef_t x86_tests_slow[] = {
 
 static testdef_t ppc64_tests[] = {
 { "pseries", "spapr-vlan",
-  "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken" },
+  "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken,vsmt=8" },
 { "pseries", "virtio-net-pci",
-  "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken" },
+  "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken,vsmt=8" },
 { NULL },
 };
 
 static testdef_t ppc64_tests_slow[] = {
 { "pseries", "e1000",
-  "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken" },
+  "-machine cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken,vsmt=8" },
 { NULL },
 };
 
-- 
2.23.0

[PULL 6/8] spapr: Work around spurious warnings from vfio INTx initialization

[David Gibson]

Traditional PCI INTx for vfio devices can only perform well if using
an in-kernel irqchip.  Therefore, vfio_intx_update() issues a warning
if an in kernel irqchip is not available.

We usually do have an in-kernel irqchip available for pseries machines
on POWER hosts.  However, because the platform allows feature
negotiation of what interrupt controller model to use, we don't
currently initialize it until machine reset.  vfio_intx_update() is
called (first) from vfio_realize() before that, so it can issue a
spurious warning, even if we will have an in kernel irqchip by the
time we need it.

To workaround this, make a call to spapr_irq_update_active_intc() from
spapr_irq_init() which is called at machine realize time, before the
vfio realize.  This call will be pretty much obsoleted by the later
call at reset time, but it serves to suppress the spurious warning
from VFIO.

Cc: Alex Williamson 
Cc: Alexey Kardashevskiy 

Signed-off-by: David Gibson 
Reviewed-by: Cédric Le Goater 
Tested-by: Alex Williamson 
Reviewed-by: Alex Williamson 
Reviewed-by: Greg Kurz 
Acked-by: Alex Williamson 
---
 hw/ppc/spapr_irq.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index 1d27034962..d6bb7fd2d6 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -373,6 +373,14 @@ void spapr_irq_init(SpaprMachineState *spapr, Error **errp)
 
 spapr->qirqs = qemu_allocate_irqs(spapr_set_irq, spapr,
   smc->nr_xirqs + SPAPR_XIRQ_BASE);
+
+/*
+ * Mostly we don't actually need this until reset, except that not
+ * having this set up can cause VFIO devices to issue a
+ * false-positive warning during realize(), because they don't yet
+ * have an in-kernel irq chip.
+ */
+spapr_irq_update_active_intc(spapr);
 }
 
 int spapr_irq_claim(SpaprMachineState *spapr, int irq, bool lsi, Error **errp)
@@ -528,7 +536,8 @@ void spapr_irq_update_active_intc(SpaprMachineState *spapr)
  * this.
  */
 new_intc = SPAPR_INTC(spapr->xive);
-} else if (spapr_ovec_test(spapr->ov5_cas, OV5_XIVE_EXPLOIT)) {
+} else if (spapr->ov5_cas
+   && spapr_ovec_test(spapr->ov5_cas, OV5_XIVE_EXPLOIT)) {
 new_intc = SPAPR_INTC(spapr->xive);
 } else {
 new_intc = SPAPR_INTC(spapr->ics);
-- 
2.23.0

[PULL 2/8] kvm: Introduce KVM irqchip change notifier

[David Gibson]

Awareness of an in kernel irqchip is usually local to the machine and its
top-level interrupt controller.  However, in a few cases other things need
to know about it.  In particular vfio devices need this in order to
accelerate interrupt delivery.

If interrupt routing is changed, such devices may need to readjust their
connection to the KVM irqchip.  pci_bus_fire_intx_routing_notifier() exists
to do just this.

However, for the pseries machine type we have a situation where the routing
remains constant but the top-level irq chip itself is changed.  This occurs
because of PAPR feature negotiation which allows the guest to decide
between the older XICS and newer XIVE irq chip models (both of which are
paravirtualized).

To allow devices like vfio to adjust to this change, introduce a new
notifier for the purpose kvm_irqchip_change_notify().

Cc: Alex Williamson 
Cc: Alexey Kardashevskiy 

Signed-off-by: David Gibson 
Tested-by: Alex Williamson 
Reviewed-by: Alex Williamson 
Reviewed-by: Greg Kurz 
Acked-by: Alex Williamson 
---
 accel/kvm/kvm-all.c| 18 ++
 accel/stubs/kvm-stub.c | 12 
 include/sysemu/kvm.h   |  5 +
 3 files changed, 35 insertions(+)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 140b0bd8f6..ca00daa2f5 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -149,6 +149,9 @@ static const KVMCapabilityInfo kvm_required_capabilites[] = 
{
 KVM_CAP_LAST_INFO
 };
 
+static NotifierList kvm_irqchip_change_notifiers =
+NOTIFIER_LIST_INITIALIZER(kvm_irqchip_change_notifiers);
+
 #define kvm_slots_lock(kml)  qemu_mutex_lock(&(kml)->slots_lock)
 #define kvm_slots_unlock(kml)qemu_mutex_unlock(&(kml)->slots_lock)
 
@@ -1396,6 +1399,21 @@ void kvm_irqchip_release_virq(KVMState *s, int virq)
 trace_kvm_irqchip_release_virq(virq);
 }
 
+void kvm_irqchip_add_change_notifier(Notifier *n)
+{
+notifier_list_add(_irqchip_change_notifiers, n);
+}
+
+void kvm_irqchip_remove_change_notifier(Notifier *n)
+{
+notifier_remove(n);
+}
+
+void kvm_irqchip_change_notify(void)
+{
+notifier_list_notify(_irqchip_change_notifiers, NULL);
+}
+
 static unsigned int kvm_hash_msi(uint32_t data)
 {
 /* This is optimized for IA32 MSI layout. However, no other arch shall
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 6feb66ed80..82f118d2df 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -138,6 +138,18 @@ void kvm_irqchip_commit_routes(KVMState *s)
 {
 }
 
+void kvm_irqchip_add_change_notifier(Notifier *n)
+{
+}
+
+void kvm_irqchip_remove_change_notifier(Notifier *n)
+{
+}
+
+void kvm_irqchip_change_notify(void)
+{
+}
+
 int kvm_irqchip_add_adapter_route(KVMState *s, AdapterInfo *adapter)
 {
 return -ENOSYS;
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 9d143282bc..9fe233b9bf 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -201,6 +201,7 @@ typedef struct KVMCapabilityInfo {
 struct KVMState;
 typedef struct KVMState KVMState;
 extern KVMState *kvm_state;
+typedef struct Notifier Notifier;
 
 /* external API */
 
@@ -401,6 +402,10 @@ int kvm_irqchip_send_msi(KVMState *s, MSIMessage msg);
 
 void kvm_irqchip_add_irq_route(KVMState *s, int gsi, int irqchip, int pin);
 
+void kvm_irqchip_add_change_notifier(Notifier *n);
+void kvm_irqchip_remove_change_notifier(Notifier *n);
+void kvm_irqchip_change_notify(void);
+
 void kvm_get_apic_state(DeviceState *d, struct kvm_lapic_state *kapic);
 
 struct kvm_guest_debug;
-- 
2.23.0

[PULL 7/8] mos6522: update counters when timer interrupts are off

[David Gibson]

From: Laurent Vivier 

Even if the interrupts are off, counters must be updated because
they are running anyway and kernel can try to read them
(it's the case with g3beige kernel).

Reported-by: Andrew Randrianasulu 
Signed-off-by: Laurent Vivier 
Message-Id: <20191125141414.5015-1-laur...@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: David Gibson 
---
 hw/misc/mos6522.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
index aa3bfe1afd..cecf0be59e 100644
--- a/hw/misc/mos6522.c
+++ b/hw/misc/mos6522.c
@@ -113,6 +113,10 @@ static int64_t get_next_irq_time(MOS6522State *s, 
MOS6522Timer *ti,
 int64_t d, next_time;
 unsigned int counter;
 
+if (ti->frequency == 0) {
+return INT64_MAX;
+}
+
 /* current counter value */
 d = muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) - ti->load_time,
  ti->frequency, NANOSECONDS_PER_SECOND);
@@ -149,10 +153,10 @@ static void mos6522_timer1_update(MOS6522State *s, 
MOS6522Timer *ti,
 if (!ti->timer) {
 return;
 }
+ti->next_irq_time = get_next_irq_time(s, ti, current_time);
 if ((s->ier & T1_INT) == 0 || (s->acr & T1MODE) != T1MODE_CONT) {
 timer_del(ti->timer);
 } else {
-ti->next_irq_time = get_next_irq_time(s, ti, current_time);
 timer_mod(ti->timer, ti->next_irq_time);
 }
 }
@@ -163,10 +167,10 @@ static void mos6522_timer2_update(MOS6522State *s, 
MOS6522Timer *ti,
 if (!ti->timer) {
 return;
 }
+ti->next_irq_time = get_next_irq_time(s, ti, current_time);
 if ((s->ier & T2_INT) == 0) {
 timer_del(ti->timer);
 } else {
-ti->next_irq_time = get_next_irq_time(s, ti, current_time);
 timer_mod(ti->timer, ti->next_irq_time);
 }
 }
-- 
2.23.0

[PULL 5/8] spapr: Handle irq backend changes with VFIO PCI devices

[David Gibson]

pseries machine type can have one of two different interrupt controllers in
use depending on feature negotiation with the guest.  Usually this is
invisible to devices, because they route to a common set of qemu_irqs which
in turn dispatch to the correct back end.

VFIO passthrough devices, however, wire themselves up directly to the KVM
irqchip for performance, which means they are affected by this change in
interrupt controller.  To get them to adjust correctly for the change in
irqchip, we need to fire the kvm irqchip change notifier.

Cc: Alex Williamson 
Cc: Alexey Kardashevskiy 

Signed-off-by: David Gibson 
Reviewed-by: Cédric Le Goater 
Tested-by: Alex Williamson 
Reviewed-by: Alex Williamson 
Reviewed-by: Greg Kurz 
Acked-by: Alex Williamson 
---
 hw/ppc/spapr_irq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index 168044be85..1d27034962 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -508,6 +508,12 @@ static void set_active_intc(SpaprMachineState *spapr,
 }
 
 spapr->active_intc = new_intc;
+
+/*
+ * We've changed the kernel irqchip, let VFIO devices know they
+ * need to readjust.
+ */
+kvm_irqchip_change_notify();
 }
 
 void spapr_irq_update_active_intc(SpaprMachineState *spapr)
-- 
2.23.0

[PULL 8/8] ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue

[David Gibson]

From: PanNengyuan 

This fixes coverity issues 68911917:
360
CID 68911917: (NULL_RETURNS)
361. dereference: Dereferencing "source", which is known to be
 "NULL".
361if (source->mask & event_mask) {
362break;
363}

Reported-by: Euler Robot 
Signed-off-by: PanNengyuan 
Message-Id: <1574685291-38176-1-git-send-email-pannengy...@huawei.com>
Signed-off-by: David Gibson 
---
 hw/ppc/spapr_events.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
index 0e4c19523a..e355e000d0 100644
--- a/hw/ppc/spapr_events.c
+++ b/hw/ppc/spapr_events.c
@@ -358,6 +358,7 @@ static SpaprEventLogEntry 
*rtas_event_log_dequeue(SpaprMachineState *spapr,
 rtas_event_log_to_source(spapr,
  spapr_event_log_entry_type(entry));
 
+g_assert(source);
 if (source->mask & event_mask) {
 break;
 }
-- 
2.23.0

[PULL 4/8] vfio/pci: Respond to KVM irqchip change notifier

[David Gibson]

VFIO PCI devices already respond to the pci intx routing notifier, in order
to update kernel irqchip mappings when routing is updated.  However this
won't handle the case where the irqchip itself is replaced by a different
model while retaining the same routing.  This case can happen on
the pseries machine type due to PAPR feature negotiation.

To handle that case, add a handler for the irqchip change notifier, which
does much the same thing as the routing notifier, but is unconditional,
rather than being a no-op when the routing hasn't changed.

Cc: Alex Williamson 
Cc: Alexey Kardashevskiy 

Signed-off-by: David Gibson 
Tested-by: Alex Williamson 
Reviewed-by: Alex Williamson 
Reviewed-by: Greg Kurz 
Acked-by: Alex Williamson 
---
 hw/vfio/pci.c | 25 +++--
 hw/vfio/pci.h |  1 +
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 521289aa7d..2d40b396f2 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -256,6 +256,14 @@ static void vfio_intx_routing_notifier(PCIDevice *pdev)
 }
 }
 
+static void vfio_irqchip_change(Notifier *notify, void *data)
+{
+VFIOPCIDevice *vdev = container_of(notify, VFIOPCIDevice,
+   irqchip_change_notifier);
+
+vfio_intx_update(vdev, >intx.route);
+}
+
 static int vfio_intx_enable(VFIOPCIDevice *vdev, Error **errp)
 {
 uint8_t pin = vfio_pci_read_config(>pdev, PCI_INTERRUPT_PIN, 1);
@@ -2973,30 +2981,32 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
   vfio_intx_mmap_enable, vdev);
 pci_device_set_intx_routing_notifier(>pdev,
  vfio_intx_routing_notifier);
+vdev->irqchip_change_notifier.notify = vfio_irqchip_change;
+kvm_irqchip_add_change_notifier(>irqchip_change_notifier);
 ret = vfio_intx_enable(vdev, errp);
 if (ret) {
-goto out_teardown;
+goto out_deregister;
 }
 }
 
 if (vdev->display != ON_OFF_AUTO_OFF) {
 ret = vfio_display_probe(vdev, errp);
 if (ret) {
-goto out_teardown;
+goto out_deregister;
 }
 }
 if (vdev->enable_ramfb && vdev->dpy == NULL) {
 error_setg(errp, "ramfb=on requires display=on");
-goto out_teardown;
+goto out_deregister;
 }
 if (vdev->display_xres || vdev->display_yres) {
 if (vdev->dpy == NULL) {
 error_setg(errp, "xres and yres properties require display=on");
-goto out_teardown;
+goto out_deregister;
 }
 if (vdev->dpy->edid_regs == NULL) {
 error_setg(errp, "xres and yres properties need edid support");
-goto out_teardown;
+goto out_deregister;
 }
 }
 
@@ -3020,8 +3030,10 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
 
 return;
 
-out_teardown:
+out_deregister:
 pci_device_set_intx_routing_notifier(>pdev, NULL);
+kvm_irqchip_remove_change_notifier(>irqchip_change_notifier);
+out_teardown:
 vfio_teardown_msi(vdev);
 vfio_bars_exit(vdev);
 error:
@@ -3064,6 +3076,7 @@ static void vfio_exitfn(PCIDevice *pdev)
 vfio_unregister_req_notifier(vdev);
 vfio_unregister_err_notifier(vdev);
 pci_device_set_intx_routing_notifier(>pdev, NULL);
+kvm_irqchip_remove_change_notifier(>irqchip_change_notifier);
 vfio_disable_interrupts(vdev);
 if (vdev->intx.mmap_timer) {
 timer_free(vdev->intx.mmap_timer);
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index b329d50338..35626cd63e 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -169,6 +169,7 @@ typedef struct VFIOPCIDevice {
 bool enable_ramfb;
 VFIODisplay *dpy;
 Error *migration_blocker;
+Notifier irqchip_change_notifier;
 } VFIOPCIDevice;
 
 uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
-- 
2.23.0

[PULL 0/8] ppc-for-4.2 queue 20191126

[David Gibson]

The following changes since commit 65e05c82bdc6d348155e301c9d87dba7a08a5701:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2019-11-25 15:47:44 +)

are available in the Git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-4.2-20191126

for you to fetch changes up to 59d0533b85158fdbe43bad696d4f50ec29a04c32:

  ppc/spapr_events: fix potential NULL pointer dereference in 
rtas_event_log_dequeue (2019-11-26 10:12:58 +1100)


ppc patch queue for 2019-11-26

Here's the first 4.2 hard freeze pull request from me.  This has:

  * A fix for some testcases that cause errors on older host kernels
(e.g. RHEL7), with our new default configuration of VSMT mode
  * Changes to make VFIO devices interact properly with change of irq
chip caused by PAPR feature negotiation.  This is more involved
than I would like, but it's a problem in real use cases and I
can't see an easier way to handle it.
  * Fix an error with ms6522 counters for the g3beige machine
  * Fix a coverity warning


David Gibson (5):
  kvm: Introduce KVM irqchip change notifier
  vfio/pci: Split vfio_intx_update()
  vfio/pci: Respond to KVM irqchip change notifier
  spapr: Handle irq backend changes with VFIO PCI devices
  spapr: Work around spurious warnings from vfio INTx initialization

Laurent Vivier (2):
  pseries: fix migration-test and pxe-test
  mos6522: update counters when timer interrupts are off

PanNengyuan (1):
  ppc/spapr_events: fix potential NULL pointer dereference in 
rtas_event_log_dequeue

 accel/kvm/kvm-all.c| 18 ++
 accel/stubs/kvm-stub.c | 12 ++
 hw/misc/mos6522.c  |  8 +--
 hw/ppc/spapr_events.c  |  1 +
 hw/ppc/spapr_irq.c | 17 +-
 hw/vfio/pci.c  | 64 --
 hw/vfio/pci.h  |  1 +
 include/sysemu/kvm.h   |  5 
 tests/migration-test.c |  4 ++--
 tests/pxe-test.c   |  6 ++---
 10 files changed, 105 insertions(+), 31 deletions(-)

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

[Aleksandar Markovic]

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/
> +


I had a strange feeling that something is missing here, and I finally
realized what that was:

R: Sarah Harris 

https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04225.html



 CRIS TCG CPUs
>  M: Edgar E. Iglesias 
>  S: Maintained
> --
> 2.17.2 (Apple Git-113)
>
>

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

[Cleber Rosa]

- Original Message -
> From: "Aleksandar Markovic" 
> To: "Michael Rolnik" , "Cleber Rosa" , 
> "Eduardo Habkost" 
> Cc: qemu-devel@nongnu.org, "richard henderson" 
> , phi...@redhat.com, th...@redhat.com,
> dovga...@ispras.ru, imamm...@redhat.com
> Sent: Monday, November 25, 2019 6:49:40 PM
> Subject: Re: [PATCH v36 17/17] target/avr: Update MAINTAINERS file
> 
> 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, quite the contrary, I'd happy to be CC'd when such code
changes.

Thanks,
- Cleber.

> 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 
> 
> 
> 
> >  CRIS TCG CPUs
> >  M: Edgar E. Iglesias 
> >  S: Maintained
> > --
> > 2.17.2 (Apple Git-113)
> >
> >
> 

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

[Aleksandar Markovic]

On Sunday, November 24, 2019, 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 
> ---
>  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..ed9218af5f
> --- /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 

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

[Aleksandar Markovic]

On Sunday, November 24, 2019, 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.
>
>
Michael,

Please, in the next version, add or clean up licence preambles in ALL added
files. It looks the most suitable license for you is LPGL 2.1 with "or
later (at your option)" wording, like you already have in some (but not
all) files, but it is your choice. If possible, make it consistent
throughout the series. Sarah indicated to me she agreed with GPL-like
license, but she will certainly have the chance to speak up if something is
not right in her view. Don't misspell her name (as I did in one of my
responses). All this license thing is important so that one more item of
the series is resolved, and after that you don't need to think about it
anymore.

Regards,
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 if else if ...
> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any
> device
> 5. commenst about sample board and sample IO device added
> 6. sample board description is more descriptive now
> 7. memory_region_allocate_system_memory is used to create RAM
> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access
> registers
>
> changes since v10
> 1. movig back fullwr & fullrd into the commit where outb and inb were
> introduced
> 2. changing tlb_fill function signature
> 3. adding empty line between functions
> 4. adding newline on the last line of the file
> 5. using tb->flags to generae full access ST/LD instructions
> 6. fixing SBRC bug
> 7. folding back 10th commit
> 8. whenever a new file is introduced it's added to Makefile.objs
>
> changes since v11
> 1. updating to v2.7.0-rc
> 2. removing assignment to env->fullacc from gen_intermediate_code
>
> changes since v12
> 1. fixing spacing
> 2. fixing get/put_segment functions
> 3. removing target-avr/machine.h file
> 

Re: [PATCH v36 10/17] target/avr: Add instruction disassembly function

[Aleksandar Markovic]

On Sunday, November 24, 2019, Michael Rolnik  wrote:

> Provide function disassembles executed instruction when `-d in_asm` is
> provided
>
> Signed-off-by: Michael Rolnik 
> ---


Richard, is this what you expected from Michael, or there are still some
caveats?

Thanks for the suggestion!

Aleksandar

 target/avr/cpu.h   |   1 +
>  target/avr/cpu.c   |   2 +-
>  target/avr/disas.c | 214 +
>  target/avr/translate.c |  11 +++
>  4 files changed, 227 insertions(+), 1 deletion(-)
>  create mode 100644 target/avr/disas.c
>
> diff --git a/target/avr/cpu.h b/target/avr/cpu.h
> index ed9218af5f..574118beab 100644
> --- a/target/avr/cpu.h
> +++ b/target/avr/cpu.h
> @@ -157,6 +157,7 @@ bool avr_cpu_exec_interrupt(CPUState *cpu, int
> int_req);
>  hwaddr avr_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
>  int avr_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
>  int avr_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
> +int avr_print_insn(bfd_vma addr, disassemble_info *info);
>
>  static inline int avr_feature(CPUAVRState *env, int feature)
>  {
> diff --git a/target/avr/cpu.c b/target/avr/cpu.c
> index dae56d7845..52ec21dd16 100644
> --- a/target/avr/cpu.c
> +++ b/target/avr/cpu.c
> @@ -83,7 +83,7 @@ static void avr_cpu_reset(CPUState *cs)
>  static void avr_cpu_disas_set_info(CPUState *cpu, disassemble_info *info)
>  {
>  info->mach = bfd_arch_avr;
> -info->print_insn = NULL;
> +info->print_insn = avr_print_insn;
>  }
>
>  static void avr_cpu_realizefn(DeviceState *dev, Error **errp)
> diff --git a/target/avr/disas.c b/target/avr/disas.c
> new file mode 100644
> index 00..727fc463ce
> --- /dev/null
> +++ b/target/avr/disas.c
> @@ -0,0 +1,214 @@
> +/*
> + * OpenRISC disassembler
> + *
> + * Copyright (c) 2018 Richard Henderson 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "disas/dis-asm.h"
> +#include "qemu/bitops.h"
> +#include "cpu.h"
> +
> +typedef struct {
> +disassemble_info *info;
> +uint16_t next_word;
> +bool next_word_used;
> +} DisasContext;
> +
> +static int to_A(DisasContext *ctx, int indx) { return 16 + (indx % 16); }
> +static int to_B(DisasContext *ctx, int indx) { return 16 + (indx % 8); }
> +static int to_C(DisasContext *ctx, int indx) { return 24 + (indx % 4) *
> 2; }
> +static int to_D(DisasContext *ctx, int indx) { return (indx % 16) * 2; }
> +
> +static uint16_t next_word(DisasContext *ctx)
> +{
> +ctx->next_word_used = true;
> +return ctx->next_word;
> +}
> +
> +static int append_16(DisasContext *ctx, int x)
> +{
> +return x << 16 | next_word(ctx);
> +}
> +
> +
> +/* Include the auto-generated decoder.  */
> +static bool decode_insn(DisasContext *ctx, uint16_t insn);
> +#include "decode_insn.inc.c"
> +
> +#define output(mnemonic, format, ...) \
> +(pctx->info->fprintf_func(pctx->info->stream, "%-9s " format, \
> +mnemonic, ##__VA_ARGS__))
> +
> +int avr_print_insn(bfd_vma addr, disassemble_info *info)
> +{
> +DisasContext ctx;
> +DisasContext *pctx = 
> +bfd_byte buffer[4];
> +uint16_t insn;
> +int status;
> +
> +ctx.info = info;
> +
> +status = info->read_memory_func(addr, buffer, 4, info);
> +if (status != 0) {
> +info->memory_error_func(status, addr, info);
> +return -1;
> +}
> +insn = bfd_getl16(buffer);
> +ctx.next_word = bfd_getl16(buffer + 2);
> +ctx.next_word_used = false;
> +
> +if (!decode_insn(, insn)) {
> +output(".db", "0x%02x, 0x%02x", buffer[0], buffer[1]);
> +}
> +
> +return ctx.next_word_used ? 4 : 2;
> +}
> +
> +
> +#define INSN(opcode, format, ...)   \
> +static bool trans_##opcode(DisasContext *pctx, arg_##opcode * a)\
> +{   \
> +output(#opcode, format, ##__VA_ARGS__); \
> +return true;\
> +}
> +
> +#define INSN_MNEMONIC(opcode, mnemonic, format, ...)\
> +static bool trans_##opcode(DisasContext *pctx, arg_##opcode * a)\
> +{   \
> +output(mnemonic, 

Re: [PATCH v36 12/17] target/avr: Add example board configuration

[Aleksandar Markovic]

On Sunday, November 24, 2019, Michael Rolnik  wrote:

> A simple board setup that configures an AVR CPU to run a given firmware
> image.
> This is all that's useful to implement without peripheral emulation as AVR
> CPUs include a lot of on-board peripherals.
>
> NOTE: this is not a real board 
> NOTE: it's used for CPU testing
>
> Signed-off-by: Michael Rolnik 
> ---


Given the complexities of peripherals of AVR CPUs, in my opinion it would
be overly demanding to the submitters to require a real machine emulation
at this point of time. So:

Reviewed-by: Aleksandar Markovic 

Hopefully this will superceeded with a real board emulation in not so
distsnt future.

Philippe, do you have something to add?


>
> hw/avr/sample.c  | 282 +++
>  hw/Kconfig   |   1 +
>  hw/avr/Kconfig   |   6 +
>  hw/avr/Makefile.objs |   1 +
>  4 files changed, 290 insertions(+)
>  create mode 100644 hw/avr/sample.c
>  create mode 100644 hw/avr/Kconfig
>  create mode 100644 hw/avr/Makefile.objs
>
> diff --git a/hw/avr/sample.c b/hw/avr/sample.c
> new file mode 100644
> index 00..2295ec1b79
> --- /dev/null
> +++ b/hw/avr/sample.c
> @@ -0,0 +1,282 @@
> +/*
> + * 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 

Re: [PATCH v9 Kernel 2/5] vfio iommu: Add ioctl defination to get dirty pages bitmap.

[Yan Zhao]

On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
> On Fri, 15 Nov 2019 00:26:07 +0530
> Kirti Wankhede  wrote:
> 
> > On 11/14/2019 1:37 AM, Alex Williamson wrote:
> > > On Thu, 14 Nov 2019 01:07:21 +0530
> > > Kirti Wankhede  wrote:
> > >   
> > >> On 11/13/2019 4:00 AM, Alex Williamson wrote:  
> > >>> On Tue, 12 Nov 2019 22:33:37 +0530
> > >>> Kirti Wankhede  wrote:
> > >>>  
> >  All pages pinned by vendor driver through vfio_pin_pages API should be
> >  considered as dirty during migration. IOMMU container maintains a list 
> >  of
> >  all such pinned pages. Added an ioctl defination to get bitmap of such 
> >   
> > >>>
> > >>> definition
> > >>>  
> >  pinned pages for requested IO virtual address range.  
> > >>>
> > >>> Additionally, all mapped pages are considered dirty when physically
> > >>> mapped through to an IOMMU, modulo we discussed devices opting in to
> > >>> per page pinning to indicate finer granularity with a TBD mechanism to
> > >>> figure out if any non-opt-in devices remain.
> > >>>  
> > >>
> > >> You mean, in case of device direct assignment (device pass through)?  
> > > 
> > > Yes, or IOMMU backed mdevs.  If vfio_dmas in the container are fully
> > > pinned and mapped, then the correct dirty page set is all mapped pages.
> > > We discussed using the vpfn list as a mechanism for vendor drivers to
> > > reduce their migration footprint, but we also discussed that we would
> > > need a way to determine that all participants in the container have
> > > explicitly pinned their working pages or else we must consider the
> > > entire potential working set as dirty.
> > >   
> > 
> > How can vendor driver tell this capability to iommu module? Any suggestions?
> 
> I think it does so by pinning pages.  Is it acceptable that if the
> vendor driver pins any pages, then from that point forward we consider
> the IOMMU group dirty page scope to be limited to pinned pages?  There
we should also be aware of that dirty page scope is pinned pages + unpinned 
pages,
which means ever since a page is pinned, it should be regarded as dirty
no matter whether it's unpinned later. only after log_sync is called and
dirty info retrieved, its dirty state should be cleared.

> are complications around non-singleton IOMMU groups, but I think we're
> already leaning towards that being a non-worthwhile problem to solve.
> So if we require that only singleton IOMMU groups can pin pages and we
> pass the IOMMU group as a parameter to
> vfio_iommu_driver_ops.pin_pages(), then the type1 backend can set a
> flag on its local vfio_group struct to indicate dirty page scope is
> limited to pinned pages.  We might want to keep a flag on the
> vfio_iommu struct to indicate if all of the vfio_groups for each
> vfio_domain in the vfio_iommu.domain_list dirty page scope limited to
> pinned pages as an optimization to avoid walking lists too often.  Then
> we could test if vfio_iommu.domain_list is not empty and this new flag
> does not limit the dirty page scope, then everything within each
> vfio_dma is considered dirty.
>  
> >  Signed-off-by: Kirti Wankhede 
> >  Reviewed-by: Neo Jia 
> >  ---
> > include/uapi/linux/vfio.h | 23 +++
> > 1 file changed, 23 insertions(+)
> > 
> >  diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >  index 35b09427ad9f..6fd3822aa610 100644
> >  --- a/include/uapi/linux/vfio.h
> >  +++ b/include/uapi/linux/vfio.h
> >  @@ -902,6 +902,29 @@ struct vfio_iommu_type1_dma_unmap {
> > #define VFIO_IOMMU_ENABLE   _IO(VFIO_TYPE, VFIO_BASE + 15)
> > #define VFIO_IOMMU_DISABLE  _IO(VFIO_TYPE, VFIO_BASE + 16)
> > 
> >  +/**
> >  + * VFIO_IOMMU_GET_DIRTY_BITMAP - _IOWR(VFIO_TYPE, VFIO_BASE + 17,
> >  + * struct 
> >  vfio_iommu_type1_dirty_bitmap)
> >  + *
> >  + * IOCTL to get dirty pages bitmap for IOMMU container during 
> >  migration.
> >  + * Get dirty pages bitmap of given IO virtual addresses range using
> >  + * struct vfio_iommu_type1_dirty_bitmap. Caller sets argsz, which is 
> >  size of
> >  + * struct vfio_iommu_type1_dirty_bitmap. User should allocate memory 
> >  to get
> >  + * bitmap and should set size of allocated memory in bitmap_size 
> >  field.
> >  + * One bit is used to represent per page consecutively starting from 
> >  iova
> >  + * offset. Bit set indicates page at that offset from iova is dirty.
> >  + */
> >  +struct vfio_iommu_type1_dirty_bitmap {
> >  +  __u32argsz;
> >  +  __u32flags;
> >  +  __u64iova;  /* IO virtual address */
> >  +  __u64size;  /* Size of iova range */
> >  +  __u64bitmap_size;   /* in bytes */  
> > >>>
> > >>> This seems redundant.  We can 

Re: [QUESTION] What is the best license option for new files introduced in QEMU?

[Aleksandar Markovic]

On Monday, November 25, 2019, Eric Blake  wrote:

> On 11/25/19 1:25 PM, Aleksandar Markovic wrote:
>
> Thomas pointed to me that I mixed up GPL and LGPL - which is true.
>>
>> Still, the question remains with these options:
>>
>> * GPL 2.0
>>
>
> Not good. It artificially limits who can reuse this code.
>
> * GPL 2.0 + wording "or later (at your option)"
>>
>
> Matches what qemu itself uses, so fine; but makes it harder to reuse the
> code in a standalone library.
>
> * LGPL 2.1
>>
>
> Same problems as GPL2-only
>
> * LGPL 2.1 + wording "or later (at your option)"
>>
>
> Looser than qemu as a whole, has all the benefits of GPL2+ plus the
> additional benefit of being able to copy the code into other LGPL
> standalone libraries.
>
> It's also acceptable to use even looser licenses, like BSD 2-clause, but
> preferably only if that other license is already used by part of qemu (we
> don't need to make our mix even worse than it already is).
>
>
>> The context of my question is that I am reviewing a series that came
>> with files with different license preambles (or without it at all), and I
>> want to advice the submitters on the best option.
>>
>
> You may also want advice from lawyers, based on how you see your code
> being reused outside of qemu.  This list can offer advice, but it is
> non-binding and may not best fit your needs.
>
>
I truly appreciate your response!

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

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

[Aleksandar Markovic]

On Sunday, November 24, 2019, 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.
>
> 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
>
>
Michael,

Please do persist.

In next version, please add to the cover letter, right at this place:

1) An example of invoking QEMU for AVR, and doing some simple stuff with
such virtual machine

2) An example of debugging QEMU-powered AVR vurtual machine with GDB

3) (optional) Some other interesting example.

This is needed so that more people get interested in your series, try the
things out, convince themself in the value of this series (without digging
into individual patches searching fir examples).

Regards,
Aleksandar


> 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 if else if ...
> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any
> device
> 5. commenst about sample board and sample IO device added
> 6. sample board description is more descriptive now
> 7. memory_region_allocate_system_memory is used to create RAM
> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access
> registers
>
> changes since v10
> 1. movig back fullwr & fullrd into the commit where outb and inb were
> introduced
> 2. changing tlb_fill function signature
> 3. adding empty line between functions
> 4. adding newline on the last line of the file
> 5. using tb->flags to generae full access ST/LD instructions
> 6. fixing SBRC bug
> 7. folding back 10th commit
> 8. whenever a new file is introduced it's added to Makefile.objs
>
> changes since v11
> 1. updating to v2.7.0-rc
> 2. removing assignment to env->fullacc from gen_intermediate_code
>
> changes since v12
> 1. fixing spacing
> 2. fixing get/put_segment functions
> 3. removing target-avr/machine.h file
> 4. VMSTATE_SINGLE_TEST -> VMSTATE_SINGLE
> 5. comment spelling
> 6. removing hw/avr/sample_io.c
> 7. char const* -> const char*
> 8. proper ram allocation
> 

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

[Aleksandar Markovic]

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.

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 



>  CRIS TCG CPUs
>  M: Edgar E. Iglesias 
>  S: Maintained
> --
> 2.17.2 (Apple Git-113)
>
>

Re: [PATCH] mos6522: update counters when timer interrupts are off

[David Gibson]

On Mon, Nov 25, 2019 at 03:14:14PM +0100, Laurent Vivier wrote:
> Even if the interrupts are off, counters must be updated because
> they are running anyway and kernel can try to read them
> (it's the case with g3beige kernel).
> 
> Reported-by: Andrew Randrianasulu 
> Signed-off-by: Laurent Vivier 

Applied to ppc-for-4.2, thanks.

> ---
>  hw/misc/mos6522.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index aa3bfe1afd..cecf0be59e 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -113,6 +113,10 @@ static int64_t get_next_irq_time(MOS6522State *s, 
> MOS6522Timer *ti,
>  int64_t d, next_time;
>  unsigned int counter;
>  
> +if (ti->frequency == 0) {
> +return INT64_MAX;
> +}
> +
>  /* current counter value */
>  d = muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) - ti->load_time,
>   ti->frequency, NANOSECONDS_PER_SECOND);
> @@ -149,10 +153,10 @@ static void mos6522_timer1_update(MOS6522State *s, 
> MOS6522Timer *ti,
>  if (!ti->timer) {
>  return;
>  }
> +ti->next_irq_time = get_next_irq_time(s, ti, current_time);
>  if ((s->ier & T1_INT) == 0 || (s->acr & T1MODE) != T1MODE_CONT) {
>  timer_del(ti->timer);
>  } else {
> -ti->next_irq_time = get_next_irq_time(s, ti, current_time);
>  timer_mod(ti->timer, ti->next_irq_time);
>  }
>  }
> @@ -163,10 +167,10 @@ static void mos6522_timer2_update(MOS6522State *s, 
> MOS6522Timer *ti,
>  if (!ti->timer) {
>  return;
>  }
> +ti->next_irq_time = get_next_irq_time(s, ti, current_time);
>  if ((s->ier & T2_INT) == 0) {
>  timer_del(ti->timer);
>  } else {
> -ti->next_irq_time = get_next_irq_time(s, ti, current_time);
>  timer_mod(ti->timer, ti->next_irq_time);
>  }
>  }

-- 
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 V2] ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue

[David Gibson]

On Mon, Nov 25, 2019 at 08:34:51PM +0800, pannengy...@huawei.com wrote:
> From: PanNengyuan 
> 
> This fixes coverity issues 68911917:
> 360
> CID 68911917: (NULL_RETURNS)
> 361. dereference: Dereferencing "source", which is known to be
>  "NULL".
> 361if (source->mask & event_mask) {
> 362break;
> 363}
> 
> Reported-by: Euler Robot 
> Signed-off-by: PanNengyuan 

Applied to ppc-for-4.2, thanks.

> ---
>  hw/ppc/spapr_events.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> index 0e4c195..e355e00 100644
> --- a/hw/ppc/spapr_events.c
> +++ b/hw/ppc/spapr_events.c
> @@ -358,6 +358,7 @@ static SpaprEventLogEntry 
> *rtas_event_log_dequeue(SpaprMachineState *spapr,
>  rtas_event_log_to_source(spapr,
>   spapr_event_log_entry_type(entry));
>  
> +g_assert(source);
>  if (source->mask & event_mask) {
>  break;
>  }

-- 
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 v2 0/2] s390x/cpumodel: Introduce dynamic feature group

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191125172031.16282-1-da...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [PATCH v2 0/2] s390x/cpumodel: Introduce dynamic feature group
Type: series
Message-id: 20191125172031.16282-1-da...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Switched to a new branch 'test'
abb1bba s390x/cpumodel: Introduce dynamic feature groups
f8b362f s390x/cpumodel: Factor out CPU feature dependencies

=== OUTPUT BEGIN ===
1/2 Checking commit f8b362f40451 (s390x/cpumodel: Factor out CPU feature 
dependencies)
2/2 Checking commit abb1bba82287 (s390x/cpumodel: Introduce dynamic feature 
groups)
WARNING: line over 80 characters
#82: FILE: target/s390x/cpu_features.c:186:
+DYN_FEAT_GROUP_INIT("all-features", ALL, "Features valid for a CPU 
definition"),

ERROR: line over 90 characters
#84: FILE: target/s390x/cpu_features.c:188:
+DYN_FEAT_GROUP_INIT("recommended-features", RECOMMENDED, "Available, 
recommended features supported by the accelerator in the current host for a CPU 
definition"),

ERROR: line over 90 characters
#86: FILE: target/s390x/cpu_features.c:190:
+DYN_FEAT_GROUP_INIT("available-features", AVAILABLE, "Available features 
supported by the accelerator in the current host for a CPU definition"),

total: 2 errors, 1 warnings, 209 lines checked

Patch 2/2 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20191125172031.16282-1-da...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [EXTERNAL]Re: [PATCH v2 2/5] MAINTAINERS: Adjust maintainership for Fulong 2E board

[Philippe Mathieu-Daudé]

Hi Zoltan,

On 11/14/19 2:50 PM, Philippe Mathieu-Daudé wrote:

On 11/14/19 2:08 PM, chen huacai wrote:

Hi, all,

On Thu, Nov 14, 2019 at 8:34 PM Aleksandar Markovic
 wrote:


Hi, Philippe,


From: Philippe Mathieu-Daudé 

Hi Aleksandar,

On 11/13/19 2:47 PM, Aleksandar Markovic wrote:

From: Aleksandar Markovic 

Change the maintainership for Fulong 2E board to improve its quality.


IIRC you told me once this board is named Fuloong, and its CPU is a

‎> Loongson, both with 2x 'o' :) I have a patch renaming the various

occurrences.



I still think that the oficial name is "Fuloong 2E", however, it is
shortened to "Fulong 2E" quite often in communication, and, it seems,
sometimes even in various docs/app notes etc.

Can perhaps Huacai Chen enlighten us regarding the right spelling?

The right spelling is Fuloong.

[...]>>> The original author is active on the Linux kernel, let ask him 
if he'd

be OK to keep an eye on his work.

Huacai, would you agree to be listed as a reviewer on the Fuloong
related QEMU files? You don't have to worry about the generic QEMU code
plate (like keeping API up to date) I'll manage that, but I'd like to
have you listed to assert the hardware is properly modeled.

You would appear as:
R: Huacai Chen 



That is a great idea!

Please, Chen, get involved, you would be very welcomed, there is a place
for you in QEMU community!

I'm sorry that I'm busy now, but I think I will do something in QEMU
in the next year.


No problem, we'll keep in touch.


+R: Hervé Poussineau 


I don't think Hervé is interested by this board, he has not modified 
the

code.


+R: Aleksandar Markovic 
+S: Maintained


Let keep it as "Odd Fixes" :)



OK.


    Odd Fixes:   It has a maintainer but they don't have
 time to do much other than throw the odd
 patch in.


   F: hw/mips/mips_fulong2e.c
   F: hw/isa/vt82c686.c
   F: hw/pci-host/bonito.c



So the patch would be:

-- 8< --
   Fulong 2E
-M: Aleksandar Markovic 
-R: Aleksandar Rikalo 
+M: Philippe Mathieu-Daudé 
+R: Aleksandar Markovic 
+R: Huacai Chen 
   S: Odd Fixes
   F: hw/mips/mips_fulong2e.c
   F: hw/isa/vt82c686.c


Plus possible s/Fulong 2E/Fuloong 2E/


I'd prefer to keep this change for later, with the patch cleaning its 
use in the codebase (not that trivial because we need to alias the 
machine name to keep backward compatibility).





---

But let's wait to see what Huacai Chen thinks of it, before posting it.


Aleksandar, can you stay as co-maintainer?

The patch would be:

-- 8< --
    Fulong 2E
+M: Philippe Mathieu-Daudé 
  M: Aleksandar Markovic 
-R: Aleksandar Rikalo 


You are a prolific contributor of the Fuloong, are you OK to be listed 
as reviewer in this section?



    S: Odd Fixes
    F: hw/mips/mips_fulong2e.c
    F: hw/isa/vt82c686.c
---

Either this way, or if you prefer to be listed with a R-tag:
Acked-by: Philippe Mathieu-Daudé 

[PULL 1/1] vmstate-static-checker: Fix for current python

[Eduardo Habkost]

From: "Dr. David Alan Gilbert" 

Python 3.7.5 on f31 doesn't seem to like the old type=file syntax
on argparse.

Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20191121185303.51685-1-dgilb...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Cleber Rosa 
Signed-off-by: Eduardo Habkost 
---
 scripts/vmstate-static-checker.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/vmstate-static-checker.py 
b/scripts/vmstate-static-checker.py
index d3467288dc..f8b7b8f772 100755
--- a/scripts/vmstate-static-checker.py
+++ b/scripts/vmstate-static-checker.py
@@ -375,9 +375,11 @@ def main():
 help_text = "Parse JSON-formatted vmstate dumps from QEMU in files SRC and 
DEST.  Checks whether migration from SRC to DEST QEMU versions would break 
based on the VMSTATE information contained within the JSON outputs.  The JSON 
output is created from a QEMU invocation with the -dump-vmstate parameter and a 
filename argument to it.  Other parameters to QEMU do not matter, except the -M 
(machine type) parameter."
 
 parser = argparse.ArgumentParser(description=help_text)
-parser.add_argument('-s', '--src', type=file, required=True,
+parser.add_argument('-s', '--src', type=argparse.FileType('r'),
+required=True,
 help='json dump from src qemu')
-parser.add_argument('-d', '--dest', type=file, required=True,
+parser.add_argument('-d', '--dest', type=argparse.FileType('r'),
+required=True,
 help='json dump from dest qemu')
 parser.add_argument('--reverse', required=False, default=False,
 action='store_true',
-- 
2.23.0

[PULL 0/1] vmstate-static-checker fix for 4.2

[Eduardo Habkost]

The following changes since commit 65e05c82bdc6d348155e301c9d87dba7a08a5701:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2019-11-25 15:47:44 +)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/python-next-pull-request

for you to fetch changes up to e8d0ac5801edda91412e52fb82f291eed5171c2c:

  vmstate-static-checker: Fix for current python (2019-11-25 19:49:50 -0300)


vmstate-static-checker fix for 4.2



Dr. David Alan Gilbert (1):
  vmstate-static-checker: Fix for current python

 scripts/vmstate-static-checker.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.23.0

Re: [PATCH 0/2] Minor integer parsing improvements

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191125133846.27790-1-arm...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [PATCH 0/2] Minor integer parsing improvements
Type: series
Message-id: 20191125133846.27790-1-arm...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Switched to a new branch 'test'
f4a50eb test-keyval: Tighten test of trailing crap after size
1b74bc5 util/cutils: Turn FIXME comment into QEMU_BUILD_BUG_ON()

=== OUTPUT BEGIN ===
1/2 Checking commit 1b74bc5bc45a (util/cutils: Turn FIXME comment into 
QEMU_BUILD_BUG_ON())
ERROR: trailing whitespace
#35: FILE: util/cutils.c:523:
+QEMU_BUILD_BUG_ON(sizeof(int64_t) != sizeof(long long)); $

total: 1 errors, 0 warnings, 28 lines checked

Patch 1/2 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

2/2 Checking commit f4a50eb158af (test-keyval: Tighten test of trailing crap 
after size)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20191125133846.27790-1-arm...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [QUESTION] What is the best license option for new files introduced in QEMU?

[Eric Blake]

On 11/25/19 1:25 PM, Aleksandar Markovic wrote:


Thomas pointed to me that I mixed up GPL and LGPL - which is true.

Still, the question remains with these options:

* GPL 2.0


Not good. It artificially limits who can reuse this code.


* GPL 2.0 + wording "or later (at your option)"


Matches what qemu itself uses, so fine; but makes it harder to reuse the 
code in a standalone library.



* LGPL 2.1


Same problems as GPL2-only


* LGPL 2.1 + wording "or later (at your option)"


Looser than qemu as a whole, has all the benefits of GPL2+ plus the 
additional benefit of being able to copy the code into other LGPL 
standalone libraries.


It's also acceptable to use even looser licenses, like BSD 2-clause, but 
preferably only if that other license is already used by part of qemu 
(we don't need to make our mix even worse than it already is).




The context of my question is that I am reviewing a series that came
with files with different license preambles (or without it at all), and I
want to advice the submitters on the best option.


You may also want advice from lawyers, based on how you see your code 
being reused outside of qemu.  This list can offer advice, but it is 
non-binding and may not best fit your needs.


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

[PULL 2/2] hw/riscv: Add optional symbol callback ptr to riscv_load_kernel()

[Palmer Dabbelt]

From: "Zhuang, Siwei (Data61, Kensington NSW)" 

This patch adds an optional function pointer, "sym_cb", to
riscv_load_kernel() which provides the possibility to access the symbol
table during kernel loading.

The pointer is ignored, if supplied with Image or uImage file.

The Spike board requires the access to locate the HTIF symbols.

Fixes: 0ac24d56c5e7 ("hw/riscv: Split out the boot functions")
Buglink: https://bugs.launchpad.net/qemu/+bug/1835827
Signed-off-by: Siwei Zhuang 
Reviewed-by: Alistair Francis 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/boot.c | 7 ---
 hw/riscv/sifive_e.c | 2 +-
 hw/riscv/sifive_u.c | 3 ++-
 hw/riscv/spike.c| 6 +++---
 hw/riscv/virt.c | 3 ++-
 include/hw/riscv/boot.h | 3 ++-
 6 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index 7fee98d2f8..027303d2a3 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -114,12 +114,13 @@ target_ulong riscv_load_firmware(const char 
*firmware_filename,
 exit(1);
 }
 
-target_ulong riscv_load_kernel(const char *kernel_filename)
+target_ulong riscv_load_kernel(const char *kernel_filename, symbol_fn_t sym_cb)
 {
 uint64_t kernel_entry, kernel_high;
 
-if (load_elf(kernel_filename, NULL, NULL, NULL,
- _entry, NULL, _high, 0, EM_RISCV, 1, 0) > 0) {
+if (load_elf_ram_sym(kernel_filename, NULL, NULL, NULL,
+ _entry, NULL, _high, 0,
+ EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
 return kernel_entry;
 }
 
diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index 0f9d641a0e..8a6b0348df 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -111,7 +111,7 @@ static void riscv_sifive_e_init(MachineState *machine)
   memmap[SIFIVE_E_MROM].base, _space_memory);
 
 if (machine->kernel_filename) {
-riscv_load_kernel(machine->kernel_filename);
+riscv_load_kernel(machine->kernel_filename, NULL);
 }
 }
 
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 9552abf4dd..0140e95732 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -344,7 +344,8 @@ static void riscv_sifive_u_init(MachineState *machine)
  memmap[SIFIVE_U_DRAM].base);
 
 if (machine->kernel_filename) {
-uint64_t kernel_entry = riscv_load_kernel(machine->kernel_filename);
+uint64_t kernel_entry = riscv_load_kernel(machine->kernel_filename,
+  NULL);
 
 if (machine->initrd_filename) {
 hwaddr start;
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 8bbffbcd0f..8823681783 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -184,7 +184,7 @@ static void spike_board_init(MachineState *machine)
 mask_rom);
 
 if (machine->kernel_filename) {
-riscv_load_kernel(machine->kernel_filename);
+riscv_load_kernel(machine->kernel_filename, htif_symbol_callback);
 }
 
 /* reset vector */
@@ -273,7 +273,7 @@ static void spike_v1_10_0_board_init(MachineState *machine)
 mask_rom);
 
 if (machine->kernel_filename) {
-riscv_load_kernel(machine->kernel_filename);
+riscv_load_kernel(machine->kernel_filename, htif_symbol_callback);
 }
 
 /* reset vector */
@@ -359,7 +359,7 @@ static void spike_v1_09_1_board_init(MachineState *machine)
 mask_rom);
 
 if (machine->kernel_filename) {
-riscv_load_kernel(machine->kernel_filename);
+riscv_load_kernel(machine->kernel_filename, htif_symbol_callback);
 }
 
 /* reset vector */
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 74f2dce81c..c44b865959 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -479,7 +479,8 @@ static void riscv_virt_board_init(MachineState *machine)
  memmap[VIRT_DRAM].base);
 
 if (machine->kernel_filename) {
-uint64_t kernel_entry = riscv_load_kernel(machine->kernel_filename);
+uint64_t kernel_entry = riscv_load_kernel(machine->kernel_filename,
+  NULL);
 
 if (machine->initrd_filename) {
 hwaddr start;
diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index 66075d0e57..df80051fbc 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -28,7 +28,8 @@ void riscv_find_and_load_firmware(MachineState *machine,
 char *riscv_find_firmware(const char *firmware_filename);
 target_ulong riscv_load_firmware(const char *firmware_filename,
  hwaddr firmware_load_addr);
-target_ulong riscv_load_kernel(const char *kernel_filename);
+target_ulong riscv_load_kernel(const char *kernel_filename,
+   symbol_fn_t sym_cb);
 hwaddr riscv_load_initrd(const char *filename, uint64_t mem_size,
  

[PULL 1/2] RISC-V: virt: This is a "sifive,test1" test finisher

[Palmer Dabbelt]

From: Palmer Dabbelt 

The test finisher implements the reset command, which means it's a
"sifive,test1" device.  This is a backwards compatible change, so it's
also a "sifive,test0" device.  I copied the odd idiom for adding a
two-string compatible field from the ARM virt board.

Fixes: 9a2551ed6f ("riscv: sifive_test: Add reset functionality")
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt 
Reviewed-by: Alistair Francis 
Signed-off-by: Palmer Dabbelt 
---
 hw/riscv/virt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 23f340df19..74f2dce81c 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -359,7 +359,10 @@ static void create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
 nodename = g_strdup_printf("/test@%lx",
 (long)memmap[VIRT_TEST].base);
 qemu_fdt_add_subnode(fdt, nodename);
-qemu_fdt_setprop_string(fdt, nodename, "compatible", "sifive,test0");
+{
+const char compat[] = "sifive,test1\0sifive,test0";
+qemu_fdt_setprop(fdt, nodename, "compatible", compat, sizeof(compat));
+}
 qemu_fdt_setprop_cells(fdt, nodename, "reg",
 0x0, memmap[VIRT_TEST].base,
 0x0, memmap[VIRT_TEST].size);
-- 
2.24.0.432.g9d3f5f5b63-goog

[PULL] RISC-V Patches for 4.2-rc3

[Palmer Dabbelt]

The following changes since commit 65e05c82bdc6d348155e301c9d87dba7a08a5701:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2019-11-25 15:47:44 +)

are available in the Git repository at:

  g...@github.com:palmer-dabbelt/qemu.git tags/riscv-for-master-4.2-rc3

for you to fetch changes up to 6478dd745dca49d63250500cd1aeca1c41cd6f89:

  hw/riscv: Add optional symbol callback ptr to riscv_load_kernel() (2019-11-25 
12:34:52 -0800)


RISC-V Patches for 4.2-rc3

This tag contains two patches that I'd like to target for 4.2-rc3:

* A fix to the DT entry for the SiFive test finisher.
* A fix to the spike board's HTIF interface.

This passes "make check" and boots OE for me.


Palmer Dabbelt (1):
  RISC-V: virt: This is a "sifive,test1" test finisher

Zhuang, Siwei (Data61, Kensington NSW) (1):
  hw/riscv: Add optional symbol callback ptr to riscv_load_kernel()

 hw/riscv/boot.c | 7 ---
 hw/riscv/sifive_e.c | 2 +-
 hw/riscv/sifive_u.c | 3 ++-
 hw/riscv/spike.c| 6 +++---
 hw/riscv/virt.c | 8 ++--
 include/hw/riscv/boot.h | 3 ++-
 6 files changed, 18 insertions(+), 11 deletions(-)

Re: [PATCH] linux-user: Improve strace output for read() and getcwd()

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 9:40 PM Helge Deller  wrote:
>
> On 25.11.19 14:46, Aleksandar Markovic wrote:
> > On Sun, Nov 24, 2019 at 2:31 PM Aleksandar Markovic
> >  wrote:
> >>
> >>
> >>
> >> On Sunday, November 24, 2019, Helge Deller  wrote:
> >>>
> >>> On 24.11.19 13:10, Aleksandar Markovic wrote:
> 
> 
>  On Sunday, November 24, 2019, Helge Deller   > wrote:
> 
>  On 23.11.19 12:34, Aleksandar Markovic wrote:
>  > On Thursday, November 21, 2019, Helge Deller    >> 
>  wrote:
>  >
>  > The strace functionality in qemu-user lacks the possibility to 
>  trace
>  > which real values get returned to pointers in userspace by 
>  syscalls.
>  >
>  > For example, the read() and getcwd() syscalls currently only 
>  show the
>  > destination address where the syscalls should put the return 
>  values:
>  > 2532 read(3,0xff80038c,512) = 512
>  > 2532 getcwd(0x18180,4096) = 9
>  >
>  > With the patch below, one now can specify in 
>  print_syscall_late() which
>  > syscalls should be executed first, before they get printed.
>  > After adding the read() and getcwd() syscalls, we now get this 
>  output in
>  > with strace instead:
>  > 1708 
>  read(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)
>   = 512
>  > 1708 getcwd("/usr/bin",4096) = 9
>  >
>  > This patch adds just the framework with the respective 
>  implemenations for
>  > read() and getcwd(). If applied, more functions can be added 
>  easily later.
>  >
>  >
>  > Great out-of-the-box idea! However, there are some things that are
>  > not thought over yet. There is a good reason why strace happens
>  > "early": if something crash-like happens during syscall 
>  translation,
>  > we still have trace of original target syscall. In case of "late"
>  > flavor, we don't have anything. Another potentially problematic
>  > aspect is that end user certainly should know whether the trace was
>  > done "early" or "late" - otherwise, there will be, for certain, 
>  cases
>  > of misinterpretation / misleading / confusion of end users.
> 
>  Thanks for the feedback - I'm shortly sending a v2 version which
>  prints the syscall name with an open parenthesis, e.g. "read(" or 
>  "getcwd(",
>  before calling the syscall. That way you can see where it 
>  crashed/hangs...
> 
> 
>  ... but I cannot see passed arguments (for example, whether NULL is 
>  passed, or somrthing that looks like a real address)...
> >>>
> >>> Right.
> >>> And you won't see that in native strace either...
> >>> If you have an idea, just let me know.
> >>>
> >>
> >> Helge, I do have an idea how to amend your proposal that should give us, 
> >> believe it or not, "best of both worlds", but let's wait few days, I don't 
> >> have any dev setup ar hand at the moment to check it in action, and on top 
> >> of that I am swamped with other unrelated tasks. In the meantime, maybe 
> >> other guys will say something too, or perhaps you would have something new 
> >> as well.
> >>
> >> Still, by no means, I see this as a (potential) *huge* improvement of QEMU 
> >> strace. Thanks!
> >>
> >
> > Helge, Laurent,
> >
> > I don't have time to experiment, but I will write down here my
> > suggestion to extending Helge's system in a textual form, based on
> > example from prevous Helge's patches:
> >
> > 1. CURRENT STATE:
> >
> > early: read(3,0xff80038c,512)
> > late: = 512
> >
> > early: getcwd(0x18180,4096)
> > late: = 9
> >
> > 2. HELGE'S PROPOSAL 1:
> >
> > late: 
> > read(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)
> > = 512
> > late: getcwd("/usr/bin",4096) = 9
> >
> > 3. HELGE'S PROPOSAL 2:
> >
> > early: read
> > late: 
> > (3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)
> > = 512
> > early: getcwd
> > late: ("/usr/bin",4096) = 9
>
> My v2 patch actually includes the opening parenthesis in the early part:
> early: read(
> late: 
> 3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512) = 
> 512
>
> The open parenthesis should make it visible, that the call hasn't happened 
> yet.
>

Helge, with due respect, you are mixed up here. The purpose of QEMU
strace is to trace *target* syscalls, not *host* syscalls. Target
syscall read() happened.

> > 4. NEW PROPOSAL :
> >
> > early: read(3,0xff80038c,512)
> > late: = 512  
> > [(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)]
> > early: getcwd(0x18180,4096)
> > late: = 9  [("/usr/bin",4096)]
> >
> > In other words, we would print 

Re: [PATCH v2] linux-user/strace: Improve strace output for read() and getcwd()

[Helge Deller]

On 24.11.19 13:38, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/20191124115656.ga23...@ls3530.fritz.box/
> ...
> This series seems to have some coding style problems. See output below for
> more information:
>
> Subject: [PATCH v2] linux-user/strace: Improve strace output for read() and 
> getcwd()
> ...
> === OUTPUT BEGIN ===
> WARNING: line over 80 characters
> #51: FILE: linux-user/strace.c:64:
> +UNUSED static void print_encoded_string(abi_long addr, unsigned int maxlen, 
> int last);
>
> ERROR: storage class should be at the beginning of the declaration
> #51: FILE: linux-user/strace.c:64:
> +UNUSED static void print_encoded_string(abi_long addr, unsigned int maxlen, 
> int last);

IMHO the error is bogus.
This is the part of the patch:

diff --git a/linux-user/strace.c b/linux-user/strace.c
index de43238fa4..dc963accd5 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -61,6 +61,7 @@ UNUSED static void print_open_flags(abi_long, int);
 UNUSED static void print_syscall_prologue(const struct syscallname *);
 UNUSED static void print_syscall_epilogue(const struct syscallname *);
 UNUSED static void print_string(abi_long, int);
+UNUSED static void print_encoded_string(abi_long addr, unsigned int maxlen, 
int last);
 UNUSED static void print_buf(abi_long addr, abi_long len, int last);
 UNUSED static void print_raw_param(const char *, abi_long, int);
 UNUSED static void print_timeval(abi_ulong, int);

Maybe the warning is somewhat real, but *if* I should cut the line to
less than 80 chars, where should I break it?
E.g. like this?

+UNUSED static void print_encoded_string(abi_long addr, unsigned int maxlen,
+int last);
 UNUSED static void print_buf(abi_long addr, abi_long len, int last);

Helge

Re: [PATCH] linux-user: Improve strace output for read() and getcwd()

[Helge Deller]

On 25.11.19 14:46, Aleksandar Markovic wrote:
> On Sun, Nov 24, 2019 at 2:31 PM Aleksandar Markovic
>  wrote:
>>
>>
>>
>> On Sunday, November 24, 2019, Helge Deller  wrote:
>>>
>>> On 24.11.19 13:10, Aleksandar Markovic wrote:


 On Sunday, November 24, 2019, Helge Deller >>> > wrote:

 On 23.11.19 12:34, Aleksandar Markovic wrote:
 > On Thursday, November 21, 2019, Helge Deller >>>  >> 
 wrote:
 >
 > The strace functionality in qemu-user lacks the possibility to 
 trace
 > which real values get returned to pointers in userspace by 
 syscalls.
 >
 > For example, the read() and getcwd() syscalls currently only 
 show the
 > destination address where the syscalls should put the return 
 values:
 > 2532 read(3,0xff80038c,512) = 512
 > 2532 getcwd(0x18180,4096) = 9
 >
 > With the patch below, one now can specify in 
 print_syscall_late() which
 > syscalls should be executed first, before they get printed.
 > After adding the read() and getcwd() syscalls, we now get this 
 output in
 > with strace instead:
 > 1708 
 read(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)
  = 512
 > 1708 getcwd("/usr/bin",4096) = 9
 >
 > This patch adds just the framework with the respective 
 implemenations for
 > read() and getcwd(). If applied, more functions can be added 
 easily later.
 >
 >
 > Great out-of-the-box idea! However, there are some things that are
 > not thought over yet. There is a good reason why strace happens
 > "early": if something crash-like happens during syscall translation,
 > we still have trace of original target syscall. In case of "late"
 > flavor, we don't have anything. Another potentially problematic
 > aspect is that end user certainly should know whether the trace was
 > done "early" or "late" - otherwise, there will be, for certain, cases
 > of misinterpretation / misleading / confusion of end users.

 Thanks for the feedback - I'm shortly sending a v2 version which
 prints the syscall name with an open parenthesis, e.g. "read(" or 
 "getcwd(",
 before calling the syscall. That way you can see where it 
 crashed/hangs...


 ... but I cannot see passed arguments (for example, whether NULL is 
 passed, or somrthing that looks like a real address)...
>>>
>>> Right.
>>> And you won't see that in native strace either...
>>> If you have an idea, just let me know.
>>>
>>
>> Helge, I do have an idea how to amend your proposal that should give us, 
>> believe it or not, "best of both worlds", but let's wait few days, I don't 
>> have any dev setup ar hand at the moment to check it in action, and on top 
>> of that I am swamped with other unrelated tasks. In the meantime, maybe 
>> other guys will say something too, or perhaps you would have something new 
>> as well.
>>
>> Still, by no means, I see this as a (potential) *huge* improvement of QEMU 
>> strace. Thanks!
>>
>
> Helge, Laurent,
>
> I don't have time to experiment, but I will write down here my
> suggestion to extending Helge's system in a textual form, based on
> example from prevous Helge's patches:
>
> 1. CURRENT STATE:
>
> early: read(3,0xff80038c,512)
> late: = 512
>
> early: getcwd(0x18180,4096)
> late: = 9
>
> 2. HELGE'S PROPOSAL 1:
>
> late: 
> read(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)
> = 512
> late: getcwd("/usr/bin",4096) = 9
>
> 3. HELGE'S PROPOSAL 2:
>
> early: read
> late: 
> (3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)
> = 512
> early: getcwd
> late: ("/usr/bin",4096) = 9

My v2 patch actually includes the opening parenthesis in the early part:
early: read(
late: 3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512) 
= 512

The open parenthesis should make it visible, that the call hasn't happened yet.

> 4. NEW PROPOSAL :
>
> early: read(3,0xff80038c,512)
> late: = 512  
> [(3,"\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2bl\0\0\04"...,512)]
> early: getcwd(0x18180,4096)
> late: = 9  [("/usr/bin",4096)]
>
> In other words, we would print for (selected) system calls content of
> the parameters both before and after actual ioctl
> translation/execution.

I don't like this.
IMHO it just adds unnecessary noise and differs from what a native strace shows.

Helge


 >
 > Signed-off-by: Helge Deller >>>  >>
 >
 > diff --git a/linux-user/strace.c b/linux-user/strace.c
 > index de43238fa4..ff254732af 100644
 

[Bug 1853781] Re: Baremetal kernel built from assembly runs multiple times

[Evan Rysdam]

Ah, I've been missing out on a whole host of ARM instructions. I haven't
tried it yet, but I should be able to get it working from here. Thanks
so much for your help!

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

Title:
  Baremetal kernel built from assembly runs multiple times

Status in QEMU:
  Invalid

Bug description:
  QEMU version: 4.1.0.

  Full command used to launch: qemu-system-arm -machine raspi2 -kernel
  main

  (Technically, the first term of the command is actually
  "~/Applications/QEMU/qemu-4.1.0/build/arm-softmmu/qemu-system-arm",
  but I shortened it for readability.)

  Host information: Running debian 9.9 on a 64-bit x86 processor (Intel
  i5-2520M).

  Guest information: No operating system. I'm providing my own kernel,
  which I assembled from a 60-line ARM assembly program using arm-none-
  eabi-as and then linked with arm-none-eabi-ld, both version
  2.28-5+9+b3.

  Additional details: To view the screen output of the program, I am
  using vncviewer version 6.19.1115 (r42122). All of the above software
  packages were installed as debian packages using apt, except for QEMU,
  which I built from source after downloading from the official website.

  .

  The issue here is that I have written a program in assembly and it
  isn't doing what I expect it to when I emulate it. Here's a summary of
  the code:

  1) Read a number from zero-initialized memory.

  2) Add one to the number and write it back.

  3) Use the number to determine a screen location to write to.

  4) Use the number to determine what color to write.

  5) Write 4000 half-words to the screen starting at that offset and
  using that color. This should result in a stripe across the whole
  screen that's about 6 pixels tall.

  The expected behavior is that *one* stripe should appear on the screen
  in a single color. However, the actual behavior is that up to *four*
  stripes appear, each in a different color. Furthermore, if I comment
  out the line that writes the incremented counter back to memory, then
  only one stripe will appear.

  I will also note that the Raspberry Pi 2, which is the system I'm
  emulating, has four cores. What I suspect is going on here is that my
  code is being loaded onto all four cores of the emulated machine. I
  couldn't find anything about this anywhere in the documentation, and
  it strikes me as bug.

  I have attached the assmebly code that I'm using, as well as a short
  makefile. Since I can only add one attachment to this report, I've
  combined the two into a single text file and labeled each. After
  separating the two into two files, you will need to change the first
  line of the makefile to point to your installation of qemu-system-arm
  v4.1.0. After that, type "make run" to run the program.

  Thanks in advance,
  Evan Rysdam

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

[Bug 1853898] [NEW] qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(>queue)' failed.

[Tony Asleson]

Public bug reported:

While experimenting with blkdebug I can consistently hit this assertion
in lsi53c895a.c.

Using locally built from master, commit:
2061735ff09f9d5e67c501a96227b470e7de69b1

Steps to reproduce

$ qemu-img create -f raw empty.raw 8G
$ sudo losetup -f --show empty.raw
$ sudo mkfs.ext3 /dev/loop0
$ sudo losetup -D

$ cat blkdebug.conf 
[inject-error]
event = "read_aio"
errno = "5"

$ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic
user,ipv6=off,model=e1000,hostfwd=tcp::-:22,net=172.16.0.0/255.255.255.0
-device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678 -drive
if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw
-cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk

Initiate install from cdrom ISO image results in:

qemu-system-x86_64: /builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: 
lsi_soft_reset: Assertion `QTAILQ_EMPTY(>queue)' failed.
Aborted (core dumped)

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion
  `QTAILQ_EMPTY(>queue)' failed.

Status in QEMU:
  New

Bug description:
  While experimenting with blkdebug I can consistently hit this
  assertion in lsi53c895a.c.

  Using locally built from master, commit:
  2061735ff09f9d5e67c501a96227b470e7de69b1

  Steps to reproduce

  $ qemu-img create -f raw empty.raw 8G
  $ sudo losetup -f --show empty.raw
  $ sudo mkfs.ext3 /dev/loop0
  $ sudo losetup -D

  $ cat blkdebug.conf 
  [inject-error]
  event = "read_aio"
  errno = "5"

  $ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic
  user,ipv6=off,model=e1000,hostfwd=tcp::-:22,net=172.16.0.0/255.255.255.0
  -device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678
  -drive
  if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw
  -cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk

  Initiate install from cdrom ISO image results in:

  qemu-system-x86_64: 
/builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: lsi_soft_reset: 
Assertion `QTAILQ_EMPTY(>queue)' failed.
  Aborted (core dumped)

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

Re: [PATCH v4 21/37] sm501: make SerialMM a child, export chardev property

[Marc-André Lureau]

On Thu, Nov 21, 2019 at 6:04 PM Peter Maydell  wrote:
>
> On Wed, 20 Nov 2019 at 15:31, Marc-André Lureau
>  wrote:
> >
> > Embed the SerialMM sybus device, and re-export its "chardev" property.
> > That way, we can get rid of PROP_PTR "chr-state" and better track
> > devices relationship.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  hw/display/sm501.c | 33 -
> >  hw/sh4/r2d.c   |  2 +-
> >  2 files changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/display/sm501.c b/hw/display/sm501.c
> > index 1f33c87e65..c4445b28f9 100644
> > --- a/hw/display/sm501.c
> > +++ b/hw/display/sm501.c
> > @@ -1930,13 +1930,14 @@ typedef struct {
> >  SM501State state;
> >  uint32_t vram_size;
> >  uint32_t base;
> > -void *chr_state;
> > +SerialMM serial;
> >  } SM501SysBusState;
> >
> >  static void sm501_realize_sysbus(DeviceState *dev, Error **errp)
> >  {
> >  SM501SysBusState *s = SYSBUS_SM501(dev);
> >  SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
> > +SerialState *ss = >serial.serial;
> >  DeviceState *usb_dev;
> >
> >  sm501_init(>state, dev, s->vram_size);
> > @@ -1958,17 +1959,19 @@ static void sm501_realize_sysbus(DeviceState *dev, 
> > Error **errp)
> >  sysbus_pass_irq(sbd, SYS_BUS_DEVICE(usb_dev));
> >
> >  /* bridge to serial emulation module */
> > -if (s->chr_state) {
> > -serial_mm_init(>state.mmio_region, SM501_UART0, 2,
> > -   NULL, /* TODO : chain irq to IRL */
> > -   115200, s->chr_state, DEVICE_LITTLE_ENDIAN);
> > +/* FIXME: SM501_UART0 is always mapped, no need to check for the 
> > backend */
> > +if (qemu_chr_fe_backend_connected(>chr)) {
> > +MemoryRegion *mr;
> > +qdev_init_nofail(DEVICE(>serial));
> > +mr = sysbus_mmio_get_region(SYS_BUS_DEVICE(>serial), 0);
> > +memory_region_add_subregion(>state.mmio_region, SM501_UART0, 
> > mr);
> > +/* TODO : chain irq to IRL */
> >  }
>
> I don't really understand what the FIXME is trying to
> tell me here. If we don't need to check for the backend,
> why is the code checking for it ? It means we have to fish
> around inside the SerialMM's implementation, which seems odd.
> Only mapping the UART registers if there happens to be a backend
> connected also doesn't conceptually seem like the right behaviour,
> because the registers should always exist. Since commit
> 12051d82f004024d5d the chardev mid-layer has correctly handled
> the backend not being connected (ie having a NULL chardev),
> so there's no longer any need for board/device code to special
> case the lack of a chardev.

As you noted, this is addressed by "[PATCH-for-5.0] hw/display/sm501:
Always map the UART0".

It's preferable to keep those 2 seperate. I can include Philippe
change on top, or earlier in my series, is that ok?

>
> >  }
> >
> >  static Property sm501_sysbus_properties[] = {
> >  DEFINE_PROP_UINT32("vram-size", SM501SysBusState, vram_size, 0),
> >  DEFINE_PROP_UINT32("base", SM501SysBusState, base, 0),
> > -DEFINE_PROP_PTR("chr-state", SM501SysBusState, chr_state),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> >
> > @@ -1999,9 +2002,20 @@ static void sm501_sysbus_class_init(ObjectClass 
> > *klass, void *data)
> >  dc->props = sm501_sysbus_properties;
> >  dc->reset = sm501_reset_sysbus;
> >  dc->vmsd = _sm501_sysbus;
> > -/* Note: pointer property "chr-state" may remain null, thus
> > - * no need for dc->user_creatable = false;
> > - */
> > +}
> > +
> > +static void sm501_sysbus_init(Object *o)
> > +{
> > +SM501SysBusState *sm501 = SYSBUS_SM501(o);
> > +SerialMM *smm = >serial;
> > +
> > +sysbus_init_child_obj(o, "serial", smm, sizeof(SerialMM), 
> > TYPE_SERIAL_MM);
> > +qdev_set_legacy_instance_id(DEVICE(smm), SM501_UART0, 2);
>
> The only board we use the sm501 sysbus device is the sh4 r2d
> board, and we don't care about migration compatibility there
> (indeed I would be unsurprised to find that it doesn't even work ;-))
> So I think we can reasonably not set the legacy-instance-ID
> and just declare in the commit message that this is a migration
> compat break for that board.
>

I am simply adapting serial_mm_init() code from "serial: register vmsd
with DeviceClass" here.

Dropping qdev_set_legacy_instance_id() is proabably a seperate concern.

> > +qdev_prop_set_uint8(DEVICE(smm), "regshift", 2);
> > +qdev_prop_set_uint8(DEVICE(smm), "endianness", DEVICE_LITTLE_ENDIAN);
> > +
> > +object_property_add_alias(o, "chardev",
> > +  OBJECT(smm), "chardev", _abort);
> >  }
> >
> >  static const TypeInfo sm501_sysbus_info = {
> > @@ -2009,6 +2023,7 @@ static const TypeInfo sm501_sysbus_info = {
> >  .parent= TYPE_SYS_BUS_DEVICE,
> >  .instance_size = sizeof(SM501SysBusState),
> >  .class_init= sm501_sysbus_class_init,
> > +.instance_init = 

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

[Launchpad Bug Tracker]

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

---
mesa (19.2.4-1ubuntu1) focal; urgency=medium

  * Merge from Debian.
  * revert-set-full-thread-affinity.diff: Dropped, qemu is fixed now in
eoan and up. (LP: #1815889)

 -- Timo Aaltonen   Wed, 20 Nov 2019 20:17:00 +0200

** Changed in: mesa (Ubuntu)
   Status: In Progress => Fix Released

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

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

Status in Mesa:
  Won't Fix
Status in QEMU:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Invalid
Status in mesa source package in Disco:
  Fix Released
Status in mesa source package in Eoan:
  Won't Fix
Status in qemu source package in Eoan:
  Fix Released

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

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

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

Re: [QUESTION] What is the best license option for new files introduced in QEMU?

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 6:49 PM Aleksandar Markovic
 wrote:
>
> I read LICENSE file, but I read also recent contributions, and it is
> not clear to me what version of GPL is best/recommended for new file
> just being introduced to QEMU:
>
> * GPL 2.0
> * GPL 2.0 (or later at your option)
> * GPL 2.1
> * GPL 2.1 (or later at your option)
>

Thomas pointed to me that I mixed up GPL and LGPL - which is true.

Still, the question remains with these options:

* GPL 2.0
* GPL 2.0 + wording "or later (at your option)"
* LGPL 2.1
* LGPL 2.1 + wording "or later (at your option)"

The context of my question is that I am reviewing a series that came
with files with different license preambles (or without it at all), and I
want to advice the submitters on the best option.

Sincerely,
Aleksandar

> or something else. (The rest od wording of license preamble is clear
> to me.) Please somebody explsin snd clarify.
>
> Thanks,
> Aleksandar

Re: [PATCH v4 17/37] mips: inline serial_init()

[Marc-André Lureau]

Hi

On Mon, Nov 25, 2019 at 5:33 PM Aleksandar Markovic
 wrote:
>
>
>
> On Monday, November 25, 2019, Marc-André Lureau  
> wrote:
>>
>> Hi
>>
>> On Mon, Nov 25, 2019 at 2:12 PM Aleksandar Markovic
>>  wrote:
>> >
>> >
>> >
>> > On Wednesday, November 20, 2019, Marc-André Lureau 
>> >  wrote:
>> >>
>> >> The function is specific to mipssim, let's inline it.
>> >>
>> >> Signed-off-by: Marc-André Lureau 
>> >> ---
>> >>  hw/char/serial.c | 16 
>> >>  hw/mips/mips_mipssim.c   | 15 ---
>> >>  include/hw/char/serial.h |  2 --
>> >>  3 files changed, 12 insertions(+), 21 deletions(-)
>> >>
>> >> diff --git a/hw/char/serial.c b/hw/char/serial.c
>> >> index 164146ede8..23f0b02516 100644
>> >> --- a/hw/char/serial.c
>> >> +++ b/hw/char/serial.c
>> >> @@ -1023,22 +1023,6 @@ static const TypeInfo serial_io_info = {
>> >>  .class_init = serial_io_class_init,
>> >>  };
>> >>
>> >> -SerialIO *serial_init(int base, qemu_irq irq, int baudbase,
>> >> - Chardev *chr, MemoryRegion *system_io)
>> >> -{
>> >> -SerialIO *sio = SERIAL_IO(qdev_create(NULL, TYPE_SERIAL_IO));
>> >> -
>> >> -qdev_prop_set_uint32(DEVICE(sio), "baudbase", baudbase);
>> >> -qdev_prop_set_chr(DEVICE(sio), "chardev", chr);
>> >> -qdev_set_legacy_instance_id(DEVICE(sio), base, 2);
>> >> -qdev_init_nofail(DEVICE(sio));
>> >> -
>> >> -sysbus_connect_irq(SYS_BUS_DEVICE(sio), 0, irq);
>> >> -memory_region_add_subregion(system_io, base, >serial.io);
>> >> -
>> >> -return sio;
>> >> -}
>> >> -
>> >>  static Property serial_properties[] = {
>> >>  DEFINE_PROP_CHR("chardev", SerialState, chr),
>> >>  DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
>> >> diff --git a/hw/mips/mips_mipssim.c b/hw/mips/mips_mipssim.c
>> >> index 282bbecb24..bfafa4d7e9 100644
>> >> --- a/hw/mips/mips_mipssim.c
>> >> +++ b/hw/mips/mips_mipssim.c
>> >> @@ -40,6 +40,7 @@
>> >>  #include "hw/loader.h"
>> >>  #include "elf.h"
>> >>  #include "hw/sysbus.h"
>> >> +#include "hw/qdev-properties.h"
>> >>  #include "exec/address-spaces.h"
>> >>  #include "qemu/error-report.h"
>> >>  #include "sysemu/qtest.h"
>> >> @@ -219,9 +220,17 @@ mips_mipssim_init(MachineState *machine)
>> >>   * A single 16450 sits at offset 0x3f8. It is attached to
>> >>   * MIPS CPU INT2, which is interrupt 4.
>> >>   */
>> >> -if (serial_hd(0)) a
>> >> -serial_init(0x3f8, env->irq[4], 115200, serial_hd(0),
>> >> -get_system_io());
>> >> +if (serial_hd(0)) {
>> >> +DeviceState *dev = qdev_create(NULL, TYPE_SERIAL_IO);
>> >> +
>> >> +qdev_prop_set_uint32(DEVICE(dev), "baudbase", 115200);
>> >> +qdev_prop_set_chr(dev, "chardev", serial_hd(0));
>> >> +qdev_set_legacy_instance_id(dev, 0x3f8, 2);
>> >> +qdev_init_nofail(dev);
>> >> +sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, env->irq[4]);
>> >> +memory_region_add_subregion(get_system_io(), 0x3f8,
>> >> +_IO(dev)->serial.io);
>> >> +}
>> >
>> >
>> >
>> > Please explain why the code in the deleted function and the new function 
>> > are not identical. Why is the new code better?
>>
>> What differences do you spot?
>>
>> serial_init() looks very generic, but it is not, and this is
>> confusing. QDev users should call qdev_create().
>>
>> If there is a single user, it is better to inline the code where it is
>> being used, or move the function there.
>>
>
> Marc-Andre, you misunderstood me: I am not complaining about inlining at all, 
> I would do the same if I were you.
>
> I just see you expressed the same thing from former function in a slightly 
> different way in the inlined version, and they look functionally equivalent 
> to me. But I suppose the new way is better, and I want to know why. Is it a 
> more standard way, or something even more? Please understand that I don't 
> come from device emulation background - I want to learn a little bit about 
> device-related QEMU customs and conventions, that is all. :)
>
> For example,
>
> in old version:
>
> >> -SerialIO *serial_init(int base, qemu_irq irq, int baudbase,
> >> - Chardev *chr, MemoryRegion *system_io)
> >> -{
> >> -SerialIO *sio = SERIAL_IO(qdev_create(NULL, TYPE_SERIAL_IO));
> >> -
> >> -qdev_prop_set_uint32(DEVICE(sio), "baudbase", baudbase);
> >> -qdev_prop_set_chr(DEVICE(sio), "chardev", chr);
> >> -qdev_set_legacy_instance_id(DEVICE(sio), base, 2);
> >> -qdev_init_nofail(DEVICE(sio));
> >> -
> >> -sysbus_connect_irq(SYS_BUS_DEVICE(sio), 0, irq);
> >> -memory_region_add_subregion(system_io, base, >serial.io);
> >> -
> >> -return sio;
> >> -}
>
> in new version:
>
>  >> +if (serial_hd(0)) {
> >> +DeviceState *dev = qdev_create(NULL, TYPE_SERIAL_IO);
> >> +
> >> +qdev_prop_set_uint32(DEVICE(dev), "baudbase", 115200);
> >> +qdev_prop_set_chr(dev, "chardev", serial_hd(0));  

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

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 7:51 PM Thomas Huth  wrote:
>
> On 24/11/2019 16.17, Aleksandar Markovic wrote:
> >
> >
> > On Sunday, November 24, 2019, 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  > >
> > ---
> >  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.
> > + *
> >
> >
> > I think version 2 would be more fitting to QEMU ovarall license than 2.1
> > (see LICENCE file in QEMU root dir).
> >
> > Peter, am I right or wrong regarding GPL 2 vs. 2.1 (My interpretation is
> > that 2 is the best "default" for new files)? The wording in "LICENSE" is
> > frankly not entirely clear, and I see many new files using 2.1.
>
>  Hi Aleksandar,
>
> I think you mix up GPL and LGPL here. This file is licensed under the
> LGPL, so version 2.1 is perfectly fine here (see COPYING.LIB in the root
> directory). For the GPL, there was never a 2.1, so if it would be GPL,
> version 2 would be appropriate. Bit since it's LGPL, 2.1 is better indeed.
>

Thanks, Thomas. I already feel dizzy of this GPL/LGPL thing. :-)

If you find appropriate and feel comfortable about it, you can respond to
my general question on the lis too, where it is also obvious that I mixed up
GPL and LGPL:

https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg04179.html

Yours,
Aleksandar

>  Thomas
>

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 4:57 PM Sarah Harris  wrote:
>
> Hi Aleksandar,
>
> > - Is there a place in docs that explain its implementation in general?
> This implementation was based on the datasheet for the ATmega2560 
> ("ATmega640/1280/1281/2560/2561 datasheet" available from Microchip's 
> website).
> (I'm not sure if posting a URL will trigger any spam filters, so I'll leave 
> it for now)
> See section 22.10, "USART - Register Description".
>

OK.

> > - Why do cases 4, 5, 6 issue relatively unclear error message
> > ""update_char_mask(): Reserved character size "? Is there a
> > better wording perhaps? Where is justification in the doc for these
> > cases?
> The hardware can send/receive characters of various lengths, specified by 
> settings in these configuration registers.
> The cases are defined in table 22-7, "UCSZn Bits Settings", which specifies 
> that modes 4, 5, and 6 are reserved and should not be used.
> I'm not sure how better to explain this fault to the user; this is an edge 
> case that I'd expect only an AVR developer testing their own program to see, 
> so describing it in the same way as the datasheet seems a good idea.
>

OK. I somehow missed table 22-7 while comparing the code and specs - my bad.

> > - What would be the docs justification for case 7? Why is an error
> > message issued, but still "char_mask" is set, and I guess, further
> > processing will go on? Why the error message says "Nine bit character
> > requested"? Who said that (that *nine* bit characters were requested?
> > :-)
> Case 7 also comes from table 22-7, and specifies that the USART should 
> send/receive 9 bits per character.
> For characters <= 8 bits it's easy to pad them to the 8 bit bytes that the 
> character device subsystem operates on.
> For characters of 9 bits we'd have to throw away one bit, which seems like a 
> bad thing to do.
> I decided it wasn't enough to justify crashing, but the user should be made 
> aware that data is being lost and the output might not be what they would 
> otherwise expect.
>

Sarah, thanks for taking your tome to respond! Could you just explain
to me do we fully support what is said in:

* 22.6.2 Sending Frames with 9 Data Bit
* 22.7.2 Receiving Frames with 9 Data Bits

or perhaps there are some limitations?

And the same question for section:

* 22.9 Multi-processor Communication Mode

Please note that I don't suggest amending or extending your
implementation, I just want to understand it better.

Best regards,
Aleksandar


> Kind regards,
> Sarah Harris
>
>
> On Fri, 22 Nov 2019 16:10:02 +0100
> Aleksandar Markovic  wrote:
>
> > On Tue, Oct 29, 2019 at 10:25 PM Michael Rolnik  wrote:
> > >
> > > From: Sarah Harris 
> > >
> > > These were designed to facilitate testing but should provide enough 
> > > function to be useful in other contexts.
> > > Only a subset of the functions of each peripheral is implemented, mainly 
> > > due to the lack of a standard way to handle electrical connections (like 
> > > GPIO pins).
> > >
> > > Signed-off-by: Sarah Harris 
> > > ---
> > >  hw/char/Kconfig|   3 +
> > >  hw/char/Makefile.objs  |   1 +
> > >  hw/char/avr_usart.c| 324 ++
> > >  hw/misc/Kconfig|   3 +
> > >  hw/misc/Makefile.objs  |   2 +
> > >  hw/misc/avr_mask.c | 112 ++
> > >  hw/timer/Kconfig   |   3 +
> > >  hw/timer/Makefile.objs |   2 +
> > >  hw/timer/avr_timer16.c | 605 +
> > >  include/hw/char/avr_usart.h|  97 ++
> > >  include/hw/misc/avr_mask.h |  47 +++
> > >  include/hw/timer/avr_timer16.h |  97 ++
> > >  12 files changed, 1296 insertions(+)
> > >  create mode 100644 hw/char/avr_usart.c
> > >  create mode 100644 hw/misc/avr_mask.c
> > >  create mode 100644 hw/timer/avr_timer16.c
> > >  create mode 100644 include/hw/char/avr_usart.h
> > >  create mode 100644 include/hw/misc/avr_mask.h
> > >  create mode 100644 include/hw/timer/avr_timer16.h
> > >
> > > diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> > > index 40e7a8b8bb..331b20983f 100644
> > > --- a/hw/char/Kconfig
> > > +++ b/hw/char/Kconfig
> > > @@ -46,3 +46,6 @@ config SCLPCONSOLE
> > >
> > >  config TERMINAL3270
> > >  bool
> > > +
> > > +config AVR_USART
> > > +bool
> > > diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> > > index 02d8a66925..f05c1f5667 100644
> > > --- a/hw/char/Makefile.objs
> > > +++ b/hw/char/Makefile.objs
> > > @@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
> > >  obj-$(CONFIG_DIGIC) += digic-uart.o
> > >  obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
> > >  obj-$(CONFIG_RASPI) += bcm2835_aux.o
> > > +common-obj-$(CONFIG_AVR_USART) += avr_usart.o
> > >
> > >  common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
> > >  common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
> > > diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
> > > new file mode 100644
> > > index 

Re: QEMU Licensing query

[Michal Suchánek]

Hello,

On Fri, Nov 22, 2019 at 03:57:07PM +0530, karina filer wrote:
> Hi All,
> 
> [1]QEMU is used in Android Emulator and is licensed under [2]GPLv2.
> 
> For one of our customer support we may have to modify QEMU.
> 
>  I have below queries,
> 
>   * Case 1: No modification in QEMU (QEMU delivered by Google)
> 
> Is there any implications if we are not modifying and releasing QEMU
> externally, but we are sharing an Android image externally that runs on QEMU
> 
>  
> 
>   * Case 2: Modification in QEMU (QEMU delivered by Google)
> 
> What are the implications if we need to modify and release QEMU, considering
> that we will also have to release an Android image that will run on this
> QEMU.

First off, this is a question that you should ask your lawyer, not a
mailing list.

As far as GPL v2 obligations go you should provide the source to anybody
to whom you distribute binaries of a GPL v2 software.

The preferred way to provide the source is alongside the binary package.
However, if you use Google Play store this is not reasonable way of
distribution. I would suggest you provide a link in the application
description pointing to a website where users can download the sources.

Thanks

Michal

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

[Thomas Huth]

On 24/11/2019 16.17, Aleksandar Markovic wrote:
> 
> 
> On Sunday, November 24, 2019, 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  >
> ---
>  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.
> + *
> 
> 
> I think version 2 would be more fitting to QEMU ovarall license than 2.1
> (see LICENCE file in QEMU root dir).
> 
> Peter, am I right or wrong regarding GPL 2 vs. 2.1 (My interpretation is
> that 2 is the best "default" for new files)? The wording in "LICENSE" is
> frankly not entirely clear, and I see many new files using 2.1.

 Hi Aleksandar,

I think you mix up GPL and LGPL here. This file is licensed under the
LGPL, so version 2.1 is perfectly fine here (see COPYING.LIB in the root
directory). For the GPL, there was never a 2.1, so if it would be GPL,
version 2 would be appropriate. Bit since it's LGPL, 2.1 is better indeed.

 Thomas

virtiofsd: Where should it live?

[Dr. David Alan Gilbert]

Hi,
  There's been quite a bit of discussion about where virtiofsd, our
implemenation of a virtiofs daemon, should live.  I'd like to get
this settled now, because I'd like to tidy it up for the next
qemu cycle.

For reference it's based on qemu's livhost-user+chunks of libfuse.
It can't live in libfuse because we change enough of the library
to break their ABI.  It's C, and we've got ~100 patches - which
we can split into about 3 chunks.

Some suggestions so far:
  a) In contrib
 This is my current working assumption; the main objection is it's
 a bit big and pulls in a chunk of libfuse.

  b) In a submodule

  c) Just separate

Your suggestions/ideas please.  My preference is (a).

Dave

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

Re: API definition for LUKS key management [V2]

[Max Reitz]

On 22.11.19 15:22, Maxim Levitsky wrote:
> Hi!
> 
> This is the second version of the proposed QMP API for key management,
> after discussion with Keven and Max.
> 
> Will this work?
> 
> Adding Peter Krempa to CC, to hear his opinion from the 
> libvirt side.
> 
> Best regards,
>   Maxim Levitsky

Looks good to me overall.  I don’t think we need to overly push having
the same interface for create and amend, because I don’t see much to be
gained from it.

[...]

> diff --git a/qapi/crypto.json b/qapi/crypto.json
> index b2a4cff683..019db682cd 100644
> --- a/qapi/crypto.json
> +++ b/qapi/crypto.json
> @@ -309,3 +309,56 @@
>'base': 'QCryptoBlockInfoBase',
>'discriminator': 'format',
>'data': { 'luks': 'QCryptoBlockInfoLUKS' } }
> +
> +
> +##
> +# @LUKSKeyslotUpdate:
> +#
> +# @keyslot: If specified, will update only keyslot with this index
> +#
> +# @old-secret:  If specified, will only update keyslots that
> +#   can be opened with password which is contained in
> +#   QCryptoSecret with @old-secret ID
> +#
> +#   If neither @keyslot nor @old-secret is specified,
> +#   first empty keyslot is selected for the update
> +#
> +# @new-secret:  The ID of a QCryptoSecret object providing a new 
> decryption
> +#   key to place in all matching keyslots. Empty string 
> erases the
> +#   keyslot.

Hm...  Can’t we make this some string-or-null alternate type so that
null will erase the keyslot?  That would make more sense to me.

Max

> +# @iter-time:   number of milliseconds to spend in
> +#   PBKDF passphrase processing
> +##
> +{ 'struct': 'LUKSKeyslotUpdate',
> +  'data': {
> + '*keyslot': 'int',
> + '*old-secret': 'str',
> + 'new-secret' : 'str',
> + '*iter-time' : 'int' } }



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 4:56 PM Sarah Harris  wrote:
>
> Hi Aleksandar,
>
> I think returning immediately should be ok, it just happened to make sense to 
> me to think in terms of this being a special case of a normal read.
> The else handles the case in which no data has been received, but the user's 
> program reads the incoming buffer anyway.
> (As far as I'm aware this is undefined behaviour, so returning zero is 
> reasonable)
>

Since people were testing with the current code for some time, and
taking into account what Sarah just said, I suggest that we don't
change the code in question (leaving "data = 0;" line as is).

Thanks again,
Aleksandar

> Kind regards,
> Sarah Harris
>
>
> On Fri, 22 Nov 2019 17:48:56 +0100
> Aleksandar Markovic  wrote:
>
> > On Tue, Oct 29, 2019 at 10:25 PM Michael Rolnik  wrote:
> > >
> > > From: Sarah Harris 
> > >
> > > These were designed to facilitate testing but should provide enough 
> > > function to be useful in other contexts.
> > > Only a subset of the functions of each peripheral is implemented, mainly 
> > > due to the lack of a standard way to handle electrical connections (like 
> > > GPIO pins).
> > >
> > > Signed-off-by: Sarah Harris 
> > > ---
> > >  hw/char/Kconfig|   3 +
> > >  hw/char/Makefile.objs  |   1 +
> > >  hw/char/avr_usart.c| 324 ++
> > >  hw/misc/Kconfig|   3 +
> > >  hw/misc/Makefile.objs  |   2 +
> > >  hw/misc/avr_mask.c | 112 ++
> > >  hw/timer/Kconfig   |   3 +
> > >  hw/timer/Makefile.objs |   2 +
> > >  hw/timer/avr_timer16.c | 605 +
> > >  include/hw/char/avr_usart.h|  97 ++
> > >  include/hw/misc/avr_mask.h |  47 +++
> > >  include/hw/timer/avr_timer16.h |  97 ++
> > >  12 files changed, 1296 insertions(+)
> > >  create mode 100644 hw/char/avr_usart.c
> > >  create mode 100644 hw/misc/avr_mask.c
> > >  create mode 100644 hw/timer/avr_timer16.c
> > >  create mode 100644 include/hw/char/avr_usart.h
> > >  create mode 100644 include/hw/misc/avr_mask.h
> > >  create mode 100644 include/hw/timer/avr_timer16.h
> > >
> > > diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> > > index 40e7a8b8bb..331b20983f 100644
> > > --- a/hw/char/Kconfig
> > > +++ b/hw/char/Kconfig
> > > @@ -46,3 +46,6 @@ config SCLPCONSOLE
> > >
> > >  config TERMINAL3270
> > >  bool
> > > +
> > > +config AVR_USART
> > > +bool
> > > diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> > > index 02d8a66925..f05c1f5667 100644
> > > --- a/hw/char/Makefile.objs
> > > +++ b/hw/char/Makefile.objs
> > > @@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
> > >  obj-$(CONFIG_DIGIC) += digic-uart.o
> > >  obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
> > >  obj-$(CONFIG_RASPI) += bcm2835_aux.o
> > > +common-obj-$(CONFIG_AVR_USART) += avr_usart.o
> > >
> > >  common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
> > >  common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
> > > diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
> > > new file mode 100644
> > > index 00..9ca3c2a1cd
> > > --- /dev/null
> > > +++ b/hw/char/avr_usart.c
> > > @@ -0,0 +1,324 @@
> > > +/*
> > > + * AVR USART
> > > + *
> > > + * Copyright (c) 2018 University of Kent
> > > + * Author: Sarah Harris
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a copy
> > > + * of this software and associated documentation files (the "Software"), 
> > > to deal
> > > + * in the Software without restriction, including without limitation the 
> > > rights
> > > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> > > sell
> > > + * copies of the Software, and to permit persons to whom the Software is
> > > + * furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice shall be 
> > > included in
> > > + * all copies or substantial portions of the Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING FROM,
> > > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > DEALINGS IN
> > > + * THE SOFTWARE.
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "hw/char/avr_usart.h"
> > > +#include "qemu/log.h"
> > > +#include "hw/irq.h"
> > > +#include "hw/qdev-properties.h"
> > > +
> > > +static int avr_usart_can_receive(void *opaque)
> > > +{
> > > +AVRUsartState *usart = opaque;
> > > +
> > > +if (usart->data_valid || !(usart->csrb & 

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

[Aleksandar Markovic]

On Mon, Nov 25, 2019 at 4:07 PM Sarah Harris  wrote:
>
> Hi Aleksandar,
>
> In avr_usart_receive():
> The two assertions check that we get only what avr_usart_can_receive() asked 
> for.
> It always requests zero or one byte and I must have assumed zero bytes isn't 
> a valid read (so assert size==1).
> It only requests data when !usart->data_valid (so assert !usart->data_valid).
> (I think this is what Philippe already said)
>
> In avr_usart_read() and avr_usart_write():
> I assumed that accesses would only ever be a single byte at a time; I don't 
> think the AVR has any multi-byte memory access instructions.
> I wasn't convinced I understood QEMU's memory model in enough depth to be 
> certain of this so I left an assertion to document and check my assumption.
> Sorry for the lack of explanatory comments, I was thinking of this as test 
> code at the time so I wasn't being as thorough as I probably would have been 
> otherwise!
>
> All of these functions use existing QEMU APIs (the read and write functions 
> are passed via the MemoryRegionOps struct, the receive function is passed to 
> qemu_chr_fe_set_handlers), so the size parameters are required to match the 
> existing interfaces.
>
> Kind regards,
> Sarah Harris
>

Hello, Sarah.

I accept your explanation.

Michael, in my opinion, there is no need for any code change wrt
"assert(size==1)" topic. Sarah perhaps may add more applicable
comments surrounding mentioned functions in future, when she amends or
revises the code, but this is not crucial at all at this moment.

Thanks a lot, Sarah!

Aleksandar

>
> On Fri, 22 Nov 2019 15:41:03 +0100
> Aleksandar Markovic  wrote:
>
> > On Tue, Oct 29, 2019 at 10:25 PM Michael Rolnik  wrote:
> > >
> > > From: Sarah Harris 
> > >
> > > These were designed to facilitate testing but should provide enough 
> > > function to be useful in other contexts.
> > > Only a subset of the functions of each peripheral is implemented, mainly 
> > > due to the lack of a standard way to handle electrical connections (like 
> > > GPIO pins).
> > >
> > > Signed-off-by: Sarah Harris 
> > > ---
> > >  hw/char/Kconfig|   3 +
> > >  hw/char/Makefile.objs  |   1 +
> > >  hw/char/avr_usart.c| 324 ++
> > >  hw/misc/Kconfig|   3 +
> > >  hw/misc/Makefile.objs  |   2 +
> > >  hw/misc/avr_mask.c | 112 ++
> > >  hw/timer/Kconfig   |   3 +
> > >  hw/timer/Makefile.objs |   2 +
> > >  hw/timer/avr_timer16.c | 605 +
> > >  include/hw/char/avr_usart.h|  97 ++
> > >  include/hw/misc/avr_mask.h |  47 +++
> > >  include/hw/timer/avr_timer16.h |  97 ++
> > >  12 files changed, 1296 insertions(+)
> > >  create mode 100644 hw/char/avr_usart.c
> > >  create mode 100644 hw/misc/avr_mask.c
> > >  create mode 100644 hw/timer/avr_timer16.c
> > >  create mode 100644 include/hw/char/avr_usart.h
> > >  create mode 100644 include/hw/misc/avr_mask.h
> > >  create mode 100644 include/hw/timer/avr_timer16.h
> > >
> > > diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> > > index 40e7a8b8bb..331b20983f 100644
> > > --- a/hw/char/Kconfig
> > > +++ b/hw/char/Kconfig
> > > @@ -46,3 +46,6 @@ config SCLPCONSOLE
> > >
> > >  config TERMINAL3270
> > >  bool
> > > +
> > > +config AVR_USART
> > > +bool
> > > diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> > > index 02d8a66925..f05c1f5667 100644
> > > --- a/hw/char/Makefile.objs
> > > +++ b/hw/char/Makefile.objs
> > > @@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
> > >  obj-$(CONFIG_DIGIC) += digic-uart.o
> > >  obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
> > >  obj-$(CONFIG_RASPI) += bcm2835_aux.o
> > > +common-obj-$(CONFIG_AVR_USART) += avr_usart.o
> > >
> > >  common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
> > >  common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
> > > diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
> > > new file mode 100644
> > > index 00..9ca3c2a1cd
> > > --- /dev/null
> > > +++ b/hw/char/avr_usart.c
> > > @@ -0,0 +1,324 @@
> > > +/*
> > > + * AVR USART
> > > + *
> > > + * Copyright (c) 2018 University of Kent
> > > + * Author: Sarah Harris
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a copy
> > > + * of this software and associated documentation files (the "Software"), 
> > > to deal
> > > + * in the Software without restriction, including without limitation the 
> > > rights
> > > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> > > sell
> > > + * copies of the Software, and to permit persons to whom the Software is
> > > + * furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice shall be 
> > > included in
> > > + * all copies or substantial portions of the Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", 

Re: QEMU Licensing query

[karina filer]

Hi All,


QEMU  is used in Android Emulator and
is licensed under GPLv2
.

For one of our customer support we may have to modify QEMU.


 I have below queries,

   - *Case 1: No modification in QEMU *(QEMU delivered by Google)

Is there any implications if we are not modifying and releasing QEMU
externally, but we are sharing an Android image externally that runs on QEMU



   - *Case 2: Modification in QEMU *(QEMU delivered by Google)

What are the implications if we need to modify and release QEMU,
considering that we will also have to release an Android image that will
run on this QEMU.



Regards
Karina

On Fri, Nov 22, 2019 at 3:57 PM karina filer  wrote:

> Hi All,
>
>
> QEMU  is used in Android Emulator and
> is licensed under GPLv2
> .
>
> For one of our customer support we may have to modify QEMU.
>
>
>  I have below queries,
>
>- *Case 1: No modification in QEMU *(QEMU delivered by Google)
>
> Is there any implications if we are not modifying and releasing QEMU
> externally, but we are sharing an Android image externally that runs on QEMU
>
>
>
>- *Case 2: Modification in QEMU *(QEMU delivered by Google)
>
> What are the implications if we need to modify and release QEMU,
> considering that we will also have to release an Android image that will
> run on this QEMU.
>
>
>
> Regards
>
> Karina
>
>
>
>

[PATCH] target/i386: add two missing VMX features for Skylake and CascadeLake Server

[Paolo Bonzini]

They are present in client (Core) Skylake but pasted wrong into the server
SKUs.

Reported-by: Dr. David Alan Gilbert 
Signed-off-by: Paolo Bonzini 
---
 target/i386/cpu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 0f38c82903..3361fe0563 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2969,7 +2969,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
  VMX_SECONDARY_EXEC_APIC_REGISTER_VIRT |
  VMX_SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
  VMX_SECONDARY_EXEC_RDRAND_EXITING | 
VMX_SECONDARY_EXEC_ENABLE_INVPCID |
- VMX_SECONDARY_EXEC_ENABLE_VMFUNC | VMX_SECONDARY_EXEC_SHADOW_VMCS,
+ VMX_SECONDARY_EXEC_ENABLE_VMFUNC | VMX_SECONDARY_EXEC_SHADOW_VMCS 
|
+ VMX_SECONDARY_EXEC_RDSEED_EXITING | VMX_SECONDARY_EXEC_ENABLE_PML,
 .xlevel = 0x8008,
 .model_id = "Intel Xeon Processor (Skylake)",
 .versions = (X86CPUVersionDefinition[]) {
@@ -3085,7 +3086,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
  VMX_SECONDARY_EXEC_APIC_REGISTER_VIRT |
  VMX_SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
  VMX_SECONDARY_EXEC_RDRAND_EXITING | 
VMX_SECONDARY_EXEC_ENABLE_INVPCID |
- VMX_SECONDARY_EXEC_ENABLE_VMFUNC | VMX_SECONDARY_EXEC_SHADOW_VMCS,
+ VMX_SECONDARY_EXEC_ENABLE_VMFUNC | VMX_SECONDARY_EXEC_SHADOW_VMCS 
|
+ VMX_SECONDARY_EXEC_RDSEED_EXITING | VMX_SECONDARY_EXEC_ENABLE_PML,
 .xlevel = 0x8008,
 .model_id = "Intel Xeon Processor (Cascadelake)",
 .versions = (X86CPUVersionDefinition[]) {
-- 
2.21.0

Re: Avocado notes from KVM forum 2019

[Cleber Rosa]

On Mon, Nov 25, 2019 at 10:58:02AM -0300, Eduardo Habkost wrote:
> Thank you, Philippe, those are great ideas.  I have copied them
> to the Avocado+QEMU Trello board so we don't forget about them:
> https://trello.com/b/6Qi1pxVn/avocado-qemu
> 
> Additional comments below:
> 
> On Mon, Nov 25, 2019 at 01:35:13PM +0100, Philippe Mathieu-Daudé wrote:
> > Hi Cleber,
> > 
> > Here are my notes from talking about Avocado with various people during the
> > KVM forum in Lyon last month.
> > 
> > All comments are QEMU oriented.
> > 
> > 
> > 1) Working offline
> > 
> > Various people complained Avocado requires online access, and they would
> > like to use it offline.
> > 
> >   Maintainer workflow example is:
> > 
> >   - run avocado
> >   - hack QEMU, build
> >   - git pull
> >   - build
> >   - hack QEMU
> >   (go offline)
> >   - hack QEMU
> >   - build
> >   - run avocado <- FAILS
> > 
> 
> Ouch.  This shouldn't happen even with no explicit --offline
> option.  Failure to download artifacts shouldn't make tests
> report failure.
> 
>

Agreed.  There are a number of work items already to cover this.  One
is a more generic test metadata collection system:

   https://trello.com/c/lumR8u8Y/1526-rfc-nrunner-extended-metadata

We already have code that can find the required assets, and with that,
we can let the job (not the test) attempt to fulfill those
requirements, skipping the tests if they can not be fulfilled.

Until this is available, we can wrap the "fetch_asset()" calls and
cancel the test if it fails.

> > Failure is because mainstream added new tests, which got pulled in, and the
> > user only notice when running avocado again, but offline.
> > Test example is boot_linux_console.py, which added various tests from other
> > subsystems, so the maintainer has to disable the new tests manually to be
> > able to run his previous tests.
> > 
> > Expected solution: skip tests when artifact is not available, eventually
> > when the --offline option is used
> > 
> > 
> > 2) Add artifacts manually to the cache
> > 
> > Not all artifacts can be easily downloadable, some are public but require
> > the user to accept an End User License Agreement.
> > Users would like to share their tests with the documentation about where/how
> > to download the requisite files (accepting the EULA) to run the tests.
> > 
> > 
> > 2b) Add reference to artifact to the cache
> > 
> > Group of users might share group of files (like NFS storage) and would like
> > to use directly their remote read-only files, instead of copying it to their
> > home directory.
> 
> This sounds nice and useful, but I don't know how to make the
> interface for this usable.
> 
>

I guess this would require an Avocado installation-wide configuration
entry for the available cache directories.  IMO given that
configuration is applied, the tests should transparently find assets
in the configured locations.

> > 
> > 
> > 3) Provide qemu/avocado-qemu Python packages
> > 
> > The mainstream project uses Avocado to test QEMU. Others projects use QEMU
> > to test their code, and would like to automatize that using Avocado. They
> > usually not rebuild QEMU but use a stable binary from distributions. The
> > python classes are not available, so they have to clone QEMU to use Avocado
> > (I guess they only need 5 python files).
> > When running on Continuous Integration, this is overkill, because when you
> > clone QEMU you also clone various other submodules.
> 
> I only have one concern, here: I don't think we have the
> bandwidth to start maintaining a stable external Python API.
> Users of those packages will need to be aware that future
> versions of the modules might have incompatible APIs.
>

My understanding is that we would publish those files as a Python
module with versions matching QEMU.  No stability would be promised.
Users can always require a specific version of the Python module that
matches the QEMU version they expect/want to use.

> > 
> > 
> > 4) Warn the user when Avocado is too old for the tests
> > 
> > Some users tried Avocado following the examples on the mailing list and the
> > one in some commit's descriptions where we simply show "avocado run ...".
> 
> Oops.
>
> > They installed the distribution Avocado package and tried and it fails for
> > few of them with no obvious reason (the .log file is hard to read when you
> > are not custom to). IIUC their distribution provides a older Avocado (69?)
> > while we use recent features (72).
> > 
> > We never noticed it because we use 'make check-venv' and do not test the
> > distrib Avocado. While we can not test all distribs, we could add a version
> > test if the Avocado version is too old, display a friendly message to the
> > console (not the logfile).
> 
> Sounds like a good idea.
>

A simpler (complementary?) solution, or maybe just a good practice, is
to try to use in the examples:

  "./tests/venv/bin/avocado run ..."

Do you think this would be enough?  It would of course not cover the

Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements

[Marc Zyngier]

On 2019-11-25 17:27, Peter Maydell wrote:

On Mon, 25 Nov 2019 at 17:08, Marc Zyngier  wrote:


On 2019-11-25 16:21, Peter Maydell wrote:
> Missing .accessfn for ID_AA4PFR2_EL1_RESERVED ?

Indeed, I oversaw that one. I'll fix it and repost it together with
the extra patches to handle TID1 and TID2.


Given that rc3 (last chance, more or less, for bugfixes for 4.2)
is tomorrow, I propose that I take this patch with the
+  .accessfn = access_aa64idreg,
line for ID_AA64PFR2_EL1_RESERVED squashed in. I think
TID1/TID2 and the MMFR-from-aarch32 parts are less urgent ?


That'd be great, thank you.

TID2 is only a nice to have (it allows us to virtualize the cache
hierarchy, only a performance optimization for fairly stupid 32bit
guests), and TID1 is so far unused by Linux.

I also had a look at TID0, but couldn't find any of the Jazelle
stuff in QEMU...


> These are the AArch64 accessors for the aarch32 MVFR registers,
> but this trap bit is also supposed to trap aarch32 accesses to
> the MVFR registers, which are via the vmrs insn. That needs
> to be done in trans_VMSR_VMRS(); we can do that with a
> followup patch, since the mechanism there is completely different.

Holy cow! I'm afraid that my newly acquired QEMU-foo is missing
a few key options. Does it mean we need to generate a trapping
instruction, as opposed to take the exception on access?


We will need to generate a call to a helper function which
does the access check (and possibly raises an exception).
We can't determine at translate time whether the insn is
going to cause an exception, because the TID3 bit is not one
of the fairly limited set of information which we put into
the TB flags and allow to be baked into the generated code.
(In theory we could add it, but we don't have very many TB
flags so we only do that for cases where the overhead of doing
the check at runtime matters.)


Ah! I guess you're referring to the HELPER() stuff in the various
target/arm/*_helper.c files? If so, I think I see how to do it.

Thanks,

M.
--
Jazz is not dead. It just smells funny...

[QUESTION] What is the best license option for new files introduced in QEMU?

[Aleksandar Markovic]

I read LICENSE file, but I read also recent contributions, and it is
not clear to me what version of GPL is best/recommended for new file
just being introduced to QEMU:

* GPL 2.0
* GPL 2.0 (or later at your option)
* GPL 2.1
* GPL 2.1 (or later at your option)

or something else. (The rest od wording of license preamble is clear
to me.) Please somebody explsin snd clarify.

Thanks,
Aleksandar

[PATCH] block: always fill entire LUKS header space with zeros

[Daniel P . Berrangé]

When initializing the LUKS header the size with default encryption
parameters will currently be 2068480 bytes. This is rounded up to
a multiple of the cluster size, 2081792, with 64k sectors. If the
end of the header is not the same as the end of the cluster we fill
the extra space with zeros. This was forgetting that not even the
space allocated for the header will be fully initialized, as we
only write key material for the first key slot. The space left
for the other 7 slots is never written to.

An optimization to the ref count checking code:

  commit a5fff8d4b4d928311a5005efa12d0991fe3b66f9 (refs/bisect/bad)
  Author: Vladimir Sementsov-Ogievskiy 
  Date:   Wed Feb 27 16:14:30 2019 +0300

qcow2-refcount: avoid eating RAM

made the assumption that every cluster which was allocated would
have at least some data written to it. This was violated by way
the LUKS header is only partially written, with much space simply
reserved for future use.

Depending on the cluster size this problem was masked by the
logic which wrote zeros between the end of the LUKS header and
the end of the cluster.

$ qemu-img create --object secret,id=cluster_encrypt0,data=123456 \
   -f qcow2 -o cluster_size=2k,encrypt.iter-time=1,\
   encrypt.format=luks,encrypt.key-secret=cluster_encrypt0 \
   cluster_size_check.qcow2 100M
  Formatting 'cluster_size_check.qcow2', fmt=qcow2 size=104857600
encrypt.format=luks encrypt.key-secret=cluster_encrypt0
encrypt.iter-time=1 cluster_size=2048 lazy_refcounts=off refcount_bits=16

$ qemu-img check --object secret,id=cluster_encrypt0,data=redhat \
'json:{"driver": "qcow2", "encrypt.format": "luks", \
   "encrypt.key-secret": "cluster_encrypt0", \
   "file.driver": "file", "file.filename": "cluster_size_check.qcow2"}'
ERROR: counting reference for region exceeding the end of the file by one 
cluster or more: offset 0x2000 size 0x1f9000
Leaked cluster 4 refcount=1 reference=0
...snip...
Leaked cluster 130 refcount=1 reference=0

1 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.

127 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
Image end offset: 268288

The problem only exists when the disk image is entirely empty. Writing
data to the disk image payload will solve the problem by causing the
end of the file to be extended further.

The change fixes it by ensuring that the entire allocated LUKS header
region is fully initialized with zeros. The qemu-img check will still
fail for any pre-existing disk images created prior to this change,
unless at least 1 byte of the payload is written to.

Fully writing zeros to the entire LUKS header is a good idea regardless
as it ensures that space has been allocated on the host filesystem (or
whatever block storage backend is used).

Signed-off-by: Daniel P. Berrangé 
---
 block/qcow2.c  |   4 +-
 tests/qemu-iotests/278 |  88 +
 tests/qemu-iotests/278.out | 197 +
 tests/qemu-iotests/group   |   1 +
 4 files changed, 288 insertions(+), 2 deletions(-)
 create mode 100755 tests/qemu-iotests/278
 create mode 100644 tests/qemu-iotests/278.out

diff --git a/block/qcow2.c b/block/qcow2.c
index 7c18721741..dcfdd200fc 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -140,8 +140,8 @@ static ssize_t qcow2_crypto_hdr_init_func(QCryptoBlock 
*block, size_t headerlen,
 clusterlen = size_to_clusters(s, headerlen) * s->cluster_size;
 assert(qcow2_pre_write_overlap_check(bs, 0, ret, clusterlen, false) == 0);
 ret = bdrv_pwrite_zeroes(bs->file,
- ret + headerlen,
- clusterlen - headerlen, 0);
+ ret,
+ clusterlen, 0);
 if (ret < 0) {
 error_setg_errno(errp, -ret, "Could not zero fill encryption header");
 return -1;
diff --git a/tests/qemu-iotests/278 b/tests/qemu-iotests/278
new file mode 100755
index 00..c52f03dd52
--- /dev/null
+++ b/tests/qemu-iotests/278
@@ -0,0 +1,88 @@
+#!/usr/bin/env bash
+#
+# Test ref count checks on encrypted images
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=berra...@redhat.com
+
+seq=`basename $0`
+echo "QA output created 

Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements

[Peter Maydell]

On Mon, 25 Nov 2019 at 17:08, Marc Zyngier  wrote:
>
> On 2019-11-25 16:21, Peter Maydell wrote:
> > Missing .accessfn for ID_AA4PFR2_EL1_RESERVED ?
>
> Indeed, I oversaw that one. I'll fix it and repost it together with
> the extra patches to handle TID1 and TID2.

Given that rc3 (last chance, more or less, for bugfixes for 4.2)
is tomorrow, I propose that I take this patch with the
+  .accessfn = access_aa64idreg,
line for ID_AA64PFR2_EL1_RESERVED squashed in. I think
TID1/TID2 and the MMFR-from-aarch32 parts are less urgent ?

> > These are the AArch64 accessors for the aarch32 MVFR registers,
> > but this trap bit is also supposed to trap aarch32 accesses to
> > the MVFR registers, which are via the vmrs insn. That needs
> > to be done in trans_VMSR_VMRS(); we can do that with a
> > followup patch, since the mechanism there is completely different.
>
> Holy cow! I'm afraid that my newly acquired QEMU-foo is missing
> a few key options. Does it mean we need to generate a trapping
> instruction, as opposed to take the exception on access?

We will need to generate a call to a helper function which
does the access check (and possibly raises an exception).
We can't determine at translate time whether the insn is
going to cause an exception, because the TID3 bit is not one
of the fairly limited set of information which we put into
the TB flags and allow to be baked into the generated code.
(In theory we could add it, but we don't have very many TB
flags so we only do that for cases where the overhead of doing
the check at runtime matters.)

thanks
-- PMM

[PATCH v2 0/2] s390x/cpumodel: Introduce dynamic feature group

[David Hildenbrand]

This thread was previously called:
s390x/cpumodel: Introduce "best" model variants

There was recently a discussion regarding CPU model versions. That concept
does not fit s390x where we have a lot of feature variability. I
proposed an alternative approach in [1], which might work for x86 as well
(but I am not sure if x86 still can or wants to switch to that), and
requires only little changes in upper layers.

[1] and patch #2 contains more information on the motivation for this. It
allows, for example, to specify/expand "best feature set possible on this
accelerator, hw and, firmware"

"
Get the best possible feature set (e.g., excluding deprecated features)
for a CPU definition in the configuration
-cpu z14,all-features=off,recommended-features=on

Get the maximum possible feature set (e.g., including deprecated
features) for a CPU definition in the configuration ("everything that
could be enabled"):
-cpu z14,all-features=off,available-features=on

Get all valid features for a CPU definition:
-cpu z14,all-features=on
"

v1 -> v2:
- Use dynamic feature groups instead of new models

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg07222.html

Cc: Daniel P. Berrangé 
Cc: Markus Armbruster 
Cc: Jiri Denemark 
Cc: Eduardo Habkost 
Cc: Michael Mueller 
Cc: Peter Maydell 

David Hildenbrand (2):
  s390x/cpumodel: Factor out CPU feature dependencies
  s390x/cpumodel: Introduce dynamic feature groups

 target/s390x/cpu_features.c |  29 +
 target/s390x/cpu_features.h |  14 +++
 target/s390x/cpu_models.c   | 242 +++-
 3 files changed, 228 insertions(+), 57 deletions(-)

-- 
2.21.0

[PATCH v2 2/2] s390x/cpumodel: Introduce dynamic feature groups

[David Hildenbrand]

For a specific CPU model, we have a lot of feature variability depending on
- The microcode version of the HW
- The hypervisor we're running on (LPAR vs. KVM vs. z/VM)
- The hypervisor version we're running on
- The KVM version
- KVM module parameters (especially, "nested=1")
- The accelerator

Our default models are migration safe, however can only be changed
between QEMU releases (glued to QEMU machine). This somewhat collides
with the feature variability we have. E.g., the z13 model will not run
under TCG. There is the demand from higher levels in the stack to "have the
best CPU model possible on a given accelerator, firmware and HW", which
should especially include all features that fix security issues.
Especially, if we have a new feature due to a security flaw, we want to
have a way to backport this feature to older QEMU versions and a way to
automatically enable it when asked.

This is where dynamic CPU feature groups come into play. They allow to
first disable all features that would be enabled as default for a QEMU
machine, to then enable a dynamic set of features (depending on the
CPU definition, the accelerator, and the host).

Get the best possible feature set (e.g., excluding deprecated features) for
a CPU definition in the configuration
-cpu z14,all-features=off,recommended-features=on

Get the maximum possible feature set (e.g., including deprecated
features) for a CPU definition in the configuration ("everything that
could be enabled"):
-cpu z14,all-features=off,available-features=on

Get all valid features for a CPU definition:
-cpu z14,all-features=on

The idea of using feature flags for this use case instead of introducing
new models was brought up by Eduardo Habkost.

The best possible features will then, for example, include nested
virtualization ("SIE" feature) when KVM+HW support is enabled, or fixes via
microcode updates (e.g., spectre) - something we cannot have in the
default models of older QEMU machines.

As soon as dynamic feature groups are used, the CPU model becomes
migration-unsafe. Upper layers can expand these models to migration-safe
and static variants, allowing them to be migrated.

Signed-off-by: David Hildenbrand 
---
 target/s390x/cpu_features.c |  29 
 target/s390x/cpu_features.h |  14 
 target/s390x/cpu_models.c   | 127 
 3 files changed, 170 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 9f817e3cfa..77deabf375 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -166,6 +166,35 @@ void s390_feat_bitmap_to_ascii(const S390FeatBitmap 
features, void *opaque,
 };
 }
 
+#define DYN_FEAT_GROUP_INIT(_name, _group, _desc)\
+[S390_DYN_FEAT_GROUP_ ## _group] = { \
+.name = _name,   \
+.desc = _desc,   \
+}
+
+/*
+ * Dynamic feature groups can change between QEMU versions (or even for the
+ * same version on backports) and depend on the selected CPU definition. Most 
of
+ * them also depend on the selected accelerator and the host ("max" model). 
When
+ * used, they turn every model into a migration-unsafe model. Thus, they will
+ * never appear in expaneded CPU models.
+ *
+ * Indexed by dynamic feature group number.
+ */
+static S390DynFeatGroupDef s390_dyn_feature_groups[] = {
+/* "all" corresponds to our "full" definitions */
+DYN_FEAT_GROUP_INIT("all-features", ALL, "Features valid for a CPU 
definition"),
+/* "recommended" does not include deprecated features. */
+DYN_FEAT_GROUP_INIT("recommended-features", RECOMMENDED, "Available, 
recommended features supported by the accelerator in the current host for a CPU 
definition"),
+/* "available" includes deprecated features. */
+DYN_FEAT_GROUP_INIT("available-features", AVAILABLE, "Available features 
supported by the accelerator in the current host for a CPU definition"),
+};
+
+const S390DynFeatGroupDef *s390_dyn_feat_group_def(S390DynFeatGroup group)
+{
+return _dyn_feature_groups[group];
+}
+
 #define FEAT_GROUP_INIT(_name, _group, _desc)\
 {\
 .name = _name,   \
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index da695a8346..4a2f418cd3 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -76,7 +76,21 @@ typedef struct {
 S390FeatInit init;  /* used to init feat from generated data */
 } S390FeatGroupDef;
 
+/* Definition of a dynamic CPU feature group */
+typedef struct {
+const char *name;   /* name exposed to the user */
+const char *desc;   /* description exposed to the user */
+} S390DynFeatGroupDef;
+
+typedef enum {
+S390_DYN_FEAT_GROUP_ALL,
+S390_DYN_FEAT_GROUP_RECOMMENDED,
+S390_DYN_FEAT_GROUP_AVAILABLE,
+S390_DYN_FEAT_GROUP_MAX,
+} S390DynFeatGroup;
+
 const 

[PATCH v2 1/2] s390x/cpumodel: Factor out CPU feature dependencies

[David Hildenbrand]

Currently we check "if bit X is set, bit Y is required". We want
to perform "if bit Y is not set, bit X must also not be set" when
creating CPU models that will pass all consistency checks.

Signed-off-by: David Hildenbrand 
---
 target/s390x/cpu_models.c | 115 +++---
 1 file changed, 58 insertions(+), 57 deletions(-)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 7e92fb2e15..e6072fab43 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -88,6 +88,59 @@ static S390CPUDef s390_cpu_defs[] = {
 CPUDEF_INIT(0x8562, 15, 1, 47, 0x0800U, "gen15b", "IBM 8562 GA1"),
 };
 
+static const int cpu_feature_dependencies[][2] = {
+{ S390_FEAT_IPTE_RANGE, S390_FEAT_DAT_ENH },
+{ S390_FEAT_IDTE_SEGMENT, S390_FEAT_DAT_ENH },
+{ S390_FEAT_IDTE_REGION, S390_FEAT_DAT_ENH },
+{ S390_FEAT_IDTE_REGION, S390_FEAT_IDTE_SEGMENT },
+{ S390_FEAT_LOCAL_TLB_CLEARING, S390_FEAT_DAT_ENH},
+{ S390_FEAT_LONG_DISPLACEMENT_FAST, S390_FEAT_LONG_DISPLACEMENT },
+{ S390_FEAT_DFP_FAST, S390_FEAT_DFP },
+{ S390_FEAT_TRANSACTIONAL_EXE, S390_FEAT_STFLE_49 },
+{ S390_FEAT_EDAT_2, S390_FEAT_EDAT},
+{ S390_FEAT_MSA_EXT_5, S390_FEAT_KIMD_SHA_512 },
+{ S390_FEAT_MSA_EXT_5, S390_FEAT_KLMD_SHA_512 },
+{ S390_FEAT_MSA_EXT_4, S390_FEAT_MSA_EXT_3 },
+{ S390_FEAT_SIE_CMMA, S390_FEAT_CMM },
+{ S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
+{ S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
+{ S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
+{ S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },
+{ S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_4 },
+{ S390_FEAT_MULTIPLE_EPOCH, S390_FEAT_TOD_CLOCK_STEERING },
+{ S390_FEAT_VECTOR_PACKED_DECIMAL, S390_FEAT_VECTOR },
+{ S390_FEAT_VECTOR_ENH, S390_FEAT_VECTOR },
+{ S390_FEAT_INSTRUCTION_EXEC_PROT, S390_FEAT_SIDE_EFFECT_ACCESS_ESOP2 },
+{ S390_FEAT_SIDE_EFFECT_ACCESS_ESOP2, S390_FEAT_ESOP },
+{ S390_FEAT_CMM_NT, S390_FEAT_CMM },
+{ S390_FEAT_GUARDED_STORAGE, S390_FEAT_SIDE_EFFECT_ACCESS_ESOP2 },
+{ S390_FEAT_MULTIPLE_EPOCH, S390_FEAT_STORE_CLOCK_FAST },
+{ S390_FEAT_MULTIPLE_EPOCH, S390_FEAT_TOD_CLOCK_STEERING },
+{ S390_FEAT_SEMAPHORE_ASSIST, S390_FEAT_STFLE_49 },
+{ S390_FEAT_KIMD_SHA3_224, S390_FEAT_MSA },
+{ S390_FEAT_KIMD_SHA3_256, S390_FEAT_MSA },
+{ S390_FEAT_KIMD_SHA3_384, S390_FEAT_MSA },
+{ S390_FEAT_KIMD_SHA3_512, S390_FEAT_MSA },
+{ S390_FEAT_KIMD_SHAKE_128, S390_FEAT_MSA },
+{ S390_FEAT_KIMD_SHAKE_256, S390_FEAT_MSA },
+{ S390_FEAT_KLMD_SHA3_224, S390_FEAT_MSA },
+{ S390_FEAT_KLMD_SHA3_256, S390_FEAT_MSA },
+{ S390_FEAT_KLMD_SHA3_384, S390_FEAT_MSA },
+{ S390_FEAT_KLMD_SHA3_512, S390_FEAT_MSA },
+{ S390_FEAT_KLMD_SHAKE_128, S390_FEAT_MSA },
+{ S390_FEAT_KLMD_SHAKE_256, S390_FEAT_MSA },
+{ S390_FEAT_PRNO_TRNG_QRTCR, S390_FEAT_MSA_EXT_5 },
+{ S390_FEAT_PRNO_TRNG, S390_FEAT_MSA_EXT_5 },
+{ S390_FEAT_SIE_KSS, S390_FEAT_SIE_F2 },
+{ S390_FEAT_AP_QUERY_CONFIG_INFO, S390_FEAT_AP },
+{ S390_FEAT_AP_FACILITIES_TEST, S390_FEAT_AP },
+{ S390_FEAT_PTFF_QSIE, S390_FEAT_MULTIPLE_EPOCH },
+{ S390_FEAT_PTFF_QTOUE, S390_FEAT_MULTIPLE_EPOCH },
+{ S390_FEAT_PTFF_STOE, S390_FEAT_MULTIPLE_EPOCH },
+{ S390_FEAT_PTFF_STOUE, S390_FEAT_MULTIPLE_EPOCH },
+{ S390_FEAT_AP_QUEUE_INTERRUPT_CONTROL, S390_FEAT_AP },
+};
+
 #define QEMU_MAX_CPU_TYPE 0x2964
 #define QEMU_MAX_CPU_GEN 13
 #define QEMU_MAX_CPU_EC_GA 2
@@ -769,66 +822,14 @@ CpuModelBaselineInfo 
*qmp_query_cpu_model_baseline(CpuModelInfo *infoa,
 
 static void check_consistency(const S390CPUModel *model)
 {
-static int dep[][2] = {
-{ S390_FEAT_IPTE_RANGE, S390_FEAT_DAT_ENH },
-{ S390_FEAT_IDTE_SEGMENT, S390_FEAT_DAT_ENH },
-{ S390_FEAT_IDTE_REGION, S390_FEAT_DAT_ENH },
-{ S390_FEAT_IDTE_REGION, S390_FEAT_IDTE_SEGMENT },
-{ S390_FEAT_LOCAL_TLB_CLEARING, S390_FEAT_DAT_ENH},
-{ S390_FEAT_LONG_DISPLACEMENT_FAST, S390_FEAT_LONG_DISPLACEMENT },
-{ S390_FEAT_DFP_FAST, S390_FEAT_DFP },
-{ S390_FEAT_TRANSACTIONAL_EXE, S390_FEAT_STFLE_49 },
-{ S390_FEAT_EDAT_2, S390_FEAT_EDAT},
-{ S390_FEAT_MSA_EXT_5, S390_FEAT_KIMD_SHA_512 },
-{ S390_FEAT_MSA_EXT_5, S390_FEAT_KLMD_SHA_512 },
-{ S390_FEAT_MSA_EXT_4, S390_FEAT_MSA_EXT_3 },
-{ S390_FEAT_SIE_CMMA, S390_FEAT_CMM },
-{ S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
-{ S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
-{ S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
-{ S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },
-{ S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_4 },
-{ S390_FEAT_MULTIPLE_EPOCH, S390_FEAT_TOD_CLOCK_STEERING },
-{ S390_FEAT_VECTOR_PACKED_DECIMAL, S390_FEAT_VECTOR },
-{ S390_FEAT_VECTOR_ENH, S390_FEAT_VECTOR },
-{ S390_FEAT_INSTRUCTION_EXEC_PROT, S390_FEAT_SIDE_EFFECT_ACCESS_ESOP2 
},
-{ 

Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements

[Marc Zyngier]

On 2019-11-25 16:21, Peter Maydell wrote:

On Sat, 23 Nov 2019 at 11:56, Marc Zyngier  wrote:


HCR_EL2.TID3 mandates that access from EL1 to a long list of id
registers traps to EL2, and QEMU has so far ignored this 
requirement.


This breaks (among other things) KVM guests that have PtrAuth 
enabled,
while the hypervisor doesn't want to expose the feature to its 
guest.
To achieve this, KVM traps the ID registers (ID_AA64ISAR1_EL1 in 
this

case), and masks out the unsupported feature.

QEMU not honoring the trap request means that the guest observes
that the feature is present in the HW, starts using it, and dies
a horrible death when KVM injects an UNDEF, because the feature
*really* isn't supported.

Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set.

Reported-by: Will Deacon 
Signed-off-by: Marc Zyngier 
---
There is a number of other trap bits missing (TID[0-2], for 
example),

but this at least gets a mainline Linux going with cpu=max.


I guess this ought to go into 4.2, given that it gets recent
Linux guest kernels to work.


@@ -6185,11 +6221,13 @@ void register_cp_regs_for_features(ARMCPU 
*cpu)
 { .name = "ID_AA64PFR0_EL1", .state = 
ARM_CP_STATE_AA64,

   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 0,
   .access = PL1_R, .type = ARM_CP_NO_RAW,
+  .accessfn = access_aa64idreg,
   .readfn = id_aa64pfr0_read,
   .writefn = arm_cp_write_ignore },
 { .name = "ID_AA64PFR1_EL1", .state = 
ARM_CP_STATE_AA64,

   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 1,
   .access = PL1_R, .type = ARM_CP_CONST,
+  .accessfn = access_aa64idreg,
   .resetvalue = cpu->isar.id_aa64pfr1},
 { .name = "ID_AA64PFR2_EL1_RESERVED", .state = 
ARM_CP_STATE_AA64,

   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 2,
@@ -6198,151 +6236,188 @@ void register_cp_regs_for_features(ARMCPU 
*cpu)
 { .name = "ID_AA64PFR3_EL1_RESERVED", .state = 
ARM_CP_STATE_AA64,

   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 3,
   .access = PL1_R, .type = ARM_CP_CONST,
+  .accessfn = access_aa64idreg,
   .resetvalue = 0 },


Missing .accessfn for ID_AA4PFR2_EL1_RESERVED ?


Indeed, I oversaw that one. I'll fix it and repost it together with
the extra patches to handle TID1 and TID2.



 { .name = "ID_AA64ZFR0_EL1", .state = 
ARM_CP_STATE_AA64,

   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 4,
   .access = PL1_R, .type = ARM_CP_CONST,
+  .accessfn = access_aa64idreg,
   /* At present, only SVEver == 0 is defined anyway.  
*/

   .resetvalue = 0 },



 { .name = "MVFR0_EL1", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 0,
   .access = PL1_R, .type = ARM_CP_CONST,
+  .accessfn = access_aa64idreg,
   .resetvalue = cpu->isar.mvfr0 },


These are the AArch64 accessors for the aarch32 MVFR registers,
but this trap bit is also supposed to trap aarch32 accesses to
the MVFR registers, which are via the vmrs insn. That needs
to be done in trans_VMSR_VMRS(); we can do that with a
followup patch, since the mechanism there is completely different.


Holy cow! I'm afraid that my newly acquired QEMU-foo is missing
a few key options. Does it mean we need to generate a trapping
instruction, as opposed to take the exception on access?

I'd very much appreciate some guidance here.

Thanks,

M.
--
Jazz is not dead. It just smells funny...

Re: [PATCH for-4.2 2/2] i386: Add -noTSX aliases for hle=off, rtm=off CPU models

[Kashyap Chamarthy]

On Mon, Nov 25, 2019 at 11:21:10AM -0300, Eduardo Habkost wrote:
> On Thu, Nov 21, 2019 at 03:12:45PM +0100, Kashyap Chamarthy wrote:
> > On Wed, Nov 20, 2019 at 01:49:12PM -0300, Eduardo Habkost wrote:

[...]

> > - - -
> > 
> > Should we (can do it, if you already don't have a patch WIP for it)
> > also update this file to reflect this?
> > https://git.qemu.org/?p=qemu.git;a=blob;f=docs/qemu-cpu-models.texi
> 
> Yes, we should.  Thanks for the reminder!
> 
> > 
> > While at it ... I wonder if it's worth making a separte doc
> > (versioned-cpu-models.rst) explaining the versioned CPU models, usage,
> > etc.
> > 
> > There was a very useful discussion between you and Dan Berrangé on this
> > list (Message-Id: <20190625050008.12789-5-ehabk...@redhat.com>, the
> > first version of the thread: "[PATCH 4/6] i386: Infrastructure for
> > versioned CPU models").  Could potentially incorporate some of that
> > content.
> > 
> 
> We should, but I don't think I can do it in time for QEMU 4.2.

It's okay; that can wait for post-4.2.

[...]

-- 
/kashyap

Re: [virtio-dev] Re: guest / host buffer sharing ...

[Liam Girdwood]

On Wed, 2019-11-20 at 10:53 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > > DSP FW has no access to userspace so we would need some
> > > > additional
> > > > API
> > > > on top of DMA_BUF_SET_NAME etc to get physical hardware pages ?
> > > 
> > > The dma-buf api currently can share guest memory sg-lists.
> > 
> > Ok, IIUC buffers can either be shared using the GPU proposed APIs
> > (above) or using the dma-buf API to share via userspace ? My
> > preference
> > would be to use teh more direct GPU APIs sending physical page
> > addresses from Guest to device driver. I guess this is your use
> > case
> > too ?
> 
> I'm not convinced this is useful for audio ...
> 
> I basically see two modes of operation which are useful:
> 
>   (1) send audio data via virtqueue.
>   (2) map host audio buffers into the guest address space.
> 
> The audio driver api (i.e. alsa) typically allows to mmap() the audio
> data buffers, so it is the host audio driver which handles the
> allocation. 

Yes, in regular non VM mode, it's the host driver which allocs the
buffers.

My end goal is to be able to share physical SG pages from host to
guests and HW (including DSP firmwares). 

>  Let the audio hardware dma from/to userspace-allocated
> buffers is not possible[1], but we would need that to allow qemu (or
> other vmms) use guest-allocated buffers.

My misunderstanding here on how the various proposals being discussed
all pass buffers between guests & host. I'm reading that some are
passing buffers via userspace descriptors and this would not be
workable for audio.

> 
> cheers,
>   Gerd
> 
> [1] Disclaimer: It's been a while I looked at alsa more closely, so
> there is a chance this might have changed without /me noticing.
> 

Your all good here from audio. Disclaimer: I'm new to virtio.

Liam 

Re: [PATCH 2/4] ich9: fix getter type for sci_int property

[Philippe Mathieu-Daudé]

On 11/25/19 4:36 PM, Felipe Franciosi wrote:

When QOM APIs were added to ich9 in 6f1426ab, the getter for sci_int was
written using uint32_t. However, the object property is uint8_t. This
fixes the getter for correctness.

Signed-off-by: Felipe Franciosi 
---
  hw/isa/lpc_ich9.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index ce3342..240979885d 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -631,9 +631,9 @@ static void ich9_lpc_get_sci_int(Object *obj, Visitor *v, 
const char *name,
   void *opaque, Error **errp)
  {
  ICH9LPCState *lpc = ICH9_LPC_DEVICE(obj);
-uint32_t value = lpc->sci_gsi;
+uint8_t value = lpc->sci_gsi;
  
-visit_type_uint32(v, name, , errp);

+visit_type_uint8(v, name, , errp);


Maybe directly as:

   visit_type_uint8(v, name, >sci_gsi, errp);

With/without stack variable:
Reviewed-by: Philippe Mathieu-Daudé 


  }
  
  static void ich9_lpc_add_properties(ICH9LPCState *lpc)

@@ -641,7 +641,7 @@ static void ich9_lpc_add_properties(ICH9LPCState *lpc)
  static const uint8_t acpi_enable_cmd = ICH9_APM_ACPI_ENABLE;
  static const uint8_t acpi_disable_cmd = ICH9_APM_ACPI_DISABLE;
  
-object_property_add(OBJECT(lpc), ACPI_PM_PROP_SCI_INT, "uint32",

+object_property_add(OBJECT(lpc), ACPI_PM_PROP_SCI_INT, "uint8",
  ich9_lpc_get_sci_int,
  NULL, NULL, NULL, NULL);
  object_property_add_uint8_ptr(OBJECT(lpc), ACPI_PM_PROP_ACPI_ENABLE_CMD,

[PULL 0/1] Linux user for 4.2 patches

[Laurent Vivier]

The following changes since commit 2061735ff09f9d5e67c501a96227b470e7de69b1:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging 
(2019-11-21 17:18:40 +)

are available in the Git repository at:

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

for you to fetch changes up to d1e26707410067891ab5199f7e9d09afa2fbc0f6:

  linux-user: fix translation of statx structures (2019-11-25 12:57:58 +0100)


fix translation of statx structures



Ariadne Conill (1):
  linux-user: fix translation of statx structures

 linux-user/syscall.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

-- 
2.21.0

[PULL 1/1] linux-user: fix translation of statx structures

[Laurent Vivier]

From: Ariadne Conill 

All timestamps were copied to atime instead of to their respective
fields.

Fixes: efa921845c03 ("linux-user: Add support for translation of statx() 
syscall")
Signed-off-by: Ariadne Conill 
Reviewed-by: Aleksandar Markovic 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Laurent Vivier 
Message-Id: <20191122174040.569252-1-aria...@dereferenced.org>
Signed-off-by: Laurent Vivier 
---
 linux-user/syscall.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index ce399a55f0db..171c0caef3a1 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -6743,12 +6743,12 @@ static inline abi_long host_to_target_statx(struct 
target_statx *host_stx,
 __put_user(host_stx->stx_attributes_mask, 
_stx->stx_attributes_mask);
 __put_user(host_stx->stx_atime.tv_sec, _stx->stx_atime.tv_sec);
 __put_user(host_stx->stx_atime.tv_nsec, _stx->stx_atime.tv_nsec);
-__put_user(host_stx->stx_btime.tv_sec, _stx->stx_atime.tv_sec);
-__put_user(host_stx->stx_btime.tv_nsec, _stx->stx_atime.tv_nsec);
-__put_user(host_stx->stx_ctime.tv_sec, _stx->stx_atime.tv_sec);
-__put_user(host_stx->stx_ctime.tv_nsec, _stx->stx_atime.tv_nsec);
-__put_user(host_stx->stx_mtime.tv_sec, _stx->stx_atime.tv_sec);
-__put_user(host_stx->stx_mtime.tv_nsec, _stx->stx_atime.tv_nsec);
+__put_user(host_stx->stx_btime.tv_sec, _stx->stx_btime.tv_sec);
+__put_user(host_stx->stx_btime.tv_nsec, _stx->stx_btime.tv_nsec);
+__put_user(host_stx->stx_ctime.tv_sec, _stx->stx_ctime.tv_sec);
+__put_user(host_stx->stx_ctime.tv_nsec, _stx->stx_ctime.tv_nsec);
+__put_user(host_stx->stx_mtime.tv_sec, _stx->stx_mtime.tv_sec);
+__put_user(host_stx->stx_mtime.tv_nsec, _stx->stx_mtime.tv_nsec);
 __put_user(host_stx->stx_rdev_major, _stx->stx_rdev_major);
 __put_user(host_stx->stx_rdev_minor, _stx->stx_rdev_minor);
 __put_user(host_stx->stx_dev_major, _stx->stx_dev_major);
-- 
2.21.0

Re: Avocado notes from KVM forum 2019

[Cleber Rosa]

On Mon, Nov 25, 2019 at 01:35:13PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> Here are my notes from talking about Avocado with various people during the
> KVM forum in Lyon last month.
> 
> All comments are QEMU oriented.
> 
> 
> 1) Working offline
> 
> Various people complained Avocado requires online access, and they would
> like to use it offline.
>

Just to be extra clear, Avocado itself doesn't require online access, but:

 * "make check-venv" will download packages from PyPI if the same
   Avocado version is not previously installed in the system

 * "make check-acceptance" depends on "make check-venv"

 * many tests depend on downlodable assets

>   Maintainer workflow example is:
> 
>   - run avocado
>   - hack QEMU, build
>   - git pull
>   - build
>   - hack QEMU
>   (go offline)
>   - hack QEMU
>   - build
>   - run avocado <- FAILS
> 
> Failure is because mainstream added new tests, which got pulled in, and the
> user only notice when running avocado again, but offline.
> Test example is boot_linux_console.py, which added various tests from other
> subsystems, so the maintainer has to disable the new tests manually to be
> able to run his previous tests.
> 
> Expected solution: skip tests when artifact is not available, eventually
> when the --offline option is used
>

Understood and agreed.  I've already adopted this approach in the
"boot_linux.py" series I'm working (about to send v8).  If the
download/preparation of images fail, we cancel the tests.  I'll look
into making that the default across all tests or in the base
avocado_qemu.Test class.

We could also have a "make check-acceptance-prepare" kind of target,
that won't run the tests, but will download all needed assets.

> 
> 2) Add artifacts manually to the cache
> 
> Not all artifacts can be easily downloadable, some are public but require
> the user to accept an End User License Agreement.
> Users would like to share their tests with the documentation about where/how
> to download the requisite files (accepting the EULA) to run the tests.
> 
>

OK, RFE taken.

> 2b) Add reference to artifact to the cache
> 
> Group of users might share group of files (like NFS storage) and would like
> to use directly their remote read-only files, instead of copying it to their
> home directory.
> 
>

The underlying "asset fetcher" utility code supports multiple locations
and multiple cache dirs (and one could be a read-only NFS-like storage):

  
https://avocado-framework.readthedocs.io/en/73.0/api/utils/avocado.utils.html#avocado.utils.asset.Asset

But we need to make that easily accessible/configurable to users
of the fetch_asset() Test method.  RFE taken.

> 3) Provide qemu/avocado-qemu Python packages
> 
> The mainstream project uses Avocado to test QEMU. Others projects use QEMU
> to test their code, and would like to automatize that using Avocado. They
> usually not rebuild QEMU but use a stable binary from distributions. The
> python classes are not available, so they have to clone QEMU to use Avocado
> (I guess they only need 5 python files).
> When running on Continuous Integration, this is overkill, because when you
> clone QEMU you also clone various other submodules.
>

Agreed, and I already have a prototype.  I'll send the RFC/patches to
the list ASAP.

> 
> 4) Warn the user when Avocado is too old for the tests
> 
> Some users tried Avocado following the examples on the mailing list and the
> one in some commit's descriptions where we simply show "avocado run ...".
> They installed the distribution Avocado package and tried and it fails for
> few of them with no obvious reason (the .log file is hard to read when you
> are not custom to). IIUC their distribution provides a older Avocado (69?)
> while we use recent features (72).
> 
> We never noticed it because we use 'make check-venv' and do not test the
> distrib Avocado. While we can not test all distribs, we could add a version
> test if the Avocado version is too old, display a friendly message to the
> console (not the logfile).
>

OK, agreed.  RFE taken.

> 
> That it for my notes.
> 
> Eduardo/Wainer, are there other topics I forgot?
> 
> 
> Regards,
> 
> Phil.
> 

Thanks *so much* for this feedback!  I'll provide individual feedback as
each of those items progresses.

- Cleber.

RE: [PATCH 0/5] ARM virt: Add NVDIMM support

[Shameerali Kolothum Thodi]

Hi Igor,

> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 25 November 2019 15:46
> To: Shameerali Kolothum Thodi 
> Cc: Auger Eric ; qemu-devel@nongnu.org;
> qemu-...@nongnu.org; peter.mayd...@linaro.org;
> shannon.zha...@gmail.com; xuwei (O) ;
> ler...@redhat.com; Linuxarm 
> Subject: Re: [PATCH 0/5] ARM virt: Add NVDIMM support
> 
> On Mon, 25 Nov 2019 13:20:02 +
> Shameerali Kolothum Thodi  wrote:
> 
> > Hi Eric/Igor,
> >
> > > -Original Message-
> > > From: Shameerali Kolothum Thodi
> > > Sent: 22 October 2019 15:05
> > > To: 'Auger Eric' ; qemu-devel@nongnu.org;
> > > qemu-...@nongnu.org; imamm...@redhat.com
> > > Cc: peter.mayd...@linaro.org; shannon.zha...@gmail.com; xuwei (O)
> > > ; ler...@redhat.com; Linuxarm
> > > 
> > > Subject: RE: [PATCH 0/5] ARM virt: Add NVDIMM support
> 
> not related to problem discussed in this patch but you probably
> need to update docs/specs/acpi_nvdimm.txt to account for your changes

Ok.

> > >
> >
> > [..]
> >
> > > > one question: I noticed that when a NVDIMM slot is hotplugged one get
> > > > the following trace on guest:
> > > >
> > > > nfit ACPI0012:00: found a zero length table '0' parsing nfit
> > > > pmem0: detected capacity change from 0 to 1073741824
> > > >
> > > > Have you experienced the 0 length trace?
> > >
> > > I double checked and yes that trace is there. And I did a quick check with
> > > x86 and it is not there.
> > >
> > > The reason looks like, ARM64 kernel receives an additional 8 bytes size
> when
> > > the kernel evaluates the "_FIT" object.
> > >
> > > For the same test scenario, Qemu reports a FIT buffer size of 0xb8 and
> > >
> > > X86 Guest kernel,
> > > [1.601077] acpi_nfit_init: data 0x8a273dc12b18 sz 0xb8
> > >
> > > ARM64 Guest,
> > > [0.933133] acpi_nfit_init: data 0x3cbe6018 sz 0xc0
> > >
> > > I am not sure how that size gets changed for ARM which results in
> > > the above mentioned 0 length trace. I need to debug this further.
> > >
> > > Please let me know if you have any pointers...
> >
> > I spend some time debugging this further and it looks like the AML code
> > behaves differently on x86 and ARM64.
> FIT table is built dynamically and you are the first to debug
> such issue.
> (apart from the author the NVDIMM code.
:)
>  btw: why NVDIMM author is not on CC list???)

Right. Missed that. CCd.
 
> 
> > Booted guest with nvdimm mem, and used SSDT override with dbg prints
> > added,
> >
> > -object memory-backend-ram,id=mem1,size=1G \
> > -device nvdimm,id=dimm1,memdev=mem1 \
> >
> > On X86,
> > ---
> >
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8
> Dirty Yes.
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0
> func_ret_status 0
> >
> > [AML]"NVDIMM-NCAL: Rcvd RLEN 00C0"
> > [AML]"NVDIMM-NCAL: Creating OBUF with 05E0 bits"
> > [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 00BC"
> > [AML]"NVDIMM-RFIT Rcvd buf size 00BC"
> > [AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 00B8"
> > [AML]"NVDIMM-FIT: Rcvd buf size 00B8"
> >
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size
> 0xb8 Dirty No.
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8
> func_ret_status 0
> >
> > [AML]"NVDIMM-NCAL: Rcvd RLEN 0008"
> > [AML]"NVDIMM-NCAL: Creating OBUF with 0020 bits"
> > [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 0004"
> > [AML]"NVDIMM-RFIT Rcvd buf size 0004"
> > [AML]"NVDIMM-FIT: Rcvd buf size "
> > [AML]"NVDIMM-FIT: _FIT returned size 00B8"
> >
> > [ KERNEL] acpi_nfit_init: NVDIMM: data 0x9855bb9a7518 sz 0xb8  -->
> Guest receives correct size(0xb8) here
> >
> > On ARM64,
> > ---
> >
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8
> Dirty Yes.
> > [Qemu]VDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0
> func_ret_status 0
> >
> > [AML]"NVDIMM-NCAL: Rcvd RLEN 00C0"
> > [AML]"NVDIMM-NCAL: Creating OBUF with 05E0 bits"
> > [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 00BC"
> > [AML]"NVDIMM-RFIT Rcvd buf size 00BC"
> > [AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 00B8"
> > [AML]"NVDIMM-FIT: Rcvd buf size 00B8"
> >
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size
> 0xb8 Dirty No.
> > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8
> func_ret_status 0
> >
> > [AML]"NVDIMM-NCAL: Rcvd RLEN 0008"
> > [AML]"NVDIMM-NCAL: Creating OBUF with 0020 bits"  --> All
> looks same as x86 up to here.
> > [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 0008"  --->
> The size goes wrong. 8 bytes instead of 4!.
> 
> > [AML]"NVDIMM-RFIT Rcvd buf size 0008"
> > [AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 0004"
> > [AML]"NVDIMM-FIT: Rcvd buf size 0008"  --> Again size goes
> wrong. 8 bytes instead of 4!.
> 
>

Re: [PULL 0/3] virtio, pc: fixes

[Peter Maydell]

On Mon, 25 Nov 2019 at 08:44, Michael S. Tsirkin  wrote:
>
> The following changes since commit 2061735ff09f9d5e67c501a96227b470e7de69b1:
>
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
> staging (2019-11-21 17:18:40 +)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to e48929c787ed0ebed87877c97ac90c3a47ef7dda:
>
>   intel_iommu: TM field should not be in reserved bits (2019-11-25 03:42:58 
> -0500)
>
> 
> virtio, pc: fixes
>
> More small bugfixes.
>
> Signed-off-by: Michael S. Tsirkin 
>
> 


Applied, thanks.

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

-- PMM

Re: [PATCH 2/2] test-keyval: Tighten test of trailing crap after size

[Eric Blake]

On 11/25/19 9:31 AM, Markus Armbruster wrote:

Eric Blake  writes:


On 11/25/19 7:38 AM, Markus Armbruster wrote:

test_keyval_visit_size() should test for trailing crap after size with
and without suffix.  It does test the latter: "sz2=16Gi" has size
"16G" followed by crap "i".  It fails to test the former "sz1=16E" is
a syntactically valid size that overflows uint64_t.  Replace by
"sz1=0Z".




 /* Trailing crap */
-qdict = keyval_parse("sz1=16E,sz2=16Gi", NULL, _abort);
+qdict = keyval_parse("sz1=0Z,sz2=16Gi", NULL, _abort);


Does this actually test both failure cases, or does it abort the parse
after the first failure (sz1=0Z) without ever hitting the second half
of the parse (sz2=16Gi)?


Fair question!  Short answer: yes, we check both.


Aha - keyval_parse() just sets up the parser, while the check for double 
failures is in the test code below.



Clear now?


Yes.
Reviewed-by: Eric Blake 

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

Re: [PATCH 3/4] block/io: bdrv_common_block_status_above: support bs == base

[Kevin Wolf]

Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> We are going to reuse bdrv_common_block_status_above in
> bdrv_is_allocated_above. bdrv_is_allocated_above may be called with
> include_base == false and still bs == base (for ex. from img_rebase()).
> 
> So, support this corner case.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 

Worth a comment in the code why we need this? Either way:

Reviewed-by: Kevin Wolf 

Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements

[Peter Maydell]

On Sat, 23 Nov 2019 at 11:56, Marc Zyngier  wrote:
>
> HCR_EL2.TID3 mandates that access from EL1 to a long list of id
> registers traps to EL2, and QEMU has so far ignored this requirement.
>
> This breaks (among other things) KVM guests that have PtrAuth enabled,
> while the hypervisor doesn't want to expose the feature to its guest.
> To achieve this, KVM traps the ID registers (ID_AA64ISAR1_EL1 in this
> case), and masks out the unsupported feature.
>
> QEMU not honoring the trap request means that the guest observes
> that the feature is present in the HW, starts using it, and dies
> a horrible death when KVM injects an UNDEF, because the feature
> *really* isn't supported.
>
> Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set.
>
> Reported-by: Will Deacon 
> Signed-off-by: Marc Zyngier 
> ---
> There is a number of other trap bits missing (TID[0-2], for example),
> but this at least gets a mainline Linux going with cpu=max.

I guess this ought to go into 4.2, given that it gets recent
Linux guest kernels to work.


> @@ -6185,11 +6221,13 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>  { .name = "ID_AA64PFR0_EL1", .state = ARM_CP_STATE_AA64,
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 0,
>.access = PL1_R, .type = ARM_CP_NO_RAW,
> +  .accessfn = access_aa64idreg,
>.readfn = id_aa64pfr0_read,
>.writefn = arm_cp_write_ignore },
>  { .name = "ID_AA64PFR1_EL1", .state = ARM_CP_STATE_AA64,
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 1,
>.access = PL1_R, .type = ARM_CP_CONST,
> +  .accessfn = access_aa64idreg,
>.resetvalue = cpu->isar.id_aa64pfr1},
>  { .name = "ID_AA64PFR2_EL1_RESERVED", .state = ARM_CP_STATE_AA64,
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 2,
> @@ -6198,151 +6236,188 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>  { .name = "ID_AA64PFR3_EL1_RESERVED", .state = ARM_CP_STATE_AA64,
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 3,
>.access = PL1_R, .type = ARM_CP_CONST,
> +  .accessfn = access_aa64idreg,
>.resetvalue = 0 },

Missing .accessfn for ID_AA4PFR2_EL1_RESERVED ?

>  { .name = "ID_AA64ZFR0_EL1", .state = ARM_CP_STATE_AA64,
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 4,
>.access = PL1_R, .type = ARM_CP_CONST,
> +  .accessfn = access_aa64idreg,
>/* At present, only SVEver == 0 is defined anyway.  */
>.resetvalue = 0 },

>  { .name = "MVFR0_EL1", .state = ARM_CP_STATE_AA64,
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 0,
>.access = PL1_R, .type = ARM_CP_CONST,
> +  .accessfn = access_aa64idreg,
>.resetvalue = cpu->isar.mvfr0 },

These are the AArch64 accessors for the aarch32 MVFR registers,
but this trap bit is also supposed to trap aarch32 accesses to
the MVFR registers, which are via the vmrs insn. That needs
to be done in trans_VMSR_VMRS(); we can do that with a
followup patch, since the mechanism there is completely different.

thanks
-- PMM

Re: [PATCH 2/4] block/io: bdrv_common_block_status_above: support include_base

[Kevin Wolf]

Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> In order to reuse bdrv_common_block_status_above in
> bdrv_is_allocated_above, let's support include_base parameter.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 

Reviewed-by: Kevin Wolf 

[PATCH] fence: introduce a file-based self-fence mechanism

[Felipe Franciosi]

This introduces a self-fence mechanism to Qemu, causing it to die if a
heartbeat condition is not met. Currently, a file-based heartbeat is
available and can be configured as follows:

-object file-fence,id=ff0,file=/foo,qtimeout=20,ktimeout=25,signal=kill

Qemu will watch 'file' for attribute changes. Touching the file works as
a heartbeat. This parameter is mandatory.

Fencing happens after 'qtimeout' or 'ktimeout' seconds elapse without a
heartbeat. At least one of these must be specified. Both may be used.

When using 'qtimeout', an internal Qemu timer is used. Fencing with this
method gives Qemu a chance to write a log message indicating which file
caused the event. If Qemu's main loop is hung for whatever reason, this
method won't successfully kill Qemu.

When using 'ktimeout', a kernel timer is used. In this case, 'signal'
can be 'kill' (for SIGKILL, default) or 'quit' (for SIGQUIT). Using
SIGQUIT may be preferred for obtaining core dumps. If Qemu is hung
(eg. uninterruptable sleep), this method won't successfully kill Qemu.

It is worth noting that even successfully killing Qemu may not be
sufficient to completely fence a VM as certain operations like network
packets or block commands may be pending in the kernel. If that is a
concern, systems should consider using further fencing mechanisms like
hardware watchdogs either in addition or in conjunction with this for
additional protection.

Signed-off-by: Felipe Franciosi 
---
Based-on: <20191125153619.39893-2-fel...@nutanix.com>

 Makefile.objs   |   1 +
 fence/Makefile.objs |   1 +
 fence/file_fence.c  | 381 
 qemu-options.hx |  27 +++-
 4 files changed, 409 insertions(+), 1 deletion(-)
 create mode 100644 fence/Makefile.objs
 create mode 100644 fence/file_fence.c

diff --git a/Makefile.objs b/Makefile.objs
index 11ba1a36bd..998eed4796 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -75,6 +75,7 @@ common-obj-$(CONFIG_TPM) += tpm.o
 
 common-obj-y += backends/
 common-obj-y += chardev/
+common-obj-y += fence/
 
 common-obj-$(CONFIG_SECCOMP) += qemu-seccomp.o
 qemu-seccomp.o-cflags := $(SECCOMP_CFLAGS)
diff --git a/fence/Makefile.objs b/fence/Makefile.objs
new file mode 100644
index 00..2ed2092568
--- /dev/null
+++ b/fence/Makefile.objs
@@ -0,0 +1 @@
+common-obj-y += file_fence.o
diff --git a/fence/file_fence.c b/fence/file_fence.c
new file mode 100644
index 00..5b743e69d2
--- /dev/null
+++ b/fence/file_fence.c
@@ -0,0 +1,381 @@
+/*
+ * QEMU file-based self-fence mechanism
+ *
+ * Copyright (c) 2019 Nutanix Inc. All rights reserved.
+ *
+ * Authors:
+ *Felipe Franciosi 
+ *
+ * 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 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 "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "qemu/filemonitor.h"
+#include "qemu/timer.h"
+
+#include 
+
+#define TYPE_FILE_FENCE "file-fence"
+
+typedef struct FileFence {
+Object parent_obj;
+
+gchar *dir;
+gchar *file;
+uint32_t qtimeout;
+uint32_t ktimeout;
+int signal;
+
+timer_t ktimer;
+QEMUTimer *qtimer;
+
+QFileMonitor *fm;
+uint64_t id;
+} FileFence;
+
+#define FILE_FENCE(obj) \
+OBJECT_CHECK(FileFence, (obj), TYPE_FILE_FENCE)
+
+static void
+timer_update(FileFence *ff)
+{
+struct itimerspec its = {
+.it_value.tv_sec = ff->ktimeout,
+};
+int err;
+
+if (ff->qtimeout) {
+timer_mod(ff->qtimer, qemu_clock_get_ms(QEMU_CLOCK_REALTIME) +
+  ff->qtimeout * 1000);
+}
+
+if (ff->ktimeout) {
+err = timer_settime(ff->ktimer, 0, , NULL);
+g_assert(err == 0);
+}
+}
+
+static void
+file_fence_abort_cb(void *opaque)
+{
+FileFence *ff = opaque;
+printf("Fencing after %u seconds on '%s'\n",
+   ff->qtimeout, g_strconcat(ff->dir, "/", ff->file, NULL));
+abort();
+}
+
+static void
+file_fence_watch_cb(int64_t id, QFileMonitorEvent ev, const char *file,
+void *opaque)
+{
+FileFence *ff = opaque;
+
+if (ev != QFILE_MONITOR_EVENT_ATTRIBUTES) {
+return;
+}
+
+if (g_strcmp0(file, ff->file) != 0) {
+return;
+}
+
+timer_update(ff);
+}
+
+static void
+ktimer_tear(FileFence *ff)
+{
+int err;
+
+if (ff->ktimer) {
+err = timer_delete(ff->ktimer);
+g_assert(err == 0);
+ 

Re: [PULL 4/4] net/virtio: return error when device_opts arg is NULL

[Paolo Bonzini]

On 25/11/19 16:40, Jason Wang wrote:
> From: Jens Freimann 
> 
> This fixes CID 1407222.
> 
> Fixes: 9711cd0dfc3f ("net/virtio: add failover support")
> Signed-off-by: Jens Freimann 
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 
> ---
>  hw/net/virtio-net.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 565dea0..3c31471 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -2880,9 +2880,12 @@ static int 
> virtio_net_primary_should_be_hidden(DeviceListener *listener,
>  QemuOpts *device_opts)
>  {
>  VirtIONet *n = container_of(listener, VirtIONet, primary_listener);
> -bool match_found;
> -bool hide;
> +bool match_found = false;
> +bool hide = false;
>  
> +if (!device_opts) {
> +return -1;
> +}
>  n->primary_device_dict = qemu_opts_to_qdict(device_opts,
>  n->primary_device_dict);
>  if (n->primary_device_dict) {
> @@ -2890,7 +2893,7 @@ static int 
> virtio_net_primary_should_be_hidden(DeviceListener *listener,
>  n->standby_id = g_strdup(qdict_get_try_str(n->primary_device_dict,
>  "failover_pair_id"));
>  }
> -if (device_opts && g_strcmp0(n->standby_id, n->netclient_name) == 0) {
> +if (g_strcmp0(n->standby_id, n->netclient_name) == 0) {
>  match_found = true;
>  } else {
>  match_found = false;
> 

It can't be NULL though, can it?  It is called from a qemu_foreach_opt
callback on device_opts itself.  This can be "re-fixed" in 5.0 though,
no hurry.

Paolo

Re: [PATCH v3 2/8] block: Add no_fallback parameter to bdrv_co_truncate()

[Kevin Wolf]

Am 25.11.2019 um 16:06 hat Alberto Garcia geschrieben:
> On Fri 22 Nov 2019 05:05:05 PM CET, Kevin Wolf wrote:
> 
> > @@ -3405,6 +3412,7 @@ typedef struct TruncateCo {
> >  int64_t offset;
> >  bool exact;
> >  PreallocMode prealloc;
> > +bool no_fallback;
> >  Error **errp;
> >  int ret;
> >  } TruncateCo;
> 
> You add the 'no_fallback' field here...
> 
> >  int bdrv_truncate(BdrvChild *child, int64_t offset, bool exact,
> > -  PreallocMode prealloc, Error **errp)
> > +  PreallocMode prealloc, bool no_fallback, Error **errp)
> >  {
> >  Coroutine *co;
> >  TruncateCo tco = {
> 
> ...but then you don't use it when the structure is initialized.

Oops. Another proof that a series like this is too much for -rc3.

Kevin

Re: [PATCH 1/4] block/io: fix bdrv_co_block_status_above

[Kevin Wolf]

Am 16.11.2019 um 17:34 hat Vladimir Sementsov-Ogievskiy geschrieben:
> bdrv_co_block_status_above has several problems with handling short
> backing files:
> 
> 1. With want_zeros=true, it may return ret with BDRV_BLOCK_ZERO but
> without BDRV_BLOCK_ALLOCATED flag, when actually short backing file
> which produces these after-EOF zeros is inside requested backing
> sequesnce.

s/sequesnce/sequence/

> 
> 2. With want_zeros=false, it will just stop inside requested region, if
> we have unallocated region in top node when underlying backing is
> short.

I honestly don't understand this one. Can you rephrase/explain in more
detail what you mean by "stop inside [the] requested region"?

> Fix these things, making logic about short backing files clearer.
> 
> Note that 154 output changed, because now bdrv_block_status_above don't
> merge unallocated zeros with zeros after EOF (which are actually
> "allocated" in POV of read from backing-chain top) and is_zero() just
> don't understand that the whole head or tail is zero. We may update
> is_zero to call bdrv_block_status_above several times, or add flag to
> bdrv_block_status_above that we are not interested in ALLOCATED flag,
> so ranges with different ALLOCATED status may be merged, but actually,
> it seems that we'd better don't care about this corner case.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/io.c | 41 --
>  tests/qemu-iotests/154.out |  4 ++--
>  2 files changed, 32 insertions(+), 13 deletions(-)
> 
> diff --git a/block/io.c b/block/io.c
> index f75777f5ea..4d7fa99bd2 100644
> --- a/block/io.c
> +++ b/block/io.c
> @@ -2434,25 +2434,44 @@ static int coroutine_fn 
> bdrv_co_block_status_above(BlockDriverState *bs,
>  ret = bdrv_co_block_status(p, want_zero, offset, bytes, pnum, map,
> file);
>  if (ret < 0) {
> -break;
> +return ret;
>  }
> -if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
> +if (*pnum == 0) {
> +if (first) {
> +return ret;
> +}
> +
>  /*
> - * Reading beyond the end of the file continues to read
> - * zeroes, but we can only widen the result to the
> - * unallocated length we learned from an earlier
> - * iteration.
> + * Reads from bs for selected region will return zeroes, produced
> + * because current level is short. We should consider it as
> + * allocated.

"the selected region"
"the current level"

> + * TODO: Should we report p as file here?

I think that would make sense.

>   */
> +assert(ret & BDRV_BLOCK_EOF);

Can this assertion be moved above the if (first)?

>  *pnum = bytes;
> +return BDRV_BLOCK_ZERO | BDRV_BLOCK_ALLOCATED;
>  }
> -if (ret & (BDRV_BLOCK_ZERO | BDRV_BLOCK_DATA)) {
> -break;
> +if (ret & BDRV_BLOCK_ALLOCATED) {
> +/* We've found the node and the status, we must return. */
> +
> +if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
> +/*
> + * This level also responsible for reads after EOF inside
> + * unallocated region in previous level.

"is also responsible"
"the unallocated region in the previous level"

> + */
> +*pnum = bytes;
> +}
> +
> +return ret;
>  }
> -/* [offset, pnum] unallocated on this layer, which could be only
> - * the first part of [offset, bytes].  */

Any reason for deleting this comment? I think it's still valid.

> -bytes = MIN(bytes, *pnum);
> +
> +/* Proceed to backing */
> +assert(*pnum <= bytes);
> +bytes = *pnum;
>  first = false;
>  }
> +
>  return ret;
>  }

Kevin

Re: [PATCH] qom/object: enable setter for uint types

[Felipe Franciosi]

> On Nov 19, 2019, at 10:06 AM, Stefan Hajnoczi  wrote:
> 
> On Sun, Nov 17, 2019 at 03:50:32PM +, Felipe Franciosi wrote:
>> Traditionally, the uint-specific property helpers only offer getters.
>> When adding object (or class) uint types, one must therefore use the
>> generic property helper if a setter is needed.
>> 
>> This enhances the uint-specific property helper APIs by adding a
>> 'readonly' field and modifying all users of that API to set this
>> parameter to true. If 'readonly' is false, though, the helper will add
>> an automatic setter for the value.
>> 
>> Signed-off-by: Felipe Franciosi 
>> ---
>> hw/acpi/ich9.c   |   4 +-
>> hw/acpi/pcihp.c  |   6 +--
>> hw/acpi/piix4.c  |  12 +++---
>> hw/isa/lpc_ich9.c|   4 +-
>> hw/ppc/spapr_drc.c   |   2 +-
>> include/qom/object.h |  28 
>> qom/object.c | 100 ---
>> ui/console.c |   3 +-
>> 8 files changed, 111 insertions(+), 48 deletions(-)
> 
> Reviewed-by: Stefan Hajnoczi 

While cleaning up more code to use these helpers, I realised that some
setters included a check to ensure values were not overflowing. I
therefore decided to improve on this setter and send other related
changes together in the following patchset:

https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg04136.html

Please don't merge this patch and look at the patchset instead.

F.

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

[Sarah Harris]

Hi Aleksandar,

> - Is there a place in docs that explain its implementation in general?
This implementation was based on the datasheet for the ATmega2560 
("ATmega640/1280/1281/2560/2561 datasheet" available from Microchip's website).
(I'm not sure if posting a URL will trigger any spam filters, so I'll leave it 
for now)
See section 22.10, "USART - Register Description".

> - Why do cases 4, 5, 6 issue relatively unclear error message
> ""update_char_mask(): Reserved character size "? Is there a
> better wording perhaps? Where is justification in the doc for these
> cases?
The hardware can send/receive characters of various lengths, specified by 
settings in these configuration registers.
The cases are defined in table 22-7, "UCSZn Bits Settings", which specifies 
that modes 4, 5, and 6 are reserved and should not be used.
I'm not sure how better to explain this fault to the user; this is an edge case 
that I'd expect only an AVR developer testing their own program to see, so 
describing it in the same way as the datasheet seems a good idea.

> - What would be the docs justification for case 7? Why is an error
> message issued, but still "char_mask" is set, and I guess, further
> processing will go on? Why the error message says "Nine bit character
> requested"? Who said that (that *nine* bit characters were requested?
> :-)
Case 7 also comes from table 22-7, and specifies that the USART should 
send/receive 9 bits per character.
For characters <= 8 bits it's easy to pad them to the 8 bit bytes that the 
character device subsystem operates on.
For characters of 9 bits we'd have to throw away one bit, which seems like a 
bad thing to do.
I decided it wasn't enough to justify crashing, but the user should be made 
aware that data is being lost and the output might not be what they would 
otherwise expect.

Kind regards,
Sarah Harris


On Fri, 22 Nov 2019 16:10:02 +0100
Aleksandar Markovic  wrote:

> On Tue, Oct 29, 2019 at 10:25 PM Michael Rolnik  wrote:
> >
> > From: Sarah Harris 
> >
> > These were designed to facilitate testing but should provide enough 
> > function to be useful in other contexts.
> > Only a subset of the functions of each peripheral is implemented, mainly 
> > due to the lack of a standard way to handle electrical connections (like 
> > GPIO pins).
> >
> > Signed-off-by: Sarah Harris 
> > ---
> >  hw/char/Kconfig|   3 +
> >  hw/char/Makefile.objs  |   1 +
> >  hw/char/avr_usart.c| 324 ++
> >  hw/misc/Kconfig|   3 +
> >  hw/misc/Makefile.objs  |   2 +
> >  hw/misc/avr_mask.c | 112 ++
> >  hw/timer/Kconfig   |   3 +
> >  hw/timer/Makefile.objs |   2 +
> >  hw/timer/avr_timer16.c | 605 +
> >  include/hw/char/avr_usart.h|  97 ++
> >  include/hw/misc/avr_mask.h |  47 +++
> >  include/hw/timer/avr_timer16.h |  97 ++
> >  12 files changed, 1296 insertions(+)
> >  create mode 100644 hw/char/avr_usart.c
> >  create mode 100644 hw/misc/avr_mask.c
> >  create mode 100644 hw/timer/avr_timer16.c
> >  create mode 100644 include/hw/char/avr_usart.h
> >  create mode 100644 include/hw/misc/avr_mask.h
> >  create mode 100644 include/hw/timer/avr_timer16.h
> >
> > diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> > index 40e7a8b8bb..331b20983f 100644
> > --- a/hw/char/Kconfig
> > +++ b/hw/char/Kconfig
> > @@ -46,3 +46,6 @@ config SCLPCONSOLE
> >
> >  config TERMINAL3270
> >  bool
> > +
> > +config AVR_USART
> > +bool
> > diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> > index 02d8a66925..f05c1f5667 100644
> > --- a/hw/char/Makefile.objs
> > +++ b/hw/char/Makefile.objs
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
> >  obj-$(CONFIG_DIGIC) += digic-uart.o
> >  obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
> >  obj-$(CONFIG_RASPI) += bcm2835_aux.o
> > +common-obj-$(CONFIG_AVR_USART) += avr_usart.o
> >
> >  common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
> >  common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
> > diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
> > new file mode 100644
> > index 00..9ca3c2a1cd
> > --- /dev/null
> > +++ b/hw/char/avr_usart.c
> > @@ -0,0 +1,324 @@
> > +/*
> > + * AVR USART
> > + *
> > + * Copyright (c) 2018 University of Kent
> > + * Author: Sarah Harris
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > + * of this software and associated documentation files (the "Software"), 
> > to deal
> > + * in the Software without restriction, including without limitation the 
> > rights
> > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> > sell
> > + * copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included 
> > in
> > + * 

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

[Sarah Harris]

Hi Aleksandar,

I think returning immediately should be ok, it just happened to make sense to 
me to think in terms of this being a special case of a normal read.
The else handles the case in which no data has been received, but the user's 
program reads the incoming buffer anyway.
(As far as I'm aware this is undefined behaviour, so returning zero is 
reasonable)

Kind regards,
Sarah Harris


On Fri, 22 Nov 2019 17:48:56 +0100
Aleksandar Markovic  wrote:

> On Tue, Oct 29, 2019 at 10:25 PM Michael Rolnik  wrote:
> >
> > From: Sarah Harris 
> >
> > These were designed to facilitate testing but should provide enough 
> > function to be useful in other contexts.
> > Only a subset of the functions of each peripheral is implemented, mainly 
> > due to the lack of a standard way to handle electrical connections (like 
> > GPIO pins).
> >
> > Signed-off-by: Sarah Harris 
> > ---
> >  hw/char/Kconfig|   3 +
> >  hw/char/Makefile.objs  |   1 +
> >  hw/char/avr_usart.c| 324 ++
> >  hw/misc/Kconfig|   3 +
> >  hw/misc/Makefile.objs  |   2 +
> >  hw/misc/avr_mask.c | 112 ++
> >  hw/timer/Kconfig   |   3 +
> >  hw/timer/Makefile.objs |   2 +
> >  hw/timer/avr_timer16.c | 605 +
> >  include/hw/char/avr_usart.h|  97 ++
> >  include/hw/misc/avr_mask.h |  47 +++
> >  include/hw/timer/avr_timer16.h |  97 ++
> >  12 files changed, 1296 insertions(+)
> >  create mode 100644 hw/char/avr_usart.c
> >  create mode 100644 hw/misc/avr_mask.c
> >  create mode 100644 hw/timer/avr_timer16.c
> >  create mode 100644 include/hw/char/avr_usart.h
> >  create mode 100644 include/hw/misc/avr_mask.h
> >  create mode 100644 include/hw/timer/avr_timer16.h
> >
> > diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> > index 40e7a8b8bb..331b20983f 100644
> > --- a/hw/char/Kconfig
> > +++ b/hw/char/Kconfig
> > @@ -46,3 +46,6 @@ config SCLPCONSOLE
> >
> >  config TERMINAL3270
> >  bool
> > +
> > +config AVR_USART
> > +bool
> > diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> > index 02d8a66925..f05c1f5667 100644
> > --- a/hw/char/Makefile.objs
> > +++ b/hw/char/Makefile.objs
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
> >  obj-$(CONFIG_DIGIC) += digic-uart.o
> >  obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
> >  obj-$(CONFIG_RASPI) += bcm2835_aux.o
> > +common-obj-$(CONFIG_AVR_USART) += avr_usart.o
> >
> >  common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
> >  common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
> > diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
> > new file mode 100644
> > index 00..9ca3c2a1cd
> > --- /dev/null
> > +++ b/hw/char/avr_usart.c
> > @@ -0,0 +1,324 @@
> > +/*
> > + * AVR USART
> > + *
> > + * Copyright (c) 2018 University of Kent
> > + * Author: Sarah Harris
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > + * of this software and associated documentation files (the "Software"), 
> > to deal
> > + * in the Software without restriction, including without limitation the 
> > rights
> > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> > sell
> > + * copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included 
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> > FROM,
> > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
> > IN
> > + * THE SOFTWARE.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "hw/char/avr_usart.h"
> > +#include "qemu/log.h"
> > +#include "hw/irq.h"
> > +#include "hw/qdev-properties.h"
> > +
> > +static int avr_usart_can_receive(void *opaque)
> > +{
> > +AVRUsartState *usart = opaque;
> > +
> > +if (usart->data_valid || !(usart->csrb & USART_CSRB_RXEN)) {
> > +return 0;
> > +}
> > +return 1;
> > +}
> > +
> > +static void avr_usart_receive(void *opaque, const uint8_t *buffer, int 
> > size)
> > +{
> > +AVRUsartState *usart = opaque;
> > +assert(size == 1);
> > +assert(!usart->data_valid);
> > +usart->data = buffer[0];
> > +usart->data_valid = true;
> > +usart->csra |= USART_CSRA_RXC;
> > +if (usart->csrb & USART_CSRB_RXCIE) {
> > +qemu_set_irq(usart->rxc_irq, 1);
> > +}
> > +}
> > +
> > +static void 

Re: [PATCH 0/4] fix & merge block_status_above and is_allocated_above

[Kevin Wolf]

Am 25.11.2019 um 11:08 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Ping?
> 
> Hi! Why so silent? Postpone this to 5.0? This is fixing the same
> problem with block commit, like Kevin's series, just commit not to mid
> but to base..

To be honest, I think by now we've found so many problems around short
backing files, each with a non-trivial fix, that I don't think we can
have a reasonably complete fix in -rc3 without risking breaking
everything. None of the problems are new, in fact I think they have
existed since day one of resize/commit, and nobody has reported problems
before, so they can't be hitting a large number of users.

So, reluctantly, I have to admit that both series and whatever we'll add
on top are probably better kept for 5.0 (and 4.2.1) rather than added
very late into 4.2.

Kevin

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

[Eric Blake]

On 11/25/19 9:40 AM, Daniel P. Berrangé wrote:


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.

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.


And that's the soonest it could be removed. If your consultation reports 
back that it is still needed, we can reverse the decision to deprecate 
or extend the deprecation to last longer, as needed, rather than blindly 
removing at the first possible moment.


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

Re: [PATCH 0/5] ARM virt: Add NVDIMM support

[Igor Mammedov]

On Mon, 25 Nov 2019 13:20:02 +
Shameerali Kolothum Thodi  wrote:

> Hi Eric/Igor,
> 
> > -Original Message-
> > From: Shameerali Kolothum Thodi
> > Sent: 22 October 2019 15:05
> > To: 'Auger Eric' ; qemu-devel@nongnu.org;
> > qemu-...@nongnu.org; imamm...@redhat.com
> > Cc: peter.mayd...@linaro.org; shannon.zha...@gmail.com; xuwei (O)
> > ; ler...@redhat.com; Linuxarm
> > 
> > Subject: RE: [PATCH 0/5] ARM virt: Add NVDIMM support

not related to problem discussed in this patch but you probably
need to update docs/specs/acpi_nvdimm.txt to account for your changes

> >   
> 
> [..]
> 
> > > one question: I noticed that when a NVDIMM slot is hotplugged one get
> > > the following trace on guest:
> > >
> > > nfit ACPI0012:00: found a zero length table '0' parsing nfit
> > > pmem0: detected capacity change from 0 to 1073741824
> > >
> > > Have you experienced the 0 length trace?  
> > 
> > I double checked and yes that trace is there. And I did a quick check with
> > x86 and it is not there.
> > 
> > The reason looks like, ARM64 kernel receives an additional 8 bytes size when
> > the kernel evaluates the "_FIT" object.
> > 
> > For the same test scenario, Qemu reports a FIT buffer size of 0xb8 and
> > 
> > X86 Guest kernel,
> > [1.601077] acpi_nfit_init: data 0x8a273dc12b18 sz 0xb8
> > 
> > ARM64 Guest,
> > [0.933133] acpi_nfit_init: data 0x3cbe6018 sz 0xc0
> > 
> > I am not sure how that size gets changed for ARM which results in
> > the above mentioned 0 length trace. I need to debug this further.
> > 
> > Please let me know if you have any pointers...  
> 
> I spend some time debugging this further and it looks like the AML code
> behaves differently on x86 and ARM64.
FIT table is built dynamically and you are the first to debug
such issue.
(apart from the author the NVDIMM code.
 btw: why NVDIMM author is not on CC list???)


> Booted guest with nvdimm mem, and used SSDT override with dbg prints
> added,
> 
> -object memory-backend-ram,id=mem1,size=1G \
> -device nvdimm,id=dimm1,memdev=mem1 \
> 
> On X86,
> ---
> 
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8 Dirty 
> Yes.
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0 
> func_ret_status 0
> 
> [AML]"NVDIMM-NCAL: Rcvd RLEN 00C0"
> [AML]"NVDIMM-NCAL: Creating OBUF with 05E0 bits"
> [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 00BC"
> [AML]"NVDIMM-RFIT Rcvd buf size 00BC"
> [AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 00B8"
> [AML]"NVDIMM-FIT: Rcvd buf size 00B8"
> 
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size 0xb8 
> Dirty No.
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8 
> func_ret_status 0 
> 
> [AML]"NVDIMM-NCAL: Rcvd RLEN 0008"
> [AML]"NVDIMM-NCAL: Creating OBUF with 0020 bits"
> [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 0004"
> [AML]"NVDIMM-RFIT Rcvd buf size 0004"
> [AML]"NVDIMM-FIT: Rcvd buf size "
> [AML]"NVDIMM-FIT: _FIT returned size 00B8"
> 
> [ KERNEL] acpi_nfit_init: NVDIMM: data 0x9855bb9a7518 sz 0xb8  --> Guest 
> receives correct size(0xb8) here 
> 
> On ARM64,
> ---
> 
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8 Dirty 
> Yes.
> [Qemu]VDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0 
> func_ret_status 0 
> 
> [AML]"NVDIMM-NCAL: Rcvd RLEN 00C0"
> [AML]"NVDIMM-NCAL: Creating OBUF with 05E0 bits"
> [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 00BC"
> [AML]"NVDIMM-RFIT Rcvd buf size 00BC"
> [AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 00B8"
> [AML]"NVDIMM-FIT: Rcvd buf size 00B8"
> 
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size 0xb8 
> Dirty No.
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8 
> func_ret_status 0 
> 
> [AML]"NVDIMM-NCAL: Rcvd RLEN 0008"
> [AML]"NVDIMM-NCAL: Creating OBUF with 0020 bits"  --> All looks 
> same as x86 up to here.
> [AML]"NVDIMM-NCAL: Created  BUF(Local7) size 0008"  ---> The size 
> goes wrong. 8 bytes instead of 4!.

> [AML]"NVDIMM-RFIT Rcvd buf size 0008"
> [AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 0004"
> [AML]"NVDIMM-FIT: Rcvd buf size 0008"  --> Again size goes wrong. 
> 8 bytes instead of 4!.

Local1 = SizeOf (Local0)
printf("NVDIMM-RFIT Rcvd buf size %o", Local1)

Local1 -= 0x04
   ^^ here you get -4 so sizes you see are 
consistent

If ((Local1 == Zero))
{
Return (Buffer (Zero){})
}

CreateField (Local0, 0x20, (Local1 << 0x03), BUFF)
printf("NVDIMM-RFIT Created NVDR.RFIT.BUFF size %o", Local1)

 
> [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xc0 FIT size 0xb8 
> Dirty No.  

Re: [PATCH v3 4/5] s390x: Move clear reset

[Cornelia Huck]

On Mon, 25 Nov 2019 14:49:54 +0100
Janosch Frank  wrote:

> On 11/25/19 2:37 PM, Cornelia Huck wrote:
> > On Mon, 25 Nov 2019 04:03:47 -0500
> > 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(-)
> >>  
> >   
> >> @@ -453,6 +424,11 @@ static Property s390x_cpu_properties[] = {
> >>  DEFINE_PROP_END_OF_LIST()
> >>  };
> >>  
> >> +static void s390_cpu_reset_clear(CPUState *s)
> >> +{
> >> +return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
> >> +}
> >> +
> >>  static void s390_cpu_class_init(ObjectClass *oc, void *data)
> >>  {
> >>  S390CPUClass *scc = S390_CPU_CLASS(oc);
> >> @@ -469,7 +445,7 @@ static void s390_cpu_class_init(ObjectClass *oc, void 
> >> *data)
> >>  scc->load_normal = s390_cpu_load_normal;
> >>  #endif
> >>  scc->reset = s390_cpu_reset;
> >> -cc->reset = s390_cpu_full_reset;
> >> +cc->reset = s390_cpu_reset_clear;
> >>  cc->class_by_name = s390_cpu_class_by_name,
> >>  cc->has_work = s390_cpu_has_work;
> >>  #ifdef CONFIG_TCG  
> > 
> > One thing I liked about the previous naming is that it is more obvious
> > that the clear reset is actually the full reset of a cpu. Not sure if
> > keeping that is better than matching the function name to the name of
> > the reset being performed. Opinions?
> >   
> 
> Are you only worrying for this particular wrapper or in general?
> I'd be happy to rename the wrapper to s390_cpu_reset_full()

Yes, I was thinking about this wrapper only, but don't feel too
strongly.


pgposG0ExOxQl.pgp
Description: OpenPGP digital signature

Re: Avocado notes from KVM forum 2019

[Cleber Rosa]

- Original Message -
> From: "Gerd Hoffmann" 
> To: "Eduardo Habkost" 
> Cc: avocado-de...@redhat.com, "Philippe Mathieu-Daudé" , 
> "qemu-devel" ,
> "Wainer dos Santos Moschetta" , "Cleber Rosa" 
> 
> Sent: Monday, November 25, 2019 9:15:53 AM
> Subject: Re: Avocado notes from KVM forum 2019
> 
> > > 1) Working offline
> > > 
> > > Various people complained Avocado requires online access, and they would
> > > like to use it offline.
> > > 
> > >   Maintainer workflow example is:
> > > 
> > >   - run avocado
> > >   - hack QEMU, build
> > >   - git pull
> > >   - build
> > >   - hack QEMU
> > >   (go offline)
> > >   - hack QEMU
> > >   - build
> > >   - run avocado <- FAILS
> > > 
> > 
> > Ouch.  This shouldn't happen even with no explicit --offline
> > option.  Failure to download artifacts shouldn't make tests
> > report failure.
> 
> Related (and already discussed in the past):  There should be a separate
> "downloads artifacts", especially for larger ones which easily fail to
> download on slower internet links due to hitting the test timeout while
> downloading ...
> 

Hi Gerd,

We listened to you :) and that's an Avocado 73.0 feature (released Friday,
very first bullet point item):

  https://avocado-framework.readthedocs.io/en/73.0/releases/73_0.html

It doesn't cover all use cases, but works as expected for QEMU.  I'm just
waiting the end of the code freeze to bump the Avocado version and have
that in by default.

Thanks!
- Cleber.

> cheers,
>   Gerd
> 
> 
> 

[PULL 4/4] net/virtio: return error when device_opts arg is NULL

[Jason Wang]

From: Jens Freimann 

This fixes CID 1407222.

Fixes: 9711cd0dfc3f ("net/virtio: add failover support")
Signed-off-by: Jens Freimann 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 hw/net/virtio-net.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 565dea0..3c31471 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2880,9 +2880,12 @@ static int 
virtio_net_primary_should_be_hidden(DeviceListener *listener,
 QemuOpts *device_opts)
 {
 VirtIONet *n = container_of(listener, VirtIONet, primary_listener);
-bool match_found;
-bool hide;
+bool match_found = false;
+bool hide = false;
 
+if (!device_opts) {
+return -1;
+}
 n->primary_device_dict = qemu_opts_to_qdict(device_opts,
 n->primary_device_dict);
 if (n->primary_device_dict) {
@@ -2890,7 +2893,7 @@ static int 
virtio_net_primary_should_be_hidden(DeviceListener *listener,
 n->standby_id = g_strdup(qdict_get_try_str(n->primary_device_dict,
 "failover_pair_id"));
 }
-if (device_opts && g_strcmp0(n->standby_id, n->netclient_name) == 0) {
+if (g_strcmp0(n->standby_id, n->netclient_name) == 0) {
 match_found = true;
 } else {
 match_found = false;
-- 
2.5.0

Re: [PULL 0/1] Miscellaneous patches for 2019-11-25

[Peter Maydell]

On Mon, 25 Nov 2019 at 06:06, Markus Armbruster  wrote:
>
> The following changes since commit 2061735ff09f9d5e67c501a96227b470e7de69b1:
>
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
> staging (2019-11-21 17:18:40 +)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/armbru.git tags/pull-misc-2019-11-25
>
> for you to fetch changes up to 25f74087c695364dfaa87443b1040a3aa5c29008:
>
>   util/cutils: Fix incorrect integer->float conversion caught by clang 
> (2019-11-25 06:00:05 +0100)
>
> 
> Miscellaneous patches for 2019-11-25
>
> 
> Fangrui Song (1):
>   util/cutils: Fix incorrect integer->float conversion caught by clang
>
>  util/cutils.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> --


Applied, thanks.

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

-- PMM

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

[Daniel P . Berrangé]

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.

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 :|

[PULL 0/4] Net patches

[Jason Wang]

The following changes since commit 122e6d2a9c1bf8aa1d51409c15809a82621515b1:

  Merge remote-tracking branch 'remotes/gkurz/tags/9p-fix-2019-11-23' into 
staging (2019-11-25 13:39:45 +)

are available in the git repository at:

  https://github.com/jasowang/qemu.git tags/net-pull-request

for you to fetch changes up to 4d0e59ace29277b2faa5b33c719be9baaa659093:

  net/virtio: return error when device_opts arg is NULL (2019-11-25 23:30:29 
+0800)




Jens Freimann (4):
  net/virtio: fix dev_unplug_pending
  net/virtio: return early when failover primary alread added
  net/virtio: fix re-plugging of primary device
  net/virtio: return error when device_opts arg is NULL

 hw/net/virtio-net.c | 58 +++--
 migration/savevm.c  |  3 ++-
 2 files changed, 40 insertions(+), 21 deletions(-)

2.5.0

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

[Vivek Goyal]

On Fri, Nov 22, 2019 at 05:47:32PM +, Dr. David Alan Gilbert wrote:

[..]
> > +static int virtio_send_notify_msg(struct fuse_session *se, struct iovec 
> > *iov,
> > + int count)
> > +{
> > +struct fv_QueueInfo *qi;
> > +VuDev *dev = >virtio_dev->dev;
> > +VuVirtq *q;
> > +FVRequest *req;
> > +VuVirtqElement *elem;
> > +unsigned int in_num, bad_in_num = 0, bad_out_num = 0;
> > +struct fuse_out_header *out = iov[0].iov_base;
> > +size_t in_len, tosend_len = iov_size(iov, count);
> > +struct iovec *in_sg;
> > +int ret = 0;
> > +
> > +/* Notifications have unique == 0 */
> > +assert (!out->unique);
> > +
> > +if (!se->notify_enabled)
> > +return -EOPNOTSUPP;
> > +
> > +/* If notifications are enabled, queue index 1 is notification queue */
> > +qi = se->virtio_dev->qi[1];
> > +q = vu_get_queue(dev, qi->qidx);
> > +
> > +pthread_rwlock_rdlock(>virtio_dev->vu_dispatch_rwlock);
> > +pthread_mutex_lock(>vq_lock);
> > +/* Pop an element from queue */
> > +req = vu_queue_pop(dev, q, sizeof(FVRequest), _in_num, 
> > _out_num);
> 
> You don't need bad_in_num/bad_out_num - just pass NULL for both; they're
> only needed if you expect to read/write data that's not mappable (i.e.
> in our direct write case).

Will do.

[..]
> > @@ -1950,21 +1948,54 @@ static void lo_setlk(fuse_req_t req, fuse_ino_t ino,
> >  
> > if (!plock) {
> > saverr = ret;
> > +   pthread_mutex_unlock(>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(>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.

Thanks
Vivek