Re: [Qemu-devel] [PATCH v4] virtio-blk: set correct config size for the host driver

[Stefan Hajnoczi]

On Tue, Feb 12, 2019 at 09:05:11PM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 13, 2019 at 09:48:57AM +0800, Changpeng Liu wrote:
> > Commit caa1ee43 "vhost-user-blk: add discard/write zeroes features
> > support" added fields to struct virtio_blk_config. This changes
> > the size of the config space and breaks migration from QEMU 3.1
> > and older:
> > 
> > qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x10 read: 41 
> > device: 1 cmask: ff wmask: 80 w1cmask:0
> > qemu-system-ppc64: Failed to load PCIDevice:config
> > qemu-system-ppc64: Failed to load virtio-blk:virtio
> > qemu-system-ppc64: error while loading state for instance 0x0 of device 
> > 'pci@8002000:01.0/virtio-blk'
> > qemu-system-ppc64: load of migration failed: Invalid argument
> > 
> > Since virtio-blk doesn't support the "discard" and "write zeroes"
> > features, it shouldn't even expose the associated fields in the
> > config space actually. Just include all fields up to num_queues to
> > match QEMU 3.1 and older.
> > 
> > Signed-off-by: Changpeng Liu 
> 
> 
> Reviewed-by: Michael S. Tsirkin 
> 
> Stefan, are you merging this?

Yes.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v4] virtio-blk: set correct config size for the host driver

[Stefan Hajnoczi]

On Wed, Feb 13, 2019 at 09:48:57AM +0800, Changpeng Liu wrote:
> Commit caa1ee43 "vhost-user-blk: add discard/write zeroes features
> support" added fields to struct virtio_blk_config. This changes
> the size of the config space and breaks migration from QEMU 3.1
> and older:
> 
> qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x10 read: 41 
> device: 1 cmask: ff wmask: 80 w1cmask:0
> qemu-system-ppc64: Failed to load PCIDevice:config
> qemu-system-ppc64: Failed to load virtio-blk:virtio
> qemu-system-ppc64: error while loading state for instance 0x0 of device 
> 'pci@8002000:01.0/virtio-blk'
> qemu-system-ppc64: load of migration failed: Invalid argument
> 
> Since virtio-blk doesn't support the "discard" and "write zeroes"
> features, it shouldn't even expose the associated fields in the
> config space actually. Just include all fields up to num_queues to
> match QEMU 3.1 and older.
> 
> Signed-off-by: Changpeng Liu 
> ---
>  hw/block/virtio-blk.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)

Stefano: Please rebase your DISCARD/WRITE_ZEROES series onto this and
check that the config space is correctly sized.  Machine types before
4.0 shouldn't have these fields so that the config space size remains
unchanged.

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC v1 1/3] intel_iommu: scalable mode emulation

[Peter Xu]

On Wed, Feb 13, 2019 at 03:38:55PM +0800, Yi Sun wrote:

[...]

> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index 8b72735..396ac8e 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -37,6 +37,34 @@
> > >  #include "kvm_i386.h"
> > >  #include "trace.h"
> > >  
> > > +#define vtd_devfn_check(devfn) ((devfn & VTD_DEVFN_CHECK_MASK) ? true : 
> > > false)
> > 
> > "vtd_devfn_check(devfn)" is merely as long as "devfn &
> > VTD_DEVFN_CHECK_MASK", isn't it? :)
> > 
> > I would just drop the macro.
> > 
> There are two places to call this macro. Is that valuable to keep it?

The point here is "A ? true : false" is exactly "A" when used in
condition checks.  So IMHO it's clean enough to write:

  if (devfn & VTD_DEVFN_CHECK_MASK) {
...
  }

Comparing to:

  if (vtd_devfn_check(devfn)) {
...
  }

And imho actually the name "check"/"mask" is confusing itself
already...  So maybe even dropping both vtd_devfn_check() and
VTD_DEVFN_CHECK_MASK (note: there's nothing about any validity checks,
and it's not a mask at all!) and simply:

  if (devfn >= UINT8_MAX / 2)

That's even clearer to me that it's splitted into two halves.

[...]

> > > diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
> > > index a321cc9..ff13ff27 100644
> > > --- a/include/hw/i386/intel_iommu.h
> > > +++ b/include/hw/i386/intel_iommu.h
> > > @@ -66,11 +66,12 @@ typedef struct VTDIOTLBEntry VTDIOTLBEntry;
> > >  typedef struct VTDBus VTDBus;
> > >  typedef union VTD_IR_TableEntry VTD_IR_TableEntry;
> > >  typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress;
> > > +typedef struct VTDPASIDDirEntry VTDPASIDDirEntry;
> > > +typedef struct VTDPASIDEntry VTDPASIDEntry;
> > >  
> > >  /* Context-Entry */
> > >  struct VTDContextEntry {
> > > -uint64_t lo;
> > > -uint64_t hi;
> > > +uint64_t val[4];
> > 
> > You can actually make it an enum, two benefits:
> > 
> Thanks for the suggestion! DYM 'union'?

Yes. :)

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH 12/13] spapr/xics: ignore the lower 4K in the IRQ number space

[Cédric Le Goater]

On 2/13/19 2:33 AM, David Gibson wrote:
> On Tue, Feb 12, 2019 at 08:05:53AM +0100, Cédric Le Goater wrote:
>> On 2/12/19 2:06 AM, David Gibson wrote:
>>> On Mon, Jan 07, 2019 at 07:39:45PM +0100, Cédric Le Goater wrote:
 The IRQ number space of the XIVE and XICS interrupt mode are aligned
 when using the dual interrupt mode for the machine. This means that
 the ICS offset is set to zero in QEMU and that the KVM XICS device
 should be informed of this new value. Unfortunately, there is now way
 to do so and KVM still maintains the XICS_IRQ_BASE (0x1000) offset.

 Ignore the lower 4K which are not used under the XICS interrupt
 mode. These IRQ numbers are only claimed by XIVE for the CPU IPIs.

 Signed-off-by: Cédric Le Goater 
 ---
  hw/intc/xics_kvm.c | 18 ++
  1 file changed, 18 insertions(+)

 diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
 index 651bbfdf6966..1d21ff217b82 100644
 --- a/hw/intc/xics_kvm.c
 +++ b/hw/intc/xics_kvm.c
 @@ -238,6 +238,15 @@ static void ics_get_kvm_state(ICSState *ics)
  for (i = 0; i < ics->nr_irqs; i++) {
  ICSIRQState *irq = &ics->irqs[i];
  
 +/*
 + * The KVM XICS device considers that the IRQ numbers should
 + * start at XICS_IRQ_BASE (0x1000). Ignore the lower 4K
 + * numbers (only claimed by XIVE for the CPU IPIs).
 + */
 +if (i + ics->offset < XICS_IRQ_BASE) {
 +continue;
 +}
 +
>>>
>>> This seems bogus to me.  The guest-visible irq numbers need to line up
>>> between xics and xive mode, yes, but that doesn't mean we need to keep
>>> around a great big array of unused array of ICS irq states, even in
>>> TCG mode.
>>
>> This is because the qirqs[] array is under the machine and shared between 
>> both interrupt modes, xics and xive.
> 
> I don't see how that follows.  ICSIRQState is indexed in terms of the
> ICS source number, not the global irq number, so I don't see why it
> has to match up with the qirq array.

The root cause is the use of spapr->irq->nr_irqs to initialize the ICS 
and sPAPRXive object. In case of the 'dual' backend, it covers the full 
XIVE IRQ number space (0x2000 today) but XICS only needs 0x1000.

I think we can fix the offset issue by using the appropriate nr_irqs 
which should be for the XICS backend : spapr->irq->nr_irqs - ics->offset


I keep in mind the XIVE support for nested guests and I think we will
need to extend the IRQ number space in L1 and have the L2 use a portion
of it (using an offset). 

C.
 
>>>
  kvm_device_access(kernel_xics_fd, KVM_DEV_XICS_GRP_SOURCES,
i + ics->offset, &state, false, &error_fatal);
  
 @@ -303,6 +312,15 @@ static int ics_set_kvm_state(ICSState *ics, int 
 version_id)
  ICSIRQState *irq = &ics->irqs[i];
  int ret;
  
 +/*
 + * The KVM XICS device considers that the IRQ numbers should
 + * start at XICS_IRQ_BASE (0x1000). Ignore the lower 4K
 + * numbers (only claimed by XIVE for the CPU IPIs).
 + */
 +if (i + ics->offset < XICS_IRQ_BASE) {
 +continue;
 +}
 +
  state = irq->server;
  state |= (uint64_t)(irq->saved_priority & KVM_XICS_PRIORITY_MASK)
  << KVM_XICS_PRIORITY_SHIFT;
>>>
>>
> 

Re: [Qemu-devel] [PATCH v4] virtio-blk: set correct config size for the host driver

[Greg Kurz]

On Wed, 13 Feb 2019 09:48:57 +0800
Changpeng Liu  wrote:

> Commit caa1ee43 "vhost-user-blk: add discard/write zeroes features
> support" added fields to struct virtio_blk_config. This changes
> the size of the config space and breaks migration from QEMU 3.1
> and older:
> 
> qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x10 read: 41 
> device: 1 cmask: ff wmask: 80 w1cmask:0
> qemu-system-ppc64: Failed to load PCIDevice:config
> qemu-system-ppc64: Failed to load virtio-blk:virtio
> qemu-system-ppc64: error while loading state for instance 0x0 of device 
> 'pci@8002000:01.0/virtio-blk'
> qemu-system-ppc64: load of migration failed: Invalid argument
> 
> Since virtio-blk doesn't support the "discard" and "write zeroes"
> features, it shouldn't even expose the associated fields in the
> config space actually. Just include all fields up to num_queues to
> match QEMU 3.1 and older.
> 
> Signed-off-by: Changpeng Liu 
> ---

Again ;-)

Reviewed-by: Greg Kurz 
Tested-by: Greg Kurz 

>  hw/block/virtio-blk.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 9a87b3b..6fce9c7 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -28,6 +28,10 @@
>  #include "hw/virtio/virtio-bus.h"
>  #include "hw/virtio/virtio-access.h"
>  
> +/* We don't support discard yet, hide associated config fields. */
> +#define VIRTIO_BLK_CFG_SIZE offsetof(struct virtio_blk_config, \
> + max_discard_sectors)
> +
>  static void virtio_blk_init_request(VirtIOBlock *s, VirtQueue *vq,
>  VirtIOBlockReq *req)
>  {
> @@ -761,7 +765,8 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
> uint8_t *config)
>  blkcfg.alignment_offset = 0;
>  blkcfg.wce = blk_enable_write_cache(s->blk);
>  virtio_stw_p(vdev, &blkcfg.num_queues, s->conf.num_queues);
> -memcpy(config, &blkcfg, sizeof(struct virtio_blk_config));
> +memcpy(config, &blkcfg, VIRTIO_BLK_CFG_SIZE);
> +QEMU_BUILD_BUG_ON(VIRTIO_BLK_CFG_SIZE > sizeof(blkcfg));
>  }
>  
>  static void virtio_blk_set_config(VirtIODevice *vdev, const uint8_t *config)
> @@ -769,7 +774,8 @@ static void virtio_blk_set_config(VirtIODevice *vdev, 
> const uint8_t *config)
>  VirtIOBlock *s = VIRTIO_BLK(vdev);
>  struct virtio_blk_config blkcfg;
>  
> -memcpy(&blkcfg, config, sizeof(blkcfg));
> +memcpy(&blkcfg, config, VIRTIO_BLK_CFG_SIZE);
> +QEMU_BUILD_BUG_ON(VIRTIO_BLK_CFG_SIZE > sizeof(blkcfg));
>  
>  aio_context_acquire(blk_get_aio_context(s->blk));
>  blk_set_enable_write_cache(s->blk, blkcfg.wce != 0);
> @@ -952,8 +958,7 @@ static void virtio_blk_device_realize(DeviceState *dev, 
> Error **errp)
>  return;
>  }
>  
> -virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
> -sizeof(struct virtio_blk_config));
> +virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK, VIRTIO_BLK_CFG_SIZE);
>  
>  s->blk = conf->conf.blk;
>  s->rq = NULL;

Re: [Qemu-devel] [PATCH 07/19] target/ppc: Make special ORs match x86 pause and don't generate on mttcg

[Cédric Le Goater]

On 2/13/19 5:54 AM, David Gibson wrote:
> On Wed, Feb 13, 2019 at 11:03:12AM +1100, Benjamin Herrenschmidt wrote:
>> On Tue, 2019-02-12 at 16:59 +1100, David Gibson wrote:
>>> On Mon, Jan 28, 2019 at 10:46:13AM +0100, Cédric Le Goater wrote:
 From: Benjamin Herrenschmidt 

 There's no point in going out of translation on an SMT OR with
 mttcg since the backend won't do anything useful such as pausing,
 it's only useful on traditional TCG to give time to other
 processors.
>>>
>>> Is it actively harmful in the MTTCG case, or just pointless?
>>
>> I think it can hurt performance, I don't remember for sure :)
>>
 Signed-off-by: Benjamin Herrenschmidt 
 Signed-off-by: Cédric Le Goater 
 ---
  target/ppc/translate.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/target/ppc/translate.c b/target/ppc/translate.c
 index e169c43643a1..7d40a1fbe6bd 100644
 --- a/target/ppc/translate.c
 +++ b/target/ppc/translate.c
 @@ -1580,7 +1580,7 @@ static void gen_pause(DisasContext *ctx)
  tcg_temp_free_i32(t0);
  
  /* Stop translation, this gives other CPUs a chance to run */
 -gen_exception_nip(ctx, EXCP_HLT, ctx->base.pc_next);
 +gen_exception_nip(ctx, EXCP_INTERRUPT, ctx->base.pc_next);
>>>
>>> I don't see how this change relates to the rest.
>>
>> Yeah not sure anymore :-)
> 
> Oh.  That certainly doesn't make this easier to review.
> 
> So, all these target/ppc patches are only indirectly related to XIVE
> pnv support.  Cédric, can you split them out into their own series on
> the next spin.

Sure. I will address your comments and resend them first.
 
Thanks,

C.

> 
>>
  }
  #endif /* defined(TARGET_PPC64) */
  
 @@ -1662,7 +1662,9 @@ static void gen_or(DisasContext *ctx)
   * than no-op, e.g., miso(rs=26), yield(27), mdoio(29), mdoom(30),
   * and all currently undefined.
   */
 -gen_pause(ctx);
 +if (!mttcg_enabled) {
 +gen_pause(ctx);
 +}
  #endif
  #endif
  }
>>
> 

Re: [Qemu-devel] [PATCH v2] hostmem-file: reject invalid pmem file sizes

[Wei Yang]

On Wed, Feb 13, 2019 at 03:14:01PM +0800, Stefan Hajnoczi wrote:
>Guests started with NVDIMMs larger than the underlying host file produce
>confusing errors inside the guest.  This happens because the guest
>accesses pages beyond the end of the file.
>
>Check the pmem file size on startup and print a clear error message if
>the size is invalid.
>
>Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1669053
>Cc: Haozhong Zhang 
>Cc: Zhang Yi 
>Cc: Eduardo Habkost 
>Cc: Igor Mammedov 
>Signed-off-by: Stefan Hajnoczi 
>---
>v2:
> * Propagate qemu_get_pmem_size() errors [Igor]
>
> include/qemu/osdep.h| 13 ++
> backends/hostmem-file.c | 22 +
> util/oslib-posix.c  | 53 +
> util/oslib-win32.c  |  5 
> 4 files changed, 93 insertions(+)
>
>diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
>index 840af09cb0..303d315c5d 100644
>--- a/include/qemu/osdep.h
>+++ b/include/qemu/osdep.h
>@@ -570,6 +570,19 @@ void qemu_set_tty_echo(int fd, bool echo);
> void os_mem_prealloc(int fd, char *area, size_t sz, int smp_cpus,
>  Error **errp);
> 
>+/**
>+ * qemu_get_pmem_size:
>+ * @filename: path to a pmem file
>+ * @errp: pointer to a NULL-initialized error object
>+ *
>+ * Determine the size of a persistent memory file.  Besides supporting files 
>on
>+ * DAX file systems, this function also supports Linux devdax character
>+ * devices.
>+ *
>+ * Returns: the size or 0 on failure
>+
> /**
>  * qemu_get_pid_name:
>  * @pid: pid of a process
>diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
>index ba601ce940..d62689179b 100644
>--- a/backends/hostmem-file.c
>+++ b/backends/hostmem-file.c
>@@ -46,6 +46,28 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
>**errp)
> gchar *name;
> #endif
> 
>+/*
>+ * Verify pmem file size since starting a guest with an incorrect size
>+ * leads to confusing failures inside the guest.
>+ */
>+if (fb->is_pmem && fb->mem_path) {
>+Error *local_err = NULL;
>+uint64_t size;
>+
>+size = qemu_get_pmem_size(fb->mem_path, &local_err);
>+if (!size) {
>+error_propagate(errp, local_err);
>+return;
>+}
>+
>+if (backend->size > size) {
>+error_setg(errp, "size property %" PRIu64 " is larger than "
>+   "pmem file \"%s\" size %" PRIu64, backend->size,
>+   fb->mem_path, size);
>+return;
>+}
>+}
>+
> if (!backend->size) {
> error_setg(errp, "can't create backend with size 0");
> return;

Would it be reasonable to move the above check after checking size and
mem_path?

>diff --git a/util/oslib-posix.c b/util/oslib-posix.c
>index 37c5854b9c..10d90d1783 100644
>--- a/util/oslib-posix.c
>+++ b/util/oslib-posix.c
>@@ -500,6 +500,59 @@ void os_mem_prealloc(int fd, char *area, size_t memory, 
>int smp_cpus,
> }
> }
> 
>+uint64_t qemu_get_pmem_size(const char *filename, Error **errp)
>+{
>+struct stat st;
>+
>+if (stat(filename, &st) < 0) {
>+error_setg(errp, "unable to stat pmem file \"%s\"", filename);
>+return 0;
>+}
>+
>+#if defined(__linux__)
>+/* Special handling for devdax character devices */
>+if (S_ISCHR(st.st_mode)) {
>+char *subsystem_path = NULL;
>+char *subsystem = NULL;
>+char *size_path = NULL;
>+char *size_str = NULL;
>+uint64_t ret = 0;
>+
>+subsystem_path = g_strdup_printf("/sys/dev/char/%d:%d/subsystem",
>+ major(st.st_rdev), 
>minor(st.st_rdev));
>+subsystem = g_file_read_link(subsystem_path, NULL);
>+if (!subsystem) {
>+error_setg(errp, "unable to read subsystem for pmem file \"%s\"",
>+   filename);
>+goto devdax_err;
>+}
>+
>+if (!g_str_has_suffix(subsystem, "/dax")) {
>+error_setg(errp, "pmem file \"%s\" is not a dax device", 
>filename);
>+goto devdax_err;
>+}
>+
>+size_path = g_strdup_printf("/sys/dev/char/%d:%d/size",
>+major(st.st_rdev), minor(st.st_rdev));
>+if (!g_file_get_contents(size_path, &size_str, NULL, NULL)) {
>+error_setg(errp, "unable to read size for pmem file \"%s\"",
>+   size_path);
>+goto devdax_err;
>+}
>+
>+ret = g_ascii_strtoull(size_str, NULL, 0);
>+
>+devdax_err:
>+g_free(size_str);
>+g_free(size_path);
>+g_free(subsystem);
>+g_free(subsystem_path);
>+return ret;
>+}
>+#endif /* defined(__linux__) */
>+
>+return st.st_size;
>+}
> 
> char *qemu_get_pid_name(pid_t pid)
> {
>diff --git a/util/oslib-win32.c b/util/oslib-win32.c
>index b4c17f5dfa..bd633afab6 100644
>--- a/util/oslib-win32.c
>+++ b/util/oslib-win32.c
>@@ -560,6 +560,11 @@ void os_mem_prealloc(int fd, ch

Re: [Qemu-devel] [RFC v1 1/3] intel_iommu: scalable mode emulation

[Peter Xu]

On Wed, Feb 13, 2019 at 04:03:05PM +0800, Peter Xu wrote:
> On Wed, Feb 13, 2019 at 03:38:55PM +0800, Yi Sun wrote:
> 
> [...]
> 
> > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > > index 8b72735..396ac8e 100644
> > > > --- a/hw/i386/intel_iommu.c
> > > > +++ b/hw/i386/intel_iommu.c
> > > > @@ -37,6 +37,34 @@
> > > >  #include "kvm_i386.h"
> > > >  #include "trace.h"
> > > >  
> > > > +#define vtd_devfn_check(devfn) ((devfn & VTD_DEVFN_CHECK_MASK) ? true 
> > > > : false)
> > > 
> > > "vtd_devfn_check(devfn)" is merely as long as "devfn &
> > > VTD_DEVFN_CHECK_MASK", isn't it? :)
> > > 
> > > I would just drop the macro.
> > > 
> > There are two places to call this macro. Is that valuable to keep it?
> 
> The point here is "A ? true : false" is exactly "A" when used in
> condition checks.  So IMHO it's clean enough to write:
> 
>   if (devfn & VTD_DEVFN_CHECK_MASK) {
> ...
>   }
> 
> Comparing to:
> 
>   if (vtd_devfn_check(devfn)) {
> ...
>   }
> 
> And imho actually the name "check"/"mask" is confusing itself
> already...  So maybe even dropping both vtd_devfn_check() and
> VTD_DEVFN_CHECK_MASK (note: there's nothing about any validity checks,
> and it's not a mask at all!) and simply:
> 
>   if (devfn >= UINT8_MAX / 2)
> 
> That's even clearer to me that it's splitted into two halves.

Sorry I didn't notice UINT8_MAX is 255 rather than 256, then it should
be ">"...  anyway, these are a bit nitpicking, feel free to use your
own preference at last.

> 
> [...]
> 
> > > > diff --git a/include/hw/i386/intel_iommu.h 
> > > > b/include/hw/i386/intel_iommu.h
> > > > index a321cc9..ff13ff27 100644
> > > > --- a/include/hw/i386/intel_iommu.h
> > > > +++ b/include/hw/i386/intel_iommu.h
> > > > @@ -66,11 +66,12 @@ typedef struct VTDIOTLBEntry VTDIOTLBEntry;
> > > >  typedef struct VTDBus VTDBus;
> > > >  typedef union VTD_IR_TableEntry VTD_IR_TableEntry;
> > > >  typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress;
> > > > +typedef struct VTDPASIDDirEntry VTDPASIDDirEntry;
> > > > +typedef struct VTDPASIDEntry VTDPASIDEntry;
> > > >  
> > > >  /* Context-Entry */
> > > >  struct VTDContextEntry {
> > > > -uint64_t lo;
> > > > -uint64_t hi;
> > > > +uint64_t val[4];
> > > 
> > > You can actually make it an enum, two benefits:
> > > 
> > Thanks for the suggestion! DYM 'union'?
> 
> Yes. :)
> 
> Regards,
> 
> -- 
> Peter Xu

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH 13/13] spapr: add KVM support to the 'dual' machine

[Cédric Le Goater]

On 2/13/19 2:32 AM, David Gibson wrote:
> On Tue, Feb 12, 2019 at 08:18:19AM +0100, Cédric Le Goater wrote:
>> On 2/12/19 2:11 AM, David Gibson wrote:
>>> On Mon, Jan 07, 2019 at 07:39:46PM +0100, Cédric Le Goater wrote:
 The interrupt mode is chosen by the CAS negotiation process and
 activated after a reset to take into account the required changes in
 the machine. This brings new constraints on how the associated KVM IRQ
 device is initialized.

 Currently, each model takes care of the initialization of the KVM
 device in their realize method but this is not possible anymore as the
 initialization needs to be done globaly when the interrupt mode is
 known, i.e. when machine is reseted. It also means that we need a way
 to delete a KVM device when another mode is chosen.

 Also, to support migration, the QEMU objects holding the state to
 transfer should always be available but not necessarily activated.

 The overall approach of this proposal is to initialize both interrupt
 mode at the QEMU level and keep the IRQ number space in sync to allow
 switching from one mode to another. For the KVM side of things, the
 whole initialization of the KVM device, sources and presenters, is
 grouped in a single routine. The XICS and XIVE sPAPR IRQ reset
 handlers are modified accordingly to handle the init and the delete
 sequences of the KVM device.

 As KVM is now initialized at reset, we loose the possiblity to
 fallback to the QEMU emulated mode in case of failure and failures
 become fatal to the machine.

 Signed-off-by: Cédric Le Goater 
 ---
  hw/intc/spapr_xive.c |  8 +---
  hw/intc/spapr_xive_kvm.c | 27 ++
  hw/intc/xics_kvm.c   | 25 +
  hw/intc/xive.c   |  4 --
  hw/ppc/spapr_irq.c   | 79 
  5 files changed, 109 insertions(+), 34 deletions(-)

 diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
 index 21f3c1ef0901..0661aca35900 100644
 --- a/hw/intc/spapr_xive.c
 +++ b/hw/intc/spapr_xive.c
 @@ -330,13 +330,7 @@ static void spapr_xive_realize(DeviceState *dev, 
 Error **errp)
  xive->eat = g_new0(XiveEAS, xive->nr_irqs);
  xive->endt = g_new0(XiveEND, xive->nr_ends);
  
 -if (kvmppc_xive_enabled()) {
 -kvmppc_xive_connect(xive, &local_err);
 -if (local_err) {
 -error_propagate(errp, local_err);
 -return;
 -}
 -} else {
 +if (!kvmppc_xive_enabled()) {
  /* TIMA initialization */
  memory_region_init_io(&xive->tm_mmio, OBJECT(xive), &xive_tm_ops, 
 xive,
"xive.tima", 4ull << TM_SHIFT);
 diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
 index d35814c1992e..3ebc947f2be7 100644
 --- a/hw/intc/spapr_xive_kvm.c
 +++ b/hw/intc/spapr_xive_kvm.c
 @@ -737,6 +737,15 @@ void kvmppc_xive_connect(sPAPRXive *xive, Error 
 **errp)
  Error *local_err = NULL;
  size_t esb_len;
  size_t tima_len;
 +CPUState *cs;
 +
 +/*
 + * The KVM XIVE device already in use. This is the case when
 + * rebooting XIVE -> XIVE
>>>
>>> Can this case actually occur?  Further down you appear to
>>> unconditionally destroy both KVM devices at reset time.
>>
>> I guess you are right. I will check.
>>
 + */
 +if (xive->fd != -1) {
 +return;
 +}
  
  if (!kvm_enabled() || !kvmppc_has_cap_xive()) {
  error_setg(errp, "IRQ_XIVE capability must be present for KVM");
 @@ -800,6 +809,24 @@ void kvmppc_xive_connect(sPAPRXive *xive, Error 
 **errp)
  xive->change = qemu_add_vm_change_state_handler(
  kvmppc_xive_change_state_handler, xive);
  
 +/* Connect the presenters to the initial VCPUs of the machine */
 +CPU_FOREACH(cs) {
 +PowerPCCPU *cpu = POWERPC_CPU(cs);
 +
 +kvmppc_xive_cpu_connect(cpu->tctx, &local_err);
 +if (local_err) {
 +error_propagate(errp, local_err);
 +return;
 +}
 +}
 +
 +/* Update the KVM sources */
 +kvmppc_xive_source_reset(xsrc, &local_err);
 +if (local_err) {
 +error_propagate(errp, local_err);
 +return;
 +}
 +
  kvm_kernel_irqchip = true;
  kvm_msi_via_irqfd_allowed = true;
  kvm_gsi_direct_mapping = true;
 diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
 index 1d21ff217b82..bfc35d71df7f 100644
 --- a/hw/intc/xics_kvm.c
 +++ b/hw/intc/xics_kvm.c
 @@ -448,6 +448,16 @@ static void rtas_dummy(PowerPCCPU *cpu, 
 sPAPRMachineState *spapr,
  int xics_kvm_init(sPAPRMachineState *spapr, Error **

Re: [Qemu-devel] [PATCH v4] virtio-blk: set correct config size for the host driver

[Stefano Garzarella]

On Wed, Feb 13, 2019 at 04:01:43PM +0800, Stefan Hajnoczi wrote:
> On Wed, Feb 13, 2019 at 09:48:57AM +0800, Changpeng Liu wrote:
> > Commit caa1ee43 "vhost-user-blk: add discard/write zeroes features
> > support" added fields to struct virtio_blk_config. This changes
> > the size of the config space and breaks migration from QEMU 3.1
> > and older:
> > 
> > qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x10 read: 41 
> > device: 1 cmask: ff wmask: 80 w1cmask:0
> > qemu-system-ppc64: Failed to load PCIDevice:config
> > qemu-system-ppc64: Failed to load virtio-blk:virtio
> > qemu-system-ppc64: error while loading state for instance 0x0 of device 
> > 'pci@8002000:01.0/virtio-blk'
> > qemu-system-ppc64: load of migration failed: Invalid argument
> > 
> > Since virtio-blk doesn't support the "discard" and "write zeroes"
> > features, it shouldn't even expose the associated fields in the
> > config space actually. Just include all fields up to num_queues to
> > match QEMU 3.1 and older.
> > 
> > Signed-off-by: Changpeng Liu 
> > ---
> >  hw/block/virtio-blk.c | 13 +
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> Stefano: Please rebase your DISCARD/WRITE_ZEROES series onto this and
> check that the config space is correctly sized.  Machine types before
> 4.0 shouldn't have these fields so that the config space size remains
> unchanged.

Sure!

Since I should set a correct config size checking if new features are
enabled or not at runtime, should be better to add a variable and an array
of sizes like in virtio-net?

Thanks,
Stefano

[Qemu-devel] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2

[Laszlo Ersek]

Hi,

using QEMU, when I specify a nonzero LUN for the hard disk that sits on
the "SCSI bus" that embodies the USB Bulk Only Transfer device, then
UsbMassStorageDxe fails to recognize the hard disk.

(1) Consider the following QEMU command line snippet:

  -drive id=disk1,if=none,format=raw,readonly,file=$APPDISK \
  -device qemu-xhci,id=xhci1,p3=15,addr=02.0 \
  -device usb-bot,bus=xhci1.0,port=3,id=bot1 \
  -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \

For this (i.e., lun=0), I see the following INQUIRY exchange between
UsbMassStorageDxe and QEMU:

> Lun=0 InquiryCmd {
> Lun=0 InquiryCmd 00 12 00 00 00 24 00 00 00 00 00 00 00
> Lun=0 InquiryCmd }
> Lun=0 InquiryData {
> Lun=0 InquiryData 00 00 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
> Lun=0 InquiryData 10 51 45 4D 55 20 48 41 52 44 44 49 53 4B 20 20 20
> Lun=0 InquiryData 20 32 2E 35 2B
> Lun=0 InquiryData }

The vendor and product ID fields translate to "QEMU" and
"QEMU_HARDDISK___", respectively. (For easier reading, I replaced the
space characters with underscores, for the sake of better
readability/wrapping.)

In this case, edk2 recognizes the disk and things work fine.

(In fact, for lun=0, the QemuBootOrderLib pattern matching / translation
works fine as well -- verifying which was my original goal, before I ran
into the issues below, for nonzero LUNs. But, I digress.)


(2) If I change the cmdline to "lun=5", then the exchange is:

> Lun=0 InquiryCmd {
> Lun=0 InquiryCmd 00 12 00 00 00 24 00 00 00 00 00 00 00
> Lun=0 InquiryCmd }
> Lun=0 InquiryData {
> Lun=0 InquiryData 00 3F 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
> Lun=0 InquiryData 10 51 45 4D 55 20 54 41 52 47 45 54 20 20 20 20 20
> Lun=0 InquiryData 20 32 2E 35 00
> Lun=0 InquiryData }

Here the product ID is unchanged, but the vendor ID becomes
"QEMU_TARGET_".

And, edk2 fails to recognize the device:

> UsbBootGetParams: Found an unsupported peripheral type[31]
> UsbMassInitMedia: UsbBootGetParams (Unsupported)
> UsbMassInitNonLun: UsbMassInitMedia (Unsupported)
> USBMassDriverBindingStart: UsbMassInitNonLun (Unsupported)

This happens because the first byte in the response is 0x3F. QEMU sets
this byte in

> r->buf[0] = TYPE_NOT_PRESENT | TYPE_INACTIVE;

in function scsi_target_emulate_inquiry(), file "hw/scsi/scsi-bus.c".

And edk2 parses the byte in UsbBootInquiry() and UsbBootGetParams()
(file "MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c"):

> typedef struct {
>   UINT8 Pdt;///< Peripheral Device Type (low 5 bits)
>   UINT8 Removable;  ///< Removable Media (highest bit)
>   UINT8 Reserved0[2];
>   UINT8 AddLen; ///< Additional length
>   UINT8 Reserved1[3];
>   UINT8 VendorID[8];
>   UINT8 ProductID[16];
>   UINT8 ProductRevision[4];
> } USB_BOOT_INQUIRY_DATA;

> #define USB_BOOT_PDT(Pdt)   ((Pdt) & 0x1f)

>   UsbMass->Pdt  = (UINT8) (USB_BOOT_PDT (UsbMass->InquiryData.Pdt));

>   //
>   // According to USB Mass Storage Specification for Bootability, only 
> following
>   // 4 Peripheral Device Types are in spec.
>   //
>   if ((UsbMass->Pdt != USB_PDT_DIRECT_ACCESS) &&
>(UsbMass->Pdt != USB_PDT_CDROM) &&
>(UsbMass->Pdt != USB_PDT_OPTICAL) &&
>(UsbMass->Pdt != USB_PDT_SIMPLE_DIRECT)) {
> DEBUG ((EFI_D_ERROR, "UsbBootGetParams: Found an unsupported peripheral 
> type[%d]\n", UsbMass->Pdt));
> return EFI_UNSUPPORTED;
>   }

It looks likely that at least one of edk2 and QEMU has a bug. Which one
is it?

Or is the command line incorrect perhaps? (I.e., is it invalid to
specify *only* lun=5? Does the LUN space have to be contiguous?)


(3) Starting again from the original command line, if I change "lun=0"
to "lun=1" (rather than to "lun=5"), then OVMF even hangs, with the
following log:

> UsbMassInitMultiLun: Start to initialize No.0 logic unit
> Lun=0 InquiryCmd {
> Lun=0 InquiryCmd 00 12 00 00 00 24 00 00 00 00 00 00 00
> Lun=0 InquiryCmd }
> Lun=0 InquiryData {
> Lun=0 InquiryData 00 3F 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
> Lun=0 InquiryData 10 51 45 4D 55 20 54 41 52 47 45 54 20 20 20 20 20
> Lun=0 InquiryData 20 32 2E 35 00
> Lun=0 InquiryData }
> UsbBootGetParams: Found an unsupported peripheral type[31]
> UsbMassInitMedia: UsbBootGetParams (Unsupported)
> UsbMassInitMultiLun: UsbMassInitMedia (Unsupported)
> UsbMassInitMultiLun: Start to initialize No.1 logic unit
> Lun=32 InquiryCmd {
> Lun=32 InquiryCmd 00 12 20 00 00 24 00 00 00 00 00 00 00
> Lun=32 InquiryCmd }
> Lun=32 InquiryData {
> Lun=32 InquiryData 00 00 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
> Lun=32 InquiryData 10 51 45 4D 55 20 48 41 52 44 44 49 53 4B 20 20 20
> Lun=32 InquiryData 20 32 2E 35 2B
> Lun=32 InquiryData }
> UsbBootExecCmd: Success to Exec 0x0 Cmd (Result = 1)
> UsbBootRequestSense: (Invalid Parameter) with error code (

Re: [Qemu-devel] [PATCH v3 0/3] Trivial cleanup in hw/acpi

[Laurent Vivier]

On 12/02/2019 06:34, Michael S. Tsirkin wrote:
> On Tue, Feb 12, 2019 at 01:22:24PM +0800, Wei Yang wrote:
>> On Wed, Jan 30, 2019 at 08:06:50AM +0800, Wei Yang wrote:
>>> There are several functions/variable which are not used anymore.
>>>
>>> This serials just remove those without functional change.
>>>
>>> v3: add ack and repost in a new thread
>>> v2: change commit log from "is now used in no place" to "in not used 
>>> anymore"
>>
>> Michael,
>>
>> Looks this serials is not merged yet.
>>
>> Is there any problem I need to fix?
> 
> Yes pls repost with fixed reviewed-by tags.

Or I can take the series through the trivial branch and update manually
Philippe's lastname?

Laurent

[Qemu-devel] [PATCH v2 21/25] hw/arm: Express dependencies for remaining IMX boards with Kconfig

[Thomas Huth]

IMX25, IMX7 and IMX6UL were still missing the Kconfig dependencies.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak |  2 --
 hw/arm/Kconfig  | 18 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 5eceeba..ebe5de6 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -33,7 +33,6 @@ CONFIG_SABRELITE=y
 CONFIG_EMCRAFT_SF2=y
 
 CONFIG_VGA=y
-CONFIG_IMX_FEC=y
 
 CONFIG_NRF51_SOC=y
 
@@ -45,4 +44,3 @@ CONFIG_PCIE_PORT=y
 CONFIG_XIO3130=y
 CONFIG_IOH3420=y
 CONFIG_I82801B11=y
-CONFIG_PCI_EXPRESS_DESIGNWARE=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index cebb410..c2fba8e 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -295,6 +295,10 @@ config XLNX_VERSAL
 
 config FSL_IMX25
 bool
+select IMX
+select IMX_FEC
+select IMX_I2C
+select DS1338
 
 config FSL_IMX31
 bool
@@ -309,6 +313,7 @@ config FSL_IMX6
 select A9MPCORE
 select IMX
 select IMX_I2C
+select SDHCI
 
 config ASPEED_SOC
 bool
@@ -348,12 +353,25 @@ config IOTKIT
 
 config FSL_IMX7
 bool
+imply PCI_DEVICES
+select A15MPCORE
+select PCI
+select IMX
+select IMX_FEC
+select IMX_I2C
+select PCI_EXPRESS_DESIGNWARE
+select SDHCI
 
 config ARM_SMMUV3
 bool
 
 config FSL_IMX6UL
 bool
+select A15MPCORE
+select IMX
+select IMX_FEC
+select IMX_I2C
+select SDHCI
 
 config NRF51_SOC
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 17/25] hw/arm: Express dependencies of the raspi machines with Kconfig

[Thomas Huth]

Most of the code is directly controlled by the CONFIG_RASPI switch,
so not much to add here additionally.

Note that CONFIG_SDHCI currently has a hard requirement for PCI, so
we select that switch now always there instead of depending on it.
We should split up sdhci.c into sysbus and pci parts later to get
rid of this hard requirement.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 4 +---
 hw/arm/Kconfig  | 3 +++
 hw/sd/Kconfig   | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index b530a06..6605786 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -27,15 +27,13 @@ CONFIG_COLLIE=y
 CONFIG_ASPEED_SOC=y
 CONFIG_NETDUINO2=y
 CONFIG_MPS2=y
+CONFIG_RASPI=y
 
 CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
 CONFIG_IMX_FEC=y
 
-CONFIG_FRAMEBUFFER=y
-
 CONFIG_DIGIC=y
-CONFIG_RASPI=y
 CONFIG_NRF51_SOC=y
 
 CONFIG_FSL_IMX6=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index d17bd2f..bb385a5 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -269,6 +269,9 @@ config ALLWINNER_A10
 
 config RASPI
 bool
+select FRAMEBUFFER
+select PL011 # UART
+select SDHCI
 
 config STM32F205_SOC
 bool
diff --git a/hw/sd/Kconfig b/hw/sd/Kconfig
index 864f535..29e359b 100644
--- a/hw/sd/Kconfig
+++ b/hw/sd/Kconfig
@@ -13,5 +13,5 @@ config SD
 config SDHCI
 bool
 default y if PCI_DEVICES
-depends on PCI
+select PCI   # TODO: Split up sdhci.c into sysbus and pci parts
 select SD
-- 
1.8.3.1

Re: [Qemu-devel] [RFC 1/4] numa, spapr: add thread-id in the possible_cpus list

[Igor Mammedov]

On Wed, 13 Feb 2019 12:25:45 +1100
David Gibson  wrote:

> On Tue, Feb 12, 2019 at 10:48:24PM +0100, Laurent Vivier wrote:
> > spapr_possible_cpu_arch_ids() counts only cores, and so
> > the number of available CPUs is the number of vCPU divided
> > by smp_threads.
> > 
> > ... -smp 4,maxcpus=8,cores=2,threads=2,sockets=2 -numa node,cpus=0,cpus=1 \
> >  -numa node,cpus=3,cpus=4 \
> >  -numa node -numa node
> > 
> > This generates (info hotpluggable-cpus)
> > 
> >   node-id: 0 core-id: 0 thread-id: 0 [thread-id: 1]
> >   node-id: 0 core-id: 6 thread-id: 0 [thread-id: 1]
> >   node-id: 1 core-id: 2 thread-id: 0 [thread-id: 1]
> >   node-id: 1 core-id: 4 thread-id: 0 [thread-id: 1]
> > 
> > And this command line generates the following error:
> > 
> >   CPU(s) not present in any NUMA nodes: CPU 3 [core-id: 6]
> > 
> > That is wrong because CPU 3 [core-id: 6] is assigned to node-id 0
> > Moreover "cpus=4" is not valid, because it means core-id 8 but
> > maxcpus is 8.
> > 
> > With this patch we have now:
> > 
> >   node-id: 0 core-id: 0 thread-id: 0
> >   node-id: 0 core-id: 0 thread-id: 1
> >   node-id: 0 core-id: 1 thread-id: 0
> >   node-id: 1 core-id: 1 thread-id: 1
> >   node-id: 0 core-id: 2 thread-id: 1
> >   node-id: 1 core-id: 2 thread-id: 0
> >   node-id: 0 core-id: 3 thread-id: 1
> >   node-id: 0 core-id: 3 thread-id: 0  
> 
> I'm afraid this is not the right solution.  The point of the
> hotpluggable cpus table is that it has exactly one entry for each
> hotpluggable unit.  For PAPR that's a core, not a thread.
> 
> So, the problem is with how the NUMA configuration code is
> interpreting possible-cpus, not how the machine is building the table.

I'd suggest to deprecate/remove 'cpus' suboption in -numa.
One should use '-numa cpu' instead, which is written with
possible_cpus in mind.

> 
> > CPUs 0 (core-id: 0 thread-id: 0) and 1 (core-id: 0 thread-id: 1) are
> > correctly assigned to node-id 0, CPUs 3 (core-id: 1 thread-id: 1) and
> >  4 (core-id: 2 thread-id: 0) are correctly assigned to node-id 1.
> > All other CPUs are assigned to node-id 0 by default.
> > 
> > And the error message is also correct:
> > 
> >   CPU(s) not present in any NUMA nodes: CPU 2 [core-id: 1, thread-id: 0], \
> > CPU 5 [core-id: 2, thread-id: 1], \
> > CPU 6 [core-id: 3, thread-id: 0], \
> > CPU 7 [core-id: 3, thread-id: 1]
> > 
> > Fixes: ec78f8114bc4 ("numa: use possible_cpus for not mapped CPUs check")
> > Cc: imamm...@redhat.com
> > 
> > Before commit ec78f8114bc4, output was correct:
> > 
> >   CPU(s) not present in any NUMA nodes: 2 5 6 7
> > 
> > Signed-off-by: Laurent Vivier 
> > ---
> >  hw/ppc/spapr.c | 33 +
> >  1 file changed, 13 insertions(+), 20 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 332cba89d425..7196ba09da34 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -2404,15 +2404,13 @@ static void spapr_validate_node_memory(MachineState 
> > *machine, Error **errp)
> >  /* find cpu slot in machine->possible_cpus by core_id */
> >  static CPUArchId *spapr_find_cpu_slot(MachineState *ms, uint32_t id, int 
> > *idx)
> >  {
> > -int index = id / smp_threads;
> > -
> > -if (index >= ms->possible_cpus->len) {
> > +if (id >= ms->possible_cpus->len) {
> >  return NULL;
> >  }
> >  if (idx) {
> > -*idx = index;
> > +*idx = id;
> >  }
> > -return &ms->possible_cpus->cpus[index];
> > +return &ms->possible_cpus->cpus[id];
> >  }
> >  
> >  static void spapr_set_vsmt_mode(sPAPRMachineState *spapr, Error **errp)
> > @@ -2514,7 +2512,7 @@ static void spapr_init_cpus(sPAPRMachineState *spapr)
> >  error_report("This machine version does not support CPU 
> > hotplug");
> >  exit(1);
> >  }
> > -boot_cores_nr = possible_cpus->len;
> > +boot_cores_nr = possible_cpus->len / smp_threads;
> >  }
> >  
> >  if (smc->pre_2_10_has_unused_icps) {
> > @@ -2528,7 +2526,7 @@ static void spapr_init_cpus(sPAPRMachineState *spapr)
> >  }
> >  }
> >  
> > -for (i = 0; i < possible_cpus->len; i++) {
> > +for (i = 0; i < possible_cpus->len / smp_threads; i++) {
> >  int core_id = i * smp_threads;
> >  
> >  if (mc->has_hotpluggable_cpus) {
> > @@ -3795,21 +3793,16 @@ spapr_cpu_index_to_props(MachineState *machine, 
> > unsigned cpu_index)
> >  
> >  static int64_t spapr_get_default_cpu_node_id(const MachineState *ms, int 
> > idx)
> >  {
> > -return idx / smp_cores % nb_numa_nodes;
> > +return idx / (smp_cores * smp_threads) % nb_numa_nodes;
> >  }
> >  
> >  static const CPUArchIdList *spapr_possible_cpu_arch_ids(MachineState 
> > *machine)
> >  {
> >  int i;
> >  const char *core_type;
> > 

[Qemu-devel] [PATCH v2 24/25] hw/arm: Express dependencies of the xlnx-versal-virt machine with Kconfig

[Thomas Huth]

Dependencies have been determined with trial-and-error and by
looking at the xlnx-versal.c source file.

Signed-off-by: Thomas Huth 
---
 hw/arm/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 721cc07..027c063 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -303,6 +303,10 @@ config XLNX_ZYNQMP_ARM
 
 config XLNX_VERSAL
 bool
+select ARM_GIC
+select PL011
+select CADENCE
+select VIRTIO_MMIO
 
 config FSL_IMX25
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 08/25] hw/arm: Express dependencies of realview, versatile and vexpress with Kconfig

[Thomas Huth]

This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 23 +++-
 hw/arm/Kconfig  | 47 +
 hw/arm/Makefile.objs|  3 ++-
 hw/display/Kconfig  |  1 +
 hw/i2c/Kconfig  |  2 +-
 5 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 1be49bd..2bac13b 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -3,8 +3,6 @@
 # TODO: ARM_V7M is currently always required - make this more flexible!
 CONFIG_ARM_V7M=y
 
-CONFIG_PCI_DEVICES=y
-
 CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
 CONFIG_INTEGRATOR=y
@@ -14,6 +12,9 @@ CONFIG_CHEETAH=y
 CONFIG_SX1=y
 CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
+CONFIG_REALVIEW=y
+CONFIG_VERSATILE=y
+CONFIG_VEXPRESS=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
@@ -22,8 +23,6 @@ CONFIG_SERIAL=y
 CONFIG_MAX7310=y
 CONFIG_TMP421=y
 CONFIG_PCA9552=y
-CONFIG_DDC=y
-CONFIG_SII9022=y
 CONFIG_ADS7846=y
 CONFIG_MAX111X=y
 CONFIG_SSI_M25P80=y
@@ -35,15 +34,8 @@ CONFIG_MICRODRIVE=y
 CONFIG_PLATFORM_BUS=y
 CONFIG_VIRTIO_MMIO=y
 
-CONFIG_ARM11MPCORE=y
-CONFIG_A9MPCORE=y
-CONFIG_A15MPCORE=y
-
 CONFIG_NETDUINO2=y
 
-CONFIG_PL041=y
-CONFIG_PL080=y
-CONFIG_PL190=y
 CONFIG_PL330=y
 CONFIG_CADENCE=y
 CONFIG_PXA2XX=y
@@ -51,12 +43,10 @@ CONFIG_FRAMEBUFFER=y
 CONFIG_XILINX_SPIPS=y
 CONFIG_ZYNQ_DEVCFG=y
 
-CONFIG_ARM11SCU=y
 CONFIG_DIGIC=y
 CONFIG_MAINSTONE=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
-CONFIG_REALVIEW=y
 CONFIG_ZAURUS=y
 CONFIG_ZYNQ=y
 CONFIG_STM32F2XX_TIMER=y
@@ -84,10 +74,6 @@ CONFIG_IOTKIT_SYSCTL=y
 CONFIG_IOTKIT_SYSINFO=y
 CONFIG_ARMSSE_CPUID=y
 
-CONFIG_VERSATILE=y
-CONFIG_VERSATILE_PCI=y
-CONFIG_VERSATILE_I2C=y
-
 CONFIG_PCI_EXPRESS=y
 CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
 CONFIG_VFIO_PLATFORM=y
@@ -123,6 +109,3 @@ CONFIG_XILINX_AXI=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
 
 CONFIG_STRONGARM=y
-
-# for realview and versatilepb
-CONFIG_LSI_SCSI_PCI=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 3034252..b76fd7c 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -92,6 +92,29 @@ config PXA2XX
 
 config REALVIEW
 bool
+imply PCI_DEVICES
+select SMC91C111
+select LAN9118
+select A9MPCORE
+select A15MPCORE
+select ARM11MPCORE
+select ARM_TIMER
+select VERSATILE_PCI
+select WM8750 # audio codec
+select LSI_SCSI_PCI
+select PCI
+select PL011  # UART
+select PL031  # RTC
+select PL041  # audio codec
+select PL050  # keyboard/mouse
+select PL061  # GPIO
+select PL080  # DMA controller
+select PL110
+select PL181  # display
+select PL310  # cache controller
+select VERSATILE_I2C
+select DS1338 # I2C RTC+NVRAM
+select USB_OHCI
 
 config STELLARIS
 bool
@@ -115,6 +138,29 @@ config SX1
 
 config VERSATILE
 bool
+select ARM_TIMER # sp804
+select PFLASH_CFI01
+select LSI_SCSI_PCI
+select PL050  # keyboard/mouse
+select PL080  # DMA controller
+select PL190  # Vector PIC
+select REALVIEW
+select USB_OHCI
+
+config VEXPRESS
+bool
+select A9MPCORE
+select A15MPCORE
+select ARM_MPTIMER
+select ARM_TIMER # sp804
+select LAN9118
+select PFLASH_CFI01
+select PL011 # UART
+select PL041 # audio codec
+select PL181  # display
+select REALVIEW
+select SII9022
+select VIRTIO_MMIO
 
 config ZYNQ
 bool
@@ -194,6 +240,7 @@ config A15MPCORE
 
 config ARM11MPCORE
 bool
+select ARM11SCU
 
 config ARMSSE
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index b0fd556..420641e 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -15,7 +15,8 @@ obj-$(CONFIG_PXA2XX) += gumstix.o spitz.o tosa.o z2.o
 obj-$(CONFIG_REALVIEW) += realview.o
 obj-$(CONFIG_STELLARIS) += stellaris.o
 obj-$(CONFIG_STRONGARM) += collie.o
-obj-$(CONFIG_VERSATILE) += vexpress.o versatilepb.o
+obj-$(CONFIG_VERSATILE) += versatilepb.o
+obj-$(CONFIG_VEXPRESS) += vexpress.o
 obj-$(CONFIG_ZYNQ) += xilinx_zynq.o
 
 obj-$(CONFIG_ARM_V7M) += armv7m.o
diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index 34c8c12..a5f3fc0 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -26,6 +26,7 @@ config PL110
 config SII9022
 bool
 depends on I2C
+select DDC
 
 config SSD0303
 bool
diff --git a/hw/i2c/Kconfig b/hw/i2c/Kconfig
index ef1caa6..0004893 100644
--- a/hw/i2c/Kconfig
+++ b/hw/i2c/Kconfig
@@ -12,7 +12,7 @@ config DDC
 
 config VERSATILE_I2C
 bool
-select I2C
+select BITBANG_I2C
 
 config ACPI_SMBUS
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 13/25] hw/arm: Express dependencies of the virt machine with Kconfig

[Thomas Huth]

Dependencies have been determined by looking at hw/arm/virt.c

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 14 +-
 hw/arm/Kconfig  | 19 +++
 hw/arm/Makefile.objs|  3 ++-
 3 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index b2e31b3..9db6808 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -3,6 +3,7 @@
 # TODO: ARM_V7M is currently always required - make this more flexible!
 CONFIG_ARM_V7M=y
 
+CONFIG_ARM_VIRT=y
 CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
 CONFIG_INTEGRATOR=y
@@ -28,8 +29,6 @@ CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
-CONFIG_PLATFORM_BUS=y
-CONFIG_VIRTIO_MMIO=y
 
 CONFIG_NETDUINO2=y
 
@@ -63,12 +62,6 @@ CONFIG_IOTKIT_SYSCTL=y
 CONFIG_IOTKIT_SYSINFO=y
 CONFIG_ARMSSE_CPUID=y
 
-CONFIG_PCI_EXPRESS=y
-CONFIG_PCI_EXPRESS_GENERIC_BRIDGE=y
-CONFIG_VFIO_PLATFORM=y
-CONFIG_VFIO_XGMAC=y
-CONFIG_VFIO_AMD_XGBE=y
-
 CONFIG_ALLWINNER_A10_PIT=y
 CONFIG_ALLWINNER_A10_PIC=y
 CONFIG_ALLWINNER_A10=y
@@ -84,10 +77,5 @@ CONFIG_PCIE_PORT=y
 CONFIG_XIO3130=y
 CONFIG_IOH3420=y
 CONFIG_I82801B11=y
-CONFIG_ACPI=y
-CONFIG_ARM_VIRT=y
-CONFIG_SMBIOS=y
-CONFIG_GPIO_KEY=y
 CONFIG_MSF2=y
-CONFIG_FW_CFG_DMA=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index a4fe2c8..3d580fa 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -1,5 +1,23 @@
 config ARM_VIRT
 bool
+imply PCI_DEVICES
+imply VFIO_AMD_XGBE
+imply VFIO_XGMAC
+select A15MPCORE
+select ACPI
+select ARM_SMMUV3
+select GPIO_KEY
+select FW_CFG_DMA
+select PCI_EXPRESS
+select PCI_EXPRESS_GENERIC_BRIDGE
+select PFLASH_CFI01
+select PL011 # UART
+select PL031 # RTC
+select PL061 # GPIO
+select PLATFORM_BUS
+select SMBIOS
+select VIRTIO_MMIO
+select VFIO_PLATFORM
 
 config CHEETAH
 bool
@@ -314,6 +332,7 @@ config A9MPCORE
 
 config A15MPCORE
 bool
+select ARM_GIC
 
 config ARM11MPCORE
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 053fcb6..f17187f 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -1,4 +1,5 @@
-obj-y += boot.o sysbus-fdt.o
+obj-y += boot.o
+obj-$(CONFIG_PLATFORM_BUS) += sysbus-fdt.o
 obj-$(CONFIG_ARM_VIRT) += virt.o
 obj-$(CONFIG_ACPI) += virt-acpi-build.o
 obj-$(CONFIG_DIGIC) += digic_boards.o
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 22/25] hw/arm: Express dependencies of the microbit / nrf51 machine with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the NRF51 / microbit machine.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 3 +--
 hw/arm/Kconfig  | 6 ++
 hw/arm/Makefile.objs| 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index ebe5de6..c1bc6ac 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -31,11 +31,10 @@ CONFIG_RASPI=y
 CONFIG_DIGIC=y
 CONFIG_SABRELITE=y
 CONFIG_EMCRAFT_SF2=y
+CONFIG_MICROBIT=y
 
 CONFIG_VGA=y
 
-CONFIG_NRF51_SOC=y
-
 CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index c2fba8e..3d96d1b 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -373,8 +373,14 @@ config FSL_IMX6UL
 select IMX_I2C
 select SDHCI
 
+config MICROBIT
+bool
+select NRF51_SOC
+
 config NRF51_SOC
 bool
+select I2C
+select ARM_V7M
 
 config EMCRAFT_SF2
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 29dc7d9..88b90ca 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -8,6 +8,7 @@ obj-$(CONFIG_EMCRAFT_SF2) += msf2-som.o
 obj-$(CONFIG_HIGHBANK) += highbank.o
 obj-$(CONFIG_INTEGRATOR) += integratorcp.o
 obj-$(CONFIG_MAINSTONE) += mainstone.o
+obj-$(CONFIG_MICROBIT) += microbit.o
 obj-$(CONFIG_MUSICPAL) += musicpal.o
 obj-$(CONFIG_NETDUINO2) += netduino2.o
 obj-$(CONFIG_NSERIES) += nseries.o
@@ -47,4 +48,4 @@ obj-$(CONFIG_ARMSSE) += armsse.o
 obj-$(CONFIG_FSL_IMX7) += fsl-imx7.o mcimx7d-sabre.o
 obj-$(CONFIG_ARM_SMMUV3) += smmu-common.o smmuv3.o
 obj-$(CONFIG_FSL_IMX6UL) += fsl-imx6ul.o mcimx6ul-evk.o
-obj-$(CONFIG_NRF51_SOC) += nrf51_soc.o microbit.o
+obj-$(CONFIG_NRF51_SOC) += nrf51_soc.o
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 25/25] hw/arm: Remove hard-enablement of the remaining PCI devices

[Thomas Huth]

The PCI devices should be pulled in by default if PCI_DEVICES
is set, so there is no need anymore to enforce them in the configs
file.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 8 
 1 file changed, 8 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index c1bc6ac..19c84ac 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -32,14 +32,6 @@ CONFIG_DIGIC=y
 CONFIG_SABRELITE=y
 CONFIG_EMCRAFT_SF2=y
 CONFIG_MICROBIT=y
-
-CONFIG_VGA=y
-
 CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
-
-CONFIG_PCIE_PORT=y
-CONFIG_XIO3130=y
-CONFIG_IOH3420=y
-CONFIG_I82801B11=y
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 23/25] hw/arm: Express dependencies of the ZynqMP zcu102 machine with Kconfig

[Thomas Huth]

This cleans up most settings in default-configs/aarch64-softmmu.mak.

Signed-off-by: Thomas Huth 
---
 default-configs/aarch64-softmmu.mak |  4 
 hw/arm/Kconfig  | 11 +++
 hw/display/Kconfig  |  1 +
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/default-configs/aarch64-softmmu.mak 
b/default-configs/aarch64-softmmu.mak
index 4ea9add..3a4b15e 100644
--- a/default-configs/aarch64-softmmu.mak
+++ b/default-configs/aarch64-softmmu.mak
@@ -3,10 +3,6 @@
 # We support all the 32 bit boards so need all their config
 include arm-softmmu.mak
 
-CONFIG_AUX=y
-CONFIG_DDC=y
-CONFIG_DPCD=y
-CONFIG_XLNX_ZYNQMP=y
 CONFIG_XLNX_ZYNQMP_ARM=y
 CONFIG_XLNX_VERSAL=y
 CONFIG_ARM_SMMUV3=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 3d96d1b..721cc07 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -289,6 +289,17 @@ config STM32F205_SOC
 
 config XLNX_ZYNQMP_ARM
 bool
+select AHCI
+select ARM_GIC
+select CADENCE
+select DDC
+select DPCD
+select SDHCI
+select SSI
+select SSI_M25P80
+select XILINX_AXI
+select XILINX_SPIPS
+select XLNX_ZYNQMP
 
 config XLNX_VERSAL
 bool
diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index a5f3fc0..d2ae2f1 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -108,3 +108,4 @@ config VIRTIO_VGA
 
 config DPCD
 bool
+select AUX
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 03/25] hw/arm: Express dependencies of integratorcp with Kconfig

[Thomas Huth]

This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 11 +--
 hw/arm/Kconfig  |  9 +
 hw/display/Kconfig  |  1 +
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 59734ee..2033050 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -7,6 +7,7 @@ CONFIG_PCI_DEVICES=y
 
 CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
+CONFIG_INTEGRATOR=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
@@ -31,7 +32,6 @@ CONFIG_ADS7846=y
 CONFIG_MAX111X=y
 CONFIG_SSI_SD=y
 CONFIG_SSI_M25P80=y
-CONFIG_SMC91C111=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
 CONFIG_FTGMAC100=y
@@ -49,15 +49,8 @@ CONFIG_A15MPCORE=y
 
 CONFIG_NETDUINO2=y
 
-CONFIG_ARM_TIMER=y
-CONFIG_PL011=y
-CONFIG_PL022=y
-CONFIG_PL031=y
 CONFIG_PL041=y
-CONFIG_PL050=y
 CONFIG_PL080=y
-CONFIG_PL110=y
-CONFIG_PL181=y
 CONFIG_PL190=y
 CONFIG_PL330=y
 CONFIG_CADENCE=y
@@ -119,8 +112,6 @@ CONFIG_VFIO_XGMAC=y
 CONFIG_VFIO_AMD_XGBE=y
 
 CONFIG_SDHCI=y
-CONFIG_INTEGRATOR=y
-CONFIG_INTEGRATOR_DEBUG=y
 
 CONFIG_ALLWINNER_A10_PIT=y
 CONFIG_ALLWINNER_A10_PIC=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 984de8a..c022b8d 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -33,6 +33,15 @@ config HIGHBANK
 
 config INTEGRATOR
 bool
+select ARM_TIMER
+select INTEGRATOR_DEBUG
+select PL011 # UART
+select PL031 # RTC
+select PL050 # keyboard/mouse
+select PL110 # pl111 LCD controller
+select PL181 # display
+select PCI
+select SMC91C111
 
 config MAINSTONE
 bool
diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index ee3acd9..34c8c12 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -21,6 +21,7 @@ config JAZZ_LED
 
 config PL110
 bool
+select FRAMEBUFFER
 
 config SII9022
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 12/25] hw/arm: Express dependencies of the aspeed boards with Kconfig

[Thomas Huth]

Dependencies have been determined by looking at hw/arm/aspeed.c

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak |  7 +--
 hw/arm/Kconfig  | 10 ++
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 9851068..b2e31b3 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -22,15 +22,12 @@ CONFIG_SPITZ=y
 CONFIG_TOSA=y
 CONFIG_Z2=y
 CONFIG_COLLIE=y
+CONFIG_ASPEED_SOC=y
 
 CONFIG_VGA=y
-CONFIG_TMP421=y
-CONFIG_PCA9552=y
 CONFIG_SSI_M25P80=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
-CONFIG_FTGMAC100=y
-CONFIG_DS1338=y
 CONFIG_PLATFORM_BUS=y
 CONFIG_VIRTIO_MMIO=y
 
@@ -90,8 +87,6 @@ CONFIG_I82801B11=y
 CONFIG_ACPI=y
 CONFIG_ARM_VIRT=y
 CONFIG_SMBIOS=y
-CONFIG_ASPEED_SOC=y
-CONFIG_SMBUS_EEPROM=y
 CONFIG_GPIO_KEY=y
 CONFIG_MSF2=y
 CONFIG_FW_CFG_DMA=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 39cbda9..a4fe2c8 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -267,6 +267,16 @@ config FSL_IMX6
 
 config ASPEED_SOC
 bool
+select DS1338
+select FTGMAC100
+select I2C
+select PCA9552
+select SERIAL
+select SMBUS_EEPROM
+select SSI
+select SSI_M25P80
+select TMP105
+select TMP421
 
 config MPS2
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 20/25] hw/arm: Express dependencies of the MSF2 machine with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the emcraft-sf2 machine - we also
distinguis between the machine (CONFIG_EMCRAFT_SF2) and the SoC
(CONFIG_MSF2) now.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 3 +--
 hw/arm/Kconfig  | 8 
 hw/arm/Makefile.objs| 3 ++-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index f6193b1..5eceeba 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -30,9 +30,9 @@ CONFIG_MPS2=y
 CONFIG_RASPI=y
 CONFIG_DIGIC=y
 CONFIG_SABRELITE=y
+CONFIG_EMCRAFT_SF2=y
 
 CONFIG_VGA=y
-CONFIG_SSI_M25P80=y
 CONFIG_IMX_FEC=y
 
 CONFIG_NRF51_SOC=y
@@ -45,5 +45,4 @@ CONFIG_PCIE_PORT=y
 CONFIG_XIO3130=y
 CONFIG_IOH3420=y
 CONFIG_I82801B11=y
-CONFIG_MSF2=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 70fc73f..cebb410 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -358,9 +358,17 @@ config FSL_IMX6UL
 config NRF51_SOC
 bool
 
+config EMCRAFT_SF2
+bool
+select MSF2
+select SSI_M25P80
+
 config MSF2
 bool
+select ARM_V7M
 select PTIMER
+select SERIAL
+select SSI
 
 config ZAURUS
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index ee9f5c6..29dc7d9 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARM_VIRT) += virt.o
 obj-$(CONFIG_ACPI) += virt-acpi-build.o
 obj-$(CONFIG_DIGIC) += digic_boards.o
 obj-$(CONFIG_EXYNOS4) += exynos4_boards.o
+obj-$(CONFIG_EMCRAFT_SF2) += msf2-som.o
 obj-$(CONFIG_HIGHBANK) += highbank.o
 obj-$(CONFIG_INTEGRATOR) += integratorcp.o
 obj-$(CONFIG_MAINSTONE) += mainstone.o
@@ -41,7 +42,7 @@ obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_soc.o aspeed.o
 obj-$(CONFIG_MPS2) += mps2.o
 obj-$(CONFIG_MPS2) += mps2-tz.o
-obj-$(CONFIG_MSF2) += msf2-soc.o msf2-som.o
+obj-$(CONFIG_MSF2) += msf2-soc.o
 obj-$(CONFIG_ARMSSE) += armsse.o
 obj-$(CONFIG_FSL_IMX7) += fsl-imx7.o mcimx7d-sabre.o
 obj-$(CONFIG_ARM_SMMUV3) += smmu-common.o smmuv3.o
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 19/25] hw/arm: Express dependencies of sabrelite with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the Sabrelite / iMX6 machine.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 4 +---
 hw/arm/Kconfig  | 7 +++
 hw/arm/Makefile.objs| 3 ++-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 20fcbcb..f6193b1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -29,6 +29,7 @@ CONFIG_NETDUINO2=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
 CONFIG_DIGIC=y
+CONFIG_SABRELITE=y
 
 CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
@@ -36,13 +37,10 @@ CONFIG_IMX_FEC=y
 
 CONFIG_NRF51_SOC=y
 
-CONFIG_FSL_IMX6=y
 CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
 
-CONFIG_IMX_I2C=y
-
 CONFIG_PCIE_PORT=y
 CONFIG_XIO3130=y
 CONFIG_IOH3420=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 80a3b1f..70fc73f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -184,6 +184,10 @@ config REALVIEW
 select DS1338 # I2C RTC+NVRAM
 select USB_OHCI
 
+config SABRELITE
+bool
+select FSL_IMX6
+
 config STELLARIS
 bool
 select ARM_V7M
@@ -302,6 +306,9 @@ config FSL_IMX31
 
 config FSL_IMX6
 bool
+select A9MPCORE
+select IMX
+select IMX_I2C
 
 config ASPEED_SOC
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index f17187f..ee9f5c6 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -22,6 +22,7 @@ obj-$(CONFIG_COLLIE) += collie.o
 obj-$(CONFIG_VERSATILE) += versatilepb.o
 obj-$(CONFIG_VEXPRESS) += vexpress.o
 obj-$(CONFIG_ZYNQ) += xilinx_zynq.o
+obj-$(CONFIG_SABRELITE) += sabrelite.o
 
 obj-$(CONFIG_ARM_V7M) += armv7m.o
 obj-$(CONFIG_EXYNOS4) += exynos4210.o
@@ -36,7 +37,7 @@ obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx-zynqmp.o xlnx-zcu102.o
 obj-$(CONFIG_XLNX_VERSAL) += xlnx-versal.o xlnx-versal-virt.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
 obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
-obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o sabrelite.o
+obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_soc.o aspeed.o
 obj-$(CONFIG_MPS2) += mps2.o
 obj-$(CONFIG_MPS2) += mps2-tz.o
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 16/25] hw/arm: Express dependencies of the MPS2 boards with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the mps2-an* machines.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 19 +--
 hw/arm/Kconfig  | 17 +
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 28bb37f..b530a06 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -26,6 +26,7 @@ CONFIG_Z2=y
 CONFIG_COLLIE=y
 CONFIG_ASPEED_SOC=y
 CONFIG_NETDUINO2=y
+CONFIG_MPS2=y
 
 CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
@@ -34,27 +35,9 @@ CONFIG_IMX_FEC=y
 CONFIG_FRAMEBUFFER=y
 
 CONFIG_DIGIC=y
-CONFIG_MPS2=y
 CONFIG_RASPI=y
 CONFIG_NRF51_SOC=y
 
-CONFIG_CMSDK_APB_TIMER=y
-CONFIG_CMSDK_APB_DUALTIMER=y
-CONFIG_CMSDK_APB_UART=y
-CONFIG_CMSDK_APB_WATCHDOG=y
-
-CONFIG_MPS2_FPGAIO=y
-CONFIG_MPS2_SCC=y
-
-CONFIG_TZ_MPC=y
-CONFIG_TZ_MSC=y
-CONFIG_TZ_PPC=y
-CONFIG_ARMSSE=y
-CONFIG_IOTKIT_SECCTL=y
-CONFIG_IOTKIT_SYSCTL=y
-CONFIG_IOTKIT_SYSINFO=y
-CONFIG_ARMSSE_CPUID=y
-
 CONFIG_FSL_IMX6=y
 CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 3d78102..d17bd2f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -314,6 +314,23 @@ config ASPEED_SOC
 
 config MPS2
 bool
+select ARMSSE
+select ARMSSE_CPUID
+select CMSDK_APB_TIMER
+select CMSDK_APB_DUALTIMER
+select CMSDK_APB_UART
+select CMSDK_APB_WATCHDOG
+select IOTKIT_SECCTL
+select IOTKIT_SYSCTL
+select IOTKIT_SYSINFO
+select LAN9118
+select MPS2_FPGAIO
+select MPS2_SCC
+select PL022# Serial port
+select PL080# DMA controller
+select TZ_MPC
+select TZ_MSC
+select TZ_PPC
 
 config IOTKIT
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 10/25] hw/arm: Express dependencies of xilinx-zynq with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the xilinx-zynq-a9 board.
This patch is based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak |  7 +--
 hw/arm/Kconfig  | 14 ++
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 1db76f6..5c43bb3 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -15,6 +15,7 @@ CONFIG_STELLARIS=y
 CONFIG_REALVIEW=y
 CONFIG_VERSATILE=y
 CONFIG_VEXPRESS=y
+CONFIG_ZYNQ=y
 CONFIG_MAINSTONE=y
 CONFIG_GUMSTIX=y
 CONFIG_SPITZ=y
@@ -34,16 +35,11 @@ CONFIG_VIRTIO_MMIO=y
 
 CONFIG_NETDUINO2=y
 
-CONFIG_PL330=y
-CONFIG_CADENCE=y
 CONFIG_FRAMEBUFFER=y
-CONFIG_XILINX_SPIPS=y
-CONFIG_ZYNQ_DEVCFG=y
 
 CONFIG_DIGIC=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
-CONFIG_ZYNQ=y
 CONFIG_STM32F2XX_TIMER=y
 CONFIG_STM32F2XX_USART=y
 CONFIG_STM32F2XX_SYSCFG=y
@@ -98,7 +94,6 @@ CONFIG_SMBUS_EEPROM=y
 CONFIG_GPIO_KEY=y
 CONFIG_MSF2=y
 CONFIG_FW_CFG_DMA=y
-CONFIG_XILINX_AXI=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
 
 CONFIG_STRONGARM=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 95f2713..67f1228 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -208,6 +208,20 @@ config VEXPRESS
 
 config ZYNQ
 bool
+select A9MPCORE
+select CADENCE # UART
+select PCI
+select PFLASH_CFI02
+select PL330
+select SDHCI
+select SSI_M25P80
+select USB_EHCI
+select USB_EHCI_SYSBUS
+select XILINX # UART
+select XILINX_AXI
+select XILINX_SPI
+select XILINX_SPIPS
+select ZYNQ_DEVCFG
 
 config ARM_V7M
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 15/25] hw/arm: Express dependencies of allwinner / cubieboard with Kconfig

[Thomas Huth]

Add dependencies for the Cubitech Cubieboard.

Note that CONFIG_AHCI has a hard dependency on CONFIG_PCI currently,
so PCI is now always selected by AHCI, even for boards that only
want to use AHCI via a sysbus device. We should break up that
dependency later by splitting ahci.c into sysbus and pci parts.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 6 +-
 hw/arm/Kconfig  | 9 +
 hw/ide/Kconfig  | 2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 3279fb5..28bb37f 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -4,6 +4,7 @@
 CONFIG_ARM_V7M=y
 
 CONFIG_ARM_VIRT=y
+CONFIG_CUBIEBOARD=y
 CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
 CONFIG_INTEGRATOR=y
@@ -28,7 +29,6 @@ CONFIG_NETDUINO2=y
 
 CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
-CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
 
 CONFIG_FRAMEBUFFER=y
@@ -55,10 +55,6 @@ CONFIG_IOTKIT_SYSCTL=y
 CONFIG_IOTKIT_SYSINFO=y
 CONFIG_ARMSSE_CPUID=y
 
-CONFIG_ALLWINNER_A10_PIT=y
-CONFIG_ALLWINNER_A10_PIC=y
-CONFIG_ALLWINNER_A10=y
-
 CONFIG_FSL_IMX6=y
 CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 5d7dafb..3d78102 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -24,6 +24,10 @@ config CHEETAH
 select OMAP
 select TSC210X
 
+config CUBIEBOARD
+bool
+select ALLWINNER_A10
+
 config DIGIC
 bool
 select PTIMER
@@ -257,6 +261,11 @@ config EXYNOS4
 
 config ALLWINNER_A10
 bool
+select AHCI
+select ALLWINNER_A10_PIT
+select ALLWINNER_A10_PIC
+select ALLWINNER_EMAC
+select SERIAL
 
 config RASPI
 bool
diff --git a/hw/ide/Kconfig b/hw/ide/Kconfig
index ab47b6a..c457f60 100644
--- a/hw/ide/Kconfig
+++ b/hw/ide/Kconfig
@@ -45,7 +45,7 @@ config MICRODRIVE
 config AHCI
 bool
 default y if PCI_DEVICES
-depends on PCI
+select PCI# TODO: Split up ahci.c into sysbus and pci parts
 select IDE_QDEV
 
 config IDE_SII3112
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 18/25] hw/arm: Express dependencies of canon-a1100 with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the DIGIC / canon-a1100 machine.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 2 +-
 hw/arm/Kconfig  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 6605786..20fcbcb 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -28,12 +28,12 @@ CONFIG_ASPEED_SOC=y
 CONFIG_NETDUINO2=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
+CONFIG_DIGIC=y
 
 CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
 CONFIG_IMX_FEC=y
 
-CONFIG_DIGIC=y
 CONFIG_NRF51_SOC=y
 
 CONFIG_FSL_IMX6=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index bb385a5..80a3b1f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -31,6 +31,7 @@ config CUBIEBOARD
 config DIGIC
 bool
 select PTIMER
+select PFLASH_CFI02
 
 config EXYNOS4
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 09/25] hw/arm: Express dependencies of the PXA2xx machines with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the PXA2xx machines (akita, borzoi,
connex and verdex gumstix, tosa, mainstone, spitz, terrier and z2).
This patch is based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 17 +--
 hw/arm/Kconfig  | 46 +
 hw/arm/Makefile.objs|  5 -
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 2bac13b..1db76f6 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -15,22 +15,20 @@ CONFIG_STELLARIS=y
 CONFIG_REALVIEW=y
 CONFIG_VERSATILE=y
 CONFIG_VEXPRESS=y
+CONFIG_MAINSTONE=y
+CONFIG_GUMSTIX=y
+CONFIG_SPITZ=y
+CONFIG_TOSA=y
+CONFIG_Z2=y
 
 CONFIG_VGA=y
-CONFIG_NAND=y
-CONFIG_ECC=y
-CONFIG_SERIAL=y
-CONFIG_MAX7310=y
 CONFIG_TMP421=y
 CONFIG_PCA9552=y
-CONFIG_ADS7846=y
-CONFIG_MAX111X=y
 CONFIG_SSI_M25P80=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
 CONFIG_FTGMAC100=y
 CONFIG_DS1338=y
-CONFIG_MICRODRIVE=y
 CONFIG_PLATFORM_BUS=y
 CONFIG_VIRTIO_MMIO=y
 
@@ -38,16 +36,13 @@ CONFIG_NETDUINO2=y
 
 CONFIG_PL330=y
 CONFIG_CADENCE=y
-CONFIG_PXA2XX=y
 CONFIG_FRAMEBUFFER=y
 CONFIG_XILINX_SPIPS=y
 CONFIG_ZYNQ_DEVCFG=y
 
 CONFIG_DIGIC=y
-CONFIG_MAINSTONE=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
-CONFIG_ZAURUS=y
 CONFIG_ZYNQ=y
 CONFIG_STM32F2XX_TIMER=y
 CONFIG_STM32F2XX_USART=y
@@ -80,8 +75,6 @@ CONFIG_VFIO_PLATFORM=y
 CONFIG_VFIO_XGMAC=y
 CONFIG_VFIO_AMD_XGBE=y
 
-CONFIG_SDHCI=y
-
 CONFIG_ALLWINNER_A10_PIT=y
 CONFIG_ALLWINNER_A10_PIC=y
 CONFIG_ALLWINNER_A10=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index b76fd7c..95f2713 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -89,6 +89,50 @@ config OMAP
 
 config PXA2XX
 bool
+select FRAMEBUFFER
+select I2C
+select PCI
+select SERIAL
+select SD
+select SSI
+select USB_OHCI
+
+config GUMSTIX
+bool
+select PFLASH_CFI01
+select SMC91C111
+select PXA2XX
+
+config TOSA
+bool
+select ZAURUS  # scoop
+select MICRODRIVE
+select PXA2XX
+
+config MAINSTONE
+bool
+select PXA2XX
+select PFLASH_CFI01
+select SMC91C111
+
+config SPITZ
+bool
+select ADS7846 # display
+select MAX111X # A/D converter
+select WM8750  # audio codec
+select MAX7310 # GPIO expander
+select ZAURUS  # scoop
+select NAND# memory
+select ECC # Error-correcting for NAND
+select MICRODRIVE
+select PXA2XX
+
+config Z2
+bool
+select PFLASH_CFI01
+select WM8750
+select PL011 # UART
+select PXA2XX
 
 config REALVIEW
 bool
@@ -227,6 +271,8 @@ config MSF2
 
 config ZAURUS
 bool
+select NAND
+select ECC
 
 config A9MPCORE
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 420641e..93e1160 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -11,7 +11,10 @@ obj-$(CONFIG_NETDUINO2) += netduino2.o
 obj-$(CONFIG_NSERIES) += nseries.o
 obj-$(CONFIG_SX1) += omap_sx1.o
 obj-$(CONFIG_CHEETAH) += palm.o
-obj-$(CONFIG_PXA2XX) += gumstix.o spitz.o tosa.o z2.o
+obj-$(CONFIG_GUMSTIX) += gumstix.o
+obj-$(CONFIG_SPITZ) += spitz.o
+obj-$(CONFIG_TOSA) += tosa.o
+obj-$(CONFIG_Z2) += z2.o
 obj-$(CONFIG_REALVIEW) += realview.o
 obj-$(CONFIG_STELLARIS) += stellaris.o
 obj-$(CONFIG_STRONGARM) += collie.o
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v3 0/3] Trivial cleanup in hw/acpi

[Philippe Mathieu-Daudé]

Hi Laurent,

On 2/13/19 9:49 AM, Laurent Vivier wrote:
> On 12/02/2019 06:34, Michael S. Tsirkin wrote:
>> On Tue, Feb 12, 2019 at 01:22:24PM +0800, Wei Yang wrote:
>>> On Wed, Jan 30, 2019 at 08:06:50AM +0800, Wei Yang wrote:
 There are several functions/variable which are not used anymore.

 This serials just remove those without functional change.

 v3: add ack and repost in a new thread
 v2: change commit log from "is now used in no place" to "in not used 
 anymore"
>>>
>>> Michael,
>>>
>>> Looks this serials is not merged yet.
>>>
>>> Is there any problem I need to fix?
>>
>> Yes pls repost with fixed reviewed-by tags.
> 
> Or I can take the series through the trivial branch and update manually
> Philippe's lastname?

I appreciate the help with manual update, however Wei is not the only
one having this problem (other developpers has non-ASCII in their name,
and use such tags).
I'd rather prefer we find a proper configuration setup to help the
community.

Another (fair) approach is to forbid non-ASCII chars in all part of patches.

Regards,

Phil.

[Qemu-devel] [PATCH v2 11/25] hw/arm: Express dependencies of collie with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the Strongarm collie machine.
This patch is based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 3 +--
 hw/arm/Kconfig  | 7 +++
 hw/arm/Makefile.objs| 2 +-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 5c43bb3..9851068 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -21,6 +21,7 @@ CONFIG_GUMSTIX=y
 CONFIG_SPITZ=y
 CONFIG_TOSA=y
 CONFIG_Z2=y
+CONFIG_COLLIE=y
 
 CONFIG_VGA=y
 CONFIG_TMP421=y
@@ -95,5 +96,3 @@ CONFIG_GPIO_KEY=y
 CONFIG_MSF2=y
 CONFIG_FW_CFG_DMA=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
-
-CONFIG_STRONGARM=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 67f1228..39cbda9 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -175,6 +175,13 @@ config STELLARIS
 
 config STRONGARM
 bool
+select PXA2XX
+
+config COLLIE
+bool
+select PFLASH_CFI01
+select ZAURUS  # scoop
+select STRONGARM
 
 config SX1
 bool
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 93e1160..053fcb6 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -17,7 +17,7 @@ obj-$(CONFIG_TOSA) += tosa.o
 obj-$(CONFIG_Z2) += z2.o
 obj-$(CONFIG_REALVIEW) += realview.o
 obj-$(CONFIG_STELLARIS) += stellaris.o
-obj-$(CONFIG_STRONGARM) += collie.o
+obj-$(CONFIG_COLLIE) += collie.o
 obj-$(CONFIG_VERSATILE) += versatilepb.o
 obj-$(CONFIG_VEXPRESS) += vexpress.o
 obj-$(CONFIG_ZYNQ) += xilinx_zynq.o
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 14/25] hw/arm: Express dependencies of netduino / stm32f2xx with Kconfig

[Thomas Huth]

Netduino only depends on the stm32f205 SoC which in turn depends on
its components.

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 9 +
 hw/arm/Kconfig  | 7 +++
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 9db6808..3279fb5 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -24,25 +24,18 @@ CONFIG_TOSA=y
 CONFIG_Z2=y
 CONFIG_COLLIE=y
 CONFIG_ASPEED_SOC=y
+CONFIG_NETDUINO2=y
 
 CONFIG_VGA=y
 CONFIG_SSI_M25P80=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
 
-CONFIG_NETDUINO2=y
-
 CONFIG_FRAMEBUFFER=y
 
 CONFIG_DIGIC=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
-CONFIG_STM32F2XX_TIMER=y
-CONFIG_STM32F2XX_USART=y
-CONFIG_STM32F2XX_SYSCFG=y
-CONFIG_STM32F2XX_ADC=y
-CONFIG_STM32F2XX_SPI=y
-CONFIG_STM32F205_SOC=y
 CONFIG_NRF51_SOC=y
 
 CONFIG_CMSDK_APB_TIMER=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 3d580fa..5d7dafb 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -81,6 +81,7 @@ config MUSICPAL
 
 config NETDUINO2
 bool
+select STM32F205_SOC
 
 config NSERIES
 bool
@@ -262,6 +263,12 @@ config RASPI
 
 config STM32F205_SOC
 bool
+select ARM_V7M
+select STM32F2XX_TIMER
+select STM32F2XX_USART
+select STM32F2XX_SYSCFG
+select STM32F2XX_ADC
+select STM32F2XX_SPI
 
 config XLNX_ZYNQMP_ARM
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 07/25] hw/arm: Express dependencies of stellaris with Kconfig

[Thomas Huth]

This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak |  7 +--
 hw/arm/Kconfig  | 10 ++
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 492db53..1be49bd 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -13,6 +13,7 @@ CONFIG_MUSICPAL=y
 CONFIG_CHEETAH=y
 CONFIG_SX1=y
 CONFIG_NSERIES=y
+CONFIG_STELLARIS=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
@@ -21,16 +22,10 @@ CONFIG_SERIAL=y
 CONFIG_MAX7310=y
 CONFIG_TMP421=y
 CONFIG_PCA9552=y
-CONFIG_STELLARIS=y
-CONFIG_STELLARIS_INPUT=y
-CONFIG_STELLARIS_ENET=y
-CONFIG_SSD0303=y
-CONFIG_SSD0323=y
 CONFIG_DDC=y
 CONFIG_SII9022=y
 CONFIG_ADS7846=y
 CONFIG_MAX111X=y
-CONFIG_SSI_SD=y
 CONFIG_SSI_M25P80=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index fe1505e..3034252 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -95,6 +95,16 @@ config REALVIEW
 
 config STELLARIS
 bool
+select ARM_V7M
+select I2C
+select PL011 # UART
+select PL022 # Serial port
+select PL061 # GPIO
+select SSD0303 # OLED display
+select SSD0323 # OLED display
+select SSI_SD
+select STELLARIS_INPUT
+select STELLARIS_ENET # ethernet
 
 config STRONGARM
 bool
-- 
1.8.3.1

Re: [Qemu-devel] [RFC v1 2/3] intel_iommu: add 256 bits qi_desc support

[Yi Sun]

On 19-02-12 14:27:28, Peter Xu wrote:
> On Wed, Jan 30, 2019 at 01:09:12PM +0800, Yi Sun wrote:
> > From: "Liu, Yi L" 
> > 
> > Per Intel(R) VT-d 3.0, the qi_desc is 256 bits in Scalable
> > Mode. This patch adds emulation of 256bits qi_desc.
> > 
> > [Yi Sun is co-developer to rebase and refine the patch.]
> > Signed-off-by: Yi Sun 
> > Signed-off-by: Liu, Yi L 
> 
> Same here; I think you should have your s-o-b last. ;)
> 
Sure.

> > ---
> >  hw/i386/intel_iommu.c  | 182 
> > +
> >  hw/i386/intel_iommu_internal.h |   8 +-
> >  include/hw/i386/intel_iommu.h  |   1 +
> >  3 files changed, 116 insertions(+), 75 deletions(-)
> > 
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index 396ac8e..3664a00 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -38,6 +38,7 @@
> >  #include "trace.h"
> >  
> >  #define vtd_devfn_check(devfn) ((devfn & VTD_DEVFN_CHECK_MASK) ? true : 
> > false)
> > +#define vtd_ecap_smts(s) ((s)->ecap & VTD_ECAP_SMTS)
> 
> I'd prefer capital letters for macros.  Your call.
> 
Will change them.

> >  
> >  /* context entry operations */
> >  #define vtd_get_ce_size(s, ce) \
> > @@ -65,6 +66,9 @@
> >  #define vtd_pe_get_slpt_base(pe) ((pe)->val[0] & 
> > VTD_SM_PASID_ENTRY_SLPTPTR)
> >  #define vtd_pe_get_domain_id(pe) VTD_SM_PASID_ENTRY_DID((pe)->val[1])
> >  
> > +/* invalidation desc */
> > +#define vtd_get_inv_desc_width(s) ((s)->iq_dw ? 32 : 16)
> 
> Nit: I'll prefer dropping all the "get" wordings in these macros to be
> "vtd_inv_desc_width" since that "get" doesn't help much on
> understanding its meanings.  But it's personal preference too.
> 
That is fine.

> And since you've already have the iq_dw variable - why not store the
> width directly into it?  An uint8_t would suffice.
> 
iq_dw corresponds to VTD_IQA_DW_MASK (Descriptor Width defined in IQA
register). 1 means 256-bit descriptor, 0 means 128-bit descriptor.

It is also used in vtd_handle_gcmd_qie() and VTD_IQT_QT() by checking if
its value is 1.

So, I would prefer to keep the original design.

> > +
> >  static void vtd_address_space_refresh_all(IntelIOMMUState *s);
> >  static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n);
> >  
> > @@ -1759,6 +1763,11 @@ static void vtd_root_table_setup(IntelIOMMUState *s)
> >  s->root_scalable = s->root & VTD_RTADDR_SMT;
> >  s->root &= VTD_RTADDR_ADDR_MASK(s->aw_bits);
> >  
> > +/* if Scalable mode is not enabled, enforce iq_dw to be 16 byte */
> > +if (!s->root_scalable) {
> > +s->iq_dw = 0;
> 
> This is ok but I feel it a bit awkward to change IQ setup specifically
> in root table setup.  You can simply do this:
> 
> - in vtd_init(), always set iq_dw=16.  This will cover system resets
>   or IOMMU device reset, then
> 
Per above explanation, I can make iq_dw=0 in vtd_init().

> - only update iq_dw to 32 in vtd_mem_write() where guest specified
> 
May add check of s->root_scalable in vtd_mem_write().

> > +}
> > +
> >  trace_vtd_reg_dmar_root(s->root, s->root_extended);
> >  }
> >  
> > @@ -2052,7 +2061,7 @@ static void vtd_handle_gcmd_qie(IntelIOMMUState *s, 
> > bool en)
> >  if (en) {
> >  s->iq = iqa_val & VTD_IQA_IQA_MASK(s->aw_bits);
> >  /* 2^(x+8) entries */
> > -s->iq_size = 1UL << ((iqa_val & VTD_IQA_QS) + 8);
> > +s->iq_size = 1UL << ((iqa_val & VTD_IQA_QS) + 8 - (s->iq_dw ? 1 : 
> > 0));
> >  s->qi_enabled = true;
> >  trace_vtd_inv_qi_setup(s->iq, s->iq_size);
> >  /* Ok - report back to driver */
> > @@ -2219,54 +2228,66 @@ static void vtd_handle_iotlb_write(IntelIOMMUState 
> > *s)
> >  }
> >  
> >  /* Fetch an Invalidation Descriptor from the Invalidation Queue */
> > -static bool vtd_get_inv_desc(dma_addr_t base_addr, uint32_t offset,
> > +static bool vtd_get_inv_desc(IntelIOMMUState *s,
> >   VTDInvDesc *inv_desc)
> >  {
> > -dma_addr_t addr = base_addr + offset * sizeof(*inv_desc);
> > -if (dma_memory_read(&address_space_memory, addr, inv_desc,
> > -sizeof(*inv_desc))) {
> > -error_report_once("Read INV DESC failed");
> > -inv_desc->lo = 0;
> > -inv_desc->hi = 0;
> > +dma_addr_t base_addr = s->iq;
> > +uint32_t offset = s->iq_head;
> > +uint32_t dw = vtd_get_inv_desc_width(s);
> > +dma_addr_t addr = base_addr + offset * dw;
> > +
> > +/* init */
> > +inv_desc->val[0] = 0;
> > +inv_desc->val[1] = 0;
> > +inv_desc->val[2] = 0;
> > +inv_desc->val[3] = 0;
> 
> No need?
> 
This is necessary. Per my test, the val[] are not 0 by default. That
makes bug happen.

> > +
> > +if (dma_memory_read(&address_space_memory, addr, inv_desc, dw)) {
> > +error_report_once("Read INV DESC failed.");
> >  return false;
> >  }
> > -inv_desc->lo = le64_to_cpu(inv_desc->lo);
> > -inv_desc->hi = le64_to_cpu(inv_desc->hi);
> > +inv_desc->val[0] = le6

[Qemu-devel] [PATCH v2 05/25] hw/arm: Express dependencies of musicpal with Kconfig

[Thomas Huth]

This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 6 +-
 hw/arm/Kconfig  | 6 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 19d0ab0..fe7e306 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -9,13 +9,13 @@ CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
 CONFIG_INTEGRATOR=y
 CONFIG_FSL_IMX31=y
+CONFIG_MUSICPAL=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
 CONFIG_ECC=y
 CONFIG_SERIAL=y
 CONFIG_MAX7310=y
-CONFIG_WM8750=y
 CONFIG_TWL92230=y
 CONFIG_TSC2005=y
 CONFIG_LM832X=y
@@ -38,7 +38,6 @@ CONFIG_IMX_FEC=y
 CONFIG_FTGMAC100=y
 CONFIG_DS1338=y
 CONFIG_PFLASH_CFI01=y
-CONFIG_PFLASH_CFI02=y
 CONFIG_MICRODRIVE=y
 CONFIG_USB_MUSB=y
 CONFIG_PLATFORM_BUS=y
@@ -56,14 +55,12 @@ CONFIG_PL190=y
 CONFIG_PL330=y
 CONFIG_CADENCE=y
 CONFIG_PXA2XX=y
-CONFIG_BITBANG_I2C=y
 CONFIG_FRAMEBUFFER=y
 CONFIG_XILINX_SPIPS=y
 CONFIG_ZYNQ_DEVCFG=y
 
 CONFIG_ARM11SCU=y
 CONFIG_DIGIC=y
-CONFIG_MARVELL_88W8618=y
 CONFIG_OMAP=y
 CONFIG_TSC210X=y
 CONFIG_BLIZZARD=y
@@ -140,7 +137,6 @@ CONFIG_XILINX_AXI=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
 
 CONFIG_STRONGARM=y
-CONFIG_MUSICPAL=y
 
 # for realview and versatilepb
 CONFIG_LSI_SCSI_PCI=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 3d0ee29..aeb0cf0 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -48,7 +48,13 @@ config MAINSTONE
 
 config MUSICPAL
 bool
+select BITBANG_I2C
+select MARVELL_88W8618
 select PTIMER
+select PFLASH_CFI02
+select PCI
+select SERIAL
+select WM8750
 
 config NETDUINO2
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 06/25] hw/arm: Express dependencies of the OMAP machines with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the OMAP machines (cheetah, n800, n810,
sx1 and sx1-v1).
This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 15 +++
 hw/arm/Kconfig  | 26 ++
 hw/arm/Makefile.objs|  3 ++-
 3 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index fe7e306..492db53 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -10,16 +10,15 @@ CONFIG_HIGHBANK=y
 CONFIG_INTEGRATOR=y
 CONFIG_FSL_IMX31=y
 CONFIG_MUSICPAL=y
+CONFIG_CHEETAH=y
+CONFIG_SX1=y
+CONFIG_NSERIES=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
 CONFIG_ECC=y
 CONFIG_SERIAL=y
 CONFIG_MAX7310=y
-CONFIG_TWL92230=y
-CONFIG_TSC2005=y
-CONFIG_LM832X=y
-CONFIG_TMP105=y
 CONFIG_TMP421=y
 CONFIG_PCA9552=y
 CONFIG_STELLARIS=y
@@ -37,9 +36,7 @@ CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
 CONFIG_FTGMAC100=y
 CONFIG_DS1338=y
-CONFIG_PFLASH_CFI01=y
 CONFIG_MICRODRIVE=y
-CONFIG_USB_MUSB=y
 CONFIG_PLATFORM_BUS=y
 CONFIG_VIRTIO_MMIO=y
 
@@ -61,14 +58,8 @@ CONFIG_ZYNQ_DEVCFG=y
 
 CONFIG_ARM11SCU=y
 CONFIG_DIGIC=y
-CONFIG_OMAP=y
-CONFIG_TSC210X=y
-CONFIG_BLIZZARD=y
-CONFIG_ONENAND=y
-CONFIG_TUSB6010=y
 CONFIG_MAINSTONE=y
 CONFIG_MPS2=y
-CONFIG_NSERIES=y
 CONFIG_RASPI=y
 CONFIG_REALVIEW=y
 CONFIG_ZAURUS=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index aeb0cf0..fe1505e 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -1,6 +1,11 @@
 config ARM_VIRT
 bool
 
+config CHEETAH
+bool
+select OMAP
+select TSC210X
+
 config DIGIC
 bool
 select PTIMER
@@ -61,9 +66,26 @@ config NETDUINO2
 
 config NSERIES
 bool
+select OMAP
+select TMP105   # tempature sensor
+select BLIZZARD # LCD/TV controller
+select ONENAND
+select TSC210X  # touchscreen/sensors/audio
+select TSC2005  # touchscreen/sensors/keypad
+select LM832X   # GPIO keyboard chip
+select TWL92230 # energy-management
+select TUSB6010
 
 config OMAP
 bool
+select FRAMEBUFFER
+select I2C
+select ECC
+select NAND
+select PFLASH_CFI01
+select PCI
+select SD
+select SERIAL
 
 config PXA2XX
 bool
@@ -77,6 +99,10 @@ config STELLARIS
 config STRONGARM
 bool
 
+config SX1
+bool
+select OMAP
+
 config VERSATILE
 bool
 
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index fa40e8d..b0fd556 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -9,7 +9,8 @@ obj-$(CONFIG_MAINSTONE) += mainstone.o
 obj-$(CONFIG_MUSICPAL) += musicpal.o
 obj-$(CONFIG_NETDUINO2) += netduino2.o
 obj-$(CONFIG_NSERIES) += nseries.o
-obj-$(CONFIG_OMAP) += omap_sx1.o palm.o
+obj-$(CONFIG_SX1) += omap_sx1.o
+obj-$(CONFIG_CHEETAH) += palm.o
 obj-$(CONFIG_PXA2XX) += gumstix.o spitz.o tosa.o z2.o
 obj-$(CONFIG_REALVIEW) += realview.o
 obj-$(CONFIG_STELLARIS) += stellaris.o
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 02/25] hw/arm: Express dependencies of the highbank machines with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the highbank machine (and the midway
machine).
This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak |  4 +---
 hw/arm/Kconfig  | 12 
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 3baafc4..59734ee 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -6,6 +6,7 @@ CONFIG_ARM_V7M=y
 CONFIG_PCI_DEVICES=y
 
 CONFIG_EXYNOS4=y
+CONFIG_HIGHBANK=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
@@ -54,14 +55,12 @@ CONFIG_PL022=y
 CONFIG_PL031=y
 CONFIG_PL041=y
 CONFIG_PL050=y
-CONFIG_PL061=y
 CONFIG_PL080=y
 CONFIG_PL110=y
 CONFIG_PL181=y
 CONFIG_PL190=y
 CONFIG_PL330=y
 CONFIG_CADENCE=y
-CONFIG_XGMAC=y
 CONFIG_PXA2XX=y
 CONFIG_BITBANG_I2C=y
 CONFIG_FRAMEBUFFER=y
@@ -151,7 +150,6 @@ CONFIG_XILINX_AXI=y
 CONFIG_PCI_EXPRESS_DESIGNWARE=y
 
 CONFIG_STRONGARM=y
-CONFIG_HIGHBANK=y
 CONFIG_MUSICPAL=y
 
 # for realview and versatilepb
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 285..984de8a 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -18,6 +18,18 @@ config EXYNOS4
 
 config HIGHBANK
 bool
+select A9MPCORE
+select A15MPCORE
+select AHCI
+select ARM_TIMER # sp804
+select ARM_V7M
+select PCI
+select PL011 # UART
+select PL022 # Serial port
+select PL031 # RTC
+select PL061 # GPIO
+select PL310 # cache controller
+select XGMAC # ethernet
 
 config INTEGRATOR
 bool
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v6 00/35] target/riscv: Convert to decodetree

[Bastian Koppelmann]

On 2/13/19 3:15 AM, Palmer Dabbelt wrote:

On Tue, Feb 12, 2019 at 3:21 PM Palmer Dabbelt  wrote:

[snip]


Do you, by any chance, have a v7?  It looks like there's quite a few merge
conflicts here, and while I'm OK fixing them I don't want to do it if you
already have.


I made it through my rebase, so unless you want to send out a v7 I will.
There were some meaningful changes so I'd like to get a round of review
just so everyone is on the same page.



Thanks for doing this work. I don't have a v7 yet, since I was waiting 
on your current pull-request to get merged. So please do send a v7, I'm 
happy to review/test it.


Cheers,

Bastian

[Qemu-devel] [PATCH v2 04/25] hw/arm: Express dependencies of the fsl-imx31 machine with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the fsl-imx31 / kzm machine.
This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 3 +--
 hw/arm/Kconfig  | 5 +
 hw/misc/Kconfig | 2 ++
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 2033050..19d0ab0 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -8,6 +8,7 @@ CONFIG_PCI_DEVICES=y
 CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
 CONFIG_INTEGRATOR=y
+CONFIG_FSL_IMX31=y
 
 CONFIG_VGA=y
 CONFIG_NAND=y
@@ -68,7 +69,6 @@ CONFIG_TSC210X=y
 CONFIG_BLIZZARD=y
 CONFIG_ONENAND=y
 CONFIG_TUSB6010=y
-CONFIG_IMX=y
 CONFIG_MAINSTONE=y
 CONFIG_MPS2=y
 CONFIG_NSERIES=y
@@ -118,7 +118,6 @@ CONFIG_ALLWINNER_A10_PIC=y
 CONFIG_ALLWINNER_A10=y
 
 CONFIG_FSL_IMX6=y
-CONFIG_FSL_IMX31=y
 CONFIG_FSL_IMX25=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index c022b8d..3d0ee29 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -103,6 +103,11 @@ config FSL_IMX25
 
 config FSL_IMX31
 bool
+select SERIAL
+select IMX
+select IMX_I2C
+select LAN9118
+select PCI
 
 config FSL_IMX6
 bool
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 11d4b30..54ff9a8 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -76,6 +76,8 @@ config ECCMEMCTL
 config IMX
 bool
 select PTIMER
+select SSI
+select USB_EHCI_SYSBUS
 
 config STM32F2XX_SYSCFG
 bool
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 00/25] Kconfig dependencies for ARM machines

[Thomas Huth]

This series reworks the default-configs/arm-softmmu.mak and
default-configs/aarch64-softmmu.mak files to use the new Kconfig-style
dependencies instead.

Based-on: 1549562254-41157-1-git-send-email-pbonz...@redhat.com
  ("Support Kconfig in QEMU")

The first half of the patches is slightly based on the work by Ákos Kovács:

https://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg03730.html

The second part has been created by looking at the sources and finding
out the dependencies the hard way via trial-and-error (i.e. by enabling
only one machine at a time and checking whether it can be compiled and
started).

NB: One thing I noticed while working on these patches: We should
tidy up the dependencies of AHCI and SDHCI. Both currently depend
on PCI, but some boards that do not have PCI also want to use them
(via sysbus devices)... but that's a clean-up for the future, this
series here is already big enough.

v2: Adressed review-feedback from v1
 - CONFIG_SDHCI and CONFIG_AHCI now select CONFIG_PCI
 - Added switches for MICROBIT and EMCRAFT_SF2

Thomas Huth (25):
  hw/arm: Express dependencies of the exynos machines with Kconfig
  hw/arm: Express dependencies of the highbank machines with Kconfig
  hw/arm: Express dependencies of integratorcp with Kconfig
  hw/arm: Express dependencies of the fsl-imx31 machine with Kconfig
  hw/arm: Express dependencies of musicpal with Kconfig
  hw/arm: Express dependencies of the OMAP machines with Kconfig
  hw/arm: Express dependencies of stellaris with Kconfig
  hw/arm: Express dependencies of realview, versatile and vexpress with
Kconfig
  hw/arm: Express dependencies of the PXA2xx machines with Kconfig
  hw/arm: Express dependencies of xilinx-zynq with Kconfig
  hw/arm: Express dependencies of collie with Kconfig
  hw/arm: Express dependencies of the aspeed boards with Kconfig
  hw/arm: Express dependencies of the virt machine with Kconfig
  hw/arm: Express dependencies of netduino / stm32f2xx with Kconfig
  hw/arm: Express dependencies of allwinner / cubieboard with Kconfig
  hw/arm: Express dependencies of the MPS2 boards with Kconfig
  hw/arm: Express dependencies of the raspi machines with Kconfig
  hw/arm: Express dependencies of canon-a1100 with Kconfig
  hw/arm: Express dependencies of sabrelite with Kconfig
  hw/arm: Express dependencies of the MSF2 machine with Kconfig
  hw/arm: Express dependencies for remaining IMX boards with Kconfig
  hw/arm: Express dependencies of the microbit / nrf51 machine with
Kconfig
  hw/arm: Express dependencies of the ZynqMP zcu102 machine with Kconfig
  hw/arm: Express dependencies of the xlnx-versal-virt machine with
Kconfig
  hw/arm: Remove hard-enablement of the remaining PCI devices

 default-configs/aarch64-softmmu.mak |   4 -
 default-configs/arm-softmmu.mak | 177 +++-
 hw/arm/Kconfig  | 313 
 hw/arm/Makefile.objs|  25 ++-
 hw/display/Kconfig  |   3 +
 hw/i2c/Kconfig  |   2 +-
 hw/ide/Kconfig  |   2 +-
 hw/misc/Kconfig |   2 +
 hw/sd/Kconfig   |   2 +-
 9 files changed, 364 insertions(+), 166 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH v2 01/25] hw/arm: Express dependencies of the exynos machines with Kconfig

[Thomas Huth]

Add Kconfig dependencies for the Exynos-related boards (nuri and
smdkc210).
This patch is slightly based on earlier work by Ákos Kovács (i.e.
his "hw/arm/Kconfig: Add ARM Kconfig" patch).

Signed-off-by: Thomas Huth 
---
 default-configs/arm-softmmu.mak | 16 ++--
 hw/arm/Kconfig  | 11 +++
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 8283aeb..3baafc4 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -1,7 +1,12 @@
 # Default configuration for arm-softmmu
 
-CONFIG_PCI=y
+# TODO: ARM_V7M is currently always required - make this more flexible!
+CONFIG_ARM_V7M=y
+
 CONFIG_PCI_DEVICES=y
+
+CONFIG_EXYNOS4=y
+
 CONFIG_VGA=y
 CONFIG_NAND=y
 CONFIG_ECC=y
@@ -25,7 +30,6 @@ CONFIG_ADS7846=y
 CONFIG_MAX111X=y
 CONFIG_SSI_SD=y
 CONFIG_SSI_M25P80=y
-CONFIG_LAN9118=y
 CONFIG_SMC91C111=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
@@ -35,7 +39,6 @@ CONFIG_PFLASH_CFI01=y
 CONFIG_PFLASH_CFI02=y
 CONFIG_MICRODRIVE=y
 CONFIG_USB_MUSB=y
-CONFIG_USB_EHCI_SYSBUS=y
 CONFIG_PLATFORM_BUS=y
 CONFIG_VIRTIO_MMIO=y
 
@@ -43,13 +46,9 @@ CONFIG_ARM11MPCORE=y
 CONFIG_A9MPCORE=y
 CONFIG_A15MPCORE=y
 
-CONFIG_ARM_V7M=y
 CONFIG_NETDUINO2=y
 
-CONFIG_ARM_GIC=y
 CONFIG_ARM_TIMER=y
-CONFIG_ARM_MPTIMER=y
-CONFIG_A9_GTIMER=y
 CONFIG_PL011=y
 CONFIG_PL022=y
 CONFIG_PL031=y
@@ -60,11 +59,9 @@ CONFIG_PL080=y
 CONFIG_PL110=y
 CONFIG_PL181=y
 CONFIG_PL190=y
-CONFIG_PL310=y
 CONFIG_PL330=y
 CONFIG_CADENCE=y
 CONFIG_XGMAC=y
-CONFIG_EXYNOS4=y
 CONFIG_PXA2XX=y
 CONFIG_BITBANG_I2C=y
 CONFIG_FRAMEBUFFER=y
@@ -72,7 +69,6 @@ CONFIG_XILINX_SPIPS=y
 CONFIG_ZYNQ_DEVCFG=y
 
 CONFIG_ARM11SCU=y
-CONFIG_A9SCU=y
 CONFIG_DIGIC=y
 CONFIG_MARVELL_88W8618=y
 CONFIG_OMAP=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 3176680..285 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -7,7 +7,14 @@ config DIGIC
 
 config EXYNOS4
 bool
+select A9MPCORE
+select I2C
+select LAN9118
+select PCI
+select PL310 # cache controller
 select PTIMER
+select SDHCI
+select USB_EHCI_SYSBUS
 
 config HIGHBANK
 bool
@@ -109,6 +116,10 @@ config ZAURUS
 
 config A9MPCORE
 bool
+select A9_GTIMER
+select A9SCU   # snoop control unit
+select ARM_GIC
+select ARM_MPTIMER
 
 config A15MPCORE
 bool
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v2] hostmem-file: reject invalid pmem file sizes

[Wei Yang]

On Wed, Feb 13, 2019 at 03:14:01PM +0800, Stefan Hajnoczi wrote:
>Guests started with NVDIMMs larger than the underlying host file produce
>confusing errors inside the guest.  This happens because the guest
>accesses pages beyond the end of the file.
>
>Check the pmem file size on startup and print a clear error message if
>the size is invalid.
>
>Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1669053
>Cc: Haozhong Zhang 
>Cc: Zhang Yi 
>Cc: Eduardo Habkost 
>Cc: Igor Mammedov 
>Signed-off-by: Stefan Hajnoczi 
>---
>v2:
> * Propagate qemu_get_pmem_size() errors [Igor]
>
> include/qemu/osdep.h| 13 ++
> backends/hostmem-file.c | 22 +
> util/oslib-posix.c  | 53 +
> util/oslib-win32.c  |  5 
> 4 files changed, 93 insertions(+)
>
>diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
>index 840af09cb0..303d315c5d 100644
>--- a/include/qemu/osdep.h
>+++ b/include/qemu/osdep.h
>@@ -570,6 +570,19 @@ void qemu_set_tty_echo(int fd, bool echo);
> void os_mem_prealloc(int fd, char *area, size_t sz, int smp_cpus,
>  Error **errp);
> 
>+/**
>+ * qemu_get_pmem_size:
>+ * @filename: path to a pmem file
>+ * @errp: pointer to a NULL-initialized error object
>+ *
>+ * Determine the size of a persistent memory file.  Besides supporting files 
>on
>+ * DAX file systems, this function also supports Linux devdax character
>+ * devices.
>+ *
>+ * Returns: the size or 0 on failure
>+ */
>+uint64_t qemu_get_pmem_size(const char *filename, Error **errp);
>+
> /**
>  * qemu_get_pid_name:
>  * @pid: pid of a process
>diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
>index ba601ce940..d62689179b 100644
>--- a/backends/hostmem-file.c
>+++ b/backends/hostmem-file.c
>@@ -46,6 +46,28 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
>**errp)
> gchar *name;
> #endif
> 
>+/*
>+ * Verify pmem file size since starting a guest with an incorrect size
>+ * leads to confusing failures inside the guest.
>+ */
>+if (fb->is_pmem && fb->mem_path) {
>+Error *local_err = NULL;
>+uint64_t size;
>+
>+size = qemu_get_pmem_size(fb->mem_path, &local_err);
>+if (!size) {
>+error_propagate(errp, local_err);
>+return;
>+}
>+
>+if (backend->size > size) {
>+error_setg(errp, "size property %" PRIu64 " is larger than "
>+   "pmem file \"%s\" size %" PRIu64, backend->size,
>+   fb->mem_path, size);
>+return;
>+}
>+}
>+

-mem-path is only supported on POSIX host.

So how about put this in the last code block before doing the real memory
region init?

BTW, I suggest to cleanup file_backend_memory_alloc() to make POSIX/non-POSIX
situation clear to understand.

> if (!backend->size) {
> error_setg(errp, "can't create backend with size 0");
> return;
>diff --git a/util/oslib-posix.c b/util/oslib-posix.c
>index 37c5854b9c..10d90d1783 100644
>--- a/util/oslib-posix.c
>+++ b/util/oslib-posix.c
>@@ -500,6 +500,59 @@ void os_mem_prealloc(int fd, char *area, size_t memory, 
>int smp_cpus,
> }
> }
> 
>+uint64_t qemu_get_pmem_size(const char *filename, Error **errp)
>+{
>+struct stat st;
>+
>+if (stat(filename, &st) < 0) {
>+error_setg(errp, "unable to stat pmem file \"%s\"", filename);
>+return 0;
>+}
>+
>+#if defined(__linux__)
>+/* Special handling for devdax character devices */
>+if (S_ISCHR(st.st_mode)) {
>+char *subsystem_path = NULL;
>+char *subsystem = NULL;
>+char *size_path = NULL;
>+char *size_str = NULL;
>+uint64_t ret = 0;
>+
>+subsystem_path = g_strdup_printf("/sys/dev/char/%d:%d/subsystem",
>+ major(st.st_rdev), 
>minor(st.st_rdev));
>+subsystem = g_file_read_link(subsystem_path, NULL);
>+if (!subsystem) {
>+error_setg(errp, "unable to read subsystem for pmem file \"%s\"",
>+   filename);
>+goto devdax_err;
>+}
>+
>+if (!g_str_has_suffix(subsystem, "/dax")) {
>+error_setg(errp, "pmem file \"%s\" is not a dax device", 
>filename);
>+goto devdax_err;
>+}
>+
>+size_path = g_strdup_printf("/sys/dev/char/%d:%d/size",
>+major(st.st_rdev), minor(st.st_rdev));
>+if (!g_file_get_contents(size_path, &size_str, NULL, NULL)) {
>+error_setg(errp, "unable to read size for pmem file \"%s\"",
>+   size_path);
>+goto devdax_err;
>+}
>+
>+ret = g_ascii_strtoull(size_str, NULL, 0);
>+
>+devdax_err:
>+g_free(size_str);
>+g_free(size_path);
>+g_free(subsystem);
>+g_free(subsystem_path);
>+return ret;
>+}
>+#endif /* defined(__linux__) */
>+
>+return st.st_size;
>+}
> 
> ch

Re: [Qemu-devel] [RFC 1/4] numa, spapr: add thread-id in the possible_cpus list

[Laurent Vivier]

On 13/02/2019 09:42, Igor Mammedov wrote:

On Wed, 13 Feb 2019 12:25:45 +1100
David Gibson  wrote:


On Tue, Feb 12, 2019 at 10:48:24PM +0100, Laurent Vivier wrote:

spapr_possible_cpu_arch_ids() counts only cores, and so
the number of available CPUs is the number of vCPU divided
by smp_threads.

... -smp 4,maxcpus=8,cores=2,threads=2,sockets=2 -numa node,cpus=0,cpus=1 \
  -numa node,cpus=3,cpus=4 \
  -numa node -numa node

This generates (info hotpluggable-cpus)

   node-id: 0 core-id: 0 thread-id: 0 [thread-id: 1]
   node-id: 0 core-id: 6 thread-id: 0 [thread-id: 1]
   node-id: 1 core-id: 2 thread-id: 0 [thread-id: 1]
   node-id: 1 core-id: 4 thread-id: 0 [thread-id: 1]

And this command line generates the following error:

   CPU(s) not present in any NUMA nodes: CPU 3 [core-id: 6]

That is wrong because CPU 3 [core-id: 6] is assigned to node-id 0
Moreover "cpus=4" is not valid, because it means core-id 8 but
maxcpus is 8.

With this patch we have now:

   node-id: 0 core-id: 0 thread-id: 0
   node-id: 0 core-id: 0 thread-id: 1
   node-id: 0 core-id: 1 thread-id: 0
   node-id: 1 core-id: 1 thread-id: 1
   node-id: 0 core-id: 2 thread-id: 1
   node-id: 1 core-id: 2 thread-id: 0
   node-id: 0 core-id: 3 thread-id: 1
   node-id: 0 core-id: 3 thread-id: 0


I'm afraid this is not the right solution.  The point of the
hotpluggable cpus table is that it has exactly one entry for each
hotpluggable unit.  For PAPR that's a core, not a thread.

So, the problem is with how the NUMA configuration code is
interpreting possible-cpus, not how the machine is building the table.


I'd suggest to deprecate/remove 'cpus' suboption in -numa.
One should use '-numa cpu' instead, which is written with
possible_cpus in mind.


I agree.

Should I keep the patch to remove the incomplete CPU mapping support?

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v3 0/3] Trivial cleanup in hw/acpi

[Wei Yang]

On Wed, Feb 13, 2019 at 09:49:01AM +0100, Laurent Vivier wrote:
>On 12/02/2019 06:34, Michael S. Tsirkin wrote:
>> On Tue, Feb 12, 2019 at 01:22:24PM +0800, Wei Yang wrote:
>>> On Wed, Jan 30, 2019 at 08:06:50AM +0800, Wei Yang wrote:
 There are several functions/variable which are not used anymore.

 This serials just remove those without functional change.

 v3: add ack and repost in a new thread
 v2: change commit log from "is now used in no place" to "in not used 
 anymore"
>>>
>>> Michael,
>>>
>>> Looks this serials is not merged yet.
>>>
>>> Is there any problem I need to fix?
>> 
>> Yes pls repost with fixed reviewed-by tags.
>
>Or I can take the series through the trivial branch and update manually
>Philippe's lastname?
>

Thanks :-)

Let's see Michael's opinion.

>Laurent

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] [PATCH 1/2] qga-win: include glib when building VSS DLL

[Daniel P . Berrangé]

On Tue, Feb 12, 2019 at 03:29:16PM -0600, Michael Roth wrote:
> Commit 3ebee3b191e defined assert() as g_assert(), but when we build
> the VSS DLL component of QGA (to handle fsfreeze) we do not include
> glib, which results in breakage when building with VSS support enabled.
> 
> Fix this by including glib. Since the VSS DLL is built statically,
> this introduces an additional dependency on static glib and supporting
> libs for the mingw environment (possibly why we didn't include glib
> originally), but VSS support already has very specific prerequisites
> so it shouldn't affect too many build environments.
> 
> Since the VSS DLL code does use qemu/osdep.h, this should also help
> avoid future breakages and possibly allow for some clean ups in current
> VSS code.
> 
> Suggested-by: Daniel P. Berrangé 
> Cc: Daniel P. Berrangé 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Michael Roth 
> ---
>  qga/vss-win32/Makefile.objs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/qga/vss-win32/Makefile.objs b/qga/vss-win32/Makefile.objs
> index 23d08da225..dad9d1b0ba 100644
> --- a/qga/vss-win32/Makefile.objs
> +++ b/qga/vss-win32/Makefile.objs
> @@ -5,7 +5,7 @@ qga-vss-dll-obj-y += requester.o provider.o install.o
>  obj-qga-vss-dll-obj-y = $(addprefix $(obj)/, $(qga-vss-dll-obj-y))
>  $(obj-qga-vss-dll-obj-y): QEMU_CXXFLAGS = $(filter-out -Wstrict-prototypes 
> -Wmissing-prototypes -Wnested-externs -Wold-style-declaration 
> -Wold-style-definition -Wredundant-decls -fstack-protector-all 
> -fstack-protector-strong, $(QEMU_CFLAGS)) -Wno-unknown-pragmas 
> -Wno-delete-non-virtual-dtor
>  
> -$(obj)/qga-vss.dll: LDFLAGS = -shared 
> -Wl,--add-stdcall-alias,--enable-stdcall-fixup -lole32 -loleaut32 -lshlwapi 
> -luuid -static
> +$(obj)/qga-vss.dll: LDFLAGS = -shared 
> -Wl,--add-stdcall-alias,--enable-stdcall-fixup -lglib-2.0 -lole32 -loleaut32 
> -lshlwapi -luuid -lintl -lws2_32 -static

Adding -lglib-2.0 makes sense, but your commit message doesn't explain
why -lintl or -lws2_32 are being added & they don't really make sense
to me.


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

Re: [Qemu-devel] [PATCH 2/2] qga-win: fix VSS build breakage due to unintended gnu99 C++ flag

[Daniel P . Berrangé]

On Tue, Feb 12, 2019 at 03:29:17PM -0600, Michael Roth wrote:
> Commit 7be41675f7c set -std=gnu99 for C code via QEMU_CFLAGS. Currently
> we generate a "custom" QEMU_CXXFLAGS for VSS DLL C++ build by
> filtering out some options from QEMU_CFLAGS and adding some others.
> Since we don't filter out -std=gnu99 currently this breaks builds when
> VSS support is enabled.
> 
> We could keep the existing approach, filter out -std=gnu99 from
> QEMU_CFLAGS, and add -std=gnu++98, like configure currently does for
> QEMU_CXXFLAGS, but as it turns out our resulting QEMU_CXXFLAGS would
> be exactly what configure already generates, just with these filtered
> out:
> 
>   -fstack-protector-all -fstack-protector-strong
> 
> and these added:
> 
>   -Wno-unknown-pragmas -Wno-delete-non-virtual-dtor
> 
> So fix the issue by re-using configure-generated QEMU_CXXFLAGS and
> just handling these specific changes.
> 
> Signed-off-by: Michael Roth 
> ---
>  qga/vss-win32/Makefile.objs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé 


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

Re: [Qemu-devel] [PATCH v4 14/15] spapr: add hotplug hooks for PHB hotplug

[David Hildenbrand]

On 12.02.19 19:25, Greg Kurz wrote:
> Hotplugging PHBs is a machine-level operation, but PHBs reside on the
> main system bus, so we register spapr machine as the handler for the
> main system bus.
> 
> Provide the usual pre-plug, plug and unplug-request handlers.
> 
> Move the checking of the PHB index to the pre-plug handler. It is okay
> to do that and assert in the realize function because the pre-plug
> handler is always called, even for the oldest machine types we support.
> 
> Unlike with other device types, there are some cases where we cannot
> provide the FDT fragment of the PHB from the plug handler, eg, before
> KVMPPC_H_UPDATE_DT was called. Do this from a DRC callback that is
> called just before the first FDT fragment is exposed to the guest.
> 
> Signed-off-by: Michael Roth 
> (Fixed interrupt controller phandle in "interrupt-map" and
>  TCE table size in "ibm,dma-window" FDT fragment, Greg Kurz)
> Signed-off-by: Greg Kurz 
> ---
> v4: - populate FDT fragment in a DRC callback
> v3: - reworked phandle handling some more
> v2: - reworked phandle handling
> - sync LSIs to KVM
> ---
> ---
>  hw/ppc/spapr.c |  121 
> 
>  hw/ppc/spapr_drc.c |2 +
>  hw/ppc/spapr_pci.c |   16 --
>  include/hw/ppc/spapr.h |5 ++
>  4 files changed, 127 insertions(+), 17 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 021758825b7e..06ce0babcb54 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2930,6 +2930,11 @@ static void spapr_machine_init(MachineState *machine)
>  register_savevm_live(NULL, "spapr/htab", -1, 1,
>   &savevm_htab_handlers, spapr);
>  
> +if (smc->dr_phb_enabled) {
> +qbus_set_hotplug_handler(sysbus_get_default(), OBJECT(machine),
> + &error_fatal);
> +}
> +
>  qemu_register_boot_set(spapr_boot_set, spapr);
>  
>  if (kvm_enabled()) {
> @@ -3733,6 +3738,108 @@ out:
>  error_propagate(errp, local_err);
>  }
>  
> +int spapr_dt_phb(DeviceState *dev, sPAPRMachineState *spapr, void *fdt,
> + int *fdt_start_offset, Error **errp)
> +{
> +sPAPRPHBState *sphb = SPAPR_PCI_HOST_BRIDGE(dev);
> +uint32_t intc_phandle;
> +
> +if (spapr_irq_get_phandle(spapr, spapr->fdt_blob, &intc_phandle, errp)) {
> +return -1;
> +}
> +
> +if (spapr_populate_pci_dt(sphb, intc_phandle, fdt, spapr->irq->nr_msis,
> +  fdt_start_offset)) {
> +error_setg(errp, "unable to create FDT node for PHB %d", 
> sphb->index);
> +return -1;
> +}
> +
> +/* generally SLOF creates these, for hotplug it's up to QEMU */
> +_FDT(fdt_setprop_string(fdt, *fdt_start_offset, "name", "pci"));
> +
> +return 0;
> +}
> +
> +static void spapr_phb_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> +   Error **errp)
> +{
> +sPAPRMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
> +sPAPRPHBState *sphb = SPAPR_PCI_HOST_BRIDGE(dev);
> +sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
> +const unsigned windows_supported = spapr_phb_windows_supported(sphb);
> +
> +if (sphb->index == (uint32_t)-1) {
> +error_setg(errp, "\"index\" for PAPR PHB is mandatory");
> +return;
> +}
> +
> +/*
> + * This will check that sphb->index doesn't exceed the maximum number of
> + * PHBs for the current machine type.
> + */
> +smc->phb_placement(spapr, sphb->index,
> +   &sphb->buid, &sphb->io_win_addr,
> +   &sphb->mem_win_addr, &sphb->mem64_win_addr,
> +   windows_supported, sphb->dma_liobn, errp);
> +}
> +
> +static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> +   Error **errp)
> +{
> +sPAPRMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
> +sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
> +sPAPRPHBState *sphb = SPAPR_PCI_HOST_BRIDGE(dev);
> +sPAPRDRConnector *drc;
> +bool hotplugged = spapr_drc_hotplugged(dev);
> +Error *local_err = NULL;
> +
> +if (!smc->dr_phb_enabled) {
> +return;
> +}
> +
> +drc = spapr_drc_by_id(TYPE_SPAPR_DRC_PHB, sphb->index);
> +/* hotplug hooks should check it's enabled before getting this far */
> +assert(drc);
> +
> +/*
> + * The FDT fragment will be added during the first invocation of RTAS
> + * ibm,client-architecture-support  for this device, when we're sure
> + * that the IOMMU is configured and that QEMU knows the phandle of the
> + * interrupt controller.
> + */
> +spapr_drc_attach(drc, DEVICE(dev), NULL, 0, &local_err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> +if (hotplugged) {
> +spapr_hotplug_req_add_by_index(drc);
> +} else {
> +spapr_drc_reset(dr

[Qemu-devel] [PATCH v4 1/2] pcie: Add a simple PCIe ACS (Access Control Services) helper function

[Knut Omang]

Add a helper function to add PCIe capability for Access Control Services (ACS)
ACS support in the associated root port is needed to pass
through individual functions of a device to different VMs with VFIO
without Alex Williamson's pcie_acs_override kernel patch or similar
in the guest.

Single function devices, or multifunction devices
that all goes to the same VM works fine even without ACS, as VFIO
will avoid putting the root port itself into the IOMMU group
even without ACS support in the port.

Multifunction endpoints may also implement an ACS capability,
only on function 0, and with more limited features.

Signed-off-by: Knut Omang 
---
 hw/pci/pcie.c  | 39 +++-
 include/hw/pci/pcie.h  |  6 ++-
 include/hw/pci/pcie_regs.h |  4 -
 3 files changed, 49 insertions(+)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 230478f..6e87994 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -906,3 +906,42 @@ void pcie_ats_init(PCIDevice *dev, uint16_t offset)
 
 pci_set_word(dev->wmask + dev->exp.ats_cap + PCI_ATS_CTRL, 0x800f);
 }
+
+/* ACS (Access Control Services) */
+void pcie_acs_init(PCIDevice *dev, uint16_t offset)
+{
+bool is_pcie_slot = !!object_dynamic_cast(OBJECT(dev), TYPE_PCIE_SLOT);
+uint16_t cap_bits = 0;
+
+/*
+ * For endpoints, only multifunction devices may have an
+ * ACS capability, and only on function 0:
+ */
+assert(is_pcie_slot ||
+   ((dev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION) &&
+PCI_FUNC(dev->devfn)));
+
+pcie_add_capability(dev, PCI_EXT_CAP_ID_ACS, PCI_ACS_VER, offset,
+PCI_ACS_SIZEOF);
+dev->exp.acs_cap = offset;
+
+if (is_pcie_slot) {
+/*
+ * Endpoints may also implement ACS, and optionally RR and CR,
+ * if they want to support p2p, but only slots may
+ * implement SV, TB or UF:
+ */
+cap_bits =
+PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF;
+}
+
+pci_set_word(dev->config + offset + PCI_ACS_CAP, cap_bits);
+pci_set_word(dev->wmask + offset + PCI_ACS_CTRL, cap_bits);
+}
+
+void pcie_acs_reset(PCIDevice *dev)
+{
+if (dev->exp.acs_cap) {
+pci_set_word(dev->config + dev->exp.acs_cap + PCI_ACS_CTRL, 0);
+}
+}
diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
index 5b82a0d..e30334d 100644
--- a/include/hw/pci/pcie.h
+++ b/include/hw/pci/pcie.h
@@ -79,6 +79,9 @@ struct PCIExpressDevice {
 
 /* Offset of ATS capability in config space */
 uint16_t ats_cap;
+
+/* ACS */
+uint16_t acs_cap;
 };
 
 #define COMPAT_PROP_PCP "power_controller_present"
@@ -128,6 +131,9 @@ void pcie_add_capability(PCIDevice *dev,
  uint16_t offset, uint16_t size);
 void pcie_sync_bridge_lnk(PCIDevice *dev);
 
+void pcie_acs_init(PCIDevice *dev, uint16_t offset);
+void pcie_acs_reset(PCIDevice *dev);
+
 void pcie_ari_init(PCIDevice *dev, uint16_t offset, uint16_t nextfn);
 void pcie_dev_ser_num_init(PCIDevice *dev, uint16_t offset, uint64_t ser_num);
 void pcie_ats_init(PCIDevice *dev, uint16_t offset);
diff --git a/include/hw/pci/pcie_regs.h b/include/hw/pci/pcie_regs.h
index ad4e780..1db86b0 100644
--- a/include/hw/pci/pcie_regs.h
+++ b/include/hw/pci/pcie_regs.h
@@ -175,4 +175,8 @@ typedef enum PCIExpLinkWidth {
  PCI_ERR_COR_INTERNAL | \
  PCI_ERR_COR_HL_OVERFLOW)
 
+/* ACS */
+#define PCI_ACS_VER 0x1
+#define PCI_ACS_SIZEOF  8
+
 #endif /* QEMU_PCIE_REGS_H */
-- 
git-series 0.9.1

[Qemu-devel] [PATCH v4 0/2] pcie: Add simple ACS "support" to the generic PCIe root port

[Knut Omang]

These two patches together implements a PCIe capability
config space header for Access Control Services (ACS) for the
new Qemu specific generic root port. ACS support in the
associated root port is a prerequisite to be able to pass
individual functions of a device populating the port through to
an L2 guest from an unmodified kernel.

Without this, the IOMMU group the device belongs to will also
include the root port itself, and all functions the device provides.

It is necessary to support SR/IOV where the primary
purpose is to be able to share out individual VFs to different
guests, which will not be permitted by VFIO or the Windows Hyper-V equivalent
unless ACS is supported by the root port.

These patches can also be found as part of an updated version of
my SR/IOV emulation patch set at

  https://github.com/knuto/qemu/tree/sriov_patches_v11

The patches' basic operation with VFIO and iommu groups have
been tested with the above patch set and a rebased version of an
in progress igb ethernet device, which needs some more care
before I can let it go out.

Changes from v3:

- rebased to the latest qemu master
- Revised commit message and comments for patch #1 to make it
  clearer that VFIO works for single function devices even without ACS.
- Improved checking for valid endpoints for ACS.
- Fixed comment style issue
- Co-locate the pci_acs_init and _reset functions and
  rename pci_cap_acs_reset to pci_acs_reset to adhere to the naming
  conventions that _cap_ functions in pcie is for changing state
  in the main pcie capability and not the individual extended
  capabilities.
- Added Marcel's r-b to patch 2, which did not change

Changes from v2:

- rebased to the latest qemu master

Incorporated further feedback from Alex:
- Make sure slot/downstream capability bits are only set for slots.
- Make acs reset callback do nothing if no acs capability exists
- Set correct acs version
- div simplification

Changes from v1:

Incorporated feedback from Alex Williamson:
- Make commit messages reflect a more correct understanding of how this
  affects VFIO operation.
- Implemented the CTRL register properly (reset callback + making 
non-implemented
  capabilities RO, default value 0)
- removed the egress ctrl vector parameter to the init function
- Fixed some whitespace issues

Knut Omang (2):
  pcie: Add a simple PCIe ACS (Access Control Services) helper function
  gen_pcie_root_port: Add ACS (Access Control Services) capability

 hw/pci-bridge/gen_pcie_root_port.c |  4 +++-
 hw/pci-bridge/pcie_root_port.c |  4 +++-
 hw/pci/pcie.c  | 39 +++-
 include/hw/pci/pcie.h  |  6 +-
 include/hw/pci/pcie_port.h |  1 +-
 include/hw/pci/pcie_regs.h |  4 +++-
 6 files changed, 58 insertions(+)

base-commit: 0b5e750bea635b167eb03d86c3d9a09bbd43bc06
-- 
git-series 0.9.1

[Qemu-devel] [PATCH v4 2/2] gen_pcie_root_port: Add ACS (Access Control Services) capability

[Knut Omang]

Claim ACS support in the generic PCIe root port to allow
passthrough of individual functions of a device to different
guests (in a nested virt.setting) with VFIO.
Without this patch, all functions of a device, such as all VFs of
an SR/IOV device, will end up in the same IOMMU group.
A similar situation occurs on Windows with Hyper-V.

In the single function device case, it also has a small cosmetic
benefit in that the root port itself is not grouped with
the device. VFIO handles that situation in that binding rules
only apply to endpoints, so it does not limit passthrough in
those cases.

Signed-off-by: Knut Omang 
Reviewed-by: Marcel Apfelbaum 
---
 hw/pci-bridge/gen_pcie_root_port.c | 4 
 hw/pci-bridge/pcie_root_port.c | 4 
 include/hw/pci/pcie_port.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/hw/pci-bridge/gen_pcie_root_port.c 
b/hw/pci-bridge/gen_pcie_root_port.c
index 9766edb..26bda73 100644
--- a/hw/pci-bridge/gen_pcie_root_port.c
+++ b/hw/pci-bridge/gen_pcie_root_port.c
@@ -20,6 +20,9 @@
 OBJECT_CHECK(GenPCIERootPort, (obj), TYPE_GEN_PCIE_ROOT_PORT)
 
 #define GEN_PCIE_ROOT_PORT_AER_OFFSET   0x100
+#define GEN_PCIE_ROOT_PORT_ACS_OFFSET \
+(GEN_PCIE_ROOT_PORT_AER_OFFSET + PCI_ERR_SIZEOF)
+
 #define GEN_PCIE_ROOT_PORT_MSIX_NR_VECTOR   1
 
 typedef struct GenPCIERootPort {
@@ -149,6 +152,7 @@ static void gen_rp_dev_class_init(ObjectClass *klass, void 
*data)
 rpc->interrupts_init = gen_rp_interrupts_init;
 rpc->interrupts_uninit = gen_rp_interrupts_uninit;
 rpc->aer_offset = GEN_PCIE_ROOT_PORT_AER_OFFSET;
+rpc->acs_offset = GEN_PCIE_ROOT_PORT_ACS_OFFSET;
 }
 
 static const TypeInfo gen_rp_dev_info = {
diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
index 34ad767..e94d918 100644
--- a/hw/pci-bridge/pcie_root_port.c
+++ b/hw/pci-bridge/pcie_root_port.c
@@ -47,6 +47,7 @@ static void rp_reset(DeviceState *qdev)
 pcie_cap_deverr_reset(d);
 pcie_cap_slot_reset(d);
 pcie_cap_arifwd_reset(d);
+pcie_acs_reset(d);
 pcie_aer_root_reset(d);
 pci_bridge_reset(qdev);
 pci_bridge_disable_base_limit(d);
@@ -106,6 +107,9 @@ static void rp_realize(PCIDevice *d, Error **errp)
 pcie_aer_root_init(d);
 rp_aer_vector_update(d);
 
+if (rpc->acs_offset) {
+pcie_acs_init(d, rpc->acs_offset);
+}
 return;
 
 err:
diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
index df242a0..09586f4 100644
--- a/include/hw/pci/pcie_port.h
+++ b/include/hw/pci/pcie_port.h
@@ -78,6 +78,7 @@ typedef struct PCIERootPortClass {
 int exp_offset;
 int aer_offset;
 int ssvid_offset;
+int acs_offset;/* If nonzero, optional ACS capability offset */
 int ssid;
 } PCIERootPortClass;
 
-- 
git-series 0.9.1

Re: [Qemu-devel] [PATCH 1/5] block/dirty-bitmap: add recording and busy properties

[Vladimir Sementsov-Ogievskiy]

On 12.02.2019 1:02, John Snow wrote:
> The current API allows us to report a single status, which we've defined as:
> 
> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
> Locked: no successor, qmp_locked. may or may not be enabled.
> Disabled: Not frozen or locked, disabled.
> Active: Not frozen, locked, or disabled.
> 
> The problem is that both "Frozen" and "Locked" mean nearly the same thing,
> and that both of them do not intuit whether they are recording guest writes
> or not.
> 
> This patch deprecates that status field and introduces two orthogonal
> properties instead to replace it.
> ---
>   block/dirty-bitmap.c   |  9 +
>   qapi/block-core.json   |  9 -
>   tests/qemu-iotests/236.out | 28 
>   3 files changed, 45 insertions(+), 1 deletion(-)
> 

> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 5a0f5f5a95..275f0d573c 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -455,7 +455,13 @@
>   #
>   # @granularity: granularity of the dirty bitmap in bytes (since 1.4)
>   #
> -# @status: current status of the dirty bitmap (since 2.4)
> +# @status: Deprecated in favor of @recording and @locked. (since 4.0)
> +#
> +# @recording: true if the bitmap is recording new writes from the guest.
> +# Replaces `active` status. (since 4.0)
> +#
> +# @busy: true if the bitmap is in-use by some operation (NBD or jobs)
> +#and cannot be modified via QMP right now. (since 4.0)

not only modified, but also cannot be used somehow for any other operation.

>   #
>   # @persistent: true if the bitmap will eventually be flushed to persistent
>   #  storage (since 4.0)
> @@ -464,6 +470,7 @@
>   ##
>   { 'struct': 'BlockDirtyInfo',
> 'data': {'*name': 'str', 'count': 'int', 'granularity': 'uint32',
> +   'recording': 'bool', 'busy': 'bool',
>  'status': 'DirtyBitmapStatus', 'persistent': 'bool' } }
>   

Re: [Qemu-devel] NSIS - including DLL dependencies for Windows

[Daniel P . Berrangé]

On Thu, Jan 31, 2019 at 10:49:11AM +, Daniel P. Berrangé wrote:
> On Thu, Jan 31, 2019 at 02:45:13PM +1100, Adam Baxter wrote:
> > Hi,
> > How do I gather and include the required DLLs (SDL, zlib etc) in the NSIS
> > installer? (and also in a standalone build to be zipped up, but that's less
> > important)
> > 
> > I noticed the wiki doesn't really mention bundling dependencies anywhere.
> > 
> > The official unofficial windows builds are documented at
> > https://qemu.weilnetz.de/FAQ but this doesn't cover building the actual
> > installer.
> 
> Yeah, this is a pretty major ommision in QEMU's build rules for the NSIS
> installer making it pretty much useless as is. We really need to expand
> it so that it can resolve the dlls that qemu .exe's need, locate them
> on the host and bundle them into the installer automatically.
> 
> It seems we can get a list of deps for an .exe using 
> 
> $ winedump  -j import /path/to/binary.exe  | grep offset | grep dll | awk 
> '{print $3}'

FYI, I re-discovered a way to do this without needing wine, just plain
binutils

  x86_64-w64-mingw32-objdump -p /path/to/binary.exe | grep "DLL Name" | awk 
'{print $3}'


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

Re: [Qemu-devel] [PATCH v3 2/2] gen_pcie_root_port: Add ACS (Access Control Services) capability

[Knut Omang]

On Mon, 2019-02-11 at 10:07 +0200, Marcel Apfelbaum wrote:
> 
> On 2/10/19 8:53 AM, Knut Omang wrote:
> > Claim ACS support in the generic PCIe root port to allow
> > passthrough of individual functions of a device to different
> > guests (in a nested virt.setting) with VFIO.
> > Without this patch, all functions of a device, such as all VFs of
> > an SR/IOV device, will end up in the same IOMMU group.
> > A similar situation occurs on Windows with Hyper-V.
> > 
> > In the single function device case, it also has a small cosmetic
> > benefit in that the root port itself is not grouped with
> > the device. VFIO handles that situation in that binding rules
> > only apply to endpoints, so it does not limit passthrough in
> > those cases.
> > 
> > Signed-off-by: Knut Omang 
> > ---
> >   hw/pci-bridge/gen_pcie_root_port.c | 4 
> >   hw/pci-bridge/pcie_root_port.c | 4 
> >   include/hw/pci/pcie_port.h | 1 +
> >   3 files changed, 9 insertions(+)
> > 
> > diff --git a/hw/pci-bridge/gen_pcie_root_port.c b/hw/pci-
> > bridge/gen_pcie_root_port.c
> > index 9766edb..26bda73 100644
> > --- a/hw/pci-bridge/gen_pcie_root_port.c
> > +++ b/hw/pci-bridge/gen_pcie_root_port.c
> > @@ -20,6 +20,9 @@
> >   OBJECT_CHECK(GenPCIERootPort, (obj), TYPE_GEN_PCIE_ROOT_PORT)
> >   
> >   #define GEN_PCIE_ROOT_PORT_AER_OFFSET   0x100
> > +#define GEN_PCIE_ROOT_PORT_ACS_OFFSET \
> > +(GEN_PCIE_ROOT_PORT_AER_OFFSET + PCI_ERR_SIZEOF)
> > +
> >   #define GEN_PCIE_ROOT_PORT_MSIX_NR_VECTOR   1
> >   
> >   typedef struct GenPCIERootPort {
> > @@ -149,6 +152,7 @@ static void gen_rp_dev_class_init(ObjectClass *klass,
> > void *data)
> >   rpc->interrupts_init = gen_rp_interrupts_init;
> >   rpc->interrupts_uninit = gen_rp_interrupts_uninit;
> >   rpc->aer_offset = GEN_PCIE_ROOT_PORT_AER_OFFSET;
> > +rpc->acs_offset = GEN_PCIE_ROOT_PORT_ACS_OFFSET;
> >   }
> >   
> >   static const TypeInfo gen_rp_dev_info = {
> > diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
> > index 34ad767..a0b4cf7 100644
> > --- a/hw/pci-bridge/pcie_root_port.c
> > +++ b/hw/pci-bridge/pcie_root_port.c
> > @@ -47,6 +47,7 @@ static void rp_reset(DeviceState *qdev)
> >   pcie_cap_deverr_reset(d);
> >   pcie_cap_slot_reset(d);
> >   pcie_cap_arifwd_reset(d);
> > +pcie_cap_acs_reset(d);
> >   pcie_aer_root_reset(d);
> >   pci_bridge_reset(qdev);
> >   pci_bridge_disable_base_limit(d);
> > @@ -106,6 +107,9 @@ static void rp_realize(PCIDevice *d, Error **errp)
> >   pcie_aer_root_init(d);
> >   rp_aer_vector_update(d);
> >   
> > +if (rpc->acs_offset) {
> > +pcie_acs_init(d, rpc->acs_offset);
> > +}
> >   return;
> >   
> >   err:
> > diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
> > index df242a0..09586f4 100644
> > --- a/include/hw/pci/pcie_port.h
> > +++ b/include/hw/pci/pcie_port.h
> > @@ -78,6 +78,7 @@ typedef struct PCIERootPortClass {
> >   int exp_offset;
> >   int aer_offset;
> >   int ssvid_offset;
> > +int acs_offset;/* If nonzero, optional ACS capability offset */
> >   int ssid;
> >   } PCIERootPortClass;
> >   
> 
> Reviewed-by: Marcel Apfelbaum 

Thanks! I added this r-b to v4, but left out the one for patch 1 as it got some
more changes based on Alex's feedback and our fruitful discussion afterwards,
so you might want to recheck it.

Knut
> 
> Thanks,
> Marcel

Re: [Qemu-devel] Is IOThread for virtio-net a good idea?

[Jason Wang]

On 2019/2/13 上午2:40, Michael S. Tsirkin wrote:

On Tue, Feb 12, 2019 at 03:00:55PM +0800, Jason Wang wrote:

On 2019/2/12 下午2:48, Jason Wang wrote:

On 2019/2/11 下午9:40, Anton Kuchin wrote:

As far as I can see currently IOThread offloading is used only for
block devices and all others are emulated by main thread.

I expect that network devices can also benefit from processing in
separate thread but I couldn't find any recent work in this
direction. I'm going to implement a PoC but I want to ask if you
know any previous attempts and do you know why it can be a total
waste of time. Are there fundamental obstacles that prevent network
emulation handling in IOThread?


I think there're no obstacles.

The only question is whether or not you need to support legacy
networking backends. If the answer is yes, you need to convert them not
to assume context of Main Loop. But I don't think it's worth to support
them. We should focus on high speed solution like linking dpdk.

Another issue is the virtio implementation. Dpdk has virtio library
which is pretty optimized, we should consider to use it. But last time I
check the code, it was tightly coupled with AF_UNIX transport of
vhost-user. We may want to decouple it out of dpdk. Of course we can do
it our own as well. (Yes I know there's a vhost-user implementation, but
it was not optimized for performance).

I do have some prototype that is based on vhost-scsi-dataplane with a
TAP backend. I can send it to you if you wish.


Note, what I did is a vhost implementation inside IOThread. It doesn't use
qemu memory core (which is slow for e.g 10Mpps) but vhost memory table.

Thanks

If you are going to all these lengths duplicating dpdk I would at least
make it out of process to qemu to improve security.



Well I think I want to do the inverse for easing the access to VM 
metadata e.g IOMMU or RSS.




As an excercise, maybe start by generalizing pxe test to support vhost
user bridge. That would already be a win.


As for IOTLB, I advicated VTD support in vhost for a while.  VTD page
table parsing isn't a lot of code at all if you put invalidations in
userspace.  We ended up with the message-passing instead for portability
but we can go back for sure.



I think implementing a vendor specific things in vhost is probably not 
good. And as we've discussed, this will end up duplicating the QI 
interface through vhost protocol which doesn't help for performance if 
you move the process out of qemu.


Thanks







Thanks

[Qemu-devel] [Bug 1813940] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device

[Darek Stojaczyk]

> Does this patch from Jagannathan Raman fixes it?
> https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg01397.html

It fixes my case. 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/1813940

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device

Status in QEMU:
  Confirmed

Bug description:
  Latest QEMU master fails to run with too many MMIO devices specified.

  After patch 3ac7d43a6fb [1] QEMU just prints an error message and exits.
  > kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device

  This is reproducible e.g. with the following setup:

  qemu-3.1.50-dirty \
  -machine pc-i440fx-2.7,accel=kvm \
  -cpu host -m 4096 \
  -smp 2,sockets=2,cores=1,threads=1 \
  -drive file=freebsd_vm_1.qcow2,format=qcow2,if=none,id=bootdr \
  -device ide-hd,drive=bootdr,bootindex=0 \
  -device virtio-scsi-pci,id=vc0 \
  -device virtio-scsi-pci,id=vc1 \
  -device virtio-scsi-pci,id=vc2 \
  -device virtio-scsi-pci,id=vc3 \

  Running with just 3 Virtio-SCSI controllers seems to work fine, adding
  more than that causes the error above. Note that this is not Virtio-
  SCSI specific. I've also reproduced this without any Virtio devices
  whatsoever.

  strace shows the following ioctl chain over and over:

  145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0
  145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = 0
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)

  Which suggests there's some kind of MMIO region leak.

  [1]
  commit 3ac7d43a6fbb5d4a3d01fc9a055c218030af3727
  Author: Paolo Bonzini 
  AuthorDate: Wed Nov 28 17:28:45 2018 +0100
  Commit: Paolo Bonzini 
  CommitDate: Fri Jan 11 13:57:24 2019 +0100

  memory: update coalesced_range on transaction_commit

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

Re: [Qemu-devel] [PATCH v4 0/6] virtio-blk: add DISCARD and WRITE_ZEROES features

[Stefano Garzarella]

On Tue, Feb 12, 2019 at 09:19:13AM -0500, Michael S. Tsirkin wrote:
> On Fri, Feb 08, 2019 at 02:49:44PM +0100, Stefano Garzarella wrote:
> > This series adds the support of DISCARD and WRITE_ZEROES commands
> > and extends the virtio-blk-test to test WRITE_ZEROES command when
> > the feature is enabled.
> 
> Looking at how this wasn't merged yet, maybe it's not too late.
> 
> Series:
> 
> Reviewed-by: Michael S. Tsirkin 
> 

It's not too late :), but I'll send a new version fixing an issue in the
test and rebasing on top of "[PATCH v4] virtio-blk: set correct config
size for the host driver"

Thanks,
Stefano

Re: [Qemu-devel] [PATCH v2 1/3] s390x/cpumodel: mepochptff: warn when no mepoch and re-align group init

[Cornelia Huck]

On Mon, 11 Feb 2019 20:16:55 -0500
Collin Walling  wrote:

> The extended PTFF features (qsie, qtoue, stoe, stoue) are dependent
> on the multiple-epoch facility (mepoch). Let's print a warning if these
> features are enabled without mepoch.
> 
> While we're at it, let's move the FEAT_GROUP_INIT for mepochptff down
> the s390_feature_groups list so it can be properly indexed with its
> generated S390FeatGroup enum.
> 
> Signed-off-by: Collin Walling 
> ---
>  target/s390x/cpu_features.c | 2 +-
>  target/s390x/cpu_models.c   | 4 
>  2 files changed, 5 insertions(+), 1 deletion(-)

Thanks, applied.

Re: [Qemu-devel] [PATCH v2 2/3] s390x/cpumodel: default enable mepoch for z14 and later

[Cornelia Huck]

On Mon, 11 Feb 2019 20:16:56 -0500
Collin Walling  wrote:

> Latest systems and host kernels support mepoch, which is a
> feature that was meant to be supported for z14 GA1 from the
> get-go. Let's copy it to the z14 GA1 default CPU model.
> 
> Machines s390-ccw-virtio-3.1 and older will retain the old CPU
> models and will not provide this bit nor the extended PTFF
> functions in the default model.
> 
> Signed-off-by: Collin Walling 
> ---
> @Christian, @David: I elected to not add your r-b's to this
> patch since I've added some code to disable feature groups.
> I'd like to know what you both think :)
> ---
>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>  target/s390x/cpu_models.c   | 24 
>  target/s390x/cpu_models.h   |  2 ++
>  target/s390x/gen-features.c |  2 ++
>  4 files changed, 30 insertions(+)

This gained a conflict in s390-virtio-ccw.c, which I fixed up.

Thanks, applied.

Re: [Qemu-devel] NSIS - including DLL dependencies for Windows

[Stefan Weil]

On 13.02.19 10:32, Daniel P. Berrangé wrote:
> FYI, I re-discovered a way to do this without needing wine, just plain
> binutils
> 
>   x86_64-w64-mingw32-objdump -p /path/to/binary.exe | grep "DLL Name" | awk 
> '{print $3}'


See also https://github.com/gsauthof/pe-util. The command line tool
peldd displays the DLLs recursively.

Regards
Stefan

Re: [Qemu-devel] [PATCH v2 3/3] s390x/cpumodel: add z14 GA2 model

[Cornelia Huck]

On Mon, 11 Feb 2019 20:16:57 -0500
Collin Walling  wrote:

> Introduce the z14 GA2 cpu model for QEMU. There are no new features
> introduced with this model, and will inherit the same feature set as
> z14 GA1.
> 
> Signed-off-by: Collin Walling 
> Acked-by: Christian Borntraeger 
> Reviewed-by: David Hildenbrand 
> ---
>  target/s390x/cpu_models.c   | 1 +
>  target/s390x/gen-features.c | 7 +++
>  2 files changed, 8 insertions(+)

Thanks, applied.

Re: [Qemu-devel] [PATCH] hw/dma/i8257: Use qemu_log_mask(UNIMP) instead of fprintf

[Stefano Garzarella]

On Tue, Feb 12, 2019 at 03:53:22PM +0100, Philippe Mathieu-Daudé wrote:
> Avoid to clutter stdout until explicitly requested (with -d unimp):
> 
>   $ qemu-system-mips64el -M fulong2e -bios pmon_2e.bin
>   dma: command df not supported
>   dma: command df not supported
>   dma: command df not supported
>   dma: command df not supported
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/dma/i8257.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Stefano Garzarella 

Thanks,
Stefano

[Qemu-devel] Seeking QEMU makefile advice

[Markus Armbruster]

Hi Paolo,

I'm trying to resolve a FIXME in a patch I recently posted.  Here's what
I want to do:

QAPI_COMMON_MODULES = block-core block char common crypto introspect
QAPI_COMMON_MODULES += job migration misc net rdma rocker run-state
QAPI_COMMON_MODULES += sockets tpm trace transaction ui
QAPI_TARGET_MODULES = target
QAPI_MODULES = $(QAPI_COMMON_MODULES) $(QAPI_TARGET_MODULES)

util-obj-y += qapi/qapi-builtin-types.o
util-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-types-%.o)
util-obj-y += qapi/qapi-builtin-visit.o
util-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-visit-%.o)
util-obj-y += qapi/qapi-emit-events.o
util-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-events-%.o)

obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-types-%.o)
obj-y += qapi/qapi-types.o
obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-visit-%.o)
obj-y += qapi/qapi-visit.o
obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-events-%.o)
obj-y += qapi/qapi-events.o
obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-commands-%.o)
obj-y += qapi/qapi-commands.o
obj-y += qapi/qapi-introspect.o

Simple enough, except which part goes where?

First attempt:

* Define QAPI_COMMON_MODULES, QAPI_TARGET_MODULES and QAPI_MODULES in
  Makefile.obj

* Add to util-obj-y in Makefile.obj

* Add to obj-y in Makefile.target

  No go, because QAPI_TARGET_MODULES is blank there.  To make progress,
  I duplicated its definition there, marked FIXME.

Message-Id: <20190206181725.14337-8-arm...@redhat.com>
https://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg01652.html
Diff appended for your convenience.

I've since realized QAPI_TARGET_MODULES is blank there because it only
gets defined further down, via include $(SRC_PATH)/Makefile.objs.

This leads me to my problem:

* On the one hand, I want to add to obj-y after the include defines
  QAPI_TARGET_MODULES.

* On the other hand, I need to be done with adding to obj-y before the
  all-obj-y := $(obj-y) line.

Can't satisfy both.  Any ideas on how to better distribute the work
between the makefiles?



diff --git a/Makefile.objs b/Makefile.objs
index 70ee51742f..5f0a7a8ca5 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -1,20 +1,19 @@
-QAPI_MODULES = block-core block char common crypto introspect job migration
-QAPI_MODULES += misc net rdma rocker run-state sockets tpm trace transaction
-QAPI_MODULES += ui
+QAPI_COMMON_MODULES = block-core block char common crypto introspect
+QAPI_COMMON_MODULES += job migration misc net rdma rocker run-state
+QAPI_COMMON_MODULES += sockets tpm trace transaction ui
+QAPI_TARGET_MODULES = target
+QAPI_MODULES = $(QAPI_COMMON_MODULES) $(QAPI_TARGET_MODULES)
 
 ###
 # Common libraries for tools and emulators
 stub-obj-y = stubs/ crypto/
 util-obj-y = util/ qobject/ qapi/
 util-obj-y += qapi/qapi-builtin-types.o
-util-obj-y += qapi/qapi-types.o
-util-obj-y += $(QAPI_MODULES:%=qapi/qapi-types-%.o)
+util-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-types-%.o)
 util-obj-y += qapi/qapi-builtin-visit.o
-util-obj-y += qapi/qapi-visit.o
-util-obj-y += $(QAPI_MODULES:%=qapi/qapi-visit-%.o)
+util-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-visit-%.o)
 util-obj-y += qapi/qapi-emit-events.o
-util-obj-y += qapi/qapi-events.o
-util-obj-y += $(QAPI_MODULES:%=qapi/qapi-events-%.o)
+util-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-events-%.o)
 
 chardev-obj-y = chardev/
 slirp-obj-$(CONFIG_SLIRP) = slirp/
@@ -92,8 +91,7 @@ common-obj-$(CONFIG_FDT) += device_tree.o
 ##
 # qapi
 
-common-obj-y += qapi/qapi-commands.o
-common-obj-y += $(QAPI_MODULES:%=qapi/qapi-commands-%.o)
+common-obj-y += $(QAPI_COMMON_MODULES:%=qapi/qapi-commands-%.o)
 common-obj-y += qmp.o hmp.o
 endif
 
diff --git a/Makefile.target b/Makefile.target
index d8af835890..f908477040 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -164,6 +164,16 @@ endif
 
 GENERATED_FILES += hmp-commands.h hmp-commands-info.h
 
+# FIXME duplicates Makefile.obj's
+QAPI_TARGET_MODULES = target
+obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-types-%.o)
+obj-y += qapi/qapi-types.o
+obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-visit-%.o)
+obj-y += qapi/qapi-visit.o
+obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-events-%.o)
+obj-y += qapi/qapi-events.o
+obj-y += $(QAPI_TARGET_MODULES:%=qapi/qapi-commands-%.o)
+obj-y += qapi/qapi-commands.o
 obj-y += qapi/qapi-introspect.o
 
 endif # CONFIG_SOFTMMU
diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
index 1845aa78ff..db61bfd688 100644
--- a/qapi/qapi-schema.json
+++ b/qapi/qapi-schema.json
@@ -97,3 +97,4 @@
 { 'include': 'trace.json' }
 { 'include': 'introspect.json' }
 { 'include': 'misc.json' }
+{ 'include': 'target.json' }
diff --git a/qapi/target.json b/qapi/target.json
new file mode 100644
index 00..8054926293
--- /dev/null
+++ b/qapi/target.json
@@ -0,0 +1,13 @@
+# -*- Mode: Python -*-
+#
+
+##
+# = Tar

Re: [Qemu-devel] [Qemu-ppc] [PATCH 13/13] spapr: add KVM support to the 'dual' machine

[Greg Kurz]

On Wed, 13 Feb 2019 09:22:46 +0100
Cédric Le Goater  wrote:

> On 2/13/19 2:32 AM, David Gibson wrote:
> > On Tue, Feb 12, 2019 at 08:18:19AM +0100, Cédric Le Goater wrote:  
> >> On 2/12/19 2:11 AM, David Gibson wrote:  
> >>> On Mon, Jan 07, 2019 at 07:39:46PM +0100, Cédric Le Goater wrote:  
>  The interrupt mode is chosen by the CAS negotiation process and
>  activated after a reset to take into account the required changes in
>  the machine. This brings new constraints on how the associated KVM IRQ
>  device is initialized.
> 
>  Currently, each model takes care of the initialization of the KVM
>  device in their realize method but this is not possible anymore as the
>  initialization needs to be done globaly when the interrupt mode is
>  known, i.e. when machine is reseted. It also means that we need a way
>  to delete a KVM device when another mode is chosen.
> 
>  Also, to support migration, the QEMU objects holding the state to
>  transfer should always be available but not necessarily activated.
> 
>  The overall approach of this proposal is to initialize both interrupt
>  mode at the QEMU level and keep the IRQ number space in sync to allow
>  switching from one mode to another. For the KVM side of things, the
>  whole initialization of the KVM device, sources and presenters, is
>  grouped in a single routine. The XICS and XIVE sPAPR IRQ reset
>  handlers are modified accordingly to handle the init and the delete
>  sequences of the KVM device.
> 
>  As KVM is now initialized at reset, we loose the possiblity to
>  fallback to the QEMU emulated mode in case of failure and failures
>  become fatal to the machine.
> 
>  Signed-off-by: Cédric Le Goater 
>  ---
>   hw/intc/spapr_xive.c |  8 +---
>   hw/intc/spapr_xive_kvm.c | 27 ++
>   hw/intc/xics_kvm.c   | 25 +
>   hw/intc/xive.c   |  4 --
>   hw/ppc/spapr_irq.c   | 79 
>   5 files changed, 109 insertions(+), 34 deletions(-)
> 
>  diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
>  index 21f3c1ef0901..0661aca35900 100644
>  --- a/hw/intc/spapr_xive.c
>  +++ b/hw/intc/spapr_xive.c
>  @@ -330,13 +330,7 @@ static void spapr_xive_realize(DeviceState *dev, 
>  Error **errp)
>   xive->eat = g_new0(XiveEAS, xive->nr_irqs);
>   xive->endt = g_new0(XiveEND, xive->nr_ends);
>   
>  -if (kvmppc_xive_enabled()) {
>  -kvmppc_xive_connect(xive, &local_err);
>  -if (local_err) {
>  -error_propagate(errp, local_err);
>  -return;
>  -}
>  -} else {
>  +if (!kvmppc_xive_enabled()) {
>   /* TIMA initialization */
>   memory_region_init_io(&xive->tm_mmio, OBJECT(xive), 
>  &xive_tm_ops, xive,
> "xive.tima", 4ull << TM_SHIFT);
>  diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
>  index d35814c1992e..3ebc947f2be7 100644
>  --- a/hw/intc/spapr_xive_kvm.c
>  +++ b/hw/intc/spapr_xive_kvm.c
>  @@ -737,6 +737,15 @@ void kvmppc_xive_connect(sPAPRXive *xive, Error 
>  **errp)
>   Error *local_err = NULL;
>   size_t esb_len;
>   size_t tima_len;
>  +CPUState *cs;
>  +
>  +/*
>  + * The KVM XIVE device already in use. This is the case when
>  + * rebooting XIVE -> XIVE  
> >>>
> >>> Can this case actually occur?  Further down you appear to
> >>> unconditionally destroy both KVM devices at reset time.  
> >>
> >> I guess you are right. I will check.
> >>  
>  + */
>  +if (xive->fd != -1) {
>  +return;
>  +}
>   
>   if (!kvm_enabled() || !kvmppc_has_cap_xive()) {
>   error_setg(errp, "IRQ_XIVE capability must be present for KVM");
>  @@ -800,6 +809,24 @@ void kvmppc_xive_connect(sPAPRXive *xive, Error 
>  **errp)
>   xive->change = qemu_add_vm_change_state_handler(
>   kvmppc_xive_change_state_handler, xive);
>   
>  +/* Connect the presenters to the initial VCPUs of the machine */
>  +CPU_FOREACH(cs) {
>  +PowerPCCPU *cpu = POWERPC_CPU(cs);
>  +
>  +kvmppc_xive_cpu_connect(cpu->tctx, &local_err);
>  +if (local_err) {
>  +error_propagate(errp, local_err);
>  +return;
>  +}
>  +}
>  +
>  +/* Update the KVM sources */
>  +kvmppc_xive_source_reset(xsrc, &local_err);
>  +if (local_err) {
>  +error_propagate(errp, local_err);
>  +return;
>  +}
>  +
>   kvm_kernel_irqchip = true;
>   kvm_msi_via_irqfd_allowed = true;
>   kvm_gsi_direct_mapping = true;
>  diff --git a/

Re: [Qemu-devel] [Qemu-block] [RFC PATCH] coroutines: generate wrapper code

[Kevin Wolf]

Am 13.02.2019 um 07:58 hat Stefan Hajnoczi geschrieben:
> On Tue, Feb 12, 2019 at 12:58:40PM +0100, Kevin Wolf wrote:
> > Am 12.02.2019 um 04:22 hat Stefan Hajnoczi geschrieben:
> > > On Mon, Feb 11, 2019 at 09:38:37AM +, Vladimir Sementsov-Ogievskiy 
> > > wrote:
> > > > 11.02.2019 6:42, Stefan Hajnoczi wrote:
> > > > > On Fri, Feb 08, 2019 at 05:11:22PM +0300, Vladimir 
> > > > > Sementsov-Ogievskiy wrote:
> > > > >> Hi all!
> > > > >>
> > > > >> We have a very frequent pattern of wrapping a coroutine_fn function
> > > > >> to be called from non-coroutine context:
> > > > >>
> > > > >>- create structure to pack parameters
> > > > >>- create function to call original function taking parameters from
> > > > >>  struct
> > > > >>- create wrapper, which in case of non-coroutine context will
> > > > >>  create a coroutine, enter it and start poll-loop.
> > > > >>
> > > > >> Here is a draft of template code + example how it can be used to 
> > > > >> drop a
> > > > >> lot of similar code.
> > > > >>
> > > > >> Hope someone like it except me)
> > > > > 
> > > > > My 2 cents.  Cons:
> > > > > 
> > > > >   * Synchronous poll loops are an anti-pattern.  They block all of 
> > > > > QEMU
> > > > > with the big mutex held.  Making them easier to write is
> > > > > questionable because we should aim to have as few of these as
> > > > > possible.
> > > > 
> > > > Understand. Do we have a concept or a kind of target for a future to 
> > > > get rid of
> > > > these a lot of poll-loops? What is the right way? At least for 
> > > > block-layer?
> > > 
> > > It's non-trivial.  The nested event loop could be flattened if there was
> > > a mechanism to stop further activity on a specific object only (e.g.
> > > BlockDriverState).  That way the event loop can continue processing
> > > events for other objects and device emulation could continue for other
> > > objects.
> > 
> > The mechanism to stop activity on BlockDriverStates is bdrv_drain(). But
> > I don't see how this is related. Nested event loops aren't for stopping
> > concurrent activity (events related to async operations started earlier
> > are still processed in nested event loops), but for making progress on
> > the operation we're waiting for. They happen when synchronous code calls
> > into asynchronous code.
> > 
> > The way to get rid of them is making their callers async. I think we
> > would come a long way if we ran QMP command handlers (at least the block
> > related ones) and qemu-img operations in coroutines instead of blocking
> > while we wait for the result.
> 
> A difficult caller is device reset, where we need to drain all requests.
> But even converting some sync code paths to async is a win because it
> removes places where QEMU can get stuck.

Yes, as I said, draining a node can hang. And it can hang not because
there are nested event loops or because of any other bad design
decision, but because waiting for all requests to complete is required.

The only thing we could try to improve this is cancelling requests after
a timeout (or triggered by an OOB QMP command?) during a drain
operation, but cancelling requests hasn't really been a success story so
far.

> Regarding block QMP handlers, do you mean suspending the monitor when
> a command yields?  The monitor will be unresponsive to the outside
> world, so this doesn't solve the problem from the QMP client's
> perspective.  This is why async QMP and jobs are interesting but it's a
> lot of work both inside QEMU and for clients like libvirt.

Yes, it wouldn't keep the monitor responsive as long as the monitor
protocol is synchronous. But it would keep the VM running at least, the
GUI would stay responsive etc.

Blocking the monitor is again nothing that restructuring the code could
fix. It requires a change to the QMP protocol, but then it will easily
fit in the current design.

Nested event loops are unrelated.

> > > Unfortunately there are interactions between objects like in block jobs
> > > that act on multiple BDSes, so it becomes even tricky.
> > > 
> > > A simple way of imagining this is to make each object an "actor"
> > > coroutine.  The coroutine processes a single message (request) at a time
> > > and yields when it needs to wait.  Callers send messages and expect
> > > asynchronous responses.  This model is bad for efficiency (parallelism
> > > is necessary) but at least it offers a sane way of thinking about
> > > multiple asynchronous components coordinating together.  (It's another
> > > way of saying, let's put everything into coroutines.)
> > > 
> > > The advantage of a flat event loop is that a hang in one object (e.g.
> > > I/O getting stuck in one file) doesn't freeze the entire event loop.
> > 
> > I think this one is more theoretical because you'll still have
> > dependencies between the components. blk_drain_all() isn't hanging
> > because the code is designed suboptimally, but because its semantics is
> > to wait until all requests h

Re: [Qemu-devel] [PATCH v2 4/9] {monitor, hw/pvrdma}: Expose device internals via monitor interface

[Dr. David Alan Gilbert]

* Yuval Shaia (yuval.sh...@oracle.com) wrote:
> Allow interrogating device internals through HMP interface.
> The exposed indicators can be used for troubleshooting by developers or
> sysadmin.
> There is no need to expose these attributes to a management system (e.x.
> libvirt) because (1) most of them are not "device-management' related
> info and (2) there is no guarantee the interface is stable.
> 
> Signed-off-by: Yuval Shaia 

OK for HMP

Acked-by: Dr. David Alan Gilbert 

> ---
>  hmp-commands-info.hx  | 16 
>  hw/rdma/rdma_backend.c| 70 ++-
>  hw/rdma/rdma_rm.c |  7 
>  hw/rdma/rdma_rm_defs.h| 27 +-
>  hw/rdma/vmw/pvrdma.h  |  5 +++
>  hw/rdma/vmw/pvrdma_hmp.h  | 21 +++
>  hw/rdma/vmw/pvrdma_main.c | 77 +++
>  monitor.c | 10 +
>  8 files changed, 215 insertions(+), 18 deletions(-)
>  create mode 100644 hw/rdma/vmw/pvrdma_hmp.h
> 
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index cbee8b944d..9153c33974 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -524,6 +524,22 @@ STEXI
>  Show CPU statistics.
>  ETEXI
>  
> +#if defined(CONFIG_PVRDMA)
> +{
> +.name   = "pvrdmacounters",
> +.args_type  = "",
> +.params = "",
> +.help   = "show pvrdma device counters",
> +.cmd= hmp_info_pvrdmacounters,
> +},
> +
> +STEXI
> +@item info pvrdmacounters
> +@findex info pvrdmacounters
> +Show pvrdma device counters.
> +ETEXI
> +#endif
> +
>  #if defined(CONFIG_SLIRP)
>  {
>  .name   = "usernet",
> diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
> index 3a2913facf..0fb4842970 100644
> --- a/hw/rdma/rdma_backend.c
> +++ b/hw/rdma/rdma_backend.c
> @@ -64,9 +64,9 @@ static inline void complete_work(enum ibv_wc_status status, 
> uint32_t vendor_err,
>  comp_handler(ctx, &wc);
>  }
>  
> -static void rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq 
> *ibcq)
> +static int rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq 
> *ibcq)
>  {
> -int i, ne;
> +int i, ne, total_ne = 0;
>  BackendCtx *bctx;
>  struct ibv_wc wc[2];
>  
> @@ -89,12 +89,18 @@ static void rdma_poll_cq(RdmaDeviceResources 
> *rdma_dev_res, struct ibv_cq *ibcq)
>  rdma_rm_dealloc_cqe_ctx(rdma_dev_res, wc[i].wr_id);
>  g_free(bctx);
>  }
> +total_ne += ne;
>  } while (ne > 0);
> +atomic_sub(&rdma_dev_res->stats.missing_cqe, total_ne);
>  qemu_mutex_unlock(&rdma_dev_res->lock);
>  
>  if (ne < 0) {
>  rdma_error_report("ibv_poll_cq fail, rc=%d, errno=%d", ne, errno);
>  }
> +
> +rdma_dev_res->stats.completions += total_ne;
> +
> +return total_ne;
>  }
>  
>  static void *comp_handler_thread(void *arg)
> @@ -122,6 +128,9 @@ static void *comp_handler_thread(void *arg)
>  while (backend_dev->comp_thread.run) {
>  do {
>  rc = qemu_poll_ns(pfds, 1, THR_POLL_TO * (int64_t)SCALE_MS);
> +if (!rc) {
> +backend_dev->rdma_dev_res->stats.poll_cq_ppoll_to++;
> +}
>  } while (!rc && backend_dev->comp_thread.run);
>  
>  if (backend_dev->comp_thread.run) {
> @@ -138,6 +147,7 @@ static void *comp_handler_thread(void *arg)
>errno);
>  }
>  
> +backend_dev->rdma_dev_res->stats.poll_cq_from_bk++;
>  rdma_poll_cq(backend_dev->rdma_dev_res, ev_cq);
>  
>  ibv_ack_cq_events(ev_cq, 1);
> @@ -271,7 +281,13 @@ int rdma_backend_query_port(RdmaBackendDev *backend_dev,
>  
>  void rdma_backend_poll_cq(RdmaDeviceResources *rdma_dev_res, RdmaBackendCQ 
> *cq)
>  {
> -rdma_poll_cq(rdma_dev_res, cq->ibcq);
> +int polled;
> +
> +rdma_dev_res->stats.poll_cq_from_guest++;
> +polled = rdma_poll_cq(rdma_dev_res, cq->ibcq);
> +if (!polled) {
> +rdma_dev_res->stats.poll_cq_from_guest_empty++;
> +}
>  }
>  
>  static GHashTable *ah_hash;
> @@ -333,7 +349,7 @@ static void ah_cache_init(void)
>  
>  static int build_host_sge_array(RdmaDeviceResources *rdma_dev_res,
>  struct ibv_sge *dsge, struct ibv_sge *ssge,
> -uint8_t num_sge)
> +uint8_t num_sge, uint64_t *total_length)
>  {
>  RdmaRmMR *mr;
>  int ssge_idx;
> @@ -349,6 +365,8 @@ static int build_host_sge_array(RdmaDeviceResources 
> *rdma_dev_res,
>  dsge->length = ssge[ssge_idx].length;
>  dsge->lkey = rdma_backend_mr_lkey(&mr->backend_mr);
>  
> +*total_length += dsge->length;
> +
>  dsge++;
>  }
>  
> @@ -445,8 +463,10 @@ void rdma_backend_post_send(RdmaBackendDev *backend_dev,
>  rc = mad_send(backend_dev, sgid_idx, sgid, sge, num_sge);
>  if (rc) {
>  complete_work(IBV_WC_GENER

[Qemu-devel] [PATCH] s390x: upgrade status of KVM cores to "supported"

[Cornelia Huck]

We are actually paid to look after this.

Signed-off-by: Cornelia Huck 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9a76845581b1..73ff5915638e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -377,7 +377,7 @@ S390
 M: Halil Pasic 
 M: Cornelia Huck 
 M: Christian Borntraeger 
-S: Maintained
+S: Supported
 F: target/s390x/kvm.c
 F: target/s390x/kvm_s390x.h
 F: target/s390x/kvm-stub.c
-- 
2.17.2

Re: [Qemu-devel] [PATCH] s390x/kvm: add tracepoint to ioeventfd interface

[Cornelia Huck]

On Tue, 12 Feb 2019 17:12:33 +0100
David Hildenbrand  wrote:

> On 12.02.19 16:58, Cornelia Huck wrote:
> > On Tue, 12 Feb 2019 16:52:09 +0100
> > Philippe Mathieu-Daudé  wrote:
> >   
> >> Hi Cornelia,
> >>
> >> On 2/12/19 4:30 PM, Cornelia Huck wrote:  
> >>> Trace when assigning/unassigning.
> >>>
> >>> Signed-off-by: Cornelia Huck 
> >>> ---
> >>>  target/s390x/kvm.c| 2 ++
> >>>  target/s390x/trace-events | 1 +
> >>>  2 files changed, 3 insertions(+)
> >>>
> >>> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> >>> index 15fdc168e1c5..7d61bd109092 100644
> >>> --- a/target/s390x/kvm.c
> >>> +++ b/target/s390x/kvm.c
> >>> @@ -1886,6 +1886,8 @@ int kvm_s390_assign_subch_ioeventfd(EventNotifier 
> >>> *notifier, uint32_t sch,
> >>>  .addr = sch,
> >>>  .len = 8,
> >>>  };
> >>> +trace_kvm_s390_assign_subch_ioeventfd(kick.fd, kick.addr, assign,
> >>> +  kick.datamatch);
> >>>  if (!kvm_check_extension(kvm_state, KVM_CAP_IOEVENTFD)) {
> >>>  return -ENOSYS;
> >>>  }
> >>> diff --git a/target/s390x/trace-events b/target/s390x/trace-events
> >>> index a84e316e4937..bdc22f42cdbb 100644
> >>> --- a/target/s390x/trace-events
> >>> +++ b/target/s390x/trace-events
> >>> @@ -14,6 +14,7 @@ ioinst_chsc_cmd(uint16_t cmd, uint16_t len) "IOINST: 
> >>> chsc command 0x%04x, len 0x
> >>>  kvm_enable_cmma(int rc) "CMMA: enabling with result code %d"
> >>>  kvm_clear_cmma(int rc) "CMMA: clearing with result code %d"
> >>>  kvm_failed_cpu_state_set(int cpu_index, uint8_t state, const char *msg) 
> >>> "Warning: Unable to set cpu %d state %" PRIu8 " to KVM: %s"
> >>> +kvm_s390_assign_subch_ioeventfd(int fd, uint32_t addr, bool assign, int 
> >>> datamatch) "fd: %d sch: @0x%x assign: %d vq: %d"
> >>
> >> I noticed all s390x related trace events don't specify 's390' in the
> >> event name, maybe you can simply strip it. If you agree, feel free to
> >> apply that change directly yourself, no need for v2 ;)  
> > 
> > Yeah; not exactly sure why the other events do that, though... I can
> > strip it if others agree.  
> 
> Yes, let's keep it consistent. Or if you feel like crafting patches,
> rename the others ;)

I just went with the path of least resistance and removed the 's390' :)

Any acks before I queue this?

Re: [Qemu-devel] [RFC v1 2/3] intel_iommu: add 256 bits qi_desc support

[Peter Xu]

On Wed, Feb 13, 2019 at 05:00:41PM +0800, Yi Sun wrote:

[...]

> > >  
> > >  /* context entry operations */
> > >  #define vtd_get_ce_size(s, ce) \
> > > @@ -65,6 +66,9 @@
> > >  #define vtd_pe_get_slpt_base(pe) ((pe)->val[0] & 
> > > VTD_SM_PASID_ENTRY_SLPTPTR)
> > >  #define vtd_pe_get_domain_id(pe) VTD_SM_PASID_ENTRY_DID((pe)->val[1])
> > >  
> > > +/* invalidation desc */
> > > +#define vtd_get_inv_desc_width(s) ((s)->iq_dw ? 32 : 16)
> > 
> > Nit: I'll prefer dropping all the "get" wordings in these macros to be
> > "vtd_inv_desc_width" since that "get" doesn't help much on
> > understanding its meanings.  But it's personal preference too.
> > 
> That is fine.
> 
> > And since you've already have the iq_dw variable - why not store the
> > width directly into it?  An uint8_t would suffice.
> > 
> iq_dw corresponds to VTD_IQA_DW_MASK (Descriptor Width defined in IQA
> register). 1 means 256-bit descriptor, 0 means 128-bit descriptor.
> 
> It is also used in vtd_handle_gcmd_qie() and VTD_IQT_QT() by checking if
> its value is 1.
> 
> So, I would prefer to keep the original design.

It's ok.   But please make it a boolean.  Now iq_dw can be 0x800.

[...]

> > >  /* Fetch an Invalidation Descriptor from the Invalidation Queue */
> > > -static bool vtd_get_inv_desc(dma_addr_t base_addr, uint32_t offset,
> > > +static bool vtd_get_inv_desc(IntelIOMMUState *s,
> > >   VTDInvDesc *inv_desc)
> > >  {
> > > -dma_addr_t addr = base_addr + offset * sizeof(*inv_desc);
> > > -if (dma_memory_read(&address_space_memory, addr, inv_desc,
> > > -sizeof(*inv_desc))) {
> > > -error_report_once("Read INV DESC failed");
> > > -inv_desc->lo = 0;
> > > -inv_desc->hi = 0;
> > > +dma_addr_t base_addr = s->iq;
> > > +uint32_t offset = s->iq_head;
> > > +uint32_t dw = vtd_get_inv_desc_width(s);
> > > +dma_addr_t addr = base_addr + offset * dw;
> > > +
> > > +/* init */
> > > +inv_desc->val[0] = 0;
> > > +inv_desc->val[1] = 0;
> > > +inv_desc->val[2] = 0;
> > > +inv_desc->val[3] = 0;
> > 
> > No need?
> > 
> This is necessary. Per my test, the val[] are not 0 by default.

I agree, it's a stack variable. However...

> That makes bug happen.

... could you explain the bug?

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v3 3/3] tpm_tis: convert tpm_tis_show_buffer() to use trace event

[Liam Merwick]

On 12/02/2019 21:01, Stefan Berger wrote:

On 2/12/19 3:48 PM, Liam Merwick wrote:

cppcheck reports:

[hw/tpm/tpm_tis.c:113]: (warning) %d in format string (no. 2) requires 
'int' but the argument type is 'unsigned int'


Rather than just converting the format specifier to use '%u", the
tpm_tis_show_buffer() function is converted to use trace points and
the two debug callers use the trace event infrastructure so that it's
available in production cases also and not just when DEBUG_TIS is 
enabled.


Signed-off-by: Liam Merwick 
---

Sample trace output

% echo tpm_tis_show_buffer > /tmp/events
% export 
QTEST_QEMU_BINARY="/home/Development/qemu-upstream/x86_64-softmmu/qemu-system-x86_64 
--trace events=/tmp/events"

% tests/tpm-tis-test
/D=/home/Development/qemu-upstream/hw/tpm/tpm-tis/test_check_localities: 
OK
/D=/home/Development/qemu-upstream/hw/tpm/tpm-tis/test_check_access_reg: 
OK
/D=/home/Development/qemu-upstream/hw/tpm/tpm-tis/test_check_access_reg_seize: 
OK
/D=/home/Development/qemu-upstream/hw/tpm/tpm-tis/test_check_access_reg_release: 
OK

/D=/home/Development/qemu-upstream/hw/tpm/tpm-tis/test_check_transmit: OK
% ./scripts/simpletrace.py trace-events-all trace-30665
tpm_tis_show_buffer 0.000 pid=30665 string=tpm_tis: To TPM len=0xc 
line=80 01 00 00 00 0C 00 00 01 44 00 00
tpm_tis_show_buffer 256.581 pid=30665 string=tpm_tis: From TPM len=0xa 
line=80 01 00 00 00 0A 00 00 01 01



should now be 'length=10' and then a new line with just the bytes?



The example I gave was using --enable-trace-backends=simple (which 
AFAICT doesn't use the format string, just the name/type of the parameters)


tpm_tis_show_buffer 0.000 pid=8416 direction=To TPM len=0xc line=80 01 
00 00 00 0C 00 00 01 44 00 00
tpm_tis_show_buffer 303.909 pid=8416 direction=From TPM len=0xa line=80 
01 00 00 00 0A 00 00 01 01


Below is the output with --enable-trace-backends=log which does include 
the newline


1255@1550051983.333949:tpm_tis_show_buffer direction: To TPM len: 12
buf: 80 01 00 00 00 0C 00 00 01 44 00 00
1255@1550051983.334213:tpm_tis_show_buffer direction: From TPM len: 10
buf: 80 01 00 00 00 0A 00 00 01 01

(those include a few tweaks for v4 I made based on investigating this 
question: dropped "tpm_tis: " since the function name is now printed by 
the tracing framework, renamed some of the parameters to 
trace_tpm_tis_show_buffer() and adjusted the format string)



diff --git a/hw/tpm/tpm_tis.c b/hw/tpm/tpm_tis.c
index 18e19d5f900d..d7b9bee85741 100644
--- a/hw/tpm/tpm_tis.c
+++ b/hw/tpm/tpm_tis.c
@@ -155,8 +155,7 @@ static void tpm_tis_sts_set(TPMLocality *l, uint32_t 
flags)

 static void tpm_tis_tpm_send(TPMState *s, uint8_t locty)
 {
 if (trace_event_get_state_backends(TRACE_TPM_TIS_SHOW_BUFFER)) {
-tpm_tis_show_buffer(s->buffer, s->be_buffer_size,
-"tpm_tis: To TPM");
+tpm_tis_show_buffer(s->buffer, s->be_buffer_size, "To TPM");
 }

 /*
@@ -325,8 +324,7 @@ static void tpm_tis_request_completed(TPMIf *ti, int 
ret)

 s->rw_offset = 0;

 if (trace_event_get_state_backends(TRACE_TPM_TIS_SHOW_BUFFER)) {
-tpm_tis_show_buffer(s->buffer, s->be_buffer_size,
-"tpm_tis: From TPM");
+tpm_tis_show_buffer(s->buffer, s->be_buffer_size, "From TPM");
 }

 if (TPM_TIS_IS_VALID_LOCTY(s->next_locty)) {
diff --git a/hw/tpm/trace-events b/hw/tpm/trace-events
index c0267d075027..f45dcd220993 100644
--- a/hw/tpm/trace-events
+++ b/hw/tpm/trace-events
@@ -36,7 +36,7 @@ tpm_emulator_pre_save(void) ""
 tpm_emulator_inst_init(void) ""

 # hw/tpm/tpm_tis.c
-tpm_tis_show_buffer(const char *string, size_t len, const char *line) 
"tpm_tis: %s length = %zu\n%s"
+tpm_tis_show_buffer(const char *direction, size_t len, const char *buf) 
"direction: %s len: %zu\nbuf: %s







  hw/tpm/tpm_tis.c    | 25 +
  hw/tpm/trace-events |  1 +
  2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/hw/tpm/tpm_tis.c b/hw/tpm/tpm_tis.c
index 772431f20874..18e19d5f900d 100644
--- a/hw/tpm/tpm_tis.c
+++ b/hw/tpm/tpm_tis.c
@@ -108,17 +108,26 @@ static uint8_t tpm_tis_locality_from_addr(hwaddr 
addr)

  static void tpm_tis_show_buffer(const unsigned char *buffer,
  size_t buffer_size, const char *string)
  {
-    uint32_t len, i;
+    size_t len, i;
+    char *line_buffer, *p;
  len = MIN(tpm_cmd_get_size(buffer), buffer_size);
-    printf("tpm_tis: %s length = %d\n", string, len);
-    for (i = 0; i < len; i++) {
+
+    /*
+ * allocate enough room for 3 chars per buffer entry plus
+ * a newline after every 16 chars.



This is missing the terminating null byte.




will fix in v4

Regards,
Liam





+ */
+    line_buffer = g_malloc(len * 3 + (len / 16));
+
+    for (i = 0, p = line_buffer; i < len; i++) {
  if (i && !(i % 16)) {
-    printf("\n");
+    p += sprintf(p, "\n");
  }
-    printf("%.2X ", buffer[i]);
+    

Re: [Qemu-devel] Combining -loadvm and -snapshot

[Kevin Wolf]

Am 13.02.2019 um 07:07 hat Markus Armbruster geschrieben:
> Cc'ing the QCOW2 folks.
> 
> Drew DeVault  writes:
> 
> > I recently ran into an issue where I found I couldn't combine the
> > -loadvm and -snapshot flags, nor any conceivable combination of
> > alternate approaches like loadvm via the monitor. Independently, both
> > options work as expected, but together I get this error:
> >
> > qemu-system-x86_64: Device 'virtio0' does not have the requested snapshot 
> > 'base'
> >
> > The goal here is to resume the VM state from a snapshot, but to prevent
> > the guest from persisting writes to the underlying qcow2.
> >
> > I started digging into the code to understand this problem more, and I
> > was pretty deep in the weeds when I realized what the underlying problem
> > probably was and the kind of refactoring necessary to fix it - so I'm
> > here to touch base before moving any further.
> >
> > I believe this happens because -snapshot creates a temporary qcow2
> > overlaid on top of the disk you're using, and this overlay does not have
> > any snapshots copied, nor does any of the snapshot reading code (e.g.
> > qcow2_snapshot_list or qcow2_snapshot_goto) iterate over backing disks
> > to load their snapshots.
> >
> > At first I was going to adjust the qcow2 snapshot loading code (those
> > two functions in particular) to read through their backends, but I'm a
> > little unfamiliar with this code and the refactoring is not minor so I
> > would like to get feedback from some of the wiser folks on this mailing
> > list before I sink too much time into this.
> >
> > Thoughts?

Reading from the backing file would be correct in your special case
(because the overlay was only just created and doesn't contain data
yet), but generally speaking, this would make the disk content
inconsistent because it would mix newer data from the overlay with old
data from the snapshot in the backing file.

But before I make suggestions how this could be addressed (it's probably
not trivial), let me ask what your real goal is?

I'm asking because when you start a VM with '-loadvm foo', this means
that you already got a snapshot at this exact point. So the guest will
write to the qcow2 file, but when you start the VM the next time, and
again with '-loadvm foo', the newly written data will be discarded and
QEMU will revert to the snapshot 'foo' again. So you already got the
same functionality that -snapshot is supposed to provide, even without
using it.

Do you have other reasons why you want to use -snapshot?

Kevin

Re: [Qemu-devel] [PATCH] s390x: upgrade status of KVM cores to "supported"

[Christian Borntraeger]

On 13.02.2019 11:35, Cornelia Huck wrote:
> We are actually paid to look after this.
> 
> Signed-off-by: Cornelia Huck 

Acked-by: Christian Borntraeger 

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9a76845581b1..73ff5915638e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -377,7 +377,7 @@ S390
>  M: Halil Pasic 
>  M: Cornelia Huck 
>  M: Christian Borntraeger 
> -S: Maintained
> +S: Supported
>  F: target/s390x/kvm.c
>  F: target/s390x/kvm_s390x.h
>  F: target/s390x/kvm-stub.c
> 

[Qemu-devel] Clearing slirp/ license

[Marc-André Lureau]

Hi,

As we are trying to move slirp/ in a standalone project, which
eventually could be installed as a shared library, we need to clear
the license.

slirp is supposed to be 3-Clause BSD license (according to
https://git.qemu.org/?p=qemu.git;a=commit;h=2f5f89963186d42a7ded253bc6cf5b32abb45cec)
but it seems to be effectively a 2-Clause BSD (the third clause is not
in COPYRIGHT)

However, there are two units that are GPL-2:

- dhcpv6.c, dhcpv6.h:
  The code was contributed by Thomas Huth 

$ git shortlog -nes slirp/dhcpv6.{c,h}
 6  Marc-André Lureau 
 1  Philippe Mathieu-Daudé 
 1  Thomas Huth 
 1  Yuval Shaia 

- ncsi.c, ncsi-pkt.h:
  The code was contributed by Cédric Le Goater 

$ git shortlog -nes slirp/ncsi.c slirp/ncsi-pkt.h
 5  Marc-André Lureau 
 4  Cédric Le Goater 

Could you reply that you have no objection in relicensing those files
are 3-Clause BSD?

After "[Qemu-devel] [PATCH 0/7] slirp: make it a standalone project",
the vmstate subset that I adapted would also need to be relicensed.
There are more contributors here, I am not sure how it should be
handled. Any idea?

thanks

-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH] hw/sparc64: Explicitly set default_display = "std"

[Philippe Mathieu-Daudé]

On 2/13/19 8:07 AM, Thomas Huth wrote:
> The sun4uv_init() function expects vga_interface_type to be either
> VGA_STD or VGA_NONE and sets up a stdvga device or no vga card
> accordingly.
> However, the code in vl.c prefers the Cirrus VGA card to stdvga if
> it is available and the user and the machine did not specify anything
> else.
> So far this has not been a problem, since the Cirrus VGA was not linked
> into the sparc64 target. But with the upcoming Kconfig build system,
> all theoretically possible PCI cards will be enabled by default, so the
> Cirrus VGA card might become available on the sparc64 target, too. vl.c
> then picks the wrong card, causing sun4uv_init() to abort.
> Thus let's make it explicit that we always want stdvga for sparc64 and
> so set default_display = "std" for these machines.
> 
> Signed-off-by: Thomas Huth 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/sparc64/sun4u.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
> index ff24d9b..399f2d7 100644
> --- a/hw/sparc64/sun4u.c
> +++ b/hw/sparc64/sun4u.c
> @@ -797,6 +797,7 @@ static void sun4u_class_init(ObjectClass *oc, void *data)
>  mc->default_boot_order = "c";
>  mc->default_cpu_type = SPARC_CPU_TYPE_NAME("TI-UltraSparc-IIi");
>  mc->ignore_boot_device_suffixes = true;
> +mc->default_display = "std";
>  fwc->get_dev_path = sun4u_fw_dev_path;
>  }
>  
> @@ -820,6 +821,7 @@ static void sun4v_class_init(ObjectClass *oc, void *data)
>  mc->max_cpus = 1; /* XXX for now */
>  mc->default_boot_order = "c";
>  mc->default_cpu_type = SPARC_CPU_TYPE_NAME("Sun-UltraSparc-T1");
> +mc->default_display = "std";
>  }
>  
>  static const TypeInfo sun4v_type = {
> 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/13] spapr/xics: ignore the lower 4K in the IRQ number space

[Greg Kurz]

On Wed, 13 Feb 2019 09:03:33 +0100
Cédric Le Goater  wrote:

> On 2/13/19 2:33 AM, David Gibson wrote:
> > On Tue, Feb 12, 2019 at 08:05:53AM +0100, Cédric Le Goater wrote:  
> >> On 2/12/19 2:06 AM, David Gibson wrote:  
> >>> On Mon, Jan 07, 2019 at 07:39:45PM +0100, Cédric Le Goater wrote:  
>  The IRQ number space of the XIVE and XICS interrupt mode are aligned
>  when using the dual interrupt mode for the machine. This means that
>  the ICS offset is set to zero in QEMU and that the KVM XICS device
>  should be informed of this new value. Unfortunately, there is now way
>  to do so and KVM still maintains the XICS_IRQ_BASE (0x1000) offset.
> 
>  Ignore the lower 4K which are not used under the XICS interrupt
>  mode. These IRQ numbers are only claimed by XIVE for the CPU IPIs.
> 
>  Signed-off-by: Cédric Le Goater 
>  ---
>   hw/intc/xics_kvm.c | 18 ++
>   1 file changed, 18 insertions(+)
> 
>  diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
>  index 651bbfdf6966..1d21ff217b82 100644
>  --- a/hw/intc/xics_kvm.c
>  +++ b/hw/intc/xics_kvm.c
>  @@ -238,6 +238,15 @@ static void ics_get_kvm_state(ICSState *ics)
>   for (i = 0; i < ics->nr_irqs; i++) {
>   ICSIRQState *irq = &ics->irqs[i];
>   
>  +/*
>  + * The KVM XICS device considers that the IRQ numbers should
>  + * start at XICS_IRQ_BASE (0x1000). Ignore the lower 4K
>  + * numbers (only claimed by XIVE for the CPU IPIs).
>  + */
>  +if (i + ics->offset < XICS_IRQ_BASE) {
>  +continue;
>  +}
>  +  
> >>>
> >>> This seems bogus to me.  The guest-visible irq numbers need to line up
> >>> between xics and xive mode, yes, but that doesn't mean we need to keep
> >>> around a great big array of unused array of ICS irq states, even in
> >>> TCG mode.  
> >>
> >> This is because the qirqs[] array is under the machine and shared between 
> >> both interrupt modes, xics and xive.  
> > 
> > I don't see how that follows.  ICSIRQState is indexed in terms of the
> > ICS source number, not the global irq number, so I don't see why it
> > has to match up with the qirq array.  
> 
> The root cause is the use of spapr->irq->nr_irqs to initialize the ICS 
> and sPAPRXive object. In case of the 'dual' backend, it covers the full 
> XIVE IRQ number space (0x2000 today) but XICS only needs 0x1000.
> 
> I think we can fix the offset issue by using the appropriate nr_irqs 
> which should be for the XICS backend : spapr->irq->nr_irqs - ics->offset
> 

Since the root cause is that the value of spapr->irq->nr_irqs should
be different in XIVE and XICS, what about fixing it during reset ?

Something like:

static void spapr_irq_reset_dual(sPAPRMachineState *spapr, Error **errp)
{
[...]

spapr->irq->nr_irqs = spapr_irq_current(spapr)->nr_irqs;

spapr_irq_current(spapr)->reset(spapr, errp);
}

> 
> I keep in mind the XIVE support for nested guests and I think we will
> need to extend the IRQ number space in L1 and have the L2 use a portion
> of it (using an offset). 
> 
> C.
>  
> >>>  
>   kvm_device_access(kernel_xics_fd, KVM_DEV_XICS_GRP_SOURCES,
> i + ics->offset, &state, false, &error_fatal);
>   
>  @@ -303,6 +312,15 @@ static int ics_set_kvm_state(ICSState *ics, int 
>  version_id)
>   ICSIRQState *irq = &ics->irqs[i];
>   int ret;
>   
>  +/*
>  + * The KVM XICS device considers that the IRQ numbers should
>  + * start at XICS_IRQ_BASE (0x1000). Ignore the lower 4K
>  + * numbers (only claimed by XIVE for the CPU IPIs).
>  + */
>  +if (i + ics->offset < XICS_IRQ_BASE) {
>  +continue;
>  +}
>  +
>   state = irq->server;
>   state |= (uint64_t)(irq->saved_priority & 
>  KVM_XICS_PRIORITY_MASK)
>   << KVM_XICS_PRIORITY_SHIFT;  
> >>>  
> >>  
> >   
> 
> 

Re: [Qemu-devel] Clearing slirp/ license

[Thomas Huth]

On 2019-02-13 12:03, Marc-André Lureau wrote:
> Hi,
> 
> As we are trying to move slirp/ in a standalone project, which
> eventually could be installed as a shared library, we need to clear
> the license.
> 
> slirp is supposed to be 3-Clause BSD license (according to
> https://git.qemu.org/?p=qemu.git;a=commit;h=2f5f89963186d42a7ded253bc6cf5b32abb45cec)
> but it seems to be effectively a 2-Clause BSD (the third clause is not
> in COPYRIGHT)
> 
> However, there are two units that are GPL-2:
> 
> - dhcpv6.c, dhcpv6.h:
>   The code was contributed by Thomas Huth 
> 
> $ git shortlog -nes slirp/dhcpv6.{c,h}
>  6  Marc-André Lureau 
>  1  Philippe Mathieu-Daudé 
>  1  Thomas Huth 
>  1  Yuval Shaia 
> 
> - ncsi.c, ncsi-pkt.h:
>   The code was contributed by Cédric Le Goater 
> 
> $ git shortlog -nes slirp/ncsi.c slirp/ncsi-pkt.h
>  5  Marc-André Lureau 
>  4  Cédric Le Goater 
> 
> Could you reply that you have no objection in relicensing those files
> are 3-Clause BSD?

Ok, for the records: I'm fine if you change the license of dhcpv6.[ch]
to either 3-Clause BSD or 2-Clause BSD.

 Thomas



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[BALATON Zoltan]

Hello,

On Wed, 13 Feb 2019, Mark Cave-Ayland wrote:

On 12/02/2019 23:59, BALATON Zoltan wrote:
This looks interesting, however I never received the original via the mailing 
list.
Did it get held somewhere because its size?


It appears in the list archives:
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg02471.html
so I think it reached the list. If it's held for you it may be your 
systems.



Also it's probably worth pushing it to a suitable git repo since then it's 
easier for
people to pull and update as required.


Yes, I though the qemu git repo would be suitable for that that's why I've 
submitted it. For testing it's just a single patch so git am should not be 
too difficult.


For mac99 you can try with -vga none -device ati-vga and it gives you 
console under Linux but not much more at the moment. MacOS can't find it 
presumably because the info and driver it needs is missing from the device 
tree. I think these should be set up by the card ROM but even if I add a 
Mac card ROM with -device ati-vga,romfile=rom_from_an_ati_card.bin 
OpenBIOS does not seem to be able to run FCode roms so currently could not 
test with MacOS.


Regards,
BALATON Zoltan

[Qemu-devel] [PATCH v2] Add a gitlab-ci file for Continuous Integration testing on Gitlab

[Thomas Huth]

This is very convenient for people like me who store their QEMU git trees
on gitlab.com: Automatic CI pipelines are now run for each branch that is
pushed to the server - useful for some extra-testing before sending PULL-
requests for example. Since the runtime of the jobs is limited to 1h, the
jobs are distributed into multiple pipelines - this way everything finishs
fine within time (ca. 30 minutes currently).

Signed-off-by: Thomas Huth 
---
 An example can be seen here: https://gitlab.com/huth/qemu/pipelines/

 I'd really like to get this into the main QEMU repository, so that I don't
 have to cherry-pick this patch onto my testing branches anymore each time
 I want to test before sending a PULL request...

 .gitlab-ci.yml | 73 ++
 MAINTAINERS|  5 
 2 files changed, 78 insertions(+)
 create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000..79d02cf
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,73 @@
+before_script:
+ - apt-get update -qq
+ - apt-get install -y -qq flex bison libglib2.0-dev libpixman-1-dev genisoimage
+
+build-system1:
+ script:
+ - apt-get install -y -qq libgtk-3-dev libvte-dev nettle-dev libcacard-dev
+  libusb-dev libvde-dev libspice-protocol-dev libgl1-mesa-dev
+ - ./configure --enable-werror --target-list="aarch64-softmmu alpha-softmmu
+  cris-softmmu hppa-softmmu lm32-softmmu moxie-softmmu microblazeel-softmmu
+  mips64el-softmmu m68k-softmmu ppc-softmmu riscv64-softmmu sparc-softmmu"
+ - make -j2
+ - make -j2 check
+
+build-system2:
+ script:
+ - apt-get install -y -qq libsdl2-dev libgcrypt-dev libbrlapi-dev libaio-dev
+  libfdt-dev liblzo2-dev librdmacm-dev libibverbs-dev libibumad-dev
+ - ./configure --enable-werror --target-list="tricore-softmmu unicore32-softmmu
+  microblaze-softmmu mips-softmmu riscv32-softmmu s390x-softmmu sh4-softmmu
+  sparc64-softmmu x86_64-softmmu xtensa-softmmu nios2-softmmu or1k-softmmu"
+ - make -j2
+ - make -j2 check
+
+build-disabled:
+ script:
+ - ./configure --enable-werror --disable-rdma --disable-slirp --disable-curl
+  --disable-capstone --disable-live-block-migration --disable-glusterfs
+  --disable-replication --disable-coroutine-pool --disable-smartcard
+  --disable-guest-agent --disable-curses --disable-libxml2 --disable-tpm
+  --disable-qom-cast-debug --disable-spice --disable-vhost-vsock
+  --disable-vhost-net --disable-vhost-crypto --disable-vhost-user
+  --target-list="i386-softmmu ppc64-softmmu mips64-softmmu i386-linux-user"
+ - make -j2
+ - make -j2 check-qtest SPEED=slow
+
+build-tcg-disabled:
+ script:
+ - apt-get install -y -qq clang libgtk-3-dev libbluetooth-dev libusb-dev
+ - ./configure --cc=clang --enable-werror --disable-tcg --audio-drv-list=""
+ - make -j2
+ - make check-unit
+ - make check-qapi-schema
+ - cd tests/qemu-iotests/
+ - ./check -raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 048
+052 063 077 086 101 104 106 113 147 148 150 151 152 157 159 160
+163 170 171 183 184 192 194 197 205 208 215 221 222 226 227 236
+ - ./check -qcow2 001 002 003 004 005 007 008 009 010 011 012 013 017 018 019
+020 021 022 024 025 027 028 029 031 032 033 034 035 036 037 038
+039 040 042 043 046 047 048 049 050 051 052 053 054 056 057 058
+060 061 062 063 065 066 067 068 069 071 072 073 074 079 080 082
+085 086 089 090 091 095 096 097 098 099 102 103 104 105 107 108
+110 111 114 117 120 122 124 126 127 129 130 132 133 134 137 138
+139 140 141 142 143 144 145 147 150 151 152 154 155 156 157 158
+161 165 170 172 174 176 177 179 184 186 187 190 192 194 195 196
+197 200 202 203 205 208 209 214 215 216 217 218 222 226 227 229 234
+
+build-user:
+ script:
+ - ./configure --enable-werror --disable-system --disable-guest-agent
+   --disable-capstone --disable-slirp --disable-fdt
+ - make -j2
+ - make run-tcg-tests-i386-linux-user run-tcg-tests-x86_64-linux-user
+
+build-clang:
+ script:
+ - apt-get install -y -qq clang libsdl2-dev
+  xfslibs-dev libiscsi-dev libnfs-dev libseccomp-dev gnutls-dev librbd-dev
+ - ./configure --cc=clang --cxx=clang++ --enable-werror
+  --target-list="alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu
+ ppc-softmmu s390x-softmmu x86_64-softmmu arm-linux-user"
+ - make -j2
+ - make -j2 check
diff --git a/MAINTAINERS b/MAINTAINERS
index a2da141..191138c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2484,6 +2484,11 @@ S: Maintained
 F: .cirrus.yml
 W: https://cirrus-ci.com/github/qemu/qemu
 
+GitLab Continuous Integration
+M: Thomas Huth 
+S: Maintained
+F: .gitlab-ci.yml
+
 Guest Test Compilation Support
 M: Alex Bennée 
 R: Philippe Mathieu-Daudé 
-- 
1.8.3.1

[Qemu-devel] [Bug 1813940] Re: kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device

[Dr. David Alan Gilbert]

That also fixes the case I'd hit

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

Title:
  kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device

Status in QEMU:
  Confirmed

Bug description:
  Latest QEMU master fails to run with too many MMIO devices specified.

  After patch 3ac7d43a6fb [1] QEMU just prints an error message and exits.
  > kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device

  This is reproducible e.g. with the following setup:

  qemu-3.1.50-dirty \
  -machine pc-i440fx-2.7,accel=kvm \
  -cpu host -m 4096 \
  -smp 2,sockets=2,cores=1,threads=1 \
  -drive file=freebsd_vm_1.qcow2,format=qcow2,if=none,id=bootdr \
  -device ide-hd,drive=bootdr,bootindex=0 \
  -device virtio-scsi-pci,id=vc0 \
  -device virtio-scsi-pci,id=vc1 \
  -device virtio-scsi-pci,id=vc2 \
  -device virtio-scsi-pci,id=vc3 \

  Running with just 3 Virtio-SCSI controllers seems to work fine, adding
  more than that causes the error above. Note that this is not Virtio-
  SCSI specific. I've also reproduced this without any Virtio devices
  whatsoever.

  strace shows the following ioctl chain over and over:

  145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0
  145787 ioctl(11, KVM_UNREGISTER_COALESCED_MMIO, 0x7f60a4985410) = 0
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = 0
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)
  145787 ioctl(11, KVM_REGISTER_COALESCED_MMIO, 0x7f60a49853b0) = -1 ENOSPC (No 
space left on device)

  Which suggests there's some kind of MMIO region leak.

  [1]
  commit 3ac7d43a6fbb5d4a3d01fc9a055c218030af3727
  Author: Paolo Bonzini 
  AuthorDate: Wed Nov 28 17:28:45 2018 +0100
  Commit: Paolo Bonzini 
  CommitDate: Fri Jan 11 13:57:24 2019 +0100

  memory: update coalesced_range on transaction_commit

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

Re: [Qemu-devel] [Qemu-block] [PATCH v3] drive-mirror: add incremental mode

[滴滴云]

On 2019/2/5 8:02 AM，“John Snow” wrote:

 >  On 1/31/19 7:17 AM, mahaocong wrote:
 >  > From: mahaocong 
 >  > 
 >  
 >  Please use "git send-email" where possible, it will help keep the
 >  formatting right. Use "RESEND" or "v4" when sending out a cover letter
 >  revision, so the tools can see it as a new thread properly.

 I understand.

 >  Sorry for the hassle!
 >  
 >  > This patch adds possibility to start mirroring with user-created-bitmap.
 >  > On full mode, mirror create a non-named-bitmap by scanning whole 
 > block-chain,
 >  > and on top mode, mirror create a bitmap by scanning the top block layer. 
 > So I
 >  > think I can copy a user-created-bitmap and use it as the initial state of 
 > the
 >  > mirror, the same as incremental mode drive-backup, and I call this new 
 > mode
 >  > as incremental mode drive-mirror.
 >  > 
 >  
 >  It makes sense by extension, yes.
 >  
 >  > A possible usage scene of incremental mode mirror is live migration. For 
 > maintain
 >  > the block data and recover after a malfunction, someone may backup data 
 > to ceph
 >  > or other distributed storage. On qemu incremental backup, we need to 
 > create a new
 >  > bitmap and attach to block device before the first backup job. Then the 
 > bitmap
 >  > records the change after the backup job. If we want to migration this vm, 
 > we can
 >  > migrate block data between source and destionation by using drive-mirror 
 > directly,
 >  > or use backup data and backup-bitmap to reduce the data should be 
 > synchronize.
 >  > To do this, we should first create a new image in destination and set 
 > backing file
 >  > as backup image, then set backup-bitmap as the initial state of 
 > incremental mode
 >  > drive-mirror, and synchronize dirty block starting with the state set by 
 > the last
 >  > incremental backup job. When the mirror complete, we get an active layer 
 > on destination,
 >  > and its backing file is backup image on ceph. Then we can do live copy 
 > data from
 >  > backing files into overlay images by using block-stream, or do backup 
 > continually.
 >  > 
 >  > In this scene, It seems that If the guest os doesn't write too many data 
 > after the
 >  > last backup, the incremental mode may transmit less data than full mode 
 > or top
 >  > mode. However, if the write data is too many, there is no advantage on 
 > incremental
 >  > mode compare with other mode.
 >  > 
 >  
 >  It does seem very situational. I suppose there's no real harm in
 >  allowing people to try it, though.
 >  
 >  > This scene can be described as following steps:
 >  > 1.create rbd image in ceph, and map nbd device with rbd image.
 >  > 2.create a new bitmap and attach to block device.
 >  > 3.do full mode backup on nbd device and thus sync it to the rbd image.
 >  > 4.severl times incremental mode backup.
 >  > 5.create new image in destination and set its backing file as backup 
 > image.
 >  > 6.do live-migration, and migrate block data by incremental mode 
 > drive-mirror
 >  >   with bitmap created from step 2.
 >  > 
 >  > Signed-off-by: Ma Haocong 
 >  > ---
 >  >  compare with old version, there are following changes:
 >  >  1.replace the copy bitmap function by bdrv_merge_dirty_bitmap
 >  >  2.remove checking for cancelled after mirror_dirty_init_incremental for 
 > bitmap
 >  >copyimg don't have yield point.
 >  >  3.adjuest input parameters on mirror_start_job and mirror_start, and so 
 > It is
 >  >no need to find bitmap on mirror_dirty_init_incremental again.
 >  >  4.assert the bitmap name is NULL on blockdev_mirror_common.
 >  >  5.change the parameter's name in qmp command 'drive-mirror' from 
 > 'bitmap_name'
 >  >to 'bitmap'.
 >  >  6.change the discribe of parameter 'bitmap' in block-core.json.
 >  > 
 >  >  block/mirror.c| 46 
 > ++
 >  >  blockdev.c| 41 -
 >  >  include/block/block_int.h |  3 ++-
 >  >  qapi/block-core.json  |  7 ++-
 >  >  4 files changed, 78 insertions(+), 19 deletions(-)
 >  > 
 >  > diff --git a/block/mirror.c b/block/mirror.c
 >  > index ab59ad77e8..c59aefe9f0 100644
 >  > --- a/block/mirror.c
 >  > +++ b/block/mirror.c
 >  > @@ -50,6 +50,7 @@ typedef struct MirrorBlockJob {
 >  >  /* Used to block operations on the drive-mirror-replace target */
 >  >  Error *replace_blocker;
 >  >  bool is_none_mode;
 >  > +BdrvDirtyBitmap *src_bitmap;
 >  >  BlockMirrorBackingMode backing_mode;
 >  >  MirrorCopyMode copy_mode;
 >  >  BlockdevOnError on_source_error, on_target_error;
 >  > @@ -814,6 +815,15 @@ static int coroutine_fn 
 > mirror_dirty_init(MirrorBlockJob *s)
 >  >  return 0;
 >  >  }
 >  >  
 >  > +/*
 >  > + * init dirty bitmap by using user bitmap. usr->hbitmap will be copy to
 >  > + * mirror bitmap->hbitmap instead of reuse it.
 >  > + */
 >  > +static void coroutine_fn mirror_dirty_init_incremental(MirrorBlockJob 
 > 

Re: [Qemu-devel] [PATCH v2] Add a gitlab-ci file for Continuous Integration testing on Gitlab

[Marc-André Lureau]

Hi

On Wed, Feb 13, 2019 at 12:55 PM Thomas Huth  wrote:
>
> This is very convenient for people like me who store their QEMU git trees
> on gitlab.com: Automatic CI pipelines are now run for each branch that is
> pushed to the server - useful for some extra-testing before sending PULL-
> requests for example. Since the runtime of the jobs is limited to 1h, the
> jobs are distributed into multiple pipelines - this way everything finishs
> fine within time (ca. 30 minutes currently).
>
> Signed-off-by: Thomas Huth 
> ---
>  An example can be seen here: https://gitlab.com/huth/qemu/pipelines/
>
>  I'd really like to get this into the main QEMU repository, so that I don't
>  have to cherry-pick this patch onto my testing branches anymore each time
>  I want to test before sending a PULL request...
>
>  .gitlab-ci.yml | 73 
> ++
>  MAINTAINERS|  5 
>  2 files changed, 78 insertions(+)
>  create mode 100644 .gitlab-ci.yml
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> new file mode 100644
> index 000..79d02cf
> --- /dev/null
> +++ b/.gitlab-ci.yml
> @@ -0,0 +1,73 @@
> +before_script:
> + - apt-get update -qq
> + - apt-get install -y -qq flex bison libglib2.0-dev libpixman-1-dev 
> genisoimage
> +
> +build-system1:
> + script:
> + - apt-get install -y -qq libgtk-3-dev libvte-dev nettle-dev libcacard-dev
> +  libusb-dev libvde-dev libspice-protocol-dev libgl1-mesa-dev
> + - ./configure --enable-werror --target-list="aarch64-softmmu alpha-softmmu
> +  cris-softmmu hppa-softmmu lm32-softmmu moxie-softmmu 
> microblazeel-softmmu
> +  mips64el-softmmu m68k-softmmu ppc-softmmu riscv64-softmmu 
> sparc-softmmu"
> + - make -j2

Have you tried $(nproc) ?

> + - make -j2 check
> +
> +build-system2:
> + script:
> + - apt-get install -y -qq libsdl2-dev libgcrypt-dev libbrlapi-dev libaio-dev
> +  libfdt-dev liblzo2-dev librdmacm-dev libibverbs-dev libibumad-dev
> + - ./configure --enable-werror --target-list="tricore-softmmu 
> unicore32-softmmu
> +  microblaze-softmmu mips-softmmu riscv32-softmmu s390x-softmmu 
> sh4-softmmu
> +  sparc64-softmmu x86_64-softmmu xtensa-softmmu nios2-softmmu 
> or1k-softmmu"
> + - make -j2
> + - make -j2 check
> +
> +build-disabled:
> + script:
> + - ./configure --enable-werror --disable-rdma --disable-slirp --disable-curl
> +  --disable-capstone --disable-live-block-migration --disable-glusterfs
> +  --disable-replication --disable-coroutine-pool --disable-smartcard
> +  --disable-guest-agent --disable-curses --disable-libxml2 --disable-tpm
> +  --disable-qom-cast-debug --disable-spice --disable-vhost-vsock
> +  --disable-vhost-net --disable-vhost-crypto --disable-vhost-user
> +  --target-list="i386-softmmu ppc64-softmmu mips64-softmmu 
> i386-linux-user"
> + - make -j2
> + - make -j2 check-qtest SPEED=slow
> +
> +build-tcg-disabled:
> + script:
> + - apt-get install -y -qq clang libgtk-3-dev libbluetooth-dev libusb-dev
> + - ./configure --cc=clang --enable-werror --disable-tcg --audio-drv-list=""
> + - make -j2
> + - make check-unit
> + - make check-qapi-schema
> + - cd tests/qemu-iotests/
> + - ./check -raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 048
> +052 063 077 086 101 104 106 113 147 148 150 151 152 157 159 160
> +163 170 171 183 184 192 194 197 205 208 215 221 222 226 227 236
> + - ./check -qcow2 001 002 003 004 005 007 008 009 010 011 012 013 017 018 019
> +020 021 022 024 025 027 028 029 031 032 033 034 035 036 037 038
> +039 040 042 043 046 047 048 049 050 051 052 053 054 056 057 058
> +060 061 062 063 065 066 067 068 069 071 072 073 074 079 080 082
> +085 086 089 090 091 095 096 097 098 099 102 103 104 105 107 108
> +110 111 114 117 120 122 124 126 127 129 130 132 133 134 137 138
> +139 140 141 142 143 144 145 147 150 151 152 154 155 156 157 158
> +161 165 170 172 174 176 177 179 184 186 187 190 192 194 195 196
> +197 200 202 203 205 208 209 214 215 216 217 218 222 226 227 229 
> 234
> +
> +build-user:
> + script:
> + - ./configure --enable-werror --disable-system --disable-guest-agent
> +   --disable-capstone --disable-slirp --disable-fdt
> + - make -j2
> + - make run-tcg-tests-i386-linux-user run-tcg-tests-x86_64-linux-user
> +
> +build-clang:
> + script:
> + - apt-get install -y -qq clang libsdl2-dev
> +  xfslibs-dev libiscsi-dev libnfs-dev libseccomp-dev gnutls-dev 
> librbd-dev
> + - ./configure --cc=clang --cxx=clang++ --enable-werror
> +  --target-list="alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu
> + ppc-softmmu s390x-softmmu x86_64-softmmu arm-linux-user"
> + - make -j2
> + - make -j2 check
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a2da141..191138c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2484,6 +2484,11 @@ S: Maintained
>  F: .cirrus.yml
>  W: https://ci

Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/13] spapr/xics: ignore the lower 4K in the IRQ number space

[Greg Kurz]

On Wed, 13 Feb 2019 12:27:13 +0100
Greg Kurz  wrote:

> On Wed, 13 Feb 2019 09:03:33 +0100
> Cédric Le Goater  wrote:
> 
> > On 2/13/19 2:33 AM, David Gibson wrote:  
> > > On Tue, Feb 12, 2019 at 08:05:53AM +0100, Cédric Le Goater wrote:
> > >> On 2/12/19 2:06 AM, David Gibson wrote:
> > >>> On Mon, Jan 07, 2019 at 07:39:45PM +0100, Cédric Le Goater wrote:
> >  The IRQ number space of the XIVE and XICS interrupt mode are aligned
> >  when using the dual interrupt mode for the machine. This means that
> >  the ICS offset is set to zero in QEMU and that the KVM XICS device
> >  should be informed of this new value. Unfortunately, there is now way
> >  to do so and KVM still maintains the XICS_IRQ_BASE (0x1000) offset.
> > 
> >  Ignore the lower 4K which are not used under the XICS interrupt
> >  mode. These IRQ numbers are only claimed by XIVE for the CPU IPIs.
> > 
> >  Signed-off-by: Cédric Le Goater 
> >  ---
> >   hw/intc/xics_kvm.c | 18 ++
> >   1 file changed, 18 insertions(+)
> > 
> >  diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
> >  index 651bbfdf6966..1d21ff217b82 100644
> >  --- a/hw/intc/xics_kvm.c
> >  +++ b/hw/intc/xics_kvm.c
> >  @@ -238,6 +238,15 @@ static void ics_get_kvm_state(ICSState *ics)
> >   for (i = 0; i < ics->nr_irqs; i++) {
> >   ICSIRQState *irq = &ics->irqs[i];
> >   
> >  +/*
> >  + * The KVM XICS device considers that the IRQ numbers should
> >  + * start at XICS_IRQ_BASE (0x1000). Ignore the lower 4K
> >  + * numbers (only claimed by XIVE for the CPU IPIs).
> >  + */
> >  +if (i + ics->offset < XICS_IRQ_BASE) {
> >  +continue;
> >  +}
> >  +
> > >>>
> > >>> This seems bogus to me.  The guest-visible irq numbers need to line up
> > >>> between xics and xive mode, yes, but that doesn't mean we need to keep
> > >>> around a great big array of unused array of ICS irq states, even in
> > >>> TCG mode.
> > >>
> > >> This is because the qirqs[] array is under the machine and shared 
> > >> between 
> > >> both interrupt modes, xics and xive.
> > > 
> > > I don't see how that follows.  ICSIRQState is indexed in terms of the
> > > ICS source number, not the global irq number, so I don't see why it
> > > has to match up with the qirq array.
> > 
> > The root cause is the use of spapr->irq->nr_irqs to initialize the ICS 
> > and sPAPRXive object. In case of the 'dual' backend, it covers the full 
> > XIVE IRQ number space (0x2000 today) but XICS only needs 0x1000.
> > 
> > I think we can fix the offset issue by using the appropriate nr_irqs 
> > which should be for the XICS backend : spapr->irq->nr_irqs - ics->offset
> >   
> 
> Since the root cause is that the value of spapr->irq->nr_irqs should
> be different in XIVE and XICS, what about fixing it during reset ?
> 

Nah this doesn't make sense :)

But if XICS always needs 0x1000, why just not change spapr_irq_init_xics()
to use SPAPR_IRQ_XICS_NR_IRQS instead of spapr->irq->nr_irqs ?

> Something like:
> 
> static void spapr_irq_reset_dual(sPAPRMachineState *spapr, Error **errp)
> {
> [...]
> 
> spapr->irq->nr_irqs = spapr_irq_current(spapr)->nr_irqs;
> 
> spapr_irq_current(spapr)->reset(spapr, errp);
> }
> 
> > 
> > I keep in mind the XIVE support for nested guests and I think we will
> > need to extend the IRQ number space in L1 and have the L2 use a portion
> > of it (using an offset). 
> > 
> > C.
> >
> > >>>
> >   kvm_device_access(kernel_xics_fd, KVM_DEV_XICS_GRP_SOURCES,
> > i + ics->offset, &state, false, 
> >  &error_fatal);
> >   
> >  @@ -303,6 +312,15 @@ static int ics_set_kvm_state(ICSState *ics, int 
> >  version_id)
> >   ICSIRQState *irq = &ics->irqs[i];
> >   int ret;
> >   
> >  +/*
> >  + * The KVM XICS device considers that the IRQ numbers should
> >  + * start at XICS_IRQ_BASE (0x1000). Ignore the lower 4K
> >  + * numbers (only claimed by XIVE for the CPU IPIs).
> >  + */
> >  +if (i + ics->offset < XICS_IRQ_BASE) {
> >  +continue;
> >  +}
> >  +
> >   state = irq->server;
> >   state |= (uint64_t)(irq->saved_priority & 
> >  KVM_XICS_PRIORITY_MASK)
> >   << KVM_XICS_PRIORITY_SHIFT;
> > >>>
> > >>
> > > 
> > 
> >   
> 
> 

Re: [Qemu-devel] [PATCH v4] virtio-blk: set correct config size for the host driver

[Stefano Garzarella]

On Wed, Feb 13, 2019 at 09:32:27AM +0100, Stefano Garzarella wrote:
> On Wed, Feb 13, 2019 at 04:01:43PM +0800, Stefan Hajnoczi wrote:
> > On Wed, Feb 13, 2019 at 09:48:57AM +0800, Changpeng Liu wrote:
> > > Commit caa1ee43 "vhost-user-blk: add discard/write zeroes features
> > > support" added fields to struct virtio_blk_config. This changes
> > > the size of the config space and breaks migration from QEMU 3.1
> > > and older:
> > > 
> > > qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x10 read: 
> > > 41 device: 1 cmask: ff wmask: 80 w1cmask:0
> > > qemu-system-ppc64: Failed to load PCIDevice:config
> > > qemu-system-ppc64: Failed to load virtio-blk:virtio
> > > qemu-system-ppc64: error while loading state for instance 0x0 of device 
> > > 'pci@8002000:01.0/virtio-blk'
> > > qemu-system-ppc64: load of migration failed: Invalid argument
> > > 
> > > Since virtio-blk doesn't support the "discard" and "write zeroes"
> > > features, it shouldn't even expose the associated fields in the
> > > config space actually. Just include all fields up to num_queues to
> > > match QEMU 3.1 and older.
> > > 
> > > Signed-off-by: Changpeng Liu 
> > > ---
> > >  hw/block/virtio-blk.c | 13 +
> > >  1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > Stefano: Please rebase your DISCARD/WRITE_ZEROES series onto this and
> > check that the config space is correctly sized.  Machine types before
> > 4.0 shouldn't have these fields so that the config space size remains
> > unchanged.
> 
> Sure!
> 
> Since I should set a correct config size checking if new features are
> enabled or not at runtime, should be better to add a variable and an array
> of sizes like in virtio-net?

In my series "[PATCH v4 0/6] virtio-blk: add DISCARD and WRITE_ZEROES"
I'm adding the host_features field in VirtIOBlock. Then, I could add
something like the following patch (proof of concept) inspired by the
virtio-net approach, that would be simplest to maintain when we will add
new features.

What do you think?

Thanks,
Stefano


diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 843bb2bec8..84dcc1406c 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -28,6 +28,51 @@
 #include "hw/virtio/virtio-bus.h"
 #include "hw/virtio/virtio-access.h"
 
+/*
+ * Calculate the number of bytes up to and including the given 'field' of
+ * 'container'.
+ */
+#define endof(container, field) \
+(offsetof(container, field) + sizeof_field(container, field))
+
+typedef struct VirtIOFeature {
+uint64_t flags;
+size_t end;
+} VirtIOFeature;
+
+static VirtIOFeature feature_sizes[] = {
+{.flags = 1ULL << VIRTIO_NET_F_SIZE_MAX,
+ .end = endof(struct virtio_blk_config, size_max)},
+{.flags = 1ULL << VIRTIO_NET_F_SEG_MAX,
+ .end = endof(struct virtio_blk_config, seg_max)},
+{.flags = 1ULL << VIRTIO_NET_F_GEOMETRY,
+ .end = endof(struct virtio_blk_config, geometry)},
+{.flags = 1ULL << VIRTIO_NET_F_BLK_SIZE,
+ .end = endof(struct virtio_blk_config, blk_size)},
+{.flags = 1ULL << VIRTIO_NET_F_TOPOLOGY,
+ .end = endof(struct virtio_blk_config, opt_io_size)},
+{.flags = 1ULL << VIRTIO_NET_F_CONFIG_WCE,
+ .end = endof(struct virtio_blk_config, wce)},
+{.flags = 1ULL << VIRTIO_NET_F_MQ,
+ .end = endof(struct virtio_blk_config, num_queues)},
+{}
+};
+
+static void virtio_blk_set_config_size(VirtIOBlock *s, uint64_t host_features)
+{
+int i, config_size;
+
+config_size = endof(struct virtio_blk_config, capacity);
+
+for (i = 0; feature_sizes[i].flags != 0; i++) {
+if (host_features & feature_sizes[i].flags) {
+config_size = MAX(feature_sizes[i].end, config_size);
+}
+}
+
+s->config_size = config_size;
+}
+
 static void virtio_blk_init_request(VirtIOBlock *s, VirtQueue *vq,
 VirtIOBlockReq *req)
 {
@@ -757,7 +802,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
uint8_t *config)
 blkcfg.alignment_offset = 0;
 blkcfg.wce = blk_enable_write_cache(s->blk);
 virtio_stw_p(vdev, &blkcfg.num_queues, s->conf.num_queues);
-memcpy(config, &blkcfg, sizeof(struct virtio_blk_config));
+memcpy(config, &blkcfg, s->config_size);
 }
 
 static void virtio_blk_set_config(VirtIODevice *vdev, const uint8_t *config)
@@ -765,7 +810,7 @@ static void virtio_blk_set_config(VirtIODevice *vdev, const 
uint8_t *config)
 VirtIOBlock *s = VIRTIO_BLK(vdev);
 struct virtio_blk_config blkcfg;
 
-memcpy(&blkcfg, config, sizeof(blkcfg));
+memcpy(&blkcfg, config, s->config_size);
 
 aio_context_acquire(blk_get_aio_context(s->blk));
 blk_set_enable_write_cache(s->blk, blkcfg.wce != 0);
@@ -948,8 +993,9 @@ static void virtio_blk_device_realize(DeviceState *dev, 
Error **errp)
 return;
 }
 
-virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
-sizeof(struct virtio_blk_config));
+virtio_blk_set_config_size(s, s->host_featur

Re: [Qemu-devel] [RFC 1/4] numa, spapr: add thread-id in the possible_cpus list

[Igor Mammedov]

On Wed, 13 Feb 2019 10:08:24 +0100
Laurent Vivier  wrote:

> On 13/02/2019 09:42, Igor Mammedov wrote:
> > On Wed, 13 Feb 2019 12:25:45 +1100
> > David Gibson  wrote:
> >   
> >> On Tue, Feb 12, 2019 at 10:48:24PM +0100, Laurent Vivier wrote:  
> >>> spapr_possible_cpu_arch_ids() counts only cores, and so
> >>> the number of available CPUs is the number of vCPU divided
> >>> by smp_threads.
> >>>
> >>> ... -smp 4,maxcpus=8,cores=2,threads=2,sockets=2 -numa node,cpus=0,cpus=1 
> >>> \
> >>>   -numa 
> >>> node,cpus=3,cpus=4 \
> >>>   -numa node -numa node
> >>>
> >>> This generates (info hotpluggable-cpus)
> >>>
> >>>node-id: 0 core-id: 0 thread-id: 0 [thread-id: 1]
> >>>node-id: 0 core-id: 6 thread-id: 0 [thread-id: 1]
> >>>node-id: 1 core-id: 2 thread-id: 0 [thread-id: 1]
> >>>node-id: 1 core-id: 4 thread-id: 0 [thread-id: 1]
> >>>
> >>> And this command line generates the following error:
> >>>
> >>>CPU(s) not present in any NUMA nodes: CPU 3 [core-id: 6]
> >>>
> >>> That is wrong because CPU 3 [core-id: 6] is assigned to node-id 0
> >>> Moreover "cpus=4" is not valid, because it means core-id 8 but
> >>> maxcpus is 8.
> >>>
> >>> With this patch we have now:
> >>>
> >>>node-id: 0 core-id: 0 thread-id: 0
> >>>node-id: 0 core-id: 0 thread-id: 1
> >>>node-id: 0 core-id: 1 thread-id: 0
> >>>node-id: 1 core-id: 1 thread-id: 1
> >>>node-id: 0 core-id: 2 thread-id: 1
> >>>node-id: 1 core-id: 2 thread-id: 0
> >>>node-id: 0 core-id: 3 thread-id: 1
> >>>node-id: 0 core-id: 3 thread-id: 0  
> >>
> >> I'm afraid this is not the right solution.  The point of the
> >> hotpluggable cpus table is that it has exactly one entry for each
> >> hotpluggable unit.  For PAPR that's a core, not a thread.
> >>
> >> So, the problem is with how the NUMA configuration code is
> >> interpreting possible-cpus, not how the machine is building the table.  
> > 
> > I'd suggest to deprecate/remove 'cpus' suboption in -numa.
> > One should use '-numa cpu' instead, which is written with
> > possible_cpus in mind.  
> 
> I agree.
> 
> Should I keep the patch to remove the incomplete CPU mapping support?
Considering code path didn't go through deprecation process (we didn't have it 
back then), lets keep it for now and deprecate option properly first.
Once deprecation period ends we well remove all related code at once.

Maybe amend affected/add error messages that it's been deprecated
and will be removed soon and point out to replacement option.



> Thanks,
> Laurent

Re: [Qemu-devel] [PATCH v4 01/15] spapr_irq: Add an @xics_offset field to sPAPRIrq

[Greg Kurz]

On Wed, 13 Feb 2019 14:26:01 +1100
David Gibson  wrote:

> On Tue, Feb 12, 2019 at 07:24:00PM +0100, Greg Kurz wrote:
> > Only pseries machines, either recent ones started with ic-mode=xics
> > or older ones using the legacy irq allocation scheme, need to set the
> > @offset of the ICS to XICS_IRQ_BASE. Recent pseries started with
> > ic-mode=dual set it to 0 and powernv machines set it to some other
> > value at runtime.
> > 
> > It thus doesn't really help to set the default value of the ICS offset
> > to XICS_IRQ_BASE in ics_base_instance_init().
> > 
> > Drop that code from XICS and let the pseries code set the offset
> > explicitely for clarity.
> > 
> > Signed-off-by: Greg Kurz   
> 
> So this actually relates to a discussion I've had on some of Cédric's
> more recent patches.  Changing the ics offset in ic-mode=dual doesn't
> make sense to me.  The global (guest) interrupt numbers need to match
> between XICS and XIVE, but the global interrupt numbers don't have to
> match the ICS source numbers, which is what ics->offset is about.
> 

Yeah. We'll see what comes out of the discussion at:

https://patchwork.ozlabs.org/patch/1021496/

> > ---
> >  hw/intc/xics.c |8 
> >  hw/ppc/spapr_irq.c |   33 -
> >  include/hw/ppc/spapr_irq.h |1 +
> >  3 files changed, 21 insertions(+), 21 deletions(-)
> > 
> > diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> > index 16e8ffa2aaf7..7cac138067e2 100644
> > --- a/hw/intc/xics.c
> > +++ b/hw/intc/xics.c
> > @@ -638,13 +638,6 @@ static void ics_base_realize(DeviceState *dev, Error 
> > **errp)
> >  ics->irqs = g_malloc0(ics->nr_irqs * sizeof(ICSIRQState));
> >  }
> >  
> > -static void ics_base_instance_init(Object *obj)
> > -{
> > -ICSState *ics = ICS_BASE(obj);
> > -
> > -ics->offset = XICS_IRQ_BASE;
> > -}
> > -
> >  static int ics_base_dispatch_pre_save(void *opaque)
> >  {
> >  ICSState *ics = opaque;
> > @@ -720,7 +713,6 @@ static const TypeInfo ics_base_info = {
> >  .parent = TYPE_DEVICE,
> >  .abstract = true,
> >  .instance_size = sizeof(ICSState),
> > -.instance_init = ics_base_instance_init,
> >  .class_init = ics_base_class_init,
> >  .class_size = sizeof(ICSStateClass),
> >  };
> > diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> > index 80b0083b8e38..8217e0215411 100644
> > --- a/hw/ppc/spapr_irq.c
> > +++ b/hw/ppc/spapr_irq.c
> > @@ -68,10 +68,11 @@ void spapr_irq_msi_reset(sPAPRMachineState *spapr)
> >  
> >  static ICSState *spapr_ics_create(sPAPRMachineState *spapr,
> >const char *type_ics,
> > -  int nr_irqs, Error **errp)
> > +  int nr_irqs, int offset, Error **errp)
> >  {
> >  Error *local_err = NULL;
> >  Object *obj;
> > +ICSState *ics;
> >  
> >  obj = object_new(type_ics);
> >  object_property_add_child(OBJECT(spapr), "ics", obj, &error_abort);
> > @@ -86,7 +87,10 @@ static ICSState *spapr_ics_create(sPAPRMachineState 
> > *spapr,
> >  goto error;
> >  }
> >  
> > -return ICS_BASE(obj);
> > +ics = ICS_BASE(obj);
> > +ics->offset = offset;
> > +
> > +return ics;
> >  
> >  error:
> >  error_propagate(errp, local_err);
> > @@ -104,6 +108,7 @@ static void spapr_irq_init_xics(sPAPRMachineState 
> > *spapr, Error **errp)
> >  !xics_kvm_init(spapr, &local_err)) {
> >  spapr->icp_type = TYPE_KVM_ICP;
> >  spapr->ics = spapr_ics_create(spapr, TYPE_ICS_KVM, nr_irqs,
> > +  spapr->irq->xics_offset,
> >&local_err);
> >  }
> >  if (machine_kernel_irqchip_required(machine) && !spapr->ics) {
> > @@ -119,6 +124,7 @@ static void spapr_irq_init_xics(sPAPRMachineState 
> > *spapr, Error **errp)
> >  xics_spapr_init(spapr);
> >  spapr->icp_type = TYPE_ICP;
> >  spapr->ics = spapr_ics_create(spapr, TYPE_ICS_SIMPLE, nr_irqs,
> > +  spapr->irq->xics_offset,
> >&local_err);
> >  }
> >  
> > @@ -246,6 +252,7 @@ sPAPRIrq spapr_irq_xics = {
> >  .nr_irqs = SPAPR_IRQ_XICS_NR_IRQS,
> >  .nr_msis = SPAPR_IRQ_XICS_NR_MSIS,
> >  .ov5 = SPAPR_OV5_XIVE_LEGACY,
> > +.xics_offset = XICS_IRQ_BASE,
> >  
> >  .init= spapr_irq_init_xics,
> >  .claim   = spapr_irq_claim_xics,
> > @@ -451,17 +458,6 @@ static void spapr_irq_init_dual(sPAPRMachineState 
> > *spapr, Error **errp)
> >  return;
> >  }
> >  
> > -/*
> > - * Align the XICS and the XIVE IRQ number space under QEMU.
> > - *
> > - * However, the XICS KVM device still considers that the IRQ
> > - * numbers should start at XICS_IRQ_BASE (0x1000). Either we
> > - * should introduce a KVM device ioctl to set the offset or ignore
> > - * the

Re: [Qemu-devel] [PATCH v2] Add a gitlab-ci file for Continuous Integration testing on Gitlab

[Thomas Huth]

On 2019-02-13 13:06, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Feb 13, 2019 at 12:55 PM Thomas Huth  wrote:
>>
>> This is very convenient for people like me who store their QEMU git trees
>> on gitlab.com: Automatic CI pipelines are now run for each branch that is
>> pushed to the server - useful for some extra-testing before sending PULL-
>> requests for example. Since the runtime of the jobs is limited to 1h, the
>> jobs are distributed into multiple pipelines - this way everything finishs
>> fine within time (ca. 30 minutes currently).
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  An example can be seen here: https://gitlab.com/huth/qemu/pipelines/
>>
>>  I'd really like to get this into the main QEMU repository, so that I don't
>>  have to cherry-pick this patch onto my testing branches anymore each time
>>  I want to test before sending a PULL request...
>>
>>  .gitlab-ci.yml | 73 
>> ++
>>  MAINTAINERS|  5 
>>  2 files changed, 78 insertions(+)
>>  create mode 100644 .gitlab-ci.yml
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> new file mode 100644
>> index 000..79d02cf
>> --- /dev/null
>> +++ b/.gitlab-ci.yml
>> @@ -0,0 +1,73 @@
>> +before_script:
>> + - apt-get update -qq
>> + - apt-get install -y -qq flex bison libglib2.0-dev libpixman-1-dev 
>> genisoimage
>> +
>> +build-system1:
>> + script:
>> + - apt-get install -y -qq libgtk-3-dev libvte-dev nettle-dev libcacard-dev
>> +  libusb-dev libvde-dev libspice-protocol-dev libgl1-mesa-dev
>> + - ./configure --enable-werror --target-list="aarch64-softmmu alpha-softmmu
>> +  cris-softmmu hppa-softmmu lm32-softmmu moxie-softmmu 
>> microblazeel-softmmu
>> +  mips64el-softmmu m68k-softmmu ppc-softmmu riscv64-softmmu 
>> sparc-softmmu"
>> + - make -j2
> 
> Have you tried $(nproc) ?

The containers are only single CPU there. I'm using -j2 just in case one
of the processes is blocked by waiting for IO, the other one can still
continue compiling.

> Despite the duplication of CI files, which is not really a problem imho,
> 
> lgtm,
> Reviewed-by: Marc-André Lureau 

Thanks!

And yes, I also think the duplication of the CI files should not really
be a problem - it's rather a plus since we also got test variations this
way. I already found some bugs with this here that were not detected by
the other CI setups yet (e.g. since one of the pipelines uses
--disable-replication and other --disable-xxx flags).

 Thomas

[Qemu-devel] [PATCH v2] chardev/wctablet: Fix a typo

[Philippe Mathieu-Daudé]

The correct name is Wacom.
Fix the typo which is present since 378af96155d.

Reviewed-by: Marc-André Lureau 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Use correct English in description
---
 chardev/wctablet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/chardev/wctablet.c b/chardev/wctablet.c
index 969d014574..35dbd29a33 100644
--- a/chardev/wctablet.c
+++ b/chardev/wctablet.c
@@ -177,7 +177,7 @@ static void wctablet_input_sync(DeviceState *dev)
 }
 
 static QemuInputHandler wctablet_handler = {
-.name  = "QEMU Wacome Pen Tablet",
+.name  = "QEMU Wacom Pen Tablet",
 .mask  = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_ABS,
 .event = wctablet_input_event,
 .sync  = wctablet_input_sync,
-- 
2.20.1

[Qemu-devel] [PATCH] hostmem: simplify ifdef-s in file_backend_memory_alloc()

[Igor Mammedov]

cleanup file_backend_memory_alloc() by using one CONFIG_POSIX ifdef
instead of several ones within the function to make it simpler to follow.

Signed-off-by: Igor Mammedov 
Suggested-by: Wei Yang 
---
Cc: Haozhong Zhang 
Cc: Zhang Yi 
Cc: Eduardo Habkost 
Cc: Stefan Hajnoczi 
CC: Wei Yang 
---
 backends/hostmem-file.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index ba601ce940..ce54788048 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -41,10 +41,12 @@ struct HostMemoryBackendFile {
 static void
 file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
 {
+#ifndef CONFIG_POSIX
+error_setg(errp, "backend '%s' not supported on this host",
+   object_get_typename(OBJECT(backend)));
+#else
 HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(backend);
-#ifdef CONFIG_POSIX
 gchar *name;
-#endif
 
 if (!backend->size) {
 error_setg(errp, "can't create backend with size 0");
@@ -54,9 +56,6 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
**errp)
 error_setg(errp, "mem-path property not set");
 return;
 }
-#ifndef CONFIG_POSIX
-error_setg(errp, "-mem-path not supported on this host");
-#else
 backend->force_prealloc = mem_prealloc;
 name = host_memory_backend_get_name(backend);
 memory_region_init_ram_from_file(&backend->mr, OBJECT(backend),
-- 
2.18.1

Re: [Qemu-devel] [PATCH v2] hostmem-file: reject invalid pmem file sizes

[Igor Mammedov]

On Wed, 13 Feb 2019 16:53:54 +0800
Wei Yang  wrote:

> On Wed, Feb 13, 2019 at 03:14:01PM +0800, Stefan Hajnoczi wrote:
> >Guests started with NVDIMMs larger than the underlying host file produce
> >confusing errors inside the guest.  This happens because the guest
> >accesses pages beyond the end of the file.
> >
> >Check the pmem file size on startup and print a clear error message if
> >the size is invalid.
> >
> >Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1669053
> >Cc: Haozhong Zhang 
> >Cc: Zhang Yi 
> >Cc: Eduardo Habkost 
> >Cc: Igor Mammedov 
> >Signed-off-by: Stefan Hajnoczi 
> >---
> >v2:
> > * Propagate qemu_get_pmem_size() errors [Igor]
> >
> > include/qemu/osdep.h| 13 ++
> > backends/hostmem-file.c | 22 +
> > util/oslib-posix.c  | 53 +
> > util/oslib-win32.c  |  5 
> > 4 files changed, 93 insertions(+)
> >
> >diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> >index 840af09cb0..303d315c5d 100644
> >--- a/include/qemu/osdep.h
> >+++ b/include/qemu/osdep.h
> >@@ -570,6 +570,19 @@ void qemu_set_tty_echo(int fd, bool echo);
> > void os_mem_prealloc(int fd, char *area, size_t sz, int smp_cpus,
> >  Error **errp);
> > 
> >+/**
> >+ * qemu_get_pmem_size:
> >+ * @filename: path to a pmem file
> >+ * @errp: pointer to a NULL-initialized error object
> >+ *
> >+ * Determine the size of a persistent memory file.  Besides supporting 
> >files on
> >+ * DAX file systems, this function also supports Linux devdax character
> >+ * devices.
> >+ *
> >+ * Returns: the size or 0 on failure
> >+ */
> >+uint64_t qemu_get_pmem_size(const char *filename, Error **errp);
> >+
> > /**
> >  * qemu_get_pid_name:
> >  * @pid: pid of a process
> >diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
> >index ba601ce940..d62689179b 100644
> >--- a/backends/hostmem-file.c
> >+++ b/backends/hostmem-file.c
> >@@ -46,6 +46,28 @@ file_backend_memory_alloc(HostMemoryBackend *backend, 
> >Error **errp)
> > gchar *name;
> > #endif
> > 
> >+/*
> >+ * Verify pmem file size since starting a guest with an incorrect size
> >+ * leads to confusing failures inside the guest.
> >+ */
> >+if (fb->is_pmem && fb->mem_path) {
> >+Error *local_err = NULL;
> >+uint64_t size;
> >+
> >+size = qemu_get_pmem_size(fb->mem_path, &local_err);
> >+if (!size) {
> >+error_propagate(errp, local_err);
> >+return;
> >+}
> >+
> >+if (backend->size > size) {
> >+error_setg(errp, "size property %" PRIu64 " is larger than "
> >+   "pmem file \"%s\" size %" PRIu64, backend->size,
> >+   fb->mem_path, size);
> >+return;
> >+}
> >+}
> >+  
> 
> -mem-path is only supported on POSIX host.
> 
> So how about put this in the last code block before doing the real memory
> region init?
Indeed, evaluating file would be better done only if we didn't fail 
size/mempath checks first.

 
> BTW, I suggest to cleanup file_backend_memory_alloc() to make POSIX/non-POSIX
> situation clear to understand.
that's a separate patch, I'll reply with it here so Sefan could pick it (due to 
conflicts the change would create)

> 
> > if (!backend->size) {
> > error_setg(errp, "can't create backend with size 0");
> > return;
> >diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> >index 37c5854b9c..10d90d1783 100644
> >--- a/util/oslib-posix.c
> >+++ b/util/oslib-posix.c
> >@@ -500,6 +500,59 @@ void os_mem_prealloc(int fd, char *area, size_t memory, 
> >int smp_cpus,
> > }
> > }
> > 
> >+uint64_t qemu_get_pmem_size(const char *filename, Error **errp)
> >+{
> >+struct stat st;
> >+
> >+if (stat(filename, &st) < 0) {
> >+error_setg(errp, "unable to stat pmem file \"%s\"", filename);
> >+return 0;
> >+}
> >+
> >+#if defined(__linux__)
> >+/* Special handling for devdax character devices */
> >+if (S_ISCHR(st.st_mode)) {
> >+char *subsystem_path = NULL;
> >+char *subsystem = NULL;
> >+char *size_path = NULL;
> >+char *size_str = NULL;
> >+uint64_t ret = 0;
> >+
> >+subsystem_path = g_strdup_printf("/sys/dev/char/%d:%d/subsystem",
> >+ major(st.st_rdev), 
> >minor(st.st_rdev));
> >+subsystem = g_file_read_link(subsystem_path, NULL);
> >+if (!subsystem) {
> >+error_setg(errp, "unable to read subsystem for pmem file 
> >\"%s\"",
> >+   filename);
> >+goto devdax_err;
> >+}
> >+
> >+if (!g_str_has_suffix(subsystem, "/dax")) {
> >+error_setg(errp, "pmem file \"%s\" is not a dax device", 
> >filename);
> >+goto devdax_err;
> >+}
> >+
> >+size_path = g_strdup_printf("/sys/dev/char/%d:%d/size",
> >+major(st.st_rdev

Re: [Qemu-devel] [PATCH v2 7/9] hw/pvrdma: Delete unneeded function argument

[Philippe Mathieu-Daudé]

On 2/13/19 7:53 AM, Yuval Shaia wrote:
> The function argument rdma_dev_res is not needed as it is stored in the
> backend_dev object at init.
> 
> Signed-off-by: Yuval Shaia 
> Reviewed-by: Marcel Apfelbaum

Should we teach checkpatch.pl to check name/space/email?

Re: [Qemu-devel] [PATCH] hostmem: fix crash when querying empty host-nodes property via QMP

[Igor Mammedov]

On Tue,  5 Feb 2019 15:31:27 +0100
Igor Mammedov  wrote:

> QEMU will crashes with
>  qapi/qobject-output-visitor.c:210: qobject_output_complete: Assertion 
> `qov->root && ((&qov->stack)->slh_first == ((void *)0))' failed
> when trying to get value of empty hostmem.host-nodes property.
> 
> Fix it by calling visitor even if host-nodes wasn't set
> before exiting from property getter to return empty list.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  backends/hostmem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 0c8ef17..fe14be5 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -86,7 +86,7 @@ host_memory_backend_get_host_nodes(Object *obj, Visitor *v, 
> const char *name,
>  
>  value = find_first_bit(backend->host_nodes, MAX_NODES);
>  if (value == MAX_NODES) {
> -return;
> +goto ret;
>  }
>  
>  *node = g_malloc0(sizeof(**node));
> @@ -104,6 +104,7 @@ host_memory_backend_get_host_nodes(Object *obj, Visitor 
> *v, const char *name,
>  node = &(*node)->next;
>  } while (true);
>  
> +ret:
>  visit_type_uint16List(v, name, &host_nodes, errp);
>  }
>  

Markus/Michael,

does this patch make sense from QAPI point of view?

Re: [Qemu-devel] [PATCH v4 03/15] spapr_irq: Set LSIs at interrupt controller init

[Greg Kurz]

On Wed, 13 Feb 2019 14:48:44 +1100
David Gibson  wrote:

> On Tue, Feb 12, 2019 at 07:24:13PM +0100, Greg Kurz wrote:
> > The pseries machine only uses LSIs to support legacy PCI devices. Every
> > PHB claims 4 LSIs at realize time. When using in-kernel XICS (or upcoming
> > in-kernel XIVE), QEMU synchronizes the state of all irqs, including these
> > LSIs, later on at machine reset.
> > 
> > In order to support PHB hotplug, we need a way to tell KVM about the LSIs
> > that doesn't require a machine reset.
> > 
> > Since recent machine types allocate all these LSIs in a fixed range for
> > the machine lifetime, identify them when initializing the interrupt
> > controller, long before they get passed to KVM.
> > 
> > In order to do that, first disintricate interrupt typing and allocation.
> > Since the vast majority of interrupts are MSIs, make that the default
> > and have only the LSI users to explicitely set the type.
> > 
> > It is rather straight forward for XIVE. XICS needs some extra care
> > though: allocation state and type are mixed up in the same bits of the
> > flags field within the interrupt state. Setting the LSI bit there at
> > init time would mean the interrupt is de facto allocated, even if no
> > device asked for it. Introduce a bitmap to track LSIs at the ICS level.
> > In order to keep the patch minimal, the bitmap is only used when writing
> > the source state to KVM and when the interrupt is claimed, so that the
> > code that checks the interrupt type through the flags stays untouched.
> > 
> > With older pseries machine using the XICS legacy IRQ allocation scheme,
> > all interrupt numbers come from a common pool and there's no such thing
> > as a fixed range for LSIs. Introduce an helper so that these older
> > machine types can continue to set the type when allocating the LSI.
> > 
> > Signed-off-by: Greg Kurz 
> > ---
> >  hw/intc/spapr_xive.c|7 +--
> >  hw/intc/xics.c  |   10 --
> >  hw/intc/xics_kvm.c  |2 +-
> >  hw/ppc/pnv_psi.c|3 ++-
> >  hw/ppc/spapr_events.c   |4 ++--
> >  hw/ppc/spapr_irq.c  |   42 
> > --
> >  hw/ppc/spapr_pci.c  |6 --
> >  hw/ppc/spapr_vio.c  |2 +-
> >  include/hw/ppc/spapr_irq.h  |5 +++--
> >  include/hw/ppc/spapr_xive.h |2 +-
> >  include/hw/ppc/xics.h   |4 +++-
> >  11 files changed, 58 insertions(+), 29 deletions(-)
> > 
> > diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> > index 290a290e43a5..815263ca72ab 100644
> > --- a/hw/intc/spapr_xive.c
> > +++ b/hw/intc/spapr_xive.c
> > @@ -480,18 +480,13 @@ static void spapr_xive_register_types(void)
> >  
> >  type_init(spapr_xive_register_types)
> >  
> > -bool spapr_xive_irq_claim(sPAPRXive *xive, uint32_t lisn, bool lsi)
> > +bool spapr_xive_irq_claim(sPAPRXive *xive, uint32_t lisn)
> >  {
> > -XiveSource *xsrc = &xive->source;
> > -
> >  if (lisn >= xive->nr_irqs) {
> >  return false;
> >  }
> >  
> >  xive->eat[lisn].w |= cpu_to_be64(EAS_VALID);
> > -if (lsi) {
> > -xive_source_irq_set_lsi(xsrc, lisn);
> > -}
> >  return true;
> >  }
> >  
> > diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> > index 7cac138067e2..26e8940d7329 100644
> > --- a/hw/intc/xics.c
> > +++ b/hw/intc/xics.c
> > @@ -636,6 +636,7 @@ static void ics_base_realize(DeviceState *dev, Error 
> > **errp)
> >  return;
> >  }
> >  ics->irqs = g_malloc0(ics->nr_irqs * sizeof(ICSIRQState));
> > +ics->lsi_map = bitmap_new(ics->nr_irqs);
> >  }
> >  
> >  static int ics_base_dispatch_pre_save(void *opaque)
> > @@ -733,12 +734,17 @@ ICPState *xics_icp_get(XICSFabric *xi, int server)
> >  return xic->icp_get(xi, server);
> >  }
> >  
> > -void ics_set_irq_type(ICSState *ics, int srcno, bool lsi)
> > +void ics_set_lsi(ICSState *ics, int srcno)
> > +{
> > +set_bit(srcno, ics->lsi_map);
> > +}
> > +
> > +void ics_claim_irq(ICSState *ics, int srcno)
> >  {
> >  assert(!(ics->irqs[srcno].flags & XICS_FLAGS_IRQ_MASK));
> >  
> >  ics->irqs[srcno].flags |=
> > -lsi ? XICS_FLAGS_IRQ_LSI : XICS_FLAGS_IRQ_MSI;
> > +test_bit(srcno, ics->lsi_map) ? XICS_FLAGS_IRQ_LSI : 
> > XICS_FLAGS_IRQ_MSI;  
> 
> I really don't like having the trigger type redundantly stored in the
> lsi_map and then again in the flags fields.
> 
> In a sense the natural way to do this would be more like the hardware
> - have two source objects, one for MSIs and one for LSIs, and make the
> trigger a per ICSState rather than per IRQState.  But that would make
> life hard for the legacy support.
> 
> But... thinking about it, isn't all this overkill anyway.  Can't we
> fix the problem by simply forcing an ics_set_kvm_state() (and the xive
> equivalent) at claim time.  It's not like it's a hot path.
> 

I had kinda followed this approach in earlier versions. I'll try
again.

> >  }
> >  
> >  static void xics_register_types

Re: [Qemu-devel] [PATCH v1 12/15] s390x/tcg: Implement XxC and checks for most FP instructions

[David Hildenbrand]

On 12.02.19 21:23, Richard Henderson wrote:
> On 2/12/19 3:03 AM, David Hildenbrand wrote:
>> -uint64_t HELPER(cegb)(CPUS390XState *env, int64_t v2, uint32_t m3)
>> +uint64_t HELPER(cegb)(CPUS390XState *env, int64_t v2, uint32_t m)
>>  {
>> -int old_mode = s390_swap_bfp_rounding_mode(env, m3);
>> +int old_mode = s390_swap_bfp_rounding_mode(env, m & 0xf);
>>  
>>  float32 ret = int64_to_float32(v2, &env->fpu_status);
>>  s390_restore_bfp_rounding_mode(env, old_mode);
>> -handle_exceptions(env, false, GETPC());
>> +handle_exceptions(env, (m >> 8) & 1, GETPC());
>>  return ret;
>>  }
> 
> It might be helpful to have inlines for these extractions.  E.g
> 
> static inline uint32_t round_from_m34(uint32_t m);
> static inline bool xxc_from_m34(uint32_t m);
> 
>>  static DisasJumpType op_cfeb(DisasContext *s, DisasOps *o)
>>  {
>> -TCGv_i32 m3 = tcg_const_i32(get_field(s->fields, m3));
>> -gen_helper_cfeb(o->out, cpu_env, o->in2, m3);
>> -tcg_temp_free_i32(m3);
>> +TCGv_i32 m;
>> +
>> +if (!valid_bfp_rounding_mode(get_field(s->fields, m3))) {
>> +gen_program_exception(s, PGM_SPECIFICATION);
>> +return DISAS_NORETURN;
>> +}
>> +m = tcg_const_i32(get_fields2(s->fields, m3, m4));
>> +gen_helper_cfeb(o->out, cpu_env, o->in2, m);
>> +tcg_temp_free_i32(m);
>>  gen_set_cc_nz_f32(s, o->in2);
>>  return DISAS_NEXT;
>>  }
> 
> The m4 field does not exist unless fp extension facility is enabled.  You
> should ignore the field if not installed.

As all users I know already take the floating-point extension facility
for granted, I wanted to avoid faking it away for now. Old
implementations set all fields to zero either way. But I'll take another
shot if it can be easily added without uglifying the code.

> 
> It would be good to split this out to a helper, since there are so many 
> copies.
>  E.g.
> 
> static bool extract_m3_m4(DisasContext *s, uint32_t *m34)
> {
> int m3 = get_field(s->fields, m3);
> int m4 = get_field(s->fields, m4);
> 
> if (!valid_bfp_rounding_mode(m3)) {
> gen_program_exception(s, PGM_SPECIFICATION);
> return false;
> }
> if (feature) {
> return deposit32(m3, 8, 1, m4);
> }
> return m3;
> }

Okay, I'll play with it to see what the end result would look like.

> 
> Hmm..  Except that I see we don't have enough stored in DisasContext to allow
> you to look up the proper feature.  So perhaps just a FIXME for now?

We do have s390_has_feat(S390_FEAT_FLOATING_POINT_EXT)

> 
> 
> r~
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH] hw/sparc64: Explicitly set default_display = "std"

[Mark Cave-Ayland]

On 13/02/2019 07:07, Thomas Huth wrote:

> The sun4uv_init() function expects vga_interface_type to be either
> VGA_STD or VGA_NONE and sets up a stdvga device or no vga card
> accordingly.
> However, the code in vl.c prefers the Cirrus VGA card to stdvga if
> it is available and the user and the machine did not specify anything
> else.
> So far this has not been a problem, since the Cirrus VGA was not linked
> into the sparc64 target. But with the upcoming Kconfig build system,
> all theoretically possible PCI cards will be enabled by default, so the
> Cirrus VGA card might become available on the sparc64 target, too. vl.c
> then picks the wrong card, causing sun4uv_init() to abort.
> Thus let's make it explicit that we always want stdvga for sparc64 and
> so set default_display = "std" for these machines.
> 
> Signed-off-by: Thomas Huth 
> ---
>  hw/sparc64/sun4u.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
> index ff24d9b..399f2d7 100644
> --- a/hw/sparc64/sun4u.c
> +++ b/hw/sparc64/sun4u.c
> @@ -797,6 +797,7 @@ static void sun4u_class_init(ObjectClass *oc, void *data)
>  mc->default_boot_order = "c";
>  mc->default_cpu_type = SPARC_CPU_TYPE_NAME("TI-UltraSparc-IIi");
>  mc->ignore_boot_device_suffixes = true;
> +mc->default_display = "std";
>  fwc->get_dev_path = sun4u_fw_dev_path;
>  }
>  
> @@ -820,6 +821,7 @@ static void sun4v_class_init(ObjectClass *oc, void *data)
>  mc->max_cpus = 1; /* XXX for now */
>  mc->default_boot_order = "c";
>  mc->default_cpu_type = SPARC_CPU_TYPE_NAME("Sun-UltraSparc-T1");
> +mc->default_display = "std";
>  }
>  
>  static const TypeInfo sun4v_type = {

Reviewed-by: Mark Cave-Ayland 


ATB,

Mark.

Re: [Qemu-devel] [PATCH v1 08/15] s390x/tcg: Handle SET FPC AND LOAD FPC 3-bit BFP rounding modes

[David Hildenbrand]

On 12.02.19 20:56, Richard Henderson wrote:
> On 2/12/19 11:32 AM, David Hildenbrand wrote:
>>> Yes, you want round_to_odd.  I suppose that's not valid for float128 right 
>>> now?
>>
>> roundAndPackFloat64()
>>
>> as well as
>>
>> roundAndPackFloat128()
>>
>> support it.
>>
>> It's not implemented for round_canonical(), round_to_int(),
> 
> These two are easy.  I think Alex and I didn't implement it in the float32/64
> rewrite because we didn't have a user.  Now we will.
> 
>> roundAndPackInt32(), roundAndPackInt64(), roundAndPackUint64(),
>> roundAndPackFloat32()
> 
> Right, these would be from the float128 side.  It shouldn't be too hard...
> 
> 
> r~
> 

Sounds like you are volunteering to implement them? ;)

-- 

Thanks,

David / dhildenb

[Qemu-devel] [PATCH] build: Correct explanation of unnest-vars example

[Markus Armbruster]

Cc: Fam Zheng 
Signed-off-by: Markus Armbruster 
---
 rules.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules.mak b/rules.mak
index 86e033d815..19f3d2c126 100644
--- a/rules.mak
+++ b/rules.mak
@@ -327,7 +327,7 @@ endef
 # ../water/ice.mo-libs = -licemaker
 # ../water/ice.mo-objs = ../water/ice1.o ../water/ice2.o
 #
-# Note that 'hot' didn't include 'season/' in the input, so 'summer.o' is not
+# Note that 'hot' didn't include 'water/' in the input, so 'steam.o' is not
 # included.
 #
 define unnest-vars
-- 
2.17.2

Re: [Qemu-devel] [PATCH v6 48/49] linux-user: Split out ioctl

[Laurent Vivier]

Hi,

this one is really a cut'n'paste but it introduces a problem with 
qemu-alpha, I don't know how/why:

  $ sudo unshare --ipc --uts --pid --fork --kill-child --mount chroot 
chroot/alpha/sid/
  Unsupported ioctl: cmd=0x80047476

And then it hangs.

I'll try to debug.

Thanks,
Laurent

On 18/01/2019 22:31, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 
> ---
>  linux-user/syscall-defs.h  |   1 +
>  linux-user/syscall-ioctl.inc.c | 873 +
>  linux-user/syscall.c   | 843 +--
>  linux-user/strace.list |   3 -
>  4 files changed, 875 insertions(+), 845 deletions(-)
>  create mode 100644 linux-user/syscall-ioctl.inc.c
> 
> diff --git a/linux-user/syscall-defs.h b/linux-user/syscall-defs.h
> index f8f280f376..f58b9745a4 100644
> --- a/linux-user/syscall-defs.h
> +++ b/linux-user/syscall-defs.h
> @@ -61,6 +61,7 @@ SYSCALL_DEF(getppid);
>  #ifdef TARGET_NR_getxpid
>  SYSCALL_DEF(getxpid);
>  #endif
> +SYSCALL_DEF(ioctl, ARG_DEC, ARG_HEX);
>  #ifdef TARGET_NR_ipc
>  SYSCALL_DEF_ARGS(ipc, ARG_HEX, ARG_DEC, ARG_DEC, ARG_HEX, ARG_PTR, ARG_HEX);
>  #endif
> diff --git a/linux-user/syscall-ioctl.inc.c b/linux-user/syscall-ioctl.inc.c
> new file mode 100644
> index 00..820994105f
> --- /dev/null
> +++ b/linux-user/syscall-ioctl.inc.c
> @@ -0,0 +1,873 @@
> +/*
> + *  Linux ioctl syscall implementation
> + *  Copyright (c) 2003 Fabrice Bellard
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, see .
> + */
> +
> +typedef struct IOCTLEntry IOCTLEntry;
> +
> +typedef abi_long do_ioctl_fn(const IOCTLEntry *ie, uint8_t *buf_temp,
> + int fd, int cmd, abi_long arg);
> +
> +struct IOCTLEntry {
> +int target_cmd;
> +unsigned int host_cmd;
> +const char *name;
> +int access;
> +do_ioctl_fn *do_ioctl;
> +const argtype arg_type[5];
> +};
> +
> +#define IOC_R 0x0001
> +#define IOC_W 0x0002
> +#define IOC_RW (IOC_R | IOC_W)
> +
> +#define MAX_STRUCT_SIZE 4096
> +
> +#ifdef CONFIG_FIEMAP
> +/*
> + * So fiemap access checks don't overflow on 32 bit systems.
> + * This is very slightly smaller than the limit imposed by
> + * the underlying kernel.
> + */
> +#define FIEMAP_MAX_EXTENTS ((UINT_MAX - sizeof(struct fiemap))  \
> +/ sizeof(struct fiemap_extent))
> +
> +static abi_long do_ioctl_fs_ioc_fiemap(const IOCTLEntry *ie, uint8_t 
> *buf_temp,
> +   int fd, int cmd, abi_long arg)
> +{
> +/*
> + * The parameter for this ioctl is a struct fiemap followed
> + * by an array of struct fiemap_extent whose size is set
> + * in fiemap->fm_extent_count. The array is filled in by the
> + * ioctl.
> + */
> +int target_size_in, target_size_out;
> +struct fiemap *fm;
> +const argtype *arg_type = ie->arg_type;
> +const argtype extent_arg_type[] = { MK_STRUCT(STRUCT_fiemap_extent) };
> +void *argptr, *p;
> +abi_long ret;
> +int i, extent_size = thunk_type_size(extent_arg_type, 0);
> +uint32_t outbufsz;
> +int free_fm = 0;
> +
> +assert(arg_type[0] == TYPE_PTR);
> +assert(ie->access == IOC_RW);
> +arg_type++;
> +target_size_in = thunk_type_size(arg_type, 0);
> +argptr = lock_user(VERIFY_READ, arg, target_size_in, 1);
> +if (!argptr) {
> +return -TARGET_EFAULT;
> +}
> +thunk_convert(buf_temp, argptr, arg_type, THUNK_HOST);
> +unlock_user(argptr, arg, 0);
> +fm = (struct fiemap *)buf_temp;
> +if (fm->fm_extent_count > FIEMAP_MAX_EXTENTS) {
> +return -TARGET_EINVAL;
> +}
> +
> +outbufsz = sizeof(*fm) + sizeof(struct fiemap_extent) * 
> fm->fm_extent_count;
> +
> +if (outbufsz > MAX_STRUCT_SIZE) {
> +/*
> + * We can't fit all the extents into the fixed size buffer.
> + * Allocate one that is large enough and use it instead.
> + */
> +fm = g_try_malloc(outbufsz);
> +if (!fm) {
> +return -TARGET_ENOMEM;
> +}
> +memcpy(fm, buf_temp, sizeof(struct fiemap));
> +free_fm = 1;
> +}
> +ret = get_errno(safe_ioctl(fd, ie->host_cmd, fm));
> +if (!is_error(ret)) {
> +target_size_out = target_size_in;
> +/*
> + * An extent_count of 0 means we were only counting the extents
> +   

Re: [Qemu-devel] [PATCH v4 05/15] spapr_irq: Expose the phandle of the interrupt controller

[Greg Kurz]

On Wed, 13 Feb 2019 14:52:04 +1100
David Gibson  wrote:

> On Tue, Feb 12, 2019 at 07:24:26PM +0100, Greg Kurz wrote:
> > This will be used by PHB hotplug in order to create the "interrupt-map"
> > property of the PHB node.
> > 
> > Reviewed-by: Cédric Le Goater 
> > Signed-off-by: Greg Kurz 
> > ---
> > v4: - return phandle via a pointer  
> 
> You don't really need to do this.  You already have an Error ** to
> return errors via, so you don't need an error return code.  Plus
> phandles are not permitted to be 0 or -1, so you have some safe values
> even for that case.
> 

Ok, I'll use the return value for the phandle.

> > ---
> >  hw/ppc/spapr_irq.c |   26 ++
> >  include/hw/ppc/spapr_irq.h |2 ++
> >  2 files changed, 28 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> > index b8d725e251ba..31495033c37c 100644
> > --- a/hw/ppc/spapr_irq.c
> > +++ b/hw/ppc/spapr_irq.c
> > @@ -692,6 +692,32 @@ void spapr_irq_reset(sPAPRMachineState *spapr, Error 
> > **errp)
> >  }
> >  }
> >  
> > +int spapr_irq_get_phandle(sPAPRMachineState *spapr, void *fdt,
> > +  uint32_t *phandle, Error **errp)
> > +{
> > +const char *nodename = spapr->irq->get_nodename(spapr);
> > +int offset, ph;
> > +
> > +offset = fdt_subnode_offset(fdt, 0, nodename);
> > +if (offset < 0) {
> > +error_setg(errp, "Can't find node \"%s\": %s", nodename,
> > +   fdt_strerror(offset));
> > +return -1;
> > +}
> > +
> > +ph = fdt_get_phandle(fdt, offset);
> > +if (!ph) {
> > +error_setg(errp, "Can't get phandle of node \"%s\"", nodename);
> > +return -1;
> > +}
> > +
> > +if (phandle) {
> > +*phandle = ph;
> > +}
> > +
> > +return 0;
> > +}
> > +
> >  /*
> >   * XICS legacy routines - to deprecate one day
> >   */
> > diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
> > index ad7127355441..4b3303ef4f6a 100644
> > --- a/include/hw/ppc/spapr_irq.h
> > +++ b/include/hw/ppc/spapr_irq.h
> > @@ -62,6 +62,8 @@ void spapr_irq_free(sPAPRMachineState *spapr, int irq, 
> > int num);
> >  qemu_irq spapr_qirq(sPAPRMachineState *spapr, int irq);
> >  int spapr_irq_post_load(sPAPRMachineState *spapr, int version_id);
> >  void spapr_irq_reset(sPAPRMachineState *spapr, Error **errp);
> > +int spapr_irq_get_phandle(sPAPRMachineState *spapr, void *fdt,
> > +  uint32_t *phandle, Error **errp);
> >  
> >  /*
> >   * XICS legacy routines
> >   
> 



pgppS6xgydlFA.pgp
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v4 13/15] spapr_drc: Allow FDT fragment to be added later

[Greg Kurz]

On Wed, 13 Feb 2019 15:05:24 +1100
David Gibson  wrote:

> On Tue, Feb 12, 2019 at 07:25:19PM +0100, Greg Kurz wrote:
> > The current logic is to provide the FDT fragment when attaching a device
> > to a DRC. This works perfectly fine for our current hotplug support, but
> > soon we will add support for PHB hotplug which has some constraints, that
> > CPU, PCI and LMB devices don't seem to have.
> > 
> > The first constraint is that the "ibm,dma-window" property of the PHB
> > node requires the IOMMU to be configured, ie, spapr_tce_table_enable()
> > has been called, which happens during PHB reset. It is okay in the case
> > of hotplug since the device is reset before the hotplug handler is
> > called. On the contrary with coldplug, the hotplug handler is called
> > first and device is only reset during the initial system reset. Trying
> > to create the FDT fragment on the hotplug path in this case, would
> > result in somthing like this:
> > 
> > ibm,dma-window = < 0x8000 0x00 0x00 0x00 0x00 >;
> > 
> > This will cause linux in the guest to panic, by simply removing and
> > re-adding the PHB using the drmgr command:
> > 
> > page = alloc_pages_node(nid, GFP_KERNEL, get_order(sz));
> > if (!page)
> > panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
> > 
> > The second and maybe more problematic constraint is that the
> > "interrupt-map" property needs to reference the interrupt controller
> > node using the very same phandle that SLOF has already exposed to the
> > guest. QEMU requires SLOF to call the private KVMPPC_H_UPDATE_DT hcall
> > at some point to know about this phandle. With the latest QEMU and SLOF,
> > this happens when SLOF gets quiesced. This means that if the PHB gets
> > hotplugged after CAS but before SLOF quiesce, then we're sure that the
> > phandle is not known when the hotplug handler is called.
> > 
> > The FDT is only needed when the guest first invokes RTAS to configure
> > the connector actually, long after SLOF quiesce. Let's postpone the
> > creation of FDT fragments for PHBs to rtas_ibm_configure_connector().
> > 
> > Since we only need this for PHBs, introduce a new method in the base
> > DRC class for that. It will implemented for "spapr-drc-phb" DRCs in
> > a subsequent patch.
> > 
> > Allow spapr_drc_attach() to be passed a NULL fdt argument if the method
> > is available.
> > 
> > Signed-off-by: Greg Kurz   
> 
> The basic solution looks fine.  However I don't much like the fact
> that this leaves us with two ways to handle the fdt fragment - either
> at connect time or at configure connector time via a callback.  qemu
> already has way to many places where there are confusingly multiple
> ways to do things.
> 
> I know it's a detour, but I'd really prefer to convert the existing
> DRC handling to this new callback scheme, rather than have two
> different approaches.
> 

Ok. I'll introduce the new callback scheme and convert the existing code
in a separate series.

> > ---
> >  hw/ppc/spapr_drc.c |   34 +-
> >  include/hw/ppc/spapr_drc.h |6 ++
> >  2 files changed, 35 insertions(+), 5 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
> > index 189ee681062a..c5a281915665 100644
> > --- a/hw/ppc/spapr_drc.c
> > +++ b/hw/ppc/spapr_drc.c
> > @@ -22,6 +22,7 @@
> >  #include "qemu/error-report.h"
> >  #include "hw/ppc/spapr.h" /* for RTAS return codes */
> >  #include "hw/pci-host/spapr.h" /* spapr_phb_remove_pci_device_cb callback 
> > */
> > +#include "sysemu/device_tree.h"
> >  #include "trace.h"
> >  
> >  #define DRC_CONTAINER_PATH "/dr-connector"
> > @@ -376,6 +377,8 @@ static void prop_get_fdt(Object *obj, Visitor *v, const 
> > char *name,
> >  void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState *d, void *fdt,
> >int fdt_start_offset, Error **errp)
> >  {
> > +sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > +
> >  trace_spapr_drc_attach(spapr_drc_index(drc));
> >  
> >  if (drc->dev) {
> > @@ -384,11 +387,14 @@ void spapr_drc_attach(sPAPRDRConnector *drc, 
> > DeviceState *d, void *fdt,
> >  }
> >  g_assert((drc->state == SPAPR_DRC_STATE_LOGICAL_UNUSABLE)
> >   || (drc->state == SPAPR_DRC_STATE_PHYSICAL_POWERON));
> > -g_assert(fdt);
> > +g_assert(fdt || drck->populate_dt);
> >  
> >  drc->dev = d;
> > -drc->fdt = fdt;
> > -drc->fdt_start_offset = fdt_start_offset;
> > +
> > +if (fdt) {
> > +drc->fdt = fdt;
> > +drc->fdt_start_offset = fdt_start_offset;
> > +}
> >  
> >  object_property_add_link(OBJECT(drc), "device",
> >   object_get_typename(OBJECT(drc->dev)),
> > @@ -1118,10 +1124,28 @@ static void rtas_ibm_configure_connector(PowerPCCPU 
> > *cpu,
> >  goto out;
> >  }
> >  
> > -g_assert(drc->fdt);
> > -
> >  drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> >  
> > +g_assert(drc->fdt || d

Re: [Qemu-devel] [PATCH 1/2] qga-win: include glib when building VSS DLL

[Michael Roth]

Quoting Daniel P. Berrangé (2019-02-13 03:12:06)
> On Tue, Feb 12, 2019 at 03:29:16PM -0600, Michael Roth wrote:
> > Commit 3ebee3b191e defined assert() as g_assert(), but when we build
> > the VSS DLL component of QGA (to handle fsfreeze) we do not include
> > glib, which results in breakage when building with VSS support enabled.
> > 
> > Fix this by including glib. Since the VSS DLL is built statically,
> > this introduces an additional dependency on static glib and supporting
> > libs for the mingw environment (possibly why we didn't include glib
> > originally), but VSS support already has very specific prerequisites
> > so it shouldn't affect too many build environments.
> > 
> > Since the VSS DLL code does use qemu/osdep.h, this should also help
> > avoid future breakages and possibly allow for some clean ups in current
> > VSS code.
> > 
> > Suggested-by: Daniel P. Berrangé 
> > Cc: Daniel P. Berrangé 
> > Cc: qemu-sta...@nongnu.org
> > Signed-off-by: Michael Roth 
> > ---
> >  qga/vss-win32/Makefile.objs | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/qga/vss-win32/Makefile.objs b/qga/vss-win32/Makefile.objs
> > index 23d08da225..dad9d1b0ba 100644
> > --- a/qga/vss-win32/Makefile.objs
> > +++ b/qga/vss-win32/Makefile.objs
> > @@ -5,7 +5,7 @@ qga-vss-dll-obj-y += requester.o provider.o install.o
> >  obj-qga-vss-dll-obj-y = $(addprefix $(obj)/, $(qga-vss-dll-obj-y))
> >  $(obj-qga-vss-dll-obj-y): QEMU_CXXFLAGS = $(filter-out -Wstrict-prototypes 
> > -Wmissing-prototypes -Wnested-externs -Wold-style-declaration 
> > -Wold-style-definition -Wredundant-decls -fstack-protector-all 
> > -fstack-protector-strong, $(QEMU_CFLAGS)) -Wno-unknown-pragmas 
> > -Wno-delete-non-virtual-dtor
> >  
> > -$(obj)/qga-vss.dll: LDFLAGS = -shared 
> > -Wl,--add-stdcall-alias,--enable-stdcall-fixup -lole32 -loleaut32 -lshlwapi 
> > -luuid -static
> > +$(obj)/qga-vss.dll: LDFLAGS = -shared 
> > -Wl,--add-stdcall-alias,--enable-stdcall-fixup -lglib-2.0 -lole32 
> > -loleaut32 -lshlwapi -luuid -lintl -lws2_32 -static
> 
> Adding -lglib-2.0 makes sense, but your commit message doesn't explain
> why -lintl or -lws2_32 are being added & they don't really make sense
> to me.

Those are dependencies introduced by glib for w32 socket APIs and 
gettext/internationalization. I was getting linker errors otherwise.

I'll add a note in the commit msg before applying (if there's no need for
a re-respin).

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