Re: Regression with latest SeaBIOS booting multi-disk root LVs?

[Gerd Hoffmann]

On Mon, Sep 21, 2020 at 03:10:51PM +0200, Stefan Reiter wrote:
> Hi list,
> 
> since SeaBIOS 1.14.0 (QEMU 5.1) VMs with LVM root disks spanning more than
> one PV fail to boot, if only the first is set as bootable. I believe this is
> due to the changes in SeaBIOS only initializing drives marked as 'bootable'
> by QEMU.
> 
> One fix is to mark all disks containing root data as bootable, but existing
> setups will still break on upgrade (where only the disk containing the
> bootloader is marked). This is not ideal.
> 
> Discovered by a user in our bugtracker:
> https://bugzilla.proxmox.com/show_bug.cgi?id=3011
> 
> and verified by installing Ubuntu 20.04 w/ LVM and GRUB on virtio-scsi, then
> expanding the LV to a second disk.
> 
> I found that just reverting SeaBIOS to 1.13.0 makes it work again, same
> guest install, even with QEMU 5.1.
> 
> Is this intended behaviour?

Yes, it is intentional.  Save some memory and speed up boot by not
initializing disks which are not needed.

> Any fix or workaround?

 - Assign a bootindex to all drives needed, as you already figured, or

 - Start qemu with -boot strict=off, or

 - Install guest with a /boot filesystem on a normal partition.  Which
   is IMHO a good idea anyway for robustness reasons, you can use all
   lvm features without worrying whenever grub is able to cope or not.

take care,
  Gerd

Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Derek Su]

Hi, Chen and Lei

Using Lei's patch is OK to me.
Please help to add "Signed-off-by: Derek Su " for merging
it.
Thank you. :)

Regards
Derek

Zhang, Chen  於 2020年9月22日 週二 下午1:37寫道：

> So, Derek, you will send new version patch?
>
>
>
> Thanks
>
> Zhang Chen
>
>
>
> *From:* Derek Su 
> *Sent:* Tuesday, September 22, 2020 1:18 PM
> *To:* Rao, Lei 
> *Cc:* Zhang, Chen ; qemu-devel <
> qemu-devel@nongnu.org>; zhang.zhanghaili...@huawei.com;
> quint...@redhat.com; dgilb...@redhat.com
> *Subject:* Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo
> cache
>
>
>
> Hi, Lei
>
>
>
> Got it. Thanks.
>
>
>
> Regards,
>
> Derek
>
>
>
> Rao, Lei  於 2020年9月22日 週二 下午1:04寫道：
>
> Hi, Derek and Chen
>
> ram_bulk_stage is false by default before Hailiang's patch.
> For COLO, it does not seem to be used, so I think there is no need to
> reset it to true.
>
> Thanks,
> Lei.
>
> From: Derek Su 
> Sent: Tuesday, September 22, 2020 11:48 AM
> To: Zhang, Chen 
> Cc: qemu-devel ; Rao, Lei ;
> zhang.zhanghaili...@huawei.com; quint...@redhat.com; dgilb...@redhat.com
> Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo
> cache
>
> Hi, Chen
>
> Sure.
>
> BTW, I just went through Lei's patch.
> ram_bulk_stage() might need to reset to true after stopping COLO service
> as my patch.
> How about your opinion?
>
> Thanks.
>
>
> Best regards,
> Derek
>
>
> Zhang, Chen  於 2020年9月22日 週二 上午11:41寫道：
> Hi Derek and Lei,
>
> It looks same with Lei’ patch:
> [PATCH 2/3] Reduce the time of checkpoint for COLO
> Can you discuss to merge it into one patch?
>
> Thanks
> Zhang Chen
>
> From: Derek Su 
> Sent: Tuesday, September 22, 2020 11:31 AM
> To: qemu-devel 
> Cc: mailto:zhang.zhanghaili...@huawei.com; mailto:quint...@redhat.com;
> mailto:dgilb...@redhat.com; Zhang, Chen 
> Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo
> cache
>
> Hello, all
>
> Ping...
>
> Regards,
> Derek Su
>
> Derek Su  於 2020年9月10日 週四 下午6:47寫道：
> In secondary side, the colo_flush_ram_cache() calls
> migration_bitmap_find_dirty() to finding the dirty pages and
> flush them to host. But ram_state's ram_bulk_stage flag is always
> enabled in secondary side, it leads to the whole ram pages copy
> instead of only dirty pages.
>
> Here, the ram_bulk_stage in secondary side is disabled in the
> preparation of COLO incoming process to avoid the whole dirty
> ram pages flush.
>
> Signed-off-by: Derek Su 
> ---
>  migration/colo.c |  6 +-
>  migration/ram.c  | 10 ++
>  migration/ram.h  |  3 +++
>  3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/migration/colo.c b/migration/colo.c
> index ea7d1e9d4e..6e644db306 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
>  return NULL;
>  }
>
> +colo_disable_ram_bulk_stage();
> +
>  failover_init_state();
>
>  mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
> @@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
>  goto out;
>  }
>  #else
> -abort();
> +abort();
>  #endif
>  vm_start();
>  trace_colo_vm_state_change("stop", "run");
> @@ -924,6 +926,8 @@ out:
>  qemu_fclose(fb);
>  }
>
> +colo_enable_ram_bulk_stage();
> +
>  /* Hope this not to be too long to loop here */
>  qemu_sem_wait(>colo_incoming_sem);
>  qemu_sem_destroy(>colo_incoming_sem);
> diff --git a/migration/ram.c b/migration/ram.c
> index 76d4fee5d5..65e9b12058 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
>  return ps >= POSTCOPY_INCOMING_LISTENING && ps <
> POSTCOPY_INCOMING_END;
>  }
>
> +void colo_enable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = true;
> +}
> +
> +void colo_disable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = false;
> +}
> +
>  /*
>   * Flush content of RAM cache into SVM's memory.
>   * Only flush the pages that be dirtied by PVM or SVM or both.
> diff --git a/migration/ram.h b/migration/ram.h
> index 2eeaacfa13..c1c0ebbe0f 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
>  void colo_release_ram_cache(void);
>  void colo_incoming_start_dirty_log(void);
>
> +void colo_enable_ram_bulk_stage(void);
> +void colo_disable_ram_bulk_stage(void);
> +
>  #endif
> --
> 2.25.1
>
>

RE: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Zhang, Chen]

So, Derek, you will send new version patch?

Thanks
Zhang Chen

From: Derek Su 
Sent: Tuesday, September 22, 2020 1:18 PM
To: Rao, Lei 
Cc: Zhang, Chen ; qemu-devel ; 
zhang.zhanghaili...@huawei.com; quint...@redhat.com; dgilb...@redhat.com
Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

Hi, Lei

Got it. Thanks.

Regards,
Derek

Rao, Lei mailto:lei@intel.com>> 於 2020年9月22日 週二 下午1:04寫道：
Hi, Derek and Chen

ram_bulk_stage is false by default before Hailiang's patch.
For COLO, it does not seem to be used, so I think there is no need to reset it 
to true.

Thanks,
Lei.

From: Derek Su mailto:dere...@qnap.com>>
Sent: Tuesday, September 22, 2020 11:48 AM
To: Zhang, Chen mailto:chen.zh...@intel.com>>
Cc: qemu-devel mailto:qemu-devel@nongnu.org>>; Rao, Lei 
mailto:lei@intel.com>>; 
zhang.zhanghaili...@huawei.com; 
quint...@redhat.com; 
dgilb...@redhat.com
Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

Hi, Chen

Sure.

BTW, I just went through Lei's patch.
ram_bulk_stage() might need to reset to true after stopping COLO service as my 
patch.
How about your opinion?

Thanks.


Best regards,
Derek


Zhang, Chen > 於 
2020年9月22日 週二 上午11:41寫道：
Hi Derek and Lei,

It looks same with Lei’ patch:
[PATCH 2/3] Reduce the time of checkpoint for COLO
Can you discuss to merge it into one patch?

Thanks
Zhang Chen

From: Derek Su >
Sent: Tuesday, September 22, 2020 11:31 AM
To: qemu-devel >
Cc: 
mailto:zhang.zhanghaili...@huawei.com; 
mailto:quint...@redhat.com; 
mailto:dgilb...@redhat.com; Zhang, Chen 
>
Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

Hello, all

Ping...

Regards,
Derek Su

Derek Su > 於 2020年9月10日 週四 
下午6:47寫道：
In secondary side, the colo_flush_ram_cache() calls
migration_bitmap_find_dirty() to finding the dirty pages and
flush them to host. But ram_state's ram_bulk_stage flag is always
enabled in secondary side, it leads to the whole ram pages copy
instead of only dirty pages.

Here, the ram_bulk_stage in secondary side is disabled in the
preparation of COLO incoming process to avoid the whole dirty
ram pages flush.

Signed-off-by: Derek Su >
---
 migration/colo.c |  6 +-
 migration/ram.c  | 10 ++
 migration/ram.h  |  3 +++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/migration/colo.c b/migration/colo.c
index ea7d1e9d4e..6e644db306 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
 return NULL;
 }

+colo_disable_ram_bulk_stage();
+
 failover_init_state();

 mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
@@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
 goto out;
 }
 #else
-abort();
+abort();
 #endif
 vm_start();
 trace_colo_vm_state_change("stop", "run");
@@ -924,6 +926,8 @@ out:
 qemu_fclose(fb);
 }

+colo_enable_ram_bulk_stage();
+
 /* Hope this not to be too long to loop here */
 qemu_sem_wait(>colo_incoming_sem);
 qemu_sem_destroy(>colo_incoming_sem);
diff --git a/migration/ram.c b/migration/ram.c
index 76d4fee5d5..65e9b12058 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
 return ps >= POSTCOPY_INCOMING_LISTENING && ps < POSTCOPY_INCOMING_END;
 }

+void colo_enable_ram_bulk_stage(void)
+{
+ram_state->ram_bulk_stage = true;
+}
+
+void colo_disable_ram_bulk_stage(void)
+{
+ram_state->ram_bulk_stage = false;
+}
+
 /*
  * Flush content of RAM cache into SVM's memory.
  * Only flush the pages that be dirtied by PVM or SVM or both.
diff --git a/migration/ram.h b/migration/ram.h
index 2eeaacfa13..c1c0ebbe0f 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
 void colo_release_ram_cache(void);
 void colo_incoming_start_dirty_log(void);

+void colo_enable_ram_bulk_stage(void);
+void colo_disable_ram_bulk_stage(void);
+
 #endif
--
2.25.1

Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Derek Su]

Hi, Lei

Got it. Thanks.

Regards,
Derek

Rao, Lei  於 2020年9月22日 週二 下午1:04寫道：

> Hi, Derek and Chen
>
> ram_bulk_stage is false by default before Hailiang's patch.
> For COLO, it does not seem to be used, so I think there is no need to
> reset it to true.
>
> Thanks,
> Lei.
>
> From: Derek Su 
> Sent: Tuesday, September 22, 2020 11:48 AM
> To: Zhang, Chen 
> Cc: qemu-devel ; Rao, Lei ;
> zhang.zhanghaili...@huawei.com; quint...@redhat.com; dgilb...@redhat.com
> Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo
> cache
>
> Hi, Chen
>
> Sure.
>
> BTW, I just went through Lei's patch.
> ram_bulk_stage() might need to reset to true after stopping COLO service
> as my patch.
> How about your opinion?
>
> Thanks.
>
>
> Best regards,
> Derek
>
>
> Zhang, Chen  於 2020年9月22日 週二 上午11:41寫道：
> Hi Derek and Lei,
>
> It looks same with Lei’ patch:
> [PATCH 2/3] Reduce the time of checkpoint for COLO
> Can you discuss to merge it into one patch?
>
> Thanks
> Zhang Chen
>
> From: Derek Su 
> Sent: Tuesday, September 22, 2020 11:31 AM
> To: qemu-devel 
> Cc: mailto:zhang.zhanghaili...@huawei.com; mailto:quint...@redhat.com;
> mailto:dgilb...@redhat.com; Zhang, Chen 
> Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo
> cache
>
> Hello, all
>
> Ping...
>
> Regards,
> Derek Su
>
> Derek Su  於 2020年9月10日 週四 下午6:47寫道：
> In secondary side, the colo_flush_ram_cache() calls
> migration_bitmap_find_dirty() to finding the dirty pages and
> flush them to host. But ram_state's ram_bulk_stage flag is always
> enabled in secondary side, it leads to the whole ram pages copy
> instead of only dirty pages.
>
> Here, the ram_bulk_stage in secondary side is disabled in the
> preparation of COLO incoming process to avoid the whole dirty
> ram pages flush.
>
> Signed-off-by: Derek Su 
> ---
>  migration/colo.c |  6 +-
>  migration/ram.c  | 10 ++
>  migration/ram.h  |  3 +++
>  3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/migration/colo.c b/migration/colo.c
> index ea7d1e9d4e..6e644db306 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
>  return NULL;
>  }
>
> +colo_disable_ram_bulk_stage();
> +
>  failover_init_state();
>
>  mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
> @@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
>  goto out;
>  }
>  #else
> -abort();
> +abort();
>  #endif
>  vm_start();
>  trace_colo_vm_state_change("stop", "run");
> @@ -924,6 +926,8 @@ out:
>  qemu_fclose(fb);
>  }
>
> +colo_enable_ram_bulk_stage();
> +
>  /* Hope this not to be too long to loop here */
>  qemu_sem_wait(>colo_incoming_sem);
>  qemu_sem_destroy(>colo_incoming_sem);
> diff --git a/migration/ram.c b/migration/ram.c
> index 76d4fee5d5..65e9b12058 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
>  return ps >= POSTCOPY_INCOMING_LISTENING && ps <
> POSTCOPY_INCOMING_END;
>  }
>
> +void colo_enable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = true;
> +}
> +
> +void colo_disable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = false;
> +}
> +
>  /*
>   * Flush content of RAM cache into SVM's memory.
>   * Only flush the pages that be dirtied by PVM or SVM or both.
> diff --git a/migration/ram.h b/migration/ram.h
> index 2eeaacfa13..c1c0ebbe0f 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
>  void colo_release_ram_cache(void);
>  void colo_incoming_start_dirty_log(void);
>
> +void colo_enable_ram_bulk_stage(void);
> +void colo_disable_ram_bulk_stage(void);
> +
>  #endif
> --
> 2.25.1
>

Re: [PATCH v3 1/2] Introduce (x86) CPU model deprecation API

[Robert Hoo]

On Mon, 2020-09-21 at 11:37 -0400, Eduardo Habkost wrote:
> > 
...
> > Yes. Trying as less refactor as possible. I think my changes even
> > cannot be called refactor at all. :)
> > My idea is to make unversioned CPU model virtual. I did some patch,
> > doable:
> > 1) in x86_register_cpudef_types(), don't register cpu_model type
> > for
> > the unversioned 'Model'.
> > 2) in x86_cpu_class_by_name(), check passed-in cpu_model param
> > versioned or not, if the virtual unversioned 'Model', parse it to
> > some
> > concrete version by global default_cpu_version designation.
> > 
> > So, user can still use '-cpu Model' as before, no interface
> > changes.
> > And no nature changes:
> > 1) in current code, even legacy 'Model', you have created a v1
> > model
> > for it. i.e., every virtual 'Model' already has at least one
> > concrete
> > versioned one.
> > 2) in current code, x86_cpu_model_resolve_version() is called when
> > x86_cpu_load_model(). x86_cpu_model_resolve_version() actually does
> > kind of work that concreting unversioned Model to its versioned
> > one, by
> > global default_cpu_version designation. Same as my aforementioned
> > above.
> > 
> > Would you like me to integrate this implementation in v4? to have a
> > look.
> 
> I think we might give this a try, but I wouldn't like to have
> your model deprecation series delayed because of this.  Some
> obstacles I expect to see:
> 
> Right now the code assumes a 1:1 mapping between CPU model and
> QOM class.  We even have a `typename` field returned by
> query-cpu-definitions.
> 
> It would also become an obstacle for removing the existing
> arch-specific class_by_name methods and do the model->class
> mapping based solely on a string template.  See this thread for a
> glimpse on what we have been trying to do:
> https://lore.kernel.org/qemu-devel/877eb173a3@dusky.pond.sub.org/
> 
> I'm not saying we shouldn't do what you suggest, but it would add
> a lot of complexity to your CPU model deprecation work (that's
> very close to be ready to be merged).
> 
OK, I'm going to send v4 without this.
Then send this in a separate patch for discussion.
> > > > 
> > > --
> > > Eduardo
> > > 
> 
> 

RE: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Rao, Lei]

Hi, Derek and Chen

ram_bulk_stage is false by default before Hailiang's patch.
For COLO, it does not seem to be used, so I think there is no need to reset it 
to true.

Thanks,
Lei.

From: Derek Su  
Sent: Tuesday, September 22, 2020 11:48 AM
To: Zhang, Chen 
Cc: qemu-devel ; Rao, Lei ; 
zhang.zhanghaili...@huawei.com; quint...@redhat.com; dgilb...@redhat.com
Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

Hi, Chen

Sure.

BTW, I just went through Lei's patch.
ram_bulk_stage() might need to reset to true after stopping COLO service as my 
patch.
How about your opinion?

Thanks.


Best regards,
Derek


Zhang, Chen  於 2020年9月22日 週二 上午11:41寫道：
Hi Derek and Lei,
 
It looks same with Lei’ patch:
[PATCH 2/3] Reduce the time of checkpoint for COLO
Can you discuss to merge it into one patch?
 
Thanks
Zhang Chen
 
From: Derek Su  
Sent: Tuesday, September 22, 2020 11:31 AM
To: qemu-devel 
Cc: mailto:zhang.zhanghaili...@huawei.com; mailto:quint...@redhat.com; 
mailto:dgilb...@redhat.com; Zhang, Chen 
Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache
 
Hello, all
 
Ping...
 
Regards,
Derek Su
 
Derek Su  於 2020年9月10日 週四 下午6:47寫道：
In secondary side, the colo_flush_ram_cache() calls
migration_bitmap_find_dirty() to finding the dirty pages and
flush them to host. But ram_state's ram_bulk_stage flag is always
enabled in secondary side, it leads to the whole ram pages copy
instead of only dirty pages.

Here, the ram_bulk_stage in secondary side is disabled in the
preparation of COLO incoming process to avoid the whole dirty
ram pages flush.

Signed-off-by: Derek Su 
---
 migration/colo.c |  6 +-
 migration/ram.c  | 10 ++
 migration/ram.h  |  3 +++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/migration/colo.c b/migration/colo.c
index ea7d1e9d4e..6e644db306 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
         return NULL;
     }

+    colo_disable_ram_bulk_stage();
+
     failover_init_state();

     mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
@@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
         goto out;
     }
 #else
-        abort();
+    abort();
 #endif
     vm_start();
     trace_colo_vm_state_change("stop", "run");
@@ -924,6 +926,8 @@ out:
         qemu_fclose(fb);
     }

+    colo_enable_ram_bulk_stage();
+
     /* Hope this not to be too long to loop here */
     qemu_sem_wait(>colo_incoming_sem);
     qemu_sem_destroy(>colo_incoming_sem);
diff --git a/migration/ram.c b/migration/ram.c
index 76d4fee5d5..65e9b12058 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
     return ps >= POSTCOPY_INCOMING_LISTENING && ps < POSTCOPY_INCOMING_END;
 }

+void colo_enable_ram_bulk_stage(void)
+{
+    ram_state->ram_bulk_stage = true;
+}
+
+void colo_disable_ram_bulk_stage(void)
+{
+    ram_state->ram_bulk_stage = false;
+}
+
 /*
  * Flush content of RAM cache into SVM's memory.
  * Only flush the pages that be dirtied by PVM or SVM or both.
diff --git a/migration/ram.h b/migration/ram.h
index 2eeaacfa13..c1c0ebbe0f 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
 void colo_release_ram_cache(void);
 void colo_incoming_start_dirty_log(void);

+void colo_enable_ram_bulk_stage(void);
+void colo_disable_ram_bulk_stage(void);
+
 #endif
-- 
2.25.1

Re: [PATCH 00/24] qom: Convert some properties to class properties

[Eduardo Habkost]

On Tue, Sep 22, 2020 at 09:47:57AM +0800, Li Qiang wrote:
> Eduardo Habkost  于2020年9月22日周二 上午6:11写道：
> >
> > Class properties make QOM introspection simpler and easier, as it
> > doesn't require an object to be instantiated.  This series
> > converts a few existing object_property_add*() calls to register
> > class properties instead.
> >
> 
> Hello Eduardo,
> 
> IIUC, most of the properties can be dev-spec or class-spec.
> Do we have any principle or rule to specify the property to be dev or class?
> 
> Maybe if the property which is always the same between instances can
> be a class-property?

If you are talking about having the same value, this is not the
use case for class properties.  Registering a class property just
means all instances of the object will have that property (but
each instance can have the property set to a different value),
and makes this information available for introspection before
instantiating the object.

-- 
Eduardo

Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Derek Su]

Hi, Chen

Sure.

BTW, I just went through Lei's patch.
ram_bulk_stage() might need to reset to true after stopping COLO service as
my patch.
How about your opinion?

Thanks.

Best regards,
Derek


Zhang, Chen  於 2020年9月22日 週二 上午11:41寫道：

> Hi Derek and Lei,
>
>
>
> It looks same with Lei’ patch:
>
> [PATCH 2/3] Reduce the time of checkpoint for COLO
>
> Can you discuss to merge it into one patch?
>
>
>
> Thanks
>
> Zhang Chen
>
>
>
> *From:* Derek Su 
> *Sent:* Tuesday, September 22, 2020 11:31 AM
> *To:* qemu-devel 
> *Cc:* zhang.zhanghaili...@huawei.com; quint...@redhat.com;
> dgilb...@redhat.com; Zhang, Chen 
> *Subject:* Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo
> cache
>
>
>
> Hello, all
>
>
>
> Ping...
>
>
>
> Regards,
>
> Derek Su
>
>
>
> Derek Su  於 2020年9月10日 週四 下午6:47寫道：
>
> In secondary side, the colo_flush_ram_cache() calls
> migration_bitmap_find_dirty() to finding the dirty pages and
> flush them to host. But ram_state's ram_bulk_stage flag is always
> enabled in secondary side, it leads to the whole ram pages copy
> instead of only dirty pages.
>
> Here, the ram_bulk_stage in secondary side is disabled in the
> preparation of COLO incoming process to avoid the whole dirty
> ram pages flush.
>
> Signed-off-by: Derek Su 
> ---
>  migration/colo.c |  6 +-
>  migration/ram.c  | 10 ++
>  migration/ram.h  |  3 +++
>  3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/migration/colo.c b/migration/colo.c
> index ea7d1e9d4e..6e644db306 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
>  return NULL;
>  }
>
> +colo_disable_ram_bulk_stage();
> +
>  failover_init_state();
>
>  mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
> @@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
>  goto out;
>  }
>  #else
> -abort();
> +abort();
>  #endif
>  vm_start();
>  trace_colo_vm_state_change("stop", "run");
> @@ -924,6 +926,8 @@ out:
>  qemu_fclose(fb);
>  }
>
> +colo_enable_ram_bulk_stage();
> +
>  /* Hope this not to be too long to loop here */
>  qemu_sem_wait(>colo_incoming_sem);
>  qemu_sem_destroy(>colo_incoming_sem);
> diff --git a/migration/ram.c b/migration/ram.c
> index 76d4fee5d5..65e9b12058 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
>  return ps >= POSTCOPY_INCOMING_LISTENING && ps <
> POSTCOPY_INCOMING_END;
>  }
>
> +void colo_enable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = true;
> +}
> +
> +void colo_disable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = false;
> +}
> +
>  /*
>   * Flush content of RAM cache into SVM's memory.
>   * Only flush the pages that be dirtied by PVM or SVM or both.
> diff --git a/migration/ram.h b/migration/ram.h
> index 2eeaacfa13..c1c0ebbe0f 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
>  void colo_release_ram_cache(void);
>  void colo_incoming_start_dirty_log(void);
>
> +void colo_enable_ram_bulk_stage(void);
> +void colo_disable_ram_bulk_stage(void);
> +
>  #endif
> --
> 2.25.1
>
>

RE: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Zhang, Chen]

Hi Derek and Lei,

It looks same with Lei’ patch:
[PATCH 2/3] Reduce the time of checkpoint for COLO
Can you discuss to merge it into one patch?

Thanks
Zhang Chen

From: Derek Su 
Sent: Tuesday, September 22, 2020 11:31 AM
To: qemu-devel 
Cc: zhang.zhanghaili...@huawei.com; quint...@redhat.com; dgilb...@redhat.com; 
Zhang, Chen 
Subject: Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

Hello, all

Ping...

Regards,
Derek Su

Derek Su mailto:dere...@qnap.com>> 於 2020年9月10日 週四 下午6:47寫道：
In secondary side, the colo_flush_ram_cache() calls
migration_bitmap_find_dirty() to finding the dirty pages and
flush them to host. But ram_state's ram_bulk_stage flag is always
enabled in secondary side, it leads to the whole ram pages copy
instead of only dirty pages.

Here, the ram_bulk_stage in secondary side is disabled in the
preparation of COLO incoming process to avoid the whole dirty
ram pages flush.

Signed-off-by: Derek Su mailto:dere...@qnap.com>>
---
 migration/colo.c |  6 +-
 migration/ram.c  | 10 ++
 migration/ram.h  |  3 +++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/migration/colo.c b/migration/colo.c
index ea7d1e9d4e..6e644db306 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
 return NULL;
 }

+colo_disable_ram_bulk_stage();
+
 failover_init_state();

 mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
@@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
 goto out;
 }
 #else
-abort();
+abort();
 #endif
 vm_start();
 trace_colo_vm_state_change("stop", "run");
@@ -924,6 +926,8 @@ out:
 qemu_fclose(fb);
 }

+colo_enable_ram_bulk_stage();
+
 /* Hope this not to be too long to loop here */
 qemu_sem_wait(>colo_incoming_sem);
 qemu_sem_destroy(>colo_incoming_sem);
diff --git a/migration/ram.c b/migration/ram.c
index 76d4fee5d5..65e9b12058 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
 return ps >= POSTCOPY_INCOMING_LISTENING && ps < POSTCOPY_INCOMING_END;
 }

+void colo_enable_ram_bulk_stage(void)
+{
+ram_state->ram_bulk_stage = true;
+}
+
+void colo_disable_ram_bulk_stage(void)
+{
+ram_state->ram_bulk_stage = false;
+}
+
 /*
  * Flush content of RAM cache into SVM's memory.
  * Only flush the pages that be dirtied by PVM or SVM or both.
diff --git a/migration/ram.h b/migration/ram.h
index 2eeaacfa13..c1c0ebbe0f 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
 void colo_release_ram_cache(void);
 void colo_incoming_start_dirty_log(void);

+void colo_enable_ram_bulk_stage(void);
+void colo_disable_ram_bulk_stage(void);
+
 #endif
--
2.25.1

Re: [PATCH v1 1/1] COLO: only flush dirty ram pages from colo cache

[Derek Su]

Hello, all

Ping...

Regards,
Derek Su

Derek Su  於 2020年9月10日 週四 下午6:47寫道：

> In secondary side, the colo_flush_ram_cache() calls
> migration_bitmap_find_dirty() to finding the dirty pages and
> flush them to host. But ram_state's ram_bulk_stage flag is always
> enabled in secondary side, it leads to the whole ram pages copy
> instead of only dirty pages.
>
> Here, the ram_bulk_stage in secondary side is disabled in the
> preparation of COLO incoming process to avoid the whole dirty
> ram pages flush.
>
> Signed-off-by: Derek Su 
> ---
>  migration/colo.c |  6 +-
>  migration/ram.c  | 10 ++
>  migration/ram.h  |  3 +++
>  3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/migration/colo.c b/migration/colo.c
> index ea7d1e9d4e..6e644db306 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -844,6 +844,8 @@ void *colo_process_incoming_thread(void *opaque)
>  return NULL;
>  }
>
> +colo_disable_ram_bulk_stage();
> +
>  failover_init_state();
>
>  mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
> @@ -873,7 +875,7 @@ void *colo_process_incoming_thread(void *opaque)
>  goto out;
>  }
>  #else
> -abort();
> +abort();
>  #endif
>  vm_start();
>  trace_colo_vm_state_change("stop", "run");
> @@ -924,6 +926,8 @@ out:
>  qemu_fclose(fb);
>  }
>
> +colo_enable_ram_bulk_stage();
> +
>  /* Hope this not to be too long to loop here */
>  qemu_sem_wait(>colo_incoming_sem);
>  qemu_sem_destroy(>colo_incoming_sem);
> diff --git a/migration/ram.c b/migration/ram.c
> index 76d4fee5d5..65e9b12058 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3357,6 +3357,16 @@ static bool postcopy_is_running(void)
>  return ps >= POSTCOPY_INCOMING_LISTENING && ps <
> POSTCOPY_INCOMING_END;
>  }
>
> +void colo_enable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = true;
> +}
> +
> +void colo_disable_ram_bulk_stage(void)
> +{
> +ram_state->ram_bulk_stage = false;
> +}
> +
>  /*
>   * Flush content of RAM cache into SVM's memory.
>   * Only flush the pages that be dirtied by PVM or SVM or both.
> diff --git a/migration/ram.h b/migration/ram.h
> index 2eeaacfa13..c1c0ebbe0f 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -69,4 +69,7 @@ void colo_flush_ram_cache(void);
>  void colo_release_ram_cache(void);
>  void colo_incoming_start_dirty_log(void);
>
> +void colo_enable_ram_bulk_stage(void);
> +void colo_disable_ram_bulk_stage(void);
> +
>  #endif
> --
> 2.25.1
>
>

[PATCH] vhost-user: save features of multiqueues if chardev is closed

[张海斌]

Fore-commit(c6beefd674) only saves features of queue0,
this makes wrong features of other queues in multiqueues
situation.
For examples:
  qemu-system-aarch64 ... \
  -chardev socket,id=charnet0,path=/var/run/vhost_sock \
  -netdev vhost-user,chardev=charnet0,queues=2,id=hostnet0 \
  ...
There are two queues in nic assocated with one chardev.
When chardev is reconnected, it is necessary to save and
restore features of all queues.

Signed-of-by: Haibin Zhang 
---
 net/vhost-user.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/net/vhost-user.c b/net/vhost-user.c
index 17532daaf3..ffbd94d944 100644
--- a/net/vhost-user.c
+++ b/net/vhost-user.c
@@ -226,7 +226,7 @@ static void chr_closed_bh(void *opaque)
 NetClientState *ncs[MAX_QUEUE_NUM];
 NetVhostUserState *s;
 Error *err = NULL;
-int queues;
+int queues, i;
 
 queues = qemu_find_net_clients_except(name, ncs,
   NET_CLIENT_DRIVER_NIC,
@@ -235,8 +235,12 @@ static void chr_closed_bh(void *opaque)
 
 s = DO_UPCAST(NetVhostUserState, nc, ncs[0]);
 
-if (s->vhost_net) {
-s->acked_features = vhost_net_get_acked_features(s->vhost_net);
+for (i = queues -1; i >= 0; i--) {
+s = DO_UPCAST(NetVhostUserState, nc, ncs[i]);
+
+if (s->vhost_net) {
+s->acked_features = vhost_net_get_acked_features(s->vhost_net);
+}
 }
 
 qmp_set_link(name, false, );
-- 
2.23.0

Re: [PATCH 00/24] qom: Convert some properties to class properties

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200921221045.699690-1-ehabk...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or 
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
Running test qtest-x86_64: qos-test
Broken pipe
../src/tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 
7 (Bus error) (core dumped)
ERROR qtest-x86_64: device-introspect-test - too few tests run (expected 6, got 
5)
make: *** [run-test-151] Error 1
make: *** Waiting for unfinished jobs

Looking for expected file 'tests/data/acpi/microvm/FACP'
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', 
'--label', 'com.qemu.instance.uuid=1012ee92264940698a9ece48329b2072', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 
'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-h2ifbdcv/src/docker-src.2020-09-21-22.55.00.16625:/var/tmp/qemu:z,ro',
 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=1012ee92264940698a9ece48329b2072
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-h2ifbdcv/src'
make: *** [docker-run-test-quick@centos7] Error 2

real7m22.647s
user0m20.149s


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

Re: [PATCH 1/3] virtio-net: Set mac address to hardware if the peer is vdpa

[Cindy Lu]

On Tue, Sep 22, 2020 at 9:55 AM Jason Wang  wrote:
>
>
> On 2020/9/17 下午11:58, Cindy Lu wrote:
> > If the peer's type is vdpa,set the mac address to NIC in 
> > virtio_net_device_realize,
> > Also sometime vdpa get an all 0 macaddress from the hardware, this will 
> > cause the traffic down
> > So we add the check for this part.
> > if we get an 0 mac address we will use the default mac address instead
> >
> > Signed-off-by: Cindy Lu 
> > ---
> >   hw/net/virtio-net.c | 12 +++-
> >   1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index cb0d27084c..7db9da1482 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -126,6 +126,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
> > uint8_t *config)
> >   VirtIONet *n = VIRTIO_NET(vdev);
> >   struct virtio_net_config netcfg;
> >   NetClientState *nc = qemu_get_queue(n->nic);
> > +static const MACAddr zero = { .a = { 0, 0, 0, 0, 0, 0 } };
> >
> >   int ret = 0;
> >   memset(, 0 , sizeof(struct virtio_net_config));
> > @@ -151,7 +152,11 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
> > uint8_t *config)
> >   ret = vhost_net_get_config(get_vhost_net(nc->peer), (uint8_t 
> > *),
> >  n->config_size);
> >   if (ret != -1) {
> > -memcpy(config, , n->config_size);
> > +if (memcmp(, , sizeof(zero)) != 0) {
> > +memcpy(config, , n->config_size);
> > +} else {
> > +error_report("Get an all zero mac address from hardware");
>
>
> This is probably a hint that MAC is not properly provisioned.
>
> So I guess we can leave this as is, or simply warn until the management
> interface is finalized.
>
Hi Jason, For sure this is NIC card's problem, They cannot provide an
correct MAC address,
But if we continue use this 0 mac address will cause this traffic
down, maybe will cost a lot of effort in debugging
So I think maybe Just an warn is not enough, We can use the default
mac address  and let the traffic working
>
> > +}
> >   }
> >   }
> >   }
> > @@ -3399,6 +3404,11 @@ static void virtio_net_device_realize(DeviceState 
> > *dev, Error **errp)
> >   nc = qemu_get_queue(n->nic);
> >   nc->rxfilter_notify_enabled = 1;
> >
> > +   if (nc->peer && nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) {
> > +struct virtio_net_config netcfg = {};
> > +memcpy(, >nic_conf.macaddr, ETH_ALEN);
> > +virtio_net_set_config(vdev, (uint8_t *));
>
>
> Won't this overwrite all other fields in the netcfg? I think we should
> only touch mac part.
>
> Thanks
>
>
Sure, will fix this
> > +}
> >   QTAILQ_INIT(>rsc_chains);
> >   n->qdev = dev;
> >
>

[Bug 1896561] [NEW] EFI GOP Mode 1366x768

[Benjamin David Lunt]

Public bug reported:

When using the EFI firmware from
https://www.kraxel.org/repos/jenkins/edk2/
(https://www.kraxel.org/repos/jenkins/edk2/edk2.git-
ovmf-x64-0-20200919.1453.g7faece6985.noarch.rpm) (OVMF-pure-efi.fd and
OVMF_VARS-pure-efi.fd) then using the GOP, setting the mode to 1366x768,
QEMU uses a width of 1360 instead.

I am using QEMU for windows (https://qemu.weilnetz.de/) on a Windows 10
machine.

To verify, while in the EFI firmware loaded code (within BOOTx64.EFI)
and before ExitBootServices(), I choose the 1360x768 mode.  I then took
notice of where the host window was and how many pixels it occupied.  I
then reset the emulation (without quitting) and chose the 1366x768 mode.
QEMU set the host window to the exact same width as the 1360 mode.
i.e.: The same exact pixels where shown in the host background.  The
window did not expand the extra 6 pixels.

I allowed the firmware to run its course to my test environment when
using mode 1366x768, all pixels are 6 pixels off to the right.  i.e.: 6
pixels down the Frame Buffer.  If my test environment changes its HORZ
WIDTH and PIXELS PER SCANLINE to 1360 while using this (1366x768) mode,
the display is correct.

This told me that it could be a few things.
1) Since most (I didn't check them all) of the other modes have the width 
value's bits 2:0 clear, mode 1366x768 is the only mode the EDK2 firmware has 
with a width where bits 2:0 are not zero.  Could EDK2 or QEMU (which for the 
Windows version may use SDL2 so it must be considered here) be clearing these 
bits?  The value of 1366 when clearing bits 2:0 is 1360.

2) Could there be a typo in the code EDK2 where the width should have been 1366?
(I went looking at both QEMU (for Windows) and EDK2 and after looking at many 
lines of code, I could not find anywhere where this might happen. 

By the way, in /ui/sdl2-2d.c (QEMU Windows version only?), there is a
typo in a comment, missing the second 'e':

Line 156:  * the native ones. Thes are the ones I have tested.

3) Could EDK2 be sending 1360 instead of 1366?
4) Could QEMU (passing it on to SDL2 in SDL_SetWindowSize()?) be destroying the 
value (bottom three bits)?

Anyway, using the latest version of the EDK2 from the URL listed above,
choosing the 1366x768 mode, does not set QEMU (for Windows) to 1366
pixels in width.

Ben

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  EFI GOP Mode 1366x768

Status in QEMU:
  New

Bug description:
  When using the EFI firmware from
  https://www.kraxel.org/repos/jenkins/edk2/
  (https://www.kraxel.org/repos/jenkins/edk2/edk2.git-
  ovmf-x64-0-20200919.1453.g7faece6985.noarch.rpm) (OVMF-pure-efi.fd and
  OVMF_VARS-pure-efi.fd) then using the GOP, setting the mode to
  1366x768, QEMU uses a width of 1360 instead.

  I am using QEMU for windows (https://qemu.weilnetz.de/) on a Windows
  10 machine.

  To verify, while in the EFI firmware loaded code (within BOOTx64.EFI)
  and before ExitBootServices(), I choose the 1360x768 mode.  I then
  took notice of where the host window was and how many pixels it
  occupied.  I then reset the emulation (without quitting) and chose the
  1366x768 mode.  QEMU set the host window to the exact same width as
  the 1360 mode.  i.e.: The same exact pixels where shown in the host
  background.  The window did not expand the extra 6 pixels.

  I allowed the firmware to run its course to my test environment when
  using mode 1366x768, all pixels are 6 pixels off to the right.  i.e.:
  6 pixels down the Frame Buffer.  If my test environment changes its
  HORZ WIDTH and PIXELS PER SCANLINE to 1360 while using this (1366x768)
  mode, the display is correct.

  This told me that it could be a few things.
  1) Since most (I didn't check them all) of the other modes have the width 
value's bits 2:0 clear, mode 1366x768 is the only mode the EDK2 firmware has 
with a width where bits 2:0 are not zero.  Could EDK2 or QEMU (which for the 
Windows version may use SDL2 so it must be considered here) be clearing these 
bits?  The value of 1366 when clearing bits 2:0 is 1360.

  2) Could there be a typo in the code EDK2 where the width should have been 
1366?
  (I went looking at both QEMU (for Windows) and EDK2 and after looking at many 
lines of code, I could not find anywhere where this might happen. 

  By the way, in /ui/sdl2-2d.c (QEMU Windows version only?), there is a
  typo in a comment, missing the second 'e':

  Line 156:  * the native ones. Thes are the ones I have tested.

  3) Could EDK2 be sending 1360 instead of 1366?
  4) Could QEMU (passing it on to SDL2 in SDL_SetWindowSize()?) be destroying 
the value (bottom three bits)?

  Anyway, using the latest version of the EDK2 from the URL listed
  above, choosing the 1366x768 mode, does not set QEMU (for Windows) to
  1366 pixels in width.

  Ben

To manage 

[PATCH V10 6/8] hw/mips: Implement fw_cfg_arch_key_name()

[Huacai Chen]

Implement fw_cfg_arch_key_name(), which returns the name of a
mips-specific key.

Signed-off-by: Huacai Chen 
Co-developed-by: Jiaxun Yang 
---
 hw/mips/fw_cfg.c| 35 +++
 hw/mips/fw_cfg.h| 19 +++
 hw/mips/meson.build |  2 +-
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 hw/mips/fw_cfg.c
 create mode 100644 hw/mips/fw_cfg.h

diff --git a/hw/mips/fw_cfg.c b/hw/mips/fw_cfg.c
new file mode 100644
index 00..67c4a74f4b
--- /dev/null
+++ b/hw/mips/fw_cfg.c
@@ -0,0 +1,35 @@
+/*
+ * QEMU fw_cfg helpers (MIPS specific)
+ *
+ * Copyright (c) 2020 Lemote, Inc.
+ *
+ * Author:
+ *   Huacai Chen (che...@lemote.com)
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/mips/fw_cfg.h"
+#include "hw/nvram/fw_cfg.h"
+
+const char *fw_cfg_arch_key_name(uint16_t key)
+{
+static const struct {
+uint16_t key;
+const char *name;
+} fw_cfg_arch_wellknown_keys[] = {
+{FW_CFG_MACHINE_VERSION, "machine_version"},
+{FW_CFG_CPU_FREQ, "cpu_frequency"},
+};
+
+for (size_t i = 0; i < ARRAY_SIZE(fw_cfg_arch_wellknown_keys); i++) {
+if (fw_cfg_arch_wellknown_keys[i].key == key) {
+return fw_cfg_arch_wellknown_keys[i].name;
+}
+}
+return NULL;
+}
diff --git a/hw/mips/fw_cfg.h b/hw/mips/fw_cfg.h
new file mode 100644
index 00..e317d5b9a3
--- /dev/null
+++ b/hw/mips/fw_cfg.h
@@ -0,0 +1,19 @@
+/*
+ * QEMU fw_cfg helpers (MIPS specific)
+ *
+ * Copyright (c) 2020 Huacai Chen
+ *
+ * SPDX-License-Identifier: MIT
+ */
+
+#ifndef HW_MIPS_FW_CFG_H
+#define HW_MIPS_FW_CFG_H
+
+#include "hw/boards.h"
+#include "hw/nvram/fw_cfg.h"
+
+/* Data for BIOS to identify machine */
+#define FW_CFG_MACHINE_VERSION  (FW_CFG_ARCH_LOCAL + 0)
+#define FW_CFG_CPU_FREQ (FW_CFG_ARCH_LOCAL + 1)
+
+#endif
diff --git a/hw/mips/meson.build b/hw/mips/meson.build
index 46294b7382..c98391ce99 100644
--- a/hw/mips/meson.build
+++ b/hw/mips/meson.build
@@ -1,5 +1,5 @@
 mips_ss = ss.source_set()
-mips_ss.add(files('addr.c', 'mips_int.c'))
+mips_ss.add(files('addr.c', 'mips_int.c', 'fw_cfg.c'))
 mips_ss.add(when: 'CONFIG_FULOONG', if_true: files('fuloong2e.c'))
 mips_ss.add(when: 'CONFIG_JAZZ', if_true: files('jazz.c'))
 mips_ss.add(when: 'CONFIG_MALTA', if_true: files('gt64xxx_pci.c', 'malta.c'))
-- 
2.17.2

[PATCH V10 8/8] docs/system: Update MIPS machine documentation

[Huacai Chen]

Add Loongson-3A CPU models and Loongson-3 based machine description.

Signed-off-by: Huacai Chen 
---
 docs/system/cpu-models-mips.rst.inc | 10 --
 docs/system/target-mips.rst | 10 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/docs/system/cpu-models-mips.rst.inc 
b/docs/system/cpu-models-mips.rst.inc
index 499b5b6fed..02cc4bb884 100644
--- a/docs/system/cpu-models-mips.rst.inc
+++ b/docs/system/cpu-models-mips.rst.inc
@@ -48,11 +48,17 @@ across all desired hosts.
 ``I6400``
 MIPS64 Processor (Release 6, 2014)
 
+``Loongson-2E``
+MIPS64 Processor (Loongson 2, 2006)
+
 ``Loongson-2F``
 MIPS64 Processor (Loongson 2, 2008)
 
-``Loongson-2E``
-MIPS64 Processor (Loongson 2, 2006)
+``Loongson-3A1000``
+MIPS64 Processor (Loongson 3, 2010)
+
+``Loongson-3A4000``
+MIPS64 Processor (Loongson 3, 2018)
 
 ``mips64dspr2``
 MIPS64 Processor (Release 2, 2006)
diff --git a/docs/system/target-mips.rst b/docs/system/target-mips.rst
index cd2a931edf..1f86ccb697 100644
--- a/docs/system/target-mips.rst
+++ b/docs/system/target-mips.rst
@@ -84,6 +84,16 @@ The Fuloong 2E emulation supports:
 
 -  RTL8139D as a network card chipset
 
+The Loongson-3 virtual platform emulation supports:
+
+-  Loongson 3A CPU
+
+-  LIOINTC as interrupt controller
+
+-  GPEX and virtio as variable devices
+
+-  Both KVM and TCG supported
+
 The mipssim pseudo board emulation provides an environment similar to
 what the proprietary MIPS emulator uses for running Linux. It supports:
 
-- 
2.17.2

[PATCH V10 5/8] target/mips: Add loongson-ext lsdc2 group of instructions

[Huacai Chen]

From: Jiaxun Yang 

LDC2/SDC2 opcodes have been rewritten as "load & store with offset"
group of instructions by loongson-ext ASE.

This patch add implementation of these instructions:
gslbx: load 1 bytes to GPR
gslhx: load 2 bytes to GPR
gslwx: load 4 bytes to GPR
gsldx: load 8 bytes to GPR
gslwxc1: load 4 bytes to FPR
gsldxc1: load 8 bytes to FPR
gssbx: store 1 bytes from GPR
gsshx: store 2 bytes from GPR
gsswx: store 4 bytes from GPR
gssdx: store 8 bytes from GPR
gsswxc1: store 4 bytes from FPR
gssdxc1: store 8 bytes from FPR

Details of Loongson-EXT is here:
https://github.com/FlyGoat/loongson-insn/blob/master/loongson-ext.md

Signed-off-by: Huacai Chen 
Signed-off-by: Jiaxun Yang 
---
 target/mips/translate.c | 179 
 1 file changed, 179 insertions(+)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 916b57f293..4d42cfceaf 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -484,6 +484,24 @@ enum {
 OPC_GSSDRC1 = 0x7 | OPC_GSSHFS,
 };
 
+/* Loongson EXT LDC2/SDC2 opcodes */
+#define MASK_LOONGSON_LSDC2(op)   (MASK_OP_MAJOR(op) | (op & 0x7))
+
+enum {
+OPC_GSLBX  = 0x0 | OPC_LDC2,
+OPC_GSLHX  = 0x1 | OPC_LDC2,
+OPC_GSLWX  = 0x2 | OPC_LDC2,
+OPC_GSLDX  = 0x3 | OPC_LDC2,
+OPC_GSLWXC1= 0x6 | OPC_LDC2,
+OPC_GSLDXC1= 0x7 | OPC_LDC2,
+OPC_GSSBX  = 0x0 | OPC_SDC2,
+OPC_GSSHX  = 0x1 | OPC_SDC2,
+OPC_GSSWX  = 0x2 | OPC_SDC2,
+OPC_GSSDX  = 0x3 | OPC_SDC2,
+OPC_GSSWXC1= 0x6 | OPC_SDC2,
+OPC_GSSDXC1= 0x7 | OPC_SDC2,
+};
+
 /* BSHFL opcodes */
 #define MASK_BSHFL(op)  (MASK_SPECIAL3(op) | (op & (0x1F << 6)))
 
@@ -6172,6 +6190,165 @@ static void gen_loongson_lswc2(DisasContext *ctx, int 
rt,
 tcg_temp_free(t0);
 }
 
+/* Loongson EXT LDC2/SDC2 */
+static void gen_loongson_lsdc2(DisasContext *ctx, int rt,
+int rs, int rd)
+{
+int offset = (int8_t)(ctx->opcode >> 3);
+uint32_t opc = MASK_LOONGSON_LSDC2(ctx->opcode);
+TCGv t0, t1;
+TCGv_i32 fp0;
+
+/* Pre-conditions */
+switch (opc) {
+case OPC_GSLBX:
+case OPC_GSLHX:
+case OPC_GSLWX:
+case OPC_GSLDX:
+/* prefetch, implement as NOP */
+if (rt == 0) {
+return;
+}
+break;
+case OPC_GSSBX:
+case OPC_GSSHX:
+case OPC_GSSWX:
+case OPC_GSSDX:
+break;
+case OPC_GSLWXC1:
+#if defined(TARGET_MIPS64)
+case OPC_GSLDXC1:
+#endif
+check_cp1_enabled(ctx);
+/* prefetch, implement as NOP */
+if (rt == 0) {
+return;
+}
+break;
+case OPC_GSSWXC1:
+#if defined(TARGET_MIPS64)
+case OPC_GSSDXC1:
+#endif
+check_cp1_enabled(ctx);
+break;
+default:
+MIPS_INVAL("loongson_lsdc2");
+generate_exception_end(ctx, EXCP_RI);
+return;
+break;
+}
+
+t0 = tcg_temp_new();
+
+gen_base_offset_addr(ctx, t0, rs, offset);
+gen_op_addr_add(ctx, t0, cpu_gpr[rd], t0);
+
+switch (opc) {
+case OPC_GSLBX:
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_SB);
+gen_store_gpr(t0, rt);
+break;
+case OPC_GSLHX:
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TESW |
+ctx->default_tcg_memop_mask);
+gen_store_gpr(t0, rt);
+break;
+case OPC_GSLWX:
+gen_base_offset_addr(ctx, t0, rs, offset);
+if (rd) {
+gen_op_addr_add(ctx, t0, cpu_gpr[rd], t0);
+}
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TESL |
+ctx->default_tcg_memop_mask);
+gen_store_gpr(t0, rt);
+break;
+#if defined(TARGET_MIPS64)
+case OPC_GSLDX:
+gen_base_offset_addr(ctx, t0, rs, offset);
+if (rd) {
+gen_op_addr_add(ctx, t0, cpu_gpr[rd], t0);
+}
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_store_gpr(t0, rt);
+break;
+#endif
+case OPC_GSLWXC1:
+check_cp1_enabled(ctx);
+gen_base_offset_addr(ctx, t0, rs, offset);
+if (rd) {
+gen_op_addr_add(ctx, t0, cpu_gpr[rd], t0);
+}
+fp0 = tcg_temp_new_i32();
+tcg_gen_qemu_ld_i32(fp0, t0, ctx->mem_idx, MO_TESL |
+ctx->default_tcg_memop_mask);
+gen_store_fpr32(ctx, fp0, rt);
+tcg_temp_free_i32(fp0);
+break;
+#if defined(TARGET_MIPS64)
+case OPC_GSLDXC1:
+check_cp1_enabled(ctx);
+gen_base_offset_addr(ctx, t0, rs, offset);
+if (rd) {
+gen_op_addr_add(ctx, t0, cpu_gpr[rd], t0);
+}
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_store_fpr64(ctx, t0, rt);
+break;
+#endif
+case OPC_GSSBX:
+t1 = 

[PATCH V10 3/8] target/mips: Add loongson-ext lswc2 group of instructions (Part 1)

[Huacai Chen]

From: Jiaxun Yang 

LWC2 & SWC2 have been rewritten by Loongson EXT vendor ASE
as "load/store quad word" and "shifted load/store" groups of
instructions.

This patch add implementation of these instructions:
gslq: load 16 bytes to GPR
gssq: store 16 bytes from GPR
gslqc1: load 16 bytes to FPR
gssqc1: store 16 bytes from FPR

Details of Loongson-EXT is here:
https://github.com/FlyGoat/loongson-insn/blob/master/loongson-ext.md

Signed-off-by: Huacai Chen 
Signed-off-by: Jiaxun Yang 
---
 target/mips/translate.c | 87 +
 1 file changed, 87 insertions(+)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 398edf7289..cb0adde310 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -460,6 +460,17 @@ enum {
 R6_OPC_SCD = 0x27 | OPC_SPECIAL3,
 };
 
+/* Loongson EXT load/store quad word opcodes */
+#define MASK_LOONGSON_GSLSQ(op)   (MASK_OP_MAJOR(op) | (op & 0x8020))
+enum {
+OPC_GSLQ= 0x0020 | OPC_LWC2,
+OPC_GSLQC1  = 0x8020 | OPC_LWC2,
+OPC_GSSHFL  = OPC_LWC2,
+OPC_GSSQ= 0x0020 | OPC_SWC2,
+OPC_GSSQC1  = 0x8020 | OPC_SWC2,
+OPC_GSSHFS  = OPC_SWC2,
+};
+
 /* BSHFL opcodes */
 #define MASK_BSHFL(op)  (MASK_SPECIAL3(op) | (op & (0x1F << 6)))
 
@@ -5910,6 +5921,80 @@ no_rd:
 tcg_temp_free_i64(t1);
 }
 
+static void gen_loongson_lswc2(DisasContext *ctx, int rt,
+int rs, int rd)
+{
+TCGv t0, t1, t2;
+TCGv_i32 fp0;
+#if defined(TARGET_MIPS64)
+int lsq_rt1 = ctx->opcode & 0x1f;
+int lsq_offset = ((int)((ctx->opcode >> 6) & 0x1ff) << 23) >> 19;
+#endif
+int shf_offset = (int8_t)(ctx->opcode >> 6);
+
+t0 = tcg_temp_new();
+
+switch (MASK_LOONGSON_GSLSQ(ctx->opcode)) {
+#if defined(TARGET_MIPS64)
+case OPC_GSLQ:
+t1 = tcg_temp_new();
+gen_base_offset_addr(ctx, t0, rs, lsq_offset);
+tcg_gen_qemu_ld_tl(t1, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_base_offset_addr(ctx, t0, rs, lsq_offset + 8);
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_store_gpr(t1, rt);
+gen_store_gpr(t0, lsq_rt1);
+tcg_temp_free(t1);
+break;
+case OPC_GSLQC1:
+check_cp1_enabled(ctx);
+t1 = tcg_temp_new();
+gen_base_offset_addr(ctx, t0, rs, lsq_offset);
+tcg_gen_qemu_ld_tl(t1, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_base_offset_addr(ctx, t0, rs, lsq_offset + 8);
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_store_fpr64(ctx, t1, rt);
+gen_store_fpr64(ctx, t0, lsq_rt1);
+tcg_temp_free(t1);
+break;
+case OPC_GSSQ:
+t1 = tcg_temp_new();
+gen_base_offset_addr(ctx, t0, rs, lsq_offset);
+gen_load_gpr(t1, rt);
+tcg_gen_qemu_st_tl(t1, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_base_offset_addr(ctx, t0, rs, lsq_offset + 8);
+gen_load_gpr(t1, lsq_rt1);
+tcg_gen_qemu_st_tl(t1, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+tcg_temp_free(t1);
+break;
+case OPC_GSSQC1:
+check_cp1_enabled(ctx);
+t1 = tcg_temp_new();
+gen_base_offset_addr(ctx, t0, rs, lsq_offset);
+gen_load_fpr64(ctx, t1, rt);
+tcg_gen_qemu_st_tl(t1, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+gen_base_offset_addr(ctx, t0, rs, lsq_offset + 8);
+gen_load_fpr64(ctx, t1, lsq_rt1);
+tcg_gen_qemu_st_tl(t1, t0, ctx->mem_idx, MO_TEQ |
+ctx->default_tcg_memop_mask);
+tcg_temp_free(t1);
+break;
+#endif
+default:
+MIPS_INVAL("loongson_gslsq");
+generate_exception_end(ctx, EXCP_RI);
+break;
+}
+tcg_temp_free(t0);
+}
+
 /* Traps */
 static void gen_trap(DisasContext *ctx, uint32_t opc,
  int rs, int rt, int16_t imm)
@@ -30774,6 +30859,8 @@ static void decode_opc(CPUMIPSState *env, DisasContext 
*ctx)
 /* OPC_BC, OPC_BALC */
 gen_compute_compact_branch(ctx, op, 0, 0,
sextract32(ctx->opcode << 2, 0, 28));
+} else if (ctx->insn_flags & ASE_LEXT) {
+gen_loongson_lswc2(ctx, rt, rs, rd);
 } else {
 /* OPC_LWC2, OPC_SWC2 */
 /* COP2: Not implemented. */
-- 
2.17.2

[PATCH V10 2/8] target/mips: Fix PageMask with variable page size

[Huacai Chen]

From: Jiaxun Yang 

Our current code assumed the target page size is always 4k
when handling PageMask and VPN2, however, variable page size
was just added to mips target and that's nolonger true.

Signed-off-by: Huacai Chen 
Signed-off-by: Jiaxun Yang 
---
 target/mips/cp0_helper.c | 36 +---
 target/mips/cpu.h|  1 +
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
index de64add038..62bcb9707e 100644
--- a/target/mips/cp0_helper.c
+++ b/target/mips/cp0_helper.c
@@ -867,13 +867,35 @@ void helper_mtc0_memorymapid(CPUMIPSState *env, 
target_ulong arg1)
 
 void update_pagemask(CPUMIPSState *env, target_ulong arg1, int32_t *pagemask)
 {
-uint64_t mask = arg1 >> (TARGET_PAGE_BITS + 1);
-if (!(env->insn_flags & ISA_MIPS32R6) || (arg1 == ~0) ||
-(mask == 0x || mask == 0x0003 || mask == 0x000F ||
- mask == 0x003F || mask == 0x00FF || mask == 0x03FF ||
- mask == 0x0FFF || mask == 0x3FFF || mask == 0x)) {
-env->CP0_PageMask = arg1 & (0x1FFF & (TARGET_PAGE_MASK << 1));
+unsigned long mask;
+int maskbits;
+
+if (env->insn_flags & ISA_MIPS32R6) {
+return;
+}
+/* Don't care MASKX as we don't support 1KB page */
+mask = extract32((uint32_t)arg1, CP0PM_MASK, 16);
+maskbits = find_first_zero_bit(, 32);
+
+/* Ensure no more set bit after first zero */
+if (mask >> maskbits) {
+goto invalid;
+}
+/* We don't support VTLB entry smaller than target page */
+if ((maskbits + 12) < TARGET_PAGE_BITS) {
+goto invalid;
 }
+env->CP0_PageMask = mask << CP0PM_MASK;
+
+return;
+
+invalid:
+/*
+ * When invalid, ensure the value is bigger tan or equel to
+ * the minimal but smaller than or equel to the maxium.
+ */
+maskbits = MIN(16, MAX(maskbits, TARGET_PAGE_BITS - 12));
+env->CP0_PageMask = ((1 << (16 + 1)) - 1) << CP0PM_MASK;
 }
 
 void helper_mtc0_pagemask(CPUMIPSState *env, target_ulong arg1)
@@ -1104,7 +1126,7 @@ void helper_mthc0_saar(CPUMIPSState *env, target_ulong 
arg1)
 void helper_mtc0_entryhi(CPUMIPSState *env, target_ulong arg1)
 {
 target_ulong old, val, mask;
-mask = (TARGET_PAGE_MASK << 1) | env->CP0_EntryHi_ASID_mask;
+mask = ~((1 << 14) - 1) | env->CP0_EntryHi_ASID_mask;
 if (((env->CP0_Config4 >> CP0C4_IE) & 0x3) >= 2) {
 mask |= 1 << CP0EnHi_EHINV;
 }
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 7cf7f5239f..9c8bb23807 100644
--- a/target/mips/cpu.h
+++ b/target/mips/cpu.h
@@ -618,6 +618,7 @@ struct CPUMIPSState {
  * CP0 Register 5
  */
 int32_t CP0_PageMask;
+#define CP0PM_MASK 13
 int32_t CP0_PageGrain_rw_bitmask;
 int32_t CP0_PageGrain;
 #define CP0PG_RIE 31
-- 
2.17.2

[PATCH V10 7/8] hw/mips: Add Loongson-3 machine support

[Huacai Chen]

Add Loongson-3 based machine support, it use liointc as the interrupt
controler and use GPEX as the pci controller. Currently it can work with
both TCG and KVM.

As the machine model is not based on any exiting physical hardware, the
name of the machine is "loongson3-virt". It may be superseded in future
by a real machine model. If this happens, then a regular deprecation
procedure shall occur for "loongson3-virt" machine.

We now already have a full functional Linux kernel (based on Linux-5.4.x
LTS, the kvm host side and guest side have both been upstream for Linux-
5.9, but Linux-5.9 has not been released yet) here:

https://github.com/chenhuacai/linux

Of course the upstream kernel is also usable (though it is "unstable"
now):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

How to use QEMU/Loongson-3?
1, Download kernel source from the above URL;
2, Build a kernel with arch/mips/configs/loongson3_defconfig;
3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
4, Build QEMU-master with this patchset;
5, modprobe kvm (only necessary for KVM mode);
6, Use QEMU with TCG:
   qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu Loongson-3A1000 
-kernel  -append ...
   Use QEMU with KVM:
   qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu Loongson-3A4000 
-kernel  -append ...

   The "-cpu" parameter is optional here and QEMU will use the correct type for 
TCG/KVM automatically.

Signed-off-by: Huacai Chen 
Co-developed-by: Jiaxun Yang 
---
 default-configs/mips64el-softmmu.mak |   1 +
 hw/mips/Kconfig  |  11 +
 hw/mips/loongson3_virt.c | 775 +++
 hw/mips/loongson_bootp.h | 187 +++
 hw/mips/meson.build  |   1 +
 5 files changed, 975 insertions(+)
 create mode 100644 hw/mips/loongson3_virt.c
 create mode 100644 hw/mips/loongson_bootp.h

diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index 9f8a3ef156..26c660a05c 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -3,6 +3,7 @@
 include mips-softmmu-common.mak
 CONFIG_IDE_VIA=y
 CONFIG_FULOONG=y
+CONFIG_LOONGSON3V=y
 CONFIG_ATI_VGA=y
 CONFIG_RTL8139_PCI=y
 CONFIG_JAZZ=y
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index 67d39c56a4..cc5609b08c 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -45,6 +45,18 @@ config FULOONG
 bool
 select PCI_BONITO
 
+config LOONGSON3V
+bool
+select PCKBD
+select SERIAL
+select GOLDFISH_RTC
+select LOONGSON_LIOINTC
+select PCI_DEVICES
+select PCI_EXPRESS_GENERIC_BRIDGE
+select VIRTIO_VGA
+select QXL if SPICE
+select MSI_NONBROKEN
+
 config MIPS_CPS
 bool
 select PTIMER
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
new file mode 100644
index 00..f9f454b47c
--- /dev/null
+++ b/hw/mips/loongson3_virt.c
@@ -0,0 +1,775 @@
+/*
+ * Generic Loongson-3 Platform support
+ *
+ * Copyright (c) 2017-2020 Huacai Chen (che...@lemote.com)
+ * Copyright (c) 2017-2020 Jiaxun Yang 
+ *
+ * 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 .
+ */
+
+/*
+ * Generic virtualized PC Platform based on Loongson-3 CPU (MIPS64R2 with
+ * extensions, 800~2000MHz)
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/units.h"
+#include "qemu/cutils.h"
+#include "qapi/error.h"
+#include "cpu.h"
+#include "elf.h"
+#include "kvm_mips.h"
+#include "hw/boards.h"
+#include "hw/char/serial.h"
+#include "hw/mips/mips.h"
+#include "hw/mips/cpudevs.h"
+#include "hw/mips/fw_cfg.h"
+#include "hw/mips/loongson_bootp.h"
+#include "hw/misc/unimp.h"
+#include "hw/intc/i8259.h"
+#include "hw/loader.h"
+#include "hw/isa/superio.h"
+#include "hw/pci/msi.h"
+#include "hw/pci/pci.h"
+#include "hw/pci/pci_host.h"
+#include "hw/pci-host/gpex.h"
+#include "hw/rtc/mc146818rtc.h"
+#include "hw/usb.h"
+#include "net/net.h"
+#include "exec/address-spaces.h"
+#include "sysemu/kvm.h"
+#include "sysemu/qtest.h"
+#include "sysemu/reset.h"
+#include "sysemu/runstate.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+
+#define PM_CNTL_MODE  0x10
+
+/* Overall MMIO & Memory layout */
+enum {
+VIRT_LOWMEM,
+VIRT_PM,
+VIRT_FW_CFG,
+VIRT_RTC,
+VIRT_PCIE_PIO,
+VIRT_PCIE_ECAM,
+VIRT_BIOS_ROM,
+VIRT_UART,
+VIRT_LIOINTC,
+

[PATCH V10 0/8] mips: Add Loongson-3 machine support

[Huacai Chen]

Loongson-3 CPU family include Loongson-3A R1/R2/R3/R4 and Loongson-3B
R1/R2. Loongson-3A R1 is the oldest and its ISA is the smallest, while
Loongson-3A R4 is the newest and its ISA is almost the superset of all
others. To reduce complexity, in QEMU we just define two CPU types:

1, "Loongson-3A1000" CPU which is corresponding to Loongson-3A R1. It is
   suitable for TCG because Loongson-3A R1 has fewest ASE.
2, "Loongson-3A4000" CPU which is corresponding to Loongson-3A R4. It is
   suitable for KVM because Loongson-3A R4 has the VZ ASE.

Loongson-3 lacks English documents. I've tried to translated them with
translate.google.com, and the machine translated documents (together
with their original Chinese versions) are available here.

Loongson-3A R1 (Loongson-3A1000)
User Manual Part 1:
http://ftp.godson.ac.cn/lemote/3A1000_p1.pdf
http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P1.pdf 
(Chinese Version)
User Manual Part 2:
http://ftp.godson.ac.cn/lemote/3A1000_p2.pdf
http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P2.pdf 
(Chinese Version)

Loongson-3A R2 (Loongson-3A2000)
User Manual Part 1:
http://ftp.godson.ac.cn/lemote/3A2000_p1.pdf
http://ftp.godson.ac.cn/lemote/Loongson3A2000_user1.pdf (Chinese Version)
User Manual Part 2:
http://ftp.godson.ac.cn/lemote/3A2000_p2.pdf
http://ftp.godson.ac.cn/lemote/Loongson3A2000_user2.pdf (Chinese Version)

Loongson-3A R3 (Loongson-3A3000)
User Manual Part 1:
http://ftp.godson.ac.cn/lemote/3A3000_p1.pdf
http://ftp.godson.ac.cn/lemote/Loongson3A3000_3B3000usermanual1.pdf (Chinese 
Version)
User Manual Part 2:
http://ftp.godson.ac.cn/lemote/3A3000_p2.pdf
http://ftp.godson.ac.cn/lemote/Loongson3A3000_3B3000usermanual2.pdf (Chinese 
Version)

Loongson-3A R4 (Loongson-3A4000)
User Manual Part 1:
http://ftp.godson.ac.cn/lemote/3A4000_p1.pdf
http://ftp.godson.ac.cn/lemote/3A4000user.pdf (Chinese Version)
User Manual Part 2:
I'm sorry that it is unavailable now.

And human-translated documents (W.I.P) are available here now:
https://github.com/loongson-community/docs/tree/master/English-translation-of-Loongson-manual

Both KVM and TCG are available now!

We now already have a full functional Linux kernel (based on Linux-5.4.x
LTS, the kvm host side and guest side have both been upstream for Linux-
5.9, but Linux-5.9 has not been released yet) here:

https://github.com/chenhuacai/linux

Of course the upstream kernel is also usable (though it is "unstable"
now):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

How to use QEMU/Loongson-3?
1, Download kernel source from the above URL;
2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
4, Build QEMU-master with this patchset;
5, modprobe kvm (only necessary for KVM mode);
6, Use QEMU with TCG:
   qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu Loongson-3A1000 
-kernel  -append ...
   Use QEMU with KVM:
   qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu Loongson-3A4000 
-kernel  -append ...

   The "-cpu" parameter is optional here and QEMU will use the correct type for 
TCG/KVM automatically.

V1 -> V2:
1, Add a cover letter;
2, Improve CPU definitions;
3, Remove LS7A-related things (Use GPEX instead);
4, Add a description of how to run QEMU/Loongson-3.

V2 -> V3:
1, Fix all possible checkpatch.pl errors and warnings.

V3 -> V4:
1, Sync code with upstream;
2, Remove merged patches;
3, Fix build failure without CONFIG_KVM;
4, Add Reviewed-by: Aleksandar Markovic .

V4 -> V5:
1, Improve coding style;
2, Remove merged patches;
3, Rename machine name from "loongson3" to "loongson3-virt";
4, Rework the "loongson3-virt" machine to drop any ISA things;
5, Rework "hw/mips: Implement the kvm_type() hook in MachineClass";
6, Add Jiaxun Yang as a reviewer of Loongson-3.

V5 -> V6:
1, Fix license preamble;
2, Improve commit messages;
3, Add hw/intc/loongson_liointc.c to MAINTAINERS;
4, Fix all possible checkpatch.pl errors and warnings.

V7 and V8 have only one patch (machine definition) with some minor improvements.

V8 -> V9:
1, Update KVM type definition from kernel;
2, Fix PageMask with variable page size for TCG;
3, Add TCG support (add Loongson-EXT instructions).

V9 -> V10:
1, Split fw_cfg to a separate patch;
2, Split boot parameters definition to a local header;
3, Update MIPS machine documentation;
4, Many other improvements suggested by Philippe Mathieu-Daud??.

Huacai Chen and Jiaxun Yang (8):
 linux-headers: Update MIPS KVM type defintition
 target/mips: Fix PageMask with variable page size
 target/mips: Add loongson-ext lswc2 group of instructions (Part 1)
 target/mips: Add loongson-ext lswc2 group of instructions (Part 2)
 target/mips: Add loongson-ext lsdc2 group of instructions
 hw/mips: Implement fw_cfg_arch_key_name()
 hw/mips: Add Loongson-3 machine support
 docs/system: Update MIPS machine documentation

Signed-off-by: Huacai Chen 
---
 

[PATCH V10 1/8] linux-headers: Update MIPS KVM type defintition

[Huacai Chen]

Update MIPS KVM type defintition from Linux 5.9-rc6.

Signed-off-by: Huacai Chen 
---
 linux-headers/linux/kvm.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index a28c366737..36a480fd77 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -789,9 +789,10 @@ struct kvm_ppc_resize_hpt {
 #define KVM_VM_PPC_HV 1
 #define KVM_VM_PPC_PR 2
 
-/* on MIPS, 0 forces trap & emulate, 1 forces VZ ASE */
-#define KVM_VM_MIPS_TE 0
+/* on MIPS, 0 indicates auto, 1 forces VZ ASE, 2 forces trap & emulate */
+#define KVM_VM_MIPS_AUTO   0
 #define KVM_VM_MIPS_VZ 1
+#define KVM_VM_MIPS_TE 2
 
 #define KVM_S390_SIE_PAGE_OFFSET 1
 
-- 
2.17.2

[PATCH V10 4/8] target/mips: Add loongson-ext lswc2 group of instructions (Part 2)

[Huacai Chen]

From: Jiaxun Yang 

LWC2 & SWC2 have been rewritten by Loongson EXT vendor ASE
as "load/store quad word" and "shifted load/store" groups of
instructions.

This patch add implementation of these instructions:
gslwlc1: similar to lwl but RT is FPR instead of GPR
gslwrc1: similar to lwr but RT is FPR instead of GPR
gsldlc1: similar to ldl but RT is FPR instead of GPR
gsldrc1: similar to ldr but RT is FPR instead of GPR
gsswlc1: similar to swl but RT is FPR instead of GPR
gsswrc1: similar to swr but RT is FPR instead of GPR
gssdlc1: similar to sdl but RT is FPR instead of GPR
gssdrc1: similar to sdr but RT is FPR instead of GPR

Details of Loongson-EXT is here:
https://github.com/FlyGoat/loongson-insn/blob/master/loongson-ext.md

Signed-off-by: Huacai Chen 
Signed-off-by: Jiaxun Yang 
---
 target/mips/translate.c | 177 
 1 file changed, 177 insertions(+)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index cb0adde310..916b57f293 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -471,6 +471,19 @@ enum {
 OPC_GSSHFS  = OPC_SWC2,
 };
 
+/* Loongson EXT shifted load/store opcodes */
+#define MASK_LOONGSON_GSSHFLS(op) (MASK_OP_MAJOR(op) | (op & 0xc03f))
+enum {
+OPC_GSLWLC1 = 0x4 | OPC_GSSHFL,
+OPC_GSLWRC1 = 0x5 | OPC_GSSHFL,
+OPC_GSLDLC1 = 0x6 | OPC_GSSHFL,
+OPC_GSLDRC1 = 0x7 | OPC_GSSHFL,
+OPC_GSSWLC1 = 0x4 | OPC_GSSHFS,
+OPC_GSSWRC1 = 0x5 | OPC_GSSHFS,
+OPC_GSSDLC1 = 0x6 | OPC_GSSHFS,
+OPC_GSSDRC1 = 0x7 | OPC_GSSHFS,
+};
+
 /* BSHFL opcodes */
 #define MASK_BSHFL(op)  (MASK_SPECIAL3(op) | (op & (0x1F << 6)))
 
@@ -5987,6 +6000,170 @@ static void gen_loongson_lswc2(DisasContext *ctx, int 
rt,
 tcg_temp_free(t1);
 break;
 #endif
+case OPC_GSSHFL:
+switch (MASK_LOONGSON_GSSHFLS(ctx->opcode)) {
+case OPC_GSLWLC1:
+check_cp1_enabled(ctx);
+gen_base_offset_addr(ctx, t0, rs, shf_offset);
+t1 = tcg_temp_new();
+tcg_gen_qemu_ld_tl(t1, t0, ctx->mem_idx, MO_UB);
+tcg_gen_andi_tl(t1, t0, 3);
+#ifndef TARGET_WORDS_BIGENDIAN
+tcg_gen_xori_tl(t1, t1, 3);
+#endif
+tcg_gen_shli_tl(t1, t1, 3);
+tcg_gen_andi_tl(t0, t0, ~3);
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEUL);
+tcg_gen_shl_tl(t0, t0, t1);
+t2 = tcg_const_tl(-1);
+tcg_gen_shl_tl(t2, t2, t1);
+fp0 = tcg_temp_new_i32();
+gen_load_fpr32(ctx, fp0, rt);
+tcg_gen_ext_i32_tl(t1, fp0);
+tcg_gen_andc_tl(t1, t1, t2);
+tcg_temp_free(t2);
+tcg_gen_or_tl(t0, t0, t1);
+tcg_temp_free(t1);
+#if defined(TARGET_MIPS64)
+tcg_gen_extrl_i64_i32(fp0, t0);
+#else
+tcg_gen_ext32s_tl(fp0, t0);
+#endif
+gen_store_fpr32(ctx, fp0, rt);
+tcg_temp_free_i32(fp0);
+break;
+case OPC_GSLWRC1:
+check_cp1_enabled(ctx);
+gen_base_offset_addr(ctx, t0, rs, shf_offset);
+t1 = tcg_temp_new();
+tcg_gen_qemu_ld_tl(t1, t0, ctx->mem_idx, MO_UB);
+tcg_gen_andi_tl(t1, t0, 3);
+#ifdef TARGET_WORDS_BIGENDIAN
+tcg_gen_xori_tl(t1, t1, 3);
+#endif
+tcg_gen_shli_tl(t1, t1, 3);
+tcg_gen_andi_tl(t0, t0, ~3);
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEUL);
+tcg_gen_shr_tl(t0, t0, t1);
+tcg_gen_xori_tl(t1, t1, 31);
+t2 = tcg_const_tl(0xfffeull);
+tcg_gen_shl_tl(t2, t2, t1);
+fp0 = tcg_temp_new_i32();
+gen_load_fpr32(ctx, fp0, rt);
+tcg_gen_ext_i32_tl(t1, fp0);
+tcg_gen_and_tl(t1, t1, t2);
+tcg_temp_free(t2);
+tcg_gen_or_tl(t0, t0, t1);
+tcg_temp_free(t1);
+#if defined(TARGET_MIPS64)
+tcg_gen_extrl_i64_i32(fp0, t0);
+#else
+tcg_gen_ext32s_tl(fp0, t0);
+#endif
+gen_store_fpr32(ctx, fp0, rt);
+tcg_temp_free_i32(fp0);
+break;
+#if defined(TARGET_MIPS64)
+case OPC_GSLDLC1:
+check_cp1_enabled(ctx);
+gen_base_offset_addr(ctx, t0, rs, shf_offset);
+t1 = tcg_temp_new();
+tcg_gen_qemu_ld_tl(t1, t0, ctx->mem_idx, MO_UB);
+tcg_gen_andi_tl(t1, t0, 7);
+#ifndef TARGET_WORDS_BIGENDIAN
+tcg_gen_xori_tl(t1, t1, 7);
+#endif
+tcg_gen_shli_tl(t1, t1, 3);
+tcg_gen_andi_tl(t0, t0, ~7);
+tcg_gen_qemu_ld_tl(t0, t0, ctx->mem_idx, MO_TEQ);
+tcg_gen_shl_tl(t0, t0, t1);
+t2 = tcg_const_tl(-1);
+tcg_gen_shl_tl(t2, t2, t1);
+gen_load_fpr64(ctx, t1, rt);
+tcg_gen_andc_tl(t1, t1, t2);
+tcg_temp_free(t2);
+tcg_gen_or_tl(t0, t0, t1);
+tcg_temp_free(t1);

Re: [PATCH v2 2/2] vhost-vdpa: add trace-events

[Jason Wang]

On 2020/9/21 下午9:04, Laurent Vivier wrote:

Add trace functionis in vhost-vdpa.c.

All traces from this file can be enabled with '-trace vhost_vdpa*'.

Acked-by: Stefan Hajnoczi 
Signed-off-by: Laurent Vivier 
---
  hw/virtio/trace-events | 29 ++
  hw/virtio/vhost-vdpa.c | 86 +++---
  2 files changed, 110 insertions(+), 5 deletions(-)

diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 845200bf109d..2b453f77a4e3 100644
--- a/hw/virtio/trace-events
+++ b/hw/virtio/trace-events
@@ -22,6 +22,35 @@ vhost_user_postcopy_waker(const char *rb, uint64_t rb_offset) "%s 
+ 0x%"PRIx64
  vhost_user_postcopy_waker_found(uint64_t client_addr) "0x%"PRIx64
  vhost_user_postcopy_waker_nomatch(const char *rb, uint64_t rb_offset) "%s + 
0x%"PRIx64
  
+# vhost-vdpa.c

+vhost_vdpa_listener_region_add(void *vdpa, uint64_t iova, uint64_t llend, void *vaddr, bool readonly) 
"vdpa: %p iova 0x%"PRIx64" llend 0x%"PRIx64" vaddr: %p read-only: %d"
+vhost_vdpa_listener_region_del(void *vdpa, uint64_t iova, uint64_t llend) "vdpa: %p iova 
0x%"PRIx64" llend 0x%"PRIx64
+vhost_vdpa_add_status(void *dev, uint8_t status) "dev: %p status: 0x%"PRIx8
+vhost_vdpa_init(void *dev, void *vdpa) "dev: %p vdpa: %p"
+vhost_vdpa_cleanup(void *dev, void *vdpa) "dev: %p vdpa: %p"
+vhost_vdpa_memslots_limit(void *dev, int ret) "dev: %p = 0x%x"
+vhost_vdpa_set_mem_table(void *dev, uint32_t nregions, uint32_t padding) "dev: %p nregions: 
%"PRIu32" padding: 0x%"PRIx32
+vhost_vdpa_dump_regions(void *dev, int i, uint64_t guest_phys_addr, uint64_t memory_size, uint64_t userspace_addr, 
uint64_t flags_padding) "dev: %p %d: guest_phys_addr: 0x%"PRIx64" memory_size: 0x%"PRIx64" 
userspace_addr: 0x%"PRIx64" flags_padding: 0x%"PRIx64
+vhost_vdpa_set_features(void *dev, uint64_t features) "dev: %p features: 
0x%"PRIx64
+vhost_vdpa_get_device_id(void *dev, uint32_t device_id) "dev: %p device_id 
%"PRIu32
+vhost_vdpa_reset_device(void *dev, uint8_t status) "dev: %p status: 0x%"PRIx8
+vhost_vdpa_get_vq_index(void *dev, int idx, int vq_idx) "dev: %p idx: %d vq idx: 
%d"
+vhost_vdpa_set_vring_ready(void *dev) "dev: %p"
+vhost_vdpa_dump_config(void *dev, const char *line) "dev: %p %s"
+vhost_vdpa_set_config(void *dev, uint32_t offset, uint32_t size, uint32_t flags) "dev: %p offset: 
%"PRIu32" size: %"PRIu32" flags: 0x%"PRIx32
+vhost_vdpa_get_config(void *dev, void *config, uint32_t config_len) "dev: %p 
config: %p config_len: %"PRIu32
+vhost_vdpa_dev_start(void *dev, bool started) "dev: %p started: %d"
+vhost_vdpa_set_log_base(void *dev, uint64_t base, unsigned long long size, int refcnt, int fd, 
void *log) "dev: %p base: 0x%"PRIx64" size: %llu refcnt: %d fd: %d log: %p"
+vhost_vdpa_set_vring_addr(void *dev, unsigned int index, unsigned int flags, uint64_t desc_user_addr, uint64_t 
used_user_addr, uint64_t avail_user_addr, uint64_t log_guest_addr) "dev: %p index: %u flags: 0x%x desc_user_addr: 
0x%"PRIx64" used_user_addr: 0x%"PRIx64" avail_user_addr: 0x%"PRIx64" log_guest_addr: 
0x%"PRIx64
+vhost_vdpa_set_vring_num(void *dev, unsigned int index, unsigned int num) "dev: %p 
index: %u num: %u"
+vhost_vdpa_set_vring_base(void *dev, unsigned int index, unsigned int num) "dev: %p 
index: %u num: %u"
+vhost_vdpa_get_vring_base(void *dev, unsigned int index, unsigned int num) "dev: %p 
index: %u num: %u"
+vhost_vdpa_set_vring_kick(void *dev, unsigned int index, int fd) "dev: %p index: %u 
fd: %d"
+vhost_vdpa_set_vring_call(void *dev, unsigned int index, int fd) "dev: %p index: %u 
fd: %d"



It's better to add set/get_vring_addr() and dma_map()/dma_unmap().

Thanks



+vhost_vdpa_get_features(void *dev, uint64_t features) "dev: %p features: 
0x%"PRIx64
+vhost_vdpa_set_owner(void *dev) "dev: %p"
+vhost_vdpa_vq_get_addr(void *dev, void *vq, uint64_t desc_user_addr, uint64_t avail_user_addr, uint64_t 
used_user_addr) "dev: %p vq: %p desc_user_addr: 0x%"PRIx64" avail_user_addr: 
0x%"PRIx64" used_user_addr: 0x%"PRIx64
+
  # virtio.c
  virtqueue_alloc_element(void *elem, size_t sz, unsigned in_num, unsigned out_num) 
"elem %p size %zd in_num %u out_num %u"
  virtqueue_fill(void *vq, const void *elem, unsigned int len, unsigned int idx) "vq 
%p elem %p len %u idx %u"
diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
index 4580f3efd8a2..dc987704dcd9 100644
--- a/hw/virtio/vhost-vdpa.c
+++ b/hw/virtio/vhost-vdpa.c
@@ -20,6 +20,8 @@
  #include "hw/virtio/vhost-vdpa.h"
  #include "qemu/main-loop.h"
  #include "cpu.h"
+#include "trace.h"
+#include "qemu-common.h"
  
  static bool vhost_vdpa_listener_skipped_section(MemoryRegionSection *section)

  {
@@ -114,6 +116,9 @@ static void vhost_vdpa_listener_region_add(MemoryListener 
*listener,
  section->offset_within_region +
  (iova - section->offset_within_address_space);
  
+trace_vhost_vdpa_listener_region_add(v, iova, int128_get64(llend),

+ vaddr, section->readonly);
+
  llsize = 

Re: [PATCH 3/3] net: Add vhost-vdpa in show_netdevs()

[Jason Wang]

On 2020/9/17 下午11:58, Cindy Lu wrote:

Fix the bug that while Check qemu supported netdev,
there is no vhost-vdpa

Signed-off-by: Cindy Lu 



Acked-by: Jason Wang 



---
  net/net.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/net/net.c b/net/net.c
index 7a2a0fb5ac..794c652282 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1049,6 +1049,9 @@ static void show_netdevs(void)
  #endif
  #ifdef CONFIG_POSIX
  "vhost-user",
+#endif
+#ifdef CONFIG_VHOST_VDPA
+"vhost-vdpa",
  #endif
  };
  

Re: [PATCH 2/3] vhost-vdpa: Add qemu_close in vhost_vdpa_cleanup

[Jason Wang]

On 2020/9/17 下午11:58, Cindy Lu wrote:

fix the bug that fd will still open after the cleanup

Signed-off-by: Cindy Lu 



Acked-by: Jason Wang 



---
  net/vhost-vdpa.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index bc0e0d2d35..0480b92102 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -144,6 +144,10 @@ static void vhost_vdpa_cleanup(NetClientState *nc)
  g_free(s->vhost_net);
  s->vhost_net = NULL;
  }
+ if (s->vhost_vdpa.device_fd >= 0) {
+qemu_close(s->vhost_vdpa.device_fd);
+s->vhost_vdpa.device_fd = -1;
+}
  }
  
  static bool vhost_vdpa_has_vnet_hdr(NetClientState *nc)

Re: [PATCH 1/3] virtio-net: Set mac address to hardware if the peer is vdpa

[Jason Wang]

On 2020/9/17 下午11:58, Cindy Lu wrote:

If the peer's type is vdpa,set the mac address to NIC in 
virtio_net_device_realize,
Also sometime vdpa get an all 0 macaddress from the hardware, this will cause 
the traffic down
So we add the check for this part.
if we get an 0 mac address we will use the default mac address instead

Signed-off-by: Cindy Lu 
---
  hw/net/virtio-net.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index cb0d27084c..7db9da1482 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -126,6 +126,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
uint8_t *config)
  VirtIONet *n = VIRTIO_NET(vdev);
  struct virtio_net_config netcfg;
  NetClientState *nc = qemu_get_queue(n->nic);
+static const MACAddr zero = { .a = { 0, 0, 0, 0, 0, 0 } };
  
  int ret = 0;

  memset(, 0 , sizeof(struct virtio_net_config));
@@ -151,7 +152,11 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
uint8_t *config)
  ret = vhost_net_get_config(get_vhost_net(nc->peer), (uint8_t 
*),
 n->config_size);
  if (ret != -1) {
-memcpy(config, , n->config_size);
+if (memcmp(, , sizeof(zero)) != 0) {
+memcpy(config, , n->config_size);
+} else {
+error_report("Get an all zero mac address from hardware");



This is probably a hint that MAC is not properly provisioned.

So I guess we can leave this as is, or simply warn until the management 
interface is finalized.




+}
  }
  }
  }
@@ -3399,6 +3404,11 @@ static void virtio_net_device_realize(DeviceState *dev, 
Error **errp)
  nc = qemu_get_queue(n->nic);
  nc->rxfilter_notify_enabled = 1;
  
+   if (nc->peer && nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) {

+struct virtio_net_config netcfg = {};
+memcpy(, >nic_conf.macaddr, ETH_ALEN);
+virtio_net_set_config(vdev, (uint8_t *));



Won't this overwrite all other fields in the netcfg? I think we should 
only touch mac part.


Thanks



+}
  QTAILQ_INIT(>rsc_chains);
  n->qdev = dev;
  

Re: [PATCH 00/24] qom: Convert some properties to class properties

[Li Qiang]

Eduardo Habkost  于2020年9月22日周二 上午6:11写道：
>
> Class properties make QOM introspection simpler and easier, as it
> doesn't require an object to be instantiated.  This series
> converts a few existing object_property_add*() calls to register
> class properties instead.
>

Hello Eduardo,

IIUC, most of the properties can be dev-spec or class-spec.
Do we have any principle or rule to specify the property to be dev or class?

Maybe if the property which is always the same between instances can
be a class-property?

Thanks,
Li Qiang



> Eduardo Habkost (24):
>   cryptodev-vhost-user: Register "chardev" as class property
>   cryptodev-backend: Register "chardev" as class property
>   rng-egd: Register "chardev" as class property
>   rng-random: register "filename" as class property
>   vhost-user: Register "chardev" as class property
>   vexpress: Register "secure" as class property
>   rng: Register "opened" as class property
>   vexpress-a15: Register "virtualization" as class property
>   input-linux: Register properties as class properties
>   input-barrier: Register properties as class properties
>   tmp421: Register properties as class properties
>   s390x: Register all CPU properties as class properties
>   i386: Register most CPU properties as class properties
>   i386: Register feature bit properties as class properties
>   arm/virt: Register most properties as class properties
>   virt: Register "its" as class property
>   cpu/core: Register core-id and nr-threads as class properties
>   arm/cpu64: Register "aarch64" as class property
>   xlnx-zcu102: Register properties as class properties
>   machine: Register "memory-backend" as class property
>   vga-pci: Register "big-endian-framebuffer" as class property
>   i440fx: Register i440FX-pcihost properties as class properties
>   sifive_e: Register "revb" as class property
>   sifive_u: Register "start-in-flash" as class property
>
>  target/s390x/internal.h |  1 -
>  backends/cryptodev-vhost-user.c | 13 ++---
>  backends/cryptodev.c|  8 +--
>  backends/rng-egd.c  |  9 +--
>  backends/rng-random.c   |  8 +--
>  backends/rng.c  |  8 +--
>  backends/vhost-user.c   |  6 +-
>  hw/arm/vexpress.c   | 25 +
>  hw/arm/virt.c   | 88 -
>  hw/arm/xlnx-zcu102.c| 25 +
>  hw/core/machine.c   | 12 ++--
>  hw/cpu/core.c   |  8 +--
>  hw/display/vga-pci.c| 12 ++--
>  hw/misc/tmp421.c| 30 +-
>  hw/pci-host/i440fx.c| 32 +--
>  hw/riscv/sifive_e.c | 11 ++--
>  hw/riscv/sifive_u.c | 16 +++---
>  target/arm/cpu64.c  | 16 ++
>  target/i386/cpu.c   | 99 +
>  target/s390x/cpu.c  |  1 -
>  target/s390x/cpu_models.c   | 35 ++--
>  ui/input-barrier.c  | 44 +++
>  ui/input-linux.c| 27 -
>  23 files changed, 262 insertions(+), 272 deletions(-)
>
> --
> 2.26.2
>
>

Re: [PATCH] hw: ide: check the pointer before do dma memory unmap

[Alexander Bulekov]

On 200815 0020, Li Qiang wrote:
> In 'map_page' we need to check the return value of
> 'dma_memory_map' to ensure the we actully maped something.
> Otherwise, we will hit an assert in 'address_space_unmap'.
> This is because we can't find the MR with the NULL buffer.
> This is the LP#1884693:
> 
> -->https://bugs.launchpad.net/qemu/+bug/1884693
> 
> Reported-by: Alexander Bulekov 
> Signed-off-by: Li Qiang 

I'm not very familiar with the IDE code, but this seems like a simple
null-ptr check, and Li has not received a response in over a month.

Reviewed-by: Alexander Bulekov 

> ---
>  hw/ide/ahci.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 009120f88b..63e9fccdbe 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -250,6 +250,11 @@ static void map_page(AddressSpace *as, uint8_t **ptr, 
> uint64_t addr,
>  }
>  
>  *ptr = dma_memory_map(as, addr, , DMA_DIRECTION_FROM_DEVICE);
> +
> +if (!*ptr) {
> +return;
> +}
> +
>  if (len < wanted) {
>  dma_memory_unmap(as, *ptr, len, DMA_DIRECTION_FROM_DEVICE, len);
>  *ptr = NULL;
> -- 
> 2.17.1
> 

RE: [PATCH 01/24] cryptodev-vhost-user: Register "chardev" as class property

[Gonglei (Arei)]

> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Tuesday, September 22, 2020 6:10 AM
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange
> ; John Snow ; Gonglei (Arei)
> 
> Subject: [PATCH 01/24] cryptodev-vhost-user: Register "chardev" as class
> property
> 
> Class properties make QOM introspection simpler and easier, as they don't
> require an object to be instantiated.
> 
> Signed-off-by: Eduardo Habkost 
> ---
> Cc: "Gonglei (Arei)" 
> Cc: qemu-devel@nongnu.org
> ---

Reviewed-by: Gonglei 

Regards,
-Gonglei

>  backends/cryptodev-vhost-user.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/backends/cryptodev-vhost-user.c
> b/backends/cryptodev-vhost-user.c index 41089dede15..690738c6c95
> 100644
> --- a/backends/cryptodev-vhost-user.c
> +++ b/backends/cryptodev-vhost-user.c
> @@ -336,13 +336,6 @@ cryptodev_vhost_user_get_chardev(Object *obj,
> Error **errp)
>  return NULL;
>  }
> 
> -static void cryptodev_vhost_user_instance_int(Object *obj) -{
> -object_property_add_str(obj, "chardev",
> -cryptodev_vhost_user_get_chardev,
> -cryptodev_vhost_user_set_chardev);
> -}
> -
>  static void cryptodev_vhost_user_finalize(Object *obj)  {
>  CryptoDevBackendVhostUser *s =
> @@ -363,13 +356,17 @@ cryptodev_vhost_user_class_init(ObjectClass *oc,
> void *data)
>  bc->create_session = cryptodev_vhost_user_sym_create_session;
>  bc->close_session = cryptodev_vhost_user_sym_close_session;
>  bc->do_sym_op = NULL;
> +
> +object_class_property_add_str(oc, "chardev",
> +  cryptodev_vhost_user_get_chardev,
> +  cryptodev_vhost_user_set_chardev);
> +
>  }
> 
>  static const TypeInfo cryptodev_vhost_user_info = {
>  .name = TYPE_CRYPTODEV_BACKEND_VHOST_USER,
>  .parent = TYPE_CRYPTODEV_BACKEND,
>  .class_init = cryptodev_vhost_user_class_init,
> -.instance_init = cryptodev_vhost_user_instance_int,
>  .instance_finalize = cryptodev_vhost_user_finalize,
>  .instance_size = sizeof(CryptoDevBackendVhostUser),
>  };
> --
> 2.26.2

RE: [PATCH 02/24] cryptodev-backend: Register "chardev" as class property

[Gonglei (Arei)]

> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Tuesday, September 22, 2020 6:10 AM
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange
> ; John Snow ; Gonglei (Arei)
> 
> Subject: [PATCH 02/24] cryptodev-backend: Register "chardev" as class
> property
> 
> Class properties make QOM introspection simpler and easier, as they don't
> require an object to be instantiated.
> 
> Signed-off-by: Eduardo Habkost 
> ---
> Cc: "Gonglei (Arei)" 
> Cc: qemu-devel@nongnu.org
> ---
>  backends/cryptodev.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

Reviewed-by: Gonglei 

Regards,
-Gonglei


> diff --git a/backends/cryptodev.c b/backends/cryptodev.c index
> ada4ebe78b1..3f141f61ed6 100644
> --- a/backends/cryptodev.c
> +++ b/backends/cryptodev.c
> @@ -206,10 +206,6 @@ cryptodev_backend_can_be_deleted(UserCreatable
> *uc)
> 
>  static void cryptodev_backend_instance_init(Object *obj)  {
> -object_property_add(obj, "queues", "uint32",
> -  cryptodev_backend_get_queues,
> -  cryptodev_backend_set_queues,
> -  NULL, NULL);
>  /* Initialize devices' queues property to 1 */
>  object_property_set_int(obj, "queues", 1, NULL);  } @@ -230,6 +226,10
> @@ cryptodev_backend_class_init(ObjectClass *oc, void *data)
>  ucc->can_be_deleted = cryptodev_backend_can_be_deleted;
> 
>  QTAILQ_INIT(_clients);
> +object_class_property_add(oc, "queues", "uint32",
> +  cryptodev_backend_get_queues,
> +  cryptodev_backend_set_queues,
> +  NULL, NULL);
>  }
> 
>  static const TypeInfo cryptodev_backend_info = {
> --
> 2.26.2

Re: [PATCH] migration: increase max-bandwidth to 128 MiB/s (1 Gib/s)

[David Gibson]

On Mon, Sep 21, 2020 at 04:49:57PM +0200, Laurent Vivier wrote:
> max-bandwidth is set by default to 32 MiB/s (256 Mib/s)
> since 2008 (5bb7910af031c).
> 
> Most of the CPUs can dirty memory faster than that now,
> and this is clearly a problem with POWER where the page
> size is 64 kiB and not 4 KiB.
> 
> Signed-off-by: Laurent Vivier 

Reviewed-by: David Gibson 

> ---
>  migration/migration.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 58a5452471f9..1c4174947181 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -57,7 +57,7 @@
>  #include "qemu/queue.h"
>  #include "multifd.h"
>  
> -#define MAX_THROTTLE  (32 << 20)  /* Migration transfer speed throttling 
> */
> +#define MAX_THROTTLE  (128 << 20)  /* Migration transfer speed 
> throttling */
>  
>  /* Amount of time to allocate to each "chunk" of bandwidth-throttled
>   * data. */

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


signature.asc
Description: PGP signature

Re: [PATCH] hw: ide: check the pointer before do dma memory unmap

[Li Qiang]

Ping!!

Li Qiang  于2020年9月15日周二 下午9:38写道：
>
> ping!!
>
> Li Qiang  于2020年9月7日周一 上午9:39写道：
> >
> > Ping!
> >
> > Li Qiang  于2020年9月1日周二 下午6:34写道：
> > >
> > > Ping.
> > >
> > > Li Qiang  于2020年8月15日周六 下午3:21写道：
> > > >
> > > > In 'map_page' we need to check the return value of
> > > > 'dma_memory_map' to ensure the we actully maped something.
> > > > Otherwise, we will hit an assert in 'address_space_unmap'.
> > > > This is because we can't find the MR with the NULL buffer.
> > > > This is the LP#1884693:
> > > >
> > > > -->https://bugs.launchpad.net/qemu/+bug/1884693
> > > >
> > > > Reported-by: Alexander Bulekov 
> > > > Signed-off-by: Li Qiang 
> > > > ---
> > > >  hw/ide/ahci.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> > > > index 009120f88b..63e9fccdbe 100644
> > > > --- a/hw/ide/ahci.c
> > > > +++ b/hw/ide/ahci.c
> > > > @@ -250,6 +250,11 @@ static void map_page(AddressSpace *as, uint8_t 
> > > > **ptr, uint64_t addr,
> > > >  }
> > > >
> > > >  *ptr = dma_memory_map(as, addr, , DMA_DIRECTION_FROM_DEVICE);
> > > > +
> > > > +if (!*ptr) {
> > > > +return;
> > > > +}
> > > > +
> > > >  if (len < wanted) {
> > > >  dma_memory_unmap(as, *ptr, len, DMA_DIRECTION_FROM_DEVICE, 
> > > > len);
> > > >  *ptr = NULL;
> > > > --
> > > > 2.17.1
> > > >

[PULL 0/1] bitmaps patches for 2020-09-21

[Eric Blake]

The following changes since commit 5df6c87e8080e0021e975c8387baa20cfe43c932:

  Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' 
into staging (2020-09-21 17:41:32 +0100)

are available in the Git repository at:

  https://repo.or.cz/qemu/ericb.git tags/pull-bitmaps-2020-09-21

for you to fetch changes up to 14f16bf9474c860ecc127a66a86961942319f7af:

  qemu-img: Support bitmap --merge into backing image (2020-09-21 17:01:09 
-0500)


bitmaps patches for 2020-09-21

- Eric Blake: Improve 'qemu-img bitmap --merge' by not opening backing images


Eric Blake (1):
  qemu-img: Support bitmap --merge into backing image

 qemu-img.c | 11 ++---
 tests/qemu-iotests/291 | 12 ++
 tests/qemu-iotests/291.out | 56 ++
 3 files changed, 76 insertions(+), 3 deletions(-)
The following changes since commit 5df6c87e8080e0021e975c8387baa20cfe43c932:

  Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' 
into staging (2020-09-21 17:41:32 +0100)

are available in the Git repository at:

  https://repo.or.cz/qemu/ericb.git tags/pull-bitmaps-2020-09-21

for you to fetch changes up to 14f16bf9474c860ecc127a66a86961942319f7af:

  qemu-img: Support bitmap --merge into backing image (2020-09-21 17:01:09 
-0500)


bitmaps patches for 2020-09-21

- Eric Blake: Improve 'qemu-img bitmap --merge' by not opening backing images


Eric Blake (1):
  qemu-img: Support bitmap --merge into backing image

 qemu-img.c | 11 ++---
 tests/qemu-iotests/291 | 12 ++
 tests/qemu-iotests/291.out | 56 ++
 3 files changed, 76 insertions(+), 3 deletions(-)

-- 
2.28.0

[PULL 1/1] qemu-img: Support bitmap --merge into backing image

[Eric Blake]

If you have the chain 'base.qcow2 <- top.qcow2' and want to merge a
bitmap from top into base, qemu-img was failing with:

qemu-img: Could not open 'top.qcow2': Could not open backing file: Failed to 
get shared "write" lock
Is another process using the image [base.qcow2]?

The easiest fix is to not open the entire backing chain of either
image (source or destination); after all, the point of 'qemu-img
bitmap' is solely to manipulate bitmaps directly within a single qcow2
image, and this is made more precise if we don't pay attention to
other images in the chain that may happen to have a bitmap by the same
name.

However, note that on a case-by-case analysis, there _are_ times where
we treat it as a feature that we can access a bitmap from a backing
layer in association with an overlay BDS.  A demonstration of this is
using NBD to expose both an overlay BDS (for constant contents) and a
bitmap (for learning which blocks are interesting) during an
incremental backup:

Base <- Active <- Temporary
  \--block job ->/

where Temporary is being fed by a backup 'sync=none' job.  When
exposing Temporary over NBD, referring to a bitmap that lives only in
Active is less effort than having to copy a bitmap into Temporary [1].
So the testsuite additions in this patch check both where bitmaps get
allocated (the qemu-img info output), and that qemu-nbd is indeed able
to access a bitmap inherited from the backing chain since it is a
different use case than 'qemu-img bitmap'.

[1] Full disclosure: prior to the recent commit 374eedd1c4 and
friends, we were NOT able to see bitmaps through filters, which meant
that we actually did not have nice clean semantics for uniformly being
able to pick up bitmaps from anywhere in the backing chain (seen as a
change in behavior between qemu 4.1 and 4.2 at commit 00e30f05de, when
block-copy swapped from a one-off to a filter).  Which means libvirt
was already coded to copy bitmaps around for the sake of older qemu,
even though modern qemu no longer needs it.  Oh well.

Fixes: http://bugzilla.redhat.com/1877209
Reported-by: Eyal Shenitzky 
Signed-off-by: Eric Blake 
Message-Id: <20200914191009.644842-1-ebl...@redhat.com>
[eblake: more commit message tweaks, per Max Reitz review]
Reviewed-by: Max Reitz 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 qemu-img.c | 11 ++--
 tests/qemu-iotests/291 | 12 
 tests/qemu-iotests/291.out | 56 ++
 3 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index 1d8c5cd778c0..d79c6ffa2e49 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -4779,14 +4779,19 @@ static int img_bitmap(int argc, char **argv)
 filename = argv[optind];
 bitmap = argv[optind + 1];

-blk = img_open(image_opts, filename, fmt, BDRV_O_RDWR, false, false,
-   false);
+/*
+ * No need to open backing chains; we will be manipulating bitmaps
+ * directly in this image without reference to image contents.
+ */
+blk = img_open(image_opts, filename, fmt, BDRV_O_RDWR | BDRV_O_NO_BACKING,
+   false, false, false);
 if (!blk) {
 goto out;
 }
 bs = blk_bs(blk);
 if (src_filename) {
-src = img_open(false, src_filename, src_fmt, 0, false, false, false);
+src = img_open(false, src_filename, src_fmt, BDRV_O_NO_BACKING,
+   false, false, false);
 if (!src) {
 goto out;
 }
diff --git a/tests/qemu-iotests/291 b/tests/qemu-iotests/291
index 1e0bb76959bb..4f837b205655 100755
--- a/tests/qemu-iotests/291
+++ b/tests/qemu-iotests/291
@@ -91,6 +91,15 @@ $QEMU_IMG bitmap --remove --image-opts \
 driver=$IMGFMT,file.driver=file,file.filename="$TEST_IMG" tmp
 _img_info --format-specific

+echo
+echo "=== Merge from top layer into backing image ==="
+echo
+
+$QEMU_IMG rebase -u -F qcow2 -b "$TEST_IMG.base" "$TEST_IMG"
+$QEMU_IMG bitmap --add --merge b2 -b "$TEST_IMG" -F $IMGFMT \
+ -f $IMGFMT "$TEST_IMG.base" b3
+_img_info --format-specific --backing-chain
+
 echo
 echo "=== Check bitmap contents ==="
 echo
@@ -107,6 +116,9 @@ $QEMU_IMG map --output=json --image-opts \
 nbd_server_start_unix_socket -r -f qcow2 -B b2 "$TEST_IMG"
 $QEMU_IMG map --output=json --image-opts \
 "$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b2" | _filter_qemu_img_map
+nbd_server_start_unix_socket -r -f qcow2 -B b3 "$TEST_IMG"
+$QEMU_IMG map --output=json --image-opts \
+"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b3" | _filter_qemu_img_map

 # success, all done
 echo '*** done'
diff --git a/tests/qemu-iotests/291.out b/tests/qemu-iotests/291.out
index ee89a728855f..3990f7aacc7b 100644
--- a/tests/qemu-iotests/291.out
+++ b/tests/qemu-iotests/291.out
@@ -68,6 +68,59 @@ Format specific information:
 corrupt: false
 extended l2: false

+=== Merge from top layer into backing image ===
+
+image: TEST_DIR/t.IMGFMT
+file format: IMGFMT
+virtual size: 10 MiB (10485760 bytes)

Re: [PATCH v5 4/7] tests/qtest/libqos/virtio-blk: add support for vhost-user-blk

[Dima Stepanov]

On Mon, Sep 21, 2020 at 07:04:20PM -0400, Raphael Norwitz wrote:
> MST already sent a PR with all the patches :)

Thank you! )

> 
> On Wed, Sep 16, 2020 at 6:13 PM Dima Stepanov  wrote:
> >
> > On Mon, Sep 14, 2020 at 09:23:42PM -0400, Raphael Norwitz wrote:
> > > On Fri, Sep 11, 2020 at 4:43 AM Dima Stepanov  
> > > wrote:
> > > >
> > > > Add support for the vhost-user-blk-pci device. This node can be used by
> > > > the vhost-user-blk tests. Tests for the vhost-user-blk device are added
> > > > in the following patches.
> > > >
> > > > Signed-off-by: Dima Stepanov 
> > >
> > > Reviewed-by: Raphael Norwitz 
> > Hi,
> >
> > Looks like that all the patch set is reviewed except 7/7. If it is an
> > issue, we can cut it from the set and merge other six commits.
> >
> > Raphael,
> >
> > Will you take it for merge?
> >
> > Thanks, Dima.
> >
> > >
> > > > ---
> > > >  tests/qtest/libqos/virtio-blk.c | 14 +-
> > > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/tests/qtest/libqos/virtio-blk.c 
> > > > b/tests/qtest/libqos/virtio-blk.c
> > > > index 5da0259..c0fd9d2 100644
> > > > --- a/tests/qtest/libqos/virtio-blk.c
> > > > +++ b/tests/qtest/libqos/virtio-blk.c
> > > > @@ -30,7 +30,8 @@
> > > >  static void *qvirtio_blk_get_driver(QVirtioBlk *v_blk,
> > > >  const char *interface)
> > > >  {
> > > > -if (!g_strcmp0(interface, "virtio-blk")) {
> > > > +if (!g_strcmp0(interface, "virtio-blk") ||
> > > > +!g_strcmp0(interface, "vhost-user-blk")) {
> > > >  return v_blk;
> > > >  }
> > > >  if (!g_strcmp0(interface, "virtio")) {
> > > > @@ -120,6 +121,17 @@ static void virtio_blk_register_nodes(void)
> > > >  qos_node_produces("virtio-blk-pci", "virtio-blk");
> > > >
> > > >  g_free(arg);
> > > > +
> > > > +/* vhost-user-blk-pci */
> > > > +arg = g_strdup_printf("id=drv0,chardev=chdev0,addr=%x.%x",
> > > > +PCI_SLOT, PCI_FN);
> > > > +opts.extra_device_opts = arg;
> > > > +add_qpci_address(, );
> > > > +qos_node_create_driver("vhost-user-blk-pci", 
> > > > virtio_blk_pci_create);
> > > > +qos_node_consumes("vhost-user-blk-pci", "pci-bus", );
> > > > +qos_node_produces("vhost-user-blk-pci", "vhost-user-blk");
> > > > +
> > > > +g_free(arg);
> > > >  }
> > > >
> > > >  libqos_init(virtio_blk_register_nodes);
> > > > --
> > > > 2.7.4
> > > >
> > > >

Re: [PATCH v4 00/11] capstone + disassembler patches

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200921174118.39352-1-richard.hender...@linaro.org/



Hi,

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

Type: series
Message-id: 20200921174118.39352-1-richard.hender...@linaro.org
Subject: [PATCH v4 00/11] capstone + disassembler patches

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
3d764d3 disas/capstone: Add skipdata hook for s390x
04c1cfa disas: Enable capstone disassembly for s390x
93a2da5 disas: Split out capstone code to disas/capstone.c
d29736e disas: Configure capstone for aarch64 host without libvixl
f283959 disas: Cleanup plugin_disas
b3a548e disas: Use qemu/bswap.h for bfd endian loads
1b6e185 disas: Clean up CPUDebug initialization
3b1f6f9 disas: Move host asm annotations to tb_gen_code
856507e capstone: Require version 4.0 from a system library
a714c28 capstone: Update to upstream "next" branch
823a3e2 capstone: Convert Makefile bits to meson bits

=== OUTPUT BEGIN ===
1/11 Checking commit 823a3e2a9f3c (capstone: Convert Makefile bits to meson 
bits)
2/11 Checking commit a714c28917da (capstone: Update to upstream "next" branch)
3/11 Checking commit 856507eedce4 (capstone: Require version 4.0 from a system 
library)
4/11 Checking commit 3b1f6f9ca3a0 (disas: Move host asm annotations to 
tb_gen_code)
5/11 Checking commit 1b6e185eee3e (disas: Clean up CPUDebug initialization)
WARNING: Block comments use a trailing */ on a separate line
#73: FILE: disas.c:48:
+   an error return from {host,target}_read_memory.  */

ERROR: code indent should never use tabs
#91: FILE: disas.c:58:
+^I^I^I   "Address 0x%" PRIx64 " is out of bounds.\n",$

WARNING: architecture specific defines should be avoided
#203: FILE: disas.c:479:
+#if defined(_ILP32) || (__riscv_xlen == 32)

total: 1 errors, 2 warnings, 490 lines checked

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

6/11 Checking commit b3a548e1996e (disas: Use qemu/bswap.h for bfd endian loads)
7/11 Checking commit f2839591e583 (disas: Cleanup plugin_disas)
8/11 Checking commit d29736e11366 (disas: Configure capstone for aarch64 host 
without libvixl)
9/11 Checking commit 93a2da58d997 (disas: Split out capstone code to 
disas/capstone.c)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#309: 
new file mode 100644

total: 0 errors, 1 warnings, 604 lines checked

Patch 9/11 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
10/11 Checking commit 04c1cfa18ca8 (disas: Enable capstone disassembly for 
s390x)
11/11 Checking commit 3d764d3d1e7b (disas/capstone: Add skipdata hook for s390x)
=== OUTPUT END ===

Test command exited with code: 1


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

Re: [PATCH] xen: xenguest is not used so is not needed

[Stefano Stabellini]

Adding Paul


On Sat, 19 Sep 2020, Philippe Mathieu-Daudé wrote:
> Cc'ing qemu-trivial@
> 
> On 7/27/20 5:09 PM, Anthony PERARD wrote:
> > On Mon, Jul 27, 2020 at 05:00:48PM +0300, Michael Tokarev wrote:
> >> There's no references in only file which includes xenguest.h
> >> to any xen definitions. And there's no references to -lxenguest
> >> in qemu, either. Drop it.
> > 
> > I'm not sure what you mean by "no references to -lxenguest", do you mean
> > in the binary?
> > 
> >> Signed-off-by: Michael Tokarev 
> > 
> > Otherwise, thanks for the cleanup!
> > 
> > Reviewed-by: Anthony PERARD 
> > 
> 

Re: [PATCH v2] target/i386: Remove core_id assert check in CPUID 0x8000001E

[Eduardo Habkost]

On Mon, Sep 21, 2020 at 05:47:28PM -0500, Babu Moger wrote:
> With x2apic enabled, configurations can have more that 255 cores.
> Noticed the device add test is hitting an assert when during cpu
> hotplug with core_id > 255. This is due to assert check in the
> CPUID 0x801E.
> 
> Remove the assert check and fix the problem.
> 
> Fixes the bug:
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1834200
> 
> Signed-off-by: Babu Moger 

Queued, thanks!

> ---
> v2:
>   Resubmitting an old patch which was lost in the mix.
>   Just rebased on the latest tree.
> v1:
>   
> https://lore.kernel.org/qemu-devel/159257395689.52908.4409314503988289481.st...@naples-babu.amd.com/
> 
>  target/i386/cpu.c |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1c58f764dc..4f1d62c838 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5912,9 +5912,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  }
>  break;
>  case 0x801E:
> -assert(cpu->core_id <= 255);
> -encode_topo_cpuid801e(cpu, _info,
> -  eax, ebx, ecx, edx);
> +if (cpu->core_id <= 255) {
> +encode_topo_cpuid801e(cpu, _info, eax, ebx, ecx, edx);
> +} else {
> +*eax = 0;
> +*ebx = 0;
> +*ecx = 0;
> +*edx = 0;
> +}
>  break;
>  case 0xC000:
>  *eax = env->cpuid_xlevel2;
> 

-- 
Eduardo

Re: [RFC PATCH 3/6] hw/sd/sdcard: Do not use legal address '0' for INVALID_ADDRESS

[Kevin O'Connor]

On Mon, Sep 21, 2020 at 12:31:21PM +0200, Philippe Mathieu-Daudé wrote:
> Back to the SDcard, it might be less critical, so a migration
> breaking change might be acceptable. I'm only aware of Paolo
> and Kevin using this device for testing. Not sure of its
> importance in production.

FWIW, I only use the sdcard for testing (and only use sdhci-pci).  I
don't know if others use it in production, however.

Cheers,
-Kevin

Re: [PATCH] migration: Truncate state file in xen-save-devices-state

[Stefano Stabellini]

Adding Paul


On Mon, 21 Sep 2020, Dr. David Alan Gilbert wrote:
> * Dov Murik (dovmu...@linux.vnet.ibm.com) wrote:
> > 
> > 
> > On 21/09/2020 14:17, Dr. David Alan Gilbert wrote:
> > > * Dov Murik (dovmu...@linux.vnet.ibm.com) wrote:
> > > > When running the xen-save-devices-state QMP command, if the filename
> > > > already exists it will be truncated before dumping the devices' state
> > > > into it.
> > > > 
> > > > Signed-off-by: Dov Murik 
> > > > ---
> > > 
> > > OK, that looks fine to me, so:
> > > 
> > > Reviewed-by: Dr. David Alan Gilbert 
> > > 
> > > > 
> > > > Note that I found the above issue while trying to debug
> > > > xen-load-devices-state which simply fails (prints "Configuration section
> > > > missing" to stderr) directly after xen-save-devices-state (in the same
> > > > VM).  I wonder if I should file a bug report as-is or investigate some
> > > > more.  Advice welcome.
> > > 
> > > I don't try the xen-* commands normally; I've cc'ing in Stefano and
> > > Anthony.
> > 
> > Thanks Dave.  Just to be clear, I'm running this without Xen at all; but
> > these commands seem to work OK for dumping/restoring guest's devices
> > state (without RAM) -- if I modify the code to circumvent the mentioned
> > problem.
> 
> Yeh, although you can't rely on them not doing something Xen in the
> future.  There are a few other similar ways of doing what you want; eg.
> if your RAM is 'shared' then you can set the x-ignore-shared migration
> capability.
> 
> Dave
> 
> > Dov
> > 
> > > 
> > > Dave
> > > 
> > > > 
> > > > -Dov
> > > > 
> > > > ---
> > > >   migration/savevm.c | 3 ++-
> > > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/migration/savevm.c b/migration/savevm.c
> > > > index 304d98ff78..e1b26672cc 100644
> > > > --- a/migration/savevm.c
> > > > +++ b/migration/savevm.c
> > > > @@ -2803,7 +2803,8 @@ void qmp_xen_save_devices_state(const char 
> > > > *filename, bool has_live, bool live,
> > > >   vm_stop(RUN_STATE_SAVE_VM);
> > > >   global_state_store_running();
> > > > -ioc = qio_channel_file_new_path(filename, O_WRONLY | O_CREAT, 
> > > > 0660, errp);
> > > > +ioc = qio_channel_file_new_path(filename, O_WRONLY | O_CREAT | 
> > > > O_TRUNC,
> > > > +0660, errp);
> > > >   if (!ioc) {
> > > >   goto the_end;
> > > >   }
> > > > -- 
> > > > 2.20.1
> > > > 
> > 
> -- 
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> 

Re: [PATCH 6/6] travis.yml: Drop the superfluous Python 3.6 build

[Cleber Rosa]

On Fri, Sep 18, 2020 at 12:34:30PM +0200, Thomas Huth wrote:
> Python 3.6 is already the default Python in the jobs that are based
> on Ubuntu Bionic, so it does not make much sense to test this again
> separately.
> 
> Signed-off-by: Thomas Huth 
> ---
>  .travis.yml | 8 
>  1 file changed, 8 deletions(-)
>

Reviewed-by: Cleber Rosa 


signature.asc
Description: PGP signature

Re: [PATCH 5/6] travis.yml: Update Travis to use Bionic and Focal instead of Xenial

[Cleber Rosa]

On Fri, Sep 18, 2020 at 12:34:29PM +0200, Thomas Huth wrote:
> According to our support policy, we do not support Xenial anymore.
> Time to switch the bigger parts of the builds to Focal instead.
> Some few jobs have to be updated to Bionic instead, since they are
> currently still failing on Focal otherwise. Also "--disable-pie" is
> causing linker problems with newer versions of Ubuntu ... so remove
> that switch from the jobs now (we still test it in a gitlab CI job,
> so we don't lose much test coverage here).
> 
> Signed-off-by: Thomas Huth 
> ---
>  .travis.yml | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 1fc49b0746..80da4ebc8e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -2,7 +2,7 @@
>  # Additional builds with specific requirements for a full VM need to
>  # be added as additional matrix: entries later on
>  os: linux
> -dist: xenial
> +dist: focal
>  language: c
>  compiler:
>- gcc
> @@ -10,7 +10,7 @@ cache:
># There is one cache per branch and compiler version.
># characteristics of each job are used to identify the cache:
># - OS name (currently only linux)
> -  # - OS distribution (for Linux, xenial, trusty, or precise)
> +  # - OS distribution (for Linux, bionic or focal)
># - Names and values of visible environment variables set in .travis.yml 
> or Settings panel
>timeout: 1200
>ccache: true
> @@ -27,7 +27,7 @@ addons:
>- libattr1-dev
>- libbrlapi-dev
>- libcap-ng-dev
> -  - libgcc-4.8-dev
> +  - libgcc-7-dev
>- libgnutls28-dev
>- libgtk-3-dev
>- libiscsi-dev
> @@ -211,8 +211,10 @@ jobs:
>  
>  # gprof/gcov are GCC features
>  - name: "GCC gprof/gcov"
> +  dist: bionic
>env:
> -- CONFIG="--enable-gprof --enable-gcov --disable-pie 
> --target-list=${MAIN_SOFTMMU_TARGETS}"
> +- CONFIG="--enable-gprof --enable-gcov --disable-libssh
> +  --target-list=${MAIN_SOFTMMU_TARGETS}"

While the commit message describes the reason for dropping
'--disable-pie', it doesn't talk about why it adds '--disable-libssh'.
Other than that, it's working fine, according to:

  https://travis-ci.org/github/clebergnu/qemu/builds/729121964

Reviewed-by: Cleber Rosa 
Tested-by: Cleber Rosa 


signature.asc
Description: PGP signature

Re: [PATCH v5 4/7] tests/qtest/libqos/virtio-blk: add support for vhost-user-blk

[Raphael Norwitz]

MST already sent a PR with all the patches :)

On Wed, Sep 16, 2020 at 6:13 PM Dima Stepanov  wrote:
>
> On Mon, Sep 14, 2020 at 09:23:42PM -0400, Raphael Norwitz wrote:
> > On Fri, Sep 11, 2020 at 4:43 AM Dima Stepanov  
> > wrote:
> > >
> > > Add support for the vhost-user-blk-pci device. This node can be used by
> > > the vhost-user-blk tests. Tests for the vhost-user-blk device are added
> > > in the following patches.
> > >
> > > Signed-off-by: Dima Stepanov 
> >
> > Reviewed-by: Raphael Norwitz 
> Hi,
>
> Looks like that all the patch set is reviewed except 7/7. If it is an
> issue, we can cut it from the set and merge other six commits.
>
> Raphael,
>
> Will you take it for merge?
>
> Thanks, Dima.
>
> >
> > > ---
> > >  tests/qtest/libqos/virtio-blk.c | 14 +-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tests/qtest/libqos/virtio-blk.c 
> > > b/tests/qtest/libqos/virtio-blk.c
> > > index 5da0259..c0fd9d2 100644
> > > --- a/tests/qtest/libqos/virtio-blk.c
> > > +++ b/tests/qtest/libqos/virtio-blk.c
> > > @@ -30,7 +30,8 @@
> > >  static void *qvirtio_blk_get_driver(QVirtioBlk *v_blk,
> > >  const char *interface)
> > >  {
> > > -if (!g_strcmp0(interface, "virtio-blk")) {
> > > +if (!g_strcmp0(interface, "virtio-blk") ||
> > > +!g_strcmp0(interface, "vhost-user-blk")) {
> > >  return v_blk;
> > >  }
> > >  if (!g_strcmp0(interface, "virtio")) {
> > > @@ -120,6 +121,17 @@ static void virtio_blk_register_nodes(void)
> > >  qos_node_produces("virtio-blk-pci", "virtio-blk");
> > >
> > >  g_free(arg);
> > > +
> > > +/* vhost-user-blk-pci */
> > > +arg = g_strdup_printf("id=drv0,chardev=chdev0,addr=%x.%x",
> > > +PCI_SLOT, PCI_FN);
> > > +opts.extra_device_opts = arg;
> > > +add_qpci_address(, );
> > > +qos_node_create_driver("vhost-user-blk-pci", virtio_blk_pci_create);
> > > +qos_node_consumes("vhost-user-blk-pci", "pci-bus", );
> > > +qos_node_produces("vhost-user-blk-pci", "vhost-user-blk");
> > > +
> > > +g_free(arg);
> > >  }
> > >
> > >  libqos_init(virtio_blk_register_nodes);
> > > --
> > > 2.7.4
> > >
> > >

Re: [PATCH] vhost-blk: set features before setting inflight feature

[Raphael Norwitz]

I see your point - all the open source backends I could find which
support VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD rely on knowing the vq
type to allocate the fd.

That said, it looks like dpdk supports both
VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD and packed vqs without needing
such an API 
https://github.com/DPDK/dpdk/blob/main/lib/librte_vhost/vhost_user.c#L1509.
I'm not sure exactly how the VQ state is sent to DPDK before the
inflight fd negotiation, but ideally vhost-user-blk could be made to
work the same way. Maybe someone with more vhost-net and dpdk
knowledge could chime in on how vhost-net backends do it?

On Mon, Sep 14, 2020 at 10:52 PM Yu, Jin  wrote:
>
> > -Original Message-
> > From: Raphael Norwitz 
> > Sent: Tuesday, September 15, 2020 9:25 AM
> > To: Yu, Jin 
> > Cc: Michael S. Tsirkin ; Raphael Norwitz
> > ; Kevin Wolf ; Max
> > Reitz ; QEMU 
> > Subject: Re: [PATCH] vhost-blk: set features before setting inflight feature
> >
> > Backends already receive the format in vhost_dev_start before the memory
> > tables are set or any of the virtqueues are started. Can you elaborate on 
> > why
> > you need to know the virtqueue format before setting the inflight FD?
> >
> First, when the backend receives the get_inflight_fd sent by QEMU, it needs 
> to allocate vq's inflight memory,
> and it needs to know the format of vq.
> Second, when the backend reconnects to QEMU, QEMU sends set_inflight_fd, and 
> the backend restores the inflight memory of vq.
> It also needs to know the format of vq.
> Thanks.
> > On Thu, Sep 10, 2020 at 2:15 AM Jin Yu  wrote:
> > >
> > > Virtqueue has split and packed, so before setting inflight, you need
> > > to inform the back-end virtqueue format.
> > >
> > > Signed-off-by: Jin Yu 
> > > ---
> > >  hw/block/vhost-user-blk.c |  6 ++
> > >  hw/virtio/vhost.c | 18 ++
> > >  include/hw/virtio/vhost.h |  1 +
> > >  3 files changed, 25 insertions(+)
> > >
> > > diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> > > index 39aec42dae..9e0e9ebec0 100644
> > > --- a/hw/block/vhost-user-blk.c
> > > +++ b/hw/block/vhost-user-blk.c
> > > @@ -131,6 +131,12 @@ static int vhost_user_blk_start(VirtIODevice
> > > *vdev)
> > >
> > >  s->dev.acked_features = vdev->guest_features;
> > >
> > > +ret = vhost_dev_prepare_inflight(>dev);
> > > +if (ret < 0) {
> > > +error_report("Error set inflight format: %d", -ret);
> > > +goto err_guest_notifiers;
> > > +}
> > > +
> > >  if (!s->inflight->addr) {
> > >  ret = vhost_dev_get_inflight(>dev, s->queue_size, 
> > > s->inflight);
> > >  if (ret < 0) {
> > > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c index
> > > 1a1384e7a6..4027c11886 100644
> > > --- a/hw/virtio/vhost.c
> > > +++ b/hw/virtio/vhost.c
> > > @@ -1616,6 +1616,24 @@ int vhost_dev_load_inflight(struct vhost_inflight
> > *inflight, QEMUFile *f)
> > >  return 0;
> > >  }
> > >
> > > +int vhost_dev_prepare_inflight(struct vhost_dev *hdev) {
> > > +int r;
> > > +
> > > +if (hdev->vhost_ops->vhost_get_inflight_fd == NULL ||
> > > +hdev->vhost_ops->vhost_set_inflight_fd == NULL) {
> > > +return 0;
> > > +}
> > > +
> > > +r = vhost_dev_set_features(hdev, hdev->log_enabled);
> > > +if (r < 0) {
> > > +VHOST_OPS_DEBUG("vhost_dev_prepare_inflight failed");
> > > +return r;
> > > +}
> > > +
> > > +return 0;
> > > +}
> > > +
> > >  int vhost_dev_set_inflight(struct vhost_dev *dev,
> > > struct vhost_inflight *inflight)  { diff
> > > --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h index
> > > 767a95ec0b..4e2fc75528 100644
> > > --- a/include/hw/virtio/vhost.h
> > > +++ b/include/hw/virtio/vhost.h
> > > @@ -140,6 +140,7 @@ void vhost_dev_reset_inflight(struct
> > > vhost_inflight *inflight);  void vhost_dev_free_inflight(struct
> > > vhost_inflight *inflight);  void vhost_dev_save_inflight(struct
> > > vhost_inflight *inflight, QEMUFile *f);  int
> > > vhost_dev_load_inflight(struct vhost_inflight *inflight, QEMUFile *f);
> > > +int vhost_dev_prepare_inflight(struct vhost_dev *hdev);
> > >  int vhost_dev_set_inflight(struct vhost_dev *dev,
> > > struct vhost_inflight *inflight);  int
> > > vhost_dev_get_inflight(struct vhost_dev *dev, uint16_t queue_size,
> > > --
> > > 2.17.2
> > >
> > >

[PATCH v2] target/i386: Remove core_id assert check in CPUID 0x8000001E

[Babu Moger]

With x2apic enabled, configurations can have more that 255 cores.
Noticed the device add test is hitting an assert when during cpu
hotplug with core_id > 255. This is due to assert check in the
CPUID 0x801E.

Remove the assert check and fix the problem.

Fixes the bug:
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1834200

Signed-off-by: Babu Moger 
---
v2:
  Resubmitting an old patch which was lost in the mix.
  Just rebased on the latest tree.
v1:
  
https://lore.kernel.org/qemu-devel/159257395689.52908.4409314503988289481.st...@naples-babu.amd.com/

 target/i386/cpu.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1c58f764dc..4f1d62c838 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5912,9 +5912,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
 }
 break;
 case 0x801E:
-assert(cpu->core_id <= 255);
-encode_topo_cpuid801e(cpu, _info,
-  eax, ebx, ecx, edx);
+if (cpu->core_id <= 255) {
+encode_topo_cpuid801e(cpu, _info, eax, ebx, ecx, edx);
+} else {
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+}
 break;
 case 0xC000:
 *eax = env->cpuid_xlevel2;

[PATCH 22/24] i440fx: Register i440FX-pcihost properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: "Michael S. Tsirkin" 
Cc: Marcel Apfelbaum 
Cc: qemu-devel@nongnu.org
---
 hw/pci-host/i440fx.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index 93c62235ca7..4454ba06621 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -212,22 +212,6 @@ static void i440fx_pcihost_initfn(Object *obj)
   "pci-conf-idx", 4);
 memory_region_init_io(>data_mem, obj, _host_data_le_ops, s,
   "pci-conf-data", 4);
-
-object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
-i440fx_pcihost_get_pci_hole_start,
-NULL, NULL, NULL);
-
-object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32",
-i440fx_pcihost_get_pci_hole_end,
-NULL, NULL, NULL);
-
-object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64",
-i440fx_pcihost_get_pci_hole64_start,
-NULL, NULL, NULL);
-
-object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64",
-i440fx_pcihost_get_pci_hole64_end,
-NULL, NULL, NULL);
 }
 
 static void i440fx_pcihost_realize(DeviceState *dev, Error **errp)
@@ -403,6 +387,22 @@ static void i440fx_pcihost_class_init(ObjectClass *klass, 
void *data)
 device_class_set_props(dc, i440fx_props);
 /* Reason: needs to be wired up by pc_init1 */
 dc->user_creatable = false;
+
+object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
+  i440fx_pcihost_get_pci_hole_start,
+  NULL, NULL, NULL);
+
+object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_END, "uint32",
+  i440fx_pcihost_get_pci_hole_end,
+  NULL, NULL, NULL);
+
+object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_START, "uint64",
+  i440fx_pcihost_get_pci_hole64_start,
+  NULL, NULL, NULL);
+
+object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_END, "uint64",
+  i440fx_pcihost_get_pci_hole64_end,
+  NULL, NULL, NULL);
 }
 
 static const TypeInfo i440fx_pcihost_info = {
-- 
2.26.2

[PATCH 23/24] sifive_e: Register "revb" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Palmer Dabbelt 
Cc: Alistair Francis 
Cc: Sagar Karandikar 
Cc: Bastian Koppelmann 
Cc: qemu-ri...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/riscv/sifive_e.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index 40bbf530d49..9fe0c12df64 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -137,11 +137,6 @@ static void sifive_e_machine_instance_init(Object *obj)
 SiFiveEState *s = RISCV_E_MACHINE(obj);
 
 s->revb = false;
-object_property_add_bool(obj, "revb", sifive_e_machine_get_revb,
- sifive_e_machine_set_revb);
-object_property_set_description(obj, "revb",
-"Set on to tell QEMU that it should model "
-"the revB HiFive1 board");
 }
 
 static void sifive_e_machine_class_init(ObjectClass *oc, void *data)
@@ -152,6 +147,12 @@ static void sifive_e_machine_class_init(ObjectClass *oc, 
void *data)
 mc->init = sifive_e_machine_init;
 mc->max_cpus = 1;
 mc->default_cpu_type = SIFIVE_E_CPU;
+
+object_class_property_add_bool(oc, "revb", sifive_e_machine_get_revb,
+   sifive_e_machine_set_revb);
+object_class_property_set_description(oc, "revb",
+  "Set on to tell QEMU that it should 
model "
+  "the revB HiFive1 board");
 }
 
 static const TypeInfo sifive_e_machine_typeinfo = {
-- 
2.26.2

[PATCH 19/24] xlnx-zcu102: Register properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Alistair Francis 
Cc: "Edgar E. Iglesias" 
Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/arm/xlnx-zcu102.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index 19d5a4d4e0e..4deb96bfcc1 100644
--- a/hw/arm/xlnx-zcu102.c
+++ b/hw/arm/xlnx-zcu102.c
@@ -208,20 +208,8 @@ static void xlnx_zcu102_machine_instance_init(Object *obj)
 
 /* Default to secure mode being disabled */
 s->secure = false;
-object_property_add_bool(obj, "secure", zcu102_get_secure,
- zcu102_set_secure);
-object_property_set_description(obj, "secure",
-"Set on/off to enable/disable the ARM "
-"Security Extensions (TrustZone)");
-
 /* Default to virt (EL2) being disabled */
 s->virt = false;
-object_property_add_bool(obj, "virtualization", zcu102_get_virt,
- zcu102_set_virt);
-object_property_set_description(obj, "virtualization",
-"Set on/off to enable/disable emulating a "
-"guest CPU which implements the ARM "
-"Virtualization Extensions");
 }
 
 static void xlnx_zcu102_machine_class_init(ObjectClass *oc, void *data)
@@ -237,6 +225,19 @@ static void xlnx_zcu102_machine_class_init(ObjectClass 
*oc, void *data)
 mc->max_cpus = XLNX_ZYNQMP_NUM_APU_CPUS + XLNX_ZYNQMP_NUM_RPU_CPUS;
 mc->default_cpus = XLNX_ZYNQMP_NUM_APU_CPUS;
 mc->default_ram_id = "ddr-ram";
+
+object_class_property_add_bool(oc, "secure", zcu102_get_secure,
+   zcu102_set_secure);
+object_class_property_set_description(oc, "secure",
+  "Set on/off to enable/disable the 
ARM "
+  "Security Extensions (TrustZone)");
+
+object_class_property_add_bool(oc, "virtualization", zcu102_get_virt,
+   zcu102_set_virt);
+object_class_property_set_description(oc, "virtualization",
+  "Set on/off to enable/disable 
emulating a "
+  "guest CPU which implements the ARM "
+  "Virtualization Extensions");
 }
 
 static const TypeInfo xlnx_zcu102_machine_init_typeinfo = {
-- 
2.26.2

Re: [PATCH 0/3] Hyper-V Dynamic Memory Protocol driver (hv-balloon)

[Maciej S. Szmigiero]

Hi David,

Thank you for your comments.

First, I want to underline that this driver targets Windows guests,
where ability to modify and adapt the guest memory management
code is extremely limited.

While it does work with Linux guests, too, this is definitely not its
native environment.

It also has to support rather big guests, up to 1 TB of RAM, so
performance-related things are important.

Further answers are bellow.

On 21.09.2020 11:10, David Hildenbrand wrote:
> On 20.09.20 15:25, Maciej S. Szmigiero wrote:
>> From: "Maciej S. Szmigiero" 
>>
>> This series adds a Hyper-V Dynamic Memory Protocol driver (hv-balloon)
>> and its protocol definitions.
>> Also included is a driver providing backing devices for memory hot-add
>> protocols ("haprots").
>>
>> A haprot device works like a virtual DIMM stick: it allows inserting
>> extra RAM into the guest at run time.
>>
>> The main differences from the ACPI-based PC DIMM hotplug are:
>> * Notifying the guest about the new memory range is not done via ACPI but
>> via a protocol handler that registers with the haprot framework.
>> This means that the ACPI DIMM slot limit does not apply.
>>
>> * A protocol handler can prevent removal of a haprot device when it is
>> still in use by setting its "busy" field.
>>
>> * A protocol handler can also register an "unplug" callback so it gets
>> notified when an user decides to remove the haprot device.
>> This way the protocol handler can inform the guest about this fact and / or
>> do its own cleanup.
>>
>> The hv-balloon driver is like virtio-balloon on steroids: it allows both
>> changing the guest memory allocation via ballooning and inserting extra
>> RAM into it by adding haprot virtual DIMM sticks.
>> One of advantages of these over ACPI-based PC DIMM hotplug is that such
>> memory can be hotplugged in much smaller granularity because the ACPI DIMM
>> slot limit does not apply.
> 
> Reading further below, it's essentially DIMM-based memory hotplug +
> virtio-balloon - except the 256MB DIMM limit. But reading below, I don't
> see how you want to avoid the KVM memory slot limit that's in a similar
> size (I recall 256*2 due to 2 address spaces). 

The idea is to use virtual DIMM sticks for hot-adding extra memory at
runtime, while using ballooning for runtime adjustment of the guest
memory size within the current maximum.

When the guest is rebooted the virtual DIMMs configuration is adjusted
by the software controlling QEMU (some are removed and / or some are
added) to give the guest the same effective memory size as it had before
the reboot.

So, yes, it will be a problem if the user expands their running guest
~256 times, each time making it even bigger than previously, without
rebooting it even once, but this does seem to be an edge use case.

In the future it would be better to automatically turn the current
effective guest size into its boot memory size when the VM restarts
(the VM will then have no virtual DIMMs inserted after a reboot), but
doing this requires quite a few changes to QEMU, that's why it isn't
there yet.

The above is basically how Hyper-V hypervisor handles its memory size
changes and it seems to be as close to having a transparently resizable
guest as reasonably possible.


> Or avoid VMA limits when wanting to grow a VM big in very tiny steps over
> time (e.g., adding 64MB at a time).

Not sure if you are taking about VMA limits inside the host or the guest.
>>
>> In contrast with ACPI DIMM hotplug where one can only request to unplug a
>> whole DIMM stick this driver allows removing memory from guest in single
>> page (4k) units via ballooning.
>> Then, once the guest has released the whole memory backed by a haprot
>> virtual DIMM stick such device is marked "unused" and can be removed from
>> the VM, if one wants so.
>> A "HV_BALLOON_HAPROT_UNUSED" QMP event is emitted in this case so the
>> software controlling QEMU knows that this operation is now possible.
>>
>> The haprot devices are also marked unused after a VM reboot (with a
>> corresponding "HV_BALLOON_HAPROT_UNUSED" QMP event).
>> They are automatically reinserted (if still present) after the guest
>> reconnects to this protocol (a "HV_BALLOON_HAPROT_INUSE" QMP event is then
>> emitted).
>>
>> For performance reasons, the guest-released memory is tracked in few range
>> trees, as a series of (start, count) ranges.
>> Each time a new page range is inserted into such tree its neighbors are
>> checked as candidates for possible merging with it.
>>
>> Besides performance reasons, the Dynamic Memory protocol itself uses page
>> ranges as the data structure in its messages, so relevant pages need to be
>> merged into such ranges anyway.
>>
>> One has to be careful when tracking the guest-released pages, since the
>> guest can maliciously report returning pages outside its current address
>> space, which later clash with the address range of newly added memory.
>> Similarly, the guest can report freeing the same page twice.
>>
>> The 

[PATCH 21/24] vga-pci: Register "big-endian-framebuffer" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Gerd Hoffmann 
Cc: qemu-devel@nongnu.org
---
 hw/display/vga-pci.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c
index 3b45fa3bad0..b2a7d03c5d5 100644
--- a/hw/display/vga-pci.c
+++ b/hw/display/vga-pci.c
@@ -269,13 +269,6 @@ static void pci_std_vga_realize(PCIDevice *dev, Error 
**errp)
 }
 }
 
-static void pci_std_vga_init(Object *obj)
-{
-/* Expose framebuffer byteorder via QOM */
-object_property_add_bool(obj, "big-endian-framebuffer",
- vga_get_big_endian_fb, vga_set_big_endian_fb);
-}
-
 static void pci_secondary_vga_realize(PCIDevice *dev, Error **errp)
 {
 PCIVGAState *d = PCI_VGA(dev);
@@ -388,6 +381,10 @@ static void vga_class_init(ObjectClass *klass, void *data)
 k->class_id = PCI_CLASS_DISPLAY_VGA;
 device_class_set_props(dc, vga_pci_properties);
 dc->hotpluggable = false;
+
+/* Expose framebuffer byteorder via QOM */
+object_class_property_add_bool(klass, "big-endian-framebuffer",
+   vga_get_big_endian_fb, 
vga_set_big_endian_fb);
 }
 
 static void secondary_class_init(ObjectClass *klass, void *data)
@@ -405,7 +402,6 @@ static void secondary_class_init(ObjectClass *klass, void 
*data)
 static const TypeInfo vga_info = {
 .name  = "VGA",
 .parent= TYPE_PCI_VGA,
-.instance_init = pci_std_vga_init,
 .class_init= vga_class_init,
 };
 
-- 
2.26.2

[PATCH 14/24] i386: Register feature bit properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 
Cc: qemu-devel@nongnu.org
---
 target/i386/cpu.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 66792f28ba7..1aba87e0a5b 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6819,16 +6819,17 @@ static void x86_cpu_release_bit_prop(Object *obj, const 
char *name,
  * multiple bits in the same FeatureWord. In that case, the getter will return
  * true only if all bits are set.
  */
-static void x86_cpu_register_bit_prop(X86CPU *cpu,
+static void x86_cpu_register_bit_prop(X86CPUClass *xcc,
   const char *prop_name,
   FeatureWord w,
   int bitnr)
 {
+ObjectClass *oc = OBJECT_CLASS(xcc);
 BitProperty *fp;
 ObjectProperty *op;
 uint64_t mask = (1ULL << bitnr);
 
-op = object_property_find(OBJECT(cpu), prop_name, NULL);
+op = object_class_property_find(oc, prop_name, NULL);
 if (op) {
 fp = op->opaque;
 assert(fp->w == w);
@@ -6837,14 +6838,14 @@ static void x86_cpu_register_bit_prop(X86CPU *cpu,
 fp = g_new0(BitProperty, 1);
 fp->w = w;
 fp->mask = mask;
-object_property_add(OBJECT(cpu), prop_name, "bool",
-x86_cpu_get_bit_prop,
-x86_cpu_set_bit_prop,
-x86_cpu_release_bit_prop, fp);
+object_class_property_add(oc, prop_name, "bool",
+  x86_cpu_get_bit_prop,
+  x86_cpu_set_bit_prop,
+  x86_cpu_release_bit_prop, fp);
 }
 }
 
-static void x86_cpu_register_feature_bit_props(X86CPU *cpu,
+static void x86_cpu_register_feature_bit_props(X86CPUClass *xcc,
FeatureWord w,
int bitnr)
 {
@@ -6863,7 +6864,7 @@ static void x86_cpu_register_feature_bit_props(X86CPU 
*cpu,
 /* aliases don't use "|" delimiters anymore, they are registered
  * manually using object_property_add_alias() */
 assert(!strchr(name, '|'));
-x86_cpu_register_bit_prop(cpu, name, w, bitnr);
+x86_cpu_register_bit_prop(xcc, name, w, bitnr);
 }
 
 #if !defined(CONFIG_USER_ONLY)
@@ -6917,7 +6918,6 @@ static void x86_cpu_initfn(Object *obj)
 X86CPU *cpu = X86_CPU(obj);
 X86CPUClass *xcc = X86_CPU_GET_CLASS(obj);
 CPUX86State *env = >env;
-FeatureWord w;
 
 env->nr_dies = 1;
 cpu_set_cpustate_pointers(cpu);
@@ -6929,14 +6929,6 @@ static void x86_cpu_initfn(Object *obj)
 x86_cpu_get_feature_words,
 NULL, NULL, (void *)cpu->filtered_features);
 
-for (w = 0; w < FEATURE_WORDS; w++) {
-int bitnr;
-
-for (bitnr = 0; bitnr < 64; bitnr++) {
-x86_cpu_register_feature_bit_props(cpu, w, bitnr);
-}
-}
-
 object_property_add_alias(obj, "sse3", obj, "pni");
 object_property_add_alias(obj, "pclmuldq", obj, "pclmulqdq");
 object_property_add_alias(obj, "sse4-1", obj, "sse4.1");
@@ -7221,6 +7213,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
 X86CPUClass *xcc = X86_CPU_CLASS(oc);
 CPUClass *cc = CPU_CLASS(oc);
 DeviceClass *dc = DEVICE_CLASS(oc);
+FeatureWord w;
 
 device_class_set_parent_realize(dc, x86_cpu_realizefn,
 >parent_realize);
@@ -7310,6 +7303,12 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
   x86_cpu_get_crash_info_qom, NULL, NULL, NULL);
 #endif
 
+for (w = 0; w < FEATURE_WORDS; w++) {
+int bitnr;
+for (bitnr = 0; bitnr < 64; bitnr++) {
+x86_cpu_register_feature_bit_props(xcc, w, bitnr);
+}
+}
 }
 
 static const TypeInfo x86_cpu_type_info = {
-- 
2.26.2

[PATCH 20/24] machine: Register "memory-backend" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Eduardo Habkost 
Cc: Marcel Apfelbaum 
Cc: qemu-devel@nongnu.org
---
 hw/core/machine.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index ea26d612374..675ca6d651c 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -874,6 +874,12 @@ static void machine_class_init(ObjectClass *oc, void *data)
 machine_get_memory_encryption, machine_set_memory_encryption);
 object_class_property_set_description(oc, "memory-encryption",
 "Set memory encryption object to use");
+
+object_class_property_add_str(oc, "memory-backend",
+  machine_get_memdev, machine_set_memdev);
+object_class_property_set_description(oc, "memory-backend",
+  "Set RAM backend"
+  "Valid value is ID of hostmem based 
backend");
 }
 
 static void machine_class_base_init(ObjectClass *oc, void *data)
@@ -925,12 +931,6 @@ static void machine_initfn(Object *obj)
 "Table (HMAT)");
 }
 
-object_property_add_str(obj, "memory-backend",
-machine_get_memdev, machine_set_memdev);
-object_property_set_description(obj, "memory-backend",
-"Set RAM backend"
-"Valid value is ID of hostmem based 
backend");
-
 /* Register notifier when init is done for sysbus sanity checks */
 ms->sysbus_notifier.notify = machine_init_notify;
 qemu_add_machine_init_done_notifier(>sysbus_notifier);
-- 
2.26.2

[PATCH 17/24] cpu/core: Register core-id and nr-threads as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: qemu-devel@nongnu.org
---
 hw/cpu/core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/cpu/core.c b/hw/cpu/core.c
index 3a659291eae..92d3b2fbad6 100644
--- a/hw/cpu/core.c
+++ b/hw/cpu/core.c
@@ -69,10 +69,6 @@ static void cpu_core_instance_init(Object *obj)
 MachineState *ms = MACHINE(qdev_get_machine());
 CPUCore *core = CPU_CORE(obj);
 
-object_property_add(obj, "core-id", "int", core_prop_get_core_id,
-core_prop_set_core_id, NULL, NULL);
-object_property_add(obj, "nr-threads", "int", core_prop_get_nr_threads,
-core_prop_set_nr_threads, NULL, NULL);
 core->nr_threads = ms->smp.threads;
 }
 
@@ -81,6 +77,10 @@ static void cpu_core_class_init(ObjectClass *oc, void *data)
 DeviceClass *dc = DEVICE_CLASS(oc);
 
 set_bit(DEVICE_CATEGORY_CPU, dc->categories);
+object_class_property_add(oc, "core-id", "int", core_prop_get_core_id,
+  core_prop_set_core_id, NULL, NULL);
+object_class_property_add(oc, "nr-threads", "int", 
core_prop_get_nr_threads,
+  core_prop_set_nr_threads, NULL, NULL);
 }
 
 static const TypeInfo cpu_core_type_info = {
-- 
2.26.2

[PATCH 12/24] s390x: Register all CPU properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Cornelia Huck 
Cc: Thomas Huth 
Cc: Richard Henderson 
Cc: David Hildenbrand 
Cc: Halil Pasic 
Cc: Christian Borntraeger 
Cc: qemu-s3...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 target/s390x/internal.h   |  1 -
 target/s390x/cpu.c|  1 -
 target/s390x/cpu_models.c | 35 ---
 3 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/target/s390x/internal.h b/target/s390x/internal.h
index b1e0ebf67f8..bac0d3c67b2 100644
--- a/target/s390x/internal.h
+++ b/target/s390x/internal.h
@@ -260,7 +260,6 @@ static inline void s390_cpu_unhalt(S390CPU *cpu)
 
 
 /* cpu_models.c */
-void s390_cpu_model_register_props(Object *obj);
 void s390_cpu_model_class_register_props(ObjectClass *oc);
 void s390_realize_cpu_model(CPUState *cs, Error **errp);
 ObjectClass *s390_cpu_class_by_name(const char *name);
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 749cd548f0f..1dc45ca11b9 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -302,7 +302,6 @@ static void s390_cpu_initfn(Object *obj)
 timer_new_ns(QEMU_CLOCK_VIRTUAL, s390x_cpu_timer, cpu);
 s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
 #endif
-s390_cpu_model_register_props(obj);
 }
 
 static void s390_cpu_finalize(Object *obj)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index c2af2261743..b97e9596ab0 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -1089,25 +1089,6 @@ static void set_feature_group(Object *obj, Visitor *v, 
const char *name,
 }
 }
 
-void s390_cpu_model_register_props(Object *obj)
-{
-S390FeatGroup group;
-S390Feat feat;
-
-for (feat = 0; feat < S390_FEAT_MAX; feat++) {
-const S390FeatDef *def = s390_feat_def(feat);
-object_property_add(obj, def->name, "bool", get_feature,
-set_feature, NULL, (void *) feat);
-object_property_set_description(obj, def->name, def->desc);
-}
-for (group = 0; group < S390_FEAT_GROUP_MAX; group++) {
-const S390FeatGroupDef *def = s390_feat_group_def(group);
-object_property_add(obj, def->name, "bool", get_feature_group,
-set_feature_group, NULL, (void *) group);
-object_property_set_description(obj, def->name, def->desc);
-}
-}
-
 static void s390_cpu_model_initfn(Object *obj)
 {
 S390CPU *cpu = S390_CPU(obj);
@@ -1215,11 +1196,27 @@ static char *get_description(Object *obj, Error **errp)
 
 void s390_cpu_model_class_register_props(ObjectClass *oc)
 {
+S390FeatGroup group;
+S390Feat feat;
+
 object_class_property_add_bool(oc, "migration-safe", get_is_migration_safe,
NULL);
 object_class_property_add_bool(oc, "static", get_is_static,
NULL);
 object_class_property_add_str(oc, "description", get_description, NULL);
+
+for (feat = 0; feat < S390_FEAT_MAX; feat++) {
+const S390FeatDef *def = s390_feat_def(feat);
+object_class_property_add(oc, def->name, "bool", get_feature,
+  set_feature, NULL, (void *) feat);
+object_class_property_set_description(oc, def->name, def->desc);
+}
+for (group = 0; group < S390_FEAT_GROUP_MAX; group++) {
+const S390FeatGroupDef *def = s390_feat_group_def(group);
+object_class_property_add(oc, def->name, "bool", get_feature_group,
+  set_feature_group, NULL, (void *) group);
+object_class_property_set_description(oc, def->name, def->desc);
+}
 }
 
 #ifdef CONFIG_KVM
-- 
2.26.2

Re: [PATCH v3] SEV: QMP support for Inject-Launch-Secret

[Tom Lendacky]

On 9/21/20 3:33 PM, Tobin Feldman-Fitzthum wrote:
> On 2020-09-21 15:16, Dr. David Alan Gilbert wrote:
>> * Tobin Feldman-Fitzthum (to...@linux.vnet.ibm.com) wrote:
>>> AMD SEV allows a guest owner to inject a secret blob
>>> into the memory of a virtual machine. The secret is
>>> encrypted with the SEV Transport Encryption Key and
>>> integrity is guaranteed with the Transport Integrity
>>> Key. Although QEMU faciliates the injection of the
>>> launch secret, it cannot access the secret.
>>>
>>> Signed-off-by: Tobin Feldman-Fitzthum 
>>
>> Hi Tobin,
>>   Did the ovmf stuff for agreeing the GUID for automating this ever
>> happen?
>>
> OVMF patches have not been upstreamed yet. I think we are planning
> to do that relatively soon.

The SEV-ES code was recently accepted and uses a GUID for locating SEV
related information. You can probably build upon that GUID or stack
another GUID above that. The GUID block has a size indicator that can help
determine what information is available or for tracking stacked GUIDs.

https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847

Thanks,
Tom

> 
> -Tobin
>> Dave
>>
>>> ---
>>>  include/monitor/monitor.h |  3 ++
>>>  include/sysemu/sev.h  |  2 ++
>>>  monitor/misc.c    |  8 ++---
>>>  qapi/misc-target.json | 18 +++
>>>  target/i386/monitor.c |  9 ++
>>>  target/i386/sev-stub.c    |  5 +++
>>>  target/i386/sev.c | 66 +++
>>>  target/i386/trace-events  |  1 +
>>>  8 files changed, 108 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
>>> index 1018d754a6..bf049c5b00 100644
>>> --- a/include/monitor/monitor.h
>>> +++ b/include/monitor/monitor.h
>>> @@ -4,6 +4,7 @@
>>>  #include "block/block.h"
>>>  #include "qapi/qapi-types-misc.h"
>>>  #include "qemu/readline.h"
>>> +#include "include/exec/hwaddr.h"
>>>
>>>  extern __thread Monitor *cur_mon;
>>>  typedef struct MonitorHMP MonitorHMP;
>>> @@ -36,6 +37,8 @@ void monitor_flush(Monitor *mon);
>>>  int monitor_set_cpu(int cpu_index);
>>>  int monitor_get_cpu_index(void);
>>>
>>> +void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, uint64_t size, Error
>>> **errp);
>>> +
>>>  void monitor_read_command(MonitorHMP *mon, int show_prompt);
>>>  int monitor_read_password(MonitorHMP *mon, ReadLineFunc *readline_func,
>>>    void *opaque);
>>> diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
>>> index 98c1ec8d38..b279b293e8 100644
>>> --- a/include/sysemu/sev.h
>>> +++ b/include/sysemu/sev.h
>>> @@ -18,4 +18,6 @@
>>>
>>>  void *sev_guest_init(const char *id);
>>>  int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
>>> +int sev_inject_launch_secret(const char *hdr, const char *secret,
>>> + uint64_t gpa);
>>>  #endif
>>> diff --git a/monitor/misc.c b/monitor/misc.c
>>> index 89bb970b00..b9ec8ba410 100644
>>> --- a/monitor/misc.c
>>> +++ b/monitor/misc.c
>>> @@ -674,10 +674,10 @@ static void hmp_physical_memory_dump(Monitor
>>> *mon, const QDict *qdict)
>>>  memory_dump(mon, count, format, size, addr, 1);
>>>  }
>>>
>>> -static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
>>> +void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, uint64_t size, Error
>>> **errp)
>>>  {
>>>  MemoryRegionSection mrs = memory_region_find(get_system_memory(),
>>> - addr, 1);
>>> + addr, size);
>>>
>>>  if (!mrs.mr) {
>>>  error_setg(errp, "No memory is mapped at address 0x%"
>>> HWADDR_PRIx, addr);
>>> @@ -701,7 +701,7 @@ static void hmp_gpa2hva(Monitor *mon, const QDict
>>> *qdict)
>>>  MemoryRegion *mr = NULL;
>>>  void *ptr;
>>>
>>> -    ptr = gpa2hva(, addr, _err);
>>> +    ptr = gpa2hva(, addr, 1, _err);
>>>  if (local_err) {
>>>  error_report_err(local_err);
>>>  return;
>>> @@ -777,7 +777,7 @@ static void hmp_gpa2hpa(Monitor *mon, const QDict
>>> *qdict)
>>>  void *ptr;
>>>  uint64_t physaddr;
>>>
>>> -    ptr = gpa2hva(, addr, _err);
>>> +    ptr = gpa2hva(, addr, 1, _err);
>>>  if (local_err) {
>>>  error_report_err(local_err);
>>>  return;
>>> diff --git a/qapi/misc-target.json b/qapi/misc-target.json
>>> index dee3b45930..d145f916b3 100644
>>> --- a/qapi/misc-target.json
>>> +++ b/qapi/misc-target.json
>>> @@ -200,6 +200,24 @@
>>>  { 'command': 'query-sev-capabilities', 'returns': 'SevCapability',
>>>    'if': 'defined(TARGET_I386)' }
>>>
>>> +##
>>> +# @sev-inject-launch-secret:
>>> +#
>>> +# This command injects a secret blob into memory of SEV guest.
>>> +#
>>> +# @packet-header: the launch secret packet header encoded in base64
>>> +#
>>> +# @secret: the launch secret data to be injected encoded in base64
>>> +#
>>> +# @gpa: the guest physical address where secret will be injected.
>>> +#
>>> +# Since: 5.1
>>> +#
>>> +##
>>> +{ 'command': 

[PATCH 24/24] sifive_u: Register "start-in-flash" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Palmer Dabbelt 
Cc: Alistair Francis 
Cc: Sagar Karandikar 
Cc: Bastian Koppelmann 
Cc: qemu-ri...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/riscv/sifive_u.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 4f12a93188d..0f0fab9a47b 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -568,14 +568,6 @@ static void sifive_u_machine_instance_init(Object *obj)
 SiFiveUState *s = RISCV_U_MACHINE(obj);
 
 s->start_in_flash = false;
-object_property_add_bool(obj, "start-in-flash",
- sifive_u_machine_get_start_in_flash,
- sifive_u_machine_set_start_in_flash);
-object_property_set_description(obj, "start-in-flash",
-"Set on to tell QEMU's ROM to jump to "
-"flash. Otherwise QEMU will jump to DRAM "
-"or L2LIM depending on the msel value");
-
 s->msel = 0;
 object_property_add(obj, "msel", "uint32",
 sifive_u_machine_get_uint32_prop,
@@ -599,6 +591,14 @@ static void sifive_u_machine_class_init(ObjectClass *oc, 
void *data)
 mc->max_cpus = SIFIVE_U_MANAGEMENT_CPU_COUNT + SIFIVE_U_COMPUTE_CPU_COUNT;
 mc->min_cpus = SIFIVE_U_MANAGEMENT_CPU_COUNT + 1;
 mc->default_cpus = mc->min_cpus;
+
+object_class_property_add_bool(oc, "start-in-flash",
+   sifive_u_machine_get_start_in_flash,
+   sifive_u_machine_set_start_in_flash);
+object_class_property_set_description(oc, "start-in-flash",
+  "Set on to tell QEMU's ROM to jump 
to "
+  "flash. Otherwise QEMU will jump to 
DRAM "
+  "or L2LIM depending on the msel 
value");
 }
 
 static const TypeInfo sifive_u_machine_typeinfo = {
-- 
2.26.2

[PATCH 08/24] vexpress-a15: Register "virtualization" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/arm/vexpress.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index 0cc35749d7d..13339302af5 100644
--- a/hw/arm/vexpress.c
+++ b/hw/arm/vexpress.c
@@ -769,12 +769,6 @@ static void vexpress_a15_instance_init(Object *obj)
  * but can also be specifically set to on or off.
  */
 vms->virt = true;
-object_property_add_bool(obj, "virtualization", vexpress_get_virt,
- vexpress_set_virt);
-object_property_set_description(obj, "virtualization",
-"Set on/off to enable/disable the ARM "
-"Virtualization Extensions "
-"(defaults to same as 'secure')");
 }
 
 static void vexpress_a9_instance_init(Object *obj)
@@ -822,6 +816,14 @@ static void vexpress_a15_class_init(ObjectClass *oc, void 
*data)
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
 
 vmc->daughterboard = _daughterboard;
+
+object_class_property_add_bool(oc, "virtualization", vexpress_get_virt,
+   vexpress_set_virt);
+object_class_property_set_description(oc, "virtualization",
+  "Set on/off to enable/disable the 
ARM "
+  "Virtualization Extensions "
+  "(defaults to same as 'secure')");
+
 }
 
 static const TypeInfo vexpress_info = {
-- 
2.26.2

[PATCH 04/24] rng-random: register "filename" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Laurent Vivier 
Cc: Amit Shah 
Cc: qemu-devel@nongnu.org
---
 backends/rng-random.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/backends/rng-random.c b/backends/rng-random.c
index 245b12ab245..7add272eddd 100644
--- a/backends/rng-random.c
+++ b/backends/rng-random.c
@@ -108,10 +108,6 @@ static void rng_random_init(Object *obj)
 {
 RngRandom *s = RNG_RANDOM(obj);
 
-object_property_add_str(obj, "filename",
-rng_random_get_filename,
-rng_random_set_filename);
-
 s->filename = g_strdup("/dev/urandom");
 s->fd = -1;
 }
@@ -134,6 +130,10 @@ static void rng_random_class_init(ObjectClass *klass, void 
*data)
 
 rbc->request_entropy = rng_random_request_entropy;
 rbc->opened = rng_random_opened;
+object_class_property_add_str(klass, "filename",
+  rng_random_get_filename,
+  rng_random_set_filename);
+
 }
 
 static const TypeInfo rng_random_info = {
-- 
2.26.2

[PATCH 16/24] virt: Register "its" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Note: "its" is currently registered conditionally, but this makes
the feature be registered unconditionally.  The only side effect
is that it will be now possible to set its=on on virt-2.7 and
older.

Signed-off-by: Eduardo Habkost 
---
Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/arm/virt.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index d1ab660fa60..986b75a6b89 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2484,6 +2484,13 @@ static void virt_machine_class_init(ObjectClass *oc, 
void *data)
   "Set on/off to enable/disable 
emulating a "
   "guest CPU which implements the ARM "
   "Memory Tagging Extension");
+
+object_class_property_add_bool(oc, "its", virt_get_its,
+   virt_set_its);
+object_class_property_set_description(oc, "its",
+  "Set on/off to enable/disable "
+  "ITS instantiation");
+
 }
 
 static void virt_instance_init(Object *obj)
@@ -2511,11 +2518,6 @@ static void virt_instance_init(Object *obj)
 } else {
 /* Default allows ITS instantiation */
 vms->its = true;
-object_property_add_bool(obj, "its", virt_get_its,
- virt_set_its);
-object_property_set_description(obj, "its",
-"Set on/off to enable/disable "
-"ITS instantiation");
 }
 
 /* Default disallows iommu instantiation */
-- 
2.26.2

[PATCH 11/24] tmp421: Register properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: qemu-devel@nongnu.org
---
 hw/misc/tmp421.c | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/hw/misc/tmp421.c b/hw/misc/tmp421.c
index 212d6e0e831..1c19a3a9713 100644
--- a/hw/misc/tmp421.c
+++ b/hw/misc/tmp421.c
@@ -340,22 +340,6 @@ static void tmp421_realize(DeviceState *dev, Error **errp)
 tmp421_reset(>i2c);
 }
 
-static void tmp421_initfn(Object *obj)
-{
-object_property_add(obj, "temperature0", "int",
-tmp421_get_temperature,
-tmp421_set_temperature, NULL, NULL);
-object_property_add(obj, "temperature1", "int",
-tmp421_get_temperature,
-tmp421_set_temperature, NULL, NULL);
-object_property_add(obj, "temperature2", "int",
-tmp421_get_temperature,
-tmp421_set_temperature, NULL, NULL);
-object_property_add(obj, "temperature3", "int",
-tmp421_get_temperature,
-tmp421_set_temperature, NULL, NULL);
-}
-
 static void tmp421_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -368,6 +352,19 @@ static void tmp421_class_init(ObjectClass *klass, void 
*data)
 k->send = tmp421_tx;
 dc->vmsd = _tmp421;
 sc->dev = (DeviceInfo *) data;
+
+object_class_property_add(klass, "temperature0", "int",
+  tmp421_get_temperature,
+  tmp421_set_temperature, NULL, NULL);
+object_class_property_add(klass, "temperature1", "int",
+  tmp421_get_temperature,
+  tmp421_set_temperature, NULL, NULL);
+object_class_property_add(klass, "temperature2", "int",
+  tmp421_get_temperature,
+  tmp421_set_temperature, NULL, NULL);
+object_class_property_add(klass, "temperature3", "int",
+  tmp421_get_temperature,
+  tmp421_set_temperature, NULL, NULL);
 }
 
 static const TypeInfo tmp421_info = {
@@ -375,7 +372,6 @@ static const TypeInfo tmp421_info = {
 .parent= TYPE_I2C_SLAVE,
 .instance_size = sizeof(TMP421State),
 .class_size= sizeof(TMP421Class),
-.instance_init = tmp421_initfn,
 .abstract  = true,
 };
 
-- 
2.26.2

[PATCH 10/24] input-barrier: Register properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Gerd Hoffmann 
Cc: qemu-devel@nongnu.org
---
 ui/input-barrier.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/ui/input-barrier.c b/ui/input-barrier.c
index 87543a33993..9a196d0a33d 100644
--- a/ui/input-barrier.c
+++ b/ui/input-barrier.c
@@ -689,28 +689,6 @@ static void input_barrier_instance_init(Object *obj)
 ib->y_origin = 0;
 ib->width = 1920;
 ib->height = 1080;
-
-object_property_add_str(obj, "name",
-input_barrier_get_name,
-input_barrier_set_name);
-object_property_add_str(obj, "server",
-input_barrier_get_server,
-input_barrier_set_server);
-object_property_add_str(obj, "port",
-input_barrier_get_port,
-input_barrier_set_port);
-object_property_add_str(obj, "x-origin",
-input_barrier_get_x_origin,
-input_barrier_set_x_origin);
-object_property_add_str(obj, "y-origin",
-input_barrier_get_y_origin,
-input_barrier_set_y_origin);
-object_property_add_str(obj, "width",
-input_barrier_get_width,
-input_barrier_set_width);
-object_property_add_str(obj, "height",
-input_barrier_get_height,
-input_barrier_set_height);
 }
 
 static void input_barrier_class_init(ObjectClass *oc, void *data)
@@ -718,6 +696,28 @@ static void input_barrier_class_init(ObjectClass *oc, void 
*data)
 UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
 
 ucc->complete = input_barrier_complete;
+
+object_class_property_add_str(oc, "name",
+  input_barrier_get_name,
+  input_barrier_set_name);
+object_class_property_add_str(oc, "server",
+  input_barrier_get_server,
+  input_barrier_set_server);
+object_class_property_add_str(oc, "port",
+  input_barrier_get_port,
+  input_barrier_set_port);
+object_class_property_add_str(oc, "x-origin",
+  input_barrier_get_x_origin,
+  input_barrier_set_x_origin);
+object_class_property_add_str(oc, "y-origin",
+  input_barrier_get_y_origin,
+  input_barrier_set_y_origin);
+object_class_property_add_str(oc, "width",
+  input_barrier_get_width,
+  input_barrier_set_width);
+object_class_property_add_str(oc, "height",
+  input_barrier_get_height,
+  input_barrier_set_height);
 }
 
 static const TypeInfo input_barrier_info = {
-- 
2.26.2

[PATCH 18/24] arm/cpu64: Register "aarch64" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 target/arm/cpu64.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 3c2b3d95993..349c9fa3a3a 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -758,15 +758,6 @@ static void aarch64_cpu_set_aarch64(Object *obj, bool 
value, Error **errp)
 }
 }
 
-static void aarch64_cpu_initfn(Object *obj)
-{
-object_property_add_bool(obj, "aarch64", aarch64_cpu_get_aarch64,
- aarch64_cpu_set_aarch64);
-object_property_set_description(obj, "aarch64",
-"Set on/off to enable/disable aarch64 "
-"execution state ");
-}
-
 static void aarch64_cpu_finalizefn(Object *obj)
 {
 }
@@ -786,6 +777,12 @@ static void aarch64_cpu_class_init(ObjectClass *oc, void 
*data)
 cc->gdb_num_core_regs = 34;
 cc->gdb_core_xml_file = "aarch64-core.xml";
 cc->gdb_arch_name = aarch64_gdb_arch_name;
+
+object_class_property_add_bool(oc, "aarch64", aarch64_cpu_get_aarch64,
+   aarch64_cpu_set_aarch64);
+object_class_property_set_description(oc, "aarch64",
+  "Set on/off to enable/disable 
aarch64 "
+  "execution state ");
 }
 
 static void aarch64_cpu_instance_init(Object *obj)
@@ -823,7 +820,6 @@ static const TypeInfo aarch64_cpu_type_info = {
 .name = TYPE_AARCH64_CPU,
 .parent = TYPE_ARM_CPU,
 .instance_size = sizeof(ARMCPU),
-.instance_init = aarch64_cpu_initfn,
 .instance_finalize = aarch64_cpu_finalizefn,
 .abstract = true,
 .class_size = sizeof(AArch64CPUClass),
-- 
2.26.2

[PATCH 13/24] i386: Register most CPU properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 
Cc: qemu-devel@nongnu.org
---
 target/i386/cpu.c | 66 ---
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1c58f764dcb..66792f28ba7 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6922,44 +6922,12 @@ static void x86_cpu_initfn(Object *obj)
 env->nr_dies = 1;
 cpu_set_cpustate_pointers(cpu);
 
-object_property_add(obj, "family", "int",
-x86_cpuid_version_get_family,
-x86_cpuid_version_set_family, NULL, NULL);
-object_property_add(obj, "model", "int",
-x86_cpuid_version_get_model,
-x86_cpuid_version_set_model, NULL, NULL);
-object_property_add(obj, "stepping", "int",
-x86_cpuid_version_get_stepping,
-x86_cpuid_version_set_stepping, NULL, NULL);
-object_property_add_str(obj, "vendor",
-x86_cpuid_get_vendor,
-x86_cpuid_set_vendor);
-object_property_add_str(obj, "model-id",
-x86_cpuid_get_model_id,
-x86_cpuid_set_model_id);
-object_property_add(obj, "tsc-frequency", "int",
-x86_cpuid_get_tsc_freq,
-x86_cpuid_set_tsc_freq, NULL, NULL);
 object_property_add(obj, "feature-words", "X86CPUFeatureWordInfo",
 x86_cpu_get_feature_words,
 NULL, NULL, (void *)env->features);
 object_property_add(obj, "filtered-features", "X86CPUFeatureWordInfo",
 x86_cpu_get_feature_words,
 NULL, NULL, (void *)cpu->filtered_features);
-/*
- * The "unavailable-features" property has the same semantics as
- * CpuDefinitionInfo.unavailable-features on the "query-cpu-definitions"
- * QMP command: they list the features that would have prevented the
- * CPU from running if the "enforce" flag was set.
- */
-object_property_add(obj, "unavailable-features", "strList",
-x86_cpu_get_unavailable_features,
-NULL, NULL, NULL);
-
-#if !defined(CONFIG_USER_ONLY)
-object_property_add(obj, "crash-information", "GuestPanicInformation",
-x86_cpu_get_crash_info_qom, NULL, NULL, NULL);
-#endif
 
 for (w = 0; w < FEATURE_WORDS; w++) {
 int bitnr;
@@ -7308,6 +7276,40 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
 cc->disas_set_info = x86_disas_set_info;
 
 dc->user_creatable = true;
+
+object_class_property_add(oc, "family", "int",
+  x86_cpuid_version_get_family,
+  x86_cpuid_version_set_family, NULL, NULL);
+object_class_property_add(oc, "model", "int",
+  x86_cpuid_version_get_model,
+  x86_cpuid_version_set_model, NULL, NULL);
+object_class_property_add(oc, "stepping", "int",
+  x86_cpuid_version_get_stepping,
+  x86_cpuid_version_set_stepping, NULL, NULL);
+object_class_property_add_str(oc, "vendor",
+  x86_cpuid_get_vendor,
+  x86_cpuid_set_vendor);
+object_class_property_add_str(oc, "model-id",
+  x86_cpuid_get_model_id,
+  x86_cpuid_set_model_id);
+object_class_property_add(oc, "tsc-frequency", "int",
+  x86_cpuid_get_tsc_freq,
+  x86_cpuid_set_tsc_freq, NULL, NULL);
+/*
+ * The "unavailable-features" property has the same semantics as
+ * CpuDefinitionInfo.unavailable-features on the "query-cpu-definitions"
+ * QMP command: they list the features that would have prevented the
+ * CPU from running if the "enforce" flag was set.
+ */
+object_class_property_add(oc, "unavailable-features", "strList",
+  x86_cpu_get_unavailable_features,
+  NULL, NULL, NULL);
+
+#if !defined(CONFIG_USER_ONLY)
+object_class_property_add(oc, "crash-information", "GuestPanicInformation",
+  x86_cpu_get_crash_info_qom, NULL, NULL, NULL);
+#endif
+
 }
 
 static const TypeInfo x86_cpu_type_info = {
-- 
2.26.2

[PATCH 03/24] rng-egd: Register "chardev" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Laurent Vivier 
Cc: Amit Shah 
Cc: qemu-devel@nongnu.org
---
 backends/rng-egd.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/backends/rng-egd.c b/backends/rng-egd.c
index d905fe657c5..d3a8b1ebe2a 100644
--- a/backends/rng-egd.c
+++ b/backends/rng-egd.c
@@ -137,12 +137,6 @@ static char *rng_egd_get_chardev(Object *obj, Error **errp)
 return NULL;
 }
 
-static void rng_egd_init(Object *obj)
-{
-object_property_add_str(obj, "chardev",
-rng_egd_get_chardev, rng_egd_set_chardev);
-}
-
 static void rng_egd_finalize(Object *obj)
 {
 RngEgd *s = RNG_EGD(obj);
@@ -157,6 +151,8 @@ static void rng_egd_class_init(ObjectClass *klass, void 
*data)
 
 rbc->request_entropy = rng_egd_request_entropy;
 rbc->opened = rng_egd_opened;
+object_class_property_add_str(klass, "chardev",
+  rng_egd_get_chardev, rng_egd_set_chardev);
 }
 
 static const TypeInfo rng_egd_info = {
@@ -164,7 +160,6 @@ static const TypeInfo rng_egd_info = {
 .parent = TYPE_RNG_BACKEND,
 .instance_size = sizeof(RngEgd),
 .class_init = rng_egd_class_init,
-.instance_init = rng_egd_init,
 .instance_finalize = rng_egd_finalize,
 };
 
-- 
2.26.2

[PATCH 07/24] rng: Register "opened" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Laurent Vivier 
Cc: Amit Shah 
Cc: qemu-devel@nongnu.org
---
 backends/rng.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/backends/rng.c b/backends/rng.c
index 484f04e8916..3757b044855 100644
--- a/backends/rng.c
+++ b/backends/rng.c
@@ -105,10 +105,6 @@ static void rng_backend_init(Object *obj)
 RngBackend *s = RNG_BACKEND(obj);
 
 QSIMPLEQ_INIT(>requests);
-
-object_property_add_bool(obj, "opened",
- rng_backend_prop_get_opened,
- rng_backend_prop_set_opened);
 }
 
 static void rng_backend_finalize(Object *obj)
@@ -123,6 +119,10 @@ static void rng_backend_class_init(ObjectClass *oc, void 
*data)
 UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
 
 ucc->complete = rng_backend_complete;
+
+object_class_property_add_bool(oc, "opened",
+   rng_backend_prop_get_opened,
+   rng_backend_prop_set_opened);
 }
 
 static const TypeInfo rng_backend_info = {
-- 
2.26.2

[PATCH 02/24] cryptodev-backend: Register "chardev" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: "Gonglei (Arei)" 
Cc: qemu-devel@nongnu.org
---
 backends/cryptodev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/backends/cryptodev.c b/backends/cryptodev.c
index ada4ebe78b1..3f141f61ed6 100644
--- a/backends/cryptodev.c
+++ b/backends/cryptodev.c
@@ -206,10 +206,6 @@ cryptodev_backend_can_be_deleted(UserCreatable *uc)
 
 static void cryptodev_backend_instance_init(Object *obj)
 {
-object_property_add(obj, "queues", "uint32",
-  cryptodev_backend_get_queues,
-  cryptodev_backend_set_queues,
-  NULL, NULL);
 /* Initialize devices' queues property to 1 */
 object_property_set_int(obj, "queues", 1, NULL);
 }
@@ -230,6 +226,10 @@ cryptodev_backend_class_init(ObjectClass *oc, void *data)
 ucc->can_be_deleted = cryptodev_backend_can_be_deleted;
 
 QTAILQ_INIT(_clients);
+object_class_property_add(oc, "queues", "uint32",
+  cryptodev_backend_get_queues,
+  cryptodev_backend_set_queues,
+  NULL, NULL);
 }
 
 static const TypeInfo cryptodev_backend_info = {
-- 
2.26.2

[PATCH 15/24] arm/virt: Register most properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/arm/virt.c | 76 +++
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index acf9bfbecea..d1ab660fa60 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2443,6 +2443,47 @@ static void virt_machine_class_init(ObjectClass *oc, 
void *data)
 NULL, NULL);
 object_class_property_set_description(oc, "acpi",
 "Enable ACPI");
+object_class_property_add_bool(oc, "secure", virt_get_secure,
+   virt_set_secure);
+object_class_property_set_description(oc, "secure",
+"Set on/off to enable/disable 
the ARM "
+"Security Extensions 
(TrustZone)");
+
+object_class_property_add_bool(oc, "virtualization", virt_get_virt,
+   virt_set_virt);
+object_class_property_set_description(oc, "virtualization",
+  "Set on/off to enable/disable 
emulating a "
+  "guest CPU which implements the ARM "
+  "Virtualization Extensions");
+
+object_class_property_add_bool(oc, "highmem", virt_get_highmem,
+   virt_set_highmem);
+object_class_property_set_description(oc, "highmem",
+  "Set on/off to enable/disable using "
+  "physical address space above 32 
bits");
+
+object_class_property_add_str(oc, "gic-version", virt_get_gic_version,
+  virt_set_gic_version);
+object_class_property_set_description(oc, "gic-version",
+  "Set GIC version. "
+  "Valid values are 2, 3, host and 
max");
+
+object_class_property_add_str(oc, "iommu", virt_get_iommu, virt_set_iommu);
+object_class_property_set_description(oc, "iommu",
+  "Set the IOMMU type. "
+  "Valid values are none and smmuv3");
+
+object_class_property_add_bool(oc, "ras", virt_get_ras,
+   virt_set_ras);
+object_class_property_set_description(oc, "ras",
+  "Set on/off to enable/disable 
reporting host memory errors "
+  "to a KVM guest using ACPI and guest 
external abort exceptions");
+
+object_class_property_add_bool(oc, "mte", virt_get_mte, virt_set_mte);
+object_class_property_set_description(oc, "mte",
+  "Set on/off to enable/disable 
emulating a "
+  "guest CPU which implements the ARM "
+  "Memory Tagging Extension");
 }
 
 static void virt_instance_init(Object *obj)
@@ -2455,34 +2496,13 @@ static void virt_instance_init(Object *obj)
  * boot UEFI blobs which assume no TrustZone support.
  */
 vms->secure = false;
-object_property_add_bool(obj, "secure", virt_get_secure,
- virt_set_secure);
-object_property_set_description(obj, "secure",
-"Set on/off to enable/disable the ARM "
-"Security Extensions (TrustZone)");
 
 /* EL2 is also disabled by default, for similar reasons */
 vms->virt = false;
-object_property_add_bool(obj, "virtualization", virt_get_virt,
- virt_set_virt);
-object_property_set_description(obj, "virtualization",
-"Set on/off to enable/disable emulating a "
-"guest CPU which implements the ARM "
-"Virtualization Extensions");
 
 /* High memory is enabled by default */
 vms->highmem = true;
-object_property_add_bool(obj, "highmem", virt_get_highmem,
- virt_set_highmem);
-object_property_set_description(obj, "highmem",
-"Set on/off to enable/disable using "
-"physical address space above 32 bits");
 vms->gic_version = VIRT_GIC_VERSION_NOSEL;
-object_property_add_str(obj, "gic-version", virt_get_gic_version,
-virt_set_gic_version);
-object_property_set_description(obj, "gic-version",
-"Set GIC version. "
-"Valid values are 2, 3, host and max");
 
 vms->highmem_ecam = !vmc->no_highmem_ecam;
 
@@ 

[PATCH 09/24] input-linux: Register properties as class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Gerd Hoffmann 
Cc: qemu-devel@nongnu.org
---
 ui/input-linux.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/ui/input-linux.c b/ui/input-linux.c
index 5d501c8360c..cb86774a51e 100644
--- a/ui/input-linux.c
+++ b/ui/input-linux.c
@@ -489,19 +489,6 @@ static void input_linux_set_grab_toggle(Object *obj, int 
value,
 
 static void input_linux_instance_init(Object *obj)
 {
-object_property_add_str(obj, "evdev",
-input_linux_get_evdev,
-input_linux_set_evdev);
-object_property_add_bool(obj, "grab_all",
- input_linux_get_grab_all,
- input_linux_set_grab_all);
-object_property_add_bool(obj, "repeat",
- input_linux_get_repeat,
- input_linux_set_repeat);
-object_property_add_enum(obj, "grab-toggle", "GrabToggleKeys",
- _lookup,
- input_linux_get_grab_toggle,
- input_linux_set_grab_toggle);
 }
 
 static void input_linux_class_init(ObjectClass *oc, void *data)
@@ -509,6 +496,20 @@ static void input_linux_class_init(ObjectClass *oc, void 
*data)
 UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
 
 ucc->complete = input_linux_complete;
+
+object_class_property_add_str(oc, "evdev",
+  input_linux_get_evdev,
+  input_linux_set_evdev);
+object_class_property_add_bool(oc, "grab_all",
+   input_linux_get_grab_all,
+   input_linux_set_grab_all);
+object_class_property_add_bool(oc, "repeat",
+   input_linux_get_repeat,
+   input_linux_set_repeat);
+object_class_property_add_enum(oc, "grab-toggle", "GrabToggleKeys",
+   _lookup,
+   input_linux_get_grab_toggle,
+   input_linux_set_grab_toggle);
 }
 
 static const TypeInfo input_linux_info = {
-- 
2.26.2

[PATCH 05/24] vhost-user: Register "chardev" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: "Michael S. Tsirkin" 
Cc: qemu-devel@nongnu.org
---
 backends/vhost-user.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/backends/vhost-user.c b/backends/vhost-user.c
index 9e6e1985465..858fdeae26c 100644
--- a/backends/vhost-user.c
+++ b/backends/vhost-user.c
@@ -175,9 +175,9 @@ static char *get_chardev(Object *obj, Error **errp)
 return NULL;
 }
 
-static void vhost_user_backend_init(Object *obj)
+static void vhost_user_backend_class_init(ObjectClass *oc, void *data)
 {
-object_property_add_str(obj, "chardev", get_chardev, set_chardev);
+object_class_property_add_str(oc, "chardev", get_chardev, set_chardev);
 }
 
 static void vhost_user_backend_finalize(Object *obj)
@@ -195,7 +195,7 @@ static const TypeInfo vhost_user_backend_info = {
 .name = TYPE_VHOST_USER_BACKEND,
 .parent = TYPE_OBJECT,
 .instance_size = sizeof(VhostUserBackend),
-.instance_init = vhost_user_backend_init,
+.class_init = vhost_user_backend_class_init,
 .instance_finalize = vhost_user_backend_finalize,
 .class_size = sizeof(VhostUserBackendClass),
 };
-- 
2.26.2

[PATCH 00/24] qom: Convert some properties to class properties

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as it
doesn't require an object to be instantiated.  This series
converts a few existing object_property_add*() calls to register
class properties instead.

Eduardo Habkost (24):
  cryptodev-vhost-user: Register "chardev" as class property
  cryptodev-backend: Register "chardev" as class property
  rng-egd: Register "chardev" as class property
  rng-random: register "filename" as class property
  vhost-user: Register "chardev" as class property
  vexpress: Register "secure" as class property
  rng: Register "opened" as class property
  vexpress-a15: Register "virtualization" as class property
  input-linux: Register properties as class properties
  input-barrier: Register properties as class properties
  tmp421: Register properties as class properties
  s390x: Register all CPU properties as class properties
  i386: Register most CPU properties as class properties
  i386: Register feature bit properties as class properties
  arm/virt: Register most properties as class properties
  virt: Register "its" as class property
  cpu/core: Register core-id and nr-threads as class properties
  arm/cpu64: Register "aarch64" as class property
  xlnx-zcu102: Register properties as class properties
  machine: Register "memory-backend" as class property
  vga-pci: Register "big-endian-framebuffer" as class property
  i440fx: Register i440FX-pcihost properties as class properties
  sifive_e: Register "revb" as class property
  sifive_u: Register "start-in-flash" as class property

 target/s390x/internal.h |  1 -
 backends/cryptodev-vhost-user.c | 13 ++---
 backends/cryptodev.c|  8 +--
 backends/rng-egd.c  |  9 +--
 backends/rng-random.c   |  8 +--
 backends/rng.c  |  8 +--
 backends/vhost-user.c   |  6 +-
 hw/arm/vexpress.c   | 25 +
 hw/arm/virt.c   | 88 -
 hw/arm/xlnx-zcu102.c| 25 +
 hw/core/machine.c   | 12 ++--
 hw/cpu/core.c   |  8 +--
 hw/display/vga-pci.c| 12 ++--
 hw/misc/tmp421.c| 30 +-
 hw/pci-host/i440fx.c| 32 +--
 hw/riscv/sifive_e.c | 11 ++--
 hw/riscv/sifive_u.c | 16 +++---
 target/arm/cpu64.c  | 16 ++
 target/i386/cpu.c   | 99 +
 target/s390x/cpu.c  |  1 -
 target/s390x/cpu_models.c   | 35 ++--
 ui/input-barrier.c  | 44 +++
 ui/input-linux.c| 27 -
 23 files changed, 262 insertions(+), 272 deletions(-)

-- 
2.26.2

[PATCH 06/24] vexpress: Register "secure" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
 hw/arm/vexpress.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index 01bb4bba1ec..0cc35749d7d 100644
--- a/hw/arm/vexpress.c
+++ b/hw/arm/vexpress.c
@@ -758,11 +758,6 @@ static void vexpress_instance_init(Object *obj)
 
 /* EL3 is enabled by default on vexpress */
 vms->secure = true;
-object_property_add_bool(obj, "secure", vexpress_get_secure,
- vexpress_set_secure);
-object_property_set_description(obj, "secure",
-"Set on/off to enable/disable the ARM "
-"Security Extensions (TrustZone)");
 }
 
 static void vexpress_a15_instance_init(Object *obj)
@@ -799,6 +794,12 @@ static void vexpress_class_init(ObjectClass *oc, void 
*data)
 mc->max_cpus = 4;
 mc->ignore_memory_transaction_failures = true;
 mc->default_ram_id = "vexpress.highmem";
+
+object_class_property_add_bool(oc, "secure", vexpress_get_secure,
+   vexpress_set_secure);
+object_class_property_set_description(oc, "secure",
+  "Set on/off to enable/disable the 
ARM "
+  "Security Extensions (TrustZone)");
 }
 
 static void vexpress_a9_class_init(ObjectClass *oc, void *data)
-- 
2.26.2

[PATCH 01/24] cryptodev-vhost-user: Register "chardev" as class property

[Eduardo Habkost]

Class properties make QOM introspection simpler and easier, as
they don't require an object to be instantiated.

Signed-off-by: Eduardo Habkost 
---
Cc: "Gonglei (Arei)" 
Cc: qemu-devel@nongnu.org
---
 backends/cryptodev-vhost-user.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c
index 41089dede15..690738c6c95 100644
--- a/backends/cryptodev-vhost-user.c
+++ b/backends/cryptodev-vhost-user.c
@@ -336,13 +336,6 @@ cryptodev_vhost_user_get_chardev(Object *obj, Error **errp)
 return NULL;
 }
 
-static void cryptodev_vhost_user_instance_int(Object *obj)
-{
-object_property_add_str(obj, "chardev",
-cryptodev_vhost_user_get_chardev,
-cryptodev_vhost_user_set_chardev);
-}
-
 static void cryptodev_vhost_user_finalize(Object *obj)
 {
 CryptoDevBackendVhostUser *s =
@@ -363,13 +356,17 @@ cryptodev_vhost_user_class_init(ObjectClass *oc, void 
*data)
 bc->create_session = cryptodev_vhost_user_sym_create_session;
 bc->close_session = cryptodev_vhost_user_sym_close_session;
 bc->do_sym_op = NULL;
+
+object_class_property_add_str(oc, "chardev",
+  cryptodev_vhost_user_get_chardev,
+  cryptodev_vhost_user_set_chardev);
+
 }
 
 static const TypeInfo cryptodev_vhost_user_info = {
 .name = TYPE_CRYPTODEV_BACKEND_VHOST_USER,
 .parent = TYPE_CRYPTODEV_BACKEND,
 .class_init = cryptodev_vhost_user_class_init,
-.instance_init = cryptodev_vhost_user_instance_int,
 .instance_finalize = cryptodev_vhost_user_finalize,
 .instance_size = sizeof(CryptoDevBackendVhostUser),
 };
-- 
2.26.2

Re: [PATCH v2] qemu-img: Support bitmap --merge into backing image

[Eric Blake]

On 9/17/20 5:19 AM, Max Reitz wrote:


temporary over NBD, referring to a bitmap that lives only in Active is
less effort than having to copy a bitmap into temporary [1].  So the
testsuite additions in this patch check both where bitmaps get
allocated (the qemu-img info output), and, when NOT using 'qemu-img
bitmap', that bitmaps are indeed visible through a backing chain.


Well.  It is useful over NBD but I would doubt that it isn’t useful in
general.  For example, the QMP commands that refer to bitmaps always do
so through a node-name + bitmap-name combination, and they require that
the given bitmap is exactly on the given node.

So I think this is a very much a case-by-case question.  (And in
practice, NBD seems to be the outlier, not qemu-img bitmap.)



I'm happy to reword slightly to give that caveat.




The code looks good to me, but I wonder whether in the commit message it
should be noted that we don’t want to let bitmaps from deeper nodes
shine through by default everywhere, but just in specific cases where
that’s useful (i.e. only NBD so far AFAIA).


So is this a Reviewed-by?  I'm happy to queue it through my bitmaps
tree, if so.


It wasn’t meant as an R-b, because my R-b depends on how the commit
message addresses the question of when exactly bitmaps from the backing
chain should be visible on the top image.  Whether qemu-img bitmap is an
exception, or whether this is really a case-by-case question.

(I wanted to know whether you agree on including it.  Normally, I’m
happy to give an R-b on the basis of “with that done”, but in this case
I wasn’t entirely sure whether my request was reasonable, but I also
felt that in case it was, it wasn’t optional, given that you do have an
entire paragraph in the commit message dedicated to why the backing
image’s bitmap is visible on an image exported over NBD.)


Here's my rewording:

However, note that on a case-by-case analysis, there _are_ times where
we treat it as a feature that we can access a bitmap from a backing
layer in association with an overlay BDS.  A demonstration of this is
using NBD to expose both an overlay BDS (for constant contents) and a
bitmap (for learning which blocks are interesting) during an
incremental backup:

Base <- Active <- Temporary
  \--block job ->/

where Temporary is being fed by a backup 'sync=none' job.  When
exposing Temporary over NBD, referring to a bitmap that lives only in
Active is less effort than having to copy a bitmap into Temporary [1].
So the testsuite additions in this patch check both where bitmaps get
allocated (the qemu-img info output), and that qemu-nbd is indeed able
to access a bitmap inherited from the backing chain since it is a
different use case than 'qemu-img bitmap'.



I have to say I would like to see how you do phrase it in the end, but
given that you do agree on including it, I can give a

Reviewed-by: Max Reitz 

Now.


Okay, I think I've met your request, so I'll go ahead and send the pull 
request today.


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

Re: [PATCH 0/6] block/nvme: Map doorbells pages write-only, remove magic from nvme_init

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200921162949.553863-1-phi...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or 
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
Compiling C object authz/libauthz.fa.p/listfile.c.o
Compiling C object authz/libauthz.fa.p/list.c.o
../src/block/nvme.c: In function 'nvme_file_open':
../src/block/nvme.c:807:8: error: 'regs' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
 if (regs) {
^
../src/block/nvme.c:692:23: note: 'regs' was declared here
 volatile NvmeBar *regs;
   ^
cc1: all warnings being treated as errors
make: *** [libblock.fa.p/block_nvme.c.o] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 709, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', 
'--label', 'com.qemu.instance.uuid=99233811d86a42b1b27aa376bb85979d', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 
'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-wu686lwl/src/docker-src.2020-09-21-17.52.21.21740:/var/tmp/qemu:z,ro',
 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=99233811d86a42b1b27aa376bb85979d
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-wu686lwl/src'
make: *** [docker-run-test-quick@centos7] Error 2

real3m46.350s
user0m15.940s


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

RE: [PATCH v3 01/15] hw/block/nvme: Define 64 bit cqe.result

[Dmitry Fomichev]

> -Original Message-
> From: Keith Busch 
> Sent: Friday, September 18, 2020 5:10 PM
> To: Klaus Jensen 
> Cc: Dmitry Fomichev ; Fam Zheng
> ; Kevin Wolf ; Damien Le Moal
> ; qemu-bl...@nongnu.org; Niklas Cassel
> ; Klaus Jensen ; qemu-
> de...@nongnu.org; Alistair Francis ; Philippe
> Mathieu-Daudé ; Matias Bjorling
> 
> Subject: Re: [PATCH v3 01/15] hw/block/nvme: Define 64 bit cqe.result
> 
> On Tue, Sep 15, 2020 at 10:48:49PM +0200, Klaus Jensen wrote:
> > On Sep 15 20:44, Dmitry Fomichev wrote:
> > >
> > > It is not necessary to change it in NST patch since result64 field is not 
> > > used
> > > in that patch. But if you insist, I can move it to NST patch :)
> >
> > You are right of course, but since it is a change to the "spec" related
> > data structures that go into include/block/nvme.h, I think it belongs in
> > "hw/block/nvme: Introduce the Namespace Types definitions".
> 
> Just my $.02, unless you're making exernal APIs, I really find it easier
> to review internal changes inline with the patches that use it.
> 
> Another example, there are patches in this series that introduce trace
> points, but the patch that use them come later. I find that harder to
> review since I need to look at two different patches to understand its
> value.
> 

I decided to split the trace events to be separate because I felt that it
could make the reviewing process simpler. Since the majority of the patches
in this series are on the large side, I thought it would be easier to open
them in separate sessions rather than to review a large single diff.
Let me know if you'd like me to fold the tracing stuff together with
the code...

DF

> I realize this particular patch is implementing a spec feature, but I'd
> prefer to see how it's used over of making a round trip to the spec.

Re: [PATCH 0/6] block/nvme: Map doorbells pages write-only, remove magic from nvme_init

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200921162949.553863-1-phi...@redhat.com/



Hi,

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

Type: series
Message-id: 20200921162949.553863-1-phi...@redhat.com
Subject: [PATCH 0/6] block/nvme: Map doorbells pages write-only, remove magic 
from nvme_init

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
b0ef8b7 block/nvme: Replace magic value by SCALE_MS definition
1792c4d block/nvme: Use register definitions from 'block/nvme.h'
352be0c block/nvme: Drop NVMeRegs structure, directly use NvmeBar
7aa184a block/nvme: Reduce I/O registers scope
4b1effc block/nvme: Map doorbells pages write-only
7ae4653 util/vfio-helpers: Pass page protections to qemu_vfio_pci_map_bar()

=== OUTPUT BEGIN ===
1/6 Checking commit 7ae46536369a (util/vfio-helpers: Pass page protections to 
qemu_vfio_pci_map_bar())
2/6 Checking commit 4b1effcfcd2b (block/nvme: Map doorbells pages write-only)
3/6 Checking commit 7aa184a756dc (block/nvme: Reduce I/O registers scope)
4/6 Checking commit 352be0c97869 (block/nvme: Drop NVMeRegs structure, directly 
use NvmeBar)
ERROR: Use of volatile is usually wrong, please add a comment
#43: FILE: block/nvme.c:692:
+volatile NvmeBar *regs;

total: 1 errors, 0 warnings, 62 lines checked

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

5/6 Checking commit 1792c4da4bc2 (block/nvme: Use register definitions from 
'block/nvme.h')
6/6 Checking commit b0ef8b776eb1 (block/nvme: Replace magic value by SCALE_MS 
definition)
=== OUTPUT END ===

Test command exited with code: 1


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

[PATCH] virtiofsd: Used glib "shared" thread pool

[Vivek Goyal]

glib offers thread pools and it seems to support "exclusive" and "shared"
thread pools.

https://developer.gnome.org/glib/stable/glib-Thread-Pools.html#g-thread-pool-new

Currently we use "exlusive" thread pools but its performance seems to be
poor. I tried using "shared" thread pools and performance seems much
better. I posted performance results here.

https://www.redhat.com/archives/virtio-fs/2020-September/msg00080.html

So lets switch to shared thread pools. We can think of making it optional
once somebody can show in what cases exclusive thread pools offer better
results. For now, my simple performance tests across the board see
better results with shared thread pools.

Signed-off-by: Vivek Goyal 
---
 tools/virtiofsd/fuse_virtio.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: qemu/tools/virtiofsd/fuse_virtio.c
===
--- qemu.orig/tools/virtiofsd/fuse_virtio.c 2020-09-21 17:28:27.38015 
-0400
+++ qemu/tools/virtiofsd/fuse_virtio.c  2020-09-21 17:28:30.584568910 -0400
@@ -695,7 +695,7 @@ static void *fv_queue_thread(void *opaqu
 struct fuse_session *se = qi->virtio_dev->se;
 GThreadPool *pool;
 
-pool = g_thread_pool_new(fv_queue_worker, qi, se->thread_pool_size, TRUE,
+pool = g_thread_pool_new(fv_queue_worker, qi, se->thread_pool_size, FALSE,
  NULL);
 if (!pool) {
 fuse_log(FUSE_LOG_ERR, "%s: g_thread_pool_new failed\n", __func__);

Re: [PATCH] qemu/atomic.h: prefix qemu_ to solve collisions

[Eric Blake]

On 9/21/20 11:23 AM, Stefan Hajnoczi wrote:

clang's C11 atomic_fetch_*() functions only take a C11 atomic type
pointer argument. QEMU uses direct types (int, etc) and this causes a
compiler error when a QEMU code calls these functions in a source file
that also included  via a system header file:

   $ CC=clang CXX=clang++ ./configure ... && make
   ../util/async.c:79:17: error: address argument to atomic operation must be a 
pointer to _Atomic type ('unsigned int *' invalid)

Avoid using atomic_*() names in QEMU's atomic.h since that namespace is
used by . Prefix QEMU's APIs with qemu_ so that atomic.h
and  can co-exist.

This patch was generated using:

   $ git diff | grep -o '\/tmp/changed_identifiers


Missing a step in the recipe: namely, you probably modified 
include/qemu/atomic*.h prior to running 'git diff' (so that you actually 
had input to feed to grep -o).  But spelling it 'git diff HEAD^ 
include/qemu/atomic*.h | ...' does indeed give me a sane list of 
identifiers that looks like what you touched in the rest of the patch.



   $ for identifier in $(

Also not quite the right recipe, based on the file name used in the line 
above.



sed -i "s%\<$identifier\>%qemu_$identifier%" $(git grep -l 
"\<$identifier\>") \
 done



Fortunately, running "git grep -c '\pre-patch state of the tree gives me a list that is somewhat close to 
yours, where the obvious difference in line counts is explained by:



I manually fixed line-wrap issues and misaligned rST tables.

Signed-off-by: Stefan Hajnoczi 
---


First, focusing on the change summary:


  docs/devel/lockcnt.txt|  14 +-
  docs/devel/rcu.txt|  40 +--
  accel/tcg/atomic_template.h   |  20 +-
  include/block/aio-wait.h  |   4 +-
  include/block/aio.h   |   8 +-
  include/exec/cpu_ldst.h   |   2 +-
  include/exec/exec-all.h   |   6 +-
  include/exec/log.h|   6 +-
  include/exec/memory.h |   2 +-
  include/exec/ram_addr.h   |  27 +-
  include/exec/ramlist.h|   2 +-
  include/exec/tb-lookup.h  |   4 +-
  include/hw/core/cpu.h |   2 +-
  include/qemu/atomic.h | 258 +++---
  include/qemu/atomic128.h  |   6 +-


These two are the most important for the sake of this patch; perhaps 
it's worth a temporary override of your git orderfile if you have to 
respin, to list them first?



  include/qemu/bitops.h |   2 +-
  include/qemu/coroutine.h  |   2 +-
  include/qemu/log.h|   6 +-
  include/qemu/queue.h  |   8 +-
  include/qemu/rcu.h|  10 +-
  include/qemu/rcu_queue.h  | 103 +++---


Presumably, this and any other file with an odd number of changes was 
due to a difference in lines after reformatting long lines.



  include/qemu/seqlock.h|   8 +-

...


  util/stats64.c|  34 +-
  docs/devel/atomics.rst| 326 +-
  .../opensbi-riscv32-generic-fw_dynamic.elf| Bin 558668 -> 558698 bytes
  .../opensbi-riscv64-generic-fw_dynamic.elf| Bin 620424 -> 620454 bytes


Why are we regenerating .elf files in this patch?  Is your change even 
correct for those two files?



  scripts/kernel-doc|   2 +-
  tcg/aarch64/tcg-target.c.inc  |   2 +-
  tcg/mips/tcg-target.c.inc |   2 +-
  tcg/ppc/tcg-target.c.inc  |   6 +-
  tcg/sparc/tcg-target.c.inc|   5 +-
  135 files changed, 1195 insertions(+), 1130 deletions(-)


I don't spot accel/tcg/atomic_common.c.inc in the list (which declares 
functions such as atomic_trace_rmw_pre) - I guess that's intentional 
based on how you tried to edit only the identifiers you touched in 
include/qemu/atomic*.h.


For the rest of this patch, I only spot-checked in places, trusting the 
mechanical nature of this patch, and not spotting anything wrong in the 
places I checked.  But the two .elf files worry me enough to withhold 
R-b.  At the same time, because it's big, it will probably be a source 
of conflicts if we don't get it in soon, but can also be regenerated (if 
your recipe is corrected) without too much difficulty.  So I am in favor 
of the idea.



diff --git a/pc-bios/opensbi-riscv32-generic-fw_dynamic.elf 
b/pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
index 
eb9ebf5674d3953ab25de6bf4db134abe904eb20..35b80512446dcf5c49424ae90caacf3c579be1b5
 100644
GIT binary patch
delta 98
zcmX@pqx7mrsiB3jg{g(Pg=Gt?!4uZP)ZEhe?LdZ@5QIJ5?Hg+mgxS918!HgAZQt>Y
ceSHN~X?i|K5fhYsvykI97nHrFhGPaN0Hp#a^8f$<

delta 62

Re: [PATCH] qemu/atomic.h: prefix qemu_ to solve collisions

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200921162346.188997-1-stefa...@redhat.com/



Hi,

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

Type: series
Message-id: 20200921162346.188997-1-stefa...@redhat.com
Subject: [PATCH] qemu/atomic.h: prefix qemu_ to solve  collisions

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200918103430.297167-1-th...@redhat.com -> 
patchew/20200918103430.297167-1-th...@redhat.com
Switched to a new branch 'test'
25ca702 qemu/atomic.h: prefix qemu_ to solve  collisions

=== OUTPUT BEGIN ===
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#2968: FILE: include/qemu/atomic.h:152:
+#define qemu_atomic_rcu_read__nocheck(ptr, valptr)  \
 __atomic_load(ptr, valptr, __ATOMIC_RELAXED);   \
 smp_read_barrier_depends();

ERROR: space required before that '*' (ctx:VxB)
#3123: FILE: include/qemu/atomic.h:347:
+#define qemu_atomic_read__nocheck(p) (*(__typeof__(*(p)) volatile*) (p))
  ^

ERROR: Use of volatile is usually wrong, please add a comment
#3123: FILE: include/qemu/atomic.h:347:
+#define qemu_atomic_read__nocheck(p) (*(__typeof__(*(p)) volatile*) (p))

ERROR: space required before that '*' (ctx:VxB)
#3125: FILE: include/qemu/atomic.h:349:
+((*(__typeof__(*(p)) volatile*) (p)) = (i))
  ^

ERROR: Use of volatile is usually wrong, please add a comment
#3125: FILE: include/qemu/atomic.h:349:
+((*(__typeof__(*(p)) volatile*) (p)) = (i))

ERROR: space required after that ',' (ctx:VxV)
#3130: FILE: include/qemu/atomic.h:352:
+#define qemu_atomic_set(ptr, i) qemu_atomic_set__nocheck(ptr,i)
 ^

ERROR: memory barrier without comment
#3205: FILE: include/qemu/atomic.h:410:
+#define qemu_atomic_xchg(ptr, i) (smp_mb(), __sync_lock_test_and_set(ptr, i))

WARNING: Block comments use a leading /* on a separate line
#3280: FILE: include/qemu/atomic.h:462:
+/* qemu_atomic_mb_read/set semantics map Java volatile variables. They are

WARNING: Block comments use a leading /* on a separate line
#6394: FILE: util/bitmap.c:214:
+/* If we avoided the full barrier in qemu_atomic_or(), issue a

WARNING: Block comments use a leading /* on a separate line
#7430: FILE: util/rcu.c:85:
+/* Instead of using qemu_atomic_mb_set for index->waiting, and

WARNING: Block comments use a leading /* on a separate line
#7456: FILE: util/rcu.c:154:
+/* In either case, the qemu_atomic_mb_set below blocks stores that free

total: 7 errors, 4 warnings, 6507 lines checked

Commit 25ca7029b2f2 (qemu/atomic.h: prefix qemu_ to solve  
collisions) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


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

Re: [PATCH v3] SEV: QMP support for Inject-Launch-Secret

[Tobin Feldman-Fitzthum]

On 2020-09-21 15:16, Dr. David Alan Gilbert wrote:

* Tobin Feldman-Fitzthum (to...@linux.vnet.ibm.com) wrote:

AMD SEV allows a guest owner to inject a secret blob
into the memory of a virtual machine. The secret is
encrypted with the SEV Transport Encryption Key and
integrity is guaranteed with the Transport Integrity
Key. Although QEMU faciliates the injection of the
launch secret, it cannot access the secret.

Signed-off-by: Tobin Feldman-Fitzthum 


Hi Tobin,
  Did the ovmf stuff for agreeing the GUID for automating this ever
happen?


OVMF patches have not been upstreamed yet. I think we are planning
to do that relatively soon.

-Tobin

Dave


---
 include/monitor/monitor.h |  3 ++
 include/sysemu/sev.h  |  2 ++
 monitor/misc.c|  8 ++---
 qapi/misc-target.json | 18 +++
 target/i386/monitor.c |  9 ++
 target/i386/sev-stub.c|  5 +++
 target/i386/sev.c | 66 
+++

 target/i386/trace-events  |  1 +
 8 files changed, 108 insertions(+), 4 deletions(-)

diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 1018d754a6..bf049c5b00 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -4,6 +4,7 @@
 #include "block/block.h"
 #include "qapi/qapi-types-misc.h"
 #include "qemu/readline.h"
+#include "include/exec/hwaddr.h"

 extern __thread Monitor *cur_mon;
 typedef struct MonitorHMP MonitorHMP;
@@ -36,6 +37,8 @@ void monitor_flush(Monitor *mon);
 int monitor_set_cpu(int cpu_index);
 int monitor_get_cpu_index(void);

+void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, uint64_t size, Error 
**errp);

+
 void monitor_read_command(MonitorHMP *mon, int show_prompt);
 int monitor_read_password(MonitorHMP *mon, ReadLineFunc 
*readline_func,

   void *opaque);
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 98c1ec8d38..b279b293e8 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -18,4 +18,6 @@

 void *sev_guest_init(const char *id);
 int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+int sev_inject_launch_secret(const char *hdr, const char *secret,
+ uint64_t gpa);
 #endif
diff --git a/monitor/misc.c b/monitor/misc.c
index 89bb970b00..b9ec8ba410 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -674,10 +674,10 @@ static void hmp_physical_memory_dump(Monitor 
*mon, const QDict *qdict)

 memory_dump(mon, count, format, size, addr, 1);
 }

-static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
+void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, uint64_t size, Error 
**errp)

 {
 MemoryRegionSection mrs = memory_region_find(get_system_memory(),
- addr, 1);
+ addr, size);

 if (!mrs.mr) {
 error_setg(errp, "No memory is mapped at address 0x%" 
HWADDR_PRIx, addr);
@@ -701,7 +701,7 @@ static void hmp_gpa2hva(Monitor *mon, const QDict 
*qdict)

 MemoryRegion *mr = NULL;
 void *ptr;

-ptr = gpa2hva(, addr, _err);
+ptr = gpa2hva(, addr, 1, _err);
 if (local_err) {
 error_report_err(local_err);
 return;
@@ -777,7 +777,7 @@ static void hmp_gpa2hpa(Monitor *mon, const QDict 
*qdict)

 void *ptr;
 uint64_t physaddr;

-ptr = gpa2hva(, addr, _err);
+ptr = gpa2hva(, addr, 1, _err);
 if (local_err) {
 error_report_err(local_err);
 return;
diff --git a/qapi/misc-target.json b/qapi/misc-target.json
index dee3b45930..d145f916b3 100644
--- a/qapi/misc-target.json
+++ b/qapi/misc-target.json
@@ -200,6 +200,24 @@
 { 'command': 'query-sev-capabilities', 'returns': 'SevCapability',
   'if': 'defined(TARGET_I386)' }

+##
+# @sev-inject-launch-secret:
+#
+# This command injects a secret blob into memory of SEV guest.
+#
+# @packet-header: the launch secret packet header encoded in base64
+#
+# @secret: the launch secret data to be injected encoded in base64
+#
+# @gpa: the guest physical address where secret will be injected.
+#
+# Since: 5.1
+#
+##
+{ 'command': 'sev-inject-launch-secret',
+  'data': { 'packet-header': 'str', 'secret': 'str', 'gpa': 'uint64' 
},

+  'if': 'defined(TARGET_I386)' }
+
 ##
 # @dump-skeys:
 #
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 27ebfa3ad2..42bcfe6dc0 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -736,3 +736,12 @@ SevCapability *qmp_query_sev_capabilities(Error 
**errp)


 return data;
 }
+
+void qmp_sev_inject_launch_secret(const char *packet_hdr,
+  const char *secret, uint64_t gpa,
+  Error **errp)
+{
+if (sev_inject_launch_secret(packet_hdr, secret, gpa) != 0) {
+error_setg(errp, "SEV inject secret failed");
+}
+}
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index e5ee13309c..fed4588185 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -48,3 

Re: [PATCH 4/6] travis.yml: Drop the default softmmu builds

[Cleber Rosa]

On Fri, Sep 18, 2020 at 12:34:28PM +0200, Thomas Huth wrote:
> The total runtime of all Travis jobs is very long and we are testing
> all softmmu targets in the gitlab-CI already - so we can speed up the
> Travis testing a little bit by not testing the softmmu targets here
> anymore.
> 
> Reviewed-by: Daniel P. Berrangé 
> Acked-by: Alex Bennée 
> Acked-by: Philippe Mathieu-Daudé 
> Signed-off-by: Thomas Huth 
> ---
>  .travis.yml | 14 --
>  1 file changed, 14 deletions(-)
>

Reviewed-by: Cleber Rosa 


signature.asc
Description: PGP signature

Re: [PATCH 3/6] migration: Silence compiler warning in global_state_store_running()

[Cleber Rosa]

On Fri, Sep 18, 2020 at 12:34:27PM +0200, Thomas Huth wrote:
> GCC 9.3.0 on Ubuntu complains:
> 
> In file included from /usr/include/string.h:495,
>  from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
>  from ../migration/global_state.c:13:
> In function ‘strncpy’,
> inlined from ‘global_state_store_running’ at 
> ../migration/global_state.c:47:5:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
>  ‘__builtin_strncpy’ specified bound 100 equals destination size 
> [-Werror=stringop-truncation]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
> (__dest));
>   |  
> ^~
> 
> ... but we apparently really want to do a strncpy here - the size is already
> checked with the assert() statement right in front of it. To silence the
> warning, simply replace it with our strpadcpy() function.
> 
> Suggested-by: Philippe Mathieu-Daudé  (two years ago)
> Reviewed-by: Philippe Mathieu-Daudé 
> Signed-off-by: Thomas Huth 
> ---
>  migration/global_state.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/global_state.c b/migration/global_state.c
> index 25311479a4..a33947ca32 100644
> --- a/migration/global_state.c
> +++ b/migration/global_state.c
> @@ -44,8 +44,8 @@ void global_state_store_running(void)
>  {
>  const char *state = RunState_str(RUN_STATE_RUNNING);
>  assert(strlen(state) < sizeof(global_state.runstate));
> -strncpy((char *)global_state.runstate,
> -   state, sizeof(global_state.runstate));
> +strpadcpy((char *)global_state.runstate, sizeof(global_state.runstate),
> +  state, '\0');
>  }
>  
>  bool global_state_received(void)
> -- 
> 2.18.2
> 
> 

Hi Thomas,

FIY, I couldn't reproduce the complaint from GCC.  I've tested it on focal,
"gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0", with QEMU 5df6c87e8.

After a succesfull "configure --target-list=x86_64-softmmu && meson
compile" build, I tried to manually enable meson's "werror" option,
and found no difference.

Then, I manually ran gcc, with a couple of "-Werror" variations, such
as:

cc -Ilibcommon.fa.p -I. -I../../src/qemu -Iqapi -Itrace -Iui \
   -Iui/shader -I/usr/include/libpng16 -I/usr/include/libmount \
   -I/usr/include/blkid -I/usr/include/glib-2.0 \
   -I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
   -I/usr/include/gio-unix-2.0 -I/root/src/qemu/slirp/src -Islirp/src \
   -I/usr/include/pixman-1 -I/usr/include/gtk-3.0 \
   -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 \
   -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include \
   -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi \
   -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/uuid \
   -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -Ilinux-headers \
   -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Werror \
   -Werror=stringop-truncation -std=gnu99 -O2 -g -U_FORTIFY_SOURCE \
   -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 \
   -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef \
   -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common \
   -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits \
   -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers \
   -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined \
   -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi \
   -fstack-protector-strong -iquote /root/src/qemu/tcg/i386 -isystem \
   /root/src/qemu/linux-headers -iquote . -iquote /root/src/qemu -iquote \
   /root/src/qemu/accel/tcg -iquote /root/src/qemu/include -iquote \
   /root/src/qemu/disas/libvixl -pthread -fPIC -MD -MQ \
   libcommon.fa.p/migration_global_state.c.o -MF \
   libcommon.fa.p/migration_global_state.c.o.d -o \
   libcommon.fa.p/migration_global_state.c.o -c \
   ../../src/qemu/migration/global_state.c

But I could not trigger the warning (and thus error).  The change here
looks good, but I thought I should let you know, and maybe I'm missing
something obvious.

Thanks,
- Cleber.


signature.asc
Description: PGP signature

Re: tools/virtiofs: Multi threading seems to hurt performance

[Vivek Goyal]

On Fri, Sep 18, 2020 at 05:34:36PM -0400, Vivek Goyal wrote:
> Hi All,
> 
> virtiofsd default thread pool size is 64. To me it feels that in most of
> the cases thread pool size 1 performs better than thread pool size 64.
> 
> I ran virtiofs-tests.
> 
> https://github.com/rhvgoyal/virtiofs-tests

I spent more time debugging this. First thing I noticed is that we
are using "exclusive" glib thread pool.

https://developer.gnome.org/glib/stable/glib-Thread-Pools.html#g-thread-pool-new

This seems to run pre-determined number of threads dedicated to that
thread pool. Little instrumentation of code revealed that every new
request gets assiged to new thread (despite the fact that previous
thread finished its job). So internally there might be some kind of
round robin policy to choose next thread for running the job.

I decided to switch to "shared" pool instead where it seemed to spin
up new threads only if there is enough work. Also threads can be shared
between pools.

And looks like testing results are way better with "shared" pools. So
may be we should switch to shared pool by default. (Till somebody shows
in what cases exclusive pools are better).

Second thought which came to mind was what's the impact of NUMA. What
if qemu and virtiofsd process/threads are running on separate NUMA
node. That should increase memory access latency and increased overhead.
So I used "numactl --cpubind=0" to bind both qemu and virtiofsd to node
0. My machine seems to have two numa nodes. (Each node is having 32
logical processors). Keeping both qemu and virtiofsd on same node
improves throughput further.

So here are the results.

vtfs-none-epool --> cache=none, exclusive thread pool.
vtfs-none-spool --> cache=none, shared thread pool.
vtfs-none-spool-numa --> cache=none, shared thread pool, same numa node


NAMEWORKLOADBandwidth   IOPS
vtfs-none-epool seqread-psync   36(MiB/s)   9392
vtfs-none-spool seqread-psync   68(MiB/s)   17k 
vtfs-none-spool-numaseqread-psync   73(MiB/s)   18k 

vtfs-none-epool seqread-psync-multi 210(MiB/s)  52k 
vtfs-none-spool seqread-psync-multi 260(MiB/s)  65k 
vtfs-none-spool-numaseqread-psync-multi 309(MiB/s)  77k 

vtfs-none-epool seqread-libaio  286(MiB/s)  71k 
vtfs-none-spool seqread-libaio  328(MiB/s)  82k 
vtfs-none-spool-numaseqread-libaio  332(MiB/s)  83k 

vtfs-none-epool seqread-libaio-multi201(MiB/s)  50k 
vtfs-none-spool seqread-libaio-multi254(MiB/s)  63k 
vtfs-none-spool-numaseqread-libaio-multi276(MiB/s)  69k 

vtfs-none-epool randread-psync  40(MiB/s)   10k 
vtfs-none-spool randread-psync  64(MiB/s)   16k 
vtfs-none-spool-numarandread-psync  72(MiB/s)   18k 

vtfs-none-epool randread-psync-multi211(MiB/s)  52k 
vtfs-none-spool randread-psync-multi252(MiB/s)  63k 
vtfs-none-spool-numarandread-psync-multi297(MiB/s)  74k 

vtfs-none-epool randread-libaio 313(MiB/s)  78k 
vtfs-none-spool randread-libaio 320(MiB/s)  80k 
vtfs-none-spool-numarandread-libaio 330(MiB/s)  82k 

vtfs-none-epool randread-libaio-multi   257(MiB/s)  64k 
vtfs-none-spool randread-libaio-multi   274(MiB/s)  68k 
vtfs-none-spool-numarandread-libaio-multi   319(MiB/s)  79k 

vtfs-none-epool seqwrite-psync  34(MiB/s)   8926
vtfs-none-spool seqwrite-psync  55(MiB/s)   13k 
vtfs-none-spool-numaseqwrite-psync  66(MiB/s)   16k 

vtfs-none-epool seqwrite-psync-multi196(MiB/s)  49k 
vtfs-none-spool seqwrite-psync-multi225(MiB/s)  56k 
vtfs-none-spool-numaseqwrite-psync-multi270(MiB/s)  67k 

vtfs-none-epool seqwrite-libaio 257(MiB/s)  64k 
vtfs-none-spool seqwrite-libaio 304(MiB/s)  76k 
vtfs-none-spool-numaseqwrite-libaio 267(MiB/s)  66k 

vtfs-none-epool seqwrite-libaio-multi   312(MiB/s)  78k 
vtfs-none-spool seqwrite-libaio-multi   366(MiB/s)  91k 
vtfs-none-spool-numaseqwrite-libaio-multi   381(MiB/s)  95k 

vtfs-none-epool randwrite-psync 38(MiB/s)   9745
vtfs-none-spool randwrite-psync 55(MiB/s)   13k 

Re: [PATCH v3 7/8] hw/arm/raspi: Use RaspiProcessorId to set the firmware load address

[Luc Michel]

Hi Phil,

Just two small typos in the commit message.

On 9/21/20 9:56 AM, Philippe Mathieu-Daudé wrote:

The firmware load address depends of the SoC ("processor id") used,

"depends on"

not of the version of the board.

"not on"

Otherwise:

Reviewed-by: Luc Michel 




Signed-off-by: Philippe Mathieu-Daudé 
---
  hw/arm/raspi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 0d8e5a34c78..ae98a2fbfca 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -238,7 +238,8 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
   * the normal Linux boot process
   */
  if (machine->firmware) {
-hwaddr firmware_addr = version == 3 ? FIRMWARE_ADDR_3 : 
FIRMWARE_ADDR_2;
+hwaddr firmware_addr = processor_id <= PROCESSOR_ID_BCM2836
+ ? FIRMWARE_ADDR_2 : FIRMWARE_ADDR_3;
  /* load the firmware image (typically kernel.img) */
  r = load_image_targphys(machine->firmware, firmware_addr,
  ram_size - firmware_addr);

Re: [PATCH v2 5/5] hw/arm/bcm2835_peripherals: Correctly wire the SYS_timer IRQs

[Luc Michel]

On 9/21/20 5:52 AM, Philippe Mathieu-Daudé wrote:

The SYS_timer is not directly wired to the ARM core, but to the
SoC (peripheral) interrupt controller.

Fixes: 0e5bbd74064 ("hw/arm/bcm2835_peripherals: Use the SYS_timer")
Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Luc Michel 


---
  hw/arm/bcm2835_peripherals.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
index 15c5c72e465..48909a43c32 100644
--- a/hw/arm/bcm2835_peripherals.c
+++ b/hw/arm/bcm2835_peripherals.c
@@ -171,8 +171,17 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
  memory_region_add_subregion(>peri_mr, ST_OFFSET,
  sysbus_mmio_get_region(SYS_BUS_DEVICE(>systmr), 0));
  sysbus_connect_irq(SYS_BUS_DEVICE(>systmr), 0,
-qdev_get_gpio_in_named(DEVICE(>ic), BCM2835_IC_ARM_IRQ,
-   INTERRUPT_ARM_TIMER));
+qdev_get_gpio_in_named(DEVICE(>ic), BCM2835_IC_GPU_IRQ,
+   INTERRUPT_TIMER0));
+sysbus_connect_irq(SYS_BUS_DEVICE(>systmr), 1,
+qdev_get_gpio_in_named(DEVICE(>ic), BCM2835_IC_GPU_IRQ,
+   INTERRUPT_TIMER1));
+sysbus_connect_irq(SYS_BUS_DEVICE(>systmr), 2,
+qdev_get_gpio_in_named(DEVICE(>ic), BCM2835_IC_GPU_IRQ,
+   INTERRUPT_TIMER2));
+sysbus_connect_irq(SYS_BUS_DEVICE(>systmr), 3,
+qdev_get_gpio_in_named(DEVICE(>ic), BCM2835_IC_GPU_IRQ,
+   INTERRUPT_TIMER3));
  
  /* UART0 */

  qdev_prop_set_chr(DEVICE(>uart0), "chardev", serial_hd(0));

Re: [PATCH v3 2/8] hw/arm/raspi: Load the firmware on the first core

[Luc Michel]

On 9/21/20 9:56 AM, Philippe Mathieu-Daudé wrote:

The 'first_cpu' is more a QEMU accelerator-related concept
than a variable the machine requires to use.
Since the machine is aware of its CPUs, directly use the
first one to load the firmware.

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Luc Michel 


---
  hw/arm/raspi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 46d9ed7f054..8716a80a75e 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -205,6 +205,7 @@ static void reset_secondary(ARMCPU *cpu, const struct 
arm_boot_info *info)
  
  static void setup_boot(MachineState *machine, int version, size_t ram_size)

  {
+RaspiMachineState *s = RASPI_MACHINE(machine);
  static struct arm_boot_info binfo;
  int r;
  
@@ -253,7 +254,7 @@ static void setup_boot(MachineState *machine, int version, size_t ram_size)

  binfo.firmware_loaded = true;
  }
  
-arm_load_kernel(ARM_CPU(first_cpu), machine, );

+arm_load_kernel(>soc.cpu[0].core, machine, );
  }
  
  static void raspi_machine_init(MachineState *machine)

Re: [PATCH v4 04/11] disas: Move host asm annotations to tb_gen_code

[Richard Henderson]

On 9/21/20 12:29 PM, Alex Bennée wrote:
> 
> Richard Henderson  writes:
> 
>> Instead of creating GStrings and passing them into log_disas,
>> just print the annotations directly in tb_gen_code.
>>
>> Fix the annotations for the slow paths of the TB, after the
>> part implementing the final guest instruction.
>>
>> Reviewed-by: Thomas Huth 
>> Signed-off-by: Richard Henderson 
> 
> I guess what we loose in the inline annotation we gain in simpler code.
> We can always grep stuff out of the logs if we need to:

What information do you think we're losing?


r~

Re: [PATCH v3 3/8] hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState

[Luc Michel]

On 9/21/20 9:56 AM, Philippe Mathieu-Daudé wrote:

The arm_boot_info structure belong to the machine,
move it to RaspiMachineState.

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Luc Michel 


---
  hw/arm/raspi.c | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 8716a80a75e..16e6c83c925 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -41,6 +41,7 @@ struct RaspiMachineState {
  MachineState parent_obj;
  /*< public >*/
  BCM283XState soc;
+struct arm_boot_info binfo;
  };
  typedef struct RaspiMachineState RaspiMachineState;
  
@@ -206,12 +207,11 @@ static void reset_secondary(ARMCPU *cpu, const struct arm_boot_info *info)

  static void setup_boot(MachineState *machine, int version, size_t ram_size)
  {
  RaspiMachineState *s = RASPI_MACHINE(machine);
-static struct arm_boot_info binfo;
  int r;
  
-binfo.board_id = MACH_TYPE_BCM2708;

-binfo.ram_size = ram_size;
-binfo.nb_cpus = machine->smp.cpus;
+s->binfo.board_id = MACH_TYPE_BCM2708;
+s->binfo.ram_size = ram_size;
+s->binfo.nb_cpus = machine->smp.cpus;
  
  if (version <= 2) {

  /* The rpi1 and 2 require some custom setup code to run in Secure
@@ -220,21 +220,21 @@ static void setup_boot(MachineState *machine, int 
version, size_t ram_size)
   * firmware for some cache maintenance operations.
   * The rpi3 doesn't need this.
   */
-binfo.board_setup_addr = BOARDSETUP_ADDR;
-binfo.write_board_setup = write_board_setup;
-binfo.secure_board_setup = true;
-binfo.secure_boot = true;
+s->binfo.board_setup_addr = BOARDSETUP_ADDR;
+s->binfo.write_board_setup = write_board_setup;
+s->binfo.secure_board_setup = true;
+s->binfo.secure_boot = true;
  }
  
  /* Pi2 and Pi3 requires SMP setup */

  if (version >= 2) {
-binfo.smp_loader_start = SMPBOOT_ADDR;
+s->binfo.smp_loader_start = SMPBOOT_ADDR;
  if (version == 2) {
-binfo.write_secondary_boot = write_smpboot;
+s->binfo.write_secondary_boot = write_smpboot;
  } else {
-binfo.write_secondary_boot = write_smpboot64;
+s->binfo.write_secondary_boot = write_smpboot64;
  }
-binfo.secondary_cpu_reset_hook = reset_secondary;
+s->binfo.secondary_cpu_reset_hook = reset_secondary;
  }
  
  /* If the user specified a "firmware" image (e.g. UEFI), we bypass

@@ -250,11 +250,11 @@ static void setup_boot(MachineState *machine, int 
version, size_t ram_size)
  exit(1);
  }
  
-binfo.entry = firmware_addr;

-binfo.firmware_loaded = true;
+s->binfo.entry = firmware_addr;
+s->binfo.firmware_loaded = true;
  }
  
-arm_load_kernel(>soc.cpu[0].core, machine, );

+arm_load_kernel(>soc.cpu[0].core, machine, >binfo);
  }
  
  static void raspi_machine_init(MachineState *machine)

Re: [PATCH v2 03/17] hw/block/nvme: handle dma errors

[Klaus Jensen]

On Sep 21 09:50, Keith Busch wrote:
> On Fri, Sep 18, 2020 at 10:36:07PM +0200, Klaus Jensen wrote:
> > @@ -466,15 +476,21 @@ static void nvme_post_cqes(void *opaque)
> >  break;
> >  }
> >  
> > -QTAILQ_REMOVE(>req_list, req, entry);
> >  sq = req->sq;
> >  req->cqe.status = cpu_to_le16((req->status << 1) | cq->phase);
> >  req->cqe.sq_id = cpu_to_le16(sq->sqid);
> >  req->cqe.sq_head = cpu_to_le16(sq->head);
> >  addr = cq->dma_addr + cq->tail * n->cqe_size;
> > +ret = pci_dma_write(>parent_obj, addr, (void *)>cqe,
> > +sizeof(req->cqe));
> > +if (ret) {
> > +trace_pci_nvme_err_addr_write(addr);
> > +timer_mod(cq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> > +  500 * SCALE_MS);
> > +break;
> > +}
> > +QTAILQ_REMOVE(>req_list, req, entry);
> 
> Is this error really ever transient such that a retry later may be
> successful? I didn't find a way that appeared that it could be. If not,
> this probably deserves a CFS condition rather than a retry.
> 

I'll admit that I did this patch with the blktests test case in mind,
and that retrying causes the test to pass.

But I think you are right that retrying might not be the right way to
"pass the test".

I tested and setting CFS also passes the test and now actually exercises
the reset path in the kernel. So wins all around.

I am thinking we do the same for a failed read in nvme_process_sq then?


signature.asc
Description: PGP signature

Re: [PATCH v3 1/8] hw/arm/raspi: Display the board revision in the machine description

[Luc Michel]

On 9/21/20 9:56 AM, Philippe Mathieu-Daudé wrote:

Display the board revision in the machine description.

Before:

   $ qemu-system-aarch64 -M help | fgrep raspi
   raspi2   Raspberry Pi 2B
   raspi3   Raspberry Pi 3B

After:

   raspi2   Raspberry Pi 2B (revision 1.1)
   raspi3   Raspberry Pi 3B (revision 1.2)

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Luc Michel 


---
  hw/arm/raspi.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 811eaf52ff5..46d9ed7f054 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -312,7 +312,9 @@ static void raspi_machine_class_init(ObjectClass *oc, void 
*data)
  uint32_t board_rev = (uint32_t)(uintptr_t)data;
  
  rmc->board_rev = board_rev;

-mc->desc = g_strdup_printf("Raspberry Pi %s", board_type(board_rev));
+mc->desc = g_strdup_printf("Raspberry Pi %s (revision 1.%u)",
+   board_type(board_rev),
+   FIELD_EX32(board_rev, REV_CODE, REVISION));
  mc->init = raspi_machine_init;
  mc->block_default_type = IF_SD;
  mc->no_parallel = 1;

Re: [PATCH v2 1/5] hw/intc/bcm2835_ic: Trace GPU/CPU IRQ handlers

[Luc Michel]

On 9/21/20 5:52 AM, Philippe Mathieu-Daudé wrote:

Add trace events for GPU and CPU IRQs.

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Luc Michel 


---
  hw/intc/bcm2835_ic.c | 4 +++-
  hw/intc/trace-events | 4 
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/intc/bcm2835_ic.c b/hw/intc/bcm2835_ic.c
index 53ab8f58810..9000d995e81 100644
--- a/hw/intc/bcm2835_ic.c
+++ b/hw/intc/bcm2835_ic.c
@@ -18,6 +18,7 @@
  #include "migration/vmstate.h"
  #include "qemu/log.h"
  #include "qemu/module.h"
+#include "trace.h"
  
  #define GPU_IRQS 64

  #define ARM_IRQS 8
@@ -51,7 +52,6 @@ static void bcm2835_ic_update(BCM2835ICState *s)
  set = (s->gpu_irq_level & s->gpu_irq_enable)
  || (s->arm_irq_level & s->arm_irq_enable);
  qemu_set_irq(s->irq, set);
-
  }
  
  static void bcm2835_ic_set_gpu_irq(void *opaque, int irq, int level)

@@ -59,6 +59,7 @@ static void bcm2835_ic_set_gpu_irq(void *opaque, int irq, int 
level)
  BCM2835ICState *s = opaque;
  
  assert(irq >= 0 && irq < 64);

+trace_bcm2835_ic_set_gpu_irq(irq, level);
  s->gpu_irq_level = deposit64(s->gpu_irq_level, irq, 1, level != 0);
  bcm2835_ic_update(s);
  }
@@ -68,6 +69,7 @@ static void bcm2835_ic_set_arm_irq(void *opaque, int irq, int 
level)
  BCM2835ICState *s = opaque;
  
  assert(irq >= 0 && irq < 8);

+trace_bcm2835_ic_set_cpu_irq(irq, level);
  s->arm_irq_level = deposit32(s->arm_irq_level, irq, 1, level != 0);
  bcm2835_ic_update(s);
  }
diff --git a/hw/intc/trace-events b/hw/intc/trace-events
index 527c3f76cae..22782b3f089 100644
--- a/hw/intc/trace-events
+++ b/hw/intc/trace-events
@@ -199,3 +199,7 @@ nvic_sysreg_write(uint64_t addr, uint32_t value, unsigned size) 
"NVIC sysreg wri
  heathrow_write(uint64_t addr, unsigned int n, uint64_t value) "0x%"PRIx64" %u: 
0x%"PRIx64
  heathrow_read(uint64_t addr, unsigned int n, uint64_t value) "0x%"PRIx64" %u: 
0x%"PRIx64
  heathrow_set_irq(int num, int level) "set_irq: num=0x%02x level=%d"
+
+# bcm2835_ic.c
+bcm2835_ic_set_gpu_irq(int irq, int level) "GPU irq #%d level %d"
+bcm2835_ic_set_cpu_irq(int irq, int level) "CPU irq #%d level %d"

Re: [PATCH v2 3/5] hw/timer/bcm2835: Rename variable holding CTRL_STATUS register

[Luc Michel]

On 9/21/20 5:52 AM, Philippe Mathieu-Daudé wrote:

The variable holding the CTRL_STATUS register is misnamed
'status'. Rename it 'ctrl_status' to make it more obvious
this register is also used to control the peripheral.

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Luc Michel 


---
  include/hw/timer/bcm2835_systmr.h | 2 +-
  hw/timer/bcm2835_systmr.c | 8 
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/hw/timer/bcm2835_systmr.h 
b/include/hw/timer/bcm2835_systmr.h
index 11272837a6b..e0db9e9e12b 100644
--- a/include/hw/timer/bcm2835_systmr.h
+++ b/include/hw/timer/bcm2835_systmr.h
@@ -29,7 +29,7 @@ struct BCM2835SystemTimerState {
  qemu_irq irq;
  
  struct {

-uint32_t status;
+uint32_t ctrl_status;
  uint32_t compare[BCM2835_SYSTIMER_COUNT];
  } reg;
  };
diff --git a/hw/timer/bcm2835_systmr.c b/hw/timer/bcm2835_systmr.c
index ff8c5536610..b234e83824f 100644
--- a/hw/timer/bcm2835_systmr.c
+++ b/hw/timer/bcm2835_systmr.c
@@ -30,7 +30,7 @@ REG32(COMPARE3, 0x18)
  
  static void bcm2835_systmr_update_irq(BCM2835SystemTimerState *s)

  {
-bool enable = !!s->reg.status;
+bool enable = !!s->reg.ctrl_status;
  
  trace_bcm2835_systmr_irq(enable);

  qemu_set_irq(s->irq, enable);
@@ -52,7 +52,7 @@ static uint64_t bcm2835_systmr_read(void *opaque, hwaddr 
offset,
  
  switch (offset) {

  case A_CTRL_STATUS:
-r = s->reg.status;
+r = s->reg.ctrl_status;
  break;
  case A_COMPARE0 ... A_COMPARE3:
  r = s->reg.compare[(offset - A_COMPARE0) >> 2];
@@ -82,7 +82,7 @@ static void bcm2835_systmr_write(void *opaque, hwaddr offset,
  trace_bcm2835_systmr_write(offset, value);
  switch (offset) {
  case A_CTRL_STATUS:
-s->reg.status &= ~value; /* Ack */
+s->reg.ctrl_status &= ~value; /* Ack */
  bcm2835_systmr_update_irq(s);
  break;
  case A_COMPARE0 ... A_COMPARE3:
@@ -133,7 +133,7 @@ static const VMStateDescription bcm2835_systmr_vmstate = {
  .version_id = 1,
  .minimum_version_id = 1,
  .fields = (VMStateField[]) {
-VMSTATE_UINT32(reg.status, BCM2835SystemTimerState),
+VMSTATE_UINT32(reg.ctrl_status, BCM2835SystemTimerState),
  VMSTATE_UINT32_ARRAY(reg.compare, BCM2835SystemTimerState,
   BCM2835_SYSTIMER_COUNT),
  VMSTATE_END_OF_LIST()

Re: [PATCH v2 2/5] hw/timer/bcm2835: Introduce BCM2835_SYSTIMER_COUNT definition

[Luc Michel]

On 9/21/20 5:52 AM, Philippe Mathieu-Daudé wrote:

Use the BCM2835_SYSTIMER_COUNT definition instead of the
magic '4' value.

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Luc Michel 


---
  include/hw/timer/bcm2835_systmr.h | 4 +++-
  hw/timer/bcm2835_systmr.c | 3 ++-
  2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/hw/timer/bcm2835_systmr.h 
b/include/hw/timer/bcm2835_systmr.h
index 64166bd7120..11272837a6b 100644
--- a/include/hw/timer/bcm2835_systmr.h
+++ b/include/hw/timer/bcm2835_systmr.h
@@ -18,6 +18,8 @@ typedef struct BCM2835SystemTimerState 
BCM2835SystemTimerState;
  DECLARE_INSTANCE_CHECKER(BCM2835SystemTimerState, BCM2835_SYSTIMER,
   TYPE_BCM2835_SYSTIMER)
  
+#define BCM2835_SYSTIMER_COUNT 4

+
  struct BCM2835SystemTimerState {
  /*< private >*/
  SysBusDevice parent_obj;
@@ -28,7 +30,7 @@ struct BCM2835SystemTimerState {
  
  struct {

  uint32_t status;
-uint32_t compare[4];
+uint32_t compare[BCM2835_SYSTIMER_COUNT];
  } reg;
  };
  
diff --git a/hw/timer/bcm2835_systmr.c b/hw/timer/bcm2835_systmr.c

index 3387a6214a2..ff8c5536610 100644
--- a/hw/timer/bcm2835_systmr.c
+++ b/hw/timer/bcm2835_systmr.c
@@ -134,7 +134,8 @@ static const VMStateDescription bcm2835_systmr_vmstate = {
  .minimum_version_id = 1,
  .fields = (VMStateField[]) {
  VMSTATE_UINT32(reg.status, BCM2835SystemTimerState),
-VMSTATE_UINT32_ARRAY(reg.compare, BCM2835SystemTimerState, 4),
+VMSTATE_UINT32_ARRAY(reg.compare, BCM2835SystemTimerState,
+ BCM2835_SYSTIMER_COUNT),
  VMSTATE_END_OF_LIST()
  }
  };

Re: [PATCH v2 4/5] hw/timer/bcm2835: Support the timer COMPARE registers

[Luc Michel]

Hi Phil,

On 9/21/20 5:52 AM, Philippe Mathieu-Daudé wrote:

This peripheral has 1 free-running timer and 4 compare registers.

Only the free-running timer is implemented. Add support the
COMPARE registers (each register is wired to an IRQ).

Reference: "BCM2835 ARM Peripherals" datasheet [*]
 chapter 12 "System Timer":

   The System Timer peripheral provides four 32-bit timer channels
   and a single 64-bit free running counter. Each channel has an
   output compare register, which is compared against the 32 least
   significant bits of the free running counter values. When the
   two values match, the system timer peripheral generates a signal
   to indicate a match for the appropriate channel. The match signal
   is then fed into the interrupt controller.

This peripheral is used since Linux 3.7, commit ee4af5696720
("ARM: bcm2835: add system timer").

[*] https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

Signed-off-by: Philippe Mathieu-Daudé 
---
  include/hw/timer/bcm2835_systmr.h | 11 +++--
  hw/timer/bcm2835_systmr.c | 41 +++
  hw/timer/trace-events |  4 ++-
  3 files changed, 37 insertions(+), 19 deletions(-)

diff --git a/include/hw/timer/bcm2835_systmr.h 
b/include/hw/timer/bcm2835_systmr.h
index e0db9e9e12b..17fdd9d67b2 100644
--- a/include/hw/timer/bcm2835_systmr.h
+++ b/include/hw/timer/bcm2835_systmr.h
@@ -11,6 +11,7 @@
  
  #include "hw/sysbus.h"

  #include "hw/irq.h"
+#include "qemu/timer.h"
  #include "qom/object.h"
  
  #define TYPE_BCM2835_SYSTIMER "bcm2835-sys-timer"

@@ -20,18 +21,24 @@ DECLARE_INSTANCE_CHECKER(BCM2835SystemTimerState, 
BCM2835_SYSTIMER,
  
  #define BCM2835_SYSTIMER_COUNT 4
  
+typedef struct {

+unsigned id;
+QEMUTimer timer;
+qemu_irq irq;
+BCM2835SystemTimerState *state;
+} BCM2835SystemTimerCompare;
+
  struct BCM2835SystemTimerState {
  /*< private >*/
  SysBusDevice parent_obj;
  
  /*< public >*/

  MemoryRegion iomem;
-qemu_irq irq;
-
  struct {
  uint32_t ctrl_status;
  uint32_t compare[BCM2835_SYSTIMER_COUNT];
  } reg;
+BCM2835SystemTimerCompare tmr[BCM2835_SYSTIMER_COUNT];
  };
  
  #endif

diff --git a/hw/timer/bcm2835_systmr.c b/hw/timer/bcm2835_systmr.c
index b234e83824f..43e644f5e45 100644
--- a/hw/timer/bcm2835_systmr.c
+++ b/hw/timer/bcm2835_systmr.c
@@ -28,20 +28,13 @@ REG32(COMPARE1, 0x10)
  REG32(COMPARE2, 0x14)
  REG32(COMPARE3, 0x18)
  
-static void bcm2835_systmr_update_irq(BCM2835SystemTimerState *s)

+static void bcm2835_systmr_timer_expire(void *opaque)
  {
-bool enable = !!s->reg.ctrl_status;
+BCM2835SystemTimerCompare *tmr = opaque;
  
-trace_bcm2835_systmr_irq(enable);

-qemu_set_irq(s->irq, enable);
-}
-
-static void bcm2835_systmr_update_compare(BCM2835SystemTimerState *s,
-  unsigned timer_index)
-{
-/* TODO fow now, since neither Linux nor U-boot use these timers. */
-qemu_log_mask(LOG_UNIMP, "COMPARE register %u not implemented\n",
-  timer_index);
+trace_bcm2835_systmr_timer_expired(tmr->id);
+tmr->state->reg.ctrl_status |= 1 << tmr->id;
+qemu_set_irq(tmr->irq, 1);
  }
  
  static uint64_t bcm2835_systmr_read(void *opaque, hwaddr offset,

@@ -78,16 +71,25 @@ static void bcm2835_systmr_write(void *opaque, hwaddr 
offset,
   uint64_t value, unsigned size)
  {
  BCM2835SystemTimerState *s = BCM2835_SYSTIMER(opaque);
+int index;
  
  trace_bcm2835_systmr_write(offset, value);

  switch (offset) {
  case A_CTRL_STATUS:
  s->reg.ctrl_status &= ~value; /* Ack */
-bcm2835_systmr_update_irq(s);
+for (index = 0; index < ARRAY_SIZE(s->tmr); index++) {
+if (extract32(value, index, 1)) {
+trace_bcm2835_systmr_irq_ack(index);
+qemu_set_irq(s->tmr[index].irq, 0);
+}
+}
  break;
  case A_COMPARE0 ... A_COMPARE3:
-s->reg.compare[(offset - A_COMPARE0) >> 2] = value;
-bcm2835_systmr_update_compare(s, (offset - A_COMPARE0) >> 2);
+index = (offset - A_COMPARE0) >> 2;
+s->reg.compare[index] = value;
+timer_mod(>tmr[index].timer, value);
I think "value" is wrong here. timer_mod takes an absolute time value. 
Here "value" is a 32 bits truncated view of "current_time + some_time".

+trace_bcm2835_systmr_run(index,
+ value - 
qemu_clock_get_us(QEMU_CLOCK_VIRTUAL));

Here also.

I think you can do something like (untested):
   {
   uint64_t now, triggers_at;
   uint32_t clo, triggers_in;

   index = (offset - A_COMPARE0) >> 2;
   s->reg.compare[index] = value;

   /* get the current clock and its truncated 32 bits view */
   now = qemu_clock_get_us(QEMU_CLOCK_VIRTUAL);
   clo = now;

 

Re: [PATCH v4 06/11] disas: Use qemu/bswap.h for bfd endian loads

[Alex Bennée]

Richard Henderson  writes:

> Use the routines we have already instead of open-coding.
>
> Reviewed-by: Philippe Mathieu-Daudé 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée

Re: [PATCH v4 05/11] disas: Clean up CPUDebug initialization

[Alex Bennée]

Richard Henderson  writes:

> Rename several functions, dropping "generic" and making "host"
> vs "target" clearer.  Make a bunch of functions static that are
> not used outside this file. Replace INIT_DISASSEMBLE_INFO with
> a trio of functions.

  "Also clean up a bunch of CODING_STYLE violations."?

>
> Acked-by: Thomas Huth 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée

Re: [PATCH v4 04/11] disas: Move host asm annotations to tb_gen_code

[Alex Bennée]

Richard Henderson  writes:

> Instead of creating GStrings and passing them into log_disas,
> just print the annotations directly in tb_gen_code.
>
> Fix the annotations for the slow paths of the TB, after the
> part implementing the final guest instruction.
>
> Reviewed-by: Thomas Huth 
> Signed-off-by: Richard Henderson 

I guess what we loose in the inline annotation we gain in simpler code.
We can always grep stuff out of the logs if we need to:

Reviewed-by: Alex Bennée 

-- 
Alex Bennée

Re: [RFC PATCH 3/6] hw/sd/sdcard: Do not use legal address '0' for INVALID_ADDRESS

[Paolo Bonzini]

I think we can just bite the bullet and bump the version number. Just like
not all boards are created equal in terms of migration compatibility,
neither are all devices.

Unfortunately pflash is among those that need some care, but we have much
more leeway with sdhci-pci.

Paolo

Il lun 21 set 2020, 17:08 Markus Armbruster  ha scritto:

> Philippe Mathieu-Daudé  writes:
>
> > On 9/21/20 2:24 PM, Dr. David Alan Gilbert wrote:
> >> * Markus Armbruster (arm...@redhat.com) wrote:
> >>> Philippe Mathieu-Daudé  writes:
> >>>
>  +Paolo & Kevin.
> 
>  On 9/21/20 10:40 AM, Markus Armbruster wrote:
> > Philippe Mathieu-Daudé  writes:
> >
> >> As it is legal to WRITE/ERASE the address/block 0,
> >> change the value of this definition to an illegal
> >> address: UINT32_MAX.
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >> ---
> >> Cc: Dr. David Alan Gilbert 
> >> Cc: Markus Armbruster 
> >>
> >> Same problem I had with the pflash device last year...
> >> This break migration :(
> >> What is the best way to do this?
> >
> > Remind me: did we solve the problem with pflash, and if yes, how?
> 
>  No we can't. The best I could do is add a comment and as this
>  is not fixable. See commit aba53a12bd5: ("hw/block/pflash_cfi01:
>  Document use of non-CFI compliant command '0x00'").
> 
>  I now consider the device in maintenance-only
>  mode and won't add any new features.
> 
>  I started working on a new implementation, hoping it can be a
>  drop in replacement. Laszlo still has hope that QEMU pflash
>  device will support sector locking so firmware developers could
>  test upgrading fw in VMs.
> 
>  Back to the SDcard, it might be less critical, so a migration
>  breaking change might be acceptable. I'm only aware of Paolo
>  and Kevin using this device for testing. Not sure of its
>  importance in production.
> >>>
> >>> Neither am I.
> >>>
> >>> Which machine types include this device by default?
> >>
> >> To me it looks like it's some of the ARM boards.
> >
> > My worry is TYPE_PCI_SDHCI ("sdhci-pci"):
> >
> > k->vendor_id = PCI_VENDOR_ID_REDHAT;
> > k->device_id = PCI_DEVICE_ID_REDHAT_SDHCI;
> > k->class_id = PCI_CLASS_SYSTEM_SDHCI;
> >
> > config SDHCI_PCI
> > bool
> > default y if PCI_DEVICES
>
> Ah, now I remember.  Not the first time I wished it wouldn't exist...
>
> >>> How can a non-default device be added, and to which machine types?
> >>>
> >>> I gather the fix changes device state incompatibly.  Always, or only in
> >>> certain states?
>
> I think we need to answer this question.
>
> >>>  I'm asking because if device state remains compatible
> >>> most of the time, we might be able use subsection trickery to keep
> >>> migration working most of the time.  Has been done before, I think.
>
>

Re: [PATCH v2 00/17] hw/block/nvme: multiple namespaces support

[Keith Busch]

Other than the comments on patches 3 and 9, the rest of the series looks
good to me.

Reviewed-by: Keith Busch