Re: [PATCH v3] yield_until_fd_readable: make it work with any AioContect

2019-10-23 Thread Dietmar Maurer
> > +aio_set_fd_handler(ctx, fd, false, (IOHandler *)qemu_coroutine_enter,
> > +   NULL, NULL, qemu_coroutine_self());
> 
> This cast is unsafe.  If qemu_coroutine_enter()'s prototype is changed
> there will be no compiler warning that the prototypes are now
> incompatible.
> 
> Please keep fd_coroutine_enter() so the code is type-safe.

OK. Sent v4 with suggested changes.




[PATCH v4] yield_until_fd_readable: make it work with any AioContect

2019-10-23 Thread Dietmar Maurer
Simply use qemu_get_current_aio_context().

Signed-off-by: Dietmar Maurer 
---
Changelog for v4:

- avoid unsafe cast and keep fd_coroutine_enter()

Changelog for v3:

- use (IOHandler *) instead of ((void (*)(void *))
- coding style: fix max line length

Changelog for v2:

- use correct read handler in aio_set_fd_handler (instead of write handler)

 util/qemu-coroutine-io.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/util/qemu-coroutine-io.c b/util/qemu-coroutine-io.c
index 44a8969a69..5b80bb416f 100644
--- a/util/qemu-coroutine-io.c
+++ b/util/qemu-coroutine-io.c
@@ -67,6 +67,7 @@ qemu_co_send_recv(int sockfd, void *buf, size_t bytes, bool 
do_send)
 }
 
 typedef struct {
+AioContext *ctx;
 Coroutine *co;
 int fd;
 } FDYieldUntilData;
@@ -74,7 +75,7 @@ typedef struct {
 static void fd_coroutine_enter(void *opaque)
 {
 FDYieldUntilData *data = opaque;
-qemu_set_fd_handler(data->fd, NULL, NULL, NULL);
+aio_set_fd_handler(data->ctx, data->fd, false, NULL, NULL, NULL, NULL);
 qemu_coroutine_enter(data->co);
 }
 
@@ -83,8 +84,10 @@ void coroutine_fn yield_until_fd_readable(int fd)
 FDYieldUntilData data;
 
 assert(qemu_in_coroutine());
+data.ctx = qemu_get_current_aio_context();
 data.co = qemu_coroutine_self();
 data.fd = fd;
-qemu_set_fd_handler(fd, fd_coroutine_enter, NULL, );
+aio_set_fd_handler(
+data.ctx, fd, false, fd_coroutine_enter, NULL, NULL, );
 qemu_coroutine_yield();
 }
-- 
2.20.1




[PATCH qemu] spapr: Add /choses to FDT only at reset time to preserve kernel and initramdisk

2019-10-23 Thread Alexey Kardashevskiy
Since "spapr: Render full FDT on ibm,client-architecture-support" we build
the entire flatten device tree (FDT) twice - at the reset time and
when "ibm,client-architecture-support" (CAS) is called. The full FDT from
CAS is then applied on top of the SLOF internal device tree.

This is mostly ok, however there is a case when the QEMU is started with
-initrd and for some reason the guest decided to move/unpack the init RAM
disk image - the guest correctly notifies SLOF about the change but
at CAS it is overridden with the QEMU initial location addresses and
the guest may fail to boot if the original initrd memory was changed.

This fixes the problem by only adding the /chosen node at the reset time
to prevent the original QEMU's linux,initrd-start/linux,initrd-end to
override the updated addresses.

This only treats /chosen differently as we know there is a special case
already and it is unlikely anything else will need to change /chosen at CAS
we are better off not touching /chosen after we handed it over to SLOF.

Signed-off-by: Alexey Kardashevskiy 
---
 hw/ppc/spapr.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index d4c07a9b1bab..0580789a1509 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -925,7 +925,7 @@ static bool spapr_hotplugged_dev_before_cas(void)
 return false;
 }
 
-static void *spapr_build_fdt(SpaprMachineState *spapr);
+static void *spapr_build_fdt(SpaprMachineState *spapr, bool reset);
 
 int spapr_h_cas_compose_response(SpaprMachineState *spapr,
  target_ulong addr, target_ulong size,
@@ -947,7 +947,7 @@ int spapr_h_cas_compose_response(SpaprMachineState *spapr,
 
 size -= sizeof(hdr);
 
-fdt = spapr_build_fdt(spapr);
+fdt = spapr_build_fdt(spapr, false);
 _FDT((fdt_pack(fdt)));
 
 if (fdt_totalsize(fdt) + sizeof(hdr) > size) {
@@ -1205,7 +1205,7 @@ static void spapr_dt_hypervisor(SpaprMachineState *spapr, 
void *fdt)
 }
 }
 
-static void *spapr_build_fdt(SpaprMachineState *spapr)
+static void *spapr_build_fdt(SpaprMachineState *spapr, bool reset)
 {
 MachineState *machine = MACHINE(spapr);
 MachineClass *mc = MACHINE_GET_CLASS(machine);
@@ -1305,7 +1305,9 @@ static void *spapr_build_fdt(SpaprMachineState *spapr)
 spapr_dt_rtas(spapr, fdt);
 
 /* /chosen */
-spapr_dt_chosen(spapr, fdt);
+if (reset) {
+spapr_dt_chosen(spapr, fdt);
+}
 
 /* /hypervisor */
 if (kvm_enabled()) {
@@ -1313,11 +1315,14 @@ static void *spapr_build_fdt(SpaprMachineState *spapr)
 }
 
 /* Build memory reserve map */
-if (spapr->kernel_size) {
-_FDT((fdt_add_mem_rsv(fdt, KERNEL_LOAD_ADDR, spapr->kernel_size)));
-}
-if (spapr->initrd_size) {
-_FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base, spapr->initrd_size)));
+if (reset) {
+if (spapr->kernel_size) {
+_FDT((fdt_add_mem_rsv(fdt, KERNEL_LOAD_ADDR, spapr->kernel_size)));
+}
+if (spapr->initrd_size) {
+_FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base,
+  spapr->initrd_size)));
+}
 }
 
 /* ibm,client-architecture-support updates */
@@ -1726,7 +1731,7 @@ static void spapr_machine_reset(MachineState *machine)
  */
 fdt_addr = MIN(spapr->rma_size, RTAS_MAX_ADDR) - FDT_MAX_SIZE;
 
-fdt = spapr_build_fdt(spapr);
+fdt = spapr_build_fdt(spapr, true);
 
 rc = fdt_pack(fdt);
 
-- 
2.17.1




Re: [PATCH] virtio: notify virtqueue via host notifier when available

2019-10-23 Thread Yongji Xie
On Mon, 21 Oct 2019 at 19:40, Stefan Hajnoczi  wrote:
>
> Host notifiers are used in several cases:
> 1. Traditional ioeventfd where virtqueue notifications are handled in
>the main loop thread.
> 2. IOThreads (aio_handle_output) where virtqueue notifications are
>handled in an IOThread AioContext.
> 3. vhost where virtqueue notifications are handled by kernel vhost or
>a vhost-user device backend.
>
> Most virtqueue notifications from the guest use the ioeventfd mechanism,
> but there are corner cases where QEMU code calls virtio_queue_notify().
> This currently honors the host notifier for the IOThreads
> aio_handle_output case, but not for the vhost case.  The result is that
> vhost does not receive virtqueue notifications from QEMU when
> virtio_queue_notify() is called.
>
> This patch extends virtio_queue_notify() to set the host notifier
> whenever it is enabled instead of calling the vq->(aio_)handle_output()
> function directly.
>
> This fixes the vhost case although it does add a trip through the
> eventfd for the traditional ioeventfd case.  I don't think it's worth
> adding a fast path for the traditional ioeventfd case because calling
> virtio_queue_notify() is rare when ioeventfd is enabled.
>
> Reported-by: Felipe Franciosi 
> Signed-off-by: Stefan Hajnoczi 
> ---
> Felipe and Yongji: Only tested with "make check".  Please try
> vhost-user-scsi/blk and let us know if it fixes the issue.
>

I can see the vhost-user-blk issue is fixed by this patch after the
below patch applied:

diff --git a/hw/virtio/vhost-user-blk-pci.c b/hw/virtio/vhost-user-blk-pci.c
index 1dc834a..a32a439 100644
--- a/hw/virtio/vhost-user-blk-pci.c
+++ b/hw/virtio/vhost-user-blk-pci.c
@@ -46,6 +46,8 @@ static Property vhost_user_blk_pci_properties[] = {
 DEFINE_PROP_UINT32("class", VirtIOPCIProxy, class_code, 0),
 DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
DEV_NVECTORS_UNSPECIFIED),
+DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
 DEFINE_PROP_END_OF_LIST(),
 };

>  include/hw/virtio/virtio-bus.h | 7 +++
>  hw/virtio/virtio.c | 4 +++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/virtio/virtio-bus.h b/include/hw/virtio/virtio-bus.h
> index 38c9399cd4..28ca51cb4c 100644
> --- a/include/hw/virtio/virtio-bus.h
> +++ b/include/hw/virtio/virtio-bus.h
> @@ -139,6 +139,13 @@ static inline VirtIODevice 
> *virtio_bus_get_device(VirtioBusState *bus)
>
>  /* Return whether the proxy allows ioeventfd.  */
>  bool virtio_bus_ioeventfd_enabled(VirtioBusState *bus);
> +
> +/* Return whether ioeventfd has been started. */
> +static inline bool virtio_bus_ioeventfd_started(VirtioBusState *bus)
> +{
> +return bus->ioeventfd_started;
> +}
> +
>  /* Start the ioeventfd. */
>  int virtio_bus_start_ioeventfd(VirtioBusState *bus);
>  /* Stop the ioeventfd. */
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 527df03bfd..abdcec00cd 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -1567,6 +1567,8 @@ static void virtio_queue_notify_vq(VirtQueue *vq)
>
>  void virtio_queue_notify(VirtIODevice *vdev, int n)
>  {
> +BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
> +VirtioBusState *vbus = VIRTIO_BUS(qbus);
>  VirtQueue *vq = >vq[n];
>
>  if (unlikely(!vq->vring.desc || vdev->broken)) {
> @@ -1574,7 +1576,7 @@ void virtio_queue_notify(VirtIODevice *vdev, int n)
>  }
>
>  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> -if (vq->handle_aio_output) {
> +if (virtio_bus_ioeventfd_started(vbus)) {

Need to check whether vq->host_notifier is valid or not here.
Otherwise, it could break the ctrl_vq in vhost_net device.

Thanks,
Yongji



RE: [RFC PATCH 1/4] net/awd.c: Introduce Advanced Watch Dog module framework

2019-10-23 Thread Zhang, Chen

> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Wednesday, October 23, 2019 7:39 PM
> To: Zhang, Chen ; Jason Wang
> ; Paolo Bonzini ; qemu-
> dev 
> Cc: Zhang Chen 
> Subject: Re: [RFC PATCH 1/4] net/awd.c: Introduce Advanced Watch Dog
> module framework
> 
> On 10/23/19 1:09 PM, Zhang, Chen wrote:
> >> -Original Message-
> >> From: Philippe Mathieu-Daudé 
> >> Sent: Wednesday, October 23, 2019 7:01 PM
> >> To: Zhang, Chen ; Jason Wang
> >> ; Paolo Bonzini ; qemu-
> dev
> >> 
> >> Cc: Zhang Chen 
> >> Subject: Re: [RFC PATCH 1/4] net/awd.c: Introduce Advanced Watch Dog
> >> module framework
> >>
> >> Hi Chen,
> >>
> >> On 10/16/19 1:22 PM, Zhang Chen wrote:
> >>> From: Zhang Chen 
> >>>
> >>> This patch introduce a new module named Advanced Watch Dog, and
> >>> defined the input and output parameter. AWD use standard chardev as
> >>> the way of communicationg with the outside world.
> >>> Demo command:
> >>> -object
> >>> advanced-
> >> watchdog,id=heart1,server=on,awd_node=h1,notification_node=he
> >>> artbeat0,opt_script=opt_script_path,iothread=iothread1,pulse_interva
> >>> l=
> >>> 1000,timeout=5000
> >>>
> >>> Signed-off-by: Zhang Chen 
> >>> ---
> >>>net/Makefile.objs |   1 +
> >>>net/awd.c | 261
> >> ++
> >>>qemu-options.hx   |   6 ++
> >>>3 files changed, 268 insertions(+)
> >>>create mode 100644 net/awd.c
> >>>
> >>> diff --git a/net/Makefile.objs b/net/Makefile.objs index
> >>> c5d076d19c..139b1394e9 100644
> >>> --- a/net/Makefile.objs
> >>> +++ b/net/Makefile.objs
> >>> @@ -19,6 +19,7 @@ common-obj-y += colo-compare.o
> >>>common-obj-y += colo.o
> >>>common-obj-y += filter-rewriter.o
> >>>common-obj-y += filter-replay.o
> >>> +common-obj-y += awd.o
> >> Can you add a net/Kconfig file introducing the ADVANCED_WATCHDOG
> >> selector?
> >>
> >> config COLO_ADVANCED_WATCHDOG
> >>   bool
> >>   default n
> >>
> >> Then use here:
> >>
> >>   common-obj-$(COLO_ADVANCED_WATCHDOG) += awd.o
> >>
> >
> > Sure, but AWD is a universal module,  COLO is just the first user.
> > Maybe use "config ADVANCED_WATCHDOG" is better.
> 
> Oh I see, better then.
> 
> Then we might add (later)
> 
>config COLO
>...
>select ADVANCED_WATCHDOG
> 

I noticed that we haven't the "net/kconfig" file, the AWD isn't a HW in the 
hw/net.
Do you means we can add the selector in "configuration" file?
We can add some related configuration command like "--enable-advanced-watchdog" 
and default is "no".

Thanks
Zhang Chen

> Thanks!
> 
> Phil.
> 
> >>>tap-obj-$(CONFIG_LINUX) = tap-linux.o
> >>>tap-obj-$(CONFIG_BSD) = tap-bsd.o
> >> [...]


Re: [PATCH 1/6] ppc: Add intc_destroy() handlers to SpaprInterruptController/PnvChip

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 04:51:59PM +0200, Greg Kurz wrote:
> SpaprInterruptControllerClass and PnvChipClass have an intc_create() method
> that calls the appropriate routine, ie. icp_create() or xive_tctx_create(),
> to establish the link between the VCPU and the presenter component of the
> interrupt controller during realize.
> 
> There aren't any symmetrical call to be called when the VCPU gets unrealized
> though. It is assumed that object_unparent() is the only thing to do.
> 
> This is questionable because the parenting logic around the CPU and
> presenter objects is really an implementation detail of the interrupt
> controller. It shouldn't be open-coded in the machine code.
> 
> Fix this by adding an intc_destroy() method that undoes what was done in
> intc_create().
> 
> Signed-off-by: Greg Kurz 

I think it would be good to set the pointers in spapr_cpu_state() to
NULL at the point of destroy.  It probably won't matter, since this
happens in a path where the cpu's about to go away.  But still,
leaving a stale pointer around a moment more than necessary makes me
anxious.

> ---
>  hw/intc/spapr_xive.c   |7 +++
>  hw/intc/xics.c |5 +
>  hw/intc/xics_spapr.c   |7 +++
>  hw/intc/xive.c |5 +
>  hw/ppc/pnv.c   |   15 +++
>  hw/ppc/pnv_core.c  |7 ---
>  hw/ppc/spapr_cpu_core.c|7 +--
>  hw/ppc/spapr_irq.c |   14 ++
>  include/hw/ppc/pnv.h   |1 +
>  include/hw/ppc/spapr_irq.h |2 ++
>  include/hw/ppc/xics.h  |1 +
>  include/hw/ppc/xive.h  |1 +
>  12 files changed, 63 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index d8e1291905c3..b09cc48bcb61 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -555,6 +555,12 @@ static void 
> spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
>  xive_tctx_set_os_cam(tctx, xive_nvt_cam_line(nvt_blk, nvt_idx));
>  }
>  
> +static void spapr_xive_cpu_intc_destroy(SpaprInterruptController *intc,
> +PowerPCCPU *cpu)
> +{
> +xive_tctx_destroy(spapr_cpu_state(cpu)->tctx);
> +}
> +
>  static void spapr_xive_set_irq(SpaprInterruptController *intc, int irq, int 
> val)
>  {
>  SpaprXive *xive = SPAPR_XIVE(intc);
> @@ -692,6 +698,7 @@ static void spapr_xive_class_init(ObjectClass *klass, 
> void *data)
>  sicc->deactivate = spapr_xive_deactivate;
>  sicc->cpu_intc_create = spapr_xive_cpu_intc_create;
>  sicc->cpu_intc_reset = spapr_xive_cpu_intc_reset;
> +sicc->cpu_intc_destroy = spapr_xive_cpu_intc_destroy;
>  sicc->claim_irq = spapr_xive_claim_irq;
>  sicc->free_irq = spapr_xive_free_irq;
>  sicc->set_irq = spapr_xive_set_irq;
> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> index 6da05763f9db..935f325749cb 100644
> --- a/hw/intc/xics.c
> +++ b/hw/intc/xics.c
> @@ -401,6 +401,11 @@ Object *icp_create(Object *cpu, const char *type, 
> XICSFabric *xi, Error **errp)
>  return obj;
>  }
>  
> +void icp_destroy(ICPState *icp)
> +{
> +object_unparent(OBJECT(icp));
> +}
> +
>  /*
>   * ICS: Source layer
>   */
> diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
> index 7418fb9f370c..5977d1bdb73f 100644
> --- a/hw/intc/xics_spapr.c
> +++ b/hw/intc/xics_spapr.c
> @@ -352,6 +352,12 @@ static void 
> xics_spapr_cpu_intc_reset(SpaprInterruptController *intc,
>  icp_reset(spapr_cpu_state(cpu)->icp);
>  }
>  
> +static void xics_spapr_cpu_intc_destroy(SpaprInterruptController *intc,
> +PowerPCCPU *cpu)
> +{
> +icp_destroy(spapr_cpu_state(cpu)->icp);
> +}
> +
>  static int xics_spapr_claim_irq(SpaprInterruptController *intc, int irq,
>  bool lsi, Error **errp)
>  {
> @@ -440,6 +446,7 @@ static void ics_spapr_class_init(ObjectClass *klass, void 
> *data)
>  sicc->deactivate = xics_spapr_deactivate;
>  sicc->cpu_intc_create = xics_spapr_cpu_intc_create;
>  sicc->cpu_intc_reset = xics_spapr_cpu_intc_reset;
> +sicc->cpu_intc_destroy = xics_spapr_cpu_intc_destroy;
>  sicc->claim_irq = xics_spapr_claim_irq;
>  sicc->free_irq = xics_spapr_free_irq;
>  sicc->set_irq = xics_spapr_set_irq;
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index f066be5eb5e3..38257aa02083 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -696,6 +696,11 @@ error:
>  return NULL;
>  }
>  
> +void xive_tctx_destroy(XiveTCTX *tctx)
> +{
> +object_unparent(OBJECT(tctx));
> +}
> +
>  /*
>   * XIVE ESB helpers
>   */
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 4a51fb65a834..bd17c3536dd5 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -778,6 +778,7 @@ static void pnv_chip_power8_intc_create(PnvChip *chip, 
> PowerPCCPU *cpu,
>  pnv_cpu->intc = obj;
>  }
>  
> +
>  static void pnv_chip_power8_intc_reset(PnvChip *chip, PowerPCCPU *cpu)
>  {
>  PnvCPUState *pnv_cpu 

Re: [PATCH 4/6] qom: Add object_child_foreach_type() helper function

2019-10-23 Thread David Gibson
On Thu, Oct 24, 2019 at 01:59:03PM +1100, David Gibson wrote:
> On Wed, Oct 23, 2019 at 04:52:16PM +0200, Greg Kurz wrote:
> > Calling a function for children of a certain type is a recurring pattern
> > in the QEMU code base. In order to avoid the need to setup the same boiler
> > plate again and again, introduce a variant of object_child_foreach() that
> > only considers children of the given type.
> > 
> > Signed-off-by: Greg Kurz 
> 
> Reviewed-by: David Gibson 

Actually.. a couuple of caveats on that.

Reading it again the name is potentially misleading it's "for each
object of given type" not "for each type"  So maybe
"object_child_foreach_of_type()".

Also, having created these, using them to simplify hmp_info_irq() and
hmp_info_pic() seems like a good idea.

> 
> > ---
> >  include/qom/object.h |   35 +++
> >  qom/object.c |   30 +++---
> >  2 files changed, 58 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/qom/object.h b/include/qom/object.h
> > index 128d00c77fd6..e9e3c2eae8ed 100644
> > --- a/include/qom/object.h
> > +++ b/include/qom/object.h
> > @@ -1728,6 +1728,41 @@ int object_child_foreach(Object *obj, int 
> > (*fn)(Object *child, void *opaque),
> >  int object_child_foreach_recursive(Object *obj,
> > int (*fn)(Object *child, void *opaque),
> > void *opaque);
> > +
> > +/**
> > + * object_child_foreach_type:
> > + * @obj: the object whose children will be navigated
> > + * @typename: the type of child objects to consider
> > + * @fn: the iterator function to be called
> > + * @opaque: an opaque value that will be passed to the iterator
> > + *
> > + * This is similar to object_child_foreach, but it only calls @fn for
> > + * child objects of the give @typename.
> > + *
> > + * Returns: The last value returned by @fn, or 0 if there is no child of
> > + * the given @typename.
> > + */
> > +int object_child_foreach_type(Object *obj, const char *typename,
> > +  int (*fn)(Object *child, void *opaque),
> > +  void *opaque);
> > +
> > +/**
> > + * object_child_foreach_recursive_type:
> > + * @obj: the object whose children will be navigated
> > + * @typename: the type of child objects to consider
> > + * @fn: the iterator function to be called
> > + * @opaque: an opaque value that will be passed to the iterator
> > + *
> > + * This is similar to object_child_foreach_recursive, but it only calls
> > + * @fn for child objects of the give @typename.
> > + *
> > + * Returns: The last value returned by @fn, or 0 if there is no child of
> > + * the given @typename.
> > + */
> > +int object_child_foreach_recursive_type(Object *obj, const char *typename,
> > +int (*fn)(Object *child, void 
> > *opaque),
> > +void *opaque);
> > +
> >  /**
> >   * container_get:
> >   * @root: root of the #path, e.g., object_get_root()
> > diff --git a/qom/object.c b/qom/object.c
> > index 6fa9c619fac4..a2dec1261ff7 100644
> > --- a/qom/object.c
> > +++ b/qom/object.c
> > @@ -986,7 +986,7 @@ void object_class_foreach(void (*fn)(ObjectClass 
> > *klass, void *opaque),
> >  enumerating_types = false;
> >  }
> >  
> > -static int do_object_child_foreach(Object *obj,
> > +static int do_object_child_foreach(Object *obj, const char *typename,
> > int (*fn)(Object *child, void *opaque),
> > void *opaque, bool recurse)
> >  {
> > @@ -999,12 +999,14 @@ static int do_object_child_foreach(Object *obj,
> >  if (object_property_is_child(prop)) {
> >  Object *child = prop->opaque;
> >  
> > -ret = fn(child, opaque);
> > -if (ret != 0) {
> > -break;
> > +if (!typename || object_dynamic_cast(child, typename)) {
> > +ret = fn(child, opaque);
> > +if (ret != 0) {
> > +break;
> > +}
> >  }
> >  if (recurse) {
> > -do_object_child_foreach(child, fn, opaque, true);
> > +do_object_child_foreach(child, typename, fn, opaque, true);
> >  }
> >  }
> >  }
> > @@ -1014,14 +1016,28 @@ static int do_object_child_foreach(Object *obj,
> >  int object_child_foreach(Object *obj, int (*fn)(Object *child, void 
> > *opaque),
> >   void *opaque)
> >  {
> > -return do_object_child_foreach(obj, fn, opaque, false);
> > +return do_object_child_foreach(obj, NULL, fn, opaque, false);
> >  }
> >  
> >  int object_child_foreach_recursive(Object *obj,
> > int (*fn)(Object *child, void *opaque),
> > void *opaque)
> >  {
> > -return do_object_child_foreach(obj, fn, opaque, true);
> > +

Re: [PATCH v5 7/7] spapr/xive: Set the OS CAM line at reset

2019-10-23 Thread David Gibson
On Tue, Oct 22, 2019 at 06:38:12PM +0200, Cédric Le Goater wrote:
> When a Virtual Processor is scheduled to run on a HW thread, the
> hypervisor pushes its identifier in the OS CAM line. When running with
> kernel_irqchip=off, QEMU needs to emulate the same behavior.
> 
> Set the OS CAM line when the interrupt presenter of the sPAPR core is
> reset. This will also cover the case of hot-plugged CPUs.
> 
> This change also has the benefit to remove the use of CPU_FOREACH()
> which can be unsafe.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: Greg Kurz 

Since the values here should remain constant for the lifetime of a
(PAPR) guest, it kind of seems like this belongs more in realize()
than reset.  But this definitely fixes a real problem, so that's
somethine we can tweak later.

> ---
>  include/hw/ppc/spapr_xive.h |  1 -
>  hw/intc/spapr_xive.c| 48 +
>  2 files changed, 17 insertions(+), 32 deletions(-)
> 
> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> index d84bd5c229f0..742b7e834f2a 100644
> --- a/include/hw/ppc/spapr_xive.h
> +++ b/include/hw/ppc/spapr_xive.h
> @@ -57,7 +57,6 @@ typedef struct SpaprXive {
>  void spapr_xive_pic_print_info(SpaprXive *xive, Monitor *mon);
>  
>  void spapr_xive_hcall_init(SpaprMachineState *spapr);
> -void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx);
>  void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool enable);
>  void spapr_xive_map_mmio(SpaprXive *xive);
>  
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 20a8d8285f64..d8e1291905c3 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -205,23 +205,6 @@ void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool 
> enable)
>  memory_region_set_enabled(>end_source.esb_mmio, false);
>  }
>  
> -/*
> - * When a Virtual Processor is scheduled to run on a HW thread, the
> - * hypervisor pushes its identifier in the OS CAM line. Emulate the
> - * same behavior under QEMU.
> - */
> -void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx)
> -{
> -uint8_t  nvt_blk;
> -uint32_t nvt_idx;
> -uint32_t nvt_cam;
> -
> -spapr_xive_cpu_to_nvt(POWERPC_CPU(tctx->cs), _blk, _idx);
> -
> -nvt_cam = cpu_to_be32(TM_QW1W2_VO | xive_nvt_cam_line(nvt_blk, nvt_idx));
> -memcpy(>regs[TM_QW1_OS + TM_WORD2], _cam, 4);
> -}
> -
>  static void spapr_xive_end_reset(XiveEND *end)
>  {
>  memset(end, 0, sizeof(*end));
> @@ -544,21 +527,32 @@ static int 
> spapr_xive_cpu_intc_create(SpaprInterruptController *intc,
>  }
>  
>  spapr_cpu->tctx = XIVE_TCTX(obj);
> -
> -/*
> - * (TCG) Early setting the OS CAM line for hotplugged CPUs as they
> - * don't beneficiate from the reset of the XIVE IRQ backend
> - */
> -spapr_xive_set_tctx_os_cam(spapr_cpu->tctx);
>  return 0;
>  }
>  
> +static void xive_tctx_set_os_cam(XiveTCTX *tctx, uint32_t os_cam)
> +{
> +uint32_t qw1w2 = cpu_to_be32(TM_QW1W2_VO | os_cam);
> +memcpy(>regs[TM_QW1_OS + TM_WORD2], , 4);
> +}
> +
>  static void spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
>   PowerPCCPU *cpu)
>  {
>  XiveTCTX *tctx = spapr_cpu_state(cpu)->tctx;
> +uint8_t  nvt_blk;
> +uint32_t nvt_idx;
>  
>  xive_tctx_reset(tctx);
> +
> +/*
> + * When a Virtual Processor is scheduled to run on a HW thread,
> + * the hypervisor pushes its identifier in the OS CAM line.
> + * Emulate the same behavior under QEMU.
> + */
> +spapr_xive_cpu_to_nvt(cpu, _blk, _idx);
> +
> +xive_tctx_set_os_cam(tctx, xive_nvt_cam_line(nvt_blk, nvt_idx));
>  }
>  
>  static void spapr_xive_set_irq(SpaprInterruptController *intc, int irq, int 
> val)
> @@ -651,14 +645,6 @@ static void spapr_xive_dt(SpaprInterruptController 
> *intc, uint32_t nr_servers,
>  static int spapr_xive_activate(SpaprInterruptController *intc, Error **errp)
>  {
>  SpaprXive *xive = SPAPR_XIVE(intc);
> -CPUState *cs;
> -
> -CPU_FOREACH(cs) {
> -PowerPCCPU *cpu = POWERPC_CPU(cs);
> -
> -/* (TCG) Set the OS CAM line of the thread interrupt context. */
> -spapr_xive_set_tctx_os_cam(spapr_cpu_state(cpu)->tctx);
> -}
>  
>  if (kvm_enabled()) {
>  int rc = spapr_irq_init_kvm(kvmppc_xive_connect, intc, errp);

-- 
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 5/6] spapr: Don't use CPU_FOREACH() in 'info pic'

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 04:52:21PM +0200, Greg Kurz wrote:
> Now that presenter objects are parented to the interrupt controller, stop
> relying on CPU_FOREACH() which can race with CPU hotplug and crash QEMU.
> 
> Signed-off-by: Greg Kurz 

So.. we might be able to go further than this.  Having the
TYPE_INTERRUPT_STATS_PROVIDER interrupt on the machine is actually an
spapr and pnv oddity.  In most cases that interface is on the various
components of the interrupt controller directly.  hmp_info_irq() scans
the whole QOM tree looking for everything with the interface to
produce the info pic output.

It would be nice if we can do the same for xics and xive.  The tricky
bit is that we do have the possibility of both, in which case the
individual components would need to know if they're currently "active"
and minimize their output if so.

> ---
>  hw/intc/spapr_xive.c  |8 +---
>  hw/intc/xics.c|   12 
>  hw/intc/xics_spapr.c  |8 +---
>  hw/intc/xive.c|   12 
>  include/hw/ppc/xics.h |1 +
>  include/hw/ppc/xive.h |2 ++
>  6 files changed, 29 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index d74ee71e76b4..05763a58cf5d 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -579,14 +579,8 @@ static void spapr_xive_set_irq(SpaprInterruptController 
> *intc, int irq, int val)
>  static void spapr_xive_print_info(SpaprInterruptController *intc, Monitor 
> *mon)
>  {
>  SpaprXive *xive = SPAPR_XIVE(intc);
> -CPUState *cs;
> -
> -CPU_FOREACH(cs) {
> -PowerPCCPU *cpu = POWERPC_CPU(cs);
> -
> -xive_tctx_pic_print_info(spapr_cpu_state(cpu)->tctx, mon);
> -}
>  
> +xive_presenter_print_info(XIVE_ROUTER(intc), mon);
>  spapr_xive_pic_print_info(xive, mon);
>  }
>  
> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> index d5e4db668a4b..6e820c4851f3 100644
> --- a/hw/intc/xics.c
> +++ b/hw/intc/xics.c
> @@ -88,6 +88,18 @@ void ics_pic_print_info(ICSState *ics, Monitor *mon)
>  }
>  }
>  
> +static int do_ics_pic_print_icp_infos(Object *child, void *opaque)
> +{
> +icp_pic_print_info(ICP(child), opaque);
> +return 0;
> +}
> +
> +void ics_pic_print_icp_infos(ICSState *ics, const char *type, Monitor *mon)
> +{
> +object_child_foreach_type(OBJECT(ics), type, do_ics_pic_print_icp_infos,
> +  mon);
> +}
> +
>  /*
>   * ICP: Presentation layer
>   */
> diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
> index 080ed73aad64..7624d693c8da 100644
> --- a/hw/intc/xics_spapr.c
> +++ b/hw/intc/xics_spapr.c
> @@ -400,14 +400,8 @@ static void xics_spapr_set_irq(SpaprInterruptController 
> *intc, int irq, int val)
>  static void xics_spapr_print_info(SpaprInterruptController *intc, Monitor 
> *mon)
>  {
>  ICSState *ics = ICS_SPAPR(intc);
> -CPUState *cs;
> -
> -CPU_FOREACH(cs) {
> -PowerPCCPU *cpu = POWERPC_CPU(cs);
> -
> -icp_pic_print_info(spapr_cpu_state(cpu)->icp, mon);
> -}
>  
> +ics_pic_print_icp_infos(ics, TYPE_ICP, mon);
>  ics_pic_print_info(ics, mon);
>  }
>  
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 8d2da4a11163..40ce43152456 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -547,6 +547,18 @@ void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor 
> *mon)
>  }
>  }
>  
> +static int do_xive_presenter_print_info(Object *child, void *opaque)
> +{
> +xive_tctx_pic_print_info(XIVE_TCTX(child), opaque);
> +return 0;
> +}
> +
> +void xive_presenter_print_info(XiveRouter *xrtr, Monitor *mon)
> +{
> +object_child_foreach_type(OBJECT(xrtr), TYPE_XIVE_TCTX,
> +  do_xive_presenter_print_info, mon);
> +}
> +
>  void xive_tctx_reset(XiveTCTX *tctx)
>  {
>  memset(tctx->regs, 0, sizeof(tctx->regs));
> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
> index f4827e748fd8..4de1f421c997 100644
> --- a/include/hw/ppc/xics.h
> +++ b/include/hw/ppc/xics.h
> @@ -175,6 +175,7 @@ static inline bool ics_irq_free(ICSState *ics, uint32_t 
> srcno)
>  void ics_set_irq_type(ICSState *ics, int srcno, bool lsi);
>  void icp_pic_print_info(ICPState *icp, Monitor *mon);
>  void ics_pic_print_info(ICSState *ics, Monitor *mon);
> +void ics_pic_print_icp_infos(ICSState *ics, const char *type, Monitor *mon);
>  
>  void ics_resend(ICSState *ics);
>  void icp_resend(ICPState *ss);
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index 8fd439ec9bba..14690428a0aa 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -367,6 +367,8 @@ int xive_router_write_nvt(XiveRouter *xrtr, uint8_t 
> nvt_blk, uint32_t nvt_idx,
>  XiveTCTX *xive_router_get_tctx(XiveRouter *xrtr, CPUState *cs);
>  void xive_router_notify(XiveNotifier *xn, uint32_t lisn);
>  
> +void xive_presenter_print_info(XiveRouter *xrtr, Monitor *mon);
> +
>  /*
>   * XIVE END ESBs
>   */
> 

-- 
David Gibson| I'll have my music 

Re: [PATCH 3/6] ppc: Reparent presenter objects to the interrupt controller object

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 04:52:10PM +0200, Greg Kurz wrote:
> Each VCPU is associated to a presenter object within the interrupt
> controller, ie. TCTX for XIVE and ICP for XICS, but our current
> models put these objects below the VCPU, and we rely on CPU_FOREACH()
> to do anything that involves presenters.
> 
> This recently bit us with the CAM line matching logic in XIVE because
> CPU_FOREACH() can race with CPU hotplug and we ended up considering a
> VCPU that wasn't associated to a TCTX object yet. Other users of
> CPU_FOREACH() are 'info pic' for both XICS and XIVE. It is again very
> easy to crash QEMU with concurrent VCPU hotplug/unplug and 'info pic'.
> 
> Reparent the presenter objects to the corresponding interrupt controller
> object, ie. XIVE router or ICS, to make it clear they are not some extra
> data hanging from the CPU but internal XIVE or XICS entities. The CPU
> object now needs to explicitely take a reference on the presenter to
> ensure its pointer remains valid until unrealize time.
> 
> This will allow to get rid of CPU_FOREACH() and ease further improvements
> to the XIVE model.
> 
> This change doesn't impact section ids and is thus transparent to
> migration.
> 
> Signed-off-by: Greg Kurz 


Urgh.  I see why we want something like this, but reparenting the
presenters to the source modules (particularly for XICS) makes me
uncomfortable.

AFAICT the association here is *purely* about managing lifetimes, not
because those ICPs inherently have something to do with those ICSes.
Same with XIVE, although since they'll be on the same chip there's a
bit more logic to it.

For spapr we kinda-sorta treat the (single) ICS or XiveRouter object
as the "master" of the interrupt controller.  But that's not really
accurate to the hardware, so I don't really want to push that way of
looking at it any further than it already is.

If we could make the presenters children of the machine (spapr) or
chip (pnv) that might make more sense?

I'm also not totally convinced that having the presenter as a child of
the cpu is inherently bad.  Yes we have bugs now, but maybe the right
fix *is* actually to do the NULL check on every CPU_FOREACH().

For comparison, the lapic on x86 machines is a child of the cpu, and I
believe they do have NULL checks on cpu->apic_state in various places
they use CPU_FOREACH().

> ---
>  hw/intc/spapr_xive.c  |6 +-
>  hw/intc/xics.c|7 +--
>  hw/intc/xics_spapr.c  |8 ++--
>  hw/intc/xive.c|4 +++-
>  hw/ppc/pnv.c  |   17 +
>  include/hw/ppc/xics.h |2 +-
>  6 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index b09cc48bcb61..d74ee71e76b4 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -526,6 +526,7 @@ static int 
> spapr_xive_cpu_intc_create(SpaprInterruptController *intc,
>  return -1;
>  }
>  
> +object_ref(obj);
>  spapr_cpu->tctx = XIVE_TCTX(obj);
>  return 0;
>  }
> @@ -558,7 +559,10 @@ static void 
> spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
>  static void spapr_xive_cpu_intc_destroy(SpaprInterruptController *intc,
>  PowerPCCPU *cpu)
>  {
> -xive_tctx_destroy(spapr_cpu_state(cpu)->tctx);
> +XiveTCTX *tctx = spapr_cpu_state(cpu)->tctx;
> +
> +object_unref(OBJECT(tctx));
> +xive_tctx_destroy(tctx);
>  }
>  
>  static void spapr_xive_set_irq(SpaprInterruptController *intc, int irq, int 
> val)
> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> index 5f746079be46..d5e4db668a4b 100644
> --- a/hw/intc/xics.c
> +++ b/hw/intc/xics.c
> @@ -380,13 +380,16 @@ static const TypeInfo icp_info = {
>  .class_size = sizeof(ICPStateClass),
>  };
>  
> -Object *icp_create(Object *cpu, const char *type, XICSFabric *xi, Error 
> **errp)
> +Object *icp_create(Object *cpu, const char *type, ICSState *ics, XICSFabric 
> *xi,
> +   Error **errp)
>  {
>  Error *local_err = NULL;
> +g_autofree char *name = NULL;
>  Object *obj;
>  
>  obj = object_new(type);
> -object_property_add_child(cpu, type, obj, _abort);
> +name = g_strdup_printf("%s[%d]", type, CPU(cpu)->cpu_index);
> +object_property_add_child(OBJECT(ics), name, obj, _abort);
>  object_unref(obj);
>  object_ref(OBJECT(xi));
>  object_property_add_const_link(obj, ICP_PROP_XICS, OBJECT(xi),
> diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
> index 5977d1bdb73f..080ed73aad64 100644
> --- a/hw/intc/xics_spapr.c
> +++ b/hw/intc/xics_spapr.c
> @@ -337,11 +337,12 @@ static int 
> xics_spapr_cpu_intc_create(SpaprInterruptController *intc,
>  Object *obj;
>  SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
>  
> -obj = icp_create(OBJECT(cpu), TYPE_ICP, ics->xics, errp);
> +obj = icp_create(OBJECT(cpu), TYPE_ICP, ics, ics->xics, errp);
>  if (!obj) {
>  return -1;
>  }
>  
> +object_ref(obj);
>  

Re: [PATCH 4/6] qom: Add object_child_foreach_type() helper function

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 04:52:16PM +0200, Greg Kurz wrote:
> Calling a function for children of a certain type is a recurring pattern
> in the QEMU code base. In order to avoid the need to setup the same boiler
> plate again and again, introduce a variant of object_child_foreach() that
> only considers children of the given type.
> 
> Signed-off-by: Greg Kurz 

Reviewed-by: David Gibson 

> ---
>  include/qom/object.h |   35 +++
>  qom/object.c |   30 +++---
>  2 files changed, 58 insertions(+), 7 deletions(-)
> 
> diff --git a/include/qom/object.h b/include/qom/object.h
> index 128d00c77fd6..e9e3c2eae8ed 100644
> --- a/include/qom/object.h
> +++ b/include/qom/object.h
> @@ -1728,6 +1728,41 @@ int object_child_foreach(Object *obj, int (*fn)(Object 
> *child, void *opaque),
>  int object_child_foreach_recursive(Object *obj,
> int (*fn)(Object *child, void *opaque),
> void *opaque);
> +
> +/**
> + * object_child_foreach_type:
> + * @obj: the object whose children will be navigated
> + * @typename: the type of child objects to consider
> + * @fn: the iterator function to be called
> + * @opaque: an opaque value that will be passed to the iterator
> + *
> + * This is similar to object_child_foreach, but it only calls @fn for
> + * child objects of the give @typename.
> + *
> + * Returns: The last value returned by @fn, or 0 if there is no child of
> + * the given @typename.
> + */
> +int object_child_foreach_type(Object *obj, const char *typename,
> +  int (*fn)(Object *child, void *opaque),
> +  void *opaque);
> +
> +/**
> + * object_child_foreach_recursive_type:
> + * @obj: the object whose children will be navigated
> + * @typename: the type of child objects to consider
> + * @fn: the iterator function to be called
> + * @opaque: an opaque value that will be passed to the iterator
> + *
> + * This is similar to object_child_foreach_recursive, but it only calls
> + * @fn for child objects of the give @typename.
> + *
> + * Returns: The last value returned by @fn, or 0 if there is no child of
> + * the given @typename.
> + */
> +int object_child_foreach_recursive_type(Object *obj, const char *typename,
> +int (*fn)(Object *child, void 
> *opaque),
> +void *opaque);
> +
>  /**
>   * container_get:
>   * @root: root of the #path, e.g., object_get_root()
> diff --git a/qom/object.c b/qom/object.c
> index 6fa9c619fac4..a2dec1261ff7 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -986,7 +986,7 @@ void object_class_foreach(void (*fn)(ObjectClass *klass, 
> void *opaque),
>  enumerating_types = false;
>  }
>  
> -static int do_object_child_foreach(Object *obj,
> +static int do_object_child_foreach(Object *obj, const char *typename,
> int (*fn)(Object *child, void *opaque),
> void *opaque, bool recurse)
>  {
> @@ -999,12 +999,14 @@ static int do_object_child_foreach(Object *obj,
>  if (object_property_is_child(prop)) {
>  Object *child = prop->opaque;
>  
> -ret = fn(child, opaque);
> -if (ret != 0) {
> -break;
> +if (!typename || object_dynamic_cast(child, typename)) {
> +ret = fn(child, opaque);
> +if (ret != 0) {
> +break;
> +}
>  }
>  if (recurse) {
> -do_object_child_foreach(child, fn, opaque, true);
> +do_object_child_foreach(child, typename, fn, opaque, true);
>  }
>  }
>  }
> @@ -1014,14 +1016,28 @@ static int do_object_child_foreach(Object *obj,
>  int object_child_foreach(Object *obj, int (*fn)(Object *child, void *opaque),
>   void *opaque)
>  {
> -return do_object_child_foreach(obj, fn, opaque, false);
> +return do_object_child_foreach(obj, NULL, fn, opaque, false);
>  }
>  
>  int object_child_foreach_recursive(Object *obj,
> int (*fn)(Object *child, void *opaque),
> void *opaque)
>  {
> -return do_object_child_foreach(obj, fn, opaque, true);
> +return do_object_child_foreach(obj, NULL, fn, opaque, true);
> +}
> +
> +int object_child_foreach_type(Object *obj, const char *typename,
> +  int (*fn)(Object *child, void *opaque),
> +  void *opaque)
> +{
> +return do_object_child_foreach(obj, typename, fn, opaque, false);
> +}
> +
> +int object_child_foreach_recursive_type(Object *obj, const char *typename,
> +int (*fn)(Object *child, void 
> *opaque),
> +void *opaque)
> +{
> +return 

Re: [PATCH 2/6] xive, xics: Fix reference counting on CPU objects

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 04:52:05PM +0200, Greg Kurz wrote:
> When a VCPU gets connected to the XIVE interrupt controller, we add a
> const link targetting the CPU object to the TCTX object. Similar links
> are added to the ICP object when using the XICS interrupt controller.
> 
> As explained in :
> 
>  * The caller must ensure that @target stays alive as long as
>  * this property exists.  In the case @target is a child of @obj,
>  * this will be the case.  Otherwise, the caller is responsible for
>  * taking a reference.
> 
> We're in the latter case for both XICS and XIVE. Add the missing
> calls to object_ref() and object_unref().
> 
> This doesn't fix any known issue because the life cycle of the TCTX or
> ICP happens to be shorter than the one of the CPU or XICS fabric, but
> better safe than sorry.
> 
> Signed-off-by: Greg Kurz 

LGTM
Reviewed-by: David Gibson 

> ---
>  hw/intc/xics.c |8 +++-
>  hw/intc/xive.c |6 +-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> index 935f325749cb..5f746079be46 100644
> --- a/hw/intc/xics.c
> +++ b/hw/intc/xics.c
> @@ -388,8 +388,10 @@ Object *icp_create(Object *cpu, const char *type, 
> XICSFabric *xi, Error **errp)
>  obj = object_new(type);
>  object_property_add_child(cpu, type, obj, _abort);
>  object_unref(obj);
> +object_ref(OBJECT(xi));
>  object_property_add_const_link(obj, ICP_PROP_XICS, OBJECT(xi),
> _abort);
> +object_ref(cpu);
>  object_property_add_const_link(obj, ICP_PROP_CPU, cpu, _abort);
>  object_property_set_bool(obj, true, "realized", _err);
>  if (local_err) {
> @@ -403,7 +405,11 @@ Object *icp_create(Object *cpu, const char *type, 
> XICSFabric *xi, Error **errp)
>  
>  void icp_destroy(ICPState *icp)
>  {
> -object_unparent(OBJECT(icp));
> +Object *obj = OBJECT(icp);
> +
> +object_unref(object_property_get_link(obj, ICP_PROP_CPU, _abort));
> +object_unref(object_property_get_link(obj, ICP_PROP_XICS, _abort));
> +object_unparent(obj);
>  }
>  
>  /*
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 38257aa02083..952a461d5329 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -682,6 +682,7 @@ Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, 
> Error **errp)
>  obj = object_new(TYPE_XIVE_TCTX);
>  object_property_add_child(cpu, TYPE_XIVE_TCTX, obj, _abort);
>  object_unref(obj);
> +object_ref(cpu);
>  object_property_add_const_link(obj, "cpu", cpu, _abort);
>  object_property_set_bool(obj, true, "realized", _err);
>  if (local_err) {
> @@ -698,7 +699,10 @@ error:
>  
>  void xive_tctx_destroy(XiveTCTX *tctx)
>  {
> -object_unparent(OBJECT(tctx));
> +Object *obj = OBJECT(tctx);
> +
> +object_unref(object_property_get_link(obj, "cpu", _abort));
> +object_unparent(obj);
>  }
>  
>  /*
> 

-- 
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 v5 3/7] ppc/pnv: Introduce a PnvCore reset handler

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 01:18:06PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Cédric,
> 
> On 10/22/19 6:38 PM, Cédric Le Goater wrote:
> > in which individual CPUs are reset. It will ease the introduction of
> > future change reseting the interrupt presenter from the CPU reset
> > handler.
> > 
> > Signed-off-by: Cédric Le Goater 
> > Reviewed-by: Greg Kurz 
> > ---
> >   hw/ppc/pnv_core.c | 19 +++
> >   1 file changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
> > index b1a7489e7abf..9f981a4940e6 100644
> > --- a/hw/ppc/pnv_core.c
> > +++ b/hw/ppc/pnv_core.c
> > @@ -40,9 +40,8 @@ static const char *pnv_core_cpu_typename(PnvCore *pc)
> >   return cpu_type;
> >   }
> > -static void pnv_cpu_reset(void *opaque)
> > +static void pnv_core_cpu_reset(PowerPCCPU *cpu)
> >   {
> > -PowerPCCPU *cpu = opaque;
> >   CPUState *cs = CPU(cpu);
> >   CPUPPCState *env = >env;
> > @@ -192,8 +191,17 @@ static void pnv_realize_vcpu(PowerPCCPU *cpu, PnvChip 
> > *chip, Error **errp)
> >   /* Set time-base frequency to 512 MHz */
> >   cpu_ppc_tb_init(env, PNV_TIMEBASE_FREQ);
> > +}
> > +
> > +static void pnv_core_reset(void *dev)
> 
> Here the opaque pointer is a 'PnvCore *pc'.
> If you don't want to call it 'opaque', maybe 'pc' is better.
> 
> > +{
> > +CPUCore *cc = CPU_CORE(dev);
> > +PnvCore *pc = PNV_CORE(dev);
> 
> This type conversion is not necessary.
> 
> What about:
> 
>static void pnv_core_reset(void *opaque)
>{
>PnvCore *pc = opaque;
>CPUCore *cc = CPU_CORE(pc);

Those suggestions look good to me, but they can be done as a follow up.

> 
> > +int i;
> > -qemu_register_reset(pnv_cpu_reset, cpu);
> > +for (i = 0; i < cc->nr_threads; i++) {
> > +pnv_core_cpu_reset(pc->threads[i]);
> > +}
> >   }
> >   static void pnv_core_realize(DeviceState *dev, Error **errp)
> > @@ -244,6 +252,8 @@ static void pnv_core_realize(DeviceState *dev, Error 
> > **errp)
> >   snprintf(name, sizeof(name), "xscom-core.%d", cc->core_id);
> >   pnv_xscom_region_init(>xscom_regs, OBJECT(dev), pcc->xscom_ops,
> > pc, name, PNV_XSCOM_EX_SIZE);
> > +
> > +qemu_register_reset(pnv_core_reset, pc);
> >   return;
> >   err:
> > @@ -259,7 +269,6 @@ static void pnv_unrealize_vcpu(PowerPCCPU *cpu)
> >   {
> >   PnvCPUState *pnv_cpu = pnv_cpu_state(cpu);
> > -qemu_unregister_reset(pnv_cpu_reset, cpu);
> >   object_unparent(OBJECT(pnv_cpu_state(cpu)->intc));
> >   cpu_remove_sync(CPU(cpu));
> >   cpu->machine_data = NULL;
> > @@ -273,6 +282,8 @@ static void pnv_core_unrealize(DeviceState *dev, Error 
> > **errp)
> >   CPUCore *cc = CPU_CORE(dev);
> >   int i;
> > +qemu_unregister_reset(pnv_core_reset, pc);
> > +
> >   for (i = 0; i < cc->nr_threads; i++) {
> >   pnv_unrealize_vcpu(pc->threads[i]);
> >   }
> > 
> 

-- 
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 6/6] xive: Don't use CPU_FOREACH() to perform CAM line matching

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 04:52:27PM +0200, Greg Kurz wrote:
> Now that the TCTX objects are children of the XIVE router, stop
> using CPU_FOREACH() when looking for a matching VCPU target.
> 
> Signed-off-by: Greg Kurz 
> ---
>  hw/intc/xive.c |  100 
> +++-
>  1 file changed, 62 insertions(+), 38 deletions(-)
> 
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 40ce43152456..ec5e7d0ee39a 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -1403,55 +1403,79 @@ typedef struct XiveTCTXMatch {
>  uint8_t ring;
>  } XiveTCTXMatch;
>  
> -static bool xive_presenter_match(XiveRouter *xrtr, uint8_t format,
> - uint8_t nvt_blk, uint32_t nvt_idx,
> - bool cam_ignore, uint8_t priority,
> - uint32_t logic_serv, XiveTCTXMatch *match)
> +typedef struct XivePresenterMatch {
> +uint8_t format;
> +uint8_t nvt_blk;
> +uint32_t nvt_idx;
> +bool cam_ignore;
> +uint8_t priority;
> +uint32_t logic_serv;
> +XiveTCTXMatch *match;
> +int count;
> +} XivePresenterMatch;
> +
> +static int do_xive_presenter_match(Object *child, void *opaque)
>  {
> -CPUState *cs;
> +XiveTCTX *tctx = XIVE_TCTX(child);
> +XivePresenterMatch *xpm = opaque;
> +int ring;
>  
>  /*
>   * TODO (PowerNV): handle chip_id overwrite of block field for
>   * hardwired CAM compares
>   */
>  
> -CPU_FOREACH(cs) {
> -XiveTCTX *tctx = xive_router_get_tctx(xrtr, cs);
> -int ring;
> +/*
> + * HW checks that the CPU is enabled in the Physical Thread
> + * Enable Register (PTER).
> + */
>  
> -/*
> - * Skip partially initialized vCPUs. This can happen when
> - * vCPUs are hotplugged.
> - */
> -if (!tctx) {
> -continue;
> +/*
> + * Check the thread context CAM lines and record matches. We
> + * will handle CPU exception delivery later
> + */
> +ring = xive_presenter_tctx_match(tctx, xpm->format, xpm->nvt_blk,
> + xpm->nvt_idx, xpm->cam_ignore,
> + xpm->logic_serv);
> +
> +/*
> + * Save the context and follow on to catch duplicates, that we
> + * don't support yet.
> + */
> +if (ring != -1) {
> +if (xpm->match->tctx) {
> +qemu_log_mask(LOG_GUEST_ERROR, "XIVE: already found a thread "
> +  "context NVT %x/%x\n", xpm->nvt_blk, xpm->nvt_idx);
> +return -1;
>  }
>  
> -/*
> - * HW checks that the CPU is enabled in the Physical Thread
> - * Enable Register (PTER).
> - */
> +xpm->match->ring = ring;
> +xpm->match->tctx = tctx;
> +xpm->count++;
> +}
>  
> -/*
> - * Check the thread context CAM lines and record matches. We
> - * will handle CPU exception delivery later
> - */
> -ring = xive_presenter_tctx_match(tctx, format, nvt_blk, nvt_idx,
> - cam_ignore, logic_serv);
> -/*
> - * Save the context and follow on to catch duplicates, that we
> - * don't support yet.
> - */
> -if (ring != -1) {
> -if (match->tctx) {
> -qemu_log_mask(LOG_GUEST_ERROR, "XIVE: already found a thread 
> "
> -  "context NVT %x/%x\n", nvt_blk, nvt_idx);
> -return false;
> -}
> -
> -match->ring = ring;
> -match->tctx = tctx;
> -}
> +return 0;
> +}
> +
> +static bool xive_presenter_match(XiveRouter *xrtr, uint8_t format,
> + uint8_t nvt_blk, uint32_t nvt_idx,
> + bool cam_ignore, uint8_t priority,
> + uint32_t logic_serv, XiveTCTXMatch *match)
> +{
> +XivePresenterMatch xpm = {
> +.format = format,
> +.nvt_blk= nvt_blk,
> +.nvt_idx= nvt_idx,
> +.cam_ignore = cam_ignore,
> +.priority   = priority,
> +.logic_serv = logic_serv,
> +.match  = match,
> +.count  = 0,
> +};
> +
> +if (object_child_foreach_type(OBJECT(xrtr), TYPE_XIVE_TCTX,
> +  do_xive_presenter_match, ) < 0) {
> +return false;

Hrm... xive_presenter_match() is potentially a pretty hot path, it's
called on every interrupt delivery - especially since we don't have a
usable KVM irq chip for Boston machines.  I'm concerned that using
something as heavyweight as object_child_foreach() might have a
noticeable performance impact.

>  }
>  
>  if (!match->tctx) {
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_

Re: [PATCH v5 0/7] ppc: reset the interrupt presenter from the CPU reset handler

2019-10-23 Thread David Gibson
On Tue, Oct 22, 2019 at 06:38:05PM +0200, Cédric Le Goater wrote:
> Hello,
> 
> On the sPAPR machine and PowerNV machine, the interrupt presenters are
> created by a machine handler at the core level and are reseted
> independently. This is not consistent and it raises issues when it
> comes to handle hot-plugged CPUs. In that case, the presenters are not
> reseted. This is less of an issue in XICS, although a zero MFFR could
> be a concern, but in XIVE, the OS CAM line is not set and this breaks
> the presenting algorithm. The current code has workarounds which need
> a global cleanup.
> 
> Extend the sPAPR IRQ backend and the PowerNV Chip class with a new
> cpu_intc_reset() handler called by the CPU reset handler and remove
> the XiveTCTX reset handler which is now redundant.
> 
> Set the OS CAM line when the interrupt presenter of the sPAPR core is
> reseted. This will also cover the case of hot-plugged CPUs.

I'm not totally convinced whether every step here is done the best it
can be.  But it addresses real problems, so I've applied anyway.  I
will make some comments inline, which could be addressed in follow up
patches.

> 
> Thanks,
> 
> C.
> 
> Changes in v5:
> 
>  - Removed useless PNV_CHIP() cast
>  
> Changes in v4:
> 
>  - Introduce a PnvCore reset handler
>  - Add PnvChip pointer to PnvCore
> 
> Changes in v3:
> 
>  - Introduced a DeviceClass::reset for the CPU (Greg)
>  - add support for PowerNV
>  
> Changes in v2:
> 
>  - removed property
>  - simplified reset handlers
> 
> Cédric Le Goater (6):
>   spapr: move CPU reset after presenter creation
>   ppc/pnv: Introduce a PnvCore reset handler
>   ppc/pnv: Add a PnvChip pointer to PnvCore
>   ppc: Reset the interrupt presenter from the CPU reset handler
>   ppc/pnv: Fix naming of routines realizing the CPUs
>   spapr/xive: Set the OS CAM line at reset
> 
> Greg Kurz (1):
>   spapr_cpu_core: Implement DeviceClass::reset
> 
>  include/hw/ppc/pnv.h|  1 +
>  include/hw/ppc/pnv_core.h   |  3 +++
>  include/hw/ppc/spapr_irq.h  |  2 ++
>  include/hw/ppc/spapr_xive.h |  1 -
>  include/hw/ppc/xics.h   |  1 +
>  include/hw/ppc/xive.h   |  1 +
>  hw/intc/spapr_xive.c| 53 +
>  hw/intc/xics.c  |  8 ++
>  hw/intc/xics_spapr.c|  7 +
>  hw/intc/xive.c  | 12 +
>  hw/ppc/pnv.c| 18 +
>  hw/ppc/pnv_core.c   | 31 --
>  hw/ppc/spapr_cpu_core.c | 44 +++---
>  hw/ppc/spapr_irq.c  | 14 ++
>  14 files changed, 131 insertions(+), 65 deletions(-)
> 

-- 
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 v5 4/7] ppc/pnv: Add a PnvChip pointer to PnvCore

2019-10-23 Thread David Gibson
On Tue, Oct 22, 2019 at 06:38:09PM +0200, Cédric Le Goater wrote:
> We will use it to reset the interrupt presenter from the CPU reset
> handler.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: Greg Kurz 
> ---
>  include/hw/ppc/pnv_core.h | 3 +++
>  hw/ppc/pnv_core.c | 3 ++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
> index bfbd2ec42aa6..55eee95104da 100644
> --- a/include/hw/ppc/pnv_core.h
> +++ b/include/hw/ppc/pnv_core.h
> @@ -31,6 +31,8 @@
>  #define PNV_CORE_GET_CLASS(obj) \
>   OBJECT_GET_CLASS(PnvCoreClass, (obj), TYPE_PNV_CORE)
>  
> +typedef struct PnvChip PnvChip;
> +
>  typedef struct PnvCore {
>  /*< private >*/
>  CPUCore parent_obj;
> @@ -38,6 +40,7 @@ typedef struct PnvCore {
>  /*< public >*/
>  PowerPCCPU **threads;
>  uint32_t pir;
> +PnvChip *chip;

I don't love having this as a redundant encoding of the information
already in the property, since it raises the possibility of confusing
bugs if they ever got out of sync.

It's not a huge deal, but it would be nice to at least to at least
consider either a) grabbing the property everywhere you need it (if
there aren't too many places) or b) customizing the property
definition so it's written directly into that field.

>  
>  MemoryRegion xscom_regs;
>  } PnvCore;
> diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
> index 9f981a4940e6..cc17bbfed829 100644
> --- a/hw/ppc/pnv_core.c
> +++ b/hw/ppc/pnv_core.c
> @@ -222,6 +222,7 @@ static void pnv_core_realize(DeviceState *dev, Error 
> **errp)
>  "required link 'chip' not found: ");
>  return;
>  }
> +pc->chip = PNV_CHIP(chip);
>  
>  pc->threads = g_new(PowerPCCPU *, cc->nr_threads);
>  for (i = 0; i < cc->nr_threads; i++) {
> @@ -243,7 +244,7 @@ static void pnv_core_realize(DeviceState *dev, Error 
> **errp)
>  }
>  
>  for (j = 0; j < cc->nr_threads; j++) {
> -pnv_realize_vcpu(pc->threads[j], PNV_CHIP(chip), _err);
> +pnv_realize_vcpu(pc->threads[j], pc->chip, _err);
>  if (local_err) {
>  goto err;
>  }

-- 
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 v5 5/7] ppc: Reset the interrupt presenter from the CPU reset handler

2019-10-23 Thread David Gibson
On Tue, Oct 22, 2019 at 06:38:10PM +0200, Cédric Le Goater wrote:
> On the sPAPR machine and PowerNV machine, the interrupt presenters are
> created by a machine handler at the core level and are reset
> independently. This is not consistent and it raises issues when it
> comes to handle hot-plugged CPUs. In that case, the presenters are not
> reset. This is less of an issue in XICS, although a zero MFFR could
> be a concern, but in XIVE, the OS CAM line is not set and this breaks
> the presenting algorithm. The current code has workarounds which need
> a global cleanup.
> 
> Extend the sPAPR IRQ backend and the PowerNV Chip class with a new
> cpu_intc_reset() handler called by the CPU reset handler and remove
> the XiveTCTX reset handler which is now redundant.
> 
> Signed-off-by: Cédric Le Goater 

Both XiveTCTX and ICPState are QOM subclasses of TYPE_DEVICE.  I think
that means you could avoid the new hook by using dc->reset on those
classes instead.  It wouldn't get called automatically, of course,
since it's not on a bus, but you could call it explicitly via
device_reset() from the place you currently call the new hook.

> ---
>  include/hw/ppc/pnv.h   |  1 +
>  include/hw/ppc/spapr_irq.h |  2 ++
>  include/hw/ppc/xics.h  |  1 +
>  include/hw/ppc/xive.h  |  1 +
>  hw/intc/spapr_xive.c   |  9 +
>  hw/intc/xics.c |  8 ++--
>  hw/intc/xics_spapr.c   |  7 +++
>  hw/intc/xive.c | 12 +---
>  hw/ppc/pnv.c   | 18 ++
>  hw/ppc/pnv_core.c  |  7 +--
>  hw/ppc/spapr_cpu_core.c|  5 -
>  hw/ppc/spapr_irq.c | 14 ++
>  12 files changed, 65 insertions(+), 20 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 1cdbe55bf86c..2a780e633f23 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -111,6 +111,7 @@ typedef struct PnvChipClass {
>  
>  uint32_t (*core_pir)(PnvChip *chip, uint32_t core_id);
>  void (*intc_create)(PnvChip *chip, PowerPCCPU *cpu, Error **errp);
> +void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
>  ISABus *(*isa_create)(PnvChip *chip, Error **errp);
>  void (*dt_populate)(PnvChip *chip, void *fdt);
>  void (*pic_print_info)(PnvChip *chip, Monitor *mon);
> diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
> index 5e150a667902..09232999b07e 100644
> --- a/include/hw/ppc/spapr_irq.h
> +++ b/include/hw/ppc/spapr_irq.h
> @@ -52,6 +52,7 @@ typedef struct SpaprInterruptControllerClass {
>   */
>  int (*cpu_intc_create)(SpaprInterruptController *intc,
>  PowerPCCPU *cpu, Error **errp);
> +void (*cpu_intc_reset)(SpaprInterruptController *intc, PowerPCCPU *cpu);
>  int (*claim_irq)(SpaprInterruptController *intc, int irq, bool lsi,
>   Error **errp);
>  void (*free_irq)(SpaprInterruptController *intc, int irq);
> @@ -68,6 +69,7 @@ void spapr_irq_update_active_intc(SpaprMachineState *spapr);
>  
>  int spapr_irq_cpu_intc_create(SpaprMachineState *spapr,
>PowerPCCPU *cpu, Error **errp);
> +void spapr_irq_cpu_intc_reset(SpaprMachineState *spapr, PowerPCCPU *cpu);
>  void spapr_irq_print_info(SpaprMachineState *spapr, Monitor *mon);
>  void spapr_irq_dt(SpaprMachineState *spapr, uint32_t nr_servers,
>void *fdt, uint32_t phandle);
> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
> index 1e6a9300eb2b..602173c12250 100644
> --- a/include/hw/ppc/xics.h
> +++ b/include/hw/ppc/xics.h
> @@ -161,6 +161,7 @@ void icp_set_mfrr(ICPState *icp, uint8_t mfrr);
>  uint32_t icp_accept(ICPState *ss);
>  uint32_t icp_ipoll(ICPState *ss, uint32_t *mfrr);
>  void icp_eoi(ICPState *icp, uint32_t xirr);
> +void icp_reset(ICPState *icp);
>  
>  void ics_write_xive(ICSState *ics, int nr, int server,
>  uint8_t priority, uint8_t saved_priority);
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index fd3319bd3202..99381639f50c 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -415,6 +415,7 @@ uint64_t xive_tctx_tm_read(XiveTCTX *tctx, hwaddr offset, 
> unsigned size);
>  
>  void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
>  Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, Error **errp);
> +void xive_tctx_reset(XiveTCTX *tctx);
>  
>  static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, uint32_t nvt_idx)
>  {
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index ba32d2cc5b0f..20a8d8285f64 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -553,6 +553,14 @@ static int 
> spapr_xive_cpu_intc_create(SpaprInterruptController *intc,
>  return 0;
>  }
>  
> +static void spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
> + PowerPCCPU *cpu)
> +{
> +XiveTCTX *tctx = spapr_cpu_state(cpu)->tctx;
> +
> +xive_tctx_reset(tctx);
> 

Re: [PATCH] spapr: Don't request to unplug the same core twice

2019-10-23 Thread David Gibson
On Wed, Oct 23, 2019 at 09:17:40PM +0200, Greg Kurz wrote:
> We must not call spapr_drc_detach() on a detached DRC otherwise bad things
> can happen, ie. QEMU hangs or crashes. This is easily demonstrated with
> a CPU hotplug/unplug loop using QMP.
> 
> Signed-off-by: Greg Kurz 

Ouch, good catch.  Applied.

I wonder if we have the same problem with other DRC types.

> ---
>  hw/ppc/spapr.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index f9410d390a07..94f9d27096af 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3741,9 +3741,10 @@ void spapr_core_unplug_request(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>spapr_vcpu_id(spapr, cc->core_id));
>  g_assert(drc);
>  
> -spapr_drc_detach(drc);
> -
> -spapr_hotplug_req_remove_by_index(drc);
> +if (!spapr_drc_unplug_requested(drc)) {
> +spapr_drc_detach(drc);
> +spapr_hotplug_req_remove_by_index(drc);
> +}
>  }
>  
>  int spapr_core_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr,
> 

-- 
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: [Resend PATCH 0/3] Add CPU model for intel processor Cooper Lake

2019-10-23 Thread Eduardo Habkost
On Tue, Oct 22, 2019 at 03:35:25PM +0800, Cathy Zhang wrote:
> This patchset is to add CPU model for intel processor Cooper Lake. It
> will inherit features from the existing CPU model Cascadelake-Server,
> meanwhile, add the platform associated new instruction and feature
> for speculative execution which the host supports. There are associated
> feature bit and macro defined here as needed.

Queued, thanks.

> 
> Cathy Zhang (3):
>   i386: Add MSR feature bit for MDS-NO
>   i386: Add macro for stibp
>   i386: Add new CPU model Cooperlake
> 
>  target/i386/cpu.c | 60 
> +++
>  target/i386/cpu.h |  3 +++
>  2 files changed, 63 insertions(+)
> 
> -- 
> 1.8.3.1
> 

-- 
Eduardo




[PULL 4/4] hppa: drop usage of memory_region_allocate_system_memory() for ROM

2019-10-23 Thread Eduardo Habkost
From: Igor Mammedov 

machine_hppa_init() violates memory_region_allocate_system_memory() contract
by calling it multiple times which could break with -mem-path. Replace
the second usage (for 'rom') with memory_region_init_ram() instead.

Signed-off-by: Igor Mammedov 
Message-Id: <20191008113318.7012-4-imamm...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Signed-off-by: Eduardo Habkost 
---
 hw/hppa/machine.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 7e23675429..953d454f48 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -161,9 +161,8 @@ static void machine_hppa_init(MachineState *machine)
 g_free(firmware_filename);
 
 rom_region = g_new(MemoryRegion, 1);
-memory_region_allocate_system_memory(rom_region, OBJECT(machine),
- "firmware",
- (FIRMWARE_END - FIRMWARE_START));
+memory_region_init_ram(rom_region, NULL, "firmware",
+   (FIRMWARE_END - FIRMWARE_START), _fatal);
 memory_region_add_subregion(addr_space, FIRMWARE_START, rom_region);
 
 /* Load kernel */
-- 
2.21.0




[PULL 3/4] ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory()

2019-10-23 Thread Eduardo Habkost
From: Igor Mammedov 

rs6000mc_realize() violates memory_region_allocate_system_memory() contract
by calling it multiple times which could break -mem-path. Replace it with
plain memory_region_init_ram() instead.

Signed-off-by: Igor Mammedov 
Message-Id: <20191008113318.7012-3-imamm...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: David Gibson 
Signed-off-by: Eduardo Habkost 
---
 hw/ppc/rs6000_mc.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/rs6000_mc.c b/hw/ppc/rs6000_mc.c
index df7c0006fc..66b14db5fa 100644
--- a/hw/ppc/rs6000_mc.c
+++ b/hw/ppc/rs6000_mc.c
@@ -144,6 +144,7 @@ static void rs6000mc_realize(DeviceState *dev, Error **errp)
 RS6000MCState *s = RS6000MC_DEVICE(dev);
 int socket = 0;
 unsigned int ram_size = s->ram_size / MiB;
+Error *local_err = NULL;
 
 while (socket < 6) {
 if (ram_size >= 64) {
@@ -165,19 +166,21 @@ static void rs6000mc_realize(DeviceState *dev, Error 
**errp)
 if (s->simm_size[socket]) {
 char name[] = "simm.?";
 name[5] = socket + '0';
-memory_region_allocate_system_memory(>simm[socket], OBJECT(dev),
- name,
- s->simm_size[socket] * MiB);
+memory_region_init_ram(>simm[socket], OBJECT(dev), name,
+   s->simm_size[socket] * MiB, _err);
+if (local_err) {
+goto out;
+}
 memory_region_add_subregion_overlap(get_system_memory(), 0,
 >simm[socket], socket);
 }
 }
 if (ram_size) {
 /* unable to push all requested RAM in SIMMs */
-error_setg(errp, "RAM size incompatible with this board. "
+error_setg(_err, "RAM size incompatible with this board. "
"Try again with something else, like %" PRId64 " MB",
s->ram_size / MiB - ram_size);
-return;
+goto out;
 }
 
 if (s->autoconfigure) {
@@ -193,6 +196,8 @@ static void rs6000mc_realize(DeviceState *dev, Error **errp)
 
 isa_register_portio_list(ISA_DEVICE(dev), >portio, 0x0,
  rs6000mc_port_list, s, "rs6000mc");
+out:
+error_propagate(errp, local_err);
 }
 
 static const VMStateDescription vmstate_rs6000mc = {
-- 
2.21.0




[PULL 2/4] sparc64: use memory_region_allocate_system_memory() only for '-m' specified RAM

2019-10-23 Thread Eduardo Habkost
From: Igor Mammedov 

memory_region_allocate_system_memory() was designed to be called for
allocating inital RAM. Using it mutiple times within one board is not
supported and could fail if -mem-path with non hugepage path is used.

Keep using memory_region_allocate_system_memory() only for initial
RAM and use memory_region_init_ram() for the rest fixed size regions.

Signed-off-by: Igor Mammedov 
Message-Id: <20191008113318.7012-2-imamm...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Eduardo Habkost 
---
 hw/sparc64/niagara.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c
index 167143bffe..5987693659 100644
--- a/hw/sparc64/niagara.c
+++ b/hw/sparc64/niagara.c
@@ -36,6 +36,7 @@
 #include "qemu/error-report.h"
 #include "sysemu/qtest.h"
 #include "sysemu/sysemu.h"
+#include "qapi/error.h"
 
 typedef struct NiagaraBoardState {
 MemoryRegion hv_ram;
@@ -106,8 +107,8 @@ static void niagara_init(MachineState *machine)
 /* init CPUs */
 sparc64_cpu_devinit(machine->cpu_type, NIAGARA_PROM_BASE);
 /* set up devices */
-memory_region_allocate_system_memory(>hv_ram, NULL, "sun4v-hv.ram",
- NIAGARA_HV_RAM_SIZE);
+memory_region_init_ram(>hv_ram, NULL, "sun4v-hv.ram",
+   NIAGARA_HV_RAM_SIZE, _fatal);
 memory_region_add_subregion(sysmem, NIAGARA_HV_RAM_BASE, >hv_ram);
 
 memory_region_allocate_system_memory(>partition_ram, NULL,
@@ -116,17 +117,17 @@ static void niagara_init(MachineState *machine)
 memory_region_add_subregion(sysmem, NIAGARA_PARTITION_RAM_BASE,
 >partition_ram);
 
-memory_region_allocate_system_memory(>nvram, NULL,
- "sun4v.nvram", NIAGARA_NVRAM_SIZE);
+memory_region_init_ram(>nvram, NULL, "sun4v.nvram", NIAGARA_NVRAM_SIZE,
+   _fatal);
 memory_region_add_subregion(sysmem, NIAGARA_NVRAM_BASE, >nvram);
-memory_region_allocate_system_memory(>md_rom, NULL,
- "sun4v-md.rom", NIAGARA_MD_ROM_SIZE);
+memory_region_init_ram(>md_rom, NULL, "sun4v-md.rom",
+   NIAGARA_MD_ROM_SIZE, _fatal);
 memory_region_add_subregion(sysmem, NIAGARA_MD_ROM_BASE, >md_rom);
-memory_region_allocate_system_memory(>hv_rom, NULL,
- "sun4v-hv.rom", NIAGARA_HV_ROM_SIZE);
+memory_region_init_ram(>hv_rom, NULL, "sun4v-hv.rom",
+   NIAGARA_HV_ROM_SIZE, _fatal);
 memory_region_add_subregion(sysmem, NIAGARA_HV_ROM_BASE, >hv_rom);
-memory_region_allocate_system_memory(>prom, NULL,
- "sun4v.prom", PROM_SIZE_MAX);
+memory_region_init_ram(>prom, NULL, "sun4v.prom", PROM_SIZE_MAX,
+   _fatal);
 memory_region_add_subregion(sysmem, NIAGARA_PROM_BASE, >prom);
 
 add_rom_or_fail("nvram1", NIAGARA_NVRAM_BASE);
@@ -143,8 +144,8 @@ static void niagara_init(MachineState *machine)
 BlockBackend *blk = blk_by_legacy_dinfo(dinfo);
 int size = blk_getlength(blk);
 if (size > 0) {
-memory_region_allocate_system_memory(>vdisk_ram, NULL,
- "sun4v_vdisk.ram", size);
+memory_region_init_ram(>vdisk_ram, NULL, "sun4v_vdisk.ram", 
size,
+   _fatal);
 memory_region_add_subregion(get_system_memory(),
 NIAGARA_VDISK_BASE, >vdisk_ram);
 dinfo->is_default = 1;
-- 
2.21.0




[PULL 1/4] target/i386: Introduce Denverton CPU model

2019-10-23 Thread Eduardo Habkost
From: Tao Xu 

Denverton is the Atom Processor of Intel Harrisonville platform.

For more information:
https://ark.intel.com/content/www/us/en/ark/products/\
codename/63508/denverton.html

Signed-off-by: Tao Xu 
Message-Id: <20190718073405.28301-1-tao3...@intel.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 47200b40c1..0de8a22e1e 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2724,6 +2724,53 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .xlevel = 0x8008,
 .model_id = "Intel Xeon Processor (Icelake)",
 },
+{
+.name = "Denverton",
+.level = 21,
+.vendor = CPUID_VENDOR_INTEL,
+.family = 6,
+.model = 95,
+.stepping = 1,
+.features[FEAT_1_EDX] =
+CPUID_FP87 | CPUID_VME | CPUID_DE | CPUID_PSE | CPUID_TSC |
+CPUID_MSR | CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC |
+CPUID_SEP | CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
+CPUID_PAT | CPUID_PSE36 | CPUID_CLFLUSH | CPUID_MMX | CPUID_FXSR |
+CPUID_SSE | CPUID_SSE2,
+.features[FEAT_1_ECX] =
+CPUID_EXT_SSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_MONITOR |
+CPUID_EXT_SSSE3 | CPUID_EXT_CX16 | CPUID_EXT_SSE41 |
+CPUID_EXT_SSE42 | CPUID_EXT_X2APIC | CPUID_EXT_MOVBE |
+CPUID_EXT_POPCNT | CPUID_EXT_TSC_DEADLINE_TIMER |
+CPUID_EXT_AES | CPUID_EXT_XSAVE | CPUID_EXT_RDRAND,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_SYSCALL | CPUID_EXT2_NX | CPUID_EXT2_PDPE1GB |
+CPUID_EXT2_RDTSCP | CPUID_EXT2_LM,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+.features[FEAT_7_0_EBX] =
+CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_ERMS |
+CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_SMAP |
+CPUID_7_0_EBX_CLFLUSHOPT | CPUID_7_0_EBX_SHA_NI,
+.features[FEAT_7_0_EDX] =
+CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_ARCH_CAPABILITIES |
+CPUID_7_0_EDX_SPEC_CTRL_SSBD,
+/*
+ * Missing: XSAVES (not supported by some Linux versions,
+ * including v4.1 to v4.12).
+ * KVM doesn't yet expose any XSAVES state save component,
+ * and the only one defined in Skylake (processor tracing)
+ * probably will block migration anyway.
+ */
+.features[FEAT_XSAVE] =
+CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC | CPUID_XSAVE_XGETBV1,
+.features[FEAT_6_EAX] =
+CPUID_6_EAX_ARAT,
+.features[FEAT_ARCH_CAPABILITIES] =
+MSR_ARCH_CAP_RDCL_NO | MSR_ARCH_CAP_SKIP_L1DFL_VMENTRY,
+.xlevel = 0x8008,
+.model_id = "Intel Atom Processor (Denverton)",
+},
 {
 .name = "Snowridge",
 .level = 27,
-- 
2.21.0




[PULL 0/4] x86 and machine queue, 2019-10-23

2019-10-23 Thread Eduardo Habkost
The following changes since commit f78398bfe544db81a974825b0a2aa826f6576414:

  Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-10-22' into 
staging (2019-10-23 16:06:13 +0100)

are available in the Git repository at:

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

for you to fetch changes up to 6a3a2e828220d9c86425930178445b868ea3c3c4:

  hppa: drop usage of memory_region_allocate_system_memory() for ROM 
(2019-10-23 23:37:42 -0300)


x86 and machine queue, 2019-10-23

Features:
* Denverton CPU model (Tao Xu)

Cleanups:
* Eliminate remaining places that abuse
  memory_region_allocate_system_memory() (Igor Mammedov)



Igor Mammedov (3):
  sparc64: use memory_region_allocate_system_memory() only for '-m'
specified RAM
  ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory()
  hppa: drop usage of memory_region_allocate_system_memory() for ROM

Tao Xu (1):
  target/i386: Introduce Denverton CPU model

 hw/hppa/machine.c|  5 ++---
 hw/ppc/rs6000_mc.c   | 15 +-
 hw/sparc64/niagara.c | 25 ---
 target/i386/cpu.c| 47 
 4 files changed, 72 insertions(+), 20 deletions(-)

-- 
2.21.0




Re: [PATCH v5] migration: Support QLIST migration

2019-10-23 Thread Peter Xu
On Wed, Oct 23, 2019 at 05:02:37PM +0200, Eric Auger wrote:
> Support QLIST migration using the same principle as QTAILQ:
> 94869d5c52 ("migration: migrate QTAILQ").
> 
> The VMSTATE_QLIST_V macro has the same proto as VMSTATE_QTAILQ_V.
> The change mainly resides in QLIST RAW macros: QLIST_RAW_INSERT_HEAD
> and QLIST_RAW_REVERSE.
> 
> Tests also are provided.
> 
> Signed-off-by: Eric Auger 
> Reviewed-by: Juan Quintela 

Reviewed-by: Peter Xu 

-- 
Peter Xu



Re: [PATCH 1/1] pci: pass along the return value of dma_memory_rw

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/11/19 9:01 AM, Klaus Jensen wrote:

Some might actually care about the return value of dma_memory_rw. So
let us pass it along instead of ignoring it.

Signed-off-by: Klaus Jensen 
---
  include/hw/pci/pci.h | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index f3f0ffd5fb78..4e95bb847857 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -779,8 +779,7 @@ static inline AddressSpace *pci_get_address_space(PCIDevice 
*dev)
  static inline int pci_dma_rw(PCIDevice *dev, dma_addr_t addr,
   void *buf, dma_addr_t len, DMADirection dir)
  {
-dma_memory_rw(pci_get_address_space(dev), addr, buf, len, dir);
-return 0;
+return dma_memory_rw(pci_get_address_space(dev), addr, buf, len, dir);
  }
  
  static inline int pci_dma_read(PCIDevice *dev, dma_addr_t addr,




Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH v3 32/33] qdev: remove PROP_MEMORY_REGION

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

PROP_MEMORY_REGION was a derivative of PROP_PTR, added in commit
ed03d749f3f513b8fb0287757cfda2cb6825f063 (qdev: add MemoryRegion
property) and thankfully no longer needed since commit
3eff40dbf44896a8180c86c84dbdefb2eb173fbe (hw/misc: Remove
mmio_interface device).

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
  include/hw/qdev-properties.h | 2 --
  1 file changed, 2 deletions(-)

diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 690ff07ae2..5bba033b7b 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -213,8 +213,6 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
  DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint16_t)
  #define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
  DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
-#define DEFINE_PROP_MEMORY_REGION(_n, _s, _f) \
-DEFINE_PROP(_n, _s, _f, qdev_prop_ptr, MemoryRegion *)
  #define DEFINE_PROP_OFF_AUTO_PCIBAR(_n, _s, _f, _d) \
  DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_off_auto_pcibar, \
  OffAutoPCIBAR)



Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH v3 23/33] dp8393x: replace PROP_PTR with PROP_LINK

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

Link property is the correct way to pass a MemoryRegion to a device
for DMA purposes.

Sidenote: as a sysbus device, this remains non-usercreatable
even though we can drop the specific flag here.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
  hw/mips/mips_jazz.c | 3 ++-
  hw/net/dp8393x.c| 7 +++
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/mips/mips_jazz.c b/hw/mips/mips_jazz.c
index 8d010a0b6e..878925a963 100644
--- a/hw/mips/mips_jazz.c
+++ b/hw/mips/mips_jazz.c
@@ -284,7 +284,8 @@ static void mips_jazz_init(MachineState *machine,
  dev = qdev_create(NULL, "dp8393x");
  qdev_set_nic_properties(dev, nd);
  qdev_prop_set_uint8(dev, "it_shift", 2);
-qdev_prop_set_ptr(dev, "dma_mr", rc4030_dma_mr);
+object_property_set_link(OBJECT(dev), OBJECT(rc4030_dma_mr),
+ "dma_mr", _abort);
  qdev_init_nofail(dev);
  sysbus = SYS_BUS_DEVICE(dev);
  sysbus_mmio_map(sysbus, 0, 0x80001000);
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index a5678e11fa..946c7a8f64 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -173,7 +173,7 @@ typedef struct dp8393xState {
  int loopback_packet;
  
  /* Memory access */

-void *dma_mr;
+MemoryRegion *dma_mr;
  AddressSpace as;
  } dp8393xState;
  
@@ -922,7 +922,8 @@ static const VMStateDescription vmstate_dp8393x = {
  
  static Property dp8393x_properties[] = {

  DEFINE_NIC_PROPERTIES(dp8393xState, conf),
-DEFINE_PROP_PTR("dma_mr", dp8393xState, dma_mr),
+DEFINE_PROP_LINK("dma_mr", dp8393xState, dma_mr,
+ TYPE_MEMORY_REGION, MemoryRegion *),
  DEFINE_PROP_UINT8("it_shift", dp8393xState, it_shift, 0),
  DEFINE_PROP_END_OF_LIST(),
  };
@@ -936,8 +937,6 @@ static void dp8393x_class_init(ObjectClass *klass, void 
*data)
  dc->reset = dp8393x_reset;
  dc->vmsd = _dp8393x;
  dc->props = dp8393x_properties;
-/* Reason: dma_mr property can't be set */
-dc->user_creatable = false;


Patch is OK except this user_creatable change I don't understand.


  }
  
  static const TypeInfo dp8393x_info = {






[PULL 0/2] target/xtensa queue

2019-10-23 Thread Max Filippov
Hi Peter,

please pull the following two target/xtensa patches for v4.2.

The following changes since commit a30cb4b1f22c58aa3b933ee9e1d7611399b57b5b:

  Merge remote-tracking branch 
'remotes/vivier2/tags/linux-user-for-4.2-pull-request' into staging (2019-09-12 
16:17:26 +0100)

are available in the Git repository at:

  git://github.com/OSLL/qemu-xtensa.git tags/20191023-xtensa

for you to fetch changes up to d9e8553bc8821d72cb72ca95f76b2d8ff6eb628a:

  hw/xtensa: add virt machine (2019-10-18 20:38:10 -0700)


target/xtensa improvements for v4.2:

- regenerate and reimport test_mmuhifi_c3 core;
- add virt machine.


Max Filippov (2):
  target/xtensa: regenerate and re-import test_mmuhifi_c3 core
  hw/xtensa: add virt machine

 MAINTAINERS|5 +
 default-configs/xtensa-softmmu.mak |1 +
 hw/xtensa/Kconfig  |6 +
 hw/xtensa/Makefile.objs|1 +
 hw/xtensa/sim.c|   41 +-
 hw/xtensa/virt.c   |  135 +
 hw/xtensa/xtensa_sim.h |   34 +
 target/xtensa/core-test_mmuhifi_c3.c   |3 +-
 target/xtensa/core-test_mmuhifi_c3/core-isa.h  |  116 +-
 .../xtensa/core-test_mmuhifi_c3/gdb-config.inc.c   |  114 +-
 .../core-test_mmuhifi_c3/xtensa-modules.inc.c  | 6384 ++--
 11 files changed, 3593 insertions(+), 3247 deletions(-)
 create mode 100644 hw/xtensa/virt.c
 create mode 100644 hw/xtensa/xtensa_sim.h

-- 
Thanks.
-- Max



Re: [PATCH v3 21/33] lance: replace PROP_PTR with PROP_LINK

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
  hw/dma/sparc32_dma.c | 2 +-
  hw/net/lance.c   | 5 ++---
  hw/net/pcnet-pci.c   | 2 +-
  hw/net/pcnet.h   | 2 +-
  4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/hw/dma/sparc32_dma.c b/hw/dma/sparc32_dma.c
index 0e5bbcdc7f..3e4da0c47f 100644
--- a/hw/dma/sparc32_dma.c
+++ b/hw/dma/sparc32_dma.c
@@ -346,7 +346,7 @@ static void sparc32_ledma_device_realize(DeviceState *dev, 
Error **errp)
  d = qdev_create(NULL, TYPE_LANCE);
  object_property_add_child(OBJECT(dev), "lance", OBJECT(d), errp);
  qdev_set_nic_properties(d, nd);
-qdev_prop_set_ptr(d, "dma", dev);
+object_property_set_link(OBJECT(d), OBJECT(dev), "dma", errp);
  qdev_init_nofail(d);
  }
  
diff --git a/hw/net/lance.c b/hw/net/lance.c

index 6631e2a4e0..4d96299041 100644
--- a/hw/net/lance.c
+++ b/hw/net/lance.c
@@ -138,7 +138,8 @@ static void lance_instance_init(Object *obj)
  }
  
  static Property lance_properties[] = {

-DEFINE_PROP_PTR("dma", SysBusPCNetState, state.dma_opaque),
+DEFINE_PROP_LINK("dma", SysBusPCNetState, state.dma_opaque,
+ TYPE_DEVICE, DeviceState *),
  DEFINE_NIC_PROPERTIES(SysBusPCNetState, state.conf),
  DEFINE_PROP_END_OF_LIST(),
  };
@@ -153,8 +154,6 @@ static void lance_class_init(ObjectClass *klass, void *data)
  dc->reset = lance_reset;
  dc->vmsd = _lance;
  dc->props = lance_properties;
-/* Reason: pointer property "dma" */
-dc->user_creatable = false;


But we still can not start it with the -device option and set the dma, 
can we?



  }
  
  static const TypeInfo lance_info = {

diff --git a/hw/net/pcnet-pci.c b/hw/net/pcnet-pci.c
index 4723c30c79..d067d21e2c 100644
--- a/hw/net/pcnet-pci.c
+++ b/hw/net/pcnet-pci.c
@@ -231,7 +231,7 @@ static void pci_pcnet_realize(PCIDevice *pci_dev, Error 
**errp)
  s->irq = pci_allocate_irq(pci_dev);
  s->phys_mem_read = pci_physical_memory_read;
  s->phys_mem_write = pci_physical_memory_write;
-s->dma_opaque = pci_dev;
+s->dma_opaque = DEVICE(pci_dev);
  
  pcnet_common_init(DEVICE(pci_dev), s, _pci_pcnet_info);

  }
diff --git a/hw/net/pcnet.h b/hw/net/pcnet.h
index 28d19a5c6f..f49b213c57 100644
--- a/hw/net/pcnet.h
+++ b/hw/net/pcnet.h
@@ -50,7 +50,7 @@ struct PCNetState_st {
   uint8_t *buf, int len, int do_bswap);
  void (*phys_mem_write)(void *dma_opaque, hwaddr addr,
uint8_t *buf, int len, int do_bswap);
-void *dma_opaque;
+DeviceState *dma_opaque;
  int tx_busy;
  int looptest;
  };





Re: [PATCH v3 20/33] vmmouse: replace PROP_PTR with PROP_LINK

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

While at it, use the expected type.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
  hw/i386/pc.c | 6 +++---
  hw/i386/vmmouse.c| 8 +++-
  hw/input/pckbd.c | 8 +++-
  include/hw/input/i8042.h | 4 +++-
  4 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 00ee16ccab..021ec8c593 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1861,9 +1861,9 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl, bool no_vmport)
  vmmouse = NULL;
  }
  if (vmmouse) {
-DeviceState *dev = DEVICE(vmmouse);
-qdev_prop_set_ptr(dev, "ps2_mouse", i8042);
-qdev_init_nofail(dev);
+object_property_set_link(OBJECT(vmmouse), OBJECT(i8042),
+ "i8042", _abort);
+qdev_init_nofail(DEVICE(vmmouse));
  }
  port92 = isa_create_simple(isa_bus, "port92");
  
diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c

index 41ad91ad53..c0c329f817 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -66,7 +66,7 @@ typedef struct VMMouseState
  uint16_t status;
  uint8_t absolute;
  QEMUPutMouseEntry *entry;
-void *ps2_mouse;
+ISAKBDState *i8042;
  } VMMouseState;
  
  static uint32_t vmmouse_get_status(VMMouseState *s)

@@ -105,7 +105,7 @@ static void vmmouse_mouse_event(void *opaque, int x, int y, 
int dz, int buttons_
  
  /* need to still generate PS2 events to notify driver to

 read from queue */
-i8042_isa_mouse_fake_event(s->ps2_mouse);
+i8042_isa_mouse_fake_event(s->i8042);
  }
  
  static void vmmouse_remove_handler(VMMouseState *s)

@@ -275,7 +275,7 @@ static void vmmouse_realizefn(DeviceState *dev, Error 
**errp)
  }
  
  static Property vmmouse_properties[] = {

-DEFINE_PROP_PTR("ps2_mouse", VMMouseState, ps2_mouse),
+DEFINE_PROP_LINK("i8042", VMMouseState, i8042, TYPE_I8042, ISAKBDState *),
  DEFINE_PROP_END_OF_LIST(),
  };
  
@@ -287,8 +287,6 @@ static void vmmouse_class_initfn(ObjectClass *klass, void *data)

  dc->reset = vmmouse_reset;
  dc->vmsd = _vmmouse;
  dc->props = vmmouse_properties;
-/* Reason: pointer property "ps2_mouse" */
-dc->user_creatable = false;
  }
  
  static const TypeInfo vmmouse_info = {

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index f0acfd86f7..9b641021c9 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -483,17 +483,15 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
  
  #define I8042(obj) OBJECT_CHECK(ISAKBDState, (obj), TYPE_I8042)
  
-typedef struct ISAKBDState {

+struct ISAKBDState {
  ISADevice parent_obj;
  
  KBDState kbd;

  MemoryRegion io[2];
-} ISAKBDState;
+};
  
-void i8042_isa_mouse_fake_event(void *opaque)

+void i8042_isa_mouse_fake_event(ISAKBDState *isa)
  {
-ISADevice *dev = opaque;
-ISAKBDState *isa = I8042(dev);
  KBDState *s = >kbd;
  
  ps2_mouse_fake_event(s->mouse);

diff --git a/include/hw/input/i8042.h b/include/hw/input/i8042.h
index 246e6f3335..8eaebf50ce 100644
--- a/include/hw/input/i8042.h
+++ b/include/hw/input/i8042.h
@@ -14,10 +14,12 @@
  
  #define I8042_A20_LINE "a20"
  
+typedef struct ISAKBDState ISAKBDState;

+
  void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
 MemoryRegion *region, ram_addr_t size,
 hwaddr mask);
-void i8042_isa_mouse_fake_event(void *opaque);
+void i8042_isa_mouse_fake_event(ISAKBDState *isa);
  void i8042_setup_a20_line(ISADevice *dev, qemu_irq a20_out);
  
  #endif /* HW_INPUT_I8042_H */




Nice!

Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH v3 19/33] sm501: make SerialMM a child, export chardev property

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, 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 | 31 ++-
  hw/sh4/r2d.c   |  2 +-
  2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index 1f33c87e65..6efdf764c1 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,18 @@ 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);
+if (qemu_chr_fe_backend_connected(>chr)) {


Oh, this is a Companion Chip (Northbridge + Southbridge), mostly 
implementing the display part, that's why it is in hw/display/.


The SM501_UART0 is always mapped here, no need to check for the backend.
(Not related to your series goal, but cleaning this might simplify this 
patch).



+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 */
  }
  }
  
  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 +2001,19 @@ 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 *self = SYSBUS_SM501(o);
+SerialMM *s = >serial;
+
+sysbus_init_child_obj(o, "serial", s, sizeof(SerialMM), TYPE_SERIAL_MM);
+qdev_prop_set_int32(DEVICE(s), "instance-id", SM501_UART0);
+qdev_prop_set_uint8(DEVICE(s), "regshift", 2);
+qdev_prop_set_uint8(DEVICE(s), "endianness", DEVICE_LITTLE_ENDIAN);
+
+object_property_add_alias(o, "chardev", OBJECT(s), "chardev", 
_abort);
  }
  
  static const TypeInfo sm501_sysbus_info = {

@@ -2009,6 +2021,7 @@ static const TypeInfo sm501_sysbus_info = {
  .parent= TYPE_SYS_BUS_DEVICE,
  .instance_size = sizeof(SM501SysBusState),
  .class_init= sm501_sysbus_class_init,
+.instance_init = sm501_sysbus_init,
  };
  
  #define TYPE_PCI_SM501 "sm501"

diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
index ee0840f380..72bb5285cc 100644
--- a/hw/sh4/r2d.c
+++ b/hw/sh4/r2d.c
@@ -272,7 +272,7 @@ static void r2d_init(MachineState *machine)
  busdev = SYS_BUS_DEVICE(dev);
  qdev_prop_set_uint32(dev, "vram-size", SM501_VRAM_SIZE);
  qdev_prop_set_uint32(dev, "base", 0x1000);
-qdev_prop_set_ptr(dev, "chr-state", serial_hd(2));
+qdev_prop_set_chr(dev, "chardev", serial_hd(2));
  qdev_init_nofail(dev);
  sysbus_mmio_map(busdev, 0, 0x1000);
  sysbus_mmio_map(busdev, 1, 0x13e0);





[RESEND PATCH 2/2] hw/i386: AMD-Vi IVRS DMA alias support

2019-10-23 Thread Alex Williamson
When we account for DMA aliases in the PCI address space, we can no
longer use a single IVHD entry in the IVRS covering all devices.  We
instead need to walk the PCI bus and create alias ranges when we find
a conventional bus.  These alias ranges cannot overlap with a "Select
All" range (as currently implemented), so we also need to enumerate
each device with IVHD entries.

Importantly, the IVHD entries used here include a Device ID, which is
simply the PCI BDF (Bus/Device/Function).  The guest firmware is
responsible for programming bus numbers, so the final revision of this
table depends on the update mechanism (acpi_build_update) to be called
after guest PCI enumeration.

For an example guest configuration of:

-+-[:40]---00.0-[41]00.0  Intel Corporation 82574L Gigabit Network 
Connection
 \-[:00]-+-00.0  Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller
 +-01.0  Device 1234:
 +-02.0-[01]00.0  Intel Corporation 82574L Gigabit Network 
Connection
 +-02.1-[02]00.0  Red Hat, Inc. QEMU XHCI Host Controller
 +-02.2-[03]--
 +-02.3-[04]--
 +-02.4-[05]--
 +-02.5-[06-09]00.0-[07-09]--+-00.0-[08]--
 |   \-01.0-[09]00.0  Intel 
Corporation 82574L Gigabit Network Connection
 +-02.6-[0a-0c]00.0-[0b-0c]--+-01.0-[0c]--
 |   \-03.0  Intel Corporation 82540EM 
Gigabit Ethernet Controller
 +-02.7-[0d]0e.0  Intel Corporation 82540EM Gigabit Ethernet 
Controller
 +-03.0  Red Hat, Inc. QEMU PCIe Expander bridge
 +-04.0  Advanced Micro Devices, Inc. [AMD] Device 0020
 +-1f.0  Intel Corporation 82801IB (ICH9) LPC Interface Controller
 +-1f.2  Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA 
Controller [AHCI mode]
 \-1f.3  Intel Corporation 82801I (ICH9 Family) SMBus Controller

Where we have:

00:02.7 PCI bridge: Intel Corporation 82801 PCI Bridge
 (dmi-to-pci-bridge)
00:03.0 Host bridge: Red Hat, Inc. QEMU PCIe Expander bridge
 (pcie-expander-bus)
06:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Upstream)
 (pcie-switch-upstream-port)
07:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream)
 (pcie-switch-downstream-port)
07:01.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream)
 (pcie-switch-downstream-port)
0a:00.0 PCI bridge: Red Hat, Inc. Device 000e
 (pcie-to-pci-bridge)

The following IVRS table is produced:

AMD-Vi: Using IVHD type 0x10
AMD-Vi: device: 00:04.0 cap: 0040 seg: 0 flags: d1 info 
AMD-Vi:mmio-addr: fed8
AMD-Vi:   DEV_SELECT devid: 40:00.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 41:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 41:1f.7
AMD-Vi:   DEV_SELECT devid: 00:00.0 flags: 00
AMD-Vi:   DEV_SELECT devid: 00:01.0 flags: 00
AMD-Vi:   DEV_SELECT devid: 00:02.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 01:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 01:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.1 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 02:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 02:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.2 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 03:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 03:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.3 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 04:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 04:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.4 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 05:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 05:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.5 flags: 00
AMD-Vi:   DEV_SELECT devid: 06:00.0 flags: 00
AMD-Vi:   DEV_SELECT devid: 07:00.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 08:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 08:1f.7
AMD-Vi:   DEV_SELECT devid: 07:01.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START devid: 09:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END  devid: 09:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.6 flags: 00
AMD-Vi:   DEV_SELECT devid: 0a:00.0 flags: 00
AMD-Vi:   DEV_ALIAS_RANGEdevid: 0b:00.0 flags: 00 devid_to: 
0b:00.0
AMD-Vi:   DEV_RANGE_END  devid: 0c:1f.7
AMD-Vi:   DEV_SELECT devid: 00:02.7 flags: 00
AMD-Vi:   DEV_ALIAS_RANGEdevid: 0d:00.0 flags: 00 devid_to: 
00:02.7
AMD-Vi:   DEV_RANGE_END  devid: 0d:1f.7
AMD-Vi:   DEV_SELECT devid: 00:03.0 flags: 00
AMD-Vi:   DEV_SELECT

[RESEND PATCH 0/2] PCI DMA alias support

2019-10-23 Thread Alex Williamson
Previous posting:
https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg06182.html

Rebased (no change) and added Peter's R-b.  Please apply for QEMU 4.2.

Previous cover letter:

Please see patch 1/ for the motivation and utility of this series.
This v1 submission improves on the previous RFC with revised commit
logs, comments, and more testing, and the missing IVRS support for DMA
alias ranges is now included.  Testing has been done with Linux guests
with both SeaBIOS and OVMF with configurations of intel-iommu and
amd-iommu.  Intel-iommu testing includes device assignment, amd-iommu
is necessarily limited to emulated devices with interrupt remapping
disabled and iommu=pt in the guest (enabling interrupt remapping or
disabling guest passthrough mode fails to work regardless of this
series).  This series is NOT intended for QEMU v4.1.  Thanks,

Alex

---

Alex Williamson (2):
  pci: Use PCI aliases when determining device IOMMU address space
  hw/i386: AMD-Vi IVRS DMA alias support


 hw/i386/acpi-build.c |  127 +++---
 hw/pci/pci.c |   43 -
 2 files changed, 160 insertions(+), 10 deletions(-)




[RESEND PATCH 1/2] pci: Use PCI aliases when determining device IOMMU address space

2019-10-23 Thread Alex Williamson
PCIe requester IDs are used by modern IOMMUs to differentiate devices
in order to provide a unique IOVA address space per device.  These
requester IDs are composed of the bus/device/function (BDF) of the
requesting device.  Conventional PCI pre-dates this concept and is
simply a shared parallel bus where transactions are claimed by
decoding target ranges rather than the packetized, point-to-point
mechanisms of PCI-express.  In order to interface conventional PCI
to PCIe, the PCIe-to-PCI bridge creates and accepts packetized
transactions on behalf of all downstream devices, using one of two
potential forms of a requester ID relating to the bridge itself or its
subordinate bus.  All downstream devices are therefore aliased by the
bridge's requester ID and it's not possible for the IOMMU to create
unique IOVA spaces for devices downstream of such buses.

At least that's how it works on bare metal.  Until now point we've
ignored this nuance of vIOMMU support in QEMU, creating a unique
AddressSpace per device regardless of the virtual bus topology.

Aside from simply being true to bare metal behavior, there are aspects
of a shared address space that we can use to our advantage when
designing a VM.  For instance, a PCI device assignment scenario where
we have the following IOMMU group on the host system:

  $ ls  /sys/kernel/iommu_groups/1/devices/
  :00:01.0  :01:00.0  :01:00.1

An IOMMU group is considered the smallest set of devices which are
fully DMA isolated from other devices by the IOMMU.  In this case the
root port at 00:01.0 does not guarantee that it prevents peer to peer
traffic between the endpoints on bus 01: and the devices are therefore
grouped together.  VFIO considers an IOMMU group to be the smallest
unit of device ownership and allows only a single shared IOVA space
per group due to the limitations of the isolation.

Therefore, if we attempt to create the following VM, we get an error:

qemu-system-x86_64 -machine q35... \
  -device intel-iommu,intremap=on \
  -device pcie-root-port,addr=1e.0,id=pcie.1 \
  -device vfio-pci,host=1:00.0,bus=pcie.1,addr=0.0,multifunction=on \
  -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1

qemu-system-x86_64: -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1: vfio \
:01:00.1: group 1 used in multiple address spaces

VFIO only allows a single IOVA space (AddressSpace) for both devices,
but we've placed them into a topology where the vIOMMU expects a
separate AddressSpace for each device.  On bare metal we know that
a conventional PCI bus would provide the sort of aliasing we need
here, forcing the IOMMU to consider these devices to be part of a
single shared IOVA space.  The support provided here does the same
for QEMU, such that we can create a conventional PCI topology to
expose equivalent AddressSpace sharing requirements to the VM:

qemu-system-x86_64 -machine q35... \
  -device intel-iommu,intremap=on \
  -device pcie-pci-bridge,addr=1e.0,id=pci.1 \
  -device vfio-pci,host=1:00.0,bus=pci.1,addr=1.0,multifunction=on \
  -device vfio-pci,host=1:00.1,bus=pci.1,addr=1.1

There are pros and cons to this configuration; it's not necessarily
recommended, it's simply a tool we can use to create configurations
which may provide additional functionality in spite of host hardware
limitations or as a benefit to the guest configuration or resource
usage.  An incomplete list of pros and cons:

Cons:
 a) Extended PCI configuration space is unavailable to devices
downstream of a conventional PCI bus.  The degree to which this
is a drawback depends on the device and guest drivers.
 b) Applying this topology to devices which are already isolated by
the host IOMMU (singleton IOMMU groups) will result in devices
which appear to be non-isolated to the VM (non-singleton groups).
This can limit configurations within the guest, such as userspace
drivers or nested device assignment.

Pros:
 a) QEMU better emulates bare metal.
 b) Configurations as above are now possible.
 c) Host IOMMU resources and VM locked memory requirements are reduced
in vIOMMU configurations due to shared IOMMU domains on the host
and avoidance of duplicate locked memory accounting.

Reviewed-by: Peter Xu 
Signed-off-by: Alex Williamson 
---
 hw/pci/pci.c |   43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index aa05c2b9b24e..0ac0e097bfbb 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2614,12 +2614,49 @@ AddressSpace *pci_device_iommu_address_space(PCIDevice 
*dev)
 {
 PCIBus *bus = pci_get_bus(dev);
 PCIBus *iommu_bus = bus;
+uint8_t devfn = dev->devfn;
 
-while(iommu_bus && !iommu_bus->iommu_fn && iommu_bus->parent_dev) {
-iommu_bus = pci_get_bus(iommu_bus->parent_dev);
+while (iommu_bus && !iommu_bus->iommu_fn && iommu_bus->parent_dev) {
+PCIBus *parent_bus = pci_get_bus(iommu_bus->parent_dev);
+
+/*
+ * The 

Re: [PATCH v3 05/33] serial-pci-multi: factor out multi_serial_get_nr_ports

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

Reused in following patch.

Signed-off-by: Marc-André Lureau 
---
  hw/char/serial-pci-multi.c | 26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/hw/char/serial-pci-multi.c b/hw/char/serial-pci-multi.c
index 5f13b5663b..6fa1cc6225 100644
--- a/hw/char/serial-pci-multi.c
+++ b/hw/char/serial-pci-multi.c
@@ -77,24 +77,26 @@ static void multi_serial_irq_mux(void *opaque, int n, int 
level)
  pci_set_irq(>dev, pending);
  }
  
+static int multi_serial_get_nr_ports(PCIDeviceClass *pc)


static size_t multi_serial_get_port_count()?

Reviewed-by: Philippe Mathieu-Daudé 


+{
+switch (pc->device_id) {
+case 0x0003:
+return 2;
+case 0x0004:
+return 4;
+}
+
+g_assert_not_reached();
+}
+
+
  static void multi_serial_pci_realize(PCIDevice *dev, Error **errp)
  {
  PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
  PCIMultiSerialState *pci = DO_UPCAST(PCIMultiSerialState, dev, dev);
  SerialState *s;
  Error *err = NULL;
-int i, nr_ports = 0;
-
-switch (pc->device_id) {
-case 0x0003:
-nr_ports = 2;
-break;
-case 0x0004:
-nr_ports = 4;
-break;
-}
-assert(nr_ports > 0);
-assert(nr_ports <= PCI_SERIAL_MAX_PORTS);
+int i, nr_ports = multi_serial_get_nr_ports(pc);
  
  pci->dev.config[PCI_CLASS_PROG] = pci->prog_if;

  pci->dev.config[PCI_INTERRUPT_PIN] = 0x01;





Re: [PATCH v3 09/33] serial: add "baudbase" property

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

Signed-off-by: Marc-André Lureau 
---
  hw/char/serial.c | 5 +++--
  include/hw/char/serial.h | 2 +-
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index 09e89727a6..069d8715d0 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -988,7 +988,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
  SerialState *s = SERIAL(dev);
  
  s->irq = irq;

-s->baudbase = baudbase;
+qdev_prop_set_uint32(dev, "baudbase", baudbase);
  qdev_prop_set_chr(dev, "chardev", chr);
  serial_realize_core(s, _fatal);
  qdev_set_legacy_instance_id(dev, base, 2);
@@ -1002,6 +1002,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
  
  static Property serial_properties[] = {

  DEFINE_PROP_CHR("chardev", SerialState, chr),
+DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
  DEFINE_PROP_END_OF_LIST(),
  };
  
@@ -1070,7 +1071,7 @@ SerialState *serial_mm_init(MemoryRegion *address_space,
  
  s->it_shift = it_shift;

  s->irq = irq;
-s->baudbase = baudbase;
+qdev_prop_set_uint32(dev, "baudbase", baudbase);
  qdev_prop_set_chr(dev, "chardev", chr);
  
  serial_realize_core(s, _fatal);

diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
index 180cc7c24e..3dc618598e 100644
--- a/include/hw/char/serial.h
+++ b/include/hw/char/serial.h
@@ -58,7 +58,7 @@ typedef struct SerialState {
  CharBackend chr;
  int last_break_enable;
  int it_shift;
-int baudbase;
+uint32_t baudbase;
  uint32_t tsr_retry;
  guint watch_tag;
  uint32_t wakeup;



Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH v3 08/33] serial: add "chardev" property

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

This is more QOM-friendly, callers may set/get the property themself.

Signed-off-by: Marc-André Lureau 
---
  hw/char/serial.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index 4af8b0ce4c..09e89727a6 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -34,6 +34,7 @@
  #include "sysemu/runstate.h"
  #include "qemu/error-report.h"
  #include "trace.h"
+#include "hw/qdev-properties.h"
  
  //#define DEBUG_SERIAL
  
@@ -988,7 +989,7 @@ SerialState *serial_init(int base, qemu_irq irq, int baudbase,
  
  s->irq = irq;

  s->baudbase = baudbase;
-qemu_chr_fe_init(>chr, chr, _abort);
+qdev_prop_set_chr(dev, "chardev", chr);
  serial_realize_core(s, _fatal);
  qdev_set_legacy_instance_id(dev, base, 2);
  qdev_init_nofail(dev);
@@ -999,11 +1000,17 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
  return s;
  }
  
+static Property serial_properties[] = {

+DEFINE_PROP_CHR("chardev", SerialState, chr),
+DEFINE_PROP_END_OF_LIST(),
+};
+
  static void serial_class_init(ObjectClass *klass, void* data)
  {
  DeviceClass *dc = DEVICE_CLASS(klass);
  
  dc->vmsd = _serial;

+dc->props = serial_properties;
  }
  
  static const TypeInfo serial_info = {

@@ -1064,7 +1071,7 @@ SerialState *serial_mm_init(MemoryRegion *address_space,
  s->it_shift = it_shift;
  s->irq = irq;
  s->baudbase = baudbase;
-qemu_chr_fe_init(>chr, chr, _abort);
+qdev_prop_set_chr(dev, "chardev", chr);
  
  serial_realize_core(s, _fatal);

  qdev_set_legacy_instance_id(dev, base, 2);



Reviewed-by: Philippe Mathieu-Daudé 



Re: [Qemu-devel] [PATCH v2 2/2] linux-user: manage binfmt-misc preserve-arg[0] flag

2019-10-23 Thread Christophe de Dinechin


Laurent Vivier writes:

> Add --preserve-arg0 in qemu-binfmt-conf.sh to configure the preserve-arg0
> flag.

There is an inconsistency below, where some parts use preserve-argv0
and others preserve-arg0 (no v)

Frankly, I would accept both ;-)

>
> Now, if QEMU is started with -0 or QEMU_ARGV0 and an empty parameter
> argv[0] (the full pathname provided by binfmt-misc) is removed and
> replaced by argv[1] (the original argv[0] provided by binfmt-misc when
> 'P'/preserve-arg[0] is set)
>
> For instance:
>
>   $ sudo QEMU_ARGV0= chroot m68k-chroot sh -c 'echo $0'
>   sh
>
> without this patch:
>
>   $ sudo chroot m68k-chroot sh -c 'echo $0'
>   /usr/bin/sh
>
> QEMU can be forced to always use preserve-argv[0] at configuration
> time with --force-preserve-argv0

Example of 'argv0' case

>
> Signed-off-by: Laurent Vivier 
> ---
>
> Notes:
> v2: add --force-preserve-argv0 configure option
>
>  configure   |  8 +++
>  linux-user/main.c   | 24 +++-
>  scripts/qemu-binfmt-conf.sh | 44 +++--
>  3 files changed, 58 insertions(+), 18 deletions(-)
>
> diff --git a/configure b/configure
> index 95134c0180b2..3568e192776c 100755
> --- a/configure
> +++ b/configure
> @@ -498,6 +498,7 @@ libxml2=""
>  docker="no"
>  debug_mutex="no"
>  libpmem=""
> +force_preserve_argv0="no"
>  default_devices="yes"
>
>  # cross compilers defaults, can be overridden with --cross-cc-ARCH
> @@ -1543,6 +1544,8 @@ for opt do
>;;
>--disable-libpmem) libpmem=no
>;;
> +  --force-preserve-argv0) force_preserve_argv0=yes
> +  ;;
>*)
>echo "ERROR: unknown option $opt"
>echo "Try '$0 --help' for more information"
> @@ -1740,6 +1743,8 @@ Advanced options (experts only):
>--enable-profilerprofiler support
>--enable-debug-stack-usage
> track the maximum stack usage of stacks created 
> by qemu_alloc_stack
> +  --force-preserve-argv0   for linux-user only, force the use of binfmt_misc 
> 'P'
> +   flag (preserve-argv[0])
>
>  Optional features, enabled with --enable-FEATURE and
>  disabled with --disable-FEATURE, default is enabled if available:
> @@ -7736,6 +7741,9 @@ if test "$target_user_only" = "yes" ; then
>  fi
>  if test "$target_linux_user" = "yes" ; then
>echo "CONFIG_LINUX_USER=y" >> $config_target_mak
> +  if test "$force_preserve_argv0" = "yes" ; then
> +echo "CONFIG_FORCE_PRESERVE_ARGV0=y" >> $config_target_mak
> +  fi
>  fi
>  list=""
>  if test ! -z "$gdb_xml_files" ; then
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 28f0065b6ddf..02354d58e866 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -605,6 +605,7 @@ int main(int argc, char **argv, char **envp)
>  int i;
>  int ret;
>  int execfd;
> +bool preserve_argv0;
>
>  error_init(argv[0]);
>  module_call_init(MODULE_INIT_TRACE);
> @@ -653,6 +654,9 @@ int main(int argc, char **argv, char **envp)
>
>  init_qemu_uname_release();
>
> +/*
> + * Manage binfmt-misc open-binary flag
> + */
>  execfd = qemu_getauxval(AT_EXECFD);
>  if (execfd == 0) {
>  execfd = open(exec_path, O_RDONLY);
> @@ -662,6 +666,24 @@ int main(int argc, char **argv, char **envp)
>  }
>  }
>
> + /*
> +  * argv0 with an empty string will set argv[optind + 1]
> +  * as target_argv[0]
> +  */
> +#ifdef CONFIG_FORCE_PRESERVE_ARGV0
> +preserve_argv0 = true;
> +#else
> +preserve_argv0 = (argv0 != NULL && argv0[0] == 0);
> +#endif
> +/*
> + * Manage binfmt-misc preserve-arg[0] flag
> + *argv[optind] full path to the binary
> + *argv[optind + 1] original argv[0]
> + */
> +if (optind + 1 < argc && preserve_argv0) {
> +optind++;
> +}
> +
>  if (cpu_model == NULL) {
>  cpu_model = cpu_get_model(get_elf_eflags(execfd));
>  }
> @@ -766,7 +788,7 @@ int main(int argc, char **argv, char **envp)
>   * argv[0] pointer with the given one.
>   */
>  i = 0;
> -if (argv0 != NULL) {
> +if (argv0 != NULL && argv0[0] != 0) {
>  target_argv[i++] = strdup(argv0);
>  }
>  for (; i < target_argc; i++) {
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index b5a16742a149..7c9a4609c232 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -170,25 +170,27 @@ usage() {
>  Usage: qemu-binfmt-conf.sh [--qemu-path PATH][--debian][--systemd CPU]
> [--help][--credential yes|no][--exportdir PATH]
> [--persistent yes|no][--qemu-suffix SUFFIX]
> +   [--preserve-arg0 yes|no]

Example of arg0 case

>
> Configure binfmt_misc to use qemu interpreter
>
> -   --help:display this usage
> -   --qemu-path:   set path to qemu interpreter ($QEMU_PATH)
> -   --qemu-suffix: add a suffix to the default 

Re: [PATCH v3 03/33] sysbus: remove outdated comment

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

The init callback is no more since commit
817a17fc60f44e29a1944b60d32f45ea127f0cf9 ("core/sysbus: remove the
SysBusDeviceClass::init path")

Signed-off-by: Marc-André Lureau 
---
  include/hw/sysbus.h | 4 
  1 file changed, 4 deletions(-)

diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 2eb0484388..c4a1c0adfa 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -24,10 +24,6 @@ typedef struct SysBusDevice SysBusDevice;
  
  /**

   * SysBusDeviceClass:
- * @init: Callback function invoked when the #DeviceState.realized property
- * is changed to %true. Deprecated, new types inheriting directly from
- * TYPE_SYS_BUS_DEVICE should use #DeviceClass.realize instead, new leaf
- * types should consult their respective parent type.
   *
   * SysBusDeviceClass is not overriding #DeviceClass.realize, so derived
   * classes overriding it are not required to invoke its implementation.



Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH v3 02/33] sysbus: remove unused sysbus_try_create*

2019-10-23 Thread Philippe Mathieu-Daudé

"Last user removed in commit 7a10ef51c (2013)."

On 10/23/19 7:31 PM, Marc-André Lureau wrote:

Signed-off-by: Marc-André Lureau 


Reviewed-by: Philippe Mathieu-Daudé 


---
  hw/core/sysbus.c| 32 
  hw/i386/pc.c|  1 -
  include/hw/sysbus.h |  9 +
  3 files changed, 1 insertion(+), 41 deletions(-)

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 9e69c83aed..08b0311c5f 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -250,38 +250,6 @@ DeviceState *sysbus_create_varargs(const char *name,
  return dev;
  }
  
-DeviceState *sysbus_try_create_varargs(const char *name,

-   hwaddr addr, ...)
-{
-DeviceState *dev;
-SysBusDevice *s;
-va_list va;
-qemu_irq irq;
-int n;
-
-dev = qdev_try_create(NULL, name);
-if (!dev) {
-return NULL;
-}
-s = SYS_BUS_DEVICE(dev);
-qdev_init_nofail(dev);
-if (addr != (hwaddr)-1) {
-sysbus_mmio_map(s, 0, addr);
-}
-va_start(va, addr);
-n = 0;
-while (1) {
-irq = va_arg(va, qemu_irq);
-if (!irq) {
-break;
-}
-sysbus_connect_irq(s, n, irq);
-n++;
-}
-va_end(va);
-return dev;
-}
-
  static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
  {
  SysBusDevice *s = SYS_BUS_DEVICE(dev);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 4b1904237e..00ee16ccab 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1902,7 +1902,6 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
   * when the HPET wants to take over. Thus we have to disable the latter.
   */
  if (!no_hpet && (!kvm_irqchip_in_kernel() || kvm_has_pit_state2())) {
-/* In order to set property, here not using sysbus_try_create_simple */
  hpet = qdev_try_create(NULL, TYPE_HPET);
  if (hpet) {
  /* For pc-piix-*, hpet's intcap is always IRQ2. For pc-q35-1.7
diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 27e80881da..2eb0484388 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -117,8 +117,7 @@ void foreach_dynamic_sysbus_device(FindSysbusDeviceFunc 
*func, void *opaque);
  /* Legacy helper function for creating devices.  */
  DeviceState *sysbus_create_varargs(const char *name,
   hwaddr addr, ...);
-DeviceState *sysbus_try_create_varargs(const char *name,
-   hwaddr addr, ...);
+
  static inline DeviceState *sysbus_create_simple(const char *name,
hwaddr addr,
qemu_irq irq)
@@ -126,11 +125,5 @@ static inline DeviceState *sysbus_create_simple(const char 
*name,
  return sysbus_create_varargs(name, addr, irq, NULL);
  }
  
-static inline DeviceState *sysbus_try_create_simple(const char *name,

-hwaddr addr,
-qemu_irq irq)
-{
-return sysbus_try_create_varargs(name, addr, irq, NULL);
-}
  
  #endif /* HW_SYSBUS_H */






Re: LEON3 networking

2019-10-23 Thread Philippe Mathieu-Daudé

Hi Jiri,

On 10/23/19 9:55 PM, Jiri Gaisler wrote:

BTW, here is a patch that you might want to apply to qemu if you intend
to run RTEMS on leon3. The plug area must support byte accesses,
which is used by the RTEMS grlib scanning functions...


Do you mean this one?

http://gaisler.org/qemu/qemu-4.1.0-leon3.patch

-- >8 --
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -228,6 +228,9 @@ static uint64_t grlib_apb_pnp_read(void *opaque, 
hwaddr offset, unsigned size)

 {
 APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);

+if (size != 4)
+return apb_pnp->regs[offset >> 2] >> ((~offset & 3) * 8);
+
 return apb_pnp->regs[offset >> 2];
 }

---

But then this is incorrect for 16-bit accesses.

The proper patch might be:

-- >8 --
@@ -234,6 +234,13 @@ static uint64_t grlib_apb_pnp_read(void *opaque, 
hwaddr offset, unsigned size)

 static const MemoryRegionOps grlib_apb_pnp_ops = {
 .read   = grlib_apb_pnp_read,
 .endianness = DEVICE_BIG_ENDIAN,
+.valid = {
+.min_access_size = 1,
+},
+.impl = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
 };

---

(Unrelated note, this device model lacks the MemoryRegionOps::write 
handler).



Jiri.

On 10/23/19 8:37 PM, Jiri Gaisler wrote:

Leon3 uses the GRETH ethernet IP core for networking. You would need to
write a qemu emulation model of it to get networking support. The GRETH
is fairly well described in the GRLIB IP manual, so it should not be
impossible. The core is also available in open-source (VHDL) if you need
to look up some finer details ... :-)

Jiri.

On 10/23/19 6:59 PM, Joshua Shaffer wrote:

Does anyone know what needs implemented to get networking supported?

Joshua

On Wed, Oct 16, 2019 at 6:34 AM Fabien Chouteau  wrote:

Hello people,

On 15/10/2019 18:57, Philippe Mathieu-Daudé wrote:

Hi Joshua,

On 10/15/19 3:17 PM, Joshua Shaffer wrote:

Hello,

I've been using the LEON3 port of qemu, and am wondering if anyone has touched 
the networking setup for such since the thread here: 
https://lists.rtems.org/pipermail/users/2014-September/028224.html

Thanks for sharing this!

Good news, Jiri keeps rebasing his patch with the latest stable version.
Bad news, he didn't not signed his work with a "Signed-off-by" tag so we can 
not take this as it into the mainstream repository, see 
https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line


The Gaisler patches have been rewrote by my colleague Frederic (in CC) and they 
are now in mainstream.
(see https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03869.html)

But none of them are implementing network support, and I never heard of someone 
working on network for leon3.

Regards,






Re: qemu/powernv: coreboot support?

2019-10-23 Thread Marty E. Plummer
On Tue, Oct 22, 2019 at 09:58:10AM +0200, Cédric Le Goater wrote:
> On 22/10/2019 02:32, Marty E. Plummer wrote:
> > On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote:
> >> On 21/10/2019 07:34, David Gibson wrote:
> >>> On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote:
>  On 20/10/2019 08:28, David Gibson wrote:
> >
> > Ok.  Note that the qemu emulated machine doesn't model the hardware
> > right down to the level of hostboot.  That's wy we're just loading
> > skiboot and jumping straight into it usually.  I guess clg's stuff to
> > load pnor images gets us a little closer to the hardware behaviour,
> > but I think it's still only a rough approximation.
> 
> > On that note, is qemu-ppc64 currently capable of running LE firmware? My
> > coreboot port has currently reached a hitch in that part of the firmware
> > headers mapping stuff out is saved in LE mode while the cpu (real or emu)
> > is running in BE mode (FMAP headers are saved LE but CBFS headers are
> > saved BE)
>  It's really tied to the OpenPOWER firmwares using the HIOMAP protocol
>  to discuss with the BMC and load the flash. We could loosen how QEMU 
>  interprets the MTD device and use a property to inform QEMU that this
>  is an OpenPOWER  PNOR file and that skiboot and can be loaded from it.
>  Something to discuss.
> >>>
> >>> Right.  I'm guessing one significant issue here is that to fully model
> >>> the BMC, with *its* firmware and comms channels with the main host
> >>> would be quite a lot of work, hence cheating a bit to bypass that.
> >>
> >> In fact, we are not cheating that much. We use the IPMI BT interface of 
> >> QEMU to handle the HIOMAP communication with the BMC and this model is 
> >> quite precise. 
> >>
> >> The mapping of the PNOR is simply mapped on the LPC FW address space. 
> >> The underlying access are simplified because we don't have a LPC model
> >> but we could generate all the SPI transaction using the Aspeed models. 
> >> I had experiments in that sense for P8. 
> >>
> > Honestly getting the coreboot.rom into the lpc fw addr space in the same
> > way you do pnor images would be a useful sim, as that's more or less how
> > its going to be done on existing hardware.
> 
> That is covered by patch 'ppc/pnv: Add HIOMAP commands' in the series
> I sent.
> 
Unless I'm mistaken I have that patch in my build (I assume you pulled
that right from your git branch powernv-4.2, which is what I built from)
and that it would still parse and look for the skiboot partition, and
run it. I need something akin to 'hey, shove this at the addr space and
start executing $bios (where bios is either the bottom of the flash in
that addr space or a provided -bios file on the command line).

The final intent after the first 'conversion' flash is that the coreboot
bootblock will reside in the seeprom, akin to current hostboot bootloader,
and then pull romstage from the flash over lpc into cache, then after
romstage initializes memory pull ramstage into from the flash over lpc
into ram and start executing that.
> C. 



Re: [PATCH v7 00/14] target/mips: Misc cleanups for September/October 2019

2019-10-23 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/1571826227-10583-1-git-send-email-aleksandar.marko...@rt-rk.com/



Hi,

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

Subject: [PATCH v7 00/14] target/mips: Misc cleanups for September/October 2019
Type: series
Message-id: 1571826227-10583-1-git-send-email-aleksandar.marko...@rt-rk.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 ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
7ec7c3a target/mips: Demacro LMI decoder
4fc17e3 target/mips: Add support for emulation of CRC32 group of instructions
e96918e target/mips: msa: Split helpers for ASUB_.
d7f7bd6 target/mips: msa: Split helpers for HSUB_.
7249cb7 target/mips: msa: Split helpers for PCK.
07e71ba target/mips: msa: Split helpers for S.
56e3978 target/mips: msa: Split helpers for HADD_.
1e4e614 target/mips: msa: Split helpers for ADD<_A|S_A|S_S|S_U|V>.
2e7b6b9 target/mips: msa: Split helpers for ILV.
5c7c560 target/mips: msa: Split helpers for _.
0a73de1 target/mips: msa: Split helpers for _A.
cdecb4d MAINTAINERS: Update mail address of Aleksandar Rikalo
2e158cc target/mips: Clean up op_helper.c
8f48cdd target/mips: Clean up helper.c

=== OUTPUT BEGIN ===
1/14 Checking commit 8f48cdd5eeff (target/mips: Clean up helper.c)
2/14 Checking commit 2e158cc201b0 (target/mips: Clean up op_helper.c)
ERROR: spaces required around that '*' (ctx:WxV)
#1059: FILE: target/mips/op_helper.c:3871:
+  float_status *status)  \
^

total: 1 errors, 0 warnings, 1681 lines checked

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

3/14 Checking commit cdecb4d2b939 (MAINTAINERS: Update mail address of 
Aleksandar Rikalo)
4/14 Checking commit 0a73de15e1da (target/mips: msa: Split helpers for 
_A.)
5/14 Checking commit 5c7c5604af5a (target/mips: msa: Split helpers for 
_.)
6/14 Checking commit 2e7b6b975619 (target/mips: msa: Split helpers for 
ILV.)
7/14 Checking commit 1e4e614a7140 (target/mips: msa: Split helpers for 
ADD<_A|S_A|S_S|S_U|V>.)
8/14 Checking commit 56e397811d1c (target/mips: msa: Split helpers for 
HADD_.)
9/14 Checking commit 07e71ba61252 (target/mips: msa: Split helpers for 
S.)
10/14 Checking commit 7249cb7ea32e (target/mips: msa: Split helpers for 
PCK.)
11/14 Checking commit d7f7bd6e74d2 (target/mips: msa: Split helpers for 
HSUB_.)
12/14 Checking commit e96918e60aa2 (target/mips: msa: Split helpers for 
ASUB_.)
13/14 Checking commit 4fc17e3d3450 (target/mips: Add support for emulation of 
CRC32 group of instructions)
14/14 Checking commit 7ec7c3a29c8d (target/mips: Demacro LMI decoder)
ERROR: trailing statements should be on next line
#64: FILE: target/mips/translate.c:5574:
+case OPC_PSUBSH: gen_helper_psubsh(t0, t0, t1);

total: 1 errors, 0 warnings, 251 lines checked

Patch 14/14 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/1571826227-10583-1-git-send-email-aleksandar.marko...@rt-rk.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

2019-10-23 Thread Michael Weiser
For completeness's sake: All the changes you proposed (replacing call to
qcow2_detect_metadata_preallocation() with ret = true and ret = false,
moving acquiring s->lock before the call and replacing the call with a
sleep) prevent corruption on my system. The latter would suggest that
it's not so much a race being exposed by a timing change as a race
directly when accessing qcow2 internals without the lock being held.

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

Title:
  4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Status in QEMU:
  New

Bug description:
  I'm seeing massive corruption of qcow2 images with qemu 4.1.0 and git
  master as of 7f21573c822805a8e6be379d9bcf3ad9effef3dc after a few
  savevm/quit/loadvm cycles. I've narrowed it down to the following
  reproducer (further notes below):

  # qemu-img check debian.qcow2
  No errors were found on the image.
  251601/327680 = 76.78% allocated, 1.63% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208
  # bin/qemu/bin/qemu-system-x86_64 -machine pc-q35-4.0.1,accel=kvm -m 4096 
-chardev stdio,id=charmonitor -mon chardev=charmonitor -drive 
file=debian.qcow2,id=d -S
  qemu-system-x86_64: warning: dbind: Couldn't register with accessibility bus: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
  QEMU 4.1.50 monitor - type 'help' for more information
  (qemu) loadvm foo
  (qemu) c
  (qemu) qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  quit
  [m@nargothrond:~] qemu-img check debian.qcow2
  Leaked cluster 85179 refcount=2 reference=1
  Leaked cluster 85180 refcount=2 reference=1
  ERROR cluster 266150 refcount=0 reference=2
  [...]
  ERROR OFLAG_COPIED data cluster: l2_entry=42284 refcount=1

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

  2 leaked clusters were found on the image.
  This means waste of disk space, but no harm to data.
  259266/327680 = 79.12% allocated, 1.67% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208

  This is on a x86_64 Linux 5.3.1 Gentoo host with qemu-system-x86_64
  and accel=kvm. The compiler is gcc-9.2.0 with the rest of the system
  similarly current.

  Reproduced with qemu-4.1.0 from distribution package as well as
  vanilla git checkout of tag v4.1.0 and commit
  7f21573c822805a8e6be379d9bcf3ad9effef3dc (today's master). Does not
  happen with qemu compiled from vanilla checkout of tag v4.0.0. Build
  sequence:

  ./configure --prefix=$HOME/bin/qemu-bisect --target-list=x86_64-softmmu 
--disable-werror --disable-docs
  [...]
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
  [...] (can provide full configure output if helpful)
  make -j8 install

  The kind of guest OS does not matter: seen with Debian testing 64bit,
  Windows 7 x86/x64 BIOS and Windows 7 x64 EFI.

  The virtual storage controller does not seem to matter: seen with
  VirtIO SCSI, emulated SCSI and emulated SATA AHCI.

  Caching modes (none, directsync, writeback), aio mode (threads,
  native) or discard (ignore, unmap) or detect-zeroes (off, unmap) does
  not influence occurence either.

  Having more RAM in the guest seems to increase odds of corruption:
  With 512MB to the Debian guest problem hardly occurs at all, with 4GB
  RAM it happens almost instantly.

  An automated reproducer works as follows:

  - the guest *does* mount its root fs and swap with option discard and
  my testing leaves me with the impression that file deletion rather
  than reading is causing the issue

  - foo is a snapshot of the running Debian VM which is already running
  command

  # while true ; do dd if=/dev/zero of=foo bs=10240k count=400 ; done

  to produce some I/O to the disk (4GB file with 4GB of RAM).

  - on the host a loop continuously resumes and saves the guest state
  and quits qemu inbetween:

  # while true ; do (echo loadvm foo ; echo c ; sleep 10 ; echo stop ;
  echo savevm foo ; echo quit ) | bin/qemu-bisect/bin/qemu-system-x86_64
  -machine pc-q35-3.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor
  -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S -display
  none ; done

  - quitting qemu inbetween saves and loads seems to be necessary for
  the problem to occur. Just continusouly in one session saving and
  loading guest state does not trigger it.

  - For me, after about 2 to 6 iterations of above loop the image is
  corrupted.

  - corruption manifests with other messages from qemu as well, e.g.:

  (qemu) loadvm foo
  Error: Device 'd' does not have the requested snapshot 'foo'

  Using above reproducer 

Re: [PATCH v5 02/11] pci: add option for net failover

2019-10-23 Thread Alex Williamson
On Wed, 23 Oct 2019 21:30:35 +0200
Jens Freimann  wrote:

> On Wed, Oct 23, 2019 at 12:06:48PM -0600, Alex Williamson wrote:
> >On Wed, 23 Oct 2019 10:27:02 +0200
> >Jens Freimann  wrote:
> >  
> >> This patch adds a net_failover_pair_id property to PCIDev which is
> >> used to link the primary device in a failover pair (the PCI dev) to
> >> a standby (a virtio-net-pci) device.
> >>
> >> It only supports ethernet devices. Also currently it only supports
> >> PCIe devices. QEMU will exit with an error message otherwise.
> >>
> >> Signed-off-by: Jens Freimann 
> >> ---
> >>  hw/pci/pci.c | 17 +
> >>  include/hw/pci/pci.h |  3 +++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> >> index aa05c2b9b2..fa9b5219f8 100644
> >> --- a/hw/pci/pci.c
> >> +++ b/hw/pci/pci.c
> >> @@ -75,6 +75,8 @@ static Property pci_props[] = {
> >>  QEMU_PCIE_LNKSTA_DLLLA_BITNR, true),
> >>  DEFINE_PROP_BIT("x-pcie-extcap-init", PCIDevice, cap_present,
> >>  QEMU_PCIE_EXTCAP_INIT_BITNR, true),
> >> +DEFINE_PROP_STRING("net_failover_pair_id", PCIDevice,
> >> +net_failover_pair_id),  
> >
> >Nit, white space appears broken here.  
> 
> I'll fix it.
> 
> >>  DEFINE_PROP_END_OF_LIST()
> >>  };
> >>
> >> @@ -2077,6 +2079,7 @@ static void pci_qdev_realize(DeviceState *qdev, 
> >> Error **errp)
> >>  ObjectClass *klass = OBJECT_CLASS(pc);
> >>  Error *local_err = NULL;
> >>  bool is_default_rom;
> >> +uint16_t class_id;
> >>
> >>  /* initialize cap_present for pci_is_express() and pci_config_size(),
> >>   * Note that hybrid PCIs are not set automatically and need to manage
> >> @@ -2101,6 +2104,20 @@ static void pci_qdev_realize(DeviceState *qdev, 
> >> Error **errp)
> >>  }
> >>  }
> >>
> >> +if (pci_dev->net_failover_pair_id) {
> >> +if (!pci_is_express(pci_dev)) {
> >> +error_setg(errp, "failover device is not a PCIExpress 
> >> device");
> >> +error_propagate(errp, local_err);
> >> +return;
> >> +}  
> >
> >Did we decide we don't need to test that the device is also in a
> >hotpluggable slot?
> 
> Hmm, my reply to you was never sent. I thought the check for
> qdev_device_add() was sufficient but you said that works only
> after qdev_hotplug is set (after machine creation). I modified
> the check to this:
> 
> hide = should_hide_device(opts);  
> 
>   
> 
> if ((hide || qdev_hotplug) && bus && !qbus_is_hotpluggable(bus)) {
> 
> error_setg(errp, QERR_BUS_NO_HOTPLUG, bus->name); 
> 
> return NULL;  
> 
> } 
> 
>   
> 
> if (hide) {   
> 
> return NULL;  
> 
> }
> 
> This will make qemu fail when we have the device in the initial
> configuration or when we hotplug it to a bus that doesn't support it.
> I tested both with a device on pcie.0. Am I missing something? 

Nope, sorry, I was expecting the check here and didn't see that you
perform it elsewhere.  Seems good enough for me.
 
> >Are there also multi-function considerations that
> >should be prevented or documented?  For example, if a user tries to
> >configure both the primary and failover NICs in the same slot, I assume
> >bad things will happen.  
> 
>   I would have expected that this is already checked in pci code, but
> it is not. I tried it and when I put both devices into the same slot
> they are both unplugged from the guest during boot but nothing else
> happens. I don't know what triggers that unplug of the devices.
> 
> I'm not aware of any other problems regarding multi-function, which
> doesn't mean there aren't any. 

Hmm, was the hidden device at function #0?  The guest won't find any
functions if function #0 isn't present, but I don't know what would
trigger the hotplug.  The angle I'm thinking is that we only have slot
level granularity for hotplug, so any sort of automatic hotplug of a
slot should probably think about bystander devices within the slot.
Thanks,

Alex

> >> +class_id = pci_get_word(pci_dev->config + PCI_CLASS_DEVICE);
> >> +if (class_id != PCI_CLASS_NETWORK_ETHERNET) {
> >> +error_setg(errp, "failover device is not an Ethernet device");
> >> +

Re: [PATCH] nvme: fix NSSRS offset in CAP register

2019-10-23 Thread Klaus Birkelund
On Wed, Oct 23, 2019 at 11:26:57AM -0400, John Snow wrote:
> 
> 
> On 10/23/19 3:33 AM, Klaus Jensen wrote:
> > Fix the offset of the NSSRS field the CAP register.
> 
> From NVME 1.4, section 3 ("Controller Registers"), subsection 3.1.1
> ("Offset 0h: CAP – Controller Capabilities") CAP_NSSRS_SHIFT is bit 36,
> not 33.
> 
> > 
> > Signed-off-by: Klaus Jensen 
> > Reported-by: Javier Gonzalez 
> > ---
> >  include/block/nvme.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/block/nvme.h b/include/block/nvme.h
> > index 3ec8efcc435e..fa15b51c33bb 100644
> > --- a/include/block/nvme.h
> > +++ b/include/block/nvme.h
> > @@ -23,7 +23,7 @@ enum NvmeCapShift {
> >  CAP_AMS_SHIFT  = 17,
> >  CAP_TO_SHIFT   = 24,
> >  CAP_DSTRD_SHIFT= 32,
> > -CAP_NSSRS_SHIFT= 33,
> > +CAP_NSSRS_SHIFT= 36,
> >  CAP_CSS_SHIFT  = 37,
> >  CAP_MPSMIN_SHIFT   = 48,
> >  CAP_MPSMAX_SHIFT   = 52,
> > 
> 
> I like updating commit messages with spec references; if it can be
> updated that would be nice.
> 
> Regardless:
> 
> Reviewed-by: John Snow 
> 

Sounds good. Can the committer squash that in?


Cheers,
Klaus



Re: [PATCH] virtio: fix IO request length in virtio SCSI/block #PSBM-78839

2019-10-23 Thread Michael S. Tsirkin
On Mon, Oct 21, 2019 at 02:24:55PM +0100, Stefan Hajnoczi wrote:
> On Fri, Oct 18, 2019 at 02:55:47PM +0300, Denis Plotnikov wrote:
> > From: "Denis V. Lunev" 
> > 
> > Linux guests submit IO requests no longer than PAGE_SIZE * max_seg
> > field reported by SCSI controler. Thus typical sequential read with
> > 1 MB size results in the following pattern of the IO from the guest:
> >   8,16   115754 2.766095122  2071  D   R 2095104 + 1008 [dd]
> >   8,16   115755 2.766108785  2071  D   R 2096112 + 1008 [dd]
> >   8,16   115756 2.766113486  2071  D   R 2097120 + 32 [dd]
> >   8,16   115757 2.767668961 0  C   R 2095104 + 1008 [0]
> >   8,16   115758 2.768534315 0  C   R 2096112 + 1008 [0]
> >   8,16   115759 2.768539782 0  C   R 2097120 + 32 [0]
> > The IO was generated by
> >   dd if=/dev/sda of=/dev/null bs=1024 iflag=direct
> > 
> > This effectively means that on rotational disks we will observe 3 IOPS
> > for each 2 MBs processed. This definitely negatively affects both
> > guest and host IO performance.
> > 
> > The cure is relatively simple - we should report lengthy scatter-gather
> > ability of the SCSI controller. Fortunately the situation here is very
> > good. VirtIO transport layer can accomodate 1024 items in one request
> > while we are using only 128. This situation is present since almost
> > very beginning. 2 items are dedicated for request metadata thus we
> > should publish VIRTQUEUE_MAX_SIZE - 2 as max_seg.
> > 
> > The following pattern is observed after the patch:
> >   8,16   1 9921 2.662721340  2063  D   R 2095104 + 1024 [dd]
> >   8,16   1 9922 2.662737585  2063  D   R 2096128 + 1024 [dd]
> >   8,16   1 9923 2.665188167 0  C   R 2095104 + 1024 [0]
> >   8,16   1 9924 2.665198777 0  C   R 2096128 + 1024 [0]
> > which is much better.
> > 
> > The dark side of this patch is that we are tweaking guest visible
> > parameter, though this should be relatively safe as above transport
> > layer support is present in QEMU/host Linux for a very long time.
> > The patch adds configurable property for VirtIO SCSI with a new default
> > and hardcode option for VirtBlock which does not provide good
> > configurable framework.
> > 
> > Unfortunately the commit can not be applied as is. For the real cure we
> > need guest to be fixed to accomodate that queue length, which is done
> > only in the latest 4.14 kernel. Thus we are going to expose the property
> > and tweak it on machine type level.
> > 
> > The problem with the old kernels is that they have
> > max_segments <= virtqueue_size restriction which cause the guest
> > crashing in the case of violation.
> > To fix the case described above in the old kernels we can increase
> > virtqueue_size to 256 and max_segments to 254. The pitfall here is
> > that seabios allows the virtqueue_size-s < 128, however, the seabios
> > patch extending that value to 256 is pending.
> 
> If I understand correctly you are relying on Indirect Descriptor support
> in the guest driver in order to exceed the Virtqueue Descriptor Table
> size.
> 
> Unfortunately the "max_segments <= virtqueue_size restriction" is
> required by the VIRTIO 1.1 specification:
> 
>   2.6.5.3.1 Driver Requirements: Indirect Descriptors
> 
>   A driver MUST NOT create a descriptor chain longer than the Queue
>   Size of the device.
> 
> So this idea seems to be in violation of the specification?
> 
> There is a bug in hw/block/virtio-blk.c:virtio_blk_update_config() and
> hw/scsi/virtio-scsi.c:virtio_scsi_get_config():
> 
>   virtio_stl_p(vdev, _max, 128 - 2);
> 
> This number should be the minimum of blk_get_max_iov() and
> virtio_queue_get_num(), minus 2 for the header and footer.
> 
> I looked at the Linux SCSI driver code and it seems each HBA has a
> single max_segments number - it does not vary on a per-device basis.
> This could be a problem if two host block device with different
> max_segments are exposed to the guest through the same virtio-scsi
> controller.  Another bug? :(
> 
> Anyway, if you want ~1024 descriptors you should set Queue Size to 1024.
> I don't see a spec-compliant way of doing it otherwise.  Hopefully I
> have overlooked something and there is a nice way to solve this.
> 
> Stefan



We can extend the spec of course. And we can also
have different vq sizes between legacy and modern
interfaces.

-- 
MST



[PATCH] Semihost SYS_READC implementation (v3)

2019-10-23 Thread Keith Packard
Provides a blocking call to read a character from the console using
semihosting.chardev, if specified. This takes some careful command
line options to use stdio successfully as the serial ports, monitor
and semihost all want to use stdio. Here's a sample set of command
line options which share stdio betwen semihost, monitor and serial
ports:

qemu \
-chardev stdio,mux=on,id=stdio0 \
-serial chardev:stdio0 \
-semihosting-config enable=on,chardev=stdio0 \
-mon chardev=stdio0,mode=readline

This creates a chardev hooked to stdio and then connects all of the
subsystems to it. A shorter mechanism would be good to hear about.

v2:
Add implementation in linux-user/arm/semihost.c

v3:  (thanks to Paolo Bonzini )
Replace hand-rolled fifo with fifo8
Avoid mixing code and declarations
Remove spurious (void) cast of function parameters
Define qemu_semihosting_console_init when CONFIG_USER_ONLY

Signed-off-by: Keith Packard 
---
 hw/semihosting/console.c  | 73 +++
 include/hw/semihosting/console.h  | 12 +
 include/hw/semihosting/semihost.h |  4 ++
 linux-user/arm/semihost.c | 24 ++
 target/arm/arm-semi.c |  3 +-
 vl.c  |  3 ++
 6 files changed, 117 insertions(+), 2 deletions(-)

diff --git a/hw/semihosting/console.c b/hw/semihosting/console.c
index b4b17c8afb..197bff079b 100644
--- a/hw/semihosting/console.c
+++ b/hw/semihosting/console.c
@@ -98,3 +98,76 @@ void qemu_semihosting_console_outc(CPUArchState *env, 
target_ulong addr)
   __func__, addr);
 }
 }
+
+#include 
+#include "chardev/char-fe.h"
+#include "sysemu/sysemu.h"
+#include "qemu/main-loop.h"
+#include "qapi/error.h"
+#include "qemu/fifo8.h"
+
+#define FIFO_SIZE   1024
+
+typedef struct SemihostingConsole {
+CharBackend backend;
+pthread_mutex_t mutex;
+pthread_cond_t  cond;
+boolgot;
+Fifo8   fifo;
+} SemihostingConsole;
+
+static SemihostingConsole console = {
+.mutex = PTHREAD_MUTEX_INITIALIZER,
+.cond = PTHREAD_COND_INITIALIZER
+};
+
+static int console_can_read(void *opaque)
+{
+SemihostingConsole *c = opaque;
+int ret;
+pthread_mutex_lock(>mutex);
+ret = (int) fifo8_num_free(>fifo);
+pthread_mutex_unlock(>mutex);
+return ret;
+}
+
+static void console_read(void *opaque, const uint8_t *buf, int size)
+{
+SemihostingConsole *c = opaque;
+pthread_mutex_lock(>mutex);
+while (size-- && !fifo8_is_full(>fifo)) {
+fifo8_push(>fifo, *buf++);
+}
+pthread_cond_broadcast(>cond);
+pthread_mutex_unlock(>mutex);
+}
+
+target_ulong qemu_semihosting_console_inc(CPUArchState *env)
+{
+uint8_t ch;
+SemihostingConsole *c = 
+qemu_mutex_unlock_iothread();
+pthread_mutex_lock(>mutex);
+while (fifo8_is_empty(>fifo)) {
+pthread_cond_wait(>cond, >mutex);
+}
+ch = fifo8_pop(>fifo);
+pthread_mutex_unlock(>mutex);
+qemu_mutex_lock_iothread();
+return (target_ulong) ch;
+}
+
+void qemu_semihosting_console_init(void)
+{
+Chardev *chr = semihosting_get_chardev();
+
+if  (chr) {
+fifo8_create(, FIFO_SIZE);
+qemu_chr_fe_init(, chr, _abort);
+qemu_chr_fe_set_handlers(,
+ console_can_read,
+ console_read,
+ NULL, NULL, ,
+ NULL, true);
+}
+}
diff --git a/include/hw/semihosting/console.h b/include/hw/semihosting/console.h
index 9be9754bcd..f7d5905b41 100644
--- a/include/hw/semihosting/console.h
+++ b/include/hw/semihosting/console.h
@@ -37,6 +37,18 @@ int qemu_semihosting_console_outs(CPUArchState *env, 
target_ulong s);
  */
 void qemu_semihosting_console_outc(CPUArchState *env, target_ulong c);
 
+/**
+ * qemu_semihosting_console_inc:
+ * @env: CPUArchState
+ *
+ * Receive single character from debug console. This
+ * may be the remote gdb session if a softmmu guest is currently being
+ * debugged.
+ *
+ * Returns: character read or -1 on error
+ */
+target_ulong qemu_semihosting_console_inc(CPUArchState *env);
+
 /**
  * qemu_semihosting_log_out:
  * @s: pointer to string
diff --git a/include/hw/semihosting/semihost.h 
b/include/hw/semihosting/semihost.h
index 60fc42d851..b8ce5117ae 100644
--- a/include/hw/semihosting/semihost.h
+++ b/include/hw/semihosting/semihost.h
@@ -56,6 +56,9 @@ static inline Chardev *semihosting_get_chardev(void)
 {
 return NULL;
 }
+static inline void qemu_semihosting_console_init(void)
+{
+}
 #else /* !CONFIG_USER_ONLY */
 bool semihosting_enabled(void);
 SemihostingTarget semihosting_get_target(void);
@@ -68,6 +71,7 @@ Chardev *semihosting_get_chardev(void);
 void qemu_semihosting_enable(void);
 int qemu_semihosting_config_options(const char *opt);
 void qemu_semihosting_connect_chardevs(void);
+void 

Re: [PATCH] Semihost SYS_READC implementation

2019-10-23 Thread Keith Packard
Paolo Bonzini  writes:

> Please take a look at include/qemu/fifo8.h instead of rolling your own
> ring buffer.  Note that it is not thread-safe so you'll have to keep
> that part.

Sorry for not looking around sooner, and thanks for the pointer.
I've also cleaned up the other issues.

> Kudos for the unlock/lock_iothread; I am not really familiar with the
> semihosting code and I would have naively assumed that it runs without
> that lock taken.

I discovered by testing that the semihosting functions were entered with
the lock taken :-)

I'll post an updated version of this patch to the list shortly. Thanks
again for your review; I really appreciate the time you've taken to look
at my patch.

-- 
-keith


signature.asc
Description: PGP signature


Re: [PATCH] virtio: fix IO request length in virtio SCSI/block #PSBM-78839

2019-10-23 Thread Michael S. Tsirkin
On Fri, Oct 18, 2019 at 02:55:47PM +0300, Denis Plotnikov wrote:
> From: "Denis V. Lunev" 
> 
> Linux guests submit IO requests no longer than PAGE_SIZE * max_seg
> field reported by SCSI controler. Thus typical sequential read with
> 1 MB size results in the following pattern of the IO from the guest:
>   8,16   115754 2.766095122  2071  D   R 2095104 + 1008 [dd]
>   8,16   115755 2.766108785  2071  D   R 2096112 + 1008 [dd]
>   8,16   115756 2.766113486  2071  D   R 2097120 + 32 [dd]
>   8,16   115757 2.767668961 0  C   R 2095104 + 1008 [0]
>   8,16   115758 2.768534315 0  C   R 2096112 + 1008 [0]
>   8,16   115759 2.768539782 0  C   R 2097120 + 32 [0]
> The IO was generated by
>   dd if=/dev/sda of=/dev/null bs=1024 iflag=direct
> 
> This effectively means that on rotational disks we will observe 3 IOPS
> for each 2 MBs processed. This definitely negatively affects both
> guest and host IO performance.
> 
> The cure is relatively simple - we should report lengthy scatter-gather
> ability of the SCSI controller. Fortunately the situation here is very
> good. VirtIO transport layer can accomodate 1024 items in one request
> while we are using only 128. This situation is present since almost
> very beginning. 2 items are dedicated for request metadata thus we
> should publish VIRTQUEUE_MAX_SIZE - 2 as max_seg.
> 
> The following pattern is observed after the patch:
>   8,16   1 9921 2.662721340  2063  D   R 2095104 + 1024 [dd]
>   8,16   1 9922 2.662737585  2063  D   R 2096128 + 1024 [dd]
>   8,16   1 9923 2.665188167 0  C   R 2095104 + 1024 [0]
>   8,16   1 9924 2.665198777 0  C   R 2096128 + 1024 [0]
> which is much better.
> 
> The dark side of this patch is that we are tweaking guest visible
> parameter, though this should be relatively safe as above transport
> layer support is present in QEMU/host Linux for a very long time.
> The patch adds configurable property for VirtIO SCSI with a new default
> and hardcode option for VirtBlock which does not provide good
> configurable framework.
> 
> Unfortunately the commit can not be applied as is. For the real cure we
> need guest to be fixed to accomodate that queue length, which is done
> only in the latest 4.14 kernel. Thus we are going to expose the property
> and tweak it on machine type level.
> 
> The problem with the old kernels is that they have
> max_segments <= virtqueue_size restriction which cause the guest
> crashing in the case of violation.

This isn't just in the guests: virtio spec also seems to imply this,
or at least be vague on this point.

So I think it'll need a feature bit.
Doing that in a safe way will also allow being compatible with old guests.

The only downside is it's a bit more work as we need to
spec this out and add guest support.

> To fix the case described above in the old kernels we can increase
> virtqueue_size to 256 and max_segments to 254. The pitfall here is
> that seabios allows the virtqueue_size-s < 128, however, the seabios
> patch extending that value to 256 is pending.


And the fix here is just to limit large vq size to virtio 1.0.
In that mode it's fine I think:


   /* check if the queue is available */
   if (vp->use_modern) {
   num = vp_read(>common, virtio_pci_common_cfg, queue_size);
   if (num > MAX_QUEUE_NUM) {
   vp_write(>common, virtio_pci_common_cfg, queue_size,
MAX_QUEUE_NUM);
   num = vp_read(>common, virtio_pci_common_cfg, queue_size);
   }
   } else {
   num = vp_read(>legacy, virtio_pci_legacy, queue_num);
   }





> CC: "Michael S. Tsirkin" 
> CC: Stefan Hajnoczi 
> CC: Kevin Wolf 
> CC: Max Reitz 
> CC: Gerd Hoffmann 
> Signed-off-by: Denis V. Lunev 
> Signed-off-by: Denis Plotnikov 
> ---
>  hw/block/virtio-blk.c   | 3 ++-
>  hw/scsi/vhost-scsi.c| 2 ++
>  hw/scsi/virtio-scsi.c   | 4 +++-
>  include/hw/virtio/virtio-blk.h  | 1 +
>  include/hw/virtio/virtio-scsi.h | 1 +
>  5 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 06e57a4d39..b2eaeeaf67 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -903,7 +903,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
> uint8_t *config)
>  blk_get_geometry(s->blk, );
>  memset(, 0, sizeof(blkcfg));
>  virtio_stq_p(vdev, , capacity);
> -virtio_stl_p(vdev, _max, 128 - 2);
> +virtio_stl_p(vdev, _max, s->conf.max_segments);
>  virtio_stw_p(vdev, , conf->cyls);
>  virtio_stl_p(vdev, _size, blk_size);
>  virtio_stw_p(vdev, _io_size, conf->min_io_size / blk_size);
> @@ -1240,6 +1240,7 @@ static Property virtio_blk_properties[] = {
> conf.max_discard_sectors, BDRV_REQUEST_MAX_SECTORS),
>  DEFINE_PROP_UINT32("max-write-zeroes-sectors", VirtIOBlock,
> conf.max_write_zeroes_sectors, 
> 

Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt

2019-10-23 Thread Fernando Casas Schössow
In virsh I would do this while the guest is running:

virsh attach-disk--type cdrom 
--mode readonly

Following the example for guest from my first email:

virsh attach-disk DCHOMENET01 /resources/virtio-win-0.1.171-stable.iso sdb 
--type cdrom --mode readonly

Right after executing this, qemu crashes and log the assertion.
I can repro this also from virt-manager by selecting the cdrom device -> 
Connect -> selecting the ISO file -> Choose volume -> Ok (basically the same 
but in the gui).

I may be able to try 4.1. Will look into it and report back.

On mié, oct 23, 2019 at 7:33 PM, John Snow  wrote:
On 10/23/19 1:28 PM, Fernando Casas Schössow wrote:
Hi John, Thanks for looking into this. I can quickly repro the problem with 
qemu 4.0 binary with debugging symbols enabled as I have it available already. 
Doing the same with qemu 4.1 or development head may be too much hassle but if 
it's really the only way I can give it try. Would it worth it to try with 4.0 
first and get the strack trace or it will not help and the only way to go is 
with 4.1 (or dev)? Thanks, Fernando
If 4.0 is what you have access to, having the stack trace for that is better 
than not, but confirming it happens on the latest release would be nice. Can 
you share your workflow for virsh that reproduces the failure? --js
On mié, oct 23, 2019 at 5:34 PM, John Snow 
mailto:js...@redhat.com>> wrote:
On 10/18/19 5:41 PM, Fernando Casas Schössow wrote: Hi, Hi! Thanks for the 
report. Today while working with two different Windows Server 2012 R2 guests I 
found that when I try to attach an ISO file to a SCSI CD-ROM device through 
libvirt (virsh or virt-manager) while the guest is running, qemu crashes and 
the following message is logged: Assertion failed: 
blk_get_aio_context(d->conf.blk) == s->ctx 
(/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: 
virtio_scsi_ctx_check: 246) I can repro this at will. All I have to do is to 
try to attach an ISO file to the SCSI CDROM while the guest is running. The 
SCSI controller model is virtio-scsi with iothread enabled. Please find below 
all the details about my setup that I considered relevant but I missed 
something please don't hesitate to let me know: Looks like we got aio_context 
management wrong with iothread for the media change events somewhere. Should be 
easy enough to fix if we figure out where the bad assumption is. Host arch: 
x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 Do you have the ability to 
try 4.1, or the latest development head with debugging symbols enabled? Linux 
kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI controller: virtio-scsi 
(with iothread enabled) Guest firmware: OVMF-EFI Guest OS: Window Server 2012 
R2 Guest virtio drivers version: 171 (current stable) qemu command line: 
/usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes
 -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu 
IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
 -drive 
file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on
 -drive 
file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1
 -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -object 
iothread,id=iothread1 -uuid f06978ad-2734-44ab-a518-5dfcf71d625e 
-no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet 
-no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot 
strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device 
virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive 
file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device 
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
 -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 
-chardev socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait 
-device isa-serial,chardev=charserial0,id=serial0 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -chardev socket,id=charchannel1,fd=45,server,nowait -device 

Re: [PATCH] translate-all: Remove tb_alloc

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 6:46 PM, Richard Henderson wrote:

Since 2ac01d6dafab, this function does only two things: assert a
lock is held, and call tcg_tb_alloc.  It is used exactly once,
and its user has already done the assert.

Signed-off-by: Richard Henderson 


Reviewed-by: Philippe Mathieu-Daudé 


---

I noticed that this function was essentially a stub while
reviewing Clement's tb->orig_tb fix.

Note that the added newline in tb_gen_code both adds the
missing break after the variable declaration block and
also happens to highlight the assert mentioned above.  ;-)


r~

---
  accel/tcg/translate-all.c | 20 ++--
  1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index f9b7ba159d..ae063b53f9 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -1156,23 +1156,6 @@ void tcg_exec_init(unsigned long tb_size)
  #endif
  }
  
-/*

- * Allocate a new translation block. Flush the translation buffer if
- * too many translation blocks or too much generated code.
- */
-static TranslationBlock *tb_alloc(target_ulong pc)
-{
-TranslationBlock *tb;
-
-assert_memory_lock();
-
-tb = tcg_tb_alloc(tcg_ctx);
-if (unlikely(tb == NULL)) {
-return NULL;
-}
-return tb;
-}
-
  /* call with @p->lock held */
  static inline void invalidate_page_bitmap(PageDesc *p)
  {
@@ -1681,6 +1664,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
  TCGProfile *prof = _ctx->prof;
  int64_t ti;
  #endif
+
  assert_memory_lock();
  
  phys_pc = get_page_addr_code(env, pc);

@@ -1706,7 +1690,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
  }
  
   buffer_overflow:

-tb = tb_alloc(pc);
+tb = tcg_tb_alloc(tcg_ctx);
  if (unlikely(!tb)) {
  /* flush must be done */
  tb_flush(cpu);






Re: [PATCH v5 02/11] pci: add option for net failover

2019-10-23 Thread Alex Williamson
On Wed, 23 Oct 2019 22:31:37 +0200
Jens Freimann  wrote:

> On Wed, Oct 23, 2019 at 02:02:11PM -0600, Alex Williamson wrote:
> >On Wed, 23 Oct 2019 21:30:35 +0200
> >Jens Freimann  wrote:
> >  
> >> On Wed, Oct 23, 2019 at 12:06:48PM -0600, Alex Williamson wrote:  
> >> >On Wed, 23 Oct 2019 10:27:02 +0200
> >> >Jens Freimann  wrote:  
> [...]
> >> >Are there also multi-function considerations that
> >> >should be prevented or documented?  For example, if a user tries to
> >> >configure both the primary and failover NICs in the same slot, I assume
> >> >bad things will happen.  
> >>
> >>   I would have expected that this is already checked in pci code, but
> >> it is not. I tried it and when I put both devices into the same slot
> >> they are both unplugged from the guest during boot but nothing else
> >> happens. I don't know what triggers that unplug of the devices.
> >>
> >> I'm not aware of any other problems regarding multi-function, which
> >> doesn't mean there aren't any.  
> >
> >Hmm, was the hidden device at function #0?  The guest won't find any
> >functions if function #0 isn't present, but I don't know what would
> >trigger the hotplug.  The angle I'm thinking is that we only have slot
> >level granularity for hotplug, so any sort of automatic hotplug of a
> >slot should probably think about bystander devices within the slot.  
> 
> Yes that would be a problem, but isn't it the same in the non-failover case
> where a user configures it wrong? The slot where the device is plugged is not
> chosen automatically it's configured by the user, no? I might be mixing 
> something
> up here.  I have no idea yet how to check if a slot is already populated, but
> I'll think about it. 

I don't think libvirt will automatically make use of multifunction
endpoints, except maybe for some built-in devices, so yes it probably
would be up to the user to explicitly create a multifunction device.
But are there other scenarios that generate an automatic hot-unplug?
If a user creates a multifunction slot and then triggers a hot-unplug
themselves, it's easy to place the blame on the user if the result is
unexpected, but is it so obviously a user configuration error if the
hotplug occurs as an automatic response to a migration?  I'm not as
sure about that.

As indicated, I don't know whether this should just be documented or if
we should spend time preventing it, but someone, somewhere will
probably think it's a good idea to put their primary and failover NIC
in the same slot and be confused that the underlying mechanisms cannot
support it.  It doesn't appear that it would be too difficult to test
QEMU_PCI_CAP_MULTIFUNCTION (not set) and PCI_FUNC (is 0) for the
primary, but maybe I'm just being paranoid.  Thanks,

Alex




[PATCH v3 32/33] qdev: remove PROP_MEMORY_REGION

2019-10-23 Thread Marc-André Lureau
PROP_MEMORY_REGION was a derivative of PROP_PTR, added in commit
ed03d749f3f513b8fb0287757cfda2cb6825f063 (qdev: add MemoryRegion
property) and thankfully no longer needed since commit
3eff40dbf44896a8180c86c84dbdefb2eb173fbe (hw/misc: Remove
mmio_interface device).

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
 include/hw/qdev-properties.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 690ff07ae2..5bba033b7b 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -213,8 +213,6 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
 DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint16_t)
 #define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
 DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
-#define DEFINE_PROP_MEMORY_REGION(_n, _s, _f) \
-DEFINE_PROP(_n, _s, _f, qdev_prop_ptr, MemoryRegion *)
 #define DEFINE_PROP_OFF_AUTO_PCIBAR(_n, _s, _f, _d) \
 DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_off_auto_pcibar, \
 OffAutoPCIBAR)
-- 
2.23.0.606.g08da6496b6




[PATCH v3 31/33] omap-gpio: remove PROP_PTR

2019-10-23 Thread Marc-André Lureau
Since clocks are not QOM objects, replace PROP_PTR of clocks with
setters methods.

Move/adapt the existing TODO comment about a clock framework.

Reviewed-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/arm/omap1.c|  2 +-
 hw/arm/omap2.c| 13 +++--
 hw/gpio/omap_gpio.c   | 42 +++---
 include/hw/arm/omap.h | 33 +
 4 files changed, 52 insertions(+), 38 deletions(-)

diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index 807e5f70d1..761cc17ea9 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -4012,7 +4012,7 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*dram,
 
 s->gpio = qdev_create(NULL, "omap-gpio");
 qdev_prop_set_int32(s->gpio, "mpu_model", s->mpu_model);
-qdev_prop_set_ptr(s->gpio, "clk", omap_findclk(s, "arm_gpio_ck"));
+omap_gpio_set_clk(OMAP1_GPIO(s->gpio), omap_findclk(s, "arm_gpio_ck"));
 qdev_init_nofail(s->gpio);
 sysbus_connect_irq(SYS_BUS_DEVICE(s->gpio), 0,
qdev_get_gpio_in(s->ih[0], OMAP_INT_GPIO_BANK1));
diff --git a/hw/arm/omap2.c b/hw/arm/omap2.c
index 171e2d0472..e1c11de5ce 100644
--- a/hw/arm/omap2.c
+++ b/hw/arm/omap2.c
@@ -2449,13 +2449,14 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion 
*sdram,
 
 s->gpio = qdev_create(NULL, "omap2-gpio");
 qdev_prop_set_int32(s->gpio, "mpu_model", s->mpu_model);
-qdev_prop_set_ptr(s->gpio, "iclk", omap_findclk(s, "gpio_iclk"));
-qdev_prop_set_ptr(s->gpio, "fclk0", omap_findclk(s, "gpio1_dbclk"));
-qdev_prop_set_ptr(s->gpio, "fclk1", omap_findclk(s, "gpio2_dbclk"));
-qdev_prop_set_ptr(s->gpio, "fclk2", omap_findclk(s, "gpio3_dbclk"));
-qdev_prop_set_ptr(s->gpio, "fclk3", omap_findclk(s, "gpio4_dbclk"));
+omap2_gpio_set_iclk(OMAP2_GPIO(s->gpio), omap_findclk(s, "gpio_iclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 0, omap_findclk(s, 
"gpio1_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 1, omap_findclk(s, 
"gpio2_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 2, omap_findclk(s, 
"gpio3_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 3, omap_findclk(s, 
"gpio4_dbclk"));
 if (s->mpu_model == omap2430) {
-qdev_prop_set_ptr(s->gpio, "fclk4", omap_findclk(s, "gpio5_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 4,
+omap_findclk(s, "gpio5_dbclk"));
 }
 qdev_init_nofail(s->gpio);
 busdev = SYS_BUS_DEVICE(s->gpio);
diff --git a/hw/gpio/omap_gpio.c b/hw/gpio/omap_gpio.c
index 41e1aa798c..85c16897ae 100644
--- a/hw/gpio/omap_gpio.c
+++ b/hw/gpio/omap_gpio.c
@@ -40,10 +40,6 @@ struct omap_gpio_s {
 uint16_t pins;
 };
 
-#define TYPE_OMAP1_GPIO "omap-gpio"
-#define OMAP1_GPIO(obj) \
-OBJECT_CHECK(struct omap_gpif_s, (obj), TYPE_OMAP1_GPIO)
-
 struct omap_gpif_s {
 SysBusDevice parent_obj;
 
@@ -212,10 +208,6 @@ struct omap2_gpio_s {
 uint8_t delay;
 };
 
-#define TYPE_OMAP2_GPIO "omap2-gpio"
-#define OMAP2_GPIO(obj) \
-OBJECT_CHECK(struct omap2_gpif_s, (obj), TYPE_OMAP2_GPIO)
-
 struct omap2_gpif_s {
 SysBusDevice parent_obj;
 
@@ -747,21 +739,13 @@ static void omap2_gpio_realize(DeviceState *dev, Error 
**errp)
 }
 }
 
-/* Using qdev pointer properties for the clocks is not ideal.
- * qdev should support a generic means of defining a 'port' with
- * an arbitrary interface for connecting two devices. Then we
- * could reframe the omap clock API in terms of clock ports,
- * and get some type safety. For now the best qdev provides is
- * passing an arbitrary pointer.
- * (It's not possible to pass in the string which is the clock
- * name, because this device does not have the necessary information
- * (ie the struct omap_mpu_state_s*) to do the clockname to pointer
- * translation.)
- */
+void omap_gpio_set_clk(omap_gpif *gpio, omap_clk clk)
+{
+gpio->clk = clk;
+}
 
 static Property omap_gpio_properties[] = {
 DEFINE_PROP_INT32("mpu_model", struct omap_gpif_s, mpu_model, 0),
-DEFINE_PROP_PTR("clk", struct omap_gpif_s, clk),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -784,15 +768,19 @@ static const TypeInfo omap_gpio_info = {
 .class_init= omap_gpio_class_init,
 };
 
+void omap2_gpio_set_iclk(omap2_gpif *gpio, omap_clk clk)
+{
+gpio->iclk = clk;
+}
+
+void omap2_gpio_set_fclk(omap2_gpif *gpio, uint8_t i, omap_clk clk)
+{
+assert(i <= 5);
+gpio->fclk[i] = clk;
+}
+
 static Property omap2_gpio_properties[] = {
 DEFINE_PROP_INT32("mpu_model", struct omap2_gpif_s, mpu_model, 0),
-DEFINE_PROP_PTR("iclk", struct omap2_gpif_s, iclk),
-DEFINE_PROP_PTR("fclk0", struct omap2_gpif_s, fclk[0]),
-DEFINE_PROP_PTR("fclk1", struct omap2_gpif_s, fclk[1]),
-DEFINE_PROP_PTR("fclk2", struct omap2_gpif_s, fclk[2]),
-DEFINE_PROP_PTR("fclk3", struct omap2_gpif_s, fclk[3]),
-DEFINE_PROP_PTR("fclk4", struct omap2_gpif_s, fclk[4]),
-DEFINE_PROP_PTR("fclk5", struct omap2_gpif_s, fclk[5]),
 

[PATCH v3 26/33] RFC: mips/cps: fix setting saar property

2019-10-23 Thread Marc-André Lureau
There is no "saar" property. Note: I haven't been able to test this
code. Help welcome.

May fix commit 043715d1e0fbb3e3411be3f898c5b77b7f90327a ("target/mips:
Update ITU to utilize SAARI and SAAR CP0 registers")

Cc: Aleksandar Markovic 
Signed-off-by: Marc-André Lureau 
---
 hw/mips/cps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/mips/cps.c b/hw/mips/cps.c
index 1660f86908..c49868d5da 100644
--- a/hw/mips/cps.c
+++ b/hw/mips/cps.c
@@ -106,7 +106,7 @@ static void mips_cps_realize(DeviceState *dev, Error **errp)
 object_property_set_bool(OBJECT(>itu), saar_present, "saar-present",
  );
 if (saar_present) {
-qdev_prop_set_ptr(DEVICE(>itu), "saar", (void *)>CP0_SAAR);
+s->itu.saar = >CP0_SAAR;
 }
 object_property_set_bool(OBJECT(>itu), true, "realized", );
 if (err != NULL) {
-- 
2.23.0.606.g08da6496b6




[PATCH v3 25/33] sparc: move PIL irq handling to cpu.c

2019-10-23 Thread Marc-André Lureau
Rather than tweaking CPU bits from leon3 machine, move it to cpu.c.

Suggested-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/sparc/leon3.c  | 37 -
 hw/sparc/trace-events |  4 
 target/sparc/cpu.c| 39 +++
 target/sparc/trace-events |  4 
 4 files changed, 43 insertions(+), 41 deletions(-)

diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c
index 6db6ea9b5c..fec460f524 100644
--- a/hw/sparc/leon3.c
+++ b/hw/sparc/leon3.c
@@ -38,7 +38,6 @@
 #include "hw/boards.h"
 #include "hw/loader.h"
 #include "elf.h"
-#include "trace.h"
 #include "exec/address-spaces.h"
 
 #include "hw/sparc/grlib.h"
@@ -143,41 +142,6 @@ void leon3_irq_ack(void *irq_manager, int intno)
 grlib_irqmp_ack((DeviceState *)irq_manager, intno);
 }
 
-static void leon3_set_pil_in(void *opaque, int n, int level)
-{
-CPUSPARCState *env = opaque;
-uint32_t pil_in = level;
-CPUState *cs;
-
-assert(env != NULL);
-
-env->pil_in = pil_in;
-
-if (env->pil_in && (env->interrupt_index == 0 ||
-(env->interrupt_index & ~15) == TT_EXTINT)) {
-unsigned int i;
-
-for (i = 15; i > 0; i--) {
-if (env->pil_in & (1 << i)) {
-int old_interrupt = env->interrupt_index;
-
-env->interrupt_index = TT_EXTINT | i;
-if (old_interrupt != env->interrupt_index) {
-cs = env_cpu(env);
-trace_leon3_set_irq(i);
-cpu_interrupt(cs, CPU_INTERRUPT_HARD);
-}
-break;
-}
-}
-} else if (!env->pil_in && (env->interrupt_index & ~15) == TT_EXTINT) {
-cs = env_cpu(env);
-trace_leon3_reset_irq(env->interrupt_index & 15);
-env->interrupt_index = 0;
-cpu_reset_interrupt(cs, CPU_INTERRUPT_HARD);
-}
-}
-
 static void leon3_generic_hw_init(MachineState *machine)
 {
 ram_addr_t ram_size = machine->ram_size;
@@ -226,7 +190,6 @@ static void leon3_generic_hw_init(MachineState *machine)
 
 /* Allocate IRQ manager */
 dev = qdev_create(NULL, TYPE_GRLIB_IRQMP);
-env->pil_irq = qemu_allocate_irq(leon3_set_pil_in, env, 0);
 qdev_connect_gpio_out_named(dev, "grlib-irq", 0, env->pil_irq);
 qdev_init_nofail(dev);
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, LEON3_IRQMP_OFFSET);
diff --git a/hw/sparc/trace-events b/hw/sparc/trace-events
index 355b07ae05..0299df24d4 100644
--- a/hw/sparc/trace-events
+++ b/hw/sparc/trace-events
@@ -15,7 +15,3 @@ sun4m_iommu_mem_writel_pgflush(uint32_t val) "page flush 0x%x"
 sun4m_iommu_page_get_flags(uint64_t pa, uint64_t iopte, uint32_t ret) "get 
flags addr 0x%"PRIx64" => pte 0x%"PRIx64", *pte = 0x%x"
 sun4m_iommu_translate_pa(uint64_t addr, uint64_t pa, uint32_t iopte) "xlate 
dva 0x%"PRIx64" => pa 0x%"PRIx64" iopte = 0x%x"
 sun4m_iommu_bad_addr(uint64_t addr) "bad addr 0x%"PRIx64
-
-# leon3.c
-leon3_set_irq(int intno) "Set CPU IRQ %d"
-leon3_reset_irq(int intno) "Reset CPU IRQ %d"
diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c
index bc65929552..693ffef3d1 100644
--- a/target/sparc/cpu.c
+++ b/target/sparc/cpu.c
@@ -25,6 +25,8 @@
 #include "exec/exec-all.h"
 #include "hw/qdev-properties.h"
 #include "qapi/visitor.h"
+#include "trace.h"
+#include "hw/irq.h"
 
 //#define DEBUG_FEATURES
 
@@ -540,6 +542,41 @@ static const sparc_def_t sparc_defs[] = {
 #endif
 };
 
+static void sparc_set_pil_in(void *opaque, int n, int level)
+{
+CPUSPARCState *env = opaque;
+uint32_t pil_in = level;
+CPUState *cs;
+
+assert(env != NULL);
+
+env->pil_in = pil_in;
+
+if (env->pil_in && (env->interrupt_index == 0 ||
+(env->interrupt_index & ~15) == TT_EXTINT)) {
+unsigned int i;
+
+for (i = 15; i > 0; i--) {
+if (env->pil_in & (1 << i)) {
+int old_interrupt = env->interrupt_index;
+
+env->interrupt_index = TT_EXTINT | i;
+if (old_interrupt != env->interrupt_index) {
+cs = env_cpu(env);
+trace_sparc_set_irq(i);
+cpu_interrupt(cs, CPU_INTERRUPT_HARD);
+}
+break;
+}
+}
+} else if (!env->pil_in && (env->interrupt_index & ~15) == TT_EXTINT) {
+cs = env_cpu(env);
+trace_sparc_reset_irq(env->interrupt_index & 15);
+env->interrupt_index = 0;
+cpu_reset_interrupt(cs, CPU_INTERRUPT_HARD);
+}
+}
+
 static const char * const feature_name[] = {
 "float",
 "float128",
@@ -762,6 +799,8 @@ static void sparc_cpu_realizefn(DeviceState *dev, Error 
**errp)
 env->version |= env->def.nwindows - 1;
 #endif
 
+env->pil_irq = qemu_allocate_irq(sparc_set_pil_in, env, 0);
+
 cpu_exec_realizefn(cs, _err);
 if (local_err != NULL) {
 error_propagate(errp, local_err);
diff --git a/target/sparc/trace-events 

[PATCH v3 24/33] leon3: use qemu_irq framework instead of callback as property

2019-10-23 Thread Marc-André Lureau
"set_pin_in" property is used to define a callback mechanism where the
device says "call the callback function, passing it an opaque cookie
and a 32-bit value". We already have a generic mechanism for doing
that, which is the qemu_irq. So we should just use that.

Signed-off-by: Marc-André Lureau 
---
 hw/intc/grlib_irqmp.c | 35 ---
 hw/sparc/leon3.c  |  9 +
 target/sparc/cpu.h|  1 +
 3 files changed, 10 insertions(+), 35 deletions(-)

diff --git a/hw/intc/grlib_irqmp.c b/hw/intc/grlib_irqmp.c
index bc78e1a14f..794c643af2 100644
--- a/hw/intc/grlib_irqmp.c
+++ b/hw/intc/grlib_irqmp.c
@@ -25,6 +25,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "hw/irq.h"
 #include "hw/sysbus.h"
 #include "cpu.h"
 
@@ -58,10 +59,8 @@ typedef struct IRQMP {
 
 MemoryRegion iomem;
 
-void *set_pil_in;
-void *set_pil_in_opaque;
-
 IRQMPState *state;
+qemu_irq irq;
 } IRQMP;
 
 struct IRQMPState {
@@ -82,7 +81,6 @@ static void grlib_irqmp_check_irqs(IRQMPState *state)
 uint32_t  pend   = 0;
 uint32_t  level0 = 0;
 uint32_t  level1 = 0;
-set_pil_in_fn set_pil_in;
 
 assert(state != NULL);
 assert(state->parent != NULL);
@@ -97,14 +95,8 @@ static void grlib_irqmp_check_irqs(IRQMPState *state)
 trace_grlib_irqmp_check_irqs(state->pending, state->force[0],
  state->mask[0], level1, level0);
 
-set_pil_in = (set_pil_in_fn)state->parent->set_pil_in;
-
 /* Trigger level1 interrupt first and level0 if there is no level1 */
-if (level1 != 0) {
-set_pil_in(state->parent->set_pil_in_opaque, level1);
-} else {
-set_pil_in(state->parent->set_pil_in_opaque, level0);
-}
+qemu_set_irq(state->parent->irq, level1 ?: level0);
 }
 
 static void grlib_irqmp_ack_mask(IRQMPState *state, uint32_t mask)
@@ -335,6 +327,7 @@ static void grlib_irqmp_init(Object *obj)
 IRQMP *irqmp = GRLIB_IRQMP(obj);
 SysBusDevice *dev = SYS_BUS_DEVICE(obj);
 
+qdev_init_gpio_out_named(DEVICE(obj), >irq, "grlib-irq", 1);
 memory_region_init_io(>iomem, obj, _irqmp_ops, irqmp,
   "irqmp", IRQMP_REG_SIZE);
 
@@ -343,31 +336,11 @@ static void grlib_irqmp_init(Object *obj)
 sysbus_init_mmio(dev, >iomem);
 }
 
-static void grlib_irqmp_realize(DeviceState *dev, Error **errp)
-{
-IRQMP *irqmp = GRLIB_IRQMP(dev);
-
-/* Check parameters */
-if (irqmp->set_pil_in == NULL) {
-error_setg(errp, "set_pil_in cannot be NULL.");
-}
-}
-
-static Property grlib_irqmp_properties[] = {
-DEFINE_PROP_PTR("set_pil_in", IRQMP, set_pil_in),
-DEFINE_PROP_PTR("set_pil_in_opaque", IRQMP, set_pil_in_opaque),
-DEFINE_PROP_END_OF_LIST(),
-};
-
 static void grlib_irqmp_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 dc->reset = grlib_irqmp_reset;
-dc->props = grlib_irqmp_properties;
-/* Reason: pointer properties "set_pil_in", "set_pil_in_opaque" */
-dc->user_creatable = false;
-dc->realize = grlib_irqmp_realize;
 }
 
 static const TypeInfo grlib_irqmp_info = {
diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c
index c5f1b1ee72..6db6ea9b5c 100644
--- a/hw/sparc/leon3.c
+++ b/hw/sparc/leon3.c
@@ -143,9 +143,10 @@ void leon3_irq_ack(void *irq_manager, int intno)
 grlib_irqmp_ack((DeviceState *)irq_manager, intno);
 }
 
-static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
+static void leon3_set_pil_in(void *opaque, int n, int level)
 {
-CPUSPARCState *env = (CPUSPARCState *)opaque;
+CPUSPARCState *env = opaque;
+uint32_t pil_in = level;
 CPUState *cs;
 
 assert(env != NULL);
@@ -225,8 +226,8 @@ static void leon3_generic_hw_init(MachineState *machine)
 
 /* Allocate IRQ manager */
 dev = qdev_create(NULL, TYPE_GRLIB_IRQMP);
-qdev_prop_set_ptr(dev, "set_pil_in", leon3_set_pil_in);
-qdev_prop_set_ptr(dev, "set_pil_in_opaque", env);
+env->pil_irq = qemu_allocate_irq(leon3_set_pil_in, env, 0);
+qdev_connect_gpio_out_named(dev, "grlib-irq", 0, env->pil_irq);
 qdev_init_nofail(dev);
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, LEON3_IRQMP_OFFSET);
 env->irq_manager = dev;
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index 778aa8e073..709215f8c1 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -508,6 +508,7 @@ struct CPUSPARCState {
 #endif
 sparc_def_t def;
 
+qemu_irq pil_irq;
 void *irq_manager;
 void (*qemu_irq_ack)(CPUSPARCState *env, void *irq_manager, int intno);
 
-- 
2.23.0.606.g08da6496b6




[PATCH v3 23/33] dp8393x: replace PROP_PTR with PROP_LINK

2019-10-23 Thread Marc-André Lureau
Link property is the correct way to pass a MemoryRegion to a device
for DMA purposes.

Sidenote: as a sysbus device, this remains non-usercreatable
even though we can drop the specific flag here.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
 hw/mips/mips_jazz.c | 3 ++-
 hw/net/dp8393x.c| 7 +++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/mips/mips_jazz.c b/hw/mips/mips_jazz.c
index 8d010a0b6e..878925a963 100644
--- a/hw/mips/mips_jazz.c
+++ b/hw/mips/mips_jazz.c
@@ -284,7 +284,8 @@ static void mips_jazz_init(MachineState *machine,
 dev = qdev_create(NULL, "dp8393x");
 qdev_set_nic_properties(dev, nd);
 qdev_prop_set_uint8(dev, "it_shift", 2);
-qdev_prop_set_ptr(dev, "dma_mr", rc4030_dma_mr);
+object_property_set_link(OBJECT(dev), OBJECT(rc4030_dma_mr),
+ "dma_mr", _abort);
 qdev_init_nofail(dev);
 sysbus = SYS_BUS_DEVICE(dev);
 sysbus_mmio_map(sysbus, 0, 0x80001000);
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index a5678e11fa..946c7a8f64 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -173,7 +173,7 @@ typedef struct dp8393xState {
 int loopback_packet;
 
 /* Memory access */
-void *dma_mr;
+MemoryRegion *dma_mr;
 AddressSpace as;
 } dp8393xState;
 
@@ -922,7 +922,8 @@ static const VMStateDescription vmstate_dp8393x = {
 
 static Property dp8393x_properties[] = {
 DEFINE_NIC_PROPERTIES(dp8393xState, conf),
-DEFINE_PROP_PTR("dma_mr", dp8393xState, dma_mr),
+DEFINE_PROP_LINK("dma_mr", dp8393xState, dma_mr,
+ TYPE_MEMORY_REGION, MemoryRegion *),
 DEFINE_PROP_UINT8("it_shift", dp8393xState, it_shift, 0),
 DEFINE_PROP_END_OF_LIST(),
 };
@@ -936,8 +937,6 @@ static void dp8393x_class_init(ObjectClass *klass, void 
*data)
 dc->reset = dp8393x_reset;
 dc->vmsd = _dp8393x;
 dc->props = dp8393x_properties;
-/* Reason: dma_mr property can't be set */
-dc->user_creatable = false;
 }
 
 static const TypeInfo dp8393x_info = {
-- 
2.23.0.606.g08da6496b6




[PATCH v3 16/33] serial-mm: use sysbus facilities

2019-10-23 Thread Marc-André Lureau
Make SerialMM a regular sysbus device, by registering the irq, and the
mmio region. Reexport the internal serial properties.

Signed-off-by: Marc-André Lureau 
---
 hw/char/serial.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index 2f7667c30c..a40bc3ab81 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -1074,21 +1074,18 @@ SerialMM *serial_mm_init(MemoryRegion *address_space,
 Chardev *chr, enum device_endian end)
 {
 SerialMM *self = SERIAL_MM(qdev_create(NULL, TYPE_SERIAL_MM));
-SerialState *s = >serial;
+MemoryRegion *mr;
 
 qdev_prop_set_uint8(DEVICE(self), "regshift", regshift);
-s->irq = irq;
-qdev_prop_set_uint32(DEVICE(s), "baudbase", baudbase);
-qdev_prop_set_chr(DEVICE(s), "chardev", chr);
-qdev_prop_set_int32(DEVICE(s), "instance-id", base);
-qdev_prop_set_uint8(DEVICE(s), "endianness", end);
-
-qdev_init_nofail(DEVICE(s));
+qdev_prop_set_uint32(DEVICE(self), "baudbase", baudbase);
+qdev_prop_set_chr(DEVICE(self), "chardev", chr);
+qdev_prop_set_int32(DEVICE(self), "instance-id", base);
+qdev_prop_set_uint8(DEVICE(self), "endianness", end);
 qdev_init_nofail(DEVICE(self));
 
-memory_region_init_io(>io, NULL, _mm_ops[end], self,
-  "serial", 8 << regshift);
-memory_region_add_subregion(address_space, base, >io);
+sysbus_connect_irq(SYS_BUS_DEVICE(self), 0, irq);
+mr = sysbus_mmio_get_region(SYS_BUS_DEVICE(self), 0);
+memory_region_add_subregion(address_space, base, mr);
 
 return self;
 }
@@ -1099,6 +1096,8 @@ static void serial_mm_instance_init(Object *o)
 
 object_initialize_child(o, "serial", >serial, sizeof(self->serial),
 TYPE_SERIAL, _abort, NULL);
+
+qdev_alias_all_properties(DEVICE(>serial), o);
 }
 
 static Property serial_mm_properties[] = {
@@ -1107,11 +1106,25 @@ static Property serial_mm_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static void serial_mm_realize(DeviceState *dev, Error **errp)
+{
+SerialMM *self = SERIAL_MM(dev);
+SerialState *s = >serial;
+
+qdev_init_nofail(DEVICE(s));
+
+memory_region_init_io(>io, NULL, _mm_ops[self->endianness], self,
+  "serial", 8 << self->regshift);
+sysbus_init_mmio(SYS_BUS_DEVICE(self), >io);
+sysbus_init_irq(SYS_BUS_DEVICE(self), >serial.irq);
+}
+
 static void serial_mm_class_init(ObjectClass *klass, void* data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 dc->props = serial_mm_properties;
+dc->realize = serial_mm_realize;
 }
 
 static const TypeInfo serial_mm_info = {
-- 
2.23.0.606.g08da6496b6




Re: [PATCH v5 02/11] pci: add option for net failover

2019-10-23 Thread Jens Freimann

On Wed, Oct 23, 2019 at 02:02:11PM -0600, Alex Williamson wrote:

On Wed, 23 Oct 2019 21:30:35 +0200
Jens Freimann  wrote:


On Wed, Oct 23, 2019 at 12:06:48PM -0600, Alex Williamson wrote:
>On Wed, 23 Oct 2019 10:27:02 +0200
>Jens Freimann  wrote:

[...]

>Are there also multi-function considerations that
>should be prevented or documented?  For example, if a user tries to
>configure both the primary and failover NICs in the same slot, I assume
>bad things will happen.

  I would have expected that this is already checked in pci code, but
it is not. I tried it and when I put both devices into the same slot
they are both unplugged from the guest during boot but nothing else
happens. I don't know what triggers that unplug of the devices.

I'm not aware of any other problems regarding multi-function, which
doesn't mean there aren't any.


Hmm, was the hidden device at function #0?  The guest won't find any
functions if function #0 isn't present, but I don't know what would
trigger the hotplug.  The angle I'm thinking is that we only have slot
level granularity for hotplug, so any sort of automatic hotplug of a
slot should probably think about bystander devices within the slot.


Yes that would be a problem, but isn't it the same in the non-failover case
where a user configures it wrong? The slot where the device is plugged is not
chosen automatically it's configured by the user, no? I might be mixing 
something
up here.  I have no idea yet how to check if a slot is already populated, but
I'll think about it. 


Thanks!

regards,
Jens 





[PATCH v3 10/33] serial: add "instance-id" property

2019-10-23 Thread Marc-André Lureau
This property will be used to move common vmstate registration to
device realize in following patch.

Signed-off-by: Marc-André Lureau 
---
 hw/char/serial.c | 3 +++
 include/hw/char/serial.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index 069d8715d0..0b61a71e4e 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -990,6 +990,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
 s->irq = irq;
 qdev_prop_set_uint32(dev, "baudbase", baudbase);
 qdev_prop_set_chr(dev, "chardev", chr);
+qdev_prop_set_int32(dev, "instance-id", base);
 serial_realize_core(s, _fatal);
 qdev_set_legacy_instance_id(dev, base, 2);
 qdev_init_nofail(dev);
@@ -1003,6 +1004,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
 static Property serial_properties[] = {
 DEFINE_PROP_CHR("chardev", SerialState, chr),
 DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
+DEFINE_PROP_INT32("instance-id", SerialState, instance_id, 0),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -1073,6 +1075,7 @@ SerialState *serial_mm_init(MemoryRegion *address_space,
 s->irq = irq;
 qdev_prop_set_uint32(dev, "baudbase", baudbase);
 qdev_prop_set_chr(dev, "chardev", chr);
+qdev_prop_set_int32(dev, "instance-id", base);
 
 serial_realize_core(s, _fatal);
 qdev_set_legacy_instance_id(dev, base, 2);
diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
index 3dc618598e..b472c7cd57 100644
--- a/include/hw/char/serial.h
+++ b/include/hw/char/serial.h
@@ -78,6 +78,7 @@ typedef struct SerialState {
 
 QEMUTimer *modem_status_poll;
 MemoryRegion io;
+int instance_id;
 } SerialState;
 
 extern const VMStateDescription vmstate_serial;
-- 
2.23.0.606.g08da6496b6




[PATCH v3 05/33] serial-pci-multi: factor out multi_serial_get_nr_ports

2019-10-23 Thread Marc-André Lureau
Reused in following patch.

Signed-off-by: Marc-André Lureau 
---
 hw/char/serial-pci-multi.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/hw/char/serial-pci-multi.c b/hw/char/serial-pci-multi.c
index 5f13b5663b..6fa1cc6225 100644
--- a/hw/char/serial-pci-multi.c
+++ b/hw/char/serial-pci-multi.c
@@ -77,24 +77,26 @@ static void multi_serial_irq_mux(void *opaque, int n, int 
level)
 pci_set_irq(>dev, pending);
 }
 
+static int multi_serial_get_nr_ports(PCIDeviceClass *pc)
+{
+switch (pc->device_id) {
+case 0x0003:
+return 2;
+case 0x0004:
+return 4;
+}
+
+g_assert_not_reached();
+}
+
+
 static void multi_serial_pci_realize(PCIDevice *dev, Error **errp)
 {
 PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
 PCIMultiSerialState *pci = DO_UPCAST(PCIMultiSerialState, dev, dev);
 SerialState *s;
 Error *err = NULL;
-int i, nr_ports = 0;
-
-switch (pc->device_id) {
-case 0x0003:
-nr_ports = 2;
-break;
-case 0x0004:
-nr_ports = 4;
-break;
-}
-assert(nr_ports > 0);
-assert(nr_ports <= PCI_SERIAL_MAX_PORTS);
+int i, nr_ports = multi_serial_get_nr_ports(pc);
 
 pci->dev.config[PCI_CLASS_PROG] = pci->prog_if;
 pci->dev.config[PCI_INTERRUPT_PIN] = 0x01;
-- 
2.23.0.606.g08da6496b6




Re: [PATCH 0/1] pci: pass along the return value of dma_memory_rw

2019-10-23 Thread Klaus Birkelund
On Fri, Oct 11, 2019 at 09:01:40AM +0200, Klaus Jensen wrote:
> Hi,
> 
> While working on fixing the emulated nvme device to pass more tests in
> the blktests suite, I discovered that the pci_dma_rw function ignores
> the return value of dma_memory_rw.
> 
> The nvme device needs to handle DMA errors gracefully in order to pass
> the block/011 test ("disable PCI device while doing I/O") in the
> blktests suite. This is only possible if the device knows if the DMA
> transfer was successful or not.
> 
> I can't see what the reason for ignoring the return value would be. But
> if there is a good reason, please enlighten me :)
> 
> 
> Klaus Jensen (1):
>   pci: pass along the return value of dma_memory_rw
> 
>  include/hw/pci/pci.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> -- 
> 2.23.0
> 

Gentle ping.

https://patchwork.kernel.org/patch/11184911/



[PATCH v3 04/33] chardev: generate an internal id when none given

2019-10-23 Thread Marc-André Lureau
Internally, qemu may create chardev without ID. Those will not be
looked up with qemu_chr_find(), which prevents using qdev_prop_set_chr().

Use id_generate(), to generate an internal name (prefixed with #), so
no conflict exist with user-named chardev.

Signed-off-by: Marc-André Lureau 
---
 chardev/char.c| 32 
 include/qemu/id.h |  1 +
 util/id.c |  1 +
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/chardev/char.c b/chardev/char.c
index 7b6b2cb123..e7e7492b0e 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -37,6 +37,7 @@
 #include "qemu/help_option.h"
 #include "qemu/module.h"
 #include "qemu/option.h"
+#include "qemu/id.h"
 
 #include "chardev/char-mux.h"
 
@@ -944,10 +945,10 @@ void qemu_chr_set_feature(Chardev *chr,
 return set_bit(feature, chr->features);
 }
 
-Chardev *qemu_chardev_new(const char *id, const char *typename,
-  ChardevBackend *backend,
-  GMainContext *gcontext,
-  Error **errp)
+static Chardev *chardev_new(const char *id, const char *typename,
+ChardevBackend *backend,
+GMainContext *gcontext,
+Error **errp)
 {
 Object *obj;
 Chardev *chr = NULL;
@@ -991,6 +992,21 @@ end:
 return chr;
 }
 
+Chardev *qemu_chardev_new(const char *id, const char *typename,
+  ChardevBackend *backend,
+  GMainContext *gcontext,
+  Error **errp)
+{
+g_autofree char *genid = NULL;
+
+if (!id) {
+genid = id_generate(ID_CHR);
+id = genid;
+}
+
+return chardev_new(id, typename, backend, gcontext, errp);
+}
+
 ChardevReturn *qmp_chardev_add(const char *id, ChardevBackend *backend,
Error **errp)
 {
@@ -1003,8 +1019,8 @@ ChardevReturn *qmp_chardev_add(const char *id, 
ChardevBackend *backend,
 return NULL;
 }
 
-chr = qemu_chardev_new(id, object_class_get_name(OBJECT_CLASS(cc)),
-   backend, NULL, errp);
+chr = chardev_new(id, object_class_get_name(OBJECT_CLASS(cc)),
+  backend, NULL, errp);
 if (!chr) {
 return NULL;
 }
@@ -1061,8 +1077,8 @@ ChardevReturn *qmp_chardev_change(const char *id, 
ChardevBackend *backend,
 return NULL;
 }
 
-chr_new = qemu_chardev_new(NULL, object_class_get_name(OBJECT_CLASS(cc)),
-   backend, chr->gcontext, errp);
+chr_new = chardev_new(NULL, object_class_get_name(OBJECT_CLASS(cc)),
+  backend, chr->gcontext, errp);
 if (!chr_new) {
 return NULL;
 }
diff --git a/include/qemu/id.h b/include/qemu/id.h
index 40c70103e4..b55c406e69 100644
--- a/include/qemu/id.h
+++ b/include/qemu/id.h
@@ -4,6 +4,7 @@
 typedef enum IdSubSystems {
 ID_QDEV,
 ID_BLOCK,
+ID_CHR,
 ID_MAX  /* last element, used as array size */
 } IdSubSystems;
 
diff --git a/util/id.c b/util/id.c
index af1c5f1b81..5addb4460e 100644
--- a/util/id.c
+++ b/util/id.c
@@ -34,6 +34,7 @@ bool id_wellformed(const char *id)
 static const char *const id_subsys_str[ID_MAX] = {
 [ID_QDEV]  = "qdev",
 [ID_BLOCK] = "block",
+[ID_CHR] = "chr",
 };
 
 /*
-- 
2.23.0.606.g08da6496b6




Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt

2019-10-23 Thread Fernando Casas Schössow
Hi John,

Thanks for looking into this.
I can quickly repro the problem with qemu 4.0 binary with debugging symbols 
enabled as I have it available already.
Doing the same with qemu 4.1 or development head may be too much hassle but if 
it's really the only way I can give it try.

Would it worth it to try with 4.0 first and get the strack trace or it will not 
help and the only way to go is with 4.1 (or dev)?

Thanks,

Fernando

On mié, oct 23, 2019 at 5:34 PM, John Snow  wrote:
On 10/18/19 5:41 PM, Fernando Casas Schössow wrote:
Hi,
Hi! Thanks for the report.
Today while working with two different Windows Server 2012 R2 guests I found 
that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt 
(virsh or virt-manager) while the guest is running, qemu crashes and the 
following message is logged: Assertion failed: blk_get_aio_context(d->conf.blk) 
== s->ctx 
(/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: 
virtio_scsi_ctx_check: 246) I can repro this at will. All I have to do is to 
try to attach an ISO file to the SCSI CDROM while the guest is running. The 
SCSI controller model is virtio-scsi with iothread enabled. Please find below 
all the details about my setup that I considered relevant but I missed 
something please don't hesitate to let me know:
Looks like we got aio_context management wrong with iothread for the media 
change events somewhere. Should be easy enough to fix if we figure out where 
the bad assumption is.
Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0
Do you have the ability to try 4.1, or the latest development head with 
debugging symbols enabled?
Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI controller: 
virtio-scsi (with iothread enabled) Guest firmware: OVMF-EFI Guest OS: Window 
Server 2012 R2 Guest virtio drivers version: 171 (current stable) qemu command 
line: /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S 
-object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes
 -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu 
IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
 -drive 
file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on
 -drive 
file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1
 -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -object 
iothread,id=iothread1 -uuid f06978ad-2734-44ab-a518-5dfcf71d625e 
-no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet 
-no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot 
strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device 
virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive 
file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device 
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
 -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 
-chardev socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait 
-device isa-serial,chardev=charserial0,id=serial0 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -chardev socket,id=charchannel1,fd=45,server,nowait -device 
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device 
virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0
 -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0x7 -spice 
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
 -chardev spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg 
timestamp=on I 

Re: LEON3 networking

2019-10-23 Thread Jiri Gaisler
BTW, here is a patch that you might want to apply to qemu if you intend
to run RTEMS on leon3. The plug area must support byte accesses,
which is used by the RTEMS grlib scanning functions...

Jiri.

On 10/23/19 8:37 PM, Jiri Gaisler wrote:
> Leon3 uses the GRETH ethernet IP core for networking. You would need to
> write a qemu emulation model of it to get networking support. The GRETH
> is fairly well described in the GRLIB IP manual, so it should not be
> impossible. The core is also available in open-source (VHDL) if you need
> to look up some finer details ... :-)
>
> Jiri.
>
> On 10/23/19 6:59 PM, Joshua Shaffer wrote:
>> Does anyone know what needs implemented to get networking supported?
>>
>> Joshua
>>
>> On Wed, Oct 16, 2019 at 6:34 AM Fabien Chouteau  wrote:
>>> Hello people,
>>>
>>> On 15/10/2019 18:57, Philippe Mathieu-Daudé wrote:
 Hi Joshua,

 On 10/15/19 3:17 PM, Joshua Shaffer wrote:
> Hello,
>
> I've been using the LEON3 port of qemu, and am wondering if anyone has 
> touched the networking setup for such since the thread here: 
> https://lists.rtems.org/pipermail/users/2014-September/028224.html
 Thanks for sharing this!

 Good news, Jiri keeps rebasing his patch with the latest stable version.
 Bad news, he didn't not signed his work with a "Signed-off-by" tag so we 
 can not take this as it into the mainstream repository, see 
 https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line

>>> The Gaisler patches have been rewrote by my colleague Frederic (in CC) and 
>>> they are now in mainstream.
>>> (see https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03869.html)
>>>
>>> But none of them are implementing network support, and I never heard of 
>>> someone working on network for leon3.
>>>
>>> Regards,
>>>
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 7338461694..eaaedbfbcc 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -228,6 +228,9 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
 {
 APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);
 
+if (size != 4)
+return apb_pnp->regs[offset >> 2] >> ((~offset & 3) * 8);
+
 return apb_pnp->regs[offset >> 2];
 }
 


Re: [Virtio-fs] [PATCH] virtiofsd: Fix data corruption with O_APPEND wirte in writeback mode

2019-10-23 Thread Vivek Goyal
On Wed, Oct 23, 2019 at 09:25:23PM +0900, Misono Tomohiro wrote:
> When writeback mode is enabled (-o writeback), O_APPEND handling is
> done in kernel. Therefore virtiofsd clears O_APPEND flag when open.
> Otherwise O_APPEND flag takes precedence over pwrite() and write
> data may corrupt.
> 
> Currently clearing O_APPEND flag is done in lo_open(), but we also
> need the same operation in lo_create().

> So, factor out the flag
> update operation in lo_open() to update_open_flags() and call it
> in both lo_open() and lo_create().
> 
> This fixes the failure of xfstest generic/069 in writeback mode
> (which tests O_APPEND write data integrity).
> 

Hi,

Consolidating updation of flags both for lo_create() and lo_open() makes
sense to me. I will test it tomorrow.

Thanks
Vivek

> Signed-off-by: Misono Tomohiro 
> ---
>  contrib/virtiofsd/passthrough_ll.c | 56 +++---
>  1 file changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/contrib/virtiofsd/passthrough_ll.c 
> b/contrib/virtiofsd/passthrough_ll.c
> index e8892c3c32..79fb78ecce 100644
> --- a/contrib/virtiofsd/passthrough_ll.c
> +++ b/contrib/virtiofsd/passthrough_ll.c
> @@ -1733,6 +1733,32 @@ static void lo_releasedir(fuse_req_t req, fuse_ino_t 
> ino, struct fuse_file_info
>   fuse_reply_err(req, 0);
>  }
>  
> +static void update_open_flags(int writeback, struct fuse_file_info *fi)
> +{
> + /* With writeback cache, kernel may send read requests even
> +when userspace opened write-only */
> + if (writeback && (fi->flags & O_ACCMODE) == O_WRONLY) {
> + fi->flags &= ~O_ACCMODE;
> + fi->flags |= O_RDWR;
> + }
> +
> + /* With writeback cache, O_APPEND is handled by the kernel.
> +This breaks atomicity (since the file may change in the
> +underlying filesystem, so that the kernel's idea of the
> +end of the file isn't accurate anymore). In this example,
> +we just accept that. A more rigorous filesystem may want
> +to return an error here */
> + if (writeback && (fi->flags & O_APPEND))
> + fi->flags &= ~O_APPEND;
> +
> + /*
> +  * O_DIRECT in guest should not necessarily mean bypassing page
> +  * cache on host as well. If somebody needs that behavior, it
> +  * probably should be a configuration knob in daemon.
> +  */
> + fi->flags &= ~O_DIRECT;
> +}
> +
>  static void lo_create(fuse_req_t req, fuse_ino_t parent, const char *name,
> mode_t mode, struct fuse_file_info *fi)
>  {
> @@ -1760,12 +1786,7 @@ static void lo_create(fuse_req_t req, fuse_ino_t 
> parent, const char *name,
>   if (err)
>   goto out;
>  
> - /*
> -  * O_DIRECT in guest should not necessarily mean bypassing page
> -  * cache on host as well. If somebody needs that behavior, it
> -  * probably should be a configuration knob in daemon.
> -  */
> - fi->flags &= ~O_DIRECT;
> + update_open_flags(lo->writeback, fi);
>  
>   fd = openat(parent_inode->fd, name,
>   (fi->flags | O_CREAT) & ~O_NOFOLLOW, mode);
> @@ -1966,28 +1987,7 @@ static void lo_open(fuse_req_t req, fuse_ino_t ino, 
> struct fuse_file_info *fi)
>  
>   fuse_log(FUSE_LOG_DEBUG, "lo_open(ino=%" PRIu64 ", flags=%d)\n", ino, 
> fi->flags);
>  
> - /* With writeback cache, kernel may send read requests even
> -when userspace opened write-only */
> - if (lo->writeback && (fi->flags & O_ACCMODE) == O_WRONLY) {
> - fi->flags &= ~O_ACCMODE;
> - fi->flags |= O_RDWR;
> - }
> -
> - /* With writeback cache, O_APPEND is handled by the kernel.
> -This breaks atomicity (since the file may change in the
> -underlying filesystem, so that the kernel's idea of the
> -end of the file isn't accurate anymore). In this example,
> -we just accept that. A more rigorous filesystem may want
> -to return an error here */
> - if (lo->writeback && (fi->flags & O_APPEND))
> - fi->flags &= ~O_APPEND;
> -
> - /*
> -  * O_DIRECT in guest should not necessarily mean bypassing page
> -  * cache on host as well. If somebody needs that behavior, it
> -  * probably should be a configuration knob in daemon.
> -  */
> - fi->flags &= ~O_DIRECT;
> + update_open_flags(lo->writeback, fi);
>  
>   sprintf(buf, "%i", lo_fd(req, ino));
>   fd = openat(lo->proc_self_fd, buf, fi->flags & ~O_NOFOLLOW);
> -- 
> 2.21.0
> 
> ___
> Virtio-fs mailing list
> virtio...@redhat.com
> https://www.redhat.com/mailman/listinfo/virtio-fs




[PATCH] spapr: Don't request to unplug the same core twice

2019-10-23 Thread Greg Kurz
We must not call spapr_drc_detach() on a detached DRC otherwise bad things
can happen, ie. QEMU hangs or crashes. This is easily demonstrated with
a CPU hotplug/unplug loop using QMP.

Signed-off-by: Greg Kurz 
---
 hw/ppc/spapr.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index f9410d390a07..94f9d27096af 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3741,9 +3741,10 @@ void spapr_core_unplug_request(HotplugHandler 
*hotplug_dev, DeviceState *dev,
   spapr_vcpu_id(spapr, cc->core_id));
 g_assert(drc);
 
-spapr_drc_detach(drc);
-
-spapr_hotplug_req_remove_by_index(drc);
+if (!spapr_drc_unplug_requested(drc)) {
+spapr_drc_detach(drc);
+spapr_hotplug_req_remove_by_index(drc);
+}
 }
 
 int spapr_core_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr,




Re: [PATCH v5 11/11] vfio: unplug failover primary device before migration

2019-10-23 Thread Alex Williamson
On Wed, 23 Oct 2019 10:27:11 +0200
Jens Freimann  wrote:

> As usual block all vfio-pci devices from being migrated, but make an
> exception for failover primary devices. This is achieved by setting
> unmigratable to 0 but also add a migration blocker for all vfio-pci
> devices except failover primary devices. These will be unplugged before
> migration happens by the migration handler of the corresponding
> virtio-net standby device.
> 
> Signed-off-by: Jens Freimann 
> ---
>  hw/vfio/pci.c | 26 --
>  hw/vfio/pci.h |  1 +
>  2 files changed, 21 insertions(+), 6 deletions(-)

I wonder if this might be cleaner if we add the migration
unconditionally initially, then remove it for specific cases, such as
this or when we start to see mdev devices that can actually support
migration.  That can be refined as we start to introduce the latter
though.

Acked-by: Alex Williamson 

> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 12fac39804..5dadfec6e8 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -40,6 +40,7 @@
>  #include "pci.h"
>  #include "trace.h"
>  #include "qapi/error.h"
> +#include "migration/blocker.h"
>  
>  #define TYPE_VFIO_PCI "vfio-pci"
>  #define PCI_VFIO(obj)OBJECT_CHECK(VFIOPCIDevice, obj, TYPE_VFIO_PCI)
> @@ -2732,6 +2733,17 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
>  return;
>  }
>  
> +if (!pdev->net_failover_pair_id) {
> +error_setg(>migration_blocker,
> +"VFIO device doesn't support migration");
> +ret = migrate_add_blocker(vdev->migration_blocker, );
> +if (err) {
> +error_propagate(errp, err);
> +error_free(vdev->migration_blocker);
> +return;
> +}
> +}
> +
>  vdev->vbasedev.name = g_path_get_basename(vdev->vbasedev.sysfsdev);
>  vdev->vbasedev.ops = _pci_ops;
>  vdev->vbasedev.type = VFIO_DEVICE_TYPE_PCI;
> @@ -3008,6 +3020,10 @@ out_teardown:
>  vfio_bars_exit(vdev);
>  error:
>  error_prepend(errp, VFIO_MSG_PREFIX, vdev->vbasedev.name);
> +if (vdev->migration_blocker) {
> +migrate_del_blocker(vdev->migration_blocker);
> +error_free(vdev->migration_blocker);
> +}
>  }
>  
>  static void vfio_instance_finalize(Object *obj)
> @@ -3019,6 +3035,10 @@ static void vfio_instance_finalize(Object *obj)
>  vfio_bars_finalize(vdev);
>  g_free(vdev->emulated_config_bits);
>  g_free(vdev->rom);
> +if (vdev->migration_blocker) {
> +migrate_del_blocker(vdev->migration_blocker);
> +error_free(vdev->migration_blocker);
> +}
>  /*
>   * XXX Leaking igd_opregion is not an oversight, we can't remove the
>   * fw_cfg entry therefore leaking this allocation seems like the safest
> @@ -3151,11 +3171,6 @@ static Property vfio_pci_dev_properties[] = {
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> -static const VMStateDescription vfio_pci_vmstate = {
> -.name = "vfio-pci",
> -.unmigratable = 1,
> -};
> -
>  static void vfio_pci_dev_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -3163,7 +3178,6 @@ static void vfio_pci_dev_class_init(ObjectClass *klass, 
> void *data)
>  
>  dc->reset = vfio_pci_reset;
>  dc->props = vfio_pci_dev_properties;
> -dc->vmsd = _pci_vmstate;
>  dc->desc = "VFIO-based PCI device assignment";
>  set_bit(DEVICE_CATEGORY_MISC, dc->categories);
>  pdc->realize = vfio_realize;
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index 834a90d646..b329d50338 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -168,6 +168,7 @@ typedef struct VFIOPCIDevice {
>  bool no_vfio_ioeventfd;
>  bool enable_ramfb;
>  VFIODisplay *dpy;
> +Error *migration_blocker;
>  } VFIOPCIDevice;
>  
>  uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);




Re: [PATCH v5 02/11] pci: add option for net failover

2019-10-23 Thread Alex Williamson
On Wed, 23 Oct 2019 10:27:02 +0200
Jens Freimann  wrote:

> This patch adds a net_failover_pair_id property to PCIDev which is
> used to link the primary device in a failover pair (the PCI dev) to
> a standby (a virtio-net-pci) device.
> 
> It only supports ethernet devices. Also currently it only supports
> PCIe devices. QEMU will exit with an error message otherwise.
> 
> Signed-off-by: Jens Freimann 
> ---
>  hw/pci/pci.c | 17 +
>  include/hw/pci/pci.h |  3 +++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index aa05c2b9b2..fa9b5219f8 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -75,6 +75,8 @@ static Property pci_props[] = {
>  QEMU_PCIE_LNKSTA_DLLLA_BITNR, true),
>  DEFINE_PROP_BIT("x-pcie-extcap-init", PCIDevice, cap_present,
>  QEMU_PCIE_EXTCAP_INIT_BITNR, true),
> +DEFINE_PROP_STRING("net_failover_pair_id", PCIDevice,
> +net_failover_pair_id),

Nit, white space appears broken here.

>  DEFINE_PROP_END_OF_LIST()
>  };
>  
> @@ -2077,6 +2079,7 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
> **errp)
>  ObjectClass *klass = OBJECT_CLASS(pc);
>  Error *local_err = NULL;
>  bool is_default_rom;
> +uint16_t class_id;
>  
>  /* initialize cap_present for pci_is_express() and pci_config_size(),
>   * Note that hybrid PCIs are not set automatically and need to manage
> @@ -2101,6 +2104,20 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
> **errp)
>  }
>  }
>  
> +if (pci_dev->net_failover_pair_id) {
> +if (!pci_is_express(pci_dev)) {
> +error_setg(errp, "failover device is not a PCIExpress device");
> +error_propagate(errp, local_err);
> +return;
> +}

Did we decide we don't need to test that the device is also in a
hotpluggable slot?  Are there also multi-function considerations that
should be prevented or documented?  For example, if a user tries to
configure both the primary and failover NICs in the same slot, I assume
bad things will happen.

> +class_id = pci_get_word(pci_dev->config + PCI_CLASS_DEVICE);
> +if (class_id != PCI_CLASS_NETWORK_ETHERNET) {
> +error_setg(errp, "failover device is not an Ethernet device");
> +error_propagate(errp, local_err);
> +return;
> +}
> +}

Looks like cleanup is missing both both error cases, the option rom
error path below this does a pci_qdev_unrealize() before returning so
I'd assume we want the same here.  Thanks,

Alex

> +
>  /* rom loading */
>  is_default_rom = false;
>  if (pci_dev->romfile == NULL && pc->romfile != NULL) {
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index f3f0ffd5fb..def5435685 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -352,6 +352,9 @@ struct PCIDevice {
>  MSIVectorUseNotifier msix_vector_use_notifier;
>  MSIVectorReleaseNotifier msix_vector_release_notifier;
>  MSIVectorPollNotifier msix_vector_poll_notifier;
> +
> +/* ID of standby device in net_failover pair */
> +char *net_failover_pair_id;
>  };
>  
>  void pci_register_bar(PCIDevice *pci_dev, int region_num,




Re: [PATCH v2 03/20] piix4: Add a i8259 Interrupt Controller as specified in datasheet

2019-10-23 Thread Esteban Bosse
El mar, 22-10-2019 a las 11:35 +0200, Philippe Mathieu-Daudé escribió:
> On 10/22/19 10:44 AM, Esteban Bosse wrote:
> > El vie, 18-10-2019 a las 15:47 +0200, Philippe Mathieu-Daudé
> > escribió:
> > > From: Hervé Poussineau 
> > > 
> > > Add ISA irqs as piix4 gpio in, and CPU interrupt request as piix4
> > > gpio out.
> > > Remove i8259 instanciated in malta board, to not have it twice.
> > > 
> > > We can also remove the now unused piix4_init() function.
> > > 
> > > Acked-by: Michael S. Tsirkin 
> > > Acked-by: Paolo Bonzini 
> > > Signed-off-by: Hervé Poussineau 
> > > Message-Id: <20171216090228.28505-8-hpous...@reactos.org>
> > > Reviewed-by: Aleksandar Markovic 
> > > [PMD: rebased, updated includes, use ISA_NUM_IRQS in for loop]
> > > Signed-off-by: Philippe Mathieu-Daudé 
> > > ---
> > >   hw/isa/piix4.c   | 43 -
> > > ---
> > > ---
> > >   hw/mips/mips_malta.c | 32 +---
> > >   include/hw/i386/pc.h |  1 -
> > >   3 files changed, 45 insertions(+), 31 deletions(-)
> > > 
> > > diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> > > index d0b18e0586..9c37c85ae2 100644
> > > --- a/hw/isa/piix4.c
> > > +++ b/hw/isa/piix4.c
> > > @@ -24,6 +24,7 @@
> > >*/
> > >   
> > >   #include "qemu/osdep.h"
> > > +#include "hw/irq.h"
> > >   #include "hw/i386/pc.h"
> > >   #include "hw/pci/pci.h"
> > >   #include "hw/isa/isa.h"
> > > @@ -36,6 +37,8 @@ PCIDevice *piix4_dev;
> > >   
> > >   typedef struct PIIX4State {
> > >   PCIDevice dev;
> > > +qemu_irq cpu_intr;
> > > +qemu_irq *isa;
> > >   
> > >   /* Reset Control Register */
> > >   MemoryRegion rcr_mem;
> > > @@ -94,6 +97,18 @@ static const VMStateDescription vmstate_piix4
> > > = {
> > >   }
> > >   };
> > >   
> > > +static void piix4_request_i8259_irq(void *opaque, int irq, int
> > > level)
> > > +{
> > > +PIIX4State *s = opaque;
> > > +qemu_set_irq(s->cpu_intr, level);
> > > +}
> > > +
> > > +static void piix4_set_i8259_irq(void *opaque, int irq, int
> > > level)
> > > +{
> > > +PIIX4State *s = opaque;
> > > +qemu_set_irq(s->isa[irq], level);
> > > +}
> > > +
> > >   static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t
> > > val,
> > >   unsigned int len)
> > >   {
> > > @@ -127,29 +142,35 @@ static const MemoryRegionOps piix4_rcr_ops
> > > = {
> > >   static void piix4_realize(PCIDevice *dev, Error **errp)
> > >   {
> > >   PIIX4State *s = PIIX4_PCI_DEVICE(dev);
> > > +ISABus *isa_bus;
> > > +qemu_irq *i8259_out_irq;
> > >   
> > > -if (!isa_bus_new(DEVICE(dev), pci_address_space(dev),
> > > - pci_address_space_io(dev), errp)) {
> > > +isa_bus = isa_bus_new(DEVICE(dev), pci_address_space(dev),
> > > +  pci_address_space_io(dev), errp);
> > > +if (!isa_bus) {
> > >   return;
> > >   }
> > >   
> > > +qdev_init_gpio_in_named(DEVICE(dev), piix4_set_i8259_irq,
> > > +"isa", ISA_NUM_IRQS);
> > > +qdev_init_gpio_out_named(DEVICE(dev), >cpu_intr,
> > > + "intr", 1);
> > My question is not about this patch:
> > 
> > The function name is "qdev_init_gpio_out_named" but support more
> > than 1
> > gpio, right? in this case, the name shouldn't be something like
> > "qdev_init_gpios_out_named"?
> 
> Indeed devices can have various IRQ output lines.
> 
> Note, QEMU does not intend to model full devices, but only the
> part required to run a guest. If a guest doesn't use some part
> of a device, QEMU will likely not model it.
> 
> For example, sometimes a device can have N output IRQ to signal
> various error conditions, which are usually used by specific
> firmwares in embedded devices. QEMU might not model embedded
> boards using this device but we can find it in a generic machine
> which runs a full operating system. So far these OS don't care
> about handling these errors, so QEMU will only model the IRQ
> line required to run the OS, no more. This is on purpose.
> 
> Now about the naming, I have no preference which form is better.
> 
> > > +
> > >   memory_region_init_io(>rcr_mem, OBJECT(dev),
> > > _rcr_ops,
> > > s,
> > > "reset-control", 1);
> > >   memory_region_add_subregion_overlap(pci_address_space_io(de
> > > v),
> > > 0xcf9,
> > >   >rcr_mem, 1);
> > Why do you use the priority 1 in this case?
> > >   
> > > +/* initialize i8259 pic */
> > > +i8259_out_irq = qemu_allocate_irqs(piix4_request_i8259_irq,
> > > s,
> > > 1);
> > > +s->isa = i8259_init(isa_bus, *i8259_out_irq);
> > > +
> > > +/* initialize ISA irqs */
> > > +isa_bus_irqs(isa_bus, s->isa);
> > > +
> > >   piix4_dev = dev;
> > >   }
> > >   
> > > -int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
> > > -{
> > > -PCIDevice *d;
> > > -
> > > -d = pci_create_simple_multifunction(bus, devfn, true,

[PATCH v3 00/33] Clean-ups: qom-ify serial and remove QDEV_PROP_PTR

2019-10-23 Thread Marc-André Lureau
Hi,

QDEV_PROP_PTR is marked in multiple places as "FIXME/TODO/remove
me". In most cases, it can be easily replaced with QDEV_PROP_LINK when
the pointer points to an Object.

There are a few places where such substitution isn't possible. For
those places, it seems reasonable to use a specific setter method
instead, and keep the user_creatable = false. In other places,
proper usage of qemu_irq is the solution.

The serial code wasn't converted to qdev, which makes it a bit more
archaic to deal with. Let's convert it first, so we can more easily
embed it from other devices, and re-export some properties.

v3:
 - introduce SerialMM and SerialIO sysbus devices
 - remove serial_mm_connect introduced in v2
 - replace "base" property introduced in v2, use "instance-id" for
   vmstate purpose only
 - add a few preliminary clean-ups

v2:
 - qom-ify serial
 - embed the serial from sm501, and expose a "chardev" property
 - add "leon3: use qemu_irq framework instead of callback as property"
 - add "sparc: move PIL irq handling to cpu.c"
 - add "cris: improve passing PIC interrupt vector to the CPU"
 - misc comment/todo changes, add r-b tags

Marc-André Lureau (33):
  qdev: remove unused qdev_prop_int64
  sysbus: remove unused sysbus_try_create*
  sysbus: remove outdated comment
  chardev: generate an internal id when none given
  serial-pci-multi: factor out multi_serial_get_nr_ports
  serial: initial qom-ification
  serial: register vmsd with DeviceClass
  serial: add "chardev" property
  serial: add "baudbase" property
  serial: add "instance-id" property
  serial: realize the serial device
  serial: replace serial_exit_core() with unrealize
  serial: start making SerialMM a sysbus device
  serial-mm: add "regshift" property
  serial-mm: add endianness property
  serial-mm: use sysbus facilities
  serial: make SerialIO a sysbus device
  mips: inline serial_init
  sm501: make SerialMM a child, export chardev property
  vmmouse: replace PROP_PTR with PROP_LINK
  lance: replace PROP_PTR with PROP_LINK
  etraxfs: remove PROP_PTR usage
  dp8393x: replace PROP_PTR with PROP_LINK
  leon3: use qemu_irq framework instead of callback as property
  sparc: move PIL irq handling to cpu.c
  RFC: mips/cps: fix setting saar property
  cris: improve passing PIC interrupt vector to the CPU
  smbus-eeprom: remove PROP_PTR
  omap-intc: remove PROP_PTR
  omap-i2c: remove PROP_PTR
  omap-gpio: remove PROP_PTR
  qdev: remove PROP_MEMORY_REGION
  qdev: remove QDEV_PROP_PTR

 chardev/char.c   |  32 +--
 hw/arm/omap1.c   |   8 +-
 hw/arm/omap2.c   |  25 +++---
 hw/char/omap_uart.c  |   2 +-
 hw/char/serial-isa.c |  11 ++-
 hw/char/serial-pci-multi.c   |  45 +++---
 hw/char/serial-pci.c |  17 +++-
 hw/char/serial.c | 164 ---
 hw/core/qdev-properties.c|  50 ---
 hw/core/sysbus.c |  32 ---
 hw/cris/axis_dev88.c |   4 -
 hw/display/sm501.c   |  31 +--
 hw/dma/sparc32_dma.c |   2 +-
 hw/gpio/omap_gpio.c  |  42 -
 hw/i2c/omap_i2c.c|  19 ++--
 hw/i2c/smbus_eeprom.c|  17 ++--
 hw/i386/pc.c |   7 +-
 hw/i386/vmmouse.c|   8 +-
 hw/input/pckbd.c |   8 +-
 hw/intc/etraxfs_pic.c|  26 +-
 hw/intc/grlib_irqmp.c|  35 +---
 hw/intc/omap_intc.c  |  17 ++--
 hw/mips/boston.c |   2 +-
 hw/mips/cps.c|   2 +-
 hw/mips/mips_jazz.c  |   3 +-
 hw/mips/mips_malta.c |   2 +-
 hw/mips/mips_mipssim.c   |  13 ++-
 hw/net/dp8393x.c |   7 +-
 hw/net/etraxfs_eth.c |  44 +++---
 hw/net/lance.c   |   5 +-
 hw/net/pcnet-pci.c   |   2 +-
 hw/net/pcnet.h   |   2 +-
 hw/sh4/r2d.c |   2 +-
 hw/sparc/leon3.c |  38 +---
 hw/sparc/trace-events|   4 -
 include/hw/arm/omap.h|  52 +++
 include/hw/char/serial.h |  44 +++---
 include/hw/cris/etraxfs.h|  20 +
 include/hw/input/i8042.h |   4 +-
 include/hw/qdev-properties.h |  27 --
 include/hw/sysbus.h  |  13 +--
 include/qemu/id.h|   1 +
 target/cris/cpu.c|   8 ++
 target/cris/cpu.h|   1 +
 target/sparc/cpu.c   |  39 +
 target/sparc/cpu.h   |   1 +
 target/sparc/trace-events|   4 +
 util/id.c|   1 +
 48 files changed, 515 insertions(+), 428 deletions(-)

-- 
2.23.0.606.g08da6496b6




Re: [PATCH v5 02/11] pci: add option for net failover

2019-10-23 Thread Jens Freimann

On Wed, Oct 23, 2019 at 12:06:48PM -0600, Alex Williamson wrote:

On Wed, 23 Oct 2019 10:27:02 +0200
Jens Freimann  wrote:


This patch adds a net_failover_pair_id property to PCIDev which is
used to link the primary device in a failover pair (the PCI dev) to
a standby (a virtio-net-pci) device.

It only supports ethernet devices. Also currently it only supports
PCIe devices. QEMU will exit with an error message otherwise.

Signed-off-by: Jens Freimann 
---
 hw/pci/pci.c | 17 +
 include/hw/pci/pci.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index aa05c2b9b2..fa9b5219f8 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -75,6 +75,8 @@ static Property pci_props[] = {
 QEMU_PCIE_LNKSTA_DLLLA_BITNR, true),
 DEFINE_PROP_BIT("x-pcie-extcap-init", PCIDevice, cap_present,
 QEMU_PCIE_EXTCAP_INIT_BITNR, true),
+DEFINE_PROP_STRING("net_failover_pair_id", PCIDevice,
+net_failover_pair_id),


Nit, white space appears broken here.


I'll fix it.


 DEFINE_PROP_END_OF_LIST()
 };

@@ -2077,6 +2079,7 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
**errp)
 ObjectClass *klass = OBJECT_CLASS(pc);
 Error *local_err = NULL;
 bool is_default_rom;
+uint16_t class_id;

 /* initialize cap_present for pci_is_express() and pci_config_size(),
  * Note that hybrid PCIs are not set automatically and need to manage
@@ -2101,6 +2104,20 @@ static void pci_qdev_realize(DeviceState *qdev, Error 
**errp)
 }
 }

+if (pci_dev->net_failover_pair_id) {
+if (!pci_is_express(pci_dev)) {
+error_setg(errp, "failover device is not a PCIExpress device");
+error_propagate(errp, local_err);
+return;
+}


Did we decide we don't need to test that the device is also in a
hotpluggable slot?  


Hmm, my reply to you was never sent. I thought the check for
qdev_device_add() was sufficient but you said that works only
after qdev_hotplug is set (after machine creation). I modified
the check to this:

   hide = should_hide_device(opts);  
 
   if ((hide || qdev_hotplug) && bus && !qbus_is_hotpluggable(bus)) {
   error_setg(errp, QERR_BUS_NO_HOTPLUG, bus->name); 
   return NULL;  
   } 
 
   if (hide) {   
   return NULL;  
   }


This will make qemu fail when we have the device in the initial
configuration or when we hotplug it to a bus that doesn't support it.
I tested both with a device on pcie.0. Am I missing something? 


Are there also multi-function considerations that
should be prevented or documented?  For example, if a user tries to
configure both the primary and failover NICs in the same slot, I assume
bad things will happen.


 I would have expected that this is already checked in pci code, but
it is not. I tried it and when I put both devices into the same slot
they are both unplugged from the guest during boot but nothing else
happens. I don't know what triggers that unplug of the devices.

I'm not aware of any other problems regarding multi-function, which
doesn't mean there aren't any. 




+class_id = pci_get_word(pci_dev->config + PCI_CLASS_DEVICE);
+if (class_id != PCI_CLASS_NETWORK_ETHERNET) {
+error_setg(errp, "failover device is not an Ethernet device");
+error_propagate(errp, local_err);
+return;
+}
+}


Looks like cleanup is missing both both error cases, the option rom
error path below this does a pci_qdev_unrealize() before returning so
I'd assume we want the same here.  Thanks,


Thanks, I'll fix this too.

regards,
Jens 





Re: LEON3 networking

2019-10-23 Thread Jiri Gaisler
Leon3 uses the GRETH ethernet IP core for networking. You would need to
write a qemu emulation model of it to get networking support. The GRETH
is fairly well described in the GRLIB IP manual, so it should not be
impossible. The core is also available in open-source (VHDL) if you need
to look up some finer details ... :-)

Jiri.

On 10/23/19 6:59 PM, Joshua Shaffer wrote:
> Does anyone know what needs implemented to get networking supported?
>
> Joshua
>
> On Wed, Oct 16, 2019 at 6:34 AM Fabien Chouteau  wrote:
>> Hello people,
>>
>> On 15/10/2019 18:57, Philippe Mathieu-Daudé wrote:
>>> Hi Joshua,
>>>
>>> On 10/15/19 3:17 PM, Joshua Shaffer wrote:
 Hello,

 I've been using the LEON3 port of qemu, and am wondering if anyone has 
 touched the networking setup for such since the thread here: 
 https://lists.rtems.org/pipermail/users/2014-September/028224.html
>>> Thanks for sharing this!
>>>
>>> Good news, Jiri keeps rebasing his patch with the latest stable version.
>>> Bad news, he didn't not signed his work with a "Signed-off-by" tag so we 
>>> can not take this as it into the mainstream repository, see 
>>> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
>>>
>> The Gaisler patches have been rewrote by my colleague Frederic (in CC) and 
>> they are now in mainstream.
>> (see https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03869.html)
>>
>> But none of them are implementing network support, and I never heard of 
>> someone working on network for leon3.
>>
>> Regards,
>>



Re: [PATCH] cputlb: Fix tlb_vaddr_to_host

2019-10-23 Thread Philippe Mathieu-Daudé

On 10/23/19 5:49 PM, Richard Henderson wrote:

Using uintptr_t instead of target_ulong meant that, for 64-bit guest
and 32-bit host, we truncated the guest address comparator and so may
not hit the tlb when we should.

Fixes: 4811e9095c0
Signed-off-by: Richard Henderson 
---

Fixes aarch64 emulation on arm32 host, after our recent changes
to tlb probing.


r~

---
  accel/tcg/cputlb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 6f4194df96..5eebddcca8 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1189,7 +1189,7 @@ void *tlb_vaddr_to_host(CPUArchState *env, abi_ptr addr,
  MMUAccessType access_type, int mmu_idx)
  {
  CPUTLBEntry *entry = tlb_entry(env, mmu_idx, addr);
-uintptr_t tlb_addr, page;
+target_ulong tlb_addr, page;
  size_t elt_ofs;
  
  switch (access_type) {




Clang catched this with -Wshorten-64-to-32 but there are so many other 
warnings to fix that we can not use it :(


accel/tcg/cputlb.c:620:26: error: implicit conversion loses integer 
precision: 'size_t' (aka 'unsigned long') to 'unsigned int' 
[-Werror,-Wshorten-64-to-32]

unsigned int n = tlb_n_entries(env, mmu_idx);
 ~   ^~~
accel/tcg/cputlb.c:788:13: error: implicit conversion loses integer 
precision: 'uintptr_t' (aka 'unsigned long') to 'unsigned int' 
[-Werror,-Wshorten-64-to-32]

index = tlb_index(env, mmu_idx, vaddr_page);
  ~ ^~~

Maybe we could try to clean accel/tcg/ and use it there at least.

Reviewed-by: Philippe Mathieu-Daudé 



[PATCH v3 15/33] serial-mm: add endianness property

2019-10-23 Thread Marc-André Lureau
Add a qdev property for endianness, so memory region setup can be done
in realize.

Signed-off-by: Marc-André Lureau 
---
 hw/char/serial.c | 2 ++
 include/hw/char/serial.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index c28cfc94fd..2f7667c30c 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -1081,6 +1081,7 @@ SerialMM *serial_mm_init(MemoryRegion *address_space,
 qdev_prop_set_uint32(DEVICE(s), "baudbase", baudbase);
 qdev_prop_set_chr(DEVICE(s), "chardev", chr);
 qdev_prop_set_int32(DEVICE(s), "instance-id", base);
+qdev_prop_set_uint8(DEVICE(s), "endianness", end);
 
 qdev_init_nofail(DEVICE(s));
 qdev_init_nofail(DEVICE(self));
@@ -1102,6 +1103,7 @@ static void serial_mm_instance_init(Object *o)
 
 static Property serial_mm_properties[] = {
 DEFINE_PROP_UINT8("regshift", SerialMM, regshift, 0),
+DEFINE_PROP_UINT8("endianness", SerialMM, endianness, 
DEVICE_NATIVE_ENDIAN),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
index 759c85976d..2d0802a909 100644
--- a/include/hw/char/serial.h
+++ b/include/hw/char/serial.h
@@ -86,6 +86,7 @@ typedef struct SerialMM {
 SerialState serial;
 
 uint8_t regshift;
+uint8_t endianness;
 } SerialMM;
 
 extern const VMStateDescription vmstate_serial;
-- 
2.23.0.606.g08da6496b6




[Bug 1721275] Re: Support more ARM CPUs

2019-10-23 Thread Richard Henderson
They are implemented, because they also appear in A-profile.
We just need to set the corresponding MVFR field to enable them.

Setting MVFR2.FPMISC = 4 will do the job, I believe.

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

Title:
  Support more ARM CPUs

Status in QEMU:
  Won't Fix

Bug description:
  Hi,

  This is an enhancement request, rather than a bug report.

  After some discussions/presentations during the last Linaro Connect
  (SFO17), I understand that it may be easy to add support for more ARM
  CPUs in QEMU. I am interested in user-mode, if that matters.

  I'm primarily using QEMU for GCC validations, and I'd like to make
  sure that GCC doesn't generate instructions not supported by the CPU
  it's supposed to generate code for.

  I'd like to have:
  cortex-m0
  cortex-m4
  cortex-m7
  cortex-m23
  cortex-m33

  cortex-a35
  cortex-a53
  cortex-a57

  Is it possible?
  Is it the right place to ask?
  Should I file separate requests for each?

  Thanks

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



Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt

2019-10-23 Thread John Snow



On 10/23/19 1:28 PM, Fernando Casas Schössow wrote:
> Hi John,
> 
> Thanks for looking into this.
> I can quickly repro the problem with qemu 4.0 binary with debugging
> symbols enabled as I have it available already.
> Doing the same with qemu 4.1 or development head may be too much hassle
> but if it's really the only way I can give it try.
> 
> Would it worth it to try with 4.0 first and get the strack trace or it
> will not help and the only way to go is with 4.1 (or dev)?
> 
> Thanks,
> 
> Fernando
> 

If 4.0 is what you have access to, having the stack trace for that is
better than not, but confirming it happens on the latest release would
be nice.

Can you share your workflow for virsh that reproduces the failure?

--js

> On mié, oct 23, 2019 at 5:34 PM, John Snow  wrote:
>> On 10/18/19 5:41 PM, Fernando Casas Schössow wrote:
>>
>> Hi, 
>>
>> Hi! Thanks for the report.
>>
>> Today while working with two different Windows Server 2012 R2
>> guests I found that when I try to attach an ISO file to a SCSI
>> CD-ROM device through libvirt (virsh or virt-manager) while the
>> guest is running, qemu crashes and the following message is
>> logged: Assertion failed: blk_get_aio_context(d->conf.blk) ==
>> s->ctx
>> (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c:
>> virtio_scsi_ctx_check: 246) I can repro this at will. All I have
>> to do is to try to attach an ISO file to the SCSI CDROM while the
>> guest is running. The SCSI controller model is virtio-scsi with
>> iothread enabled. Please find below all the details about my setup
>> that I considered relevant but I missed something please don't
>> hesitate to let me know: 
>>
>> Looks like we got aio_context management wrong with iothread for the
>> media change events somewhere. Should be easy enough to fix if we
>> figure out where the bad assumption is.
>>
>> Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 
>>
>> Do you have the ability to try 4.1, or the latest development head
>> with debugging symbols enabled?
>>
>> Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI
>> controller: virtio-scsi (with iothread enabled) Guest firmware:
>> OVMF-EFI Guest OS: Window Server 2012 R2 Guest virtio drivers
>> version: 171 (current stable) qemu command line:
>> /usr/bin/qemu-system-x86_64 -name
>> guest=DCHOMENET01,debug-threads=on -S -object
>> 
>> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes
>> -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu
>> 
>> IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
>> -drive
>> 
>> file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on
>> -drive
>> 
>> file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1
>> -m 1536 -overcommit mem-lock=off -smp
>> 1,sockets=1,cores=1,threads=1 -object iothread,id=iothread1 -uuid
>> f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults
>> -chardev socket,id=charmonitor,fd=33,server,nowait -mon
>> chardev=charmonitor,id=monitor,mode=control -rtc
>> base=localtime,driftfix=slew -global
>> kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global
>> PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot
>> strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device
>> 
>> virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5
>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6
>> -drive
>> 
>> file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads
>> -device
>> 
>> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
>> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device
>> 
>> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
>> -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device
>> 
>> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3
>> -chardev
>> socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait 
>> -device
>> isa-serial,chardev=charserial0,id=serial0 -chardev
>> spicevmc,id=charchannel0,name=vdagent -device
>> 
>> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
>> -chardev socket,id=charchannel1,fd=45,server,nowait -device
>> 
>> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
>> -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0
>> -device

[PATCH v3 14/33] serial-mm: add "regshift" property

2019-10-23 Thread Marc-André Lureau
And a property and rename "it_shift" field to "regshift", as it seems
to be more popular (and I don't know what "it" stands for).

Signed-off-by: Marc-André Lureau 
---
 hw/char/serial.c | 23 ++-
 include/hw/char/serial.h |  4 ++--
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index 0290b3c633..c28cfc94fd 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -1033,7 +1033,7 @@ static uint64_t serial_mm_read(void *opaque, hwaddr addr,
unsigned size)
 {
 SerialMM *s = SERIAL_MM(opaque);
-return serial_ioport_read(>serial, addr >> s->it_shift, 1);
+return serial_ioport_read(>serial, addr >> s->regshift, 1);
 }
 
 static void serial_mm_write(void *opaque, hwaddr addr,
@@ -1041,7 +1041,7 @@ static void serial_mm_write(void *opaque, hwaddr addr,
 {
 SerialMM *s = SERIAL_MM(opaque);
 value &= 255;
-serial_ioport_write(>serial, addr >> s->it_shift, value, 1);
+serial_ioport_write(>serial, addr >> s->regshift, value, 1);
 }
 
 static const MemoryRegionOps serial_mm_ops[3] = {
@@ -1069,14 +1069,14 @@ static const MemoryRegionOps serial_mm_ops[3] = {
 };
 
 SerialMM *serial_mm_init(MemoryRegion *address_space,
-hwaddr base, int it_shift,
+hwaddr base, int regshift,
 qemu_irq irq, int baudbase,
 Chardev *chr, enum device_endian end)
 {
 SerialMM *self = SERIAL_MM(qdev_create(NULL, TYPE_SERIAL_MM));
 SerialState *s = >serial;
 
-self->it_shift = it_shift;
+qdev_prop_set_uint8(DEVICE(self), "regshift", regshift);
 s->irq = irq;
 qdev_prop_set_uint32(DEVICE(s), "baudbase", baudbase);
 qdev_prop_set_chr(DEVICE(s), "chardev", chr);
@@ -1086,7 +1086,7 @@ SerialMM *serial_mm_init(MemoryRegion *address_space,
 qdev_init_nofail(DEVICE(self));
 
 memory_region_init_io(>io, NULL, _mm_ops[end], self,
-  "serial", 8 << it_shift);
+  "serial", 8 << regshift);
 memory_region_add_subregion(address_space, base, >io);
 
 return self;
@@ -1100,11 +1100,24 @@ static void serial_mm_instance_init(Object *o)
 TYPE_SERIAL, _abort, NULL);
 }
 
+static Property serial_mm_properties[] = {
+DEFINE_PROP_UINT8("regshift", SerialMM, regshift, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void serial_mm_class_init(ObjectClass *klass, void* data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->props = serial_mm_properties;
+}
+
 static const TypeInfo serial_mm_info = {
 .name = TYPE_SERIAL_MM,
 .parent = TYPE_SYS_BUS_DEVICE,
 .instance_init = serial_mm_instance_init,
 .instance_size = sizeof(SerialMM),
+.class_init = serial_mm_class_init,
 };
 
 static void serial_register_types(void)
diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
index f146d426c2..759c85976d 100644
--- a/include/hw/char/serial.h
+++ b/include/hw/char/serial.h
@@ -85,7 +85,7 @@ typedef struct SerialMM {
 
 SerialState serial;
 
-int it_shift;
+uint8_t regshift;
 } SerialMM;
 
 extern const VMStateDescription vmstate_serial;
@@ -102,7 +102,7 @@ void serial_set_frequency(SerialState *s, uint32_t 
frequency);
 SerialState *serial_init(int base, qemu_irq irq, int baudbase,
  Chardev *chr, MemoryRegion *system_io);
 SerialMM *serial_mm_init(MemoryRegion *address_space,
- hwaddr base, int it_shift,
+ hwaddr base, int regshift,
  qemu_irq irq, int baudbase,
  Chardev *chr, enum device_endian end);
 
-- 
2.23.0.606.g08da6496b6




Re: [PATCH v8 00/22] target/arm: Reduce overhead of cpu_get_tb_cpu_state

2019-10-23 Thread Alex Bennée
For system emulation? Sure. I think linux-user is harder because you need
the be crt and libs packaged.

On Wed, 23 Oct 2019, 17:13 Richard Henderson, 
wrote:

> On 10/23/19 11:17 AM, Alex Bennée wrote:
> >>> Dropping this series again for the moment.
> >> Argh!  I had forgotten that we have no testing of armeb in check-tcg.
> >
> > Does it need it's own toolchain or can it be done with flags?
>
> I think the compiler only needs flags, so we might be able to gin
> something up
> for {aarch64_eb,armeb}-linux-user from __start.
>
>
> r~
>


[PATCH v3 09/33] serial: add "baudbase" property

2019-10-23 Thread Marc-André Lureau
Signed-off-by: Marc-André Lureau 
---
 hw/char/serial.c | 5 +++--
 include/hw/char/serial.h | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index 09e89727a6..069d8715d0 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -988,7 +988,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
 SerialState *s = SERIAL(dev);
 
 s->irq = irq;
-s->baudbase = baudbase;
+qdev_prop_set_uint32(dev, "baudbase", baudbase);
 qdev_prop_set_chr(dev, "chardev", chr);
 serial_realize_core(s, _fatal);
 qdev_set_legacy_instance_id(dev, base, 2);
@@ -1002,6 +1002,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
 
 static Property serial_properties[] = {
 DEFINE_PROP_CHR("chardev", SerialState, chr),
+DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -1070,7 +1071,7 @@ SerialState *serial_mm_init(MemoryRegion *address_space,
 
 s->it_shift = it_shift;
 s->irq = irq;
-s->baudbase = baudbase;
+qdev_prop_set_uint32(dev, "baudbase", baudbase);
 qdev_prop_set_chr(dev, "chardev", chr);
 
 serial_realize_core(s, _fatal);
diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
index 180cc7c24e..3dc618598e 100644
--- a/include/hw/char/serial.h
+++ b/include/hw/char/serial.h
@@ -58,7 +58,7 @@ typedef struct SerialState {
 CharBackend chr;
 int last_break_enable;
 int it_shift;
-int baudbase;
+uint32_t baudbase;
 uint32_t tsr_retry;
 guint watch_tag;
 uint32_t wakeup;
-- 
2.23.0.606.g08da6496b6




[Bug 1596579] Re: segfault upon reboot

2019-10-23 Thread Eduardo
I have no way of reproducing now, should be good by now, I wouldn't
worry about it, just close this, thanks.

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

Title:
  segfault upon reboot

Status in QEMU:
  Incomplete

Bug description:
  [   31.167946] VFIO - User Level meta-driver version: 0.3
  [   34.969182] kvm: zapping shadow pages for mmio generation wraparound
  [   43.095077] vfio-pci :1a:00.0: irq 50 for MSI/MSI-X
  [166493.891331] perf interrupt took too long (2506 > 2500), lowering 
kernel.perf_event_max_sample_rate to 5
  [315765.858431] qemu-kvm[1385]: segfault at 0 ip   (null) sp 
7ffe5430db18 error 14
  [315782.002077] vfio-pci :1a:00.0: transaction is not cleared; proceeding 
with reset anyway
  [315782.910854] mptsas :1a:00.0: Refused to change power state, currently 
in D3
  [315782.911236] mptbase: ioc1: Initiating bringup
  [315782.911238] mptbase: ioc1: WARNING - Unexpected doorbell active!
  [315842.957613] mptbase: ioc1: ERROR - Failed to come READY after reset! 
IocState=f000
  [315842.957670] mptbase: ioc1: WARNING - ResetHistory bit failed to clear!
  [315842.957675] mptbase: ioc1: ERROR - Diagnostic reset FAILED! (h)
  [315842.957717] mptbase: ioc1: WARNING - NOT READY WARNING!
  [315842.957720] mptbase: ioc1: ERROR - didn't initialize properly! (-1)
  [315842.957890] mptsas: probe of :1a:00.0 failed with error -1

  The qemu-kvm segfault happens when I issue a reboot on the Windows VM. The 
card I have is:
  1a:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E 
PCI-Express Fusion-MPT SAS (rev ff)

  I have two of these cards (bought with many years difference), exact same 
model, and they fail the same way. I'm using PCI passthrough on this card for 
access to the tape drive.
  This is very easy to reproduce, so feel free to let me know what to try.
  Kernel 3.10.0-327.18.2.el7.x86_64 (Centos 7.2.1511).
  qemu-kvm-1.5.3-105.el7_2.4.x86_64
  Reporting it here because of the segfault, but I guess I might have to open a 
bug report with mptbase as well?

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



Re: [PATCH v2 03/20] piix4: Add a i8259 Interrupt Controller as specified in datasheet

2019-10-23 Thread Esteban Bosse
El mar, 22-10-2019 a las 10:42 +0100, Peter Maydell escribió:
> On Tue, 22 Oct 2019 at 09:52, Esteban Bosse 
> wrote:
> > El vie, 18-10-2019 a las 15:47 +0200, Philippe Mathieu-Daudé
> > escribió:
> > > +static void piix4_request_i8259_irq(void *opaque, int irq, int
> > > level)
> > > +{
> > > +PIIX4State *s = opaque;
> > > +qemu_set_irq(s->cpu_intr, level);
> > > +}
> > I would like to understand why in `PIIX4State *s = opaque;` its not
> > necessary a cast or a object macro magic.
> > Something like:
> > PIIX4State *s = (PIIX4State*)opaque;
> > PIIX4State *s = PIIX4STATE(opaque);
> 
> The simple answer to "why don't we need a cast" is
> "because the type of 'opaque' is 'void *', and in C there is
> no need to explicitly cast a 'void *' as it will be implicitly
> converted to the pointer type of the destination". (This is
> different from C++, which does require an explicit cast for void*.)
> 
> For QOM types, QEMU conventionally uses the QOM casting
> macro to convert a pointer-to-instance to
> pointer-to-instance-of-parent-class and vice versa.
> In some places, like this one, what we have is just a
> void* representing opaque data having been passed around.
> You could use the QOM cast macro here, which would add
> a bit of extra type-safety, but the project doesn't have
> a strong convention here on whether to do so or not, so
> you'll often see the just-assignment code.
> 
> thanks
> -- PMM

Thank you very much for your detailed explanation :).




[PATCH v3 06/33] serial: initial qom-ification

2019-10-23 Thread Marc-André Lureau
Make SerialState a device (the following patches will introduce IO/MM
sysbus serial devices)

None of the serial_{,mm}_init() callers actually free the returned
value (even if they did, it would be quite harmless), so we can change
the object allocation at will.

However, the devices that embed SerialState must now have their field
QOM-initialized manually (isa, pci, pci-multi).

Signed-off-by: Marc-André Lureau 
---
 hw/char/serial-isa.c   |  9 +
 hw/char/serial-pci-multi.c | 15 +++
 hw/char/serial-pci.c   | 13 -
 hw/char/serial.c   | 25 +++--
 include/hw/char/serial.h   |  7 ++-
 5 files changed, 61 insertions(+), 8 deletions(-)

diff --git a/hw/char/serial-isa.c b/hw/char/serial-isa.c
index 9e31c51bb6..9a5928b3ee 100644
--- a/hw/char/serial-isa.c
+++ b/hw/char/serial-isa.c
@@ -111,10 +111,19 @@ static void serial_isa_class_initfn(ObjectClass *klass, 
void *data)
 set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
 }
 
+static void serial_isa_initfn(Object *o)
+{
+ISASerialState *self = ISA_SERIAL(o);
+
+object_initialize_child(o, "serial", >state, sizeof(self->state),
+TYPE_SERIAL, _abort, NULL);
+}
+
 static const TypeInfo serial_isa_info = {
 .name  = TYPE_ISA_SERIAL,
 .parent= TYPE_ISA_DEVICE,
 .instance_size = sizeof(ISASerialState),
+.instance_init = serial_isa_initfn,
 .class_init= serial_isa_class_initfn,
 };
 
diff --git a/hw/char/serial-pci-multi.c b/hw/char/serial-pci-multi.c
index 6fa1cc6225..3485bdad87 100644
--- a/hw/char/serial-pci-multi.c
+++ b/hw/char/serial-pci-multi.c
@@ -182,10 +182,24 @@ static void multi_4x_serial_pci_class_initfn(ObjectClass 
*klass, void *data)
 set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
 }
 
+static void multi_serial_init(Object *o)
+{
+PCIDevice *dev = PCI_DEVICE(o);
+PCIMultiSerialState *self = DO_UPCAST(PCIMultiSerialState, dev, dev);
+int i, nr_ports = multi_serial_get_nr_ports(PCI_DEVICE_GET_CLASS(dev));
+
+for (i = 0; i < nr_ports; i++) {
+object_initialize_child(o, "serial[*]", >state[i],
+sizeof(self->state[i]),
+TYPE_SERIAL, _abort, NULL);
+}
+}
+
 static const TypeInfo multi_2x_serial_pci_info = {
 .name  = "pci-serial-2x",
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(PCIMultiSerialState),
+.instance_init = multi_serial_init,
 .class_init= multi_2x_serial_pci_class_initfn,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
@@ -197,6 +211,7 @@ static const TypeInfo multi_4x_serial_pci_info = {
 .name  = "pci-serial-4x",
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(PCIMultiSerialState),
+.instance_init = multi_serial_init,
 .class_init= multi_4x_serial_pci_class_initfn,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
diff --git a/hw/char/serial-pci.c b/hw/char/serial-pci.c
index cb9b76e22b..a33264a1fb 100644
--- a/hw/char/serial-pci.c
+++ b/hw/char/serial-pci.c
@@ -40,6 +40,8 @@ typedef struct PCISerialState {
 uint8_t prog_if;
 } PCISerialState;
 
+#define TYPE_PCI_SERIAL "pci-serial"
+#define PCI_SERIAL(s) OBJECT_CHECK(PCISerialState, (s), TYPE_PCI_SERIAL)
 
 static void serial_pci_realize(PCIDevice *dev, Error **errp)
 {
@@ -103,10 +105,19 @@ static void serial_pci_class_initfn(ObjectClass *klass, 
void *data)
 set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
 }
 
+static void serial_pci_init(Object *o)
+{
+PCISerialState *self = PCI_SERIAL(o);
+
+object_initialize_child(o, "serial", >state, sizeof(self->state),
+TYPE_SERIAL, _abort, NULL);
+}
+
 static const TypeInfo serial_pci_info = {
-.name  = "pci-serial",
+.name  = TYPE_PCI_SERIAL,
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(PCISerialState),
+.instance_init = serial_pci_init,
 .class_init= serial_pci_class_initfn,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
diff --git a/hw/char/serial.c b/hw/char/serial.c
index b4aa250950..c839035fdd 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -983,9 +983,8 @@ const MemoryRegionOps serial_io_ops = {
 SerialState *serial_init(int base, qemu_irq irq, int baudbase,
  Chardev *chr, MemoryRegion *system_io)
 {
-SerialState *s;
-
-s = g_malloc0(sizeof(SerialState));
+DeviceState *dev = DEVICE(object_new(TYPE_SERIAL));
+SerialState *s = SERIAL(dev);
 
 s->irq = irq;
 s->baudbase = baudbase;
@@ -993,6 +992,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
baudbase,
 serial_realize_core(s, _fatal);
 
 vmstate_register(NULL, base, _serial, s);
+qdev_init_nofail(dev);
 
 memory_region_init_io(>io, NULL, _io_ops, s, "serial", 8);
 

[PATCH v3 03/33] sysbus: remove outdated comment

2019-10-23 Thread Marc-André Lureau
The init callback is no more since commit
817a17fc60f44e29a1944b60d32f45ea127f0cf9 ("core/sysbus: remove the
SysBusDeviceClass::init path")

Signed-off-by: Marc-André Lureau 
---
 include/hw/sysbus.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 2eb0484388..c4a1c0adfa 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -24,10 +24,6 @@ typedef struct SysBusDevice SysBusDevice;
 
 /**
  * SysBusDeviceClass:
- * @init: Callback function invoked when the #DeviceState.realized property
- * is changed to %true. Deprecated, new types inheriting directly from
- * TYPE_SYS_BUS_DEVICE should use #DeviceClass.realize instead, new leaf
- * types should consult their respective parent type.
  *
  * SysBusDeviceClass is not overriding #DeviceClass.realize, so derived
  * classes overriding it are not required to invoke its implementation.
-- 
2.23.0.606.g08da6496b6




[PATCH v3 33/33] qdev: remove QDEV_PROP_PTR

2019-10-23 Thread Marc-André Lureau
No longer used in the tree. The comment about user_creatable is still
quite relevant, but there is already a similar comment in qdev-core.h.

Reviewed-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/core/qdev-properties.c| 18 --
 include/hw/qdev-properties.h | 22 --
 2 files changed, 40 deletions(-)

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index be4cb01f0b..6271169d7d 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -469,13 +469,6 @@ const PropertyInfo qdev_prop_string = {
 .set   = set_string,
 };
 
-/* --- pointer --- */
-
-/* Not a proper property, just for dirty hacks.  TODO Remove it!  */
-const PropertyInfo qdev_prop_ptr = {
-.name  = "ptr",
-};
-
 /* --- mac address --- */
 
 /*
@@ -1133,17 +1126,6 @@ void qdev_prop_set_enum(DeviceState *dev, const char 
*name, int value)
 name, _abort);
 }
 
-void qdev_prop_set_ptr(DeviceState *dev, const char *name, void *value)
-{
-Property *prop;
-void **ptr;
-
-prop = qdev_prop_find(dev, name);
-assert(prop && prop->info == _prop_ptr);
-ptr = qdev_get_prop_ptr(dev, prop);
-*ptr = value;
-}
-
 static GPtrArray *global_props(void)
 {
 static GPtrArray *gp;
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 5bba033b7b..a708c3870b 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -17,7 +17,6 @@ extern const PropertyInfo qdev_prop_size;
 extern const PropertyInfo qdev_prop_string;
 extern const PropertyInfo qdev_prop_chr;
 extern const PropertyInfo qdev_prop_tpm;
-extern const PropertyInfo qdev_prop_ptr;
 extern const PropertyInfo qdev_prop_macaddr;
 extern const PropertyInfo qdev_prop_on_off_auto;
 extern const PropertyInfo qdev_prop_losttickpolicy;
@@ -168,25 +167,6 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
 #define DEFINE_PROP_PCI_DEVFN(_n, _s, _f, _d)   \
 DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_pci_devfn, int32_t)
 
-/*
- * Please avoid pointer properties.  If you must use them, you must
- * cover them in their device's class init function as follows:
- *
- * - If the property must be set, the device cannot be used with
- *   device_add, so add code like this:
- *   |* Reason: pointer property "NAME-OF-YOUR-PROP" *|
- *   DeviceClass *dc = DEVICE_CLASS(class);
- *   dc->user_creatable = false;
- *
- * - If the property may safely remain null, document it like this:
- *   |*
- ** Note: pointer property "interrupt_vector" may remain null, thus
- ** no need for dc->user_creatable = false;
- **|
- */
-#define DEFINE_PROP_PTR(_n, _s, _f) \
-DEFINE_PROP(_n, _s, _f, qdev_prop_ptr, void*)
-
 #define DEFINE_PROP_CHR(_n, _s, _f) \
 DEFINE_PROP(_n, _s, _f, qdev_prop_chr, CharBackend)
 #define DEFINE_PROP_STRING(_n, _s, _f) \
@@ -259,8 +239,6 @@ void qdev_prop_set_drive(DeviceState *dev, const char *name,
 void qdev_prop_set_macaddr(DeviceState *dev, const char *name,
const uint8_t *value);
 void qdev_prop_set_enum(DeviceState *dev, const char *name, int value);
-/* FIXME: Remove opaque pointer properties.  */
-void qdev_prop_set_ptr(DeviceState *dev, const char *name, void *value);
 
 void qdev_prop_register_global(GlobalProperty *prop);
 int qdev_prop_check_globals(void);
-- 
2.23.0.606.g08da6496b6




[PATCH v3 02/33] sysbus: remove unused sysbus_try_create*

2019-10-23 Thread Marc-André Lureau
Signed-off-by: Marc-André Lureau 
---
 hw/core/sysbus.c| 32 
 hw/i386/pc.c|  1 -
 include/hw/sysbus.h |  9 +
 3 files changed, 1 insertion(+), 41 deletions(-)

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 9e69c83aed..08b0311c5f 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -250,38 +250,6 @@ DeviceState *sysbus_create_varargs(const char *name,
 return dev;
 }
 
-DeviceState *sysbus_try_create_varargs(const char *name,
-   hwaddr addr, ...)
-{
-DeviceState *dev;
-SysBusDevice *s;
-va_list va;
-qemu_irq irq;
-int n;
-
-dev = qdev_try_create(NULL, name);
-if (!dev) {
-return NULL;
-}
-s = SYS_BUS_DEVICE(dev);
-qdev_init_nofail(dev);
-if (addr != (hwaddr)-1) {
-sysbus_mmio_map(s, 0, addr);
-}
-va_start(va, addr);
-n = 0;
-while (1) {
-irq = va_arg(va, qemu_irq);
-if (!irq) {
-break;
-}
-sysbus_connect_irq(s, n, irq);
-n++;
-}
-va_end(va);
-return dev;
-}
-
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
 SysBusDevice *s = SYS_BUS_DEVICE(dev);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 4b1904237e..00ee16ccab 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1902,7 +1902,6 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
  * when the HPET wants to take over. Thus we have to disable the latter.
  */
 if (!no_hpet && (!kvm_irqchip_in_kernel() || kvm_has_pit_state2())) {
-/* In order to set property, here not using sysbus_try_create_simple */
 hpet = qdev_try_create(NULL, TYPE_HPET);
 if (hpet) {
 /* For pc-piix-*, hpet's intcap is always IRQ2. For pc-q35-1.7
diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 27e80881da..2eb0484388 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -117,8 +117,7 @@ void foreach_dynamic_sysbus_device(FindSysbusDeviceFunc 
*func, void *opaque);
 /* Legacy helper function for creating devices.  */
 DeviceState *sysbus_create_varargs(const char *name,
  hwaddr addr, ...);
-DeviceState *sysbus_try_create_varargs(const char *name,
-   hwaddr addr, ...);
+
 static inline DeviceState *sysbus_create_simple(const char *name,
   hwaddr addr,
   qemu_irq irq)
@@ -126,11 +125,5 @@ static inline DeviceState *sysbus_create_simple(const char 
*name,
 return sysbus_create_varargs(name, addr, irq, NULL);
 }
 
-static inline DeviceState *sysbus_try_create_simple(const char *name,
-hwaddr addr,
-qemu_irq irq)
-{
-return sysbus_try_create_varargs(name, addr, irq, NULL);
-}
 
 #endif /* HW_SYSBUS_H */
-- 
2.23.0.606.g08da6496b6




[PATCH v3 30/33] omap-i2c: remove PROP_PTR

2019-10-23 Thread Marc-André Lureau
Since clocks are not QOM objects, replace PROP_PTR of clocks with
setters methods.

Reviewed-by: Peter Maydell 
Reviewed-by: Corey Minyard 
Signed-off-by: Marc-André Lureau 
---
 hw/arm/omap1.c|  2 +-
 hw/arm/omap2.c|  8 
 hw/i2c/omap_i2c.c | 19 ---
 include/hw/arm/omap.h | 13 +
 4 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index 1afd1d3d7f..807e5f70d1 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -4030,7 +4030,7 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*dram,
 
 s->i2c[0] = qdev_create(NULL, "omap_i2c");
 qdev_prop_set_uint8(s->i2c[0], "revision", 0x11);
-qdev_prop_set_ptr(s->i2c[0], "fclk", omap_findclk(s, "mpuper_ck"));
+omap_i2c_set_fclk(OMAP_I2C(s->i2c[0]), omap_findclk(s, "mpuper_ck"));
 qdev_init_nofail(s->i2c[0]);
 busdev = SYS_BUS_DEVICE(s->i2c[0]);
 sysbus_connect_irq(busdev, 0, qdev_get_gpio_in(s->ih[1], OMAP_INT_I2C));
diff --git a/hw/arm/omap2.c b/hw/arm/omap2.c
index 1d7cc435ef..171e2d0472 100644
--- a/hw/arm/omap2.c
+++ b/hw/arm/omap2.c
@@ -2425,8 +2425,8 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion 
*sdram,
 
 s->i2c[0] = qdev_create(NULL, "omap_i2c");
 qdev_prop_set_uint8(s->i2c[0], "revision", 0x34);
-qdev_prop_set_ptr(s->i2c[0], "iclk", omap_findclk(s, "i2c1.iclk"));
-qdev_prop_set_ptr(s->i2c[0], "fclk", omap_findclk(s, "i2c1.fclk"));
+omap_i2c_set_iclk(OMAP_I2C(s->i2c[0]), omap_findclk(s, "i2c1.iclk"));
+omap_i2c_set_fclk(OMAP_I2C(s->i2c[0]), omap_findclk(s, "i2c1.fclk"));
 qdev_init_nofail(s->i2c[0]);
 busdev = SYS_BUS_DEVICE(s->i2c[0]);
 sysbus_connect_irq(busdev, 0,
@@ -2437,8 +2437,8 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion 
*sdram,
 
 s->i2c[1] = qdev_create(NULL, "omap_i2c");
 qdev_prop_set_uint8(s->i2c[1], "revision", 0x34);
-qdev_prop_set_ptr(s->i2c[1], "iclk", omap_findclk(s, "i2c2.iclk"));
-qdev_prop_set_ptr(s->i2c[1], "fclk", omap_findclk(s, "i2c2.fclk"));
+omap_i2c_set_iclk(OMAP_I2C(s->i2c[1]), omap_findclk(s, "i2c2.iclk"));
+omap_i2c_set_fclk(OMAP_I2C(s->i2c[1]), omap_findclk(s, "i2c2.fclk"));
 qdev_init_nofail(s->i2c[1]);
 busdev = SYS_BUS_DEVICE(s->i2c[1]);
 sysbus_connect_irq(busdev, 0,
diff --git a/hw/i2c/omap_i2c.c b/hw/i2c/omap_i2c.c
index 3ba965a58f..3ccbd5cc2c 100644
--- a/hw/i2c/omap_i2c.c
+++ b/hw/i2c/omap_i2c.c
@@ -28,10 +28,7 @@
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 
-#define TYPE_OMAP_I2C "omap_i2c"
-#define OMAP_I2C(obj) OBJECT_CHECK(OMAPI2CState, (obj), TYPE_OMAP_I2C)
-
-typedef struct OMAPI2CState {
+struct OMAPI2CState {
 SysBusDevice parent_obj;
 
 MemoryRegion iomem;
@@ -56,7 +53,7 @@ typedef struct OMAPI2CState {
 uint8_t divider;
 uint8_t times[2];
 uint16_t test;
-} OMAPI2CState;
+};
 
 #define OMAP2_INTR_REV 0x34
 #define OMAP2_GC_REV   0x34
@@ -504,10 +501,18 @@ static void omap_i2c_realize(DeviceState *dev, Error 
**errp)
 }
 }
 
+void omap_i2c_set_iclk(OMAPI2CState *i2c, omap_clk clk)
+{
+i2c->iclk = clk;
+}
+
+void omap_i2c_set_fclk(OMAPI2CState *i2c, omap_clk clk)
+{
+i2c->fclk = clk;
+}
+
 static Property omap_i2c_properties[] = {
 DEFINE_PROP_UINT8("revision", OMAPI2CState, revision, 0),
-DEFINE_PROP_PTR("iclk", OMAPI2CState, iclk),
-DEFINE_PROP_PTR("fclk", OMAPI2CState, fclk),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/arm/omap.h b/include/hw/arm/omap.h
index bcecf19f89..39a295ba20 100644
--- a/include/hw/arm/omap.h
+++ b/include/hw/arm/omap.h
@@ -81,6 +81,19 @@ typedef struct omap_intr_handler_s omap_intr_handler;
 void omap_intc_set_iclk(omap_intr_handler *intc, omap_clk clk);
 void omap_intc_set_fclk(omap_intr_handler *intc, omap_clk clk);
 
+/* omap_i2c.c */
+#define TYPE_OMAP_I2C "omap_i2c"
+#define OMAP_I2C(obj) OBJECT_CHECK(OMAPI2CState, (obj), TYPE_OMAP_I2C)
+
+typedef struct OMAPI2CState OMAPI2CState;
+
+/*
+ * TODO: Ideally we should have a clock framework that
+ * let us wire these clocks up with QOM properties or links.
+ */
+void omap_i2c_set_iclk(OMAPI2CState *i2c, omap_clk clk);
+void omap_i2c_set_fclk(OMAPI2CState *i2c, omap_clk clk);
+
 /* OMAP2 l4 Interconnect */
 struct omap_l4_s;
 struct omap_l4_region_s {
-- 
2.23.0.606.g08da6496b6




[PATCH v3 01/33] qdev: remove unused qdev_prop_int64

2019-10-23 Thread Marc-André Lureau
Signed-off-by: Marc-André Lureau 
---
 hw/core/qdev-properties.c| 32 
 include/hw/qdev-properties.h |  3 ---
 2 files changed, 35 deletions(-)

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index ac28890e5a..be4cb01f0b 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -409,31 +409,6 @@ static void set_uint64(Object *obj, Visitor *v, const char 
*name,
 visit_type_uint64(v, name, ptr, errp);
 }
 
-static void get_int64(Object *obj, Visitor *v, const char *name,
-  void *opaque, Error **errp)
-{
-DeviceState *dev = DEVICE(obj);
-Property *prop = opaque;
-int64_t *ptr = qdev_get_prop_ptr(dev, prop);
-
-visit_type_int64(v, name, ptr, errp);
-}
-
-static void set_int64(Object *obj, Visitor *v, const char *name,
-  void *opaque, Error **errp)
-{
-DeviceState *dev = DEVICE(obj);
-Property *prop = opaque;
-int64_t *ptr = qdev_get_prop_ptr(dev, prop);
-
-if (dev->realized) {
-qdev_prop_set_after_realize(dev, name, errp);
-return;
-}
-
-visit_type_int64(v, name, ptr, errp);
-}
-
 const PropertyInfo qdev_prop_uint64 = {
 .name  = "uint64",
 .get   = get_uint64,
@@ -441,13 +416,6 @@ const PropertyInfo qdev_prop_uint64 = {
 .set_default_value = set_default_value_uint,
 };
 
-const PropertyInfo qdev_prop_int64 = {
-.name  = "int64",
-.get   = get_int64,
-.set   = set_int64,
-.set_default_value = set_default_value_int,
-};
-
 /* --- string --- */
 
 static void release_string(Object *obj, const char *name, void *opaque)
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index c6a8cb5516..690ff07ae2 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -13,7 +13,6 @@ extern const PropertyInfo qdev_prop_uint16;
 extern const PropertyInfo qdev_prop_uint32;
 extern const PropertyInfo qdev_prop_int32;
 extern const PropertyInfo qdev_prop_uint64;
-extern const PropertyInfo qdev_prop_int64;
 extern const PropertyInfo qdev_prop_size;
 extern const PropertyInfo qdev_prop_string;
 extern const PropertyInfo qdev_prop_chr;
@@ -164,8 +163,6 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
 DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_int32, int32_t)
 #define DEFINE_PROP_UINT64(_n, _s, _f, _d)  \
 DEFINE_PROP_UNSIGNED(_n, _s, _f, _d, qdev_prop_uint64, uint64_t)
-#define DEFINE_PROP_INT64(_n, _s, _f, _d)  \
-DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_int64, int64_t)
 #define DEFINE_PROP_SIZE(_n, _s, _f, _d)   \
 DEFINE_PROP_UNSIGNED(_n, _s, _f, _d, qdev_prop_size, uint64_t)
 #define DEFINE_PROP_PCI_DEVFN(_n, _s, _f, _d)   \
-- 
2.23.0.606.g08da6496b6




Re: [PATCH v6 1/4] block/replication.c: Ignore requests after failover

2019-10-23 Thread Lukas Straub
On Wed, 23 Oct 2019 14:49:29 +0200
Max Reitz  wrote:

> On 05.10.19 15:05, Lukas Straub wrote:
> > After failover the Secondary side of replication shouldn't change state, 
> > because
> > it now functions as our primary disk.
> > 
> > In replication_start, replication_do_checkpoint, replication_stop, ignore
> > the request if current state is BLOCK_REPLICATION_DONE (sucessful failover) 
> > or
> > BLOCK_REPLICATION_FAILOVER (failover in progres i.e. currently merging 
> > active
> > and hidden images into the base image).
> > 
> > Signed-off-by: Lukas Straub 
> > Reviewed-by: Zhang Chen 
> > ---
> >  block/replication.c | 38 +++---
> >  1 file changed, 35 insertions(+), 3 deletions(-)  
> 
> Disclaimer: I don’t know anything about the replication block driver.
> 
> > diff --git a/block/replication.c b/block/replication.c
> > index 3d4dedddfc..97cc65c0cf 100644
> > --- a/block/replication.c
> > +++ b/block/replication.c  
> 
> [...]
> 
> > @@ -529,8 +540,7 @@ static void replication_start(ReplicationState *rs, 
> > ReplicationMode mode,
> > "Block device is in use by internal backup job");
> > 
> >  top_bs = bdrv_lookup_bs(s->top_id, s->top_id, NULL);
> > -if (!top_bs || !bdrv_is_root_node(top_bs) ||
> > -!check_top_bs(top_bs, bs)) {
> > +if (!top_bs || !check_top_bs(top_bs, bs)) {  
> 
> It appears to me that top_bs is only used to install op blockers.  It
> seems reasonable to require a root node to be able to do so (because op
> blockers are really only checked on a root node).
> (And the commit message doesn’t tell why we’d want to drop the
> is_root_node check here.)
> 
> Now OTOH I don’t know whether the replication driver needs an op blocker
> at all or whether the permission system suffices...

Hi,
Now that I look at again, it actually works without this change, by passing
a correct top-id= parameter to the driver (I somehow overlooked that 
parameter). 
So I will revert this change in the next version.

> 
> I suppose the rest of this patch is not really about the block layer, so
> I can’t really comment on it.  (It looks OK to me from a generic and
> naïve standpoint, though.)
> 
> >  error_setg(errp, "No top_bs or it is invalid");
> >  reopen_backing_file(bs, false, NULL);
> >  aio_context_release(aio_context);  
> 
> [...]
> 
> > @@ -593,7 +614,7 @@ static void replication_get_error(ReplicationState *rs, 
> > Error **errp)
> >  aio_context_acquire(aio_context);
> >  s = bs->opaque;
> > 
> > -if (s->stage != BLOCK_REPLICATION_RUNNING) {
> > +if (s->stage == BLOCK_REPLICATION_NONE) {  
> 
> Just one question out of curiosity, though: Is this a bug fix?

No, It only applies to continuous replication, because colo will
check all replication nodes for errors before checkpointing. So
a secondary continuing replication would error out here, because
it is either in state BLOCK_REPLICATION_DONE or 
BLOCK_REPLICATION_FAILOVER.

> Max
> 
> >  error_setg(errp, "Block replication is not running");
> >  aio_context_release(aio_context);
> >  return;  
> 




[PATCH v3 28/33] smbus-eeprom: remove PROP_PTR

2019-10-23 Thread Marc-André Lureau
Instead, set the initial data field directly.

(the initial data is an array of 256 bytes. As I don't know if it may
change over time, I keep the pointer to original buffer as is, but it
might be worth to consider to copy it instead)

Signed-off-by: Marc-André Lureau 
---
 hw/i2c/smbus_eeprom.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
index 54c86a0112..533c728b3b 100644
--- a/hw/i2c/smbus_eeprom.c
+++ b/hw/i2c/smbus_eeprom.c
@@ -44,7 +44,7 @@
 typedef struct SMBusEEPROMDevice {
 SMBusDevice smbusdev;
 uint8_t data[SMBUS_EEPROM_SIZE];
-void *init_data;
+uint8_t *init_data;
 uint8_t offset;
 bool accessed;
 } SMBusEEPROMDevice;
@@ -129,14 +129,14 @@ static void smbus_eeprom_reset(DeviceState *dev)
 
 static void smbus_eeprom_realize(DeviceState *dev, Error **errp)
 {
+SMBusEEPROMDevice *eeprom = SMBUS_EEPROM(dev);
+
 smbus_eeprom_reset(dev);
+if (eeprom->init_data == NULL) {
+error_setg(errp, "init_data cannot be NULL");
+}
 }
 
-static Property smbus_eeprom_properties[] = {
-DEFINE_PROP_PTR("data", SMBusEEPROMDevice, init_data),
-DEFINE_PROP_END_OF_LIST(),
-};
-
 static void smbus_eeprom_class_initfn(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -146,9 +146,8 @@ static void smbus_eeprom_class_initfn(ObjectClass *klass, 
void *data)
 dc->reset = smbus_eeprom_reset;
 sc->receive_byte = eeprom_receive_byte;
 sc->write_data = eeprom_write_data;
-dc->props = smbus_eeprom_properties;
 dc->vmsd = _smbus_eeprom;
-/* Reason: pointer property "data" */
+/* Reason: init_data */
 dc->user_creatable = false;
 }
 
@@ -172,7 +171,7 @@ void smbus_eeprom_init_one(I2CBus *smbus, uint8_t address, 
uint8_t *eeprom_buf)
 
 dev = qdev_create((BusState *) smbus, TYPE_SMBUS_EEPROM);
 qdev_prop_set_uint8(dev, "address", address);
-qdev_prop_set_ptr(dev, "data", eeprom_buf);
+SMBUS_EEPROM(dev)->init_data = eeprom_buf;
 qdev_init_nofail(dev);
 }
 
-- 
2.23.0.606.g08da6496b6




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

2019-10-23 Thread Michael Rolnik
Hi Aleksandar.

I am fixing flag C and I will make flag Z to be like the others, just once
bit

Sent from my cell phone, please ignore typos

On Tue, Oct 22, 2019, 1:37 AM 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 
> ---
>  gdb-xml/avr-cpu.xml|  49 
>  target/avr/cpu-param.h |  37 +++
>  target/avr/cpu-qom.h   |  54 
>  target/avr/cpu.c   | 576 +
>  target/avr/cpu.h   | 254 ++
>  target/avr/gdbstub.c   |  85 ++
>  target/avr/machine.c   | 121 +
>  7 files changed, 1176 insertions(+)
>  create mode 100644 gdb-xml/avr-cpu.xml
>  create mode 100644 target/avr/cpu-param.h
>  create mode 100644 target/avr/cpu-qom.h
>  create mode 100644 target/avr/cpu.c
>  create mode 100644 target/avr/cpu.h
>  create mode 100644 target/avr/gdbstub.c
>  create mode 100644 target/avr/machine.c
>
> diff --git a/gdb-xml/avr-cpu.xml b/gdb-xml/avr-cpu.xml
> new file mode 100644
> index 00..c4747f5b40
> --- /dev/null
> +++ b/gdb-xml/avr-cpu.xml
> @@ -0,0 +1,49 @@
> +
> +
> +
> +
> +
> +
> +
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +
> 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.c 

[PATCH v3 29/33] omap-intc: remove PROP_PTR

2019-10-23 Thread Marc-André Lureau
Since clocks are not QOM objects, replace PROP_PTR of clocks with
setters methods.

(in theory there should probably be different methods for omap1 &
omap2 intc, but this is left as a future improvement)

Reviewed-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/arm/omap1.c|  4 ++--
 hw/arm/omap2.c|  4 ++--
 hw/intc/omap_intc.c   | 17 ++---
 include/hw/arm/omap.h | 14 ++
 4 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index 6ce038a453..1afd1d3d7f 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -3889,7 +3889,7 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*dram,
 
 s->ih[0] = qdev_create(NULL, "omap-intc");
 qdev_prop_set_uint32(s->ih[0], "size", 0x100);
-qdev_prop_set_ptr(s->ih[0], "clk", omap_findclk(s, "arminth_ck"));
+omap_intc_set_iclk(OMAP_INTC(s->ih[0]), omap_findclk(s, "arminth_ck"));
 qdev_init_nofail(s->ih[0]);
 busdev = SYS_BUS_DEVICE(s->ih[0]);
 sysbus_connect_irq(busdev, 0,
@@ -3899,7 +3899,7 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*dram,
 sysbus_mmio_map(busdev, 0, 0xfffecb00);
 s->ih[1] = qdev_create(NULL, "omap-intc");
 qdev_prop_set_uint32(s->ih[1], "size", 0x800);
-qdev_prop_set_ptr(s->ih[1], "clk", omap_findclk(s, "arminth_ck"));
+omap_intc_set_iclk(OMAP_INTC(s->ih[1]), omap_findclk(s, "arminth_ck"));
 qdev_init_nofail(s->ih[1]);
 busdev = SYS_BUS_DEVICE(s->ih[1]);
 sysbus_connect_irq(busdev, 0,
diff --git a/hw/arm/omap2.c b/hw/arm/omap2.c
index 457f152bac..1d7cc435ef 100644
--- a/hw/arm/omap2.c
+++ b/hw/arm/omap2.c
@@ -2308,8 +2308,8 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion 
*sdram,
 /* Actually mapped at any 2K boundary in the ARM11 private-peripheral if */
 s->ih[0] = qdev_create(NULL, "omap2-intc");
 qdev_prop_set_uint8(s->ih[0], "revision", 0x21);
-qdev_prop_set_ptr(s->ih[0], "fclk", omap_findclk(s, "mpu_intc_fclk"));
-qdev_prop_set_ptr(s->ih[0], "iclk", omap_findclk(s, "mpu_intc_iclk"));
+omap_intc_set_fclk(OMAP_INTC(s->ih[0]), omap_findclk(s, "mpu_intc_fclk"));
+omap_intc_set_iclk(OMAP_INTC(s->ih[0]), omap_findclk(s, "mpu_intc_iclk"));
 qdev_init_nofail(s->ih[0]);
 busdev = SYS_BUS_DEVICE(s->ih[0]);
 sysbus_connect_irq(busdev, 0,
diff --git a/hw/intc/omap_intc.c b/hw/intc/omap_intc.c
index 854b709ca0..73bb1c2af4 100644
--- a/hw/intc/omap_intc.c
+++ b/hw/intc/omap_intc.c
@@ -38,10 +38,6 @@ struct omap_intr_handler_bank_s {
 unsigned char priority[32];
 };
 
-#define TYPE_OMAP_INTC "common-omap-intc"
-#define OMAP_INTC(obj) \
-OBJECT_CHECK(struct omap_intr_handler_s, (obj), TYPE_OMAP_INTC)
-
 struct omap_intr_handler_s {
 SysBusDevice parent_obj;
 
@@ -391,9 +387,18 @@ static void omap_intc_realize(DeviceState *dev, Error 
**errp)
 }
 }
 
+void omap_intc_set_iclk(omap_intr_handler *intc, omap_clk clk)
+{
+intc->iclk = clk;
+}
+
+void omap_intc_set_fclk(omap_intr_handler *intc, omap_clk clk)
+{
+intc->fclk = clk;
+}
+
 static Property omap_intc_properties[] = {
 DEFINE_PROP_UINT32("size", struct omap_intr_handler_s, size, 0x100),
-DEFINE_PROP_PTR("clk", struct omap_intr_handler_s, iclk),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -647,8 +652,6 @@ static void omap2_intc_realize(DeviceState *dev, Error 
**errp)
 static Property omap2_intc_properties[] = {
 DEFINE_PROP_UINT8("revision", struct omap_intr_handler_s,
 revision, 0x21),
-DEFINE_PROP_PTR("iclk", struct omap_intr_handler_s, iclk),
-DEFINE_PROP_PTR("fclk", struct omap_intr_handler_s, fclk),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/arm/omap.h b/include/hw/arm/omap.h
index f3aa670036..bcecf19f89 100644
--- a/include/hw/arm/omap.h
+++ b/include/hw/arm/omap.h
@@ -67,6 +67,20 @@ void omap_clk_setrate(omap_clk clk, int divide, int 
multiply);
 int64_t omap_clk_getrate(omap_clk clk);
 void omap_clk_reparent(omap_clk clk, omap_clk parent);
 
+/* omap_intc.c */
+#define TYPE_OMAP_INTC "common-omap-intc"
+#define OMAP_INTC(obj)  \
+OBJECT_CHECK(omap_intr_handler, (obj), TYPE_OMAP_INTC)
+
+typedef struct omap_intr_handler_s omap_intr_handler;
+
+/*
+ * TODO: Ideally we should have a clock framework that
+ * let us wire these clocks up with QOM properties or links.
+ */
+void omap_intc_set_iclk(omap_intr_handler *intc, omap_clk clk);
+void omap_intc_set_fclk(omap_intr_handler *intc, omap_clk clk);
+
 /* OMAP2 l4 Interconnect */
 struct omap_l4_s;
 struct omap_l4_region_s {
-- 
2.23.0.606.g08da6496b6




[PATCH v3 27/33] cris: improve passing PIC interrupt vector to the CPU

2019-10-23 Thread Marc-André Lureau
Instead of accessing cpu interrupt vector directly from PIC, send the
vector value over the qemu_irq.

Suggested-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/cris/axis_dev88.c  |  4 
 hw/intc/etraxfs_pic.c | 26 +-
 target/cris/cpu.c |  8 
 target/cris/cpu.h |  1 +
 4 files changed, 10 insertions(+), 29 deletions(-)

diff --git a/hw/cris/axis_dev88.c b/hw/cris/axis_dev88.c
index 940c7dd122..be7760476a 100644
--- a/hw/cris/axis_dev88.c
+++ b/hw/cris/axis_dev88.c
@@ -253,7 +253,6 @@ void axisdev88_init(MachineState *machine)
 const char *kernel_filename = machine->kernel_filename;
 const char *kernel_cmdline = machine->kernel_cmdline;
 CRISCPU *cpu;
-CPUCRISState *env;
 DeviceState *dev;
 SysBusDevice *s;
 DriveInfo *nand;
@@ -267,7 +266,6 @@ void axisdev88_init(MachineState *machine)
 
 /* init CPUs */
 cpu = CRIS_CPU(cpu_create(machine->cpu_type));
-env = >env;
 
 /* allocate RAM */
 memory_region_allocate_system_memory(phys_ram, NULL, "axisdev88.ram",
@@ -297,8 +295,6 @@ void axisdev88_init(MachineState *machine)
 
 
 dev = qdev_create(NULL, "etraxfs,pic");
-/* FIXME: Is there a proper way to signal vectors to the CPU core?  */
-qdev_prop_set_ptr(dev, "interrupt_vector", >interrupt_vector);
 qdev_init_nofail(dev);
 s = SYS_BUS_DEVICE(dev);
 sysbus_mmio_map(s, 0, 0x3001c000);
diff --git a/hw/intc/etraxfs_pic.c b/hw/intc/etraxfs_pic.c
index 77f652acec..12988c7aa9 100644
--- a/hw/intc/etraxfs_pic.c
+++ b/hw/intc/etraxfs_pic.c
@@ -27,8 +27,6 @@
 #include "qemu/module.h"
 #include "hw/irq.h"
 #include "hw/qdev-properties.h"
-//#include "pc.h"
-//#include "etraxfs.h"
 
 #define D(x)
 
@@ -48,7 +46,6 @@ struct etrax_pic
 SysBusDevice parent_obj;
 
 MemoryRegion mmio;
-void *interrupt_vector;
 qemu_irq parent_irq;
 qemu_irq parent_nmi;
 uint32_t regs[R_MAX];
@@ -79,11 +76,7 @@ static void pic_update(struct etrax_pic *fs)
 }
 }
 
-if (fs->interrupt_vector) {
-/* hack alert: ptr property */
-*(uint32_t*)(fs->interrupt_vector) = vector;
-}
-qemu_set_irq(fs->parent_irq, !!vector);
+qemu_set_irq(fs->parent_irq, vector);
 }
 
 static uint64_t
@@ -163,28 +156,11 @@ static void etraxfs_pic_init(Object *obj)
 sysbus_init_mmio(sbd, >mmio);
 }
 
-static Property etraxfs_pic_properties[] = {
-DEFINE_PROP_PTR("interrupt_vector", struct etrax_pic, interrupt_vector),
-DEFINE_PROP_END_OF_LIST(),
-};
-
-static void etraxfs_pic_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-
-dc->props = etraxfs_pic_properties;
-/*
- * Note: pointer property "interrupt_vector" may remain null, thus
- * no need for dc->user_creatable = false;
- */
-}
-
 static const TypeInfo etraxfs_pic_info = {
 .name  = TYPE_ETRAX_FS_PIC,
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(struct etrax_pic),
 .instance_init = etraxfs_pic_init,
-.class_init= etraxfs_pic_class_init,
 };
 
 static void etraxfs_pic_register_types(void)
diff --git a/target/cris/cpu.c b/target/cris/cpu.c
index 7adfd6caf4..6a857f548d 100644
--- a/target/cris/cpu.c
+++ b/target/cris/cpu.c
@@ -147,6 +147,14 @@ static void cris_cpu_set_irq(void *opaque, int irq, int 
level)
 CPUState *cs = CPU(cpu);
 int type = irq == CRIS_CPU_IRQ ? CPU_INTERRUPT_HARD : CPU_INTERRUPT_NMI;
 
+if (irq == CRIS_CPU_IRQ) {
+/*
+ * The PIC passes us the vector for the IRQ as the value it sends
+ * over the qemu_irq line
+ */
+cpu->env.interrupt_vector = level;
+}
+
 if (level) {
 cpu_interrupt(cs, type);
 } else {
diff --git a/target/cris/cpu.h b/target/cris/cpu.h
index aba0a66474..a7c2a8e15b 100644
--- a/target/cris/cpu.h
+++ b/target/cris/cpu.h
@@ -34,6 +34,7 @@
 #define CPU_INTERRUPT_NMI   CPU_INTERRUPT_TGT_EXT_3
 
 /* CRUS CPU device objects interrupt lines.  */
+/* PIC passes the vector for the IRQ as the value of it sends over qemu_irq */
 #define CRIS_CPU_IRQ 0
 #define CRIS_CPU_NMI 1
 
-- 
2.23.0.606.g08da6496b6




[PATCH v3 22/33] etraxfs: remove PROP_PTR usage

2019-10-23 Thread Marc-André Lureau
etraxfs_dma_client are not Object, so can't be exposed to user with
QOM path. Let's remove property usage and move the constructor to the
.c unit, simplifying some code on the way.

Signed-off-by: Marc-André Lureau 
---
 hw/net/etraxfs_eth.c  | 44 +--
 include/hw/cris/etraxfs.h | 20 +++---
 2 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/hw/net/etraxfs_eth.c b/hw/net/etraxfs_eth.c
index 4cfbf1135a..f30d963487 100644
--- a/hw/net/etraxfs_eth.c
+++ b/hw/net/etraxfs_eth.c
@@ -338,14 +338,8 @@ typedef struct ETRAXFSEthState
 uint8_t macaddr[2][6];
 uint32_t regs[FS_ETH_MAX_REGS];
 
-union {
-void *vdma_out;
-struct etraxfs_dma_client *dma_out;
-};
-union {
-void *vdma_in;
-struct etraxfs_dma_client *dma_in;
-};
+struct etraxfs_dma_client *dma_out;
+struct etraxfs_dma_client *dma_in;
 
 /* MDIO bus.  */
 struct qemu_mdio mdio_bus;
@@ -635,8 +629,6 @@ static void etraxfs_eth_realize(DeviceState *dev, Error 
**errp)
 
 static Property etraxfs_eth_properties[] = {
 DEFINE_PROP_UINT32("phyaddr", ETRAXFSEthState, phyaddr, 1),
-DEFINE_PROP_PTR("dma_out", ETRAXFSEthState, vdma_out),
-DEFINE_PROP_PTR("dma_in", ETRAXFSEthState, vdma_in),
 DEFINE_NIC_PROPERTIES(ETRAXFSEthState, conf),
 DEFINE_PROP_END_OF_LIST(),
 };
@@ -648,10 +640,40 @@ static void etraxfs_eth_class_init(ObjectClass *klass, 
void *data)
 dc->realize = etraxfs_eth_realize;
 dc->reset = etraxfs_eth_reset;
 dc->props = etraxfs_eth_properties;
-/* Reason: pointer properties "dma_out", "dma_in" */
+/* Reason: dma_out, dma_in are not user settable */
 dc->user_creatable = false;
 }
 
+
+/* Instantiate an ETRAXFS Ethernet MAC.  */
+DeviceState *
+etraxfs_eth_init(NICInfo *nd, hwaddr base, int phyaddr,
+ struct etraxfs_dma_client *dma_out,
+ struct etraxfs_dma_client *dma_in)
+{
+DeviceState *dev;
+qemu_check_nic_model(nd, "fseth");
+
+dev = qdev_create(NULL, "etraxfs-eth");
+qdev_set_nic_properties(dev, nd);
+qdev_prop_set_uint32(dev, "phyaddr", phyaddr);
+
+/*
+ * TODO: QOM design, define a QOM interface for "I am an etraxfs
+ * DMA client" (which replaces the current 'struct
+ * etraxfs_dma_client' ad-hoc interface), implement it on the
+ * ethernet device, and then have QOM link properties on the DMA
+ * controller device so that you can pass the interface
+ * implementations to it.
+ */
+ETRAX_FS_ETH(dev)->dma_out = dma_out;
+ETRAX_FS_ETH(dev)->dma_in = dma_in;
+qdev_init_nofail(dev);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+
+return dev;
+}
+
 static const TypeInfo etraxfs_eth_info = {
 .name  = TYPE_ETRAX_FS_ETH,
 .parent= TYPE_SYS_BUS_DEVICE,
diff --git a/include/hw/cris/etraxfs.h b/include/hw/cris/etraxfs.h
index aa146a2cd8..403e7f95e6 100644
--- a/include/hw/cris/etraxfs.h
+++ b/include/hw/cris/etraxfs.h
@@ -30,23 +30,9 @@
 #include "hw/qdev-properties.h"
 #include "hw/sysbus.h"
 
-/* Instantiate an ETRAXFS Ethernet MAC.  */
-static inline DeviceState *
-etraxfs_eth_init(NICInfo *nd, hwaddr base, int phyaddr,
- void *dma_out, void *dma_in)
-{
-DeviceState *dev;
-qemu_check_nic_model(nd, "fseth");
-
-dev = qdev_create(NULL, "etraxfs-eth");
-qdev_set_nic_properties(dev, nd);
-qdev_prop_set_uint32(dev, "phyaddr", phyaddr);
-qdev_prop_set_ptr(dev, "dma_out", dma_out);
-qdev_prop_set_ptr(dev, "dma_in", dma_in);
-qdev_init_nofail(dev);
-sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
-return dev;
-}
+DeviceState *etraxfs_eth_init(NICInfo *nd, hwaddr base, int phyaddr,
+  struct etraxfs_dma_client *dma_out,
+  struct etraxfs_dma_client *dma_in);
 
 static inline DeviceState *etraxfs_ser_create(hwaddr addr,
   qemu_irq irq,
-- 
2.23.0.606.g08da6496b6




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

2019-10-23 Thread Aleksandar Markovic
On Wednesday, October 23, 2019, Michael Rolnik  wrote:

> Hi Aleksandar.
>
> I am fixing flag C and I will make flag Z to be like the others, just once
> bit
>
> Sent from my cell phone, please ignore typos
>

No worries, thanks.

A.


>
> On Tue, Oct 22, 2019, 1:37 AM 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 
>> ---
>>  gdb-xml/avr-cpu.xml|  49 
>>  target/avr/cpu-param.h |  37 +++
>>  target/avr/cpu-qom.h   |  54 
>>  target/avr/cpu.c   | 576 +
>>  target/avr/cpu.h   | 254 ++
>>  target/avr/gdbstub.c   |  85 ++
>>  target/avr/machine.c   | 121 +
>>  7 files changed, 1176 insertions(+)
>>  create mode 100644 gdb-xml/avr-cpu.xml
>>  create mode 100644 target/avr/cpu-param.h
>>  create mode 100644 target/avr/cpu-qom.h
>>  create mode 100644 target/avr/cpu.c
>>  create mode 100644 target/avr/cpu.h
>>  create mode 100644 target/avr/gdbstub.c
>>  create mode 100644 target/avr/machine.c
>>
>> diff --git a/gdb-xml/avr-cpu.xml b/gdb-xml/avr-cpu.xml
>> new file mode 100644
>> index 00..c4747f5b40
>> --- /dev/null
>> +++ b/gdb-xml/avr-cpu.xml
>> @@ -0,0 +1,49 @@
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +  
>> +
>> 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 >*/
>> 

[PATCH v3 20/33] vmmouse: replace PROP_PTR with PROP_LINK

2019-10-23 Thread Marc-André Lureau
While at it, use the expected type.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
 hw/i386/pc.c | 6 +++---
 hw/i386/vmmouse.c| 8 +++-
 hw/input/pckbd.c | 8 +++-
 include/hw/input/i8042.h | 4 +++-
 4 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 00ee16ccab..021ec8c593 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1861,9 +1861,9 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl, bool no_vmport)
 vmmouse = NULL;
 }
 if (vmmouse) {
-DeviceState *dev = DEVICE(vmmouse);
-qdev_prop_set_ptr(dev, "ps2_mouse", i8042);
-qdev_init_nofail(dev);
+object_property_set_link(OBJECT(vmmouse), OBJECT(i8042),
+ "i8042", _abort);
+qdev_init_nofail(DEVICE(vmmouse));
 }
 port92 = isa_create_simple(isa_bus, "port92");
 
diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c
index 41ad91ad53..c0c329f817 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -66,7 +66,7 @@ typedef struct VMMouseState
 uint16_t status;
 uint8_t absolute;
 QEMUPutMouseEntry *entry;
-void *ps2_mouse;
+ISAKBDState *i8042;
 } VMMouseState;
 
 static uint32_t vmmouse_get_status(VMMouseState *s)
@@ -105,7 +105,7 @@ static void vmmouse_mouse_event(void *opaque, int x, int y, 
int dz, int buttons_
 
 /* need to still generate PS2 events to notify driver to
read from queue */
-i8042_isa_mouse_fake_event(s->ps2_mouse);
+i8042_isa_mouse_fake_event(s->i8042);
 }
 
 static void vmmouse_remove_handler(VMMouseState *s)
@@ -275,7 +275,7 @@ static void vmmouse_realizefn(DeviceState *dev, Error 
**errp)
 }
 
 static Property vmmouse_properties[] = {
-DEFINE_PROP_PTR("ps2_mouse", VMMouseState, ps2_mouse),
+DEFINE_PROP_LINK("i8042", VMMouseState, i8042, TYPE_I8042, ISAKBDState *),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -287,8 +287,6 @@ static void vmmouse_class_initfn(ObjectClass *klass, void 
*data)
 dc->reset = vmmouse_reset;
 dc->vmsd = _vmmouse;
 dc->props = vmmouse_properties;
-/* Reason: pointer property "ps2_mouse" */
-dc->user_creatable = false;
 }
 
 static const TypeInfo vmmouse_info = {
diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index f0acfd86f7..9b641021c9 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -483,17 +483,15 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
 
 #define I8042(obj) OBJECT_CHECK(ISAKBDState, (obj), TYPE_I8042)
 
-typedef struct ISAKBDState {
+struct ISAKBDState {
 ISADevice parent_obj;
 
 KBDState kbd;
 MemoryRegion io[2];
-} ISAKBDState;
+};
 
-void i8042_isa_mouse_fake_event(void *opaque)
+void i8042_isa_mouse_fake_event(ISAKBDState *isa)
 {
-ISADevice *dev = opaque;
-ISAKBDState *isa = I8042(dev);
 KBDState *s = >kbd;
 
 ps2_mouse_fake_event(s->mouse);
diff --git a/include/hw/input/i8042.h b/include/hw/input/i8042.h
index 246e6f3335..8eaebf50ce 100644
--- a/include/hw/input/i8042.h
+++ b/include/hw/input/i8042.h
@@ -14,10 +14,12 @@
 
 #define I8042_A20_LINE "a20"
 
+typedef struct ISAKBDState ISAKBDState;
+
 void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
MemoryRegion *region, ram_addr_t size,
hwaddr mask);
-void i8042_isa_mouse_fake_event(void *opaque);
+void i8042_isa_mouse_fake_event(ISAKBDState *isa);
 void i8042_setup_a20_line(ISADevice *dev, qemu_irq a20_out);
 
 #endif /* HW_INPUT_I8042_H */
-- 
2.23.0.606.g08da6496b6




[PATCH v3 19/33] sm501: make SerialMM a child, export chardev property

2019-10-23 Thread Marc-André Lureau
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 | 31 ++-
 hw/sh4/r2d.c   |  2 +-
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index 1f33c87e65..6efdf764c1 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,18 @@ 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);
+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 */
 }
 }
 
 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 +2001,19 @@ 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 *self = SYSBUS_SM501(o);
+SerialMM *s = >serial;
+
+sysbus_init_child_obj(o, "serial", s, sizeof(SerialMM), TYPE_SERIAL_MM);
+qdev_prop_set_int32(DEVICE(s), "instance-id", SM501_UART0);
+qdev_prop_set_uint8(DEVICE(s), "regshift", 2);
+qdev_prop_set_uint8(DEVICE(s), "endianness", DEVICE_LITTLE_ENDIAN);
+
+object_property_add_alias(o, "chardev", OBJECT(s), "chardev", 
_abort);
 }
 
 static const TypeInfo sm501_sysbus_info = {
@@ -2009,6 +2021,7 @@ static const TypeInfo sm501_sysbus_info = {
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(SM501SysBusState),
 .class_init= sm501_sysbus_class_init,
+.instance_init = sm501_sysbus_init,
 };
 
 #define TYPE_PCI_SM501 "sm501"
diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
index ee0840f380..72bb5285cc 100644
--- a/hw/sh4/r2d.c
+++ b/hw/sh4/r2d.c
@@ -272,7 +272,7 @@ static void r2d_init(MachineState *machine)
 busdev = SYS_BUS_DEVICE(dev);
 qdev_prop_set_uint32(dev, "vram-size", SM501_VRAM_SIZE);
 qdev_prop_set_uint32(dev, "base", 0x1000);
-qdev_prop_set_ptr(dev, "chr-state", serial_hd(2));
+qdev_prop_set_chr(dev, "chardev", serial_hd(2));
 qdev_init_nofail(dev);
 sysbus_mmio_map(busdev, 0, 0x1000);
 sysbus_mmio_map(busdev, 1, 0x13e0);
-- 
2.23.0.606.g08da6496b6




  1   2   3   4   >