date:20210301

Re: [PATCH v2 2/5] hw/arm: ast2600: Set AST2600_MAX_IRQ to value from datasheet

2021-03-01 Thread Philippe Mathieu-Daudé

On 3/1/21 2:06 AM, Andrew Jeffery wrote:
> The datasheet says we have 197 IRQs allocated, and we need more than 128
> to describe IRQs from LPC devices. Raise the value now to allow
> modelling of the LPC devices.
> 
> Signed-off-by: Andrew Jeffery 
> ---
>  hw/arm/aspeed_ast2600.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé

Re: [PULL 27/29] vl: deprecate -writeconfig

2021-03-01 Thread Markus Armbruster

Paolo Bonzini  writes:

> The functionality of -writeconfig is limited and the code
> does not even try to detect cases where it prints incorrect
> syntax (for example if values have a quote in them, since
> qemu_config_parse does not support any kind of escaping)
> so remove it.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  docs/system/deprecated.rst | 7 +++
>  qemu-options.hx| 7 +--
>  softmmu/vl.c   | 1 +
>  3 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index 2fcac7861e..561c916da2 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -146,6 +146,13 @@ library enabled as a cryptography provider.
>  Neither the ``nettle`` library, or the built-in cryptography provider are
>  supported on FIPS enabled hosts.
>  
> +``-writeconfig`` (since 6.0)
> +'
> +
> +The ``-writeconfig`` option is not able to serialize the entire contents
> +of the QEMU command line.  It is thus considered a failed experiment
> +and deprecated, with no current replacement.
> +
>  QEMU Machine Protocol (QMP) commands
>  
>  
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 34be5a7a2d..252db9357c 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4335,13 +4335,8 @@ SRST
>  ERST
>  DEF("writeconfig", HAS_ARG, QEMU_OPTION_writeconfig,
>  "-writeconfig \n"
> -"read/write config file\n", QEMU_ARCH_ALL)
> +"read/write config file (deprecated)\n", QEMU_ARCH_ALL)
>  SRST
> -``-writeconfig file``
> -Write device configuration to file. The file can be either filename
> -to save command line and device configuration into file or dash
> -``-``) character to print the output to stdout. This can be later
> -used as input file for ``-readconfig`` option.
>  ERST
>  
>  DEF("no-user-config", 0, QEMU_OPTION_nouserconfig,
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index b219ce1f35..6d8393b6f7 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -3356,6 +3356,7 @@ void qemu_init(int argc, char **argv, char **envp)
>  case QEMU_OPTION_writeconfig:
>  {
>  FILE *fp;
> +warn_report("-writeconfig is deprecated.  It will go 
> away in QEMU 6.2 with no replacement");
>  if (strcmp(optarg, "-") == 0) {
>  fp = stdout;
>  } else {

Forgot to tweak the warning to "-writeconfig is deprecated and will go
away without a replacement"?

Re: [PATCH v2 3/5] hw/arm: ast2600: Correct the iBT interrupt ID

2021-03-01 Thread Philippe Mathieu-Daudé

On 3/1/21 2:06 AM, Andrew Jeffery wrote:
> The AST2600 allocates distinct GIC IRQs for the LPC subdevices such as
> the iBT device. Previously on the AST2400 and AST2500 the LPC subdevices
> shared a single LPC IRQ.
> 
> Signed-off-by: Andrew Jeffery 
> ---
>  hw/arm/aspeed_ast2600.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH 1/2] target/mips: Fold jazz behaviour into mips_cpu_do_transaction_failed

2021-03-01 Thread Philippe Mathieu-Daudé

On 2/28/21 10:39 PM, Richard Henderson wrote:
> On 2/28/21 8:14 AM, Philippe Mathieu-Daudé wrote:
>>> +/* Used for the jazz board to modify mips_cpu_do_transaction_failed. */
>>
>> Isn't it possible to have other (old) boards doing something similar?
> 
> It's possible, but I doubt any need to.
> 
> I think the comment in hw/mips/jazz.c is correct, in essence.  That we're
> simply being bug-compatible with older qemu, and that 

"... we don't know if ..."

> real jazz hw does not
> discriminate between instruction and data loads.
We could figure it out by suggesting a test to linux-mips list,
one subscriber still has a working Jazz board.

Re: issue with meson and recursion: negation missing in add?

2021-03-01 Thread Philippe Mathieu-Daudé

On 2/27/21 11:23 PM, Claudio Fontana wrote:
> Hi Paolo,
> 
> I don't know how to handle an issue in the current way we are using meson 
> with recursion, ie always recursing,
> and testing multiple options inside the recursed directory.
> 
> In the case of ARM, we have:
> 
> target/arm/tcg/meson.build,
> 
> where I need to check all the time for TCG, given our current standard of 
> always recursing.
> 
> Besides being error-prone to always remember to check for CONFIG_TCG,
> 
> how do I add some object conditionally on whether CONFIG_TCG is true, but 
> TARGET_AARCH64 is false?
> 
> I'd need something like:
> 
> arm_ss.add(when: [!TARGET_AARCH64,'CONFIG_TCG'], if_true: files(
>   'tcg-cpu-models.c',
> ))
> 
> but the negation !TARGET_AARCH64 is a syntax error... is there any way to 
> negate the condition?

Funny, I asked Paolo the same question last week on IRC, but:

- I also included TARGET_SIZE in the when:
- your email is clearer than my questions :)

> 
> Also as we nest directories more and more, it seems to me that this becomes 
> more and more confusing.
> 
> How about dropping the idea to recurse always unconditionally?
> 
> Thanks!
> 
> Claudio
> 
>

Re: [PATCH 1/3] docs: vhost-user: clean up request/reply description

2021-03-01 Thread Philippe Mathieu-Daudé

On 2/26/21 3:34 PM, Paolo Bonzini wrote:
> It is not necessary to mention which side is sending/receiving
> each payload; it is more interesting to say which is the request
> and which is the reply.  This also matches what vhost-user-gpu.rst
> already does.
> 
> While at it, ensure that all messages list both the request and
> the reply payload.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  docs/interop/vhost-user.rst | 163 +---
>  1 file changed, 95 insertions(+), 68 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v4 2/4] util/qemu-sockets.c: Split host:port parsing out of inet_parse

2021-03-01 Thread Markus Armbruster

Samuel Thibault  writes:

> Hello,
>
> Daniel P. Berrangé, le lun. 22 févr. 2021 09:39:41 +, a ecrit:
>> In general callers shouldn't care about which format was parsed. The use
>> of [] is just a mechanism to reliably separate the port from the address.
>> Once you have the address part getaddrinfo() will reliably parse the
>> address into a sockaddr struct on its own.
>
> Agreed.
>
>> The is_v6 flag is only needed
>> for the legacy compat needs in slirp, even that is only if we want to 
>> have strict equivalence with historical behaviour, as opposed to changing
>> empty string to mean to listen on both IPv4+6 concurrently..
>
> I would say that empty address meaning ipv4+6 looks better to me.
>
> Doug Evans, le lun. 22 févr. 2021 09:55:09 -0800, a ecrit:
>> Hi guys. I think before I submit yet another patchset in this series I need
>> someone with authority to define the user API for ipv6 host forwarding.
>> Since the hostfwd syntax is parsed in net/slirp.c, Samuel I think that means
>> you (based on what I'm reading in MAINTAINERS).
>
> Well, I'm not maintainer of the user API actually. That'd rather be
> Markus Armbruster, now Cc-ed, who devises the command-line options,
> QAPI, etc.

I rarely devise, I just try to keep things sane by reviewing and
advising, with the help of others.

>> Based on what Maxim originally wrote I was going with addresses wrapped in []
>> mean ipv6, but Daniel does not want that.
>
> Specifying [127.0.0.1] would be odd, but for instance 
>
> ssh localhost -D '[127.0.0.1]':23456
>
> happens to listen on 127.0.0.1. So I would say that common practice
> really is that [] only matters for syntax, and not semantic.

I believe common syntactic practice is to use [brackets] only around
numeric IPv6 addresses.  E.g. socat(1):

   IP address
  An IPv4 address in numbers-and-dots notation, an IPv6 address in
  hex notation enclosed in brackets, or a hostname  that  resolves
  to an IPv4 or an IPv6 address.
  Examples: 127.0.0.1, [::1], www.dest-unreach.org, dns1

[...]

Re: [PATCH] hw/pci: Have safer pcie_bus_realize() by checking error path

2021-03-01 Thread Philippe Mathieu-Daudé

ping?

On 2/1/21 4:37 PM, Philippe Mathieu-Daudé wrote:
> While pci_bus_realize() currently does not use the Error* argument,
> it would be an error to leave pcie_bus_realize() setting bus->flags
> if pci_bus_realize() had failed.
> 
> Fix by using a local Error* and return early (propagating the error)
> if pci_bus_realize() failed.
> 
> Reported-by: Markus Armbruster 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/pci/pci.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 512e9042ffa..0d12e94a02e 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -130,8 +130,13 @@ static void pci_bus_realize(BusState *qbus, Error **errp)
>  static void pcie_bus_realize(BusState *qbus, Error **errp)
>  {
>  PCIBus *bus = PCI_BUS(qbus);
> +Error *local_err = NULL;
>  
> -pci_bus_realize(qbus, errp);
> +pci_bus_realize(qbus, &local_err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
>  
>  /*
>   * A PCI-E bus can support extended config space if it's the root
>

Re: [PATCH] gitlab-ci: Disable vhost-kernel in build-disable job

2021-03-01 Thread Philippe Mathieu-Daudé

ping?

On 1/31/21 11:46 AM, Philippe Mathieu-Daudé wrote:
> Commit 299e6f19b3e ("vhost-net: revamp configure logic") added
> the --enable-vhost-kernel option.
> Disable it in the build-disable job.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  .gitlab-ci.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 7c0db64710b..e8390314d89 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -346,6 +346,7 @@ build-disabled:
>--disable-vhost-crypto
>--disable-vhost-net
>--disable-vhost-scsi
> +  --disable-vhost-kernel
>--disable-vhost-user
>--disable-vhost-vdpa
>--disable-vhost-vsock
>

[PATCH v2 1/3] migration/ram: Modify the code comment of ram_save_host_page()

2021-03-01 Thread Kunkun Jiang

The ram_save_host_page() has been modified several times
since its birth. But the comment hasn't been modified as it should
be. It'd better to modify the comment to explain ram_save_host_page()
more clearly.

Signed-off-by: Keqian Zhu 
Signed-off-by: Kunkun Jiang 
---
 migration/ram.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 72143da0ac..24967cb970 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1970,15 +1970,13 @@ static int ram_save_target_page(RAMState *rs, 
PageSearchStatus *pss,
 }
 
 /**
- * ram_save_host_page: save a whole host page
+ * ram_save_host_page: save a whole host page or the rest of a RAMBlock
  *
- * Starting at *offset send pages up to the end of the current host
- * page. It's valid for the initial offset to point into the middle of
- * a host page in which case the remainder of the hostpage is sent.
- * Only dirty target pages are sent. Note that the host page size may
- * be a huge page for this block.
- * The saving stops at the boundary of the used_length of the block
- * if the RAMBlock isn't a multiple of the host page size.
+ * Send dirty pages between pss->page and either the end of that page
+ * or the used_length of the RAMBlock, whichever is smaller.
+ *
+ * Note that if the host page is a huge page, pss->page may be in the
+ * middle of that page.
  *
  * Returns the number of pages written or negative on error
  *
-- 
2.23.0

[PATCH v2 2/3] migration/ram: Modify ram_save_host_page() to match the comment

2021-03-01 Thread Kunkun Jiang

According to the comment, when the host page is a huge page, the
migration_rate_limit() should be executed. If not, this function
can be omitted to save time.

Signed-off-by: Keqian Zhu 
Signed-off-by: Kunkun Jiang 
---
 migration/ram.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index 24967cb970..3a9115b6dc 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2014,7 +2014,9 @@ static int ram_save_host_page(RAMState *rs, 
PageSearchStatus *pss,
 pages += tmppages;
 pss->page++;
 /* Allow rate limiting to happen in the middle of huge pages */
-migration_rate_limit();
+if (pagesize_bits > 1) {
+migration_rate_limit();
+}
 } while ((pss->page & (pagesize_bits - 1)) &&
  offset_in_ramblock(pss->block,
 ((ram_addr_t)pss->page) << TARGET_PAGE_BITS));
-- 
2.23.0

[PATCH v2 3/3] migration/ram: Optimize ram_save_host_page()

2021-03-01 Thread Kunkun Jiang

Starting from pss->page, ram_save_host_page() will check every page
and send the dirty pages up to the end of the current host page or
the boundary of used_length of the block. If the host page size is
a huge page, the step "check" will take a lot of time.

This will improve performance to use migration_bitmap_find_dirty().

Signed-off-by: Keqian Zhu 
Signed-off-by: Kunkun Jiang 
---
 migration/ram.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 3a9115b6dc..a1374db356 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1991,6 +1991,8 @@ static int ram_save_host_page(RAMState *rs, 
PageSearchStatus *pss,
 int tmppages, pages = 0;
 size_t pagesize_bits =
 qemu_ram_pagesize(pss->block) >> TARGET_PAGE_BITS;
+unsigned long hostpage_boundary =
+QEMU_ALIGN_UP(pss->page + 1, pagesize_bits);
 unsigned long start_page = pss->page;
 int res;
 
@@ -2002,7 +2004,7 @@ static int ram_save_host_page(RAMState *rs, 
PageSearchStatus *pss,
 do {
 /* Check the pages is dirty and if it is send it */
 if (!migration_bitmap_clear_dirty(rs, pss->block, pss->page)) {
-pss->page++;
+pss->page = migration_bitmap_find_dirty(rs, pss->block, pss->page);
 continue;
 }
 
@@ -2012,16 +2014,16 @@ static int ram_save_host_page(RAMState *rs, 
PageSearchStatus *pss,
 }
 
 pages += tmppages;
-pss->page++;
+pss->page = migration_bitmap_find_dirty(rs, pss->block, pss->page);
 /* Allow rate limiting to happen in the middle of huge pages */
 if (pagesize_bits > 1) {
 migration_rate_limit();
 }
-} while ((pss->page & (pagesize_bits - 1)) &&
+} while ((pss->page < hostpage_boundary) &&
  offset_in_ramblock(pss->block,
 ((ram_addr_t)pss->page) << TARGET_PAGE_BITS));
-/* The offset we leave with is the last one we looked at */
-pss->page--;
+/* The offset we leave with is the min boundary of host page and block */
+pss->page = MIN(pss->page, hostpage_boundary) - 1;
 
 res = ram_save_release_protection(rs, pss, start_page);
 return (res < 0 ? res : pages);
-- 
2.23.0

[PATCH v2 0/3] Some modifications about ram_save_host_page()

2021-03-01 Thread Kunkun Jiang

Hi,

This series include patches as below:
Patch 1-2:
- modified the comment and code of ram_save_host_page() to make them match each 
other

Patch 3:
- optimized ram_save_host_page() by using migration_bitmap_find_dirty() to find 
dirty
pages

History:

v1 -> v2:
- Modify ram_save_host_page() comment [David Edmondson]
- Remove 'goto' [David Edmondson]

Kunkun Jiang (3):
  migration/ram: Modify the code comment of ram_save_host_page()
  migration/ram: Modify ram_save_host_page() to match the comment
  migration/ram: Optimize ram_save_host_page()

 migration/ram.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

-- 
2.23.0

Re: [RFC PATCH 0/3] Add migration support for VFIO PCI devices in SMMUv3 nested stage mode

2021-03-01 Thread Kunkun Jiang

kindly ping,
Any comments and reviews are welcome.

Thanks.
Kunkun Jiang.

On 2021/2/19 17:42, Kunkun Jiang wrote:

Hi all,

Since the SMMUv3's nested translation stages[1] has been introduced by Eric, we
need to pay attention to the migration of VFIO PCI devices in SMMUv3 nested
stage
mode. At present, it is not yet supported in QEMU. There are two problems in the
existing framework.

First, the current way to get dirty pages is not applicable to nested stage
mode.
Because of the "Caching Mode", VTD can map the RAM through the host single stage
(giova->hpa). "vfio_listener_log_sync" gets dirty pages by transferring "giova"
to the kernel for the RAM block section of mapped MMIO region. In nested stage
mode, we setup the stage 2 (gpa->hpa) and the stage 1(giova->gpa) separately. So
it is inapplicable to get dirty pages by the current way in nested stage mode.

Second, it also need to pass stage 1 configurations to the destination host
after
the migration. In Eric's patch, it passes the stage 1 configuration to the host
on
each STE update for the devices set the PASID PciOps. The configuration will be
applied at physical level. But the data of physical level will not be sent to
the
destination host. So we have to pass stage 1 configurations to the destination
host after the migration.

This Patch set includes patches as below:
Patch 1-2:
- Refactor the vfio_listener_log_sync and added a new function to get dirty
pages
in nested stage mode.

Patch 3:
- Added the post_load function to vmstate_smmuv3 for passing stage 1
configuration
to the destination host after the migration.

@Eric, Could you please add this Patch set to your future version of
"vSMMUv3/pSMMUv3 2 stage VFIO integration", if you think this Patch set makes
sense? :)

Best Regards
Kunkun Jiang

[1] [RFC,v7,00/26] vSMMUv3/pSMMUv3 2 stage VFIO integration
http://patchwork.ozlabs.org/project/qemu-devel/cover/20201116181349.11908-1-eric.au...@redhat.com/

Kunkun Jiang (3):
vfio: Introduce helpers to mark dirty pages of a RAM section
vfio: Add vfio_prereg_listener_log_sync in nested stage
hw/arm/smmuv3: Post-load stage 1 configurations to the host

hw/arm/smmuv3.c | 60 +
hw/arm/trace-events | 1 +
hw/vfio/common.c| 47 +--
3 files changed, 100 insertions(+), 8 deletions(-)

Re: [PATCH v4 2/4] util/qemu-sockets.c: Split host:port parsing out of inet_parse

2021-03-01 Thread Samuel Thibault

Markus Armbruster, le lun. 01 mars 2021 09:15:41 +0100, a ecrit:
> Samuel Thibault  writes:
> > Specifying [127.0.0.1] would be odd, but for instance 
> >
> > ssh localhost -D '[127.0.0.1]':23456
> >
> > happens to listen on 127.0.0.1. So I would say that common practice
> > really is that [] only matters for syntax, and not semantic.
> 
> I believe common syntactic practice is to use [brackets] only around
> numeric IPv6 addresses.  E.g. socat(1):
> 
>IP address
>   An IPv4 address in numbers-and-dots notation, an IPv6 address in
>   hex notation enclosed in brackets, or a hostname  that  resolves
>   to an IPv4 or an IPv6 address.
>   Examples: 127.0.0.1, [::1], www.dest-unreach.org, dns1

Yes and that's also what ssh documents, but in ssh the brackets happen
to also work for an IPv4 address.

Samuel

1 2 3 4 5 >

1 - 100 of 413 matches

Mail list logo