Re: [PULL 0/1] target/sparc late fix

[M Bazz]

Applied, thanks.

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


The 9.0 Changelog was never updated. Could someone with the permissions
please add the following to the SPARC section:

sparc32: Fixed a longstanding softmmu bug that caused kernel panics
when the UserTxt ASI was accessed. 


Appreciated,
-- Bazz


-- PMM

Re: [PATCH] target/sparc: resolve ASI_USERTXT correctly

[M Bazz]

Hi Henry,

I want to thank you for every chance I get to learn from you. Each
email excites me.

On Sun, Apr 14, 2024 at 1:20 PM Richard Henderson
 wrote:
> The "current" permission, as computed by
>
> > -case ASI_KERNELTXT: /* Supervisor code access */
> > -oi = make_memop_idx(memop, cpu_mmu_index(env_cpu(env), true));
>
> was correct for ASI_KERNELTXT, because as you say "lda" is a supervisor-only 
> instruction
> prior to sparcv9.
>

I noticed that cpu_mmu_index() would have returned MMU_USER_IDX
if the supervisor bit hadn't happened to be set (not sure if this
execution path can
occur for lda). Note that this check is gone in your patch.

I consider you my sensei, so while I'm confident in your work I also
want to show
the things I catch.

If I understand everything you've taught me, then the following patch would
have also satisfied the permissions issue. Could you confirm this please?
The essential change is the MMU_USER_IDX in the call to make_memop_idx()

diff --git a/target/sparc/ldst_helper.c b/target/sparc/ldst_helper.c
index e581bb42ac..be3c03a3b6 100644
--- a/target/sparc/ldst_helper.c
+++ b/target/sparc/ldst_helper.c
@@ -702,6 +702,24 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
target_ulong addr,
 break;
 }
 break;
+case ASI_USERTXT: /* User code access */
+oi = make_memop_idx(memop, MMU_USER_IDX);
+switch (size) {
+case 1:
+ret = cpu_ldb_code_mmu(env, addr, oi, GETPC());
+break;
+case 2:
+ret = cpu_ldw_code_mmu(env, addr, oi, GETPC());
+break;
+default:
+case 4:
+ret = cpu_ldl_code_mmu(env, addr, oi, GETPC());
+break;
+case 8:
+ret = cpu_ldq_code_mmu(env, addr, oi, GETPC());
+break;
+}
+break;
 case ASI_M_TXTC_TAG:   /* SparcStation 5 I-cache tag */
 case ASI_M_TXTC_DATA:  /* SparcStation 5 I-cache data */
 case ASI_M_DATAC_TAG:  /* SparcStation 5 D-cache tag */
@@ -779,7 +797,6 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
target_ulong addr,
 case 0x4c: /* SuperSPARC MMU Breakpoint Action */
 ret = env->mmubpaction;
 break;
-case ASI_USERTXT: /* User code access, XXX */
 default:
 sparc_raise_mmu_fault(cs, addr, false, false, asi, size, GETPC());
 ret = 0;

> Unfortunately, we do not have any good documentation for tcg softmmu or the 
> intended role
> of the mmu_idx.  Partly that's due to the final use of the mmu_idx is 
> target-specific.

I love learning from code, but the lack of documentation definitely
increases the value of your
discourse with me.

Thank you,
Sincerely,
-bazz

Re: [PATCH] target/sparc: resolve ASI_USERTXT correctly

[M Bazz]

Hi Richard,

On Thu, Apr 11, 2024 at 10:16 PM Richard Henderson
 wrote:
>
> On 4/11/24 18:15, M Bazz wrote:
> > diff --git a/target/sparc/ldst_helper.c b/target/sparc/ldst_helper.c
> > index e581bb42ac..4f87e44a93 100644
> > --- a/target/sparc/ldst_helper.c
> > +++ b/target/sparc/ldst_helper.c
> > @@ -684,6 +684,7 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
> > target_ulong addr,
> >   case ASI_M_DIAGS:   /* Turbosparc DTLB Diagnostic */
> >   case ASI_M_IODIAG:  /* Turbosparc IOTLB Diagnostic */
> >   break;
> > +case ASI_USERTXT: /* User code access */
> >   case ASI_KERNELTXT: /* Supervisor code access */
> >   oi = make_memop_idx(memop, cpu_mmu_index(env_cpu(env), true));
>
> No, this also does not work, because it uses the wrong permissions (kernel 
> instead of
> user).  I have just sent a patch to fix both problems.

This thought just came to me. `lda` is a privileged instruction. It has to
run in supervisor mode. So, I'm struggling to understand how the
kernel permission
was wrong. Isn't that the right permission for this instruction?

I just want to have the right understanding, so that I'm more prepared
for the next time.

Here is a related excerpt from the Sparcv8 manual:
"For each instruction access and each normal data access, the IU
appends to the 32-bit
memory address an 8-bit address space identifier, or ASI. The ASI
encodes whether the
processor is in supervisor or user mode, and whether the access is an
instruction or data access.
There are also privileged load/store alternate instructions (see
below) that can provide an arbitrary
ASI with their data addresses."

Thank you,
-bazz

>
>
> r~

Re: [PATCH] target/sparc: Use GET_ASI_CODE for ASI_KERNELTXT and ASI_USERTXT

[M Bazz]

Hi Philippe,

On Fri, Apr 12, 2024 at 7:14 AM Philippe Mathieu-Daudé
 wrote:
>
> Hi Bazz,
>
> On 12/4/24 06:18, M Bazz wrote:
> > On Thu, Apr 11, 2024, 10:15 PM Richard Henderson
> > mailto:richard.hender...@linaro.org>> wrote:
> >
> > Reads are done with execute access.  It is not clear whether writes
> > are legal at all -- for now, leave helper_st_asi unchanged, so that
> > we continue to raise an mmu fault.
> >
> > This generalizes the exiting code for ASI_KERNELTXT to be usable for
> > ASI_USERTXT as well, by passing down the MemOpIdx to use.
> >
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2281
> > <https://gitlab.com/qemu-project/qemu/-/issues/2281>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2059
> > <https://gitlab.com/qemu-project/qemu/-/issues/2059>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1609
> > <https://gitlab.com/qemu-project/qemu/-/issues/1609>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1166
> > <https://gitlab.com/qemu-project/qemu/-/issues/1166>
> > Signed-off-by: Richard Henderson  > <mailto:richard.hender...@linaro.org>>
> > ---
> >   target/sparc/helper.h  |  3 ++
> >   target/sparc/ldst_helper.c | 65 ++
> >   target/sparc/translate.c   | 49 ++--
> >   3 files changed, 95 insertions(+), 22 deletions(-)
>
> > Hi Richard,
> >
> > I see this is in your hands now. I agree with your take on leaving
> > writes alone. I'm also grateful for the opportunity to collaborate with you.
> >
> > It brings a smile for the community members who will be touched by this
> > amazing contribution. I see them happily realizing that this perplexing
> > bug has been solved, and in our case finally able to use the debuggers
> > we love! :D
>
> Does that mean you tested this patch and it resolves your issues?
>
> If so, could you add your 'Tested-by: M Bazz ' tag
> when committing this patch?
>
> Regards,
>
> Phil.

Yes, I can confirm the issue is resolved. Richard has already made the
pull request. I am appreciative of the fast movement on this.

I would like to have my "Tested-by" tag added to the PR, if it's no
trouble. How might I get it there?

Tested-by: M Bazz 

>
> > Thanks for the proper fix, qemu sensei!
> >
> > -bazz
> >
>

Re: [PATCH] target/sparc: Use GET_ASI_CODE for ASI_KERNELTXT and ASI_USERTXT

[M Bazz]

On Thu, Apr 11, 2024, 10:15 PM Richard Henderson <
richard.hender...@linaro.org> wrote:

> Reads are done with execute access.  It is not clear whether writes
> are legal at all -- for now, leave helper_st_asi unchanged, so that
> we continue to raise an mmu fault.
>
> This generalizes the exiting code for ASI_KERNELTXT to be usable for
> ASI_USERTXT as well, by passing down the MemOpIdx to use.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2281
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2059
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1609
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1166
> Signed-off-by: Richard Henderson 
> ---
>  target/sparc/helper.h  |  3 ++
>  target/sparc/ldst_helper.c | 65 ++
>  target/sparc/translate.c   | 49 ++--
>  3 files changed, 95 insertions(+), 22 deletions(-)
>
> diff --git a/target/sparc/helper.h b/target/sparc/helper.h
> index e55fad5b8c..b8087d0d2b 100644
> --- a/target/sparc/helper.h
> +++ b/target/sparc/helper.h
> @@ -32,6 +32,9 @@ DEF_HELPER_FLAGS_3(udiv, TCG_CALL_NO_WG, i64, env, tl,
> tl)
>  DEF_HELPER_FLAGS_3(sdiv, TCG_CALL_NO_WG, i64, env, tl, tl)
>  DEF_HELPER_3(taddcctv, tl, env, tl, tl)
>  DEF_HELPER_3(tsubcctv, tl, env, tl, tl)
> +#if !defined(CONFIG_USER_ONLY) && !defined(TARGET_SPARC64)
> +DEF_HELPER_FLAGS_3(ld_code, TCG_CALL_NO_WG, i64, env, tl, i32)
> +#endif
>  #if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
>  DEF_HELPER_FLAGS_4(ld_asi, TCG_CALL_NO_WG, i64, env, tl, int, i32)
>  DEF_HELPER_FLAGS_5(st_asi, TCG_CALL_NO_WG, void, env, tl, i64, int, i32)
> diff --git a/target/sparc/ldst_helper.c b/target/sparc/ldst_helper.c
> index e581bb42ac..2846a86cc4 100644
> --- a/target/sparc/ldst_helper.c
> +++ b/target/sparc/ldst_helper.c
> @@ -585,7 +585,6 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
> target_ulong addr,
>  #if defined(DEBUG_MXCC) || defined(DEBUG_ASI)
>  uint32_t last_addr = addr;
>  #endif
> -MemOpIdx oi;
>
>  do_check_align(env, addr, size - 1, GETPC());
>  switch (asi) {
> @@ -684,24 +683,6 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
> target_ulong addr,
>  case ASI_M_DIAGS:   /* Turbosparc DTLB Diagnostic */
>  case ASI_M_IODIAG:  /* Turbosparc IOTLB Diagnostic */
>  break;
> -case ASI_KERNELTXT: /* Supervisor code access */
> -oi = make_memop_idx(memop, cpu_mmu_index(env_cpu(env), true));
> -switch (size) {
> -case 1:
> -ret = cpu_ldb_code_mmu(env, addr, oi, GETPC());
> -break;
> -case 2:
> -ret = cpu_ldw_code_mmu(env, addr, oi, GETPC());
> -break;
> -default:
> -case 4:
> -ret = cpu_ldl_code_mmu(env, addr, oi, GETPC());
> -break;
> -case 8:
> -ret = cpu_ldq_code_mmu(env, addr, oi, GETPC());
> -break;
> -}
> -break;
>  case ASI_M_TXTC_TAG:   /* SparcStation 5 I-cache tag */
>  case ASI_M_TXTC_DATA:  /* SparcStation 5 I-cache data */
>  case ASI_M_DATAC_TAG:  /* SparcStation 5 D-cache tag */
> @@ -779,7 +760,6 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
> target_ulong addr,
>  case 0x4c: /* SuperSPARC MMU Breakpoint Action */
>  ret = env->mmubpaction;
>  break;
> -case ASI_USERTXT: /* User code access, XXX */
>  default:
>  sparc_raise_mmu_fault(cs, addr, false, false, asi, size, GETPC());
>  ret = 0;
> @@ -787,6 +767,8 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
> target_ulong addr,
>
>  case ASI_USERDATA: /* User data access */
>  case ASI_KERNELDATA: /* Supervisor data access */
> +case ASI_USERTXT: /* User code access */
> +case ASI_KERNELTXT: /* Supervisor code access */
>  case ASI_P: /* Implicit primary context data access (v9 only?) */
>  case ASI_M_BYPASS:/* MMU passthrough */
>  case ASI_LEON_BYPASS: /* LEON MMU passthrough */
> @@ -1161,6 +1143,49 @@ void helper_st_asi(CPUSPARCState *env, target_ulong
> addr, uint64_t val,
>  #endif
>  }
>
> +uint64_t helper_ld_code(CPUSPARCState *env, target_ulong addr, uint32_t
> oi)
> +{
> +MemOp mop = get_memop(oi);
> +uintptr_t ra = GETPC();
> +uint64_t ret;
> +
> +switch (mop & MO_SIZE) {
> +case MO_8:
> +ret = cpu_ldb_code_mmu(env, addr, oi, ra);
> +if (mop & MO_SIGN) {
> +ret = (int8_t)ret;
> +}
> +break;
> +case MO_16:
> +ret = cpu_ldw_code_mmu(env, addr, oi, ra);
> +if ((mop & MO_BSWAP) != MO_TE) {
> +ret = bswap16(ret);
> +}
> +if (mop & MO_SIGN) {
> +ret = (int16_t)ret;
> +}
> +break;
> +case MO_32:
> +ret = cpu_ldl_code_mmu(env, addr, oi, ra);
> +if ((mop & MO_BSWAP) != MO_TE) {
> +ret = bswap32(ret);
> +}
> +if (mop & MO_SIGN) {
> +ret = (int32_t)ret;
> +}
> 

Re: [PATCH] target/sparc: resolve ASI_USERTXT correctly

[M Bazz]

On Thu, Apr 11, 2024, 5:55 PM Richard Henderson
 wrote:
>
> On 4/11/24 14:29, M Bazz wrote:
> > fixes a longstanding bug which causes a "Nonparity Synchronous Error"
> > kernel panic while using a debugger on Solaris / SunOS systems. The panic
> > would occur on the first attempt to single-step the process.
> >
> > The problem stems from an lda instruction on ASI_USERTXT (8). This asi
> > was not being resolved correctly by resolve_asi().
> >
> > Further details can be found in #2281
> >
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2281
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2059
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1609
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1166
> >
> > Signed-off-by: M Bazz 
> > ---
> >   target/sparc/translate.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/target/sparc/translate.c b/target/sparc/translate.c
> > index 319934d9bd..1596005e22 100644
> > --- a/target/sparc/translate.c
> > +++ b/target/sparc/translate.c
> > @@ -3,6 +3,7 @@
> >
> >  Copyright (C) 2003 Thomas M. Ogrisegg 
> >  Copyright (C) 2003-2005 Fabrice Bellard
> > +   Copyright (C) 2024 M Bazz 
> >
> >  This library is free software; you can redistribute it and/or
> >  modify it under the terms of the GNU Lesser General Public
> > @@ -1159,6 +1160,7 @@ static DisasASI resolve_asi(DisasContext *dc, int 
> > asi, MemOp memop)
> >  || (asi == ASI_USERDATA
> >  && (dc->def->features & CPU_FEATURE_CASA))) {
> >   switch (asi) {
> > +case ASI_USERTXT:/* User text access */
> >   case ASI_USERDATA:   /* User data access */
> >   mem_idx = MMU_USER_IDX;
> >   type = GET_ASI_DIRECT;
>
> I don't believe this is correct, because it operates against the page's 
> "read" permissions
> instead of "execute" permissions.
>
>
> r~

Hi Richard,

Thanks for your guidance. It set me in the right direction. Now I
think I've got the right spot.

function `helper_ld_asi` has a block to help load ASI_KERNELTXT, but the
ASI_USERTXT case defaults to sparc_raise_mmu_fault(); I believe this
is the true culprit
source reference:
https://gitlab.com/qemu-project/qemu/-/blob/master/target/sparc/ldst_helper.c?ref_type=heads#L687

The code for the ASI_KERNELTXT seems generic enough to also use for
ASI_USERTXT verbatim.
See v2 patch below. I've done a `make test` -- all passing (3 skips).
OS boots, and the
debuggers are working without issue. What do you think?

Once we arrive at the right solution, I'll finalize the patch.
-bazz


diff --git a/target/sparc/ldst_helper.c b/target/sparc/ldst_helper.c
index e581bb42ac..4f87e44a93 100644
--- a/target/sparc/ldst_helper.c
+++ b/target/sparc/ldst_helper.c
@@ -684,6 +684,7 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
target_ulong addr,
 case ASI_M_DIAGS:   /* Turbosparc DTLB Diagnostic */
 case ASI_M_IODIAG:  /* Turbosparc IOTLB Diagnostic */
 break;
+case ASI_USERTXT: /* User code access */
 case ASI_KERNELTXT: /* Supervisor code access */
 oi = make_memop_idx(memop, cpu_mmu_index(env_cpu(env), true));
 switch (size) {
@@ -779,7 +780,6 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
target_ulong addr,
 case 0x4c: /* SuperSPARC MMU Breakpoint Action */
 ret = env->mmubpaction;
 break;
-case ASI_USERTXT: /* User code access, XXX */
 default:
 sparc_raise_mmu_fault(cs, addr, false, false, asi, size, GETPC());
 ret = 0;

[PATCH] target/sparc: resolve ASI_USERTXT correctly

[M Bazz]

fixes a longstanding bug which causes a "Nonparity Synchronous Error"
kernel panic while using a debugger on Solaris / SunOS systems. The panic
would occur on the first attempt to single-step the process.

The problem stems from an lda instruction on ASI_USERTXT (8). This asi
was not being resolved correctly by resolve_asi().

Further details can be found in #2281

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2281
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2059
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1609
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1166

Signed-off-by: M Bazz 
---
 target/sparc/translate.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index 319934d9bd..1596005e22 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -3,6 +3,7 @@
 
Copyright (C) 2003 Thomas M. Ogrisegg 
Copyright (C) 2003-2005 Fabrice Bellard
+   Copyright (C) 2024 M Bazz 
 
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
@@ -1159,6 +1160,7 @@ static DisasASI resolve_asi(DisasContext *dc, int asi, 
MemOp memop)
|| (asi == ASI_USERDATA
&& (dc->def->features & CPU_FEATURE_CASA))) {
 switch (asi) {
+case ASI_USERTXT:/* User text access */
 case ASI_USERDATA:   /* User data access */
 mem_idx = MMU_USER_IDX;
 type = GET_ASI_DIRECT;
-- 
2.43.0

[PATCH] guest-agent: improve help for --allow-rpcs and --block-rpcs

[Angel M. Villegas]

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1757

Updates to qga help output and documentation for --allow-rpcs and --blocks-rpcs

Signed-off-by: Angel M. Villegas 
---
 docs/interop/qemu-ga.rst | 8 
 qga/main.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/interop/qemu-ga.rst b/docs/interop/qemu-ga.rst
index 461c5a35ee..72fb75a6f5 100644
--- a/docs/interop/qemu-ga.rst
+++ b/docs/interop/qemu-ga.rst
@@ -81,13 +81,13 @@ Options
 
 .. option:: -b, --block-rpcs=LIST
 
-  Comma-separated list of RPCs to disable (no spaces, use ``help`` to
-  list available RPCs).
+  Comma-separated list of RPCs to disable (no spaces, use ``--block-rpcs=help``
+  to list available RPCs).
 
 .. option:: -a, --allow-rpcs=LIST
 
-  Comma-separated list of RPCs to enable (no spaces, use ``help`` to
-  list available RPCs).
+  Comma-separated list of RPCs to enable (no spaces, use ``--allow-rpcs=help``
+  to list available RPCs).
 
 .. option:: -D, --dump-conf
 
diff --git a/qga/main.c b/qga/main.c
index 8668b9f3d3..bdf5344584 100644
--- a/qga/main.c
+++ b/qga/main.c
@@ -261,9 +261,9 @@ QEMU_COPYRIGHT "\n"
 "  -s, --service service commands: install, uninstall, vss-install, 
vss-uninstall\n"
 #endif
 "  -b, --block-rpcs  comma-separated list of RPCs to disable (no spaces,\n"
-"use \"help\" to list available RPCs)\n"
+"use \"--block-rpcs=help\" to list available RPCs)\n"
 "  -a, --allow-rpcs  comma-separated list of RPCs to enable (no spaces,\n"
-"use \"help\" to list available RPCs)\n"
+"use \"--allow-rpcs=help\" to list available RPCs)\n"
 "  -D, --dump-conf   dump a qemu-ga config file based on current config\n"
 "options / command-line parameters to stdout\n"
 "  -r, --retry-path  attempt re-opening path if it's unavailable or closed\n"
-- 
2.39.2 (Apple Git-143)

Re: [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[John M]

This is happening again in 8.1. I used Windows 95 for a while in 6.1 and it
was fine, but when I tried to upgrade to 8.1, it started happening again. I
tried reducing the memory and it still happens. Not an urgent issue though.

On Mon, Aug 30, 2021 at 2:05 AM Philippe Mathieu-Daudé <
1819...@bugs.launchpad.net> wrote:

> Brad said later after testing v6.1 it was fixed so please disregard
> previous comment ¯\_(ツ)_/¯
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1819289
>
> Title:
>   Windows 95 and Windows 98 will not install or run
>
> Status in QEMU:
>   Fix Released
>
> Bug description:
>   The last version of QEMU I have been able to run Windows 95 or Windows
>   98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
>   either not install or will not run 95 or 98 at all. I have tried every
>   combination of options like isapc or no isapc, cpu pentium  or cpu as
>   486. Tried different memory configurations, but they just don't work
>   anymore.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1819289/+subscriptions
>
>

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  Fix Released

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: regression: insmod module failed in VM with nvdimm on

[chenxiang (M)]

Hi Ard,


在 2022/12/1 19:07, Ard Biesheuvel 写道:

On Thu, 1 Dec 2022 at 09:07, Ard Biesheuvel  wrote:

On Thu, 1 Dec 2022 at 08:15, chenxiang (M)  wrote:

Hi Ard,


在 2022/11/30 16:18, Ard Biesheuvel 写道:

On Wed, 30 Nov 2022 at 08:53, Marc Zyngier  wrote:

On Wed, 30 Nov 2022 02:52:35 +,
"chenxiang (M)"  wrote:

Hi,

We boot the VM using following commands (with nvdimm on)  (qemu
version 6.1.50, kernel 6.0-r4):

How relevant is the presence of the nvdimm? Do you observe the failure
without this?


qemu-system-aarch64 -machine
virt,kernel_irqchip=on,gic-version=3,nvdimm=on  -kernel
/home/kernel/Image -initrd /home/mini-rootfs/rootfs.cpio.gz -bios
/root/QEMU_EFI.FD -cpu host -enable-kvm -net none -nographic -m
2G,maxmem=64G,slots=3 -smp 4 -append 'rdinit=init console=ttyAMA0
ealycon=pl0ll,0x9000 pcie_ports=native pciehp.pciehp_debug=1'
-object memory-backend-ram,id=ram1,size=10G -device
nvdimm,id=dimm1,memdev=ram1  -device ioh3420,id=root_port1,chassis=1
-device vfio-pci,host=7d:01.0,id=net0,bus=root_port1

Then in VM we insmod a module, vmalloc error occurs as follows (kernel
5.19-rc4 is normal, and the issue is still on kernel 6.1-rc4):

estuary:/$ insmod /lib/modules/$(uname -r)/hnae3.ko
[8.186563] vmap allocation for size 20480 failed: use
vmalloc= to increase size

Have you tried increasing the vmalloc size to check that this is
indeed the problem?

[...]


We git bisect the code, and find the patch c5a89f75d2a ("arm64: kaslr:
defer initialization to initcall where permitted").

I guess you mean commit fc5a89f75d2a instead, right?


Do you have any idea about the issue?

I sort of suspect that the nvdimm gets vmap-ed and consumes a large
portion of the vmalloc space, but you give very little information
that could help here...


Ouch. I suspect what's going on here: that patch defers the
randomization of the module region, so that we can decouple it from
the very early init code.

Obviously, it is happening too late now, and the randomized module
region is overlapping with a vmalloc region that is in use by the time
the randomization occurs.

Does the below fix the issue?

The issue still occurs, but it seems decrease the probability, before it
occured almost every time, after the change, i tried 2-3 times, and it
occurs.
But i change back "subsys_initcall" to "core_initcall", and i test more
than 20 times, and it is still ok.


Thank you for confirming. I will send out a patch today.


...but before I do that, could you please check whether the change
below fixes your issue as well?

diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 6ccc7ef600e7c1e1..c8c205b630da1951 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -20,7 +20,11 @@
  #include 
  #include 

-u64 __ro_after_init module_alloc_base;
+/*
+ * Set a reasonable default for module_alloc_base in case
+ * we end up running with module randomization disabled.
+ */
+u64 __ro_after_init module_alloc_base = (u64)_etext - MODULES_VSIZE;
  u16 __initdata memstart_offset_seed;

  struct arm64_ftr_override kaslr_feature_override __initdata;
@@ -30,12 +34,6 @@ static int __init kaslr_init(void)
 u64 module_range;
 u32 seed;

-   /*
-* Set a reasonable default for module_alloc_base in case
-* we end up running with module randomization disabled.
-*/
-   module_alloc_base = (u64)_etext - MODULES_VSIZE;
-
 if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
 pr_info("KASLR disabled on command line\n");
 return 0;
.


We have tested this change, the issue is still and it doesn't fix the issue.

Re: regression: insmod module failed in VM with nvdimm on

[chenxiang (M)]

在 2022/12/1 19:07, Ard Biesheuvel 写道:

On Thu, 1 Dec 2022 at 09:07, Ard Biesheuvel  wrote:

On Thu, 1 Dec 2022 at 08:15, chenxiang (M)  wrote:

Hi Ard,


在 2022/11/30 16:18, Ard Biesheuvel 写道:

On Wed, 30 Nov 2022 at 08:53, Marc Zyngier  wrote:

On Wed, 30 Nov 2022 02:52:35 +,
"chenxiang (M)"  wrote:

Hi,

We boot the VM using following commands (with nvdimm on)  (qemu
version 6.1.50, kernel 6.0-r4):

How relevant is the presence of the nvdimm? Do you observe the failure
without this?


qemu-system-aarch64 -machine
virt,kernel_irqchip=on,gic-version=3,nvdimm=on  -kernel
/home/kernel/Image -initrd /home/mini-rootfs/rootfs.cpio.gz -bios
/root/QEMU_EFI.FD -cpu host -enable-kvm -net none -nographic -m
2G,maxmem=64G,slots=3 -smp 4 -append 'rdinit=init console=ttyAMA0
ealycon=pl0ll,0x9000 pcie_ports=native pciehp.pciehp_debug=1'
-object memory-backend-ram,id=ram1,size=10G -device
nvdimm,id=dimm1,memdev=ram1  -device ioh3420,id=root_port1,chassis=1
-device vfio-pci,host=7d:01.0,id=net0,bus=root_port1

Then in VM we insmod a module, vmalloc error occurs as follows (kernel
5.19-rc4 is normal, and the issue is still on kernel 6.1-rc4):

estuary:/$ insmod /lib/modules/$(uname -r)/hnae3.ko
[8.186563] vmap allocation for size 20480 failed: use
vmalloc= to increase size

Have you tried increasing the vmalloc size to check that this is
indeed the problem?

[...]


We git bisect the code, and find the patch c5a89f75d2a ("arm64: kaslr:
defer initialization to initcall where permitted").

I guess you mean commit fc5a89f75d2a instead, right?


Do you have any idea about the issue?

I sort of suspect that the nvdimm gets vmap-ed and consumes a large
portion of the vmalloc space, but you give very little information
that could help here...


Ouch. I suspect what's going on here: that patch defers the
randomization of the module region, so that we can decouple it from
the very early init code.

Obviously, it is happening too late now, and the randomized module
region is overlapping with a vmalloc region that is in use by the time
the randomization occurs.

Does the below fix the issue?

The issue still occurs, but it seems decrease the probability, before it
occured almost every time, after the change, i tried 2-3 times, and it
occurs.
But i change back "subsys_initcall" to "core_initcall", and i test more
than 20 times, and it is still ok.


Thank you for confirming. I will send out a patch today.


...but before I do that, could you please check whether the change
below fixes your issue as well?


Yes, but i can only reply to you tomorrow as other guy is testing on the 
only environment today.




diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 6ccc7ef600e7c1e1..c8c205b630da1951 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -20,7 +20,11 @@
  #include 
  #include 

-u64 __ro_after_init module_alloc_base;
+/*
+ * Set a reasonable default for module_alloc_base in case
+ * we end up running with module randomization disabled.
+ */
+u64 __ro_after_init module_alloc_base = (u64)_etext - MODULES_VSIZE;
  u16 __initdata memstart_offset_seed;

  struct arm64_ftr_override kaslr_feature_override __initdata;
@@ -30,12 +34,6 @@ static int __init kaslr_init(void)
 u64 module_range;
 u32 seed;

-   /*
-* Set a reasonable default for module_alloc_base in case
-* we end up running with module randomization disabled.
-*/
-   module_alloc_base = (u64)_etext - MODULES_VSIZE;
-
 if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
 pr_info("KASLR disabled on command line\n");
 return 0;
.

Re: regression: insmod module failed in VM with nvdimm on

[chenxiang (M)]

Hi Ard,


在 2022/11/30 16:18, Ard Biesheuvel 写道:

On Wed, 30 Nov 2022 at 08:53, Marc Zyngier  wrote:

On Wed, 30 Nov 2022 02:52:35 +,
"chenxiang (M)"  wrote:

Hi,

We boot the VM using following commands (with nvdimm on)  (qemu
version 6.1.50, kernel 6.0-r4):

How relevant is the presence of the nvdimm? Do you observe the failure
without this?


qemu-system-aarch64 -machine
virt,kernel_irqchip=on,gic-version=3,nvdimm=on  -kernel
/home/kernel/Image -initrd /home/mini-rootfs/rootfs.cpio.gz -bios
/root/QEMU_EFI.FD -cpu host -enable-kvm -net none -nographic -m
2G,maxmem=64G,slots=3 -smp 4 -append 'rdinit=init console=ttyAMA0
ealycon=pl0ll,0x9000 pcie_ports=native pciehp.pciehp_debug=1'
-object memory-backend-ram,id=ram1,size=10G -device
nvdimm,id=dimm1,memdev=ram1  -device ioh3420,id=root_port1,chassis=1
-device vfio-pci,host=7d:01.0,id=net0,bus=root_port1

Then in VM we insmod a module, vmalloc error occurs as follows (kernel
5.19-rc4 is normal, and the issue is still on kernel 6.1-rc4):

estuary:/$ insmod /lib/modules/$(uname -r)/hnae3.ko
[8.186563] vmap allocation for size 20480 failed: use
vmalloc= to increase size

Have you tried increasing the vmalloc size to check that this is
indeed the problem?

[...]


We git bisect the code, and find the patch c5a89f75d2a ("arm64: kaslr:
defer initialization to initcall where permitted").

I guess you mean commit fc5a89f75d2a instead, right?


Do you have any idea about the issue?

I sort of suspect that the nvdimm gets vmap-ed and consumes a large
portion of the vmalloc space, but you give very little information
that could help here...


Ouch. I suspect what's going on here: that patch defers the
randomization of the module region, so that we can decouple it from
the very early init code.

Obviously, it is happening too late now, and the randomized module
region is overlapping with a vmalloc region that is in use by the time
the randomization occurs.

Does the below fix the issue?


The issue still occurs, but it seems decrease the probability, before it 
occured almost every time, after the change, i tried 2-3 times, and it 
occurs.
But i change back "subsys_initcall" to "core_initcall", and i test more 
than 20 times, and it is still ok.




diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 37a9deed2aec..71fb18b2f304 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -90,4 +90,4 @@ static int __init kaslr_init(void)

 return 0;
  }
-subsys_initcall(kaslr_init)
+arch_initcall(kaslr_init)
.

Re: regression: insmod module failed in VM with nvdimm on

[chenxiang (M)]

Hi Marc,


在 2022/11/30 15:53, Marc Zyngier 写道:

On Wed, 30 Nov 2022 02:52:35 +,
"chenxiang (M)"  wrote:

Hi,

We boot the VM using following commands (with nvdimm on)  (qemu
version 6.1.50, kernel 6.0-r4):

How relevant is the presence of the nvdimm? Do you observe the failure
without this?


We didn't see the failure without it.


qemu-system-aarch64 -machine
virt,kernel_irqchip=on,gic-version=3,nvdimm=on  -kernel
/home/kernel/Image -initrd /home/mini-rootfs/rootfs.cpio.gz -bios
/root/QEMU_EFI.FD -cpu host -enable-kvm -net none -nographic -m
2G,maxmem=64G,slots=3 -smp 4 -append 'rdinit=init console=ttyAMA0
ealycon=pl0ll,0x9000 pcie_ports=native pciehp.pciehp_debug=1'
-object memory-backend-ram,id=ram1,size=10G -device
nvdimm,id=dimm1,memdev=ram1  -device ioh3420,id=root_port1,chassis=1
-device vfio-pci,host=7d:01.0,id=net0,bus=root_port1

Then in VM we insmod a module, vmalloc error occurs as follows (kernel
5.19-rc4 is normal, and the issue is still on kernel 6.1-rc4):

estuary:/$ insmod /lib/modules/$(uname -r)/hnae3.ko
[8.186563] vmap allocation for size 20480 failed: use
vmalloc= to increase size

Have you tried increasing the vmalloc size to check that this is
indeed the problem?

[...]


I didn't increase the vmalloc size, but i check the vmall size and i 
think it is big enough when the issue occurs:


estuary:/$ insmod /lib/modules/$(uname -r)/hnae3.ko
[4.879899] vmap allocation for size 20480 failed: use vmalloc= 
to increase size
[4.880643] insmod: vmalloc error: size 16384, vm_struct allocation 
failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0

[4.881802] CPU: 1 PID: 230 Comm: insmod Not tainted 6.1.0-rc4+ #21
[4.882414] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
02/06/2015

[4.883082] Call trace:
[4.88]  dump_backtrace.part.0+0xc4/0xd0
[4.883766]  show_stack+0x20/0x50
[4.884091]  dump_stack_lvl+0x68/0x84
[4.884450]  dump_stack+0x18/0x34
[4.884778]  warn_alloc+0x11c/0x1bc
[4.885124]  __vmalloc_node_range+0x50c/0x64c
[4.885553]  module_alloc+0xf4/0x100
[4.885902]  load_module+0x858/0x1e90
[4.886265]  __do_sys_init_module+0x1c0/0x200
[4.886699]  __arm64_sys_init_module+0x24/0x30
[4.887147]  invoke_syscall+0x50/0x120
[4.887516]  el0_svc_common.constprop.0+0x58/0x190
[4.887993]  do_el0_svc+0x34/0xc0
[4.888327]  el0_svc+0x2c/0xb4
[4.888631]  el0t_64_sync_handler+0xb8/0xbc
[4.889046]  el0t_64_sync+0x19c/0x1a0
[4.889423] Mem-Info:
[4.889639] active_anon:9679 inactive_anon:63094 isolated_anon:0
[4.889639]  active_file:0 inactive_file:0 isolated_file:0
[4.889639]  unevictable:0 dirty:0 writeback:0
[4.889639]  slab_reclaimable:3322 slab_unreclaimable:3082
[4.889639]  mapped:873 shmem:72569 pagetables:34
[4.889639]  sec_pagetables:0 bounce:0
[4.889639]  kernel_misc_reclaimable:0
[4.889639]  free:416212 free_pcp:4414 free_cma:0
[4.893362] Node 0 active_anon:38716kB inactive_anon:252376kB 
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB 
isolated(file):0kB mapped:3492kB dirty:0kB writeback:0kB shmem:290276kB 
shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB 
kernel_stack:1904kB pagetables:136kB sec_pagetables:0kB 
all_unreclaimable? no
[4.896343] Node 0 DMA free:1664848kB boost:0kB min:22528kB 
low:28160kB high:33792kB reserved_highatomic:0KB active_anon:38716kB 
inactive_anon:252376kB active_file:0kB inactive_file:0kB unevictable:0kB 
writepending:0kB present:2097152kB managed:2010376kB mlocked:0kB 
bounce:0kB free_pcp:17704kB local_pcp:3668kB free_cma:0kB

[4.899097] lowmem_reserve[]: 0 0 0 0 0
[4.899466] Node 0 DMA: 2*4kB (UM) 1*8kB (M) 2*16kB (UM) 1*32kB (M) 
2*64kB (ME) 1*128kB (U) 2*256kB (ME) 2*512kB (M) 6*1024kB (UME) 5*2048kB 
(UM) 402*4096kB (M) = 1664848kB
[4.900865] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=1048576kB
[4.901648] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=32768kB
[4.902526] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=2048kB
[4.903354] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=64kB

[4.904173] 72569 total pagecache pages
[4.904524] 0 pages in swap cache
[4.904831] Free swap  = 0kB
[4.905109] Total swap = 0kB
[4.905407] 524288 pages RAM
[4.905696] 0 pages HighMem/MovableOnly
[4.906085] 21694 pages reserved
[4.906388] 0 pages hwpoisoned
insmod: can't insert '/lib/modules/6.1.0-rc4+/hnae3.ko': Cannot allocate 
memory

estuary:/$ insmod /lib/modules/$(uname -r)/hns3.ko
[4.911599] vmap allocation for size 122880 failed: use 
vmalloc= to increase size
insmod: can't insert '/lib/modules/6.1.0-rc4+/hns3.ko': Cannot allocate 
memory

estuary:/$ insmod /lib/modules/$(uname -r)/hclge.ko
[4.917761] vmap allocation for size 319488 failed: use 
vmalloc= to increase size
insmod: ca

regression: insmod module failed in VM with nvdimm on

[chenxiang (M)]

Hi,

We boot the VM using following commands (with nvdimm on)  (qemu version 
6.1.50, kernel 6.0-r4):


qemu-system-aarch64 -machine 
virt,kernel_irqchip=on,gic-version=3,nvdimm=on  -kernel 
/home/kernel/Image -initrd /home/mini-rootfs/rootfs.cpio.gz -bios 
/root/QEMU_EFI.FD -cpu host -enable-kvm -net none -nographic -m 
2G,maxmem=64G,slots=3 -smp 4 -append 'rdinit=init console=ttyAMA0 
ealycon=pl0ll,0x9000 pcie_ports=native pciehp.pciehp_debug=1' 
-object memory-backend-ram,id=ram1,size=10G -device 
nvdimm,id=dimm1,memdev=ram1  -device ioh3420,id=root_port1,chassis=1 
-device vfio-pci,host=7d:01.0,id=net0,bus=root_port1


Then in VM we insmod a module, vmalloc error occurs as follows (kernel 
5.19-rc4 is normal, and the issue is still on kernel 6.1-rc4):


estuary:/$ insmod /lib/modules/$(uname -r)/hnae3.ko
[8.186563] vmap allocation for size 20480 failed: use vmalloc= 
to increase size
[8.187288] insmod: vmalloc error: size 16384, vm_struct allocation 
failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0

[8.188402] CPU: 1 PID: 235 Comm: insmod Not tainted 6.0.0-rc4+ #1
[8.188958] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
02/06/2015

[8.189593] Call trace:
[8.189825]  dump_backtrace.part.0+0xc4/0xd0
[8.190245]  show_stack+0x24/0x40
[8.190563]  dump_stack_lvl+0x68/0x84
[8.190913]  dump_stack+0x18/0x34
[8.191223]  warn_alloc+0x124/0x1b0
[8.191555]  __vmalloc_node_range+0xe4/0x55c
[8.191959]  module_alloc+0xf8/0x104
[8.192305]  load_module+0x854/0x1e70
[8.192655]  __do_sys_init_module+0x1e0/0x220
[8.193075]  __arm64_sys_init_module+0x28/0x34
[8.193489]  invoke_syscall+0x50/0x120
[8.193841]  el0_svc_common.constprop.0+0x58/0x1a0
[8.194296]  do_el0_svc+0x38/0xd0
[8.194613]  el0_svc+0x2c/0xc0
[8.194901]  el0t_64_sync_handler+0x1ac/0x1b0
[8.195313]  el0t_64_sync+0x19c/0x1a0
[8.195672] Mem-Info:
[8.195872] active_anon:17641 inactive_anon:118549 isolated_anon:0
[8.195872]  active_file:0 inactive_file:0 isolated_file:0
[8.195872]  unevictable:0 dirty:0 writeback:0
[8.195872]  slab_reclaimable:3439 slab_unreclaimable:3067
[8.195872]  mapped:877 shmem:135976 pagetables:39 bounce:0
[8.195872]  kernel_misc_reclaimable:0
[8.195872]  free:353735 free_pcp:3210 free_cma:0
[8.199119] Node 0 active_anon:70564kB inactive_anon:474196kB 
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB 
isolated(file):0kB mapped:3508kB dirty:0kB writeback:0kB shmem:543904kB 
shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB 
kernel_stack:1904kB pagetables:156kB all_unreclaimable? no
[8.201683] Node 0 DMA free:1414940kB boost:0kB min:22528kB 
low:28160kB high:33792kB reserved_highatomic:0KB active_anon:70564kB 
inactive_anon:474196kB active_file:0kB inactive_file:0kB unevictable:0kB 
writepending:0kB present:2097152kB managed:2010444kB mlocked:0kB 
bounce:0kB free_pcp:12840kB local_pcp:2032kB free_cma:0kB

[8.204158] lowmem_reserve[]: 0 0 0 0
[8.204481] Node 0 DMA: 1*4kB (E) 1*8kB (U) 1*16kB (U) 2*32kB (UM) 
1*64kB (U) 1*128kB (U) 2*256kB (ME) 2*512kB (ME) 2*1024kB (M) 3*2048kB 
(UM) 343*4096kB (M) = 1414940kB
[8.205881] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=1048576kB
[8.206644] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=32768kB
[8.207381] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=2048kB
[8.208111] Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=64kB

[8.208826] 135976 total pagecache pages
[8.209195] 0 pages in swap cache
[8.209484] Free swap  = 0kB
[8.209733] Total swap = 0kB
[8.209989] 524288 pages RAM
[8.210239] 0 pages HighMem/MovableOnly
[8.210571] 21677 pages reserved
[8.210852] 0 pages hwpoisoned
insmod: can't insert '/lib/modules/6.0.0-rc4+/hnae3.ko': Cannot allocate 
memory


We git bisect the code, and find the patch c5a89f75d2a ("arm64: kaslr: 
defer initialization to initcall where permitted").


Do you have any idea about the issue?


Best Regards,

Xiang Chen

Re: [PATCH 1/2] qga-win: add logging to Windows event log

[M M]

> On 28. 11. 2022., at 21:54, Andrey Drobyshev via  
> wrote:
> 
> This commit allows QGA to write to Windows event log using Win32 API's
> ReportEvent() [1], much like syslog() under *nix guests.
> 
> In order to generate log message definitions we use a very basic message
> text file [2], so that every QGA's message gets ID 1.  The tools
> "windmc" and "windres" respectively are used to generate ".rc" file and
> COFF object file, and then the COFF file is linked into qemu-ga.exe.
> 
> [1] 
> https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-reporteventa
> [2] 
> https://learn.microsoft.com/en-us/windows/win32/eventlog/message-text-files
> 
> Originally-by: Yuri Pudgorodskiy 
> Signed-off-by: Andrey Drobyshev 
> ---
> configure |  3 +++
> qga/installer/qemu-ga.wxs |  5 +
> qga/main.c| 15 ---
> qga/meson.build   | 19 ++-
> qga/messages-win32.mc |  9 +
> 5 files changed, 47 insertions(+), 4 deletions(-)
> create mode 100644 qga/messages-win32.mc
> 
> diff --git a/configure b/configure
> index 26c7bc5154..789a4f6cc9 100755
> --- a/configure
> +++ b/configure
> @@ -372,6 +372,7 @@ smbd="$SMBD"
> strip="${STRIP-${cross_prefix}strip}"
> widl="${WIDL-${cross_prefix}widl}"
> windres="${WINDRES-${cross_prefix}windres}"
> +windmc="${WINDMC-${cross_prefix}windmc}"
> pkg_config_exe="${PKG_CONFIG-${cross_prefix}pkg-config}"
> query_pkg_config() {
> "${pkg_config_exe}" ${QEMU_PKG_CONFIG_FLAGS} "$@"
> @@ -2561,6 +2562,7 @@ if test "$skip_meson" = no; then
>   echo "strip = [$(meson_quote $strip)]" >> $cross
>   echo "widl = [$(meson_quote $widl)]" >> $cross
>   echo "windres = [$(meson_quote $windres)]" >> $cross
> +  echo "windmc = [$(meson_quote $windmc)]" >> $cross
>   if test "$cross_compile" = "yes"; then
> cross_arg="--cross-file config-meson.cross"
> echo "[host_machine]" >> $cross
> @@ -2667,6 +2669,7 @@ preserve_env SMBD
> preserve_env STRIP
> preserve_env WIDL
> preserve_env WINDRES
> +preserve_env WINDMC
> 
> printf "exec" >>config.status
> for i in "$0" "$@"; do
> diff --git a/qga/installer/qemu-ga.wxs b/qga/installer/qemu-ga.wxs
> index 73ce2c4965..d9567836f3 100644
> --- a/qga/installer/qemu-ga.wxs
> +++ b/qga/installer/qemu-ga.wxs
> @@ -110,6 +110,11 @@
>Value="fb0a0d66-c7fb-4e2e-a16b-c4a3bfe8d13b" />
>Value="$(var.QEMU_GA_VERSION)" />
> 
> + + 
> Key="System\CurrentControlSet\Services\EventLog\Application\qemu-ga">
> +   />
> +   Value="[qemu_ga_directory]qemu-ga.exe" />
> +
>   
> 
>   
> diff --git a/qga/main.c b/qga/main.c
> index b3580508fa..10314dfe5d 100644
> --- a/qga/main.c
> +++ b/qga/main.c
> @@ -82,6 +82,7 @@ struct GAState {
> bool logging_enabled;
> #ifdef _WIN32
> GAService service;
> +HANDLE event_log;
Just for the sake of uniformity
shouldn't we close this handle at cleanup_agent() similar to wakeup_event ?

> HANDLE wakeup_event;
> #endif
> bool delimit_response;
> @@ -324,13 +325,14 @@ static void ga_log(const gchar *domain, GLogLevelFlags 
> level,
> }
> 
> level &= G_LOG_LEVEL_MASK;
> -#ifndef _WIN32
> if (g_strcmp0(domain, "syslog") == 0) {
> +#ifndef _WIN32
> syslog(LOG_INFO, "%s: %s", level_str, msg);
> -} else if (level & s->log_level) {
> #else
> -if (level & s->log_level) {
> +ReportEvent(s->event_log, EVENTLOG_INFORMATION_TYPE,
> +0, 1, NULL, 1, 0, , NULL);
> #endif
> +} else if (level & s->log_level) {
> g_autoptr(GDateTime) now = g_date_time_new_now_utc();
> g_autofree char *nowstr = g_date_time_format(now, "%s.%f");
> fprintf(s->log_file, "%s: %s: %s\n", nowstr, level_str, msg);
> @@ -1286,6 +1288,13 @@ static GAState *initialize_agent(GAConfig *config, int 
> socket_activation)
> g_debug("Guest agent version %s started", QEMU_FULL_VERSION);
> 
> #ifdef _WIN32
> +s->event_log = RegisterEventSource(NULL, "qemu-ga");
> +if (!s->event_log) {
> +g_autofree gchar *errmsg = g_win32_error_message(GetLastError());
> +g_critical("unable to register event source: %s", errmsg);
> +return NULL;
> +}
> +
> /* On win32 the state directory is application specific (be it the default
>  * or a user override). We got past the command line parsing; let's create
>  * the directory (with any intermediate directories). If we run into an

Re: [PATCH v2] vfio/pci: Verify each MSI vector to avoid invalid MSI vectors

[chenxiang (M)]

在 2022/11/23 20:08, Marc Zyngier 写道:

On Wed, 23 Nov 2022 01:42:36 +,
chenxiang  wrote:

From: Xiang Chen 

Currently the number of MSI vectors comes from register PCI_MSI_FLAGS
which should be power-of-2 in qemu, in some scenaries it is not the same as
the number that driver requires in guest, for example, a PCI driver wants
to allocate 6 MSI vecotrs in guest, but as the limitation, it will allocate
8 MSI vectors. So it requires 8 MSI vectors in qemu while the driver in
guest only wants to allocate 6 MSI vectors.

When GICv4.1 is enabled, it iterates over all possible MSIs and enable the
forwarding while the guest has only created some of mappings in the virtual
ITS, so some calls fail. The exception print is as following:
vfio-pci :3a:00.1: irq bypass producer (token 8f08224d) registration
fails:66311

To avoid the issue, verify each MSI vector, skip some operations such as
request_irq() and irq_bypass_register_producer() for those invalid MSI vectors.

Signed-off-by: Xiang Chen 
---
I reported the issue at the link:
https://lkml.kernel.org/lkml/87cze9lcut.wl-...@kernel.org/T/

Change Log:
v1 -> v2:
Verify each MSI vector in kernel instead of adding systemcall according to
Mar's suggestion
---
  arch/arm64/kvm/vgic/vgic-irqfd.c  | 13 +
  arch/arm64/kvm/vgic/vgic-its.c| 36 
  arch/arm64/kvm/vgic/vgic.h|  1 +
  drivers/vfio/pci/vfio_pci_intrs.c | 33 +
  include/linux/kvm_host.h  |  2 ++
  5 files changed, 85 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c b/arch/arm64/kvm/vgic/vgic-irqfd.c
index 475059b..71f6af57 100644
--- a/arch/arm64/kvm/vgic/vgic-irqfd.c
+++ b/arch/arm64/kvm/vgic/vgic-irqfd.c
@@ -98,6 +98,19 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e,
return vgic_its_inject_msi(kvm, );
  }
  
+int kvm_verify_msi(struct kvm *kvm,

+  struct kvm_kernel_irq_routing_entry *irq_entry)
+{
+   struct kvm_msi msi;
+
+   if (!vgic_has_its(kvm))
+   return -ENODEV;
+
+   kvm_populate_msi(irq_entry, );
+
+   return vgic_its_verify_msi(kvm, );
+}
+
  /**
   * kvm_arch_set_irq_inatomic: fast-path for irqfd injection
   */
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 94a666d..8312a4a 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -767,6 +767,42 @@ int vgic_its_inject_cached_translation(struct kvm *kvm, 
struct kvm_msi *msi)
return 0;
  }
  
+int vgic_its_verify_msi(struct kvm *kvm, struct kvm_msi *msi)

+{
+   struct vgic_its *its;
+   struct its_ite *ite;
+   struct kvm_vcpu *vcpu;
+   int ret = 0;
+
+   if (!irqchip_in_kernel(kvm) || (msi->flags & ~KVM_MSI_VALID_DEVID))
+   return -EINVAL;
+
+   if (!vgic_has_its(kvm))
+   return -ENODEV;
+
+   its = vgic_msi_to_its(kvm, msi);
+   if (IS_ERR(its))
+   return PTR_ERR(its);
+
+   mutex_lock(>its_lock);
+   if (!its->enabled) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+   ite = find_ite(its, msi->devid, msi->data);
+   if (!ite || !its_is_collection_mapped(ite->collection)) {
+   ret = E_ITS_INT_UNMAPPED_INTERRUPT;
+   goto unlock;
+   }
+
+   vcpu = kvm_get_vcpu(kvm, ite->collection->target_addr);
+   if (!vcpu)
+   ret = E_ITS_INT_UNMAPPED_INTERRUPT;

I'm sorry, but what does this mean to the caller? This should never
leak outside of the ITS code.


Actually it is already leak outside of ITS code, and please see the 
exception printk (E_ITS_INT_UNMAPPED_INTERRUPT is 0x10307 which is equal 
to 66311):


vfio-pci :3a:00.1: irq bypass producer (token 8f08224d) 
registration fails:66311





+unlock:
+   mutex_unlock(>its_lock);
+   return ret;
+}
+
  /*
   * Queries the KVM IO bus framework to get the ITS pointer from the given
   * doorbell address.
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index 0c8da72..d452150 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -240,6 +240,7 @@ int kvm_vgic_register_its_device(void);
  void vgic_enable_lpis(struct kvm_vcpu *vcpu);
  void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu);
  int vgic_its_inject_msi(struct kvm *kvm, struct kvm_msi *msi);
+int vgic_its_verify_msi(struct kvm *kvm, struct kvm_msi *msi);
  int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr 
*attr);
  int vgic_v3_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
 int offset, u32 *val);
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 40c3d7c..3027805 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "vfio_pci_priv.h"
  
@@ -315,6 +316,28 @@ static int 

Re: [PATCH] KVM: Add system call KVM_VERIFY_MSI to verify MSI vector

[chenxiang (M)]

Hi Marc,


在 2022/11/10 18:28, Marc Zyngier 写道:

On Wed, 09 Nov 2022 06:21:18 +,
"chenxiang (M)"  wrote:

Hi Marc,


在 2022/11/8 20:47, Marc Zyngier 写道:

On Tue, 08 Nov 2022 08:08:57 +,
chenxiang  wrote:

From: Xiang Chen 

Currently the numbers of MSI vectors come from register PCI_MSI_FLAGS
which should be power-of-2, but in some scenaries it is not the same as
the number that driver requires in guest, for example, a PCI driver wants
to allocate 6 MSI vecotrs in guest, but as the limitation, it will allocate
8 MSI vectors. So it requires 8 MSI vectors in qemu while the driver in
guest only wants to allocate 6 MSI vectors.

When GICv4.1 is enabled, we can see some exception print as following for
above scenaro:
vfio-pci :3a:00.1: irq bypass producer (token 8f08224d) 
registration fails:66311

In order to verify whether a MSI vector is valid, add KVM_VERIFY_MSI to do
that. If there is a mapping, return 0, otherwise return negative value.

This is the kernel part of adding system call KVM_VERIFY_MSI.

Exposing something that is an internal implementation detail to
userspace feels like the absolute wrong way to solve this issue.

Can you please characterise the issue you're having? Is it that vfio
tries to enable an interrupt for which there is no virtual ITS
mapping? Shouldn't we instead try and manage this in the kernel?

Before i reported the issue to community, you gave a suggestion about
the issue, but not sure whether i misundertood your meaning.
You can refer to the link for more details about the issue.
https://lkml.kernel.org/lkml/87cze9lcut.wl-...@kernel.org/T/

Right. It would have been helpful to mention this earlier. Anyway, I
would really like this to be done without involving userspace at all.

But first, can you please confirm that the VM works as expected
despite the message?

Yes, it works well except the message.


If that's the case, we only need to handle the
case where this is a multi-MSI setup, and I think this can be done in
VFIO, without involving userspace.


It seems we can verify every kvm_msi for multi-MSI setup in function 
vfio_pci_set_msi_trigger().
If it is a invalid MSI vector, then we can decrease the numer of MSI 
vectors before  calling vfio_msi_set_block().




Thanks,

M.

Re: [PATCH] KVM: Add system call KVM_VERIFY_MSI to verify MSI vector

[chenxiang (M)]

Hi Marc,


在 2022/11/8 20:47, Marc Zyngier 写道:

On Tue, 08 Nov 2022 08:08:57 +,
chenxiang  wrote:

From: Xiang Chen 

Currently the numbers of MSI vectors come from register PCI_MSI_FLAGS
which should be power-of-2, but in some scenaries it is not the same as
the number that driver requires in guest, for example, a PCI driver wants
to allocate 6 MSI vecotrs in guest, but as the limitation, it will allocate
8 MSI vectors. So it requires 8 MSI vectors in qemu while the driver in
guest only wants to allocate 6 MSI vectors.

When GICv4.1 is enabled, we can see some exception print as following for
above scenaro:
vfio-pci :3a:00.1: irq bypass producer (token 8f08224d) 
registration fails:66311

In order to verify whether a MSI vector is valid, add KVM_VERIFY_MSI to do
that. If there is a mapping, return 0, otherwise return negative value.

This is the kernel part of adding system call KVM_VERIFY_MSI.

Exposing something that is an internal implementation detail to
userspace feels like the absolute wrong way to solve this issue.

Can you please characterise the issue you're having? Is it that vfio
tries to enable an interrupt for which there is no virtual ITS
mapping? Shouldn't we instead try and manage this in the kernel?


Before i reported the issue to community, you gave a suggestion about 
the issue, but not sure whether i misundertood your meaning.

You can refer to the link for more details about the issue.
https://lkml.kernel.org/lkml/87cze9lcut.wl-...@kernel.org/T/

Best regards,
Xiang

Re: [QUESTION] Exception print when enabling GICv4

[chenxiang (M)]

Hi Marc,

Thank you for your reply.

在 2022/7/12 23:25, Marc Zyngier 写道:

Hi Xiang,

On Tue, 12 Jul 2022 13:55:16 +0100,
"chenxiang (M)"  wrote:

Hi,
I encounter a issue related to GICv4 enable on ARM64 platform (kernel
5.19-rc4, qemu 6.2.0):
We have a accelaration module whose VF has 3 MSI interrupts, and we
passthrough it to virtual machine with following steps:

echo :79:00.1 > /sys/bus/pci/drivers/hisi_hpre/unbind
echo vfio-pci >
/sys/devices/pci\:78/\:78\:00.0/\:79\:00.1/driver_override
echo :79:00.1 > /sys/bus/pci/drivers_probe

Then we boot VM with "-device vfio-pci,host=79:00.1,id=net0 \".
When insmod the driver which registers 3 PCI MSI interrupts in VM,
some exception print occur as following:

vfio-pci :3a:00.1: irq bypass producer (token 8f08224d)
registration fails: 66311

I find that bit[6:4] of register PCI_MSI_FLAGS is 2 (4 MSI interrupts)
though we only register 3 PCI MSI interrupt,

and only 3 MSI interrupt is activated at last.
It allocates 4 vectors in function vfio_msi_enable() (qemu)  as it
reads the register PCI_MSI_FLAGS.
Later it will  call system call VFIO_DEVICE_SET_IRQS to set forwarding
for those interrupts
using function kvm_vgic_v4_set_forrwarding() as GICv4 is enabled. For
interrupt 0~2, it success to set forwarding as they are already
activated,
but for the 4th interrupt, it is not activated, so ite is not found in
function vgic_its_resolve_lpi(), so above printk occurs.

It seems that we only allocate and activate 3 MSI interrupts in guest
while it tried to set forwarding for 4 MSI interrupts in host.
Do you have any idea about this issue?

I have a hunch: QEMU cannot know that the guest is only using 3 MSIs
out of the 4 that the device can use, and PCI/Multi-MSI only has a
single enable bit for all MSIs. So it probably iterates over all
possible MSIs and enable the forwarding. Since the guest has only
created 3 mappings in the virtual ITS, the last call fails. I would
expect the guest to still work properly though.


Yes, that's the reason of exception print.
Is it possible for QEMU to get the exact number of interrupts guest is 
using? It seems not.




Thanks,

M.

[QUESTION] Exception print when enabling GICv4

[chenxiang (M)]

Hi,
I encounter a issue related to GICv4 enable on ARM64 platform (kernel 
5.19-rc4, qemu 6.2.0):
We have a accelaration module whose VF has 3 MSI interrupts, and we 
passthrough it to virtual machine with following steps:


echo :79:00.1 > /sys/bus/pci/drivers/hisi_hpre/unbind
echo vfio-pci > 
/sys/devices/pci\:78/\:78\:00.0/\:79\:00.1/driver_override

echo :79:00.1 > /sys/bus/pci/drivers_probe

Then we boot VM with "-device vfio-pci,host=79:00.1,id=net0 \".
When insmod the driver which registers 3 PCI MSI interrupts in VM,  some 
exception print occur as following:


vfio-pci :3a:00.1: irq bypass producer (token 8f08224d) 
registration fails: 66311


I find that bit[6:4] of register PCI_MSI_FLAGS is 2 (4 MSI interrupts) 
though we only register 3 PCI MSI interrupt,


and only 3 MSI interrupt is activated at last.
It allocates 4 vectors in function vfio_msi_enable() (qemu)  as it reads 
the register PCI_MSI_FLAGS.
Later it will  call system call VFIO_DEVICE_SET_IRQS to set forwarding 
for those interrupts
using function kvm_vgic_v4_set_forrwarding() as GICv4 is enabled. For 
interrupt 0~2, it success to set forwarding as they are already activated,
but for the 4th interrupt, it is not activated, so ite is not found in 
function vgic_its_resolve_lpi(), so above printk occurs.


It seems that we only allocate and activate 3 MSI interrupts in guest 
while it tried to set forwarding for 4 MSI interrupts in host.

Do you have any idea about this issue?


Best regards,

Xiang Chen

Re: [Bug] Take more 150s to boot qemu on ARM64

[chenxiang (M)]

在 2022/6/13 21:22, Paul E. McKenney 写道:

On Mon, Jun 13, 2022 at 08:26:34PM +0800, chenxiang (M) wrote:

Hi all,

I encounter a issue with kernel 5.19-rc1 on a ARM64 board:  it takes about
150s between beginning to run qemu command and beginng to boot Linux kernel
("EFI stub: Booting Linux Kernel...").

But in kernel 5.18-rc4, it only takes about 5s. I git bisect the kernel code
and it finds c2445d387850 ("srcu: Add contention check to call_srcu()
srcu_data ->lock acquisition").

The qemu (qemu version is 6.2.92) command i run is :

./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g \
--trace "kvm*" \
-cpu host \
-machine virt,accel=kvm,gic-version=3  \
-machine smp.cpus=2,smp.sockets=2 \
-no-reboot \
-nographic \
-monitor unix:/home/cx/qmp-test,server,nowait \
-bios /home/cx/boot/QEMU_EFI.fd \
-kernel /home/cx/boot/Image  \
-device 
pcie-root-port,port=0x8,chassis=1,id=net1,bus=pcie.0,multifunction=on,addr=0x1
\
-device vfio-pci,host=7d:01.3,id=net0 \
-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4  \
-drive file=/home/cx/boot/boot_ubuntu.img,if=none,id=drive0 \
-append "rdinit=init console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw " \
-net none \
-D /home/cx/qemu_log.txt

I am not familiar with rcu code, and don't know how it causes the issue. Do
you have any idea about this issue?

Please see the discussion here:

https://lore.kernel.org/all/20615615-0013-5adc-584f-2b1d5c03e...@linaro.org/

Though that report requires ACPI to be forced on to get the
delay, which results in more than 9,000 back-to-back calls to
synchronize_srcu_expedited().  I cannot reproduce this on my setup, even
with an artificial tight loop invoking synchronize_srcu_expedited(),
but then again I don't have ARM hardware.

My current guess is that the following patch, but with larger values for
SRCU_MAX_NODELAY_PHASE.  Here "larger" might well be up in the hundreds,
or perhaps even larger.

If you get a chance to experiment with this, could you please reply
to the discussion at the above URL?  (Or let me know, and I can CC
you on the next message in that thread.)


Ok, thanks, i will reply it on above URL.




Thanx, Paul



diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 50ba70f019dea..0db7873f4e95b 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -513,7 +513,7 @@ static bool srcu_readers_active(struct srcu_struct *ssp)
  
  #define SRCU_INTERVAL		1	// Base delay if no expedited GPs pending.

  #define SRCU_MAX_INTERVAL 10  // Maximum incremental delay from slow 
readers.
-#define SRCU_MAX_NODELAY_PHASE 1   // Maximum per-GP-phase consecutive 
no-delay instances.
+#define SRCU_MAX_NODELAY_PHASE 3   // Maximum per-GP-phase consecutive 
no-delay instances.
  #define SRCU_MAX_NODELAY  100 // Maximum consecutive no-delay 
instances.
  
  /*

@@ -522,16 +522,22 @@ static bool srcu_readers_active(struct srcu_struct *ssp)
   */
  static unsigned long srcu_get_delay(struct srcu_struct *ssp)
  {
+   unsigned long gpstart;
+   unsigned long j;
unsigned long jbase = SRCU_INTERVAL;
  
  	if (ULONG_CMP_LT(READ_ONCE(ssp->srcu_gp_seq), READ_ONCE(ssp->srcu_gp_seq_needed_exp)))

jbase = 0;
-   if (rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq)))
-   jbase += jiffies - READ_ONCE(ssp->srcu_gp_start);
-   if (!jbase) {
-   WRITE_ONCE(ssp->srcu_n_exp_nodelay, 
READ_ONCE(ssp->srcu_n_exp_nodelay) + 1);
-   if (READ_ONCE(ssp->srcu_n_exp_nodelay) > SRCU_MAX_NODELAY_PHASE)
-   jbase = 1;
+   if (rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq))) {
+   j = jiffies - 1;
+   gpstart = READ_ONCE(ssp->srcu_gp_start);
+   if (time_after(j, gpstart))
+   jbase += j - gpstart;
+   if (!jbase) {
+   WRITE_ONCE(ssp->srcu_n_exp_nodelay, 
READ_ONCE(ssp->srcu_n_exp_nodelay) + 1);
+   if (READ_ONCE(ssp->srcu_n_exp_nodelay) > 
SRCU_MAX_NODELAY_PHASE)
+   jbase = 1;
+   }
}
return jbase > SRCU_MAX_INTERVAL ? SRCU_MAX_INTERVAL : jbase;
  }
.

[Bug] Take more 150s to boot qemu on ARM64

[chenxiang (M)]

Hi all,

I encounter a issue with kernel 5.19-rc1 on a ARM64 board:  it takes 
about 150s between beginning to run qemu command and beginng to boot 
Linux kernel ("EFI stub: Booting Linux Kernel...").


But in kernel 5.18-rc4, it only takes about 5s. I git bisect the kernel 
code and it finds c2445d387850 ("srcu: Add contention check to 
call_srcu() srcu_data ->lock acquisition").


The qemu (qemu version is 6.2.92) command i run is :

./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g \
--trace "kvm*" \
-cpu host \
-machine virt,accel=kvm,gic-version=3  \
-machine smp.cpus=2,smp.sockets=2 \
-no-reboot \
-nographic \
-monitor unix:/home/cx/qmp-test,server,nowait \
-bios /home/cx/boot/QEMU_EFI.fd \
-kernel /home/cx/boot/Image  \
-device 
pcie-root-port,port=0x8,chassis=1,id=net1,bus=pcie.0,multifunction=on,addr=0x1 
\

-device vfio-pci,host=7d:01.3,id=net0 \
-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4  \
-drive file=/home/cx/boot/boot_ubuntu.img,if=none,id=drive0 \
-append "rdinit=init console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw " \
-net none \
-D /home/cx/qemu_log.txt

I am not familiar with rcu code, and don't know how it causes the issue. 
Do you have any idea about this issue?



Best Regard,

Xiang Chen

Re: [PATCH] hw/arm/smmuv3: Pass the real perm to returned IOMMUTLBEntry in smmuv3_translate()

[chenxiang (M)]

Hi Eric,


在 2022/4/15 0:02, Eric Auger 写道:

Hi Chenxiang,

On 4/7/22 9:57 AM, chenxiang via wrote:

From: Xiang Chen 

In function memory_region_iommu_replay(), it decides to notify() or not
according to the perm of returned IOMMUTLBEntry. But for smmuv3, the
returned perm is always IOMMU_NONE even if the translation success.

I think you should precise in the commit message that
memory_region_iommu_replay() always calls the IOMMU MR translate()
callback with flag=IOMMU_NONE and thus, currently, translate() returns
an IOMMUTLBEntry with perm set to IOMMU_NONE if the translation
succeeds, whereas it is expected to return the actual permission set in
the table entry.


Thank you for your comments.
I will change the commit message in next version.





Pass the real perm to returned IOMMUTLBEntry to avoid the issue.

Signed-off-by: Xiang Chen 
---
  hw/arm/smmuv3.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 674623aabe..707eb430c2 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -760,7 +760,7 @@ epilogue:
  qemu_mutex_unlock(>mutex);
  switch (status) {
  case SMMU_TRANS_SUCCESS:
-entry.perm = flag;
+entry.perm = cached_entry->entry.perm;

With that clarification
Reviewed-by: Eric Auger 


Ok, thanks



the translate() doc in ./include/exec/memory.h states
"
If IOMMU_NONE is passed then the IOMMU must do the
  * full page table walk and report the permissions in the returned
  * IOMMUTLBEntry. (Note that this implies that an IOMMU may not
  * return different mappings for reads and writes.)
"


Thanks

Eric

  entry.translated_addr = cached_entry->entry.translated_addr +
  (addr & cached_entry->entry.addr_mask);
  entry.addr_mask = cached_entry->entry.addr_mask;

.

Re: [PATCH] hw/vfio/common: Fix a small boundary issue of a trace

[chenxiang (M)]

Hi Damien,


在 2022/4/6 23:22, Damien Hedde 写道:



On 4/6/22 10:14, chenxiang via wrote:

From: Xiang Chen 

Right now the trace of vfio_region_sparse_mmap_entry is as follows:
vfio_region_sparse_mmap_entry sparse entry 0 [0x1000 - 0x9000]
Actually the range it wants to show is [0x1000 - 0x8fff]，so fix it.

Signed-off-by: Xiang Chen 
---
  hw/vfio/common.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 080046e3f5..0b3808caf8 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1546,7 +1546,7 @@ static int 
vfio_setup_region_sparse_mmaps(VFIORegion *region,

  for (i = 0, j = 0; i < sparse->nr_areas; i++) {
  trace_vfio_region_sparse_mmap_entry(i, 
sparse->areas[i].offset,

sparse->areas[i].offset +
- sparse->areas[i].size);
+ sparse->areas[i].size - 1);
if (sparse->areas[i].size) {
  region->mmaps[j].offset = sparse->areas[i].offset;


If the size if zero, the trace will be weird with an underflow if 
offset is zero as well.


Yes, that's a issue.


Maybe just change the trace by inverting the right bracket ?
eg: [0x1000 - 0x9000[
Or don't trace in that case ? (but I am not maintainer of this, so 
maybe that does not make sense).


But it uses [offset, offset + size - 1] in other places such as 
trace_vfio_region_region_mmap()/trace_vfio_subregion_unmap()/trace_vfio_region_mmap_fault() 
in vfio code.
Maybe it is better to move this trace to the brace of "if 
(sparse->areas[i].size)" which ensures size != 0.




--
Damien
.

Re: [PATCH] hw/arm/virt: Enable HMAT on arm virt machine

[chenxiang (M)]

在 2022/1/25 20:46, Andrew Jones 写道:

On Tue, Jan 25, 2022 at 07:46:43PM +0800, chenxiang (M) wrote:

Hi Andrew,


在 2022/1/25 18:26, Andrew Jones 写道:

On Tue, Jan 25, 2022 at 05:15:34PM +0800, chenxiang via wrote:

From: Xiang Chen 

Since the patchset ("Build ACPI Heterogeneous Memory Attribute Table (HMAT)"),
HMAT is supported, but only x86 is enabled. Enable HMAT on arm virt machine.

Hi Xiang,

What QEMU commands lines have you tested with which Linux guest kernels?

I tested it with following commands with guest kernel 5.16-rc1, and the boot
log of guest kernel is as attached:

Thanks. Please consider adding HMAT tests, see tests/qtest/numa-test.c and
tests/qtest/bios-tables-test.c, for the virt machine type to this series.
Otherwise,

Reviewed-by: Andrew Jones 


Thanks, i will add those HMAT tests in v2.

Re: [PATCH] hw/arm/virt: Enable HMAT on arm virt machine

[chenxiang (M)]

Hi Andrew,


在 2022/1/25 18:26, Andrew Jones 写道:

On Tue, Jan 25, 2022 at 05:15:34PM +0800, chenxiang via wrote:

From: Xiang Chen 

Since the patchset ("Build ACPI Heterogeneous Memory Attribute Table (HMAT)"),
HMAT is supported, but only x86 is enabled. Enable HMAT on arm virt machine.

Hi Xiang,

What QEMU commands lines have you tested with which Linux guest kernels?


I tested it with following commands with guest kernel 5.16-rc1, and the 
boot log of guest kernel is as attached:


./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g \
-object memory-backend-ram,size=2G,id=m0 \
-object memory-backend-ram,size=2G,id=m1 \
-numa node,cpus=0-3,nodeid=0,memdev=m0 \
-numa node,nodeid=1,memdev=m1,initiator=0 \
-numa 
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5 
\
-numa 
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M 
\
-numa 
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=10 
\
-numa 
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M 
\
-numa 
hmat-cache,node-id=0,size=16K,level=1,associativity=direct,policy=write-back,line=8 
\
-numa 
hmat-cache,node-id=1,size=16K,level=1,associativity=direct,policy=write-back,line=8 
\

-smp 4 \
-no-reboot \
-nographic \
-cpu host \
-machine virt,accel=kvm,gic-version=3,hmat=on \
-bios /home/cx/QEMU_EFI.fd \
-monitor unix:/home/cx/opt/qmp-test,server,nowait \
-kernel /home/cx/Image  \
-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4  \
-drive file=/home/cx/opt/boot.img,if=none,id=drive0 \
-append "rdinit=init console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw "




Thanks,
drew


Signed-off-by: Xiang Chen 
---
  hw/arm/Kconfig   | 1 +
  hw/arm/virt-acpi-build.c | 7 +++
  2 files changed, 8 insertions(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 2e0049196d..a3c6099829 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -29,6 +29,7 @@ config ARM_VIRT
  select ACPI_APEI
  select ACPI_VIOT
  select VIRTIO_MEM_SUPPORTED
+select ACPI_HMAT
  
  config CHEETAH

  bool
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 449fab0080..f19b55e486 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -42,6 +42,7 @@
  #include "hw/acpi/memory_hotplug.h"
  #include "hw/acpi/generic_event_device.h"
  #include "hw/acpi/tpm.h"
+#include "hw/acpi/hmat.h"
  #include "hw/pci/pcie_host.h"
  #include "hw/pci/pci.h"
  #include "hw/pci/pci_bus.h"
@@ -990,6 +991,12 @@ void virt_acpi_build(VirtMachineState *vms, 
AcpiBuildTables *tables)
  build_slit(tables_blob, tables->linker, ms, vms->oem_id,
 vms->oem_table_id);
  }
+
+if (ms->numa_state->hmat_enabled) {
+acpi_add_table(table_offsets, tables_blob);
+build_hmat(tables_blob, tables->linker, ms->numa_state,
+   vms->oem_id, vms->oem_table_id);
+}
  }
  
  if (ms->nvdimms_state->is_enabled) {

--
2.33.0



.



[root@centos build]# ./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g -object 
memory-backend-ram,size=2G,id=m0 -object memory-backend-ram,size=2G,id=m1 -numa 
node,cpus=0-3,nodeid=0,memdev=m0 -numa node,nodeid=1,memdev=m1,initiator=0 
-numa 
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5
 -numa 
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M
 -numa 
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=10
 -numa 
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M
 -numa 
hmat-cache,node-id=0,size=16K,level=1,associativity=direct,policy=write-back,line=8
 -numa 
hmat-cache,node-id=1,size=16K,level=1,associativity=direct,policy=write-back,line=8
 -smp 4 -no-reboot -nographic -cpu host -machine 
virt,accel=kvm,gic-version=3,hmat=on -bios /home/cx/QEMU_EFI.fd -monitor 
unix:/home/cx/opt/qmp-test,server,nowait -kernel /home/cx/Image  -device 
virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4  -drive 
file=/home/cx/opt/boot.img,if=none,id=drive0 -append "rdinit=init 
console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw "
WARNING: Image format was not specified for '/home/cx/opt/boot.img' and probing 
guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Generating empty DTB
EFI stub: Exiting boot services...
[0.00] Booting Linux on physical CPU 0x00 [0x481fd010]
[0.00] Linux version 5.16.0-rc1-15060-g07d132dd883a (chenxiang@plinth) 
(aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05-

Re: [PATCH v1 1/1] chardev: enable guest socket status/crontrol via DTR and DCD

[Darrin M. Gorski]

Unfortunately I ran out of cycles at the time.  Adding test cases seems
like it was the roadblock - I don't think I ever figured out how to
implement the needed build tests for this additional feature in chardev.
I'm not that strong of a C developer, unfortunately.

I haven't looked at picking this up in probably a year, so I don't even
remember if I was able to get *anywhere* with it.

I did end up using a patched build myself,  and it worked fine for what I
was doing which is probably why I didn't get back to it.

Sorry, I'm sure that's not the answer you were hoping for.  But the day job
takes priority ;)

- Darrin


On Wed, Jan 12, 2022 at 10:20 AM Aaro Koskinen  wrote:

> Hi,
>
> On Wed, Dec 16, 2020 at 05:06:51PM -0500, Darrin M. Gorski wrote:
> > This patch adds a 'modemctl' option to "-chardev socket" to enable
> control
> > of the socket via the guest serial port.
> > The default state of the option is disabled.
> >
> > 1. disconnect a connected socket when DTR transitions to low, also reject
> > new connections while DTR is low.
> > 2. provide socket connection status through the carrier detect line (CD
> or
> > DCD) on the guest serial port
> >
> > Buglink: https://bugs.launchpad.net/qemu/+bug/1213196
> >
> > Signed-off-by: Darrin M. Gorski 
>
> Is there any plans to continue working with this patch? Having the DCD
> status would be very useful.
>
> A.
>

Re: [RFC v2 1/2] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5

[chenxiang (M)]

在 2022/1/6 19:00, Eric Auger 写道:

Hi CHenxiangn

On 12/29/21 8:13 AM, chenxiang (M) via wrote:

Hi Eric,


在 2021/10/5 16:53, Eric Auger 写道:

Add a 'preserve_config' field in struct GPEXConfig and
if set generate the DSM #5 for preserving PCI boot configurations.
The DSM presence is needed to expose RMRs.

At the moment the DSM generation is not yet enabled.

Signed-off-by: Eric Auger 
---
   include/hw/pci-host/gpex.h |  1 +
   hw/pci-host/gpex-acpi.c| 12 
   2 files changed, 13 insertions(+)

diff --git a/include/hw/pci-host/gpex.h b/include/hw/pci-host/gpex.h
index fcf8b63820..3f8f8ec38d 100644
--- a/include/hw/pci-host/gpex.h
+++ b/include/hw/pci-host/gpex.h
@@ -64,6 +64,7 @@ struct GPEXConfig {
   MemMapEntry pio;
   int irq;
   PCIBus  *bus;
+boolpreserve_config;
   };
 int gpex_set_irq_num(GPEXHost *s, int index, int gsi);
diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c
index e7e162a00a..7dab259379 100644
--- a/hw/pci-host/gpex-acpi.c
+++ b/hw/pci-host/gpex-acpi.c
@@ -164,6 +164,12 @@ void acpi_dsdt_add_gpex(Aml *scope, struct
GPEXConfig *cfg)
   aml_append(dev, aml_name_decl("_PXM",
aml_int(numa_node)));
   }
   +if (cfg->preserve_config) {
+method = aml_method("_DSM", 5, AML_SERIALIZED);

I notice there is a ACPI BIOS Error when booting virtual machine which
seems be caused by this patch as I add this patchset in my branch to
test the function of vsmmu.
It seems that it requires only 4 parameter for method _DSM, but use 5
parameters here.
The error log is as following:

Thank you for the heads up. Yes the problem was reported by Igor too in
https://www.mail-archive.com/qemu-devel@nongnu.org/msg842972.html.

At the moment the RMRR ACPI situation has not progressed on spec side or
kernel if I have not missed anything but sure I will take this into
account in my next respin.


Ok, thanks.



Thanks!

Eric

[2.355459] ACPI BIOS Error (bug): Failure creating named object
[\_SB.PCI0._DSM], AE_ALREADY_EXISTS (20210930/dswload2-327)
[2.355467] ACPI Error: AE_ALREADY_EXISTS, During name
lookup/catalog (20210930/psobject-221)
[2.355470] ACPI: Skipping parse of AML opcode: OpcodeName
unavailable (0x0014)
[2.355657] ACPI: 1 ACPI AML tables successfully acquired and loaded
[2.356321] ACPI: Interpreter enabled
[2.356323] ACPI: Using GIC for interrupt routing
[2.356333] ACPI: MCFG table detected, 1 entries
[2.361359] ARMH0011:00: ttyAMA0 at MMIO 0x900 (irq = 16,
base_baud = 0) is a SBSA
[2.619805] printk: console [ttyAMA0] enabled
[2.622114] ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-ff])
[2.622788] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM
ClockPM Segments MSI HPX-Type3]
[2.623776] acpi PNP0A08:00: _OSC: platform does not support [LTR]
[2.624600] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME
AER PCIeCapability]
[2.625721] acpi PNP0A08:00: ECAM area [mem
0x401000-0x401fff] reserved by PNP0C02:00
[2.626645] acpi PNP0A08:00: ECAM at [mem
0x401000-0x401fff] for [bus 00-ff]
[2.627450] ACPI: Remapped I/O 0x3eff to [io
0x-0x window]
[2.628229] ACPI BIOS Error (bug): \_SB.PCI0._DSM: Excess arguments
- ASL declared 5, ACPI requires 4 (20210930/nsarguments-166)
[2.629576] PCI host bridge to bus :00
[2.630008] pci_bus :00: root bus resource [mem
0x1000-0x3efe window]
[2.630747] pci_bus :00: root bus resource [io  0x-0x
window]
[2.631405] pci_bus :00: root bus resource [mem
0x80-0xff window]
[2.632177] pci_bus :00: root bus resource [bus 00-ff]
[2.632731] ACPI BIOS Error (bug): \_SB.PCI0._DSM: Excess arguments
- ASL declared 5, ACPI requires 4 (20210930/nsarguments-166)



+aml_append(method, aml_return(aml_int(0)));
+aml_append(dev, method);
+}
+
   acpi_dsdt_add_pci_route_table(dev, cfg->irq);
 /*
@@ -191,6 +197,12 @@ void acpi_dsdt_add_gpex(Aml *scope, struct
GPEXConfig *cfg)
   aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0
Device")));
   aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
   +if (cfg->preserve_config) {
+method = aml_method("_DSM", 5, AML_SERIALIZED);
+aml_append(method, aml_return(aml_int(0)));
+aml_append(dev, method);
+}
+
   acpi_dsdt_add_pci_route_table(dev, cfg->irq);
 method = aml_method("_CBA", 0, AML_NOTSERIALIZED);



.

Re: [RFC v2 1/2] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5

[chenxiang (M)]

Hi Eric,


在 2021/10/5 16:53, Eric Auger 写道:

Add a 'preserve_config' field in struct GPEXConfig and
if set generate the DSM #5 for preserving PCI boot configurations.
The DSM presence is needed to expose RMRs.

At the moment the DSM generation is not yet enabled.

Signed-off-by: Eric Auger 
---
  include/hw/pci-host/gpex.h |  1 +
  hw/pci-host/gpex-acpi.c| 12 
  2 files changed, 13 insertions(+)

diff --git a/include/hw/pci-host/gpex.h b/include/hw/pci-host/gpex.h
index fcf8b63820..3f8f8ec38d 100644
--- a/include/hw/pci-host/gpex.h
+++ b/include/hw/pci-host/gpex.h
@@ -64,6 +64,7 @@ struct GPEXConfig {
  MemMapEntry pio;
  int irq;
  PCIBus  *bus;
+boolpreserve_config;
  };
  
  int gpex_set_irq_num(GPEXHost *s, int index, int gsi);

diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c
index e7e162a00a..7dab259379 100644
--- a/hw/pci-host/gpex-acpi.c
+++ b/hw/pci-host/gpex-acpi.c
@@ -164,6 +164,12 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg)
  aml_append(dev, aml_name_decl("_PXM", aml_int(numa_node)));
  }
  
+if (cfg->preserve_config) {

+method = aml_method("_DSM", 5, AML_SERIALIZED);


I notice there is a ACPI BIOS Error when booting virtual machine which 
seems be caused by this patch as I add this patchset in my branch to 
test the function of vsmmu.
It seems that it requires only 4 parameter for method _DSM, but use 5 
parameters here.

The error log is as following:

[2.355459] ACPI BIOS Error (bug): Failure creating named object 
[\_SB.PCI0._DSM], AE_ALREADY_EXISTS (20210930/dswload2-327)
[2.355467] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20210930/psobject-221)
[2.355470] ACPI: Skipping parse of AML opcode: OpcodeName 
unavailable (0x0014)

[2.355657] ACPI: 1 ACPI AML tables successfully acquired and loaded
[2.356321] ACPI: Interpreter enabled
[2.356323] ACPI: Using GIC for interrupt routing
[2.356333] ACPI: MCFG table detected, 1 entries
[2.361359] ARMH0011:00: ttyAMA0 at MMIO 0x900 (irq = 16, 
base_baud = 0) is a SBSA

[2.619805] printk: console [ttyAMA0] enabled
[2.622114] ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-ff])
[2.622788] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM 
ClockPM Segments MSI HPX-Type3]

[2.623776] acpi PNP0A08:00: _OSC: platform does not support [LTR]
[2.624600] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME 
AER PCIeCapability]
[2.625721] acpi PNP0A08:00: ECAM area [mem 
0x401000-0x401fff] reserved by PNP0C02:00
[2.626645] acpi PNP0A08:00: ECAM at [mem 0x401000-0x401fff] 
for [bus 00-ff]
[2.627450] ACPI: Remapped I/O 0x3eff to [io 
0x-0x window]
[2.628229] ACPI BIOS Error (bug): \_SB.PCI0._DSM: Excess arguments - 
ASL declared 5, ACPI requires 4 (20210930/nsarguments-166)

[2.629576] PCI host bridge to bus :00
[2.630008] pci_bus :00: root bus resource [mem 
0x1000-0x3efe window]

[2.630747] pci_bus :00: root bus resource [io  0x-0x window]
[2.631405] pci_bus :00: root bus resource [mem 
0x80-0xff window]

[2.632177] pci_bus :00: root bus resource [bus 00-ff]
[2.632731] ACPI BIOS Error (bug): \_SB.PCI0._DSM: Excess arguments - 
ASL declared 5, ACPI requires 4 (20210930/nsarguments-166)




+aml_append(method, aml_return(aml_int(0)));
+aml_append(dev, method);
+}
+
  acpi_dsdt_add_pci_route_table(dev, cfg->irq);
  
  /*

@@ -191,6 +197,12 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg)
  aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
  aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
  
+if (cfg->preserve_config) {

+method = aml_method("_DSM", 5, AML_SERIALIZED);
+aml_append(method, aml_return(aml_int(0)));
+aml_append(dev, method);
+}
+
  acpi_dsdt_add_pci_route_table(dev, cfg->irq);
  
  method = aml_method("_CBA", 0, AML_NOTSERIALIZED);

Re: [RESEND RFC] hw/arm/smmuv3: add device properties to disable cached iotlb

[chenxiang (M)]

Hi Eric,


在 2021/8/5 16:10, Eric Auger 写道:

Hi Chenxiang,
On 8/5/21 9:48 AM, chenxiang (M) wrote:

Hi Eric,


在 2021/8/5 0:26, Eric Auger 写道:

Hi Chenxiang,

On 8/4/21 10:49 AM, chenxiang wrote:

From: Xiang Chen 

It splits invalidations into ^2 range invalidations in the patch
6d9cd115b(" hw/arm/smmuv3: Enforce invalidation on a power of two
range").
So for some scenarios such as the size of invalidation is not ^2 range
invalidation, it costs more time to invalidate.

this ^² split is not only necessary for internal TLB management but also
for IOMMU MR notifier calls (which use a mask), ie. IOTLB unmap
notifications used for both vhost and vfio integrations.
So you can disable the internal IOTLB but we can't simply remove the pow
of 2 split. See below.

Right, in current code of qemu,  it is not right to simply remove the
pow of 2 split.
But i find that in my local repo, there is a private patch which seems
solve the issue, so it works on my test.

diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 4a7a183..83d24e1 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -825,7 +825,8 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr,
  event.type = IOMMU_NOTIFIER_UNMAP;
  event.entry.target_as = _space_memory;
  event.entry.iova = iova;
-event.entry.addr_mask = num_pages * (1 << granule) - 1;
+event.entry.addr_mask = (1 << granule) - 1;
+   event.entry.num_pages = num_pages;

OK I see. But you change the existing semantic of addr_mask which
originally matches the mask of the  full addr range of the IOTLB
operation and you replace it by the granule mask and add another
num_pages field.

This is a change in the memory.h API and should be discussed with other
memory.h and vIOMMU maintainers if you want to go that way. This
typically breaks vhost integration which does not use num_pages and
would typically fail invalidating the full range.

So we have 2 different things: the disablement of the internal IOTLB (x-
prop) which can be done easily but what you mostly want it to remove the
pow of 2 splits to reduce the interactions with the physical IOMMU in
the VFIO/SMMU use case , right?


Yes, i mainly want to remove the pow of 2 splits to reduce the times of 
invalidations which i think

it will affect the performance.


  pow of 2 splits is also needed for vhost
integration at the moment. Note this use case is not upstreamed and far
from being upstreamed given the /dev/iommu redesign, so it will be
difficult to justify that kind of change at thims moment.


I am not familar with vhost, and maybe need more investigate on it.
Do you have any suggestion about how to improve the issue?



Thanks

Eric

  event.entry.perm = IOMMU_NONE;
  event.entry.flags = IOMMU_INV_FLAGS_ARCHID;
  event.entry.arch_id = asid;
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index a863b7d..7b026f0 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -639,7 +639,7 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier
*n, IOMMUTLBEntry *iotlb)
  {
  hwaddr start = iotlb->iova + giommu->iommu_offset;
  struct iommu_inv_addr_info *addr_info;
-size_t size = iotlb->addr_mask + 1;
+size_t size = iotlb->num_pages * (iotlb->addr_mask + 1);
  int archid = -1;

  addr_info = _info;
@@ -653,8 +653,8 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier
*n, IOMMUTLBEntry *iotlb)
  }
  addr_info->archid = archid;
  addr_info->addr = start;
-addr_info->granule_size = size;
-addr_info->nb_granules = 1;
+addr_info->granule_size = iotlb->addr_mask + 1;
+   addr_info->nb_granules = iotlb->num_pages;
  trace_vfio_iommu_addr_inv_iotlb(archid, start, size,
  1, iotlb->leaf);
  break;
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 0c4389c..268a395 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -110,6 +110,7 @@ struct IOMMUTLBEntry {
  hwaddr   iova;
  hwaddr   translated_addr;
  hwaddr   addr_mask;
+   uint64_t num_pages;
  IOMMUAccessFlags perm;
  IOMMUInvGranularity granularity;
  #define IOMMU_INV_FLAGS_PASID  (1 << 0)



internal TLB could be disabled through a property but I would rather set
it as an "x-" experimental property for debug purpose. Until recently
this was indeed helpful to debug bugs related to internal IOTLB
management (RIL support) ;-) I hope this period is over though ;-)

Ok, maybe we set it as "x-" experimental property currently.


Currently smmuv3_translate is rarely used (i only see it is used when
binding msi), so i think maybe we can disable cached iotlb to promote
efficiency of invalidation. So add device property disable_cached_iotlb
to disable cached iotlb, and then we can send non-^2 range invalidation
directly.
Use tool dma_map_

Re: [RESEND RFC] hw/arm/smmuv3: add device properties to disable cached iotlb

[chenxiang (M)]

Hi Eric,


在 2021/8/5 0:26, Eric Auger 写道:

Hi Chenxiang,

On 8/4/21 10:49 AM, chenxiang wrote:

From: Xiang Chen 

It splits invalidations into ^2 range invalidations in the patch
6d9cd115b(" hw/arm/smmuv3: Enforce invalidation on a power of two range").
So for some scenarios such as the size of invalidation is not ^2 range
invalidation, it costs more time to invalidate.

this ^² split is not only necessary for internal TLB management but also
for IOMMU MR notifier calls (which use a mask), ie. IOTLB unmap
notifications used for both vhost and vfio integrations.
So you can disable the internal IOTLB but we can't simply remove the pow
of 2 split. See below.
Right, in current code of qemu,  it is not right to simply remove the 
pow of 2 split.
But i find that in my local repo, there is a private patch which seems 
solve the issue, so it works on my test.


diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 4a7a183..83d24e1 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -825,7 +825,8 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr,
 event.type = IOMMU_NOTIFIER_UNMAP;
 event.entry.target_as = _space_memory;
 event.entry.iova = iova;
-event.entry.addr_mask = num_pages * (1 << granule) - 1;
+event.entry.addr_mask = (1 << granule) - 1;
+   event.entry.num_pages = num_pages;
 event.entry.perm = IOMMU_NONE;
 event.entry.flags = IOMMU_INV_FLAGS_ARCHID;
 event.entry.arch_id = asid;
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index a863b7d..7b026f0 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -639,7 +639,7 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier 
*n, IOMMUTLBEntry *iotlb)

 {
 hwaddr start = iotlb->iova + giommu->iommu_offset;
 struct iommu_inv_addr_info *addr_info;
-size_t size = iotlb->addr_mask + 1;
+size_t size = iotlb->num_pages * (iotlb->addr_mask + 1);
 int archid = -1;

 addr_info = _info;
@@ -653,8 +653,8 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier 
*n, IOMMUTLBEntry *iotlb)

 }
 addr_info->archid = archid;
 addr_info->addr = start;
-addr_info->granule_size = size;
-addr_info->nb_granules = 1;
+addr_info->granule_size = iotlb->addr_mask + 1;
+   addr_info->nb_granules = iotlb->num_pages;
 trace_vfio_iommu_addr_inv_iotlb(archid, start, size,
 1, iotlb->leaf);
 break;
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 0c4389c..268a395 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -110,6 +110,7 @@ struct IOMMUTLBEntry {
 hwaddr   iova;
 hwaddr   translated_addr;
 hwaddr   addr_mask;
+   uint64_t num_pages;
 IOMMUAccessFlags perm;
 IOMMUInvGranularity granularity;
 #define IOMMU_INV_FLAGS_PASID  (1 << 0)




internal TLB could be disabled through a property but I would rather set
it as an "x-" experimental property for debug purpose. Until recently
this was indeed helpful to debug bugs related to internal IOTLB
management (RIL support) ;-) I hope this period is over though ;-)

Ok, maybe we set it as "x-" experimental property currently.


Currently smmuv3_translate is rarely used (i only see it is used when
binding msi), so i think maybe we can disable cached iotlb to promote
efficiency of invalidation. So add device property disable_cached_iotlb
to disable cached iotlb, and then we can send non-^2 range invalidation
directly.
Use tool dma_map_benchmark to have a test on the latency of unmap,
and we can see it promotes much on unmap when the size of invalidation
is not ^2 range invalidation (such as g = 7/15/31/511):

t = 1(thread = 1)
before opt(us)   after opt(us)
g=1(4K size)0.2/7.6 0.2/7.5
g=4(8K size)0.4/7.9 0.4/7.9
g=7(28K size)   0.6/10.20.6/8.2
g=8(32K size)   0.6/8.3 0.6/8.3
g=15(60K size)  1.1/12.11.1/9.1
g=16(64K size)  1.1/9.2 1.1/9.1
g=31(124K size) 2.0/14.82.0/10.7
g=32(128K size) 2.1/14.82.1/10.7
g=511(2044K size)   30.9/65.1   31.1/55.9
g=512(2048K size) 0.3/32.1  0.3/32.1
t = 10(thread = 10)
before opt(us)   after opt(us)
g=1(4K size)0.2/39.90.2/39.1
g=4(8K size)0.5/42.60.5/42.4
g=7(28K size)   0.6/66.40.6/45.3
g=8(32K size)   0.7/45.80.7/46.1
g=15(60K size)  1.1/80.51.1/49.6
g=16(64K size)  1.1/49.81.1/50.2
g=31(124K size) 2.0/98.32.1/58.0
g=32(128K size) 2.1/57.72.1/58.2
g=511(2044K size)   35.2/322.2  35.3/236.7
g=512(2048K size) 0.8/238.2 0.9/240.3

Note: i test it based on VSMMU enabled with the patchset
("vSMMUv3/pSMMUv3 2 stage VFIO integration").

Signed-off-by: Xiang Chen 
---
  hw/arm/smmuv3.c | 

RE: [v4] migration: fix the memory overwriting risk in add_to_iovec

[linfeng (M)]

* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> Subject: Re: [v4] migration: fix the memory overwriting risk in add_to_iovec
> 
> * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> > * Lin Feng (linfen...@huawei.com) wrote:
> > > From: Feng Lin 
> > >
> > > When testing migration, a Segmentation fault qemu core is generated.
> > > 0  error_free (err=0x1)
> > > 1  0x7f8b862df647 in qemu_fclose (f=f@entry=0x55e06c247640)
> > > 2  0x7f8b8516d59a in migrate_fd_cleanup
> > > (s=s@entry=0x55e06c0e1ef0)
> > > 3  0x7f8b8516d66c in migrate_fd_cleanup_bh
> > > (opaque=0x55e06c0e1ef0)
> > > 4  0x7f8b8626a47f in aio_bh_poll (ctx=ctx@entry=0x55e06b5a16d0)
> > > 5  0x7f8b8626e71f in aio_dispatch (ctx=0x55e06b5a16d0)
> > > 6  0x7f8b8626a33d in aio_ctx_dispatch (source=,
> > > callback=, user_data=)
> > > 7  0x7f8b866bdba4 in g_main_context_dispatch ()
> > > 8  0x7f8b8626cde9 in glib_pollfds_poll ()
> > > 9  0x7f8b8626ce62 in os_host_main_loop_wait (timeout= > > out>)
> > > 10 0x7f8b8626cffd in main_loop_wait
> > > (nonblocking=nonblocking@entry=0)
> > > 11 0x7f8b862ef01f in main_loop () Using gdb print the struct
> > > QEMUFile f = {
> > >   ...,
> > >   iovcnt = 65, last_error = 21984,
> > >   last_error_obj = 0x1, shutdown = true } Well iovcnt is overflow,
> > > because the max size of MAX_IOV_SIZE is 64.
> > > struct QEMUFile {
> > > ...;
> > > struct iovec iov[MAX_IOV_SIZE];
> > > unsigned int iovcnt;
> > > int last_error;
> > > Error *last_error_obj;
> > > bool shutdown;
> > > };
> > > iovcnt and last_error is overwrited by add_to_iovec().
> > > Right now, add_to_iovec() increase iovcnt before check the limit.
> > > And it seems that add_to_iovec() assumes that iovcnt will set to
> > > zero in qemu_fflush(). But qemu_fflush() will directly return when
> > > f->shutdown is true.
> > >
> > > The situation may occur when libvirtd restart during migration,
> > > after
> > > f->shutdown is set, before calling qemu_file_set_error() in
> > > qemu_file_shutdown().
> > >
> > > So the safiest way is checking the iovcnt before increasing it.
> > >
> > > Signed-off-by: Feng Lin 
> >
> > Queued
> 
> Hmm this didn't actually build because that function is actually misnamed 
> 'qemu_file_is_writable' (no e!);
> I've fixed that, but can you just reconfirm that you've tested this fixes 
> your original problem?
Sorry for that rookie mistake. I have tested it again with gdb-fault injection. 
It can fix my original problem.
Thanks for helping me complete my first qemu patch submission. Really helped a 
lot.
> 
> Dave
> 
> > > ---
> > >  migration/qemu-file.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/migration/qemu-file.c b/migration/qemu-file.c index
> > > d6e03dbc0e..6879615197 100644
> > > --- a/migration/qemu-file.c
> > > +++ b/migration/qemu-file.c
> > > @@ -416,6 +416,11 @@ static int add_to_iovec(QEMUFile *f, const uint8_t 
> > > *buf, size_t size,
> > >  {
> > >  f->iov[f->iovcnt - 1].iov_len += size;
> > >  } else {
> > > +if (f->iovcnt >= MAX_IOV_SIZE) {
> > > +/* Should only happen if a previous fflush failed */
> > > +assert(f->shutdown || !qemu_file_is_writeable(f));
> > > +return 1;
> > > +}
> > >  if (may_free) {
> > >  set_bit(f->iovcnt, f->may_free);
> > >  }
> > > --
> > > 2.23.0
> > >
> > >
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

RE: [v3] migration: fix the memory overwriting risk in add_to_iovec

[linfeng (M)]

* Dr. David Alan Gilbert(mailto:dgilb...@redhat.com) wrote:
> * Lin Feng (linfen...@huawei.com) wrote:
> > From: Feng Lin 
> >
> > When testing migration, a Segmentation fault qemu core is generated.
> > 0  error_free (err=0x1)
> > 1  0x7f8b862df647 in qemu_fclose (f=f@entry=0x55e06c247640)
> > 2  0x7f8b8516d59a in migrate_fd_cleanup (s=s@entry=0x55e06c0e1ef0)
> > 3  0x7f8b8516d66c in migrate_fd_cleanup_bh (opaque=0x55e06c0e1ef0)
> > 4  0x7f8b8626a47f in aio_bh_poll (ctx=ctx@entry=0x55e06b5a16d0)
> > 5  0x7f8b8626e71f in aio_dispatch (ctx=0x55e06b5a16d0)
> > 6  0x7f8b8626a33d in aio_ctx_dispatch (source=, 
> > callback=,
> user_data=)
> > 7  0x7f8b866bdba4 in g_main_context_dispatch ()
> > 8  0x7f8b8626cde9 in glib_pollfds_poll ()
> > 9  0x7f8b8626ce62 in os_host_main_loop_wait (timeout=)
> > 10 0x7f8b8626cffd in main_loop_wait (nonblocking=nonblocking@entry=0)
> > 11 0x7f8b862ef01f in main_loop ()
> > Using gdb print the struct QEMUFile f = {
> >   ...,
> >   iovcnt = 65, last_error = 21984,
> >   last_error_obj = 0x1, shutdown = true
> > }
> > Well iovcnt is overflow, because the max size of MAX_IOV_SIZE is 64.
> > struct QEMUFile {
> > ...;
> > struct iovec iov[MAX_IOV_SIZE];
> > unsigned int iovcnt;
> > int last_error;
> > Error *last_error_obj;
> > bool shutdown;
> > };
> > iovcnt and last_error is overwrited by add_to_iovec().
> > Right now, add_to_iovec() increase iovcnt before check the limit.
> > And it seems that add_to_iovec() assumes that iovcnt will set to zero
> > in qemu_fflush(). But qemu_fflush() will directly return when f->shutdown
> > is true.
> >
> > The situation may occur when libvirtd restart during migration, after
> > f->shutdown is set, before calling qemu_file_set_error() in
> > qemu_file_shutdown().
> >
> > So the safiest way is checking the iovcnt before increasing it.
> >
> > Signed-off-by: Feng Lin 
> > ---
> >  migration/qemu-file.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/migration/qemu-file.c b/migration/qemu-file.c
> > index d6e03dbc0e..f6486cf7bc 100644
> > --- a/migration/qemu-file.c
> > +++ b/migration/qemu-file.c
> > @@ -416,6 +416,9 @@ static int add_to_iovec(QEMUFile *f, const uint8_t 
> > *buf, size_t size,
> >  {
> >  f->iov[f->iovcnt - 1].iov_len += size;
> >  } else {
> > +if (f->iovcnt >= MAX_IOV_SIZE) {
> > +goto fflush;
> > +}
> 
> Why call qemu_fflush in this case?
> If I understand what you're saying, then we only get to here if a
> previous qemu_fflush has failed, so this should fail as well?
Yes, that's what I mean.

> 
> How about, something like:
> if (f->iovcnt >= MAX_IOV_SIZE) {
> /* Should only happen if a previous fflush failed */
> assert(f->shutdown || !qemu_file_is_writeable(f));
> return 1;
> }
> 
> ?
At first, I'm just thinking that overwriting requires qemu_fflush to reset 
iovcnt and do not consider
the possibility of packet loss caused by other exceptions. It makes more sense 
to make an assertion
here. Thank you for your suggestions.
> 
> Dave
> 
> >  if (may_free) {
> >  set_bit(f->iovcnt, f->may_free);
> >  }
> > @@ -423,12 +426,12 @@ static int add_to_iovec(QEMUFile *f, const uint8_t 
> > *buf, size_t size,
> >  f->iov[f->iovcnt++].iov_len = size;
> >  }
> >
> > -if (f->iovcnt >= MAX_IOV_SIZE) {
> > -qemu_fflush(f);
> > -return 1;
> > +if (f->iovcnt < MAX_IOV_SIZE) {
> > +return 0;
> >  }
> > -
> > -return 0;
> > +fflush:
> > +qemu_fflush(f);
> > +return 1;
> >  }
> >
> >  static void add_buf_to_iovec(QEMUFile *f, size_t len)
> > --
> > 2.23.0
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v3 1/3] edid: move timing generation into a separate function

[m...@knazarov.com]

I've based my work on Akihiko Odaki's previous patchset that introduced dynamic 
refresh rate (see "Based-on" in the description).
Should I rebase it to master?

> On 16 Mar 2021, at 16:32, Gerd Hoffmann  wrote:
> 
> On Mon, Mar 15, 2021 at 02:46:37PM +0300, Konstantin Nazarov wrote:
>> The timing generation is currently performed inside the function that
>> fills in the DTD. The DisplayID generation needs it as well, so moving
>> it out to a separate function.
>> 
>> Based-on: <20210303152948.59943-2-akihiko.od...@gmail.com>
>> Signed-off-by: Konstantin Nazarov 
> 
> Doesn't apply cleanly.  Do you have a git tree somewhere?
> 
> take care,
>  Gerd
> 

Re: [PATCH v2] edid: add support for DisplayID extension (5k resolution)

[m...@knazarov.com]

The change to edid_checksum is needed because the DisplayID section has another 
checksum inside for the actually used part of its 128-byte extension block. The 
checksum in this case uses the same algorithm, but for a shorter block. Thus I 
added a parameter to specify the size of the block.

I'll address the rest of your comments in a 3-rd version of this patch.

> On 15 Mar 2021, at 10:44, Gerd Hoffmann  wrote:
> 
>> +typedef struct Timings {
> 
>> +static void generate_timings(Timings *timings, uint32_t refresh_rate,
>> + uint32_t xres, uint32_t yres)
> 
> Adding these should be splitted to a separate patch.
> 
>> -static void edid_checksum(uint8_t *edid)
>> +static void edid_checksum(uint8_t *edid, size_t len)
> 
> Why this change?  Also a good candidate for a separate patch.
> 
>> +if (size >= 384) {
>> +did = edid + 256;
> 
> "if (size >= 384 && large_screen)" ?
> Also setting did should be next to setting dta.
> 
> 
>   if (did) {
>> +dummy_displayid(did);
> 
> init_displayid() ?
> 
> Especially if we generate that only in case we actually have a large
> screen so we never have an empty extension section?
> 
> take care,
>  Gerd
> 

Emulating STM32F407 (Cortex-M4) with peripherals on an X86

[Srinath M]

Hi

I am new to the Qemu project and was wondering if it is possible to emulate
the above processor with it's peripherals (Uart, DMA at least) on an X86.
Would it be possible for the following OS to run in a Qemu emulation (as it
does on the real processor) ?
https://www.st.com/en/development-tools/coide.html

I want to see how many such devices would interact with each other over a
network and it's unviable to have dozens of embedded boards at a time.

Generally all these processors have more functionality than pins, so the
pins are multiplexed and must be assigned functionality in a startup
routine. So i think there must be a CPU+peripheral emulator running on a
board emulator.

I would like to know if anyone has attempted something like this before or
some thoughts on the best way forward.

Regards
Srinath

Re: [PATCH v1 1/1] chardev: enable guest socket status/crontrol via DTR and DCD

[Darrin M. Gorski]

>> Yes, but they can override the default behaviour, or just reuse some
code.
>> If it doesn't fit, don't worry about it, we can just start with socket.

Whew.  I spent several hours yesterday trying to figure out how to alter
the base class to support this - DCD could be reasonably simple, but DTR is
another matter.  I will continue to look at that, but I do think moving
forward with sockets (since this patch already works that way) is a good
compromise.

> You can look at char_socket_server_test.

Will do.

- Darrin

On Fri, Dec 18, 2020 at 6:57 AM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:

> Hi
>
> On Thu, Dec 17, 2020 at 9:54 PM Darrin M. Gorski 
> wrote:
>
>>
>> > That sounds like a good idea to me, but others may have different
>> opinions.
>>
>> My original idea was simply to allow DCD to track socket state, because
>> this is what I need.  The DTR idea came from the referenced bug.  The
>> feature defaults to disabled like many of the other edge cases (like telnet
>> and tn3270), and it's a reasonably small non-intrusive change.
>>
>> > Can we make this generic over all chardevs by moving it to the base
>> class?
>>
>> I'll take a closer look at the base class. I admit I did not spend much
>> time studying it.  This seemed like a socket specific feature to me.  It
>> seems like it might conflict with other chardevs like pty and serial as
>> they are already using ioctl for interaction with real tty devices.
>>
>
> Yes, but they can override the default behaviour, or just reuse some code.
>
> If it doesn't fit, don't worry about it, we can just start with socket.
>
>
>> > This feature will need some new tests in tests/test-char.c.
>>
>> I would be happy to add tests but would need some guidance.
>>
>
> You can look at char_socket_server_test. You can extend
> CharSocketServerTestConfig to check for modemctl behaviour. It will need to
> send the ioctl with qemu_chr_fe_ioctl (I admit it wasn't tested so far,
> because only serial and parallel chardev did implement it, and it's not
> easy to test those)
>
> Let me know if you need more help
>
>
>> - Darrin
>>
>> On Thu, Dec 17, 2020 at 9:16 AM Marc-André Lureau <
>> marcandre.lur...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> On Thu, Dec 17, 2020 at 2:54 AM Darrin M. Gorski 
>>> wrote:
>>>
>>>>
>>>> This patch adds a 'modemctl' option to "-chardev socket" to enable
>>>> control of the socket via the guest serial port.
>>>> The default state of the option is disabled.
>>>>
>>>> 1. disconnect a connected socket when DTR transitions to low, also
>>>> reject new connections while DTR is low.
>>>> 2. provide socket connection status through the carrier detect line (CD
>>>> or DCD) on the guest serial port
>>>>
>>>
>>> That sounds like a good idea to me, but others may have different
>>> opinions.
>>>
>>>
>>>> Buglink: https://bugs.launchpad.net/qemu/+bug/1213196
>>>>
>>>> Signed-off-by: Darrin M. Gorski 
>>>>
>>>>
>>>> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
>>>> index 213a4c8dd0..94dd28e0cd 100644
>>>> --- a/chardev/char-socket.c
>>>> +++ b/chardev/char-socket.c
>>>> @@ -36,6 +36,7 @@
>>>>  #include "qapi/qapi-visit-sockets.h"
>>>>
>>>>  #include "chardev/char-io.h"
>>>> +#include "chardev/char-serial.h"
>>>>  #include "qom/object.h"
>>>>
>>>>  /***/
>>>> @@ -85,6 +86,9 @@ struct SocketChardev {
>>>>  bool connect_err_reported;
>>>>
>>>>  QIOTask *connect_task;
>>>> +
>>>> +bool is_modemctl;
>>>> +int modem_state;
>>>>
>>>
>>> Can we make this generic over all chardevs by moving it to the base
>>> class?
>>>
>>>  };
>>>>  typedef struct SocketChardev SocketChardev;
>>>>
>>>> @@ -98,12 +102,18 @@ static void tcp_chr_change_state(SocketChardev *s,
>>>> TCPChardevState state)
>>>>  {
>>>>  switch (state) {
>>>>  case TCP_CHARDEV_STATE_DISCONNECTED:
>>>> +if(s->is_modemctl) {
>>>> +s->modem_state &= ~(CHR_TIOCM_CAR);
>>>> +}
>>>>  break;
&

Re: [PATCH v1 1/1] chardev: enable guest socket status/crontrol via DTR and DCD

[Darrin M. Gorski]

> That sounds like a good idea to me, but others may have different
opinions.

My original idea was simply to allow DCD to track socket state, because
this is what I need.  The DTR idea came from the referenced bug.  The
feature defaults to disabled like many of the other edge cases (like telnet
and tn3270), and it's a reasonably small non-intrusive change.

> Can we make this generic over all chardevs by moving it to the base class?

I'll take a closer look at the base class. I admit I did not spend much
time studying it.  This seemed like a socket specific feature to me.  It
seems like it might conflict with other chardevs like pty and serial as
they are already using ioctl for interaction with real tty devices.

> This feature will need some new tests in tests/test-char.c.

I would be happy to add tests but would need some guidance.

- Darrin

On Thu, Dec 17, 2020 at 9:16 AM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:

> Hi
>
> On Thu, Dec 17, 2020 at 2:54 AM Darrin M. Gorski 
> wrote:
>
>>
>> This patch adds a 'modemctl' option to "-chardev socket" to enable
>> control of the socket via the guest serial port.
>> The default state of the option is disabled.
>>
>> 1. disconnect a connected socket when DTR transitions to low, also reject
>> new connections while DTR is low.
>> 2. provide socket connection status through the carrier detect line (CD
>> or DCD) on the guest serial port
>>
>
> That sounds like a good idea to me, but others may have different opinions.
>
>
>> Buglink: https://bugs.launchpad.net/qemu/+bug/1213196
>>
>> Signed-off-by: Darrin M. Gorski 
>>
>>
>> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
>> index 213a4c8dd0..94dd28e0cd 100644
>> --- a/chardev/char-socket.c
>> +++ b/chardev/char-socket.c
>> @@ -36,6 +36,7 @@
>>  #include "qapi/qapi-visit-sockets.h"
>>
>>  #include "chardev/char-io.h"
>> +#include "chardev/char-serial.h"
>>  #include "qom/object.h"
>>
>>  /***/
>> @@ -85,6 +86,9 @@ struct SocketChardev {
>>  bool connect_err_reported;
>>
>>  QIOTask *connect_task;
>> +
>> +bool is_modemctl;
>> +int modem_state;
>>
>
> Can we make this generic over all chardevs by moving it to the base class?
>
>  };
>>  typedef struct SocketChardev SocketChardev;
>>
>> @@ -98,12 +102,18 @@ static void tcp_chr_change_state(SocketChardev *s,
>> TCPChardevState state)
>>  {
>>  switch (state) {
>>  case TCP_CHARDEV_STATE_DISCONNECTED:
>> +if(s->is_modemctl) {
>> +s->modem_state &= ~(CHR_TIOCM_CAR);
>> +}
>>  break;
>>  case TCP_CHARDEV_STATE_CONNECTING:
>>  assert(s->state == TCP_CHARDEV_STATE_DISCONNECTED);
>>  break;
>>  case TCP_CHARDEV_STATE_CONNECTED:
>>  assert(s->state == TCP_CHARDEV_STATE_CONNECTING);
>> +if(s->is_modemctl) {
>> +s->modem_state |= CHR_TIOCM_CAR;
>> +}
>>  break;
>>  }
>>  s->state = state;
>> @@ -947,6 +957,12 @@ static void tcp_chr_accept(QIONetListener *listener,
>>  tcp_chr_change_state(s, TCP_CHARDEV_STATE_CONNECTING);
>>  tcp_chr_set_client_ioc_name(chr, cioc);
>>  tcp_chr_new_client(chr, cioc);
>> +
>> +if(s->is_modemctl) {
>> +if(!(s->modem_state & CHR_TIOCM_DTR)) {
>> +tcp_chr_disconnect(chr); /* disconnect if DTR is low */
>> +}
>> +}
>>  }
>>
>>
>> @@ -1322,12 +1338,17 @@ static void qmp_chardev_open_socket(Chardev *chr,
>>  bool is_tn3270  = sock->has_tn3270  ? sock->tn3270  : false;
>>  bool is_waitconnect = sock->has_wait? sock->wait: false;
>>  bool is_websock = sock->has_websocket ? sock->websocket : false;
>> +bool is_modemctl = sock->has_modemctl ? sock->modemctl : false;
>>  int64_t reconnect   = sock->has_reconnect ? sock->reconnect : 0;
>>  SocketAddress *addr;
>>
>>  s->is_listen = is_listen;
>>  s->is_telnet = is_telnet;
>>  s->is_tn3270 = is_tn3270;
>> +s->is_modemctl = is_modemctl;
>> +if(is_modemctl) {
>> +  s->modem_state = CHR_TIOCM_CTS | CHR_TIOCM_DSR;
>> +}
>>  s->is_websock = is_websock;
>>  s->do_nodelay = do_nodelay;
>>  if (sock->tls_creds) {
>> @@ -1448,6 +1469,8 @@ st

[Bug 1213196] Re: -serial tcp should hang up when DTR goes low

[Darrin M. Gorski]

Sent in a patch for this.

https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04658.html

DTR controls the socket.

DCD reflects the state of the socket.

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

Title:
  -serial tcp should hang up when DTR goes low

Status in QEMU:
  New

Bug description:
  In keeping with the spirit of serial modem control signals, de-
  asserting DTR should cause the TCP connection to break; asserting DTR
  should cause QEMU to initiate a new connection or for it to accept
  another (in server mode; this may involve waiting for one to arrive,
  too).

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

[PATCH v1 1/1] chardev: enable guest socket status/crontrol via DTR and DCD

[Darrin M. Gorski]

This patch adds a 'modemctl' option to "-chardev socket" to enable control
of the socket via the guest serial port.
The default state of the option is disabled.

1. disconnect a connected socket when DTR transitions to low, also reject
new connections while DTR is low.
2. provide socket connection status through the carrier detect line (CD or
DCD) on the guest serial port

Buglink: https://bugs.launchpad.net/qemu/+bug/1213196

Signed-off-by: Darrin M. Gorski 


diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 213a4c8dd0..94dd28e0cd 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -36,6 +36,7 @@
 #include "qapi/qapi-visit-sockets.h"

 #include "chardev/char-io.h"
+#include "chardev/char-serial.h"
 #include "qom/object.h"

 /***/
@@ -85,6 +86,9 @@ struct SocketChardev {
 bool connect_err_reported;

 QIOTask *connect_task;
+
+bool is_modemctl;
+int modem_state;
 };
 typedef struct SocketChardev SocketChardev;

@@ -98,12 +102,18 @@ static void tcp_chr_change_state(SocketChardev *s,
TCPChardevState state)
 {
 switch (state) {
 case TCP_CHARDEV_STATE_DISCONNECTED:
+if(s->is_modemctl) {
+s->modem_state &= ~(CHR_TIOCM_CAR);
+}
 break;
 case TCP_CHARDEV_STATE_CONNECTING:
 assert(s->state == TCP_CHARDEV_STATE_DISCONNECTED);
 break;
 case TCP_CHARDEV_STATE_CONNECTED:
 assert(s->state == TCP_CHARDEV_STATE_CONNECTING);
+if(s->is_modemctl) {
+s->modem_state |= CHR_TIOCM_CAR;
+}
 break;
 }
 s->state = state;
@@ -947,6 +957,12 @@ static void tcp_chr_accept(QIONetListener *listener,
 tcp_chr_change_state(s, TCP_CHARDEV_STATE_CONNECTING);
 tcp_chr_set_client_ioc_name(chr, cioc);
 tcp_chr_new_client(chr, cioc);
+
+if(s->is_modemctl) {
+if(!(s->modem_state & CHR_TIOCM_DTR)) {
+tcp_chr_disconnect(chr); /* disconnect if DTR is low */
+}
+}
 }


@@ -1322,12 +1338,17 @@ static void qmp_chardev_open_socket(Chardev *chr,
 bool is_tn3270  = sock->has_tn3270  ? sock->tn3270  : false;
 bool is_waitconnect = sock->has_wait? sock->wait: false;
 bool is_websock = sock->has_websocket ? sock->websocket : false;
+bool is_modemctl = sock->has_modemctl ? sock->modemctl : false;
 int64_t reconnect   = sock->has_reconnect ? sock->reconnect : 0;
 SocketAddress *addr;

 s->is_listen = is_listen;
 s->is_telnet = is_telnet;
 s->is_tn3270 = is_tn3270;
+s->is_modemctl = is_modemctl;
+if(is_modemctl) {
+  s->modem_state = CHR_TIOCM_CTS | CHR_TIOCM_DSR;
+}
 s->is_websock = is_websock;
 s->do_nodelay = do_nodelay;
 if (sock->tls_creds) {
@@ -1448,6 +1469,8 @@ static void qemu_chr_parse_socket(QemuOpts *opts,
ChardevBackend *backend,
 sock->tls_creds = g_strdup(qemu_opt_get(opts, "tls-creds"));
 sock->has_tls_authz = qemu_opt_get(opts, "tls-authz");
 sock->tls_authz = g_strdup(qemu_opt_get(opts, "tls-authz"));
+sock->has_modemctl = qemu_opt_get(opts, "modemctl");
+sock->modemctl = qemu_opt_get_bool(opts, "modemctl", false);

 addr = g_new0(SocketAddressLegacy, 1);
 if (path) {
@@ -1501,6 +1524,51 @@ char_socket_get_connected(Object *obj, Error **errp)
 return s->state == TCP_CHARDEV_STATE_CONNECTED;
 }

+/* ioctl support: allow guest to control/track socket state
+ * via modem control lines (DCD/DTR)
+ */
+static int
+char_socket_ioctl(Chardev *chr, int cmd, void *arg)
+{
+SocketChardev *s = SOCKET_CHARDEV(chr);
+
+if(!(s->is_modemctl)) {
+return -ENOTSUP;
+}
+
+switch (cmd) {
+case CHR_IOCTL_SERIAL_GET_TIOCM:
+{
+int *targ = (int *)arg;
+*targ = s->modem_state;
+}
+break;
+case CHR_IOCTL_SERIAL_SET_TIOCM:
+{
+int sarg = *(int *)arg;
+if (sarg & CHR_TIOCM_RTS) {
+s->modem_state |= CHR_TIOCM_RTS;
+} else {
+s->modem_state &= ~(CHR_TIOCM_RTS);
+}
+if (sarg & CHR_TIOCM_DTR) {
+s->modem_state |= CHR_TIOCM_DTR;
+} else {
+s->modem_state &= ~(CHR_TIOCM_DTR);
+/* disconnect if DTR goes low */
+if(s->state == TCP_CHARDEV_STATE_CONNECTED) {
+tcp_chr_disconnect(chr);
+}
+}
+}
+break;
+default:
+return -ENOTSUP;
+}
+
+return 0;
+}
+
 static void char_socket_class_init(ObjectClass *o

Re: [Bug 1759338] Re: qemu-system-sparc w/ SS-20 ROM does not add processors

[m...@papersolve.com]

Yes this can be closed, no problems now using open bios to boot Solaris
and it does support multiple processors though this is actually slower
than one.

Sent from my mobile device

On Nov 13, 2020, at 11:41 AM, Peter Maydell <1759...@bugs.launchpad.net>
wrote:

 Reporter said in comment #1 that the bug can be closed, so let's close
it :-)


** Changed in: qemu
Status: Incomplete => Fix Released

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1759338<https://bugs.launchpad.net/bugs/1759338>

Title:
qemu-system-sparc w/ SS-20 ROM does not add processors

Status in QEMU:
Fix Released

Bug description:
When booting a SPARCstation-20 with the original ROM, qemu does not
set the number of processors in a way that this ROM can understand it,
and the ROM always reports only 1 processor installed:


~/qemu  /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu 
"TI SuperSparc 60" -smp 2 -nographic

Power-ON Reset


SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)


CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache

CPU_#1 *** NOT installed ***
CPU_#2 *** NOT installed ***
CPU_#3 *** NOT installed ***

<<< CPU_ on MBus Slot_ >>> IS RUNNING (MID =
0008)


...

Cpu #0 TI,TMS390Z50
Cpu #1 Nothing there
Cpu #2 Nothing there
Cpu #3 Nothing there

...

SPARCstation 20 (1 X 390Z50), No Keyboard
ROM Rev. 2.25, 128 MB memory installed, Serial #1193046.
Ethernet address 52:54:0:12:34:56, Host ID: 72123456.


(It is necessary use SS-20 since it is the only sun4m model that
supports 512MB RAM, and I can't get Solaris to install on the SS-20
using OpenBIOS.)

When booting with OpenBIOS I can't seem to boot any version of Solaris
though I had heard this did work. Solaris 8 and 9 do work nicely with
this ROM, but I am opening this to see if it is possible to fix this
to allow the original OBP ROM to see multiple processors.

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

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

Title:
  qemu-system-sparc w/ SS-20 ROM does not add processors

Status in QEMU:
  Fix Released

Bug description:
  When booting a SPARCstation-20 with the original ROM, qemu does not
  set the number of processors in a way that this ROM can understand it,
  and the ROM always reports only 1 processor installed:

  
   ~/qemu  /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 
-cpu "TI SuperSparc 60" -smp 2 -nographic

  Power-ON Reset


  
 SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)

  
  CPU_#0   TI, TMS390Z50(3.x)   0Mb External cache

  CPU_#1   *** NOT installed ***
  CPU_#2   *** NOT installed ***
  CPU_#3   *** NOT installed ***

  <<< CPU_ on MBus Slot_ >>> IS RUNNING (MID =
  0008)

  
  ...

  Cpu #0 TI,TMS390Z50 
  Cpu #1 Nothing there 
  Cpu #2 Nothing there 
  Cpu #3 Nothing there 

  ...

  SPARCstation 20 (1 X 390Z50), No Keyboard
  ROM Rev. 2.25, 128 MB memory installed, Serial #1193046.
  Ethernet address 52:54:0:12:34:56, Host ID: 72123456.


  
  (It is necessary use SS-20 since it is the only sun4m model that supports 
512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) 

  When booting with OpenBIOS I can't seem to boot any version of Solaris
  though I had heard this did work.  Solaris 8 and 9 do work nicely with
  this ROM, but I am opening this to see if it is possible to fix this
  to allow the original OBP ROM to see multiple processors.

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

[Bug 1741718] Re: qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" with tribblix-sparc-0m16.iso

[m...@papersolve.com]

Verified same issue occurs on latest qemu.

~/qemu  qemu-system-sparc64 -version
QEMU emulator version 5.1.90 (v5.2.0-rc0-20-g3c8c36c908)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

 ~/qemu  qemu-system-sparc64 -nographic -M niagara -L niagara/S10image/ -drive 
if=pflash,readonly=on,file=./tribblix-sparc-0m16.iso -m 2048
cpu Probing I/O buses


Sun Fire T2000, No Keyboard
Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
[mo23723 obp4.20.0 #0]
Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.


ok boot
Boot device: vdisk  File and args: 
hsfs-file-system 
Loading: /platform/sun4v/boot_archive
ramdisk-root ufs-file-system 
Loading: /platform/sun4v/kernel/sparcv9/unix
\
panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found

Warning - stack not written to the dumpbuf
0180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 
81010100, ff00)
  %l0-3: 01876c00  010d6c00 
  %l4-7: 80008f000740 80008fc54750 f0254cc4 010dedd0
0180b800 unix:plat_lgrp_init+14 (4, 180e000, 4, 0, 180b950, 1)
  %l0-3: fff32000 fff340e0 fff34590 010d5f28
  %l4-7: 0016  0016 0011
0180b8b0 unix:lgrp_plat_init+74 (0, 0, 0, 180ba08, 180ba00, 91)
  %l0-3: 2000 fff34000 01874c00 01874c00
  %l4-7:  01874c00 0180b950 010de048
0180b960 unix:lgrp_init+4 (0, 2000, 70002000, 0, 180c0e8, 0)
  %l0-3: 0180e380 0183c678 0180ba08 010d4f90
  %l4-7: 010d4fa0 010d1c00 4000 80001070
0180ba10 unix:mlsetup+2f4 (180bb80, 180bec0, 0, 0, f025496c, 0)
  %l0-3: 018ee000 70002000 70002000 0180bad0
  %l4-7: 0190c4d8 0001001f56e0  80001070


ERROR: Last Trap: Level 14 Interrupt
[Exception handlers interrupted, please file a bug]
[type 'resume' to attempt a normal recovery]
ok 


Without if=pflash it now crashes:

✘  ~/qemu  qemu-system-sparc64 -nographic -M niagara -L niagara/S10image/ 
-drive readonly=on,file=./tribblix-sparc-0m16.iso -m 4096
cpu Probing I/O buses


Sun Fire T2000, No Keyboard
Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
[mo23723 obp4.20.0 #0]
Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.


ok boot
Boot device: vdisk  File and args: 
qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state
pc: 0040f02c  npc: 0040f030
%g0-3:    00970280
%g4-7: 1000   
%o0-3:  8ffd6000 8000  
%o4-7:  00f0 fff55701 f020d78c 
%l0-3: 0002fd10 7ffe 8000  
%l4-7: 000b 80008fffa750 f026fbf0 f022a0d8 
%i0-3: 8000 1000   
%i4-7:     
%f00:     
%f08:     
%f16:     
%f24:     
%f32:     
%f40:     
%f48:     
%f56:     
pstate: 0014 ccr: 11 (icc: ---C xcc: ---C) asi: 20 tl: 6 pil: d gl: 6
tbr: f020 hpstate: 0004 htba: 0040
cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 0
fsr:  y:  fprs: 0004

fish: “qemu-system-sparc64 -nographic…” terminated by signal SIGABRT
(Abort)


** Changed in: qemu
   Status: New => Confirmed

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

Title:
  qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No
  memory blocks found" with tribblix-sparc-0m16.iso

Status in QEMU:
  Confirmed

Bug description:
  qemu-system-sparc64 Niagara VM running Tribblix crashes with
  "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" on
  QEMU 2.11.0. Happens also with 1 GB, 4 GB, and 8 GB of RAM.

  $ qemu-system-sparc64 -nographic -M niagara -L 
/home/newman/Down

[Bug 1670175] Re: qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate"

[m...@papersolve.com]

This is still valid, setting to Confirmed.  With the latest qemu as of
today, it fails in a slightly different way, but still does not accept
any keyboard input:

\
\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
\ or http://www.opensolaris.org/os/licensing.
\ See the License for WARNING: add_spec: No major number for sf
unix-tte:interpret: exception -13 caught
interpret ' unix-tte is va>tte-data failed with error ffed
WARNING: consconfig: cannot find driver for screen device 
/pci@1fe,0/pci@1,1/QEMU,VGA@2
Hostname: tribblix
Remounting root read/write
Probing for device nodes ...
WARNING: Interrupt not seen after set_features
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
WARNING: ebus0 assigning default interrupt level 1 for device i80420
Preparing image for use
Done mounting /usr filesystem
USB keyboard
 1. Albanian  25. Latin-American
 2. Arabic26. Lithuanian
 3. Belarusian27. Latvian   
 4. Belgian   28. Macedonian
 5. Brazilian 29. Malta_UK  
 6. Bulgarian 30. Malta_US  
 7. Canadian-Bilingual31. Norwegian 
 8. Croatian  32. Polish
 9. Czech 33. Portuguese
10. Danish34. Romanian  
11. Dutch 35. Russian   
12. Dvorak36. Serbia-And-Montenegro 
13. Estonian  37. Slovak
14. Finnish   38. Slovenian 
15. French39. Spanish   
16. French-Canadian   40. Swedish   
17. Hungarian 41. Swiss-French  
18. German42. Swiss-German  
19. Greek 43. Traditional-Chinese   
20. Icelandic 44. TurkishF  
21. Italian   45. TurkishQ  
22. Japanese-type646. UK-English
23. Japanese  47. US-English
24. Korean
To select the keyboard layout, enter a number [default 47]:


** Changed in: qemu
   Status: Incomplete => Confirmed

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

Title:
  qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic -
  kernel: no nucleus hblk8 to allocate"

Status in QEMU:
  Confirmed

Bug description:
  > qemu-system-sparc64 -m 1024 -cdrom Downloads/tribblix-sparc-0m16.iso -boot 
d -nographic
  OpenBIOS for Sparc64
  Configuration device id QEMU version 1 machine id 0
  kernel cmdline 
  CPUs: 1 x SUNW,UltraSPARC-IIi
  UUID: ----
  Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23
Type 'help' for detailed information
  Trying cdrom:f...
  Not a bootable ELF image
  Not a bootable a.out image

  Loading FCode image...
  Loaded 7120 bytes
  entry point is 0x4000
  Evaluating FCode...
  Evaluating FCode...
  Ignoring failed claim for va 10a96a0 memsz 19!
  Ignoring failed claim for va 100 memsz d1fb6!
  Ignoring failed claim for va 1402000 memsz 32518!
  Ignoring failed claim for va 180 memsz 52ac8!
  SunOS Release 5.11 Version tribblix-m16 64-bit
  Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved.
  could not find debugger-vocabulary-hook>threads:interpret: exception -13 
caught
  interpret \ ident "%Z%%M% %I% %E% SMI"
  \ Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
  \ Use is subject to license terms.
  \
  \ CDDL HEADER START
  \
  \ The contents of this file are subject to the terms of the
  \ Common Development and Distribution License, Version 1.0 on

[Bug 1699824] Re: qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso

[m...@papersolve.com]

Still occurs with latest qemu built as of today.
 ✘  ~/qemu  qemu-system-sparc64 -cdrom ./tribblix-sparc-0m16.iso   -boot d -m 
1024 -nographic -machine sun4v
qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state
pc: 0200  npc: 0204
%g0-3:    
%g4-7:    
%o0-3:     
%o4-7:     
%l0-3: 3ff0 01ff 01fff008  
%l4-7:     
%i0-3:     
%i4-7:     
%f00:     
%f08:     
%f16:     
%f24:     
%f32:     
%f40:     
%f48:     
%f56:     
pstate: 0014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8
tbr:  hpstate: 0004 htba: 
cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7
fsr:  y:  fprs: 

fish: “qemu-system-sparc64 -cdrom ./tr…” terminated by signal SIGABRT
(Abort)


** Changed in: qemu
   Status: Incomplete => Confirmed

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

Title:
  qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso

Status in QEMU:
  Confirmed

Bug description:
  qemu-system-sparc64 qemu-2.9.0-3.10.x86_64 on openSUSE Leap 42.3 using
  'sun4v' machine aborts with tribblix. With 2048 MB of RAM it takes
  considerably more time to abort (but the core is always truncated).

  > qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso -boot d 
-nographic -M sun4v
  qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state
  pc: 0200  npc: 0204
  %g0-3:    
  %g4-7:    
  %o0-3:     
  %o4-7:     
  %l0-3: 3ff0 01ff 01fff008  
  %l4-7:     
  %i0-3:     
  %i4-7:     
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  %f32:     
  %f40:     
  %f48:     
  %f56:     
  pstate: 0014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8
  tbr:  hpstate: 0004 htba: 
  cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7
  fsr:  y:  fprs: 

  Aborted (core dumped)

  
 PID: 26999 (qemu-system-spa)
 UID: 1000 (newman)
 GID: 100 (users)
  Signal: 6 (ABRT)
   Timestamp: Thu 2017-06-22 16:19:02 CEST (1min 5s ago)
Command Line: qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso 
-boot d -nographic -M sun4v
  Executable: /usr/bin/qemu-system-sparc64
   Control Group: /
   Slice: -.slice
 Boot ID: aa7431274f854fb7a02a773eefa8a9bb
  Machine ID: 89c660865c00403a9bacef32b6828556
Hostname: assam.suse.cz
Coredump: 
/var/lib/systemd/coredump/core.qemu-system-spa.1000.aa7431274f854fb7a02a773eefa8a9bb.26999.149814114200.xz
 Message: Process 26999 (qemu-system-spa) of user 1000 dumped core.


  (gdb) thread apply all bt full

  Thread 4 (Thread 0x7f3896aca700 (LWP 27001)):
  #0  0x

Re: Should we apply for GitLab's open source program?

[Bradley M. Kuhn]

> On Fri, Sep 04, 2020 at 04:35:34PM +0100, Alex Bennée wrote:
>> Given our growing reliance on GitLab and the recent announcement about
>> free tier minutes:
>> 
>>   https://about.gitlab.com/pricing/faq-consumption-cicd/
>> 
>> is it time we officially apply for GitLab's Open Source Program:
>> 
>>   https://about.gitlab.com/solutions/open-source/program/

Sorry for my late response on this thread.  Since GitLab is requiring that
organizations be non-profits as part of this program, Conservancy will need
to coordinate your application with you as we're the parent non-profit for
this purpose.

Given my late reply, you may already be coordinating with my colleague Brett
about this, but I'll check in with him tomorrow to verify.

One thing to note is that my understanding is that most of what you're
getting access to through this program is proprietary software features that
GitLab offers as add-ons.  I really encourage you as a project not enable
such features, as ultimately you'll probably start to rely on them, and then
you'll be effectively relying on proprietary software infrastructure to
develop your project.

I'm also curious: is there something you need now from the GitLab software
that self-hosting might improve?
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[Bug 1213196] Re: -serial tcp should hang up when DTR goes low

[Darrin M. Gorski]

In addition to allowing low DTR to drop the socket connection, and
allowing low DTR to reject a socket connection, the DCD modem bit also
be implemented - DCD should follow the state of the TCP socket: a
connected socket should pull DCD high, and a disconnected socket should
pull DCD low. From what Ive seen in the source, it looks like a serial
IOCTL functioned needs to be added to chardev/char-socket.c to allow the
MSR bits to be tracked against the state of the socket.  DCD should be
very easy to implement this way, but I hadn't thought about DTR.

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

Title:
  -serial tcp should hang up when DTR goes low

Status in QEMU:
  New

Bug description:
  In keeping with the spirit of serial modem control signals, de-
  asserting DTR should cause the TCP connection to break; asserting DTR
  should cause QEMU to initiate a new connection or for it to accept
  another (in server mode; this may involve waiting for one to arrive,
  too).

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

[Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[John M]

I just did an install of Windows 95 in 4.2 and it installs and runs out
of the box with -accel tcg. Thanks!!

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: [Qemu-devel] [PATCH] i386: Fix nested SVM on older Opterons

[Bernhard M. Wiedemann]

On 23/05/2019 23.27, Eduardo Habkost wrote:
> On Thu, May 23, 2019 at 07:57:38PM +0100, Dr. David Alan Gilbert wrote:
>> * Bernhard M. Wiedemann (bwiedem...@suse.de) wrote:
>>> Without this patch, a VM on a Opteron G3 host will have the svm flag, but
>>> the kvm-amd module fails to load in there, complaining that it needs
>>> cpuid 0x800a
>>>
>>> I have successfully built and tested this for 3+ years in production
>>> on Opteron G3 servers.
> 
> Have you reproduced the bug on QEMU 2.8 or newer?  The problem
> you describe should be fixed by the following commit (from ~2.5
> years ago).
> 
> commit 0c3d7c0051576d220e6da0a8ac08f2d8482e2f0b
> target-i386: Enable CPUID[0x800A] if SVM is enabled

I was still on qemu-2.6.2 so it is good to know that this might work out
of the box with 2.8+

Thanks for the pointer.

[Qemu-devel] [PATCH] i386: Fix nested SVM on older Opterons

[Bernhard M. Wiedemann]

Without this patch, a VM on a Opteron G3 host will have the svm flag, but
the kvm-amd module fails to load in there, complaining that it needs
cpuid 0x800a

I have successfully built and tested this for 3+ years in production
on Opteron G3 servers.

Signed-off-by: Bernhard M. Wiedemann 
---
 target/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 722c5514d4..df1d81ded8 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2723,7 +2723,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_EXT_SSE3,
 .features[FEAT_8000_0001_EDX] =
 CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
 .model_id = "AMD Opteron 240 (Gen 1 Class Opteron)",
 },
 {
@@ -2745,7 +2745,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
 .features[FEAT_8000_0001_ECX] =
 CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
 .model_id = "AMD Opteron 22xx (Gen 2 Class Opteron)",
 },
 {
@@ -2770,7 +2770,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .features[FEAT_8000_0001_ECX] =
 CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
 CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
 .model_id = "AMD Opteron 23xx (Gen 3 Class Opteron)",
 },
 {
-- 
2.16.4

[Qemu-devel] [PATCH] i386: Fix nested SVM on older Opterons

[Bernhard M. Wiedemann]

Without this patch, a VM on a Opteron G3 host will have the svm flag, but
the kvm-amd module fails to load in there, complaining that it needs
cpuid 0x800a

I have successfully built and tested this for 3+ years in production
on Opteron G3 servers.

Signed-off-by: Bernhard M. Wiedemann 
---
 target/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 722c5514d4..df1d81ded8 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2723,7 +2723,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_EXT_SSE3,
 .features[FEAT_8000_0001_EDX] =
 CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
 .model_id = "AMD Opteron 240 (Gen 1 Class Opteron)",
 },
 {
@@ -2745,7 +2745,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
 .features[FEAT_8000_0001_ECX] =
 CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
 .model_id = "AMD Opteron 22xx (Gen 2 Class Opteron)",
 },
 {
@@ -2770,7 +2770,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .features[FEAT_8000_0001_ECX] =
 CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
 CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
 .model_id = "AMD Opteron 23xx (Gen 3 Class Opteron)",
 },
 {
-- 
2.16.4

[Qemu-devel] [Bug 1819289] [NEW] Windows 95 and Windows 98 will not install or run

[John M]

Public bug reported:

The last version of QEMU I have been able to run Windows 95 or Windows
98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
either not install or will not run 95 or 98 at all. I have tried every
combination of options like isapc or no isapc, cpu pentium  or cpu as
486. Tried different memory configurations, but they just don't work
anymore.

** 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/1819289

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

[Qemu-devel] [Bug 1816052] Re: qemu system emulator fails to start if no sound card is present on host

[Kris M]

I agree. Thanks. :)

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

Title:
  qemu system emulator fails to start if no sound card is present on
  host

Status in QEMU:
  New

Bug description:
  A plain build from git master at
  81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host,
  with no options passed to configure.

  Trying to launch QEMU on a  host with no audio card present:

  # ls /dev/snd/
  seq  timer

  It will fail to initialize alsa and abort startup:

  # qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso  -m 
4000 -vnc 0.0.0.0:1 
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  init fail
  audio: Failed to create voice `pcspk'
  qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing 
audio voice failed

  
  git bisect blames this change:

  
commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad)
Author: Gerd Hoffmann 
Date:   Thu Jan 24 12:20:55 2019 +0100

  audio: probe audio drivers by default
  
  Add the drivers listed in audio_possible_drivers to audio_drv_list,
  using the try-* variants.  That way the probable drivers are compiled by
  default if possible.
  
  Additioal tweaks:
linux: reorder to: pa alsa sdl oss.
*bsd: drop pa.
  
  Signed-off-by: Gerd Hoffmann 
  Message-id: 20190124112055.547-7-kra...@redhat.com

  
  This changed our probe order:

 Linux)
-  audio_drv_list="oss"
+  audio_drv_list="try-pa try-alsa try-sdl oss"

  After some debugging I can see that 'audio_init' successfully
  initializes the alsa driver.

  When the pcspk devices goes to AUD_open_out though, the alsa driver
  fails spewing the above text to stderr and thus causes QEMU to fail.

  This looks very much like the ALSA driver in QEMU is broken -
  audio_init() should not have succeeded unless the ALSA driver knew it
  could later succesfully honour AUD_open_out.

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

[Qemu-devel] [Bug 1816052] Re: qemu system emulator fails to start if no sound card is present on host

[Kris M]

Don't know if same but just noticed "no sound" unless I unplug and
replug headphones. If I boot with no headphones plugged in I get no
sound, but if I plug in headphones I get sound. Of course, then, if I
unplug headphones I still get sound. Something about plugging/unplugging
to the headphones jack wakes things up.

ThinkPad T530-2394-3J8, i5-3380M 2.9GHz, Dual boot (BIOS/MBR): Grub,
Ubuntu 18.10 / Win7 Pro x64 . 8GB(15GB/s), Sammy 250GB SSD. Fast!

4.19.0-13 kern and previous. current: I take all updates.

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

Title:
  qemu system emulator fails to start if no sound card is present on
  host

Status in QEMU:
  New

Bug description:
  A plain build from git master at
  81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host,
  with no options passed to configure.

  Trying to launch QEMU on a  host with no audio card present:

  # ls /dev/snd/
  seq  timer

  It will fail to initialize alsa and abort startup:

  # qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso  -m 
4000 -vnc 0.0.0.0:1 
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  init fail
  audio: Failed to create voice `pcspk'
  qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing 
audio voice failed

  
  git bisect blames this change:

  
commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad)
Author: Gerd Hoffmann 
Date:   Thu Jan 24 12:20:55 2019 +0100

  audio: probe audio drivers by default
  
  Add the drivers listed in audio_possible_drivers to audio_drv_list,
  using the try-* variants.  That way the probable drivers are compiled by
  default if possible.
  
  Additioal tweaks:
linux: reorder to: pa alsa sdl oss.
*bsd: drop pa.
  
  Signed-off-by: Gerd Hoffmann 
  Message-id: 20190124112055.547-7-kra...@redhat.com

  
  This changed our probe order:

 Linux)
-  audio_drv_list="oss"
+  audio_drv_list="try-pa try-alsa try-sdl oss"

  After some debugging I can see that 'audio_init' successfully
  initializes the alsa driver.

  When the pcspk devices goes to AUD_open_out though, the alsa driver
  fails spewing the above text to stderr and thus causes QEMU to fail.

  This looks very much like the ALSA driver in QEMU is broken -
  audio_init() should not have succeeded unless the ALSA driver knew it
  could later succesfully honour AUD_open_out.

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

[Qemu-devel] [Bug 1816052] Re: qemu system emulator fails to start if no sound card is present on host

[Kris M]

That was Ubuntu DD current on comment #1

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

Title:
  qemu system emulator fails to start if no sound card is present on
  host

Status in QEMU:
  New

Bug description:
  A plain build from git master at
  81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host,
  with no options passed to configure.

  Trying to launch QEMU on a  host with no audio card present:

  # ls /dev/snd/
  seq  timer

  It will fail to initialize alsa and abort startup:

  # qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso  -m 
4000 -vnc 0.0.0.0:1 
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  init fail
  audio: Failed to create voice `pcspk'
  qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing 
audio voice failed

  
  git bisect blames this change:

  
commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad)
Author: Gerd Hoffmann 
Date:   Thu Jan 24 12:20:55 2019 +0100

  audio: probe audio drivers by default
  
  Add the drivers listed in audio_possible_drivers to audio_drv_list,
  using the try-* variants.  That way the probable drivers are compiled by
  default if possible.
  
  Additioal tweaks:
linux: reorder to: pa alsa sdl oss.
*bsd: drop pa.
  
  Signed-off-by: Gerd Hoffmann 
  Message-id: 20190124112055.547-7-kra...@redhat.com

  
  This changed our probe order:

 Linux)
-  audio_drv_list="oss"
+  audio_drv_list="try-pa try-alsa try-sdl oss"

  After some debugging I can see that 'audio_init' successfully
  initializes the alsa driver.

  When the pcspk devices goes to AUD_open_out though, the alsa driver
  fails spewing the above text to stderr and thus causes QEMU to fail.

  This looks very much like the ALSA driver in QEMU is broken -
  audio_init() should not have succeeded unless the ALSA driver knew it
  could later succesfully honour AUD_open_out.

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

[Qemu-devel] [PATCH] Added support for ASLR and PIE for target user mode binaries

[Harrington, Sean M]

Hello,

I recently had to extend QEMU user mode to support PIE enabled binaries 
compiled for non-native architectures. It was also important to emulate ASLR 
for the target binary if ASLR was enabled on the host machine. I would like to 
introduce this as a feature into QEMU mainstream as it seems like a feature 
others could use as well.

With the patch implementation, ASLR will be enabled if 
/proc/sys/kernel/randomize_va_space is non-zero on the host machine. An 
alternative implementation could be passing an argument during runtime to 
enable or disable ASLR. PIE is automatically enabled as well if the binary has 
been compiled with this flag.

Best regards,
Sean Harrington

Signed-off-by: Sean Harrington 
---
 linux-user/Makefile.objs  |  3 +-
 linux-user/elfload.c  |  3 +-
 linux-user/main.c |  7 +++
 linux-user/randomize_va.c | 95 +++
 linux-user/randomize_va.h | 23 ++
 5 files changed, 129 insertions(+), 2 deletions(-)
 create mode 100644 linux-user/randomize_va.c
 create mode 100644 linux-user/randomize_va.h

diff --git a/linux-user/Makefile.objs b/linux-user/Makefile.objs
index 769b8d8336..384944a76d 100644
--- a/linux-user/Makefile.objs
+++ b/linux-user/Makefile.objs
@@ -1,7 +1,8 @@
 obj-y = main.o syscall.o strace.o mmap.o signal.o \
 elfload.o linuxload.o uaccess.o uname.o \
 safe-syscall.o $(TARGET_ABI_DIR)/signal.o \
-$(TARGET_ABI_DIR)/cpu_loop.o exit.o fd-trans.o
+$(TARGET_ABI_DIR)/cpu_loop.o exit.o fd-trans.o \
+randomize_va.o

 obj-$(TARGET_HAS_BFLT) += flatload.o
 obj-$(TARGET_I386) += vm86.o
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 5bccd2e243..5add383815 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -7,6 +7,7 @@
 #include "qemu.h"
 #include "disas/disas.h"
 #include "qemu/path.h"
+#include "randomize_va.h"

 #ifdef _ARCH_PPC64
 #undef ARCH_DLINFO
@@ -2258,7 +2259,7 @@ static void load_elf_image(const char *image_name, int 
image_fd,
image is pre-linked, LOADDR will be non-zero.  Since we do
not supply MAP_FIXED here we'll use that address if and
only if it remains available.  */
-load_addr = target_mmap(loaddr, hiaddr - loaddr, PROT_NONE,
+load_addr = get_pie_addr(loaddr, hiaddr - loaddr, PROT_NONE,
 MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
 -1, 0);
 if (load_addr == -1) {
diff --git a/linux-user/main.c b/linux-user/main.c
index 923cbb753a..3b789001dd 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -37,6 +37,7 @@
 #include "trace/control.h"
 #include "target_elf.h"
 #include "cpu_loop-common.h"
+#include "randomize_va.h"

 char *exec_path;

@@ -694,6 +695,12 @@ int main(int argc, char **argv, char **envp)
 target_environ = envlist_to_environ(envlist, NULL);
 envlist_free(envlist);

+/*
+ * If host has randomized_va_space enabled, emulate the same for the
+ * target.
+ */
+reserved_va = handle_randomized_va(reserved_va, MAX_RESERVED_VA);
+
 /*
  * Now that page sizes are configured in tcg_exec_init() we can do
  * proper page alignment for guest_base.
diff --git a/linux-user/randomize_va.c b/linux-user/randomize_va.c
new file mode 100644
index 00..792212a2b8
--- /dev/null
+++ b/linux-user/randomize_va.c
@@ -0,0 +1,95 @@
+/*
+ *  QEMU user ASLR + PIE emulation
+ *
+ *  Copyright (c) 2018 Sean Harrington (harring...@battelle.org)
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/bitops.h"
+
+#include "qemu.h"
+#include "qemu-common.h"
+#include "randomize_va.h"
+
+#define PIE_MMAP_ATTEMPTS   10
+#define RANDOMIZATION_RANGE 0x0010
+
+unsigned long handle_randomized_va(unsigned long va, unsigned long 
max_va_space) {
+
+int randomize_va_fd = open("/proc/sys/kernel/randomize_va_space", 
O_RDONLY);
+srand(time(NULL));
+
+if (randomize_va_fd >= 0) {
+int aslr;
+if (read(randomize_va_fd, , sizeof(aslr)) < 0) {
+return va;
+}
+
+if (aslr) {
+/* At start, mmap_next_state is equal to TASK_UNMAPPED_BASE in
+ * mmap.c. Randomly choose a new random value within range
+ * [mmap_next_start - (TASK_UNMAPPED_BASE / 2),
+ * 

[Qemu-devel] qemu 2.10 100% cpu with coreduo

[J-F M.]

Hi,
FYI
100% cpu usage  on kernel 4.15.8
coreduo 2 cores, address sizes 0 bits virtual.
no problem with qemu cpu 2.5+.

regards,
jfm

[Qemu-devel] [Bug 1539940] Re: Qemu 2.5 Solaris 8 and 9 sparc hang after terminal type menu

[m...@papersolve.com]

This is no longer a problem (for sure in latest git, probably further
back than that, as I installed Solaris 9/SPARC on SS-20 a few months
ago):

Type the number of your choice and press Return: 3
syslog service starting.
savecore: no dump device configured
Running in command line mode

Please wait while the system information is loaded... /



Welcome to the Web Start Solaris Command Line installation!

The following questions will gather information about this system.
This information will be used to configure:

Network
Kerberos Security
Name Service
Date and Time
Root Password
Power Management

   


This can be resolved.

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

Title:
  Qemu 2.5 Solaris 8 and 9 sparc hang after terminal type menu

Status in QEMU:
  New

Bug description:
  Qemu command:
  qemu-system-sparc -nographic -monitor null -serial 
mon:telnet:localhost:3000,server -bios ../../Downloads/ss20_v2.25_rom -M SS-20 
-hda ./solsparc -m 512 -cdrom ./sol-9-905hw-ga-sparc-dvd.iso -boot d -cpu "TI 
SuperSparc 60" -net nic,vlan=1,macaddr=52:54:0:12:34:56

  
  when i do disk2:d, the system loads until the terminal type menu.

  What type of terminal are you using?
  1) ANSI Standard CRT
  2) DEC VT52
  3) DEC VT100
  4) Heathkit 19
  5) Lear Siegler ADM31
  6) PC Console
  7) Sun Command Tool
  8) Sun Workstation
  9) Televideo 910
  10) Televideo 925
  11) Wyse Model 50
  12) X Terminal Emulator (xterms)
  13) CDE Terminal Emulator (dtterm)
  14) Other
  Type the number of your choice and press Return: 3
  syslog service starting.
  savecore: no dump device configured
  Running in command line mode

  And nothing happens after that. Anyone encountered this issue?

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

[Qemu-devel] [Bug 1588591] Re: Qemu 2.6 Solaris 8 Sparc telnet terminate itself

[m...@papersolve.com]

Although I have occasionally seen this message with later versions of
QEMU running Solaris 8/SPARC it has never affected any operations for me
or terminated a telnet or QEMU process, so I think if it is still there
it's not having any affect.  So I think this can be closed.

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

Title:
  Qemu 2.6 Solaris 8 Sparc telnet terminate itself

Status in QEMU:
  New

Bug description:
  With Qemu 2.6, Solaris 8 can be installed and run. However, it
  sometimes terminate itself with I/O thread spun for 1000 iterations.

  qemu-system-sparc -nographic -monitor null -serial 
mon:telnet:0.0.0.0:3000,server -hda ./Sparc8.disk -m 256 -boot c -net 
nic,macaddr=52:54:0:12:34:56 -net tap,ifname=tap0,script=no,downscript=noQEMU 
waiting for connection on: disconnected:telnet:0.0.0.0:3000,server
  main-loop: WARNING: I/O thread spun for 1000 iterations

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

[Qemu-devel] [Bug 1759338] [NEW] qemu-system-sparc w/ SS-20 ROM does not add processors

[m...@papersolve.com]

Public bug reported:

When booting a SPARCstation-20 with the original ROM, qemu does not set
the number of processors in a way that this ROM can understand it, and
the ROM always reports only 1 processor installed:


 ~/qemu  /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu 
"TI SuperSparc 60" -smp 2 -nographic

Power-ON Reset


   SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)


CPU_#0   TI, TMS390Z50(3.x)   0Mb External cache

CPU_#1   *** NOT installed ***
CPU_#2   *** NOT installed ***
CPU_#3   *** NOT installed ***

<<< CPU_ on MBus Slot_ >>> IS RUNNING (MID =
0008)


...

Cpu #0 TI,TMS390Z50 
Cpu #1 Nothing there 
Cpu #2 Nothing there 
Cpu #3 Nothing there 

...

SPARCstation 20 (1 X 390Z50), No Keyboard
ROM Rev. 2.25, 128 MB memory installed, Serial #1193046.
Ethernet address 52:54:0:12:34:56, Host ID: 72123456.


(It is necessary use SS-20 since it is the only sun4m model that
supports 512MB RAM, and I can't get Solaris to install on the SS-20
using OpenBIOS.)

When booting with OpenBIOS I can't seem to boot any version of Solaris
though I had heard this did work.  Solaris 8 and 9 do work nicely with
this ROM, but I am opening this to see if it is possible to fix this to
allow the original OBP ROM to see multiple processors.

** 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/1759338

Title:
  qemu-system-sparc w/ SS-20 ROM does not add processors

Status in QEMU:
  New

Bug description:
  When booting a SPARCstation-20 with the original ROM, qemu does not
  set the number of processors in a way that this ROM can understand it,
  and the ROM always reports only 1 processor installed:

  
   ~/qemu  /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 
-cpu "TI SuperSparc 60" -smp 2 -nographic

  Power-ON Reset


  
 SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)

  
  CPU_#0   TI, TMS390Z50(3.x)   0Mb External cache

  CPU_#1   *** NOT installed ***
  CPU_#2   *** NOT installed ***
  CPU_#3   *** NOT installed ***

  <<< CPU_ on MBus Slot_ >>> IS RUNNING (MID =
  0008)

  
  ...

  Cpu #0 TI,TMS390Z50 
  Cpu #1 Nothing there 
  Cpu #2 Nothing there 
  Cpu #3 Nothing there 

  ...

  SPARCstation 20 (1 X 390Z50), No Keyboard
  ROM Rev. 2.25, 128 MB memory installed, Serial #1193046.
  Ethernet address 52:54:0:12:34:56, Host ID: 72123456.


  
  (It is necessary use SS-20 since it is the only sun4m model that supports 
512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) 

  When booting with OpenBIOS I can't seem to boot any version of Solaris
  though I had heard this did work.  Solaris 8 and 9 do work nicely with
  this ROM, but I am opening this to see if it is possible to fix this
  to allow the original OBP ROM to see multiple processors.

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

[Qemu-devel] [Bug 1622547] Re: qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

[m...@papersolve.com]

Yep, this works great for the SS-20 ROM (tested with SS-5 ROM also).
Boots all the way to OS (have to use -nographic but that's fine).
Thanks!

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

Title:
  qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

Status in QEMU:
  New

Bug description:
  When trying to install Solaris 2.6 from original CDROM, qemu fail with
  the following error :

  qemu: fatal: Trap 0x29 while interrupts disabled, Error state
  pc: f0041280  npc: f0041284
  %g0-7:  f0281800 0800   f0243b88 0001 f0244020
  %o0-7: 40400ce2 40400ce2  404000e2 f0243b88  f023ffd8 
f0057914 
  %l0-7: 4cc2 f009645c f0096460 0002 0209 0004 0007 
f023ff90 
  %i0-7: 0042 404000e3  404000e3 e000 f028192a f0240038 
f0096448 
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 0002
  fsr:  y: 

  The command line was :

  qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda
  ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d
  -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null

  It fails with a similar output when using bios ss20_v2.25_rom.

  ▶ qemu-system-sparc --version
  QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the 
QEMU Project developers

  ▶ uname -a
  Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 
GNU/Linux

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

[Qemu-devel] [Bug 1622547] Re: qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

[m...@papersolve.com]

That was fun! And we have a result:

fbb4bbb62e5603c991b880e25dc4bb30d342b944 is the first bad commit
commit fbb4bbb62e5603c991b880e25dc4bb30d342b944
Author: Richard Henderson <r...@twiddle.net>
Date:   Tue Jul 12 15:38:13 2016 -0700

target-sparc: Implement ldstub_asi inline

Tested-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Richard Henderson <r...@twiddle.net>

:04 04 670db498d49d38bc878efccd55e39d03f074cadf
5052ce1f32ddf00646aaa9e37bb73e38b4e750f1 M  target-sparc


I verified that the last good commit not only boots the BIOS but also boots the 
OS properly (and faster than 2.7.1).

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

Title:
  qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

Status in QEMU:
  New

Bug description:
  When trying to install Solaris 2.6 from original CDROM, qemu fail with
  the following error :

  qemu: fatal: Trap 0x29 while interrupts disabled, Error state
  pc: f0041280  npc: f0041284
  %g0-7:  f0281800 0800   f0243b88 0001 f0244020
  %o0-7: 40400ce2 40400ce2  404000e2 f0243b88  f023ffd8 
f0057914 
  %l0-7: 4cc2 f009645c f0096460 0002 0209 0004 0007 
f023ff90 
  %i0-7: 0042 404000e3  404000e3 e000 f028192a f0240038 
f0096448 
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 0002
  fsr:  y: 

  The command line was :

  qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda
  ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d
  -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null

  It fails with a similar output when using bios ss20_v2.25_rom.

  ▶ qemu-system-sparc --version
  QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the 
QEMU Project developers

  ▶ uname -a
  Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 
GNU/Linux

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

[Qemu-devel] [Bug 1622547] Re: qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

[m...@papersolve.com]

Dropping SMP doesn't make a difference (I dropped it anyway since it doesn't 
make a second processor appear in the guest, and as I've learned it's currently 
emulated in one thread anyway). You don't need an image, just the 
SPARCstation-20 ROM file which can be had from a variety of sources:
910bd7306fcec38361fc4c3a2be50fa0  ss20_v2.25_rom
and with no images listed:
sudo /usr/src/qemu-2.8.0/build/sparc-softmmu/qemu-system-sparc -bios 
./ss20_v2.25_rom -M SS-20 -nographic -m 512 -cpu "TI SuperSparc 60" -net nic 
-net bridge,br=br0
still get the error. I've never done a git bisect before but I've always wanted 
to, so I will try. :)

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

Title:
  qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

Status in QEMU:
  New

Bug description:
  When trying to install Solaris 2.6 from original CDROM, qemu fail with
  the following error :

  qemu: fatal: Trap 0x29 while interrupts disabled, Error state
  pc: f0041280  npc: f0041284
  %g0-7:  f0281800 0800   f0243b88 0001 f0244020
  %o0-7: 40400ce2 40400ce2  404000e2 f0243b88  f023ffd8 
f0057914 
  %l0-7: 4cc2 f009645c f0096460 0002 0209 0004 0007 
f023ff90 
  %i0-7: 0042 404000e3  404000e3 e000 f028192a f0240038 
f0096448 
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 0002
  fsr:  y: 

  The command line was :

  qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda
  ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d
  -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null

  It fails with a similar output when using bios ss20_v2.25_rom.

  ▶ qemu-system-sparc --version
  QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the 
QEMU Project developers

  ▶ uname -a
  Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 
GNU/Linux

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

[Qemu-devel] [Bug 1622547] Re: qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

[m...@papersolve.com]

Just confirmed that it works in QEMU 2.7.1, which is strange, since
2.8.0 does not list any SPARC changes!

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

Title:
  qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

Status in QEMU:
  New

Bug description:
  When trying to install Solaris 2.6 from original CDROM, qemu fail with
  the following error :

  qemu: fatal: Trap 0x29 while interrupts disabled, Error state
  pc: f0041280  npc: f0041284
  %g0-7:  f0281800 0800   f0243b88 0001 f0244020
  %o0-7: 40400ce2 40400ce2  404000e2 f0243b88  f023ffd8 
f0057914 
  %l0-7: 4cc2 f009645c f0096460 0002 0209 0004 0007 
f023ff90 
  %i0-7: 0042 404000e3  404000e3 e000 f028192a f0240038 
f0096448 
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 0002
  fsr:  y: 

  The command line was :

  qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda
  ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d
  -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null

  It fails with a similar output when using bios ss20_v2.25_rom.

  ▶ qemu-system-sparc --version
  QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the 
QEMU Project developers

  ▶ uname -a
  Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 
GNU/Linux

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

[Qemu-devel] [Bug 1622547] Re: qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

[m...@papersolve.com]

** Changed in: qemu
   Status: Invalid => 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/1622547

Title:
  qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

Status in QEMU:
  New

Bug description:
  When trying to install Solaris 2.6 from original CDROM, qemu fail with
  the following error :

  qemu: fatal: Trap 0x29 while interrupts disabled, Error state
  pc: f0041280  npc: f0041284
  %g0-7:  f0281800 0800   f0243b88 0001 f0244020
  %o0-7: 40400ce2 40400ce2  404000e2 f0243b88  f023ffd8 
f0057914 
  %l0-7: 4cc2 f009645c f0096460 0002 0209 0004 0007 
f023ff90 
  %i0-7: 0042 404000e3  404000e3 e000 f028192a f0240038 
f0096448 
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 0002
  fsr:  y: 

  The command line was :

  qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda
  ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d
  -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null

  It fails with a similar output when using bios ss20_v2.25_rom.

  ▶ qemu-system-sparc --version
  QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the 
QEMU Project developers

  ▶ uname -a
  Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 
GNU/Linux

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

[Qemu-devel] [Bug 1622547] Re: qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

[m...@papersolve.com]

This still fails for me even when using that CPU option.  But it only
fails with my just-compiled QEMU 2.8.0, NOT my distribution-provided
QEMU 2.6.1.

mike@ossy ~/qemu> sudo /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom 
-M SS-20 -nographic -boot d -hda ./sol26_36G.disk -m 512 -cdrom /mymedia/Disk\ 
Sets/Solaris_2.6_SPARC/Solaris_2.6_Software_05_98.iso -serial 
telnet:0.0.0.0:3000,server -smp 2,cores=2 -cpu "TI SuperSparc 60" -net nic -net 
bridge,br=br0
QEMU 2.8.0 monitor - type 'help' for more information
(qemu) QEMU waiting for connection on: disconnected:telnet:0.0.0.0:3000,server
qemu: fatal: Trap 0x29 while interrupts disabled, Error state
pc: e754  npc: e758
%g0-7:  00010d88      
%o0-7: f1201e20       00011a38 
%l0-7: f1201e20 e754 e758 0029 0300 3c1c   
%i0-7: 00013848 0029 0099  0edfe200  ff40 00011a38 
%f00:     
%f08:     
%f16:     
%f24:     
psr: 404010c5 (icc: -Z-- SPE: SP-) wim: 
fsr:  y: 

fish: “sudo /usr/local/bin/qemu-system…” terminated by signal SIGABRT
(Abort)


In the other window:
mike@ossy ~/qemu> telnet localhost 3000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Power-ON Reset
Connection closed by foreign host.

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

Title:
  qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6

Status in QEMU:
  Invalid

Bug description:
  When trying to install Solaris 2.6 from original CDROM, qemu fail with
  the following error :

  qemu: fatal: Trap 0x29 while interrupts disabled, Error state
  pc: f0041280  npc: f0041284
  %g0-7:  f0281800 0800   f0243b88 0001 f0244020
  %o0-7: 40400ce2 40400ce2  404000e2 f0243b88  f023ffd8 
f0057914 
  %l0-7: 4cc2 f009645c f0096460 0002 0209 0004 0007 
f023ff90 
  %i0-7: 0042 404000e3  404000e3 e000 f028192a f0240038 
f0096448 
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 0002
  fsr:  y: 

  The command line was :

  qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda
  ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d
  -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null

  It fails with a similar output when using bios ss20_v2.25_rom.

  ▶ qemu-system-sparc --version
  QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the 
QEMU Project developers

  ▶ uname -a
  Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 
GNU/Linux

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

[Qemu-devel] [Bug 691424] Re: qemu/kvm SDL over ssh -X broken

[Bernhard M. Wiedemann]

It seems to be working now with current versions, so has probably been
fixed somewhere.

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

Title:
  qemu/kvm SDL over ssh -X broken

Status in QEMU:
  Incomplete

Bug description:
  qemu/kvm by default uses SDL to render the output of its emulated VGA 
graphics.
  This is broken over ssh -X since quite a while.
  The only workaround I know, is to use qemu -vnc :0
  and connect using vncviewer

  
  How To Reproduce:
  1. zypper in qemu
  2. ssh -X localhost qemu -cdrom ANYISOFILE

  Actual Results:
  qemu hangs in an endless loop on the BIOS display screen

  Expected Results:
  should boot up the iso as 0.10 versions did

  Reproducible: Always

  
  this is what broke it:
  $ git bisect bad
  c18a2c360e3100bbd71162cf922dcd8c429a8b71 is first bad commit
  commit c18a2c360e3100bbd71162cf922dcd8c429a8b71
  Author: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
  Date:   Wed Jun 24 11:58:25 2009 +0100

  sdl zooming

  Hi all,
  this patch implements zooming capabilities for the sdl interface.
  A new sdl_zoom_blit function is added that is able to scale and blit a
  portion of a surface into another.
  This way we can enable SDL_RESIZABLE and have a real_screen surface with
  a different size than the guest surface and let sdl_zoom_blit take care
  of the problem.

  Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
  Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>

  :100644 100644 a06c9bfc22cc6de1c6e5e9068d6bf59d89613767 
f8dc5065dd27010bfdbb6bcfb0c6e3af25024cdb M  Makefile
  :100644 100644 417217582363a87ee67e746ba798e285a64b6cdc 
35183399f65de6f50f3baa4767ab7d4d11d45bca M  console.h
  :100644 100644 178b5532b8d9dd2194a8662fbfdcd49b4bc04222 
d81399e51276e1c97fa1f7272ef16ea4c312b51b M  sdl.c
  :00 100644  
56d3604fc3d79e4cc4622be8437c78bf70075da3 A  sdl_zoom.c
  :00 100644  
33dc63408b43a37fd6b1acde3fa62b1a51315e75 A  sdl_zoom.h
  :00 100644  
64bbca849bd3af678c2259b4d8cc0e48c6a6b43c A  sdl_zoom_template.h

  
  This problem occurs on both Debian and openSUSE.

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

Re: [Qemu-devel] VM CPU/Disk unexplained increase in resize time

[Chathura M. Sarathchandra Magurawalage]

A kind reminder about the following email. 

Thanks!

> On 29 Jul 2016, at 11:30, Chathura M. Sarathchandra Magurawalage 
> <77.chath...@gmail.com> wrote:
> 
> Hi,
> 
> Does anyone know the reason for, VM resizing time to increase faster if you 
> continuously increase CPU or DISK resources by +1 (e.g. 1-2, 2-3, 3-4, 4-5). 
> Whereas, when you increase from 1 to any other (e.g. 1-2, 1-2, 1,3, 1-4, 1-5) 
> it takes less time in comparison. Can anyone give an explanation for this? I 
> have plotted two graphs.
> 
> https://www.dropbox.com/s/5e8xrrctu0rcwx3/CPU%20scaling%20%20-%20continuous%20vs%20increasing%20from%201.png?dl=0
> https://www.dropbox.com/s/txpkb8k6mpyexv8/CPU%20scaling%20-%20increase%20from%201.png?dl=0
> 
> The first graph shows the VM CPU resize time (y axis) vs number of vCPUs (x 
> axis) of continuous (blue) and resize from a VM with 1 vCPU (green) 
> scenarios.The second graph shows the VM CPU resize time (y axis) vs number of 
> vCPUs (x axis), when resized from a VM with 1 vCPU at each step (The green 
> line in first graph). The error bars show the standard error of the gathered 
> values at each step, as I did resize multiple times to get a mean value. I 
> use openstack on x86 with KVM, although I have asked the openstack community 
> I could not yet find an answer to this.
> 
> Thanks!
> 

[Qemu-devel] VM CPU/Disk unexplained increase in resize time

[Chathura M. Sarathchandra Magurawalage]

Hi,

Does anyone know the reason for, VM resizing time to increase faster if you 
continuously increase CPU or DISK resources by +1 (e.g. 1-2, 2-3, 3-4, 4-5). 
Whereas, when you increase from 1 to any other (e.g. 1-2, 1-2, 1,3, 1-4, 1-5) 
it takes less time in comparison. Can anyone give an explanation for this? I 
have plotted two graphs.

https://www.dropbox.com/s/5e8xrrctu0rcwx3/CPU%20scaling%20%20-%20continuous%20vs%20increasing%20from%201.png?dl=0
https://www.dropbox.com/s/txpkb8k6mpyexv8/CPU%20scaling%20-%20increase%20from%201.png?dl=0

The first graph shows the VM CPU resize time (y axis) vs number of vCPUs (x 
axis) of continuous (blue) and resize from a VM with 1 vCPU (green) 
scenarios.The second graph shows the VM CPU resize time (y axis) vs number of 
vCPUs (x axis), when resized from a VM with 1 vCPU at each step (The green line 
in first graph). The error bars show the standard error of the gathered values 
at each step, as I did resize multiple times to get a mean value. I use 
openstack on x86 with KVM, although I have asked the openstack community I 
could not yet find an answer to this.

Thanks!

Re: [Qemu-devel] [PATCH v4 4/4] hw/input/adb.c: implement QKeyCode support

[M A]

On Mar 14, 2016, at 7:06 PM, Programmingkid wrote:

> 
> On Mar 13, 2016, at 11:40 AM, Peter Maydell wrote:
> 
>> On 12 March 2016 at 05:40, Programmingkid  wrote:
>>> 
>>> On Mar 11, 2016, at 10:30 PM, Peter Maydell wrote:
>>> 
 
> +}
> +keycode = s->data[s->rptr];
> +if (++s->rptr == sizeof(s->data)) {
> +s->rptr = 0;
>   }
> +s->count--;
> +
> +obuf[0] = keycode;
 
 You are still trying to put a two byte keycode (ADB_KEY_POWER)
 into this one-byte array slot. I don't know what the right way to
 send a two-byte keycode is but this is obviously not it, as
 I said before.
 
> +/* NOTE: could put a second keycode if needed */
> +obuf[1] = 0xff;
> +olen = 2;
> +
>   return olen;
> }
>>> 
>>> Is this ok?
>>> 
>>>   /* The power key is the only two byte value key, so it is a special case. 
>>> */
>>>   if (keycode == (ADB_KEY_POWER & 0x00ff)) {
>>>   obuf[0] = ADB_KEY_POWER & 0x00ff;
>>>   obuf[1] = ADB_KEY_POWER & 0xff00 >> 8;
>>>   olen = 2;
>>>   } else {
>>>   obuf[0] = keycode;
>>>   /* NOTE: could put a second keycode if needed */
>>>   obuf[1] = 0xff;
>>>   olen = 2;
>>>   }
>>> 
>>> The keycode value comes from an 8 bit array so holding the
>>> full value of the power key is not possible.
>> 
>> Ah, I hadn't noticed that -- that is not a good approach.
>> You should either:
>> (a) deal with the fact that ADB_KEY values may be 16 bits
>> all the way through (including having that array be uint16_t
>> rather than uint8_t)
>> (b) have the power key be a completely special case which
>> is handled by
>> if (qcode == Q_KEY_CODE_POWER) {
>>   /* put power key into buffer */
>>   [...]
>> } else {
>>   keycode = qcode_to_adb_keycode[...];
>>   etc;
>> }
>> and not put it into the array at all.
>> 
>> Also, you need to handle the power-key key-release
>> scancode; as far as I can tell (by looking for info via
>> google about the ADB protocol) power-key-down is
>> 0x7f 0x7f, and power-key-up is 0xff 0xff. (This is
>> kind of weird and suggests we should just take option
>> (a) and special case the power key completely.)
> 
> The power-key-up (break) keycode is 0xff 0xff? Could you send me your source 
> for this information? I always thought the up (break) code was the keycode 
> AND with 0x80. Or this if code is easier to understand:
> break_keycode = keycode & 0x80.

* sorry I meant OR in the above code
break_keycode = keycode | 0x80.

Re: [Qemu-devel] [PATCH v4 2/8] pc: move igd support code to igd.c

[Kay, Allen M]

> -Original Message-
> From: Tian, Kevin
> Sent: Wednesday, March 09, 2016 9:56 PM
> To: Gerd Hoffmann <kra...@redhat.com>
> Cc: Alex Williamson <alex.william...@redhat.com>; Stefano Stabellini
> <stefano.stabell...@eu.citrix.com>; xen-de...@lists.xensource.com; igvt-
> g...@ml01.01.org; Michael S. Tsirkin <m...@redhat.com>; open list:All patches
> CC here <qemu-devel@nongnu.org>; Kay, Allen M <allen.m@intel.com>
> Subject: RE: [PATCH v4 2/8] pc: move igd support code to igd.c
> 
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: Wednesday, March 09, 2016 11:08 PM
> >
> >   Hi,
> >
> > > +/* Here we just expose minimal host bridge offset subset. */ static
> > > +const IGDHostInfo igd_host_bridge_infos[] = {
> > > +{0x08, 2},  /* revision id */
> > > +{0x2c, 2},  /* sybsystem vendor id */
> > > +{0x2e, 2},  /* sybsystem id */
> >
> > Can anyone clarify where this comes from?
> 
> Add Allen who is the original author.
> 
> >
> > Setting the subsystem id without also setting the pci id looks wrong,
> > given that each pci id has its own subsystem id namespace.
> >

Host bridge register passthrough only serves the purpose of allowing Windows 
IGD driver accessing info it needs to boot and leave the rest intact so it 
would not look too different from the chipset it is emulating. 

Allen

Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, February 09, 2016 10:01 PM
> To: Kay, Allen M <allen.m@intel.com>
> Cc: ehabk...@redhat.com; m...@redhat.com;
> stefano.stabell...@eu.citrix.com; qemu-devel@nongnu.org;
> pbonz...@redhat.com; r...@twiddle.net; Ruan, Shuai
> <shuai.r...@intel.com>
> Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to
> passthrough
> 
> I can run that system as either primary or secondary.  On both systems I'm
> using pci-stub to keep i915 from interfering on the host, on the SNB laptop I
> also use video=efifb:off since it's configured for UEFI boot, I'm not sure if
> that play any role in why it's not working.
> 

Hi Alex,

My understand if that your IVB system is a desktop running legacy mode BIOS and 
your SNB is a laptop running EFI mode BIOS, correct?  I'm curious how does your 
SNB system getting hold of VBT table, which is needed for lighting up local 
display.

There are two ways the driver can get VBT table:  1) VGA 0xc memory,  2) 
OpRegion

On your IVB system, the guest driver would try to get VBT from 0xc memory 
if IGD is configured as primary controller in the guest, assuming KVM/QEMU 
copies VGA 0xc memory from host to guest 0xc area.   If IGD is 
configured as secondary controller, the driver would get VBT from OpRegion.  
Given IGD works in both configurations on IVB, this mean guest driver can 
successfully read VBT from both 0xc area and OpRegion.

On your SNB system that is running in EFI mode on the host, 0xc memory does 
not contain VBIOS/VBT.  This means if you configure IGD as primary controller 
in the guest, the driver cannot get to VBT at 0xc memory even if KVM/QEMU 
copies 0xc memory from host to guest.  If you configure IGD as secondary 
controller in the guest, and guest driver should be able to read VBT from the 
OpRegion.  You might want to trace i915 to see how does the  guest driver get 
to VBT via OpRegion in this configuration.

Another potential problem to watch out for with laptop vs. desktop has to do 
FLR timeout.  If you are working with a laptop with LCD panel attached (the 
usual case), FLR will take much longer than 100ms to finish.  The reason is the 
devices needs to power down the LCD panel before it can finish FLR. I have seen 
it takes more than 500ms for FLR to finish.  As a work around, I have increase 
FLR time out in Linux PCI driver to 1000ms when working with LCD panels.   
Given that you have seen evidences that IGD HW is working, this might not be 
your issue.   I would focus tracing how does i915 get VBT from the OpRegion 
when IGD is configured as secondary controller in the guest.

Allen


> I've tried adding a bunch more registers on the SNB system to see if it helps,
> for the host bridge:
> 
> {0x50,2},
> {0x52,2},
> {0xa4,4},
> {0xa8,4},
> 
> (ie. the registers Tiejun added with this patch)
> 
> And on the ISA bridge:
> 
> {0x40,4},
> {0x44,4},
> {0x48,4},
> {0x4c,4},
> {0xf0,4},
> 
> These were registers I saw accessed with tracing enabled, but nothing
> seemed to change by adding them. I don't see any accesses to the BDSM
> register on the host bridge, but I do see GMCH accesses.  Sort of interesting
> is that the guest reads 201h from that register and tries to write 203h. In 
> the
> read case we have a 2MB GGMS and GGCLCK set, the guest tries to set IVD
> (IGD VGA Disable). I'm not sure why it bothers to try to do this with GGCLCK
> indicated since the register is locked, but it is slightly troubling that the 
> spec
> indicates that the BIOS must
> *not* set IVD to zero (VGA enabled) if GMS pre-allocates no memory, which
> is exactly what we're doing to try to indicate no stolen memory.
> If we could actually disable VGA on IGD, that might be a nice option, but I
> know there are issues with that (iirc, there's no disable for one of either 
> the
> VGA MMIO or I/O port space, so the only option is to disable that address
> space at the PCI command register, which has obvious implications - I think it
> was probably I/O port space).
> 
> I'm currently trying a Linux live CD on the guest for the SNB, mostly because 
> I
> can see driver error messages and look at the driver source, neither of which
> are available to me for the Windows driver.  Both of the driver warnings I get
> are from the driver thinking a certain feature should be disabled but finds it
> enabled.  They're also sort of on a strange drm release path, maybe due to
> being in secondary mode and Xorg not being configured to use the IGD on
> this image.  In case it loo

Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, February 09, 2016 9:44 AM
> Cc: ehabk...@redhat.com; m...@redhat.com;
> stefano.stabell...@eu.citrix.com; qemu-devel@nongnu.org;
> pbonz...@redhat.com; r...@twiddle.net; Kay, Allen M
> <allen.m@intel.com>
> Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to
> passthrough
> 
> 
> Tiejun's email bounced, so adding Allen for comment.
>

Tiejun has left Intel.  Shuai Ruan is his replacement (cc'ed).

>  Host bridge registers
> 52h, a4h, and a8h seem to be for versions of IGD prior to SandyBridge or just
> wrong. Even the GMCH (50h) doesn't seem to be necessary for the VM host
> bridge, so I'm thinking about dropping all of these for vfio-based IGD
> assignment.

I think dropping those register access in GMCH should be fine.  52h/a4h/a8h 
were for Ironlake IGD.  50h is now mirrored in IGD.  They can be removed as 
BDW/SKL driver no longer access them.

>  Do we know which guest drivers have specific dependencies on
> which host bridge and LPC bridge registers?  It would even be nice to
> document the standard registers for future maintainability.  Thanks,
> 

BDW/SKL drivers no longer need to access those registers in GMCH, especially in 
Universal Passthrough Mode.  From my perspective,  I'm OK with limiting KVM IGD 
passthrough to SKL+ platforms so that we don't need to add those hacks for KVM 
IGD passthrough.

For older HW, there weren't anything documented.  We added those register 
accesses in Xen/QEMU as we brought up Ironlake/SNB platforms on Xen.

Allen

> 
> On Mon, 8 Feb 2016 20:32:35 -0700
> Alex Williamson <alex.william...@redhat.com> wrote:
> 
> > On Wed, 15 Jul 2015 13:37:43 +0800
> > Tiejun Chen <tiejun.c...@intel.com> wrote:
> >
> > > Implement a pci host bridge specific to passthrough. Actually this
> > > just inherits the standard one. And we also just expose a minimal
> > > real host bridge pci configuration subset.
> > >
> > > Signed-off-by: Tiejun Chen <tiejun.c...@intel.com>
> > > Acked-by: Michael S. Tsirkin <m...@redhat.com>
> > > ---
> > > v10:
> > >
> > > * Nothing is changed.
> > >
> > > v9:
> > >
> > > * Just rebase on the latest.
> > >
> > >  hw/pci-host/piix.c   | 82
> 
> > >  include/hw/i386/pc.h |  2 ++
> > >  2 files changed, 84 insertions(+)
> > >
> > > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c index
> > > a203d93..7adf645 100644
> > > --- a/hw/pci-host/piix.c
> > > +++ b/hw/pci-host/piix.c
> > > @@ -734,6 +734,87 @@ static const TypeInfo i440fx_info = {
> > >  .class_init= i440fx_class_init,
> > >  };
> > >
> > > +/* IGD Passthrough Host Bridge. */
> > > +typedef struct {
> > > +uint8_t offset;
> > > +uint8_t len;
> > > +} IGDHostInfo;
> > > +
> > > +/* Here we just expose minimal host bridge offset subset. */ static
> > > +const IGDHostInfo igd_host_bridge_infos[] = {
> > > +{0x08, 2},  /* revision id */
> > > +{0x2c, 2},  /* sybsystem vendor id */
> > > +{0x2e, 2},  /* sybsystem id */
> > > +{0x50, 2},  /* SNB: processor graphics control register */
> > > +{0x52, 2},  /* processor graphics control register */
> > > +{0xa4, 4},  /* SNB: graphics base of stolen memory */
> > > +{0xa8, 4},  /* SNB: base of GTT stolen memory */ };
> >
> > Hi,
> >
> > I'm confused by these last 4 registers, could you please help me
> > understand them?
> >
> > Offset 0x50 is the GMCH register for SandyBridge and newer processors,
> > that makes sense, but I suspect we really want to mask out the GMS
> > field to indicate the size of stolen memory is zero?  Is Xen providing
> > the VM with direct access to host stolen memory or does it have support
> > in the VM BIOS for matching the host address?
> >

Xen does provide 1:1 stolen memory mapping in the guest.  However, I do agree 
with you we should disable stolen memory in the guest by mask out GMS field.  
This will avoid complications involving stolen memory/RMRR support.  The only 
features uses stolen memory are Frame Buffer Compression and PAVP content 
protection.  PAVP won't work in the guest anyways as it requires access to 
ME/HECI device.

> > 0x52 is unknown to me, it's listed as reserved for anything since
> > SandyBridge, does this date back to chipset-based graphics versus the
> > current processor-based grap

Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, February 09, 2016 1:33 PM
> To: Kay, Allen M <allen.m@intel.com>
> Cc: ehabk...@redhat.com; m...@redhat.com;
> stefano.stabell...@eu.citrix.com; qemu-devel@nongnu.org;
> pbonz...@redhat.com; r...@twiddle.net; Ruan, Shuai
> <shuai.r...@intel.com>
> Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to
> passthrough
> 
> Hi Allen,
> 
Hi Alex,

> Thanks for the reply.  I'm totally onboard with you for BDW/SKL for
> supported platforms, but I'd like to understand what the incremental
> investment is for each back step within reason for older GPUs, at least for
> best-effort, community support.  If we want to assume BDW/SKL and
> Universal Passthrough Mode, then we could abandon the host bridge and
> ISA bridge modifications altogether, right?

Right.

> On the other hand, it's not clear
> to me that UPT drivers are that pervasive and if we need to enable some
> degree of host bridge/ISA bridge poke thrus, why not enable a fair chunk of
> users, including me.
> 

Sounds good.

> My IVB desktop seems to be working well (win10 + linux) with only poking
> through the standard host bridge and ISA bridge identifications.  Yes, I need
> to know about the different GMCH layout of IVB vs BDW in the IGD device,
> but I've already taken care of that.

Other than VendorID/DeviceID, which other PCI config fields in host bridge and 
ISA bridge fields did you have to passthrough to get your IVB to work.  Are you 
passing IGD through as primary or secondary?

> It seems like SNB is pretty similar to IVB (they run on the same chipsets),

Agree.

> but I haven't yet fgured out the magic to make an SNB laptop light up with IGD
> assignment, which would be useful to show that OpRegion passthrough is
> actually doing something.
> 

There might be a difference in BDSM definition.  You might want to add 0xb0 in 
host bridge passthrough and try SNB again.

It is also possible the difference might be caused by difference in driver 
version.  If I google "sandybridge windows graphics driver" and "ivybridge 
windows graphics driver" I get the following:

SNB driver: 
https://downloadcenter.intel.com/product/81502/Intel-HD-Graphics-2000-for-2nd-Generation-Intel-Core-Processors
IVB driver: 
https://downloadcenter.intel.com/product/81501/Intel-HD-Graphics-2500-for-3rd-Generation-Intel-Core-Processors

SNB driver points to version 15.28 driver binary.  This driver supports SNB and 
ILK graphics.
IVB driver points to version 15.33 driver binary.  This driver supports IVB and 
SNB graphics.

One experiment you can try is to install same IVB 15.33 binary on both IVB and 
SNB systems.  To prevent Windows update messing with driver version, you should 
do the following:

1)  disable MSFT driver update: Computer->"Advance system 
settings"->Hardware->"Device Installation Settings"->"No, let me choose what to 
do"->"Never install driver software from Windows Update".
2) Disable Windows update to never check or download updates.
3) remove "c:\windows\system32\DriverStore\FileRepository\igd*"
4) re-install IGD driver to desired binary.
5) Double check driver versions of both IVB and SNB are the same after reboot 
guest.  Unfortunately, it won't said 15.33 but have a version number starts 
with 10.*.

> If we ignore IronLake and older GPUs, how many VM chipset hacks do we
> need?  What combinations would require GMCH mirrored in the host bridge,

Base on original code in Xen, you can try the following host bridge offset 
passthrough.  I have also attached pt-graphics.c from Xen/QEMU for your 
reference.

   case 0x00:/* vendor id */
case 0x02:/* device id */
case 0x08:/* revision id */
case 0x2c:/* sybsystem vendor id */
case 0x2e:/* sybsystem id */
case 0x50:/* SNB: processor graphics control register */
case 0x52:/* processor graphics control register */
case 0xa0:/* top of memory */
case 0xb0:/* ILK: BSM: should read from dev 2 offset 0x5c */
case 0x58:/* SNB: PAVPC Offset */
case 0xa4:/* SNB: graphics base of stolen memory */
case 0xa8:/* SNB: base of GTT stolen memory */

> and couldn't we mirror it from the IGD device itself since it's present in the
> same location all the way back through SNB.
> 

Yes, you can copy content from MCCG in IGD device to same 0x50 offset in host 
bridge.

> We certainly don't want to get into the nastiness of RMRRs in a VM, but do
> the stolen memory use cases you've outlined explain the DMAR faults to that
> region that I was seeing just booting a VM with a Linux live CD?

What I des

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: Tian, Kevin
> Sent: Monday, February 01, 2016 11:08 PM
> To: Kay, Allen M; Alex Williamson; Gerd Hoffmann; qemu-devel@nongnu.org
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; Cao jin; vfio-us...@redhat.com
> Subject: RE: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> > From: Kay, Allen M
> > Sent: Saturday, January 30, 2016 5:58 AM
> >
> > First of all, I would like to clarify I'm talking about general IGD
> > passthrough case - not specific to KVMGT.  In IGD passthrough
> > configuration, one of the following will happen when the driver accesses
> OpRegion:
> >
> > 1) If the hypervisor sets up OpRegion GPA/HPA mapping, either by
> > pre-map it (i.e. Xen) or map it during EPT page fault (i.e. KVM),
> > guest can successfully read the content of the OpRegion and check the ID
> string.  In this case, everything works fine.
> >
> > 2) if the hypervisor does not setup OpRegion GPA/HPA mapping at all,
> > then guest driver's attempt to setup GVA/GPA mapping will fail, which
> > causes the driver to fail.  In this case, guest driver won't have the
> > opportunity to look into the content of OpRegion memory and check the ID
> string.
> >
> 
> Guest mapping of GVA->GPA can always succeed regardless of whether
> GPA->HPA is valid. Failure will happen only when the GVA is actually
> accessed by guest.
> 

That is the data from team debugged IGD passthrough on a closed source 
hypervisor that does not map OpRegion with EPT.  The end result is the same 
-driver cannot access inside of OpRegion without failing.

> I don't understand 2). If hypervisor doesn't want to setup mapping, there is
> no chance for guest driver to get opregion content, right?

That was precisely the point I was trying to make.  As a result, guest driver 
needs some indication from the hypervisor that the address at 0xFC contains GPA 
that can be safely accessed by the driver without causing unrecoverable failure 
on hypervisors that does not map OpRegion - by leaving HPA address at 0xFC.

Allen

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, February 02, 2016 11:37 AM
> To: Kay, Allen M; Tian, Kevin; Gerd Hoffmann; qemu-devel@nongnu.org
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; Cao jin; vfio-us...@redhat.com
> Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> On Tue, 2016-02-02 at 19:10 +, Kay, Allen M wrote:
> >
> > > -Original Message-
> > > From: Tian, Kevin
> > > Sent: Monday, February 01, 2016 11:08 PM
> > > To: Kay, Allen M; Alex Williamson; Gerd Hoffmann;
> > > qemu-devel@nongnu.org
> > > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo
> > > Habkost; Stefano Stabellini; Cao jin; vfio-us...@redhat.com
> > > Subject: RE: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough
> > > chipset tweaks
> > >
> > > > From: Kay, Allen M
> > > > Sent: Saturday, January 30, 2016 5:58 AM
> > > >
> > > > First of all, I would like to clarify I'm talking about general
> > > > IGD passthrough case - not specific to KVMGT.  In IGD passthrough
> > > > configuration, one of the following will happen when the driver
> > > > accesses
> > > OpRegion:
> > > >
> > > > 1) If the hypervisor sets up OpRegion GPA/HPA mapping, either by
> > > > pre-map it (i.e. Xen) or map it during EPT page fault (i.e. KVM),
> > > > guest can successfully read the content of the OpRegion and check
> > > > the ID
> > > string.  In this case, everything works fine.
> > > >
> > > > 2) if the hypervisor does not setup OpRegion GPA/HPA mapping at
> > > > all, then guest driver's attempt to setup GVA/GPA mapping will
> > > > fail, which causes the driver to fail.  In this case, guest driver
> > > > won't have the opportunity to look into the content of OpRegion
> > > > memory and check the ID
> > > string.
> > > >
> > >
> > > Guest mapping of GVA->GPA can always succeed regardless of whether
> > > GPA->HPA is valid. Failure will happen only when the GVA is actually
> > > accessed by guest.
> > >
> 
> Hi Allen,
> 
> > That is the data from team debugged IGD passthrough on a closed source
> > hypervisor that does not map OpRegion with EPT.  The end result is the
> same -driver cannot access inside of OpRegion without failing.
> 
> Define "failing".
> 

Hi Alex,

The reported behavior is OpRegion mapping in the guest fail which caused driver 
fail to load.  However, I think what you described below is reasonable.  I will 
take a close look at it after I get my KVM environment setup.

Allen

> > > I don't understand 2). If hypervisor doesn't want to setup mapping,
> > > there is no chance for guest driver to get opregion content, right?
> >
> > That was precisely the point I was trying to make.  As a result, guest
> > driver needs some indication from the hypervisor that the address at 0xFC
> contains GPA that can be safely accessed by the driver without causing
> unrecoverable failure on hypervisors that does not map OpRegion - by
> leaving HPA address at 0xFC.
> 
> I think the thing that doesn't make sense to everyone here is that it's
> common practice for x86 systems, especially legacy OSes, to probe memory,
> get back -1 and move on.  A hypervisor should support that.  So if there's a
> bogus address in the ASL Storage register and the driver tries to read from
> the GPA indicated by that address, the VM should at worst get back -1 or a
> memory space that doesn't contain the graphics signature.  
> If there's a super strict hypervisor that doesn't handle the VM faulting 
> outside of it's address
> space, that's very prone to exploit.
> If a driver wants to avoid it anyway, perhaps they should be doing standard
> things like checking whether the ASL Storage address falls within a reserved
> memory region rather than coming up with ad-hoc register content based
> solutions.  Thanks,
> 
> Alex

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Sunday, January 31, 2016 9:42 AM
> To: Kay, Allen M; Gerd Hoffmann; David Woodhouse
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; qemu-devel@nongnu.org; Cao jin; vfio-
> us...@redhat.com
> Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> On Sat, 2016-01-30 at 01:18 +, Kay, Allen M wrote:
> >
> > > -Original Message-
> > > From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex
> > > Williamson
> > > Sent: Friday, January 29, 2016 10:00 AM
> > > To: Gerd Hoffmann
> > > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo
> > > Habkost; Stefano Stabellini; qemu-devel@nongnu.org; Cao jin; vfio-
> > > us...@redhat.com
> > > Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough
> > > chipset tweaks
> > >
> > > Do guest drivers depend on IGD appearing at 00:02.0?  I'm currently
> > > testing for any Intel VGA device, but I wonder if I should only be
> > > enabling anything opregion if it also appears at a specific address.
> > >
> >
> > No.  Both Windows and Linux IGD driver should work at any PCI slot.  We
> have seen 0:5.0 in the guest and the driver works.
> 
> Thanks Allen.  Another question, when I boot a VM with an assigned HD
> P4000 GPU, my console stream with IOMMU faults, like:
> 
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> 
> All of these fall within the host RMRR range for the device:
> 
> DMAR: Setting RMRR:
> DMAR: Setting identity map for device :00:02.0 [0x9f80 - 0xaf9f]

Hi Alex,

Do you configure IGD as primary or secondary display in your KVM setup?   If 
primary, are you running Intel vBIOS as part of guest boot?

On BDW/SKL systems, we have started to configure IGD as secondary and QEMU VGA 
and primary.  In this setup, we are no longer running vBIOS in the guest which 
avoids some complications.  vBIOS uses stolen memory for display buffers which 
requires RMRR mapping.  We have been using similar setup (IGD as secondary) on 
other hypervisors and have not seen IOMMU faults.

I will setup a KVM configuration on my SKL and see if I can duplicate your 
problem here.   I will try to call into Don's Thursday meeting to discuss this 
(I'm on call for jury duty this week).  I will give you a heads up on Wednesday 
evening.

Allen

> 
> A while back, we excluded devices using RMRRs from participating in IOMMU
> API domains because they may continue to DMA to these reserved regions
> after assignment, possibly corrupting VM memory (c875d2c1b808).  Intel
> later decided this exclusion shouldn't apply to graphics devices
> (18436afdc11a).  Don't the above IOMMU faults reveal that exactly the
> problem we're trying to prevent by general exclusion of RMRR encumbered
> devices from the IOMMU API is actually occuring?  If I were to have VM
> memory within the RMRR address range, I wouldn't be seeing these faults,
> I'd be having the GPU corrupt my VM memory.
> 
> David notes in the latter commit above:
> 
> "We should be able to successfully assign graphics devices to guests too, as
> long as the initial handling of stolen memory is reconfigured appropriately."
> 
> What code is supposed to be doing that reconfiguration when a device is
> assigned?  Clearly we don't have it yet, making assignment of these devices
> very unsafe.  It seems like vfio or IOMMU code  in the kernel needs device
> specific code to clear these settings to make it safe for userspace, then
> perhaps VM BIOS support to reallocate.  Is there any consistency across IGD
> revisions for doing this?  Is there a spec?
> Thanks,
> 
> Alex

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex
> Williamson
> Sent: Friday, January 29, 2016 10:00 AM
> To: Gerd Hoffmann
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; qemu-devel@nongnu.org; Cao jin; vfio-
> us...@redhat.com
> Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> Do guest drivers depend on IGD appearing at 00:02.0?  I'm currently testing
> for any Intel VGA device, but I wonder if I should only be enabling anything
> opregion if it also appears at a specific address.
> 

No.  Both Windows and Linux IGD driver should work at any PCI slot.  We have 
seen 0:5.0 in the guest and the driver works.

Allen

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 28, 2016 6:55 PM
> To: Kay, Allen M; Gerd Hoffmann; qemu-devel@nongnu.org
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; Cao jin; vfio-us...@redhat.com
> Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> On Fri, 2016-01-29 at 02:22 +, Kay, Allen M wrote:
> >
> > > -Original Message-
> > > From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex
> > > Williamson
> > > Sent: Thursday, January 28, 2016 11:36 AM
> > > To: Gerd Hoffmann; qemu-devel@nongnu.org
> > > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo
> > > Habkost; Stefano Stabellini; Cao jin; vfio-us...@redhat.com
> > > Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough
> > > chipset tweaks
> > >
> > >
> > > 1) The OpRegion MemoryRegion is mapped into system_memory
> through
> > > programming of the 0xFC config space register.
> > >  a) vfio-pci could pick an address to do this as it is realized.
> > >  b) SeaBIOS/OVMF could program this.
> > >
> > > Discussion: 1.a) Avoids any BIOS dependency, but vfio-pci would need
> > > to pick an address and mark it as e820 reserved.  I'm not sure how
> > > to pick that address.  We'd probably want to make the 0xFC config
> > > register read- only.  1.b) has the issue you mentioned where in most
> > > cases the OpRegion will be 8k, but the BIOS won't know how much
> > > address space it's mapping into system memory when it writes the
> > > 0xFC register.  I don't know how much of a problem this is since the
> > > BIOS can easily determine the size once mapped and re-map it
> somewhere there's sufficient space.
> > > Practically, it seems like it's always going to be 8K.  This of
> > > course requires modification to every BIOS.  It also leaves the 0xFC
> > > register as a mapping control rather than a pointer to the OpRegion
> > > in RAM, which doesn't really match real hardware.  The BIOS would need
> to pick an address in this case.
> > >
> > > 2) Read-only mappings version of 1)
> > >
> > > Discussion: Really nothing changes from the issues above, just
> > > prevents any possibility of the guest modifying anything in the
> > > host.  Xen apparently allows write access to the host page already.
> > >
> > > 3) Copy OpRegion contents into buffer and do either 1) or 2) above.
> > >
> > > Discussion: No benefit that I can see over above other than maybe
> > > allowing write access that doesn't affect the host.
> > >
> > > 4) Copy contents into a guest RAM location, mark it reserved, point
> > > to it via 0xFC config as scratch register.
> > >  a) Done by QEMU (vfio-pci)
> > >  b) Done by SeaBIOS/OVMF
> > >
> > > Discussion: This is the most like real hardware.  4.a) has the usual
> > > issue of how to pick an address, but the benefit of not requiring
> > > BIOS changes (simply mark the RAM reserved via existing methods).
> > > 4.b) would require passing a buffer containing the contents of the
> > > OpRegion via fw_cfg and letting the BIOS do the setup.  The latter
> > > of course requires modifying each BIOS for this support.
> > >
> > > Of course none of these support hotplug nor really can they since
> > > reserved memory regions are not dynamic in the architecture.
> > >
> > > In all cases, some piece of software needs to know where it can
> > > place the OpRegion in guest memory.  It seems like there are
> > > advantages or disadvantages whether that's done by QEMU or the BIOS,
> > > but we only need to do it once if it's QEMU.  Suggestions, comments,
> preferences?
> > >
> >
> > Hi Alex, another thing to consider is how to communicate to the guest
> > driver the address at 0xFC contains a valid GPA address that can be
> > accessed by the driver without causing a EPT fault - since the same driver
> will be used on other hypervisors and they may not EPT map OpRegion
> memory.  On idea proposed by display driver team is to set bit0 of the
> address to 1 for indicating OpRegion memory can be safely accessed by the
> guest driver.
> 
> Hi Allen,
> 
> Why is that any different than a guest accessing any other memory area that
> it shouldn't?  The OpRegion starts with a 16-byte ID string, so if the guest
> finds that it sh

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex
> Williamson
> Sent: Thursday, January 28, 2016 11:36 AM
> To: Gerd Hoffmann; qemu-devel@nongnu.org
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; Cao jin; vfio-us...@redhat.com
> Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> 
> 1) The OpRegion MemoryRegion is mapped into system_memory through
> programming of the 0xFC config space register.
>  a) vfio-pci could pick an address to do this as it is realized.
>  b) SeaBIOS/OVMF could program this.
> 
> Discussion: 1.a) Avoids any BIOS dependency, but vfio-pci would need to pick
> an address and mark it as e820 reserved.  I'm not sure how to pick that
> address.  We'd probably want to make the 0xFC config register read-
> only.  1.b) has the issue you mentioned where in most cases the OpRegion
> will be 8k, but the BIOS won't know how much address space it's mapping
> into system memory when it writes the 0xFC register.  I don't know how
> much of a problem this is since the BIOS can easily determine the size once
> mapped and re-map it somewhere there's sufficient space.
> Practically, it seems like it's always going to be 8K.  This of course 
> requires
> modification to every BIOS.  It also leaves the 0xFC register as a mapping
> control rather than a pointer to the OpRegion in RAM, which doesn't really
> match real hardware.  The BIOS would need to pick an address in this case.
> 
> 2) Read-only mappings version of 1)
> 
> Discussion: Really nothing changes from the issues above, just prevents any
> possibility of the guest modifying anything in the host.  Xen apparently 
> allows
> write access to the host page already.
> 
> 3) Copy OpRegion contents into buffer and do either 1) or 2) above.
> 
> Discussion: No benefit that I can see over above other than maybe allowing
> write access that doesn't affect the host.
> 
> 4) Copy contents into a guest RAM location, mark it reserved, point to it via
> 0xFC config as scratch register.
>  a) Done by QEMU (vfio-pci)
>  b) Done by SeaBIOS/OVMF
> 
> Discussion: This is the most like real hardware.  4.a) has the usual issue of
> how to pick an address, but the benefit of not requiring BIOS changes (simply
> mark the RAM reserved via existing methods).  4.b) would require passing a
> buffer containing the contents of the OpRegion via fw_cfg and letting the
> BIOS do the setup.  The latter of course requires modifying each BIOS for this
> support.
> 
> Of course none of these support hotplug nor really can they since reserved
> memory regions are not dynamic in the architecture.
> 
> In all cases, some piece of software needs to know where it can place the
> OpRegion in guest memory.  It seems like there are advantages or
> disadvantages whether that's done by QEMU or the BIOS, but we only need
> to do it once if it's QEMU.  Suggestions, comments, preferences?
> 

Hi Alex, another thing to consider is how to communicate to the guest driver 
the address at 0xFC contains a valid GPA address that can be accessed by the 
driver without causing a EPT fault - since the same driver will be used on 
other hypervisors and they may not EPT map OpRegion memory.  On idea proposed 
by display driver team is to set bit0 of the address to 1 for indicating 
OpRegion memory can be safely accessed by the guest driver.

> 
> Another thing I notice in this series is the access to PCI config space of 
> both
> the host bridge and the LPC bridge.  This prevents unprivileged use cases and
> is a barrier to libvirt support since it will need to provide access to the 
> pci-
> sysfs files for the process.  Should vfio add additional device specific 
> regions
> to expose the config space of these other devices?  I don't see that there's
> any write access necessary, so these would be read-only.  The comment in
> the kernel regarding why an unprivileged user can only access standard
> config space indicates that some devices lockup if unimplemented config
> space is accessed.  It seems like that's probably not an issue for recent-ish
> Intel host bridges and LPC devices.  If OpRegion, host bridge config, and LPC
> config were all provided through vfio, would there be any need for igd-
> passthrough switches on the machine type?  It seems like the QEMU vfio-pci
> driver could enable the necessary features and pre-fill the host and LPC
> bridge config items on demand when parsing an IGD device.  Thanks,
> 
> Alex
> 
> __

Allen
_
> iGVT-g mailing list
> igv...@lists.01.org
> https://lists.01.org/mailman/listinfo/igvt-g

Re: [Qemu-devel] The QEMU project has joined Software Freedom Conservancy

[Bradley M. Kuhn]

 On Thu, Jul 23, 2015 at 9:11 PM, Peter Maydell peter.mayd...@linaro.org 
 wrote:
 I'm happy to be able to announce that the QEMU project
 has joined Software Freedom Conservancy.

Stefan Hajnoczi wrote on Friday, 24 July:
 I added a wiki page listing the Leadership Committee members and
 explaining the relationship with Software Freedom Conservancy:
 http://qemu-project.org/Conservancy

 The wiki front page now says QEMU is a member of Software Freedom
 Conservancy and links to the new page.

That's great, thank you!

We're all really excited to have QEMU as a member project!

-- 
Bradley M. Kuhn
President  Distinguished Technologist of Software Freedom Conservancy

Re: [Qemu-devel] [PATCH] raw-posix.c: remove raw device access for cdrom

[M A]

On Jul 1, 2015, at 6:13 PM, Programmingkid wrote:

 Fix real cdrom access in Mac OS X so it can be used in QEMU.
 It simply removes the r from a device file's name. This
 allows for a real cdrom to be accessible to the guest.
 It has been successfully tested with a Windows XP guest
 in qemu-system-i386. The qemu-system-ppc emulator doesn't
 quit anymore, but there is another problem that prevents a 
 real cdrom from working.

Just wanted to note that qemu-system-ppc does work. I was able to read
a file from a real cd from the Mac OS 10.2 guest. It was OpenBIOS that has
the problem. 

[Qemu-devel] [Bug 601946] Re: [Feature request] qemu-img multi-threaded compressed image conversion

[Bernhard M. Wiedemann]

qcow2_write_compressed in block/qcow2.c would need to be changed. 
Currently it seems to need bigger changes as it always does compress+write for 
one block.
Not sure, how well it would handle multiple writes in parallel, so the safest 
would be to avoid that and just wait for the previous writer to finish before 
starting to write.

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

Title:
  [Feature request] qemu-img multi-threaded compressed image conversion

Status in QEMU:
  New

Bug description:
  Feature request:
  qemu-img multi-threaded compressed image conversion

  Suppose I want to convert raw image to compressed qcow2. Multi-
  threaded conversion will be much faster, because bottleneck is
  compressing data.

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

Re: [Qemu-devel] [v6][PATCH 08/10] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Kay, Allen M]

 -Original Message-
 From: Chen, Tiejun
 Sent: Tuesday, January 20, 2015 7:17 PM
 To: Michael S. Tsirkin; Kay, Allen M
 Cc: pbonz...@redhat.com; aligu...@amazon.com; r...@twiddle.net; Zhang,
 Yang Z; qemu-devel@nongnu.org
 Subject: Re: [v6][PATCH 08/10] xen, gfx passthrough: support Intel IGD
 passthrough with VT-D
 
  +uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr,
  +int len) {
  +XenHostPCIDevice dev;
  +uint32_t val;
  +int r;
  +
  +/* IGD read/write is through the host bridge.
  + */
  +assert(pci_dev-devfn == 0x00);
  +
  +if (!is_igd_passthrough(pci_dev)) {
  +goto read_default;
  +}
  +
  +/* Just work for the i915 driver. */
  +switch (config_addr) {
  +case 0x08:/* revision id */
  +case 0x2c:/* sybsystem vendor id */
  +case 0x2e:/* sybsystem id */
  +case 0x50:/* SNB: processor graphics control register */
  +case 0x52:/* processor graphics control register */
  +case 0xa0:/* top of memory */
 
  Is this host physical memory? If yes how can using it in guest work?
 
 This is just a threshold value, not a start or end address :)
 

top of memory is no longer used in new versions of Windows drivers.  Tiejun 
and I have tried BDW/HSW drivers and found they work without the need to 
passthrough 0xa0 register in the host bridge.  It can be removed.

 
  +case 0xa4:/* SNB: graphics base of stolen memory */
  +case 0xa8:/* SNB: base of GTT stolen memory */
 
  Same question for above two.
 
 I shouldn't matter since I remember we already discussed this previously but
 I can't sort out this from those emails now.
 
 Allen,
 
 Could you reexplain this?
 

These two stolen memory regions are part of the VT-d RMRR region.  They are 
1:1 mapped in the guest (GPA == HPA).  Tiejun found they are needed by vBIOS 
during boot.  Modern Windows driver no longer need to access these two 
registers in MCH.

 
  +break;
  +default:
  +/* Just gets the emulated values. */
  +goto read_default;
  +}
  +
  +/* Host read */
  +r = xen_host_pci_device_get(dev, 0, 0, 0, 0);
  +if (r) {
  +goto err_out;
  +}
  +
  +r = xen_host_pci_get_block(dev, config_addr, (uint8_t *)val, len);
  +if (r) {
  +goto err_out;
  +}
  +
  +xen_host_pci_device_put(dev);
  +
  +return val;
  +
  +read_default:
  +return pci_default_read_config(pci_dev, config_addr, len);
  +
  +err_out:
  +XEN_PT_ERR(pci_dev, Can't get pci_dev_host_bridge\n);
  +return -1;
  +}
 
  Do any of the above registers change with time?
 
 Think about we just provide read ops, so they're not changed based on my
 experiential.
 
  Does it work if we just read them when device is created and put in
  dev-config?
 
 I think this is a good idea so I will go there and thank you.
 
 Tiejun
 

Allen

Re: [Qemu-devel] Block filter status

[Farr, Kaitlin M.]

Hello,

Is anyone working on block filters?  If so, can you please tell me what the 
current progress is?  I am referring to item BlockFilter and dynamic 
reconfiguration of the BDS graph on the to-do list [1].

Thanks for your time,

Kaitlin Farr
Software Engineer
JHU/APL

1. 
http://qemu-project.org/Features/Block/Todo#BlockFilter_and_dynamic_reconfiguration_of_the_BDS_graph

From: Benoît Canet benoit.ca...@nodalink.com
Sent: Monday, December 15, 2014 11:51 AM
To: Farr, Kaitlin M.
Cc: QEMU Dev (qemu-devel@nongnu.org); benoit.ca...@nodalink.com; 
stefa...@redhat.com; kw...@redhat.com; arm...@redhat.com
Subject: Re: Block filter status

On Mon, Dec 15, 2014 at 04:32:19PM +, Farr, Kaitlin M. wrote:
 Hello all,



Hello,

1) I once wanted to write block filters.
2) I am not a QEMU contributor anymore.
3) If you need block filters you also need to write them.

Best regards

Benoît

 I would like to inquire about the status of block filters in QEMU. I work for 
 a team at the Johns Hopkins University Applied Physics Laboratory, and we 
 would be interested in a QEMU encryption feature, such as described in the 
 to-do list [1]. However, it seems the method described relies on block 
 filters, also on the to-do list. Does development work on block filters live 
 in a public branch somewhere? If so, I'd greatly appreciate it if someone 
 could point me to it so that I could take a look. Does anyone know of an 
 estimated date for when the block filters might be in state so that one could 
 write an encryption filter? Additionally, does anyone have an estimate for 
 time and amount of effort if might take to implement such an encryption 
 filter? If someone could assist me in planning out what steps need to be 
 taken to support encryption, I would appreciate it.

 Thanks,

 Kaitlin Farr

 Software engineer

 JHU/APL


 1. 
 http://qemu-project.org/Features/Block/Todo#New_design_for_better_encryption_support_.5Barmbru.5D

[Qemu-devel] Block filter status

[Farr, Kaitlin M.]

Hello all,


I would like to inquire about the status of block filters in QEMU. I work for a 
team at the Johns Hopkins University Applied Physics Laboratory, and we would 
be interested in a QEMU encryption feature, such as described in the to-do list 
[1]. However, it seems the method described relies on block filters, also on 
the to-do list. Does development work on block filters live in a public branch 
somewhere? If so, I'd greatly appreciate it if someone could point me to it so 
that I could take a look. Does anyone know of an estimated date for when the 
block filters might be in state so that one could write an encryption filter? 
Additionally, does anyone have an estimate for time and amount of effort if 
might take to implement such an encryption filter? If someone could assist me 
in planning out what steps need to be taken to support encryption, I would 
appreciate it.

Thanks,

Kaitlin Farr

Software engineer

JHU/APL


1. 
http://qemu-project.org/Features/Block/Todo#New_design_for_better_encryption_support_.5Barmbru.5D

[Qemu-devel] Qemu Translation Blocks Execute slightly different each time?

[M Chen]

Hi all!

I found that each time when Qemu is running via gdb, with the same start
options, the exact Translation Blocks (TBs) execute slightly different each
time.

For example the first time I start Qemu with gdb, and set the
breakpoint at tcg_qemu_tb_exec(env,
tc_ptr), and I ignore the first 1000 times hits, the next TB is about to
execute is:

breakpoint already hit 1001 times
(gdb) x/10i tc_ptr
0xb50c9900: mov0x28(%ebp),%ebx
0xb50c9903: mov0x8(%ebp),%esi
0xb50c9906: mov%ebx,%edi
0xb50c9908: mov%esi,%ecx
0xb50c990a: mov$0xf27ef,%edx

However, the second time, I did the exactly same thing, and the results
became:

breakpoint already hit 1001 times
(gdb) x/5i tc_ptr
0xb50c9bb0: mov0x1c(%ebp),%ebx
0xb50c9bb3: push   %ebx
0xb50c9bb4: mov%ebx,%edx
0xb50c9bb6: mov%ebx,%eax
0xb50c9bb8: shr$0x8,%edx

So Qemu was actually executing different TBs. I wonder the reason of this?
And is it possible to make it as static? It make it difficult for
debugging.

The qemu version I'm running is 1.0, the test image is linux-0.2.img from
http://wiki.qemu.org/Testing
And the start option is just -hda to the test image path.

Thanks!
Michael Chen

[Qemu-devel] [PATCH] translate-all.c: memory walker initial address miscalculation

[m . ilin]

From: Mikhail Ilyin m.i...@samsung.com

The initial base address is miscalculated in walk_memory_regions().
It has to be shifted TARGET_PAGE_BITS more. Holder variables are
extended to target_ulong size otherwise they don't fit for MIPS N32
(a 32-bit ABI with a 64-bit address space) and qemu won't compile.
The issue led to incorrect debug output of memory maps and a
mis-formed coredumped file.

Signed-off-by: Mikhail Ilyin m.i...@samsung.com
---
 include/exec/cpu-all.h |  4 ++--
 linux-user/elfload.c   | 18 +-
 translate-all.c| 27 +--
 3 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index f9d132f..c085804 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -232,8 +232,8 @@ extern uintptr_t qemu_host_page_mask;
 #if defined(CONFIG_USER_ONLY)
 void page_dump(FILE *f);
 
-typedef int (*walk_memory_regions_fn)(void *, abi_ulong,
-  abi_ulong, unsigned long);
+typedef int (*walk_memory_regions_fn)(void *, target_ulong,
+  target_ulong, unsigned long);
 int walk_memory_regions(void *, walk_memory_regions_fn);
 
 int page_get_flags(target_ulong address);
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index bea803b..1c04fcf 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2355,9 +2355,9 @@ struct elf_note_info {
 };
 
 struct vm_area_struct {
-abi_ulong   vma_start;  /* start vaddr of memory region */
-abi_ulong   vma_end;/* end vaddr of memory region */
-abi_ulong   vma_flags;  /* protection etc. flags for the region */
+target_ulong   vma_start;  /* start vaddr of memory region */
+target_ulong   vma_end;/* end vaddr of memory region */
+abi_ulong  vma_flags;  /* protection etc. flags for the region */
 QTAILQ_ENTRY(vm_area_struct) vma_link;
 };
 
@@ -2368,13 +2368,13 @@ struct mm_struct {
 
 static struct mm_struct *vma_init(void);
 static void vma_delete(struct mm_struct *);
-static int vma_add_mapping(struct mm_struct *, abi_ulong,
-   abi_ulong, abi_ulong);
+static int vma_add_mapping(struct mm_struct *, target_ulong,
+   target_ulong, abi_ulong);
 static int vma_get_mapping_count(const struct mm_struct *);
 static struct vm_area_struct *vma_first(const struct mm_struct *);
 static struct vm_area_struct *vma_next(struct vm_area_struct *);
 static abi_ulong vma_dump_size(const struct vm_area_struct *);
-static int vma_walker(void *priv, abi_ulong start, abi_ulong end,
+static int vma_walker(void *priv, target_ulong start, target_ulong end,
   unsigned long flags);
 
 static void fill_elf_header(struct elfhdr *, int, uint16_t, uint32_t);
@@ -2466,8 +2466,8 @@ static void vma_delete(struct mm_struct *mm)
 g_free(mm);
 }
 
-static int vma_add_mapping(struct mm_struct *mm, abi_ulong start,
-   abi_ulong end, abi_ulong flags)
+static int vma_add_mapping(struct mm_struct *mm, target_ulong start,
+   target_ulong end, abi_ulong flags)
 {
 struct vm_area_struct *vma;
 
@@ -2535,7 +2535,7 @@ static abi_ulong vma_dump_size(const struct 
vm_area_struct *vma)
 return (vma-vma_end - vma-vma_start);
 }
 
-static int vma_walker(void *priv, abi_ulong start, abi_ulong end,
+static int vma_walker(void *priv, target_ulong start, target_ulong end,
   unsigned long flags)
 {
 struct mm_struct *mm = (struct mm_struct *)priv;
diff --git a/translate-all.c b/translate-all.c
index 2e0265a..885a4ec 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -1660,12 +1660,12 @@ void cpu_interrupt(CPUState *cpu, int mask)
 struct walk_memory_regions_data {
 walk_memory_regions_fn fn;
 void *priv;
-uintptr_t start;
+target_ulong start;
 int prot;
 };
 
 static int walk_memory_regions_end(struct walk_memory_regions_data *data,
-   abi_ulong end, int new_prot)
+   target_ulong end, int new_prot)
 {
 if (data-start != -1ul) {
 int rc = data-fn(data-priv, data-start, end, data-prot);
@@ -1681,9 +1681,9 @@ static int walk_memory_regions_end(struct 
walk_memory_regions_data *data,
 }
 
 static int walk_memory_regions_1(struct walk_memory_regions_data *data,
- abi_ulong base, int level, void **lp)
+ target_ulong base, int level, void **lp)
 {
-abi_ulong pa;
+target_ulong pa;
 int i, rc;
 
 if (*lp == NULL) {
@@ -1708,7 +1708,7 @@ static int walk_memory_regions_1(struct 
walk_memory_regions_data *data,
 void **pp = *lp;
 
 for (i = 0; i  V_L2_SIZE; ++i) {
-pa = base | ((abi_ulong)i 
+pa = base | ((target_ulong)i 
 (TARGET_PAGE_BITS + V_L2_BITS * level));
 rc = walk_memory_regions_1(data, pa, level - 

Re: [Qemu-devel] [PATCH] translate-all.c: memory walker initial address miscalculation

[m . ilin]

From: Mikhail Ilyin m.i...@samsung.com

The initial base address is miscalculated in walk_memory_regions().
It has to be shifted TARGET_PAGE_BITS more. Holder variables are
extended to target_ulong size otherwise they don't fit for MIPS N32
(a 32-bit ABI with a 64-bit address space) and qemu won't compile.
The issue led to incorrect debug output of memory maps and a
mis-formed coredumped file.

Signed-off-by: Mikhail Ilyin m.i...@samsung.com
---
Add a small fix to build with a 64-bit compiler.

 include/exec/cpu-all.h |  4 ++--
 linux-user/elfload.c   | 18 +-
 translate-all.c| 33 -
 3 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index f9d132f..c085804 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -232,8 +232,8 @@ extern uintptr_t qemu_host_page_mask;
 #if defined(CONFIG_USER_ONLY)
 void page_dump(FILE *f);
 
-typedef int (*walk_memory_regions_fn)(void *, abi_ulong,
-  abi_ulong, unsigned long);
+typedef int (*walk_memory_regions_fn)(void *, target_ulong,
+  target_ulong, unsigned long);
 int walk_memory_regions(void *, walk_memory_regions_fn);
 
 int page_get_flags(target_ulong address);
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index bea803b..1c04fcf 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2355,9 +2355,9 @@ struct elf_note_info {
 };
 
 struct vm_area_struct {
-abi_ulong   vma_start;  /* start vaddr of memory region */
-abi_ulong   vma_end;/* end vaddr of memory region */
-abi_ulong   vma_flags;  /* protection etc. flags for the region */
+target_ulong   vma_start;  /* start vaddr of memory region */
+target_ulong   vma_end;/* end vaddr of memory region */
+abi_ulong  vma_flags;  /* protection etc. flags for the region */
 QTAILQ_ENTRY(vm_area_struct) vma_link;
 };
 
@@ -2368,13 +2368,13 @@ struct mm_struct {
 
 static struct mm_struct *vma_init(void);
 static void vma_delete(struct mm_struct *);
-static int vma_add_mapping(struct mm_struct *, abi_ulong,
-   abi_ulong, abi_ulong);
+static int vma_add_mapping(struct mm_struct *, target_ulong,
+   target_ulong, abi_ulong);
 static int vma_get_mapping_count(const struct mm_struct *);
 static struct vm_area_struct *vma_first(const struct mm_struct *);
 static struct vm_area_struct *vma_next(struct vm_area_struct *);
 static abi_ulong vma_dump_size(const struct vm_area_struct *);
-static int vma_walker(void *priv, abi_ulong start, abi_ulong end,
+static int vma_walker(void *priv, target_ulong start, target_ulong end,
   unsigned long flags);
 
 static void fill_elf_header(struct elfhdr *, int, uint16_t, uint32_t);
@@ -2466,8 +2466,8 @@ static void vma_delete(struct mm_struct *mm)
 g_free(mm);
 }
 
-static int vma_add_mapping(struct mm_struct *mm, abi_ulong start,
-   abi_ulong end, abi_ulong flags)
+static int vma_add_mapping(struct mm_struct *mm, target_ulong start,
+   target_ulong end, abi_ulong flags)
 {
 struct vm_area_struct *vma;
 
@@ -2535,7 +2535,7 @@ static abi_ulong vma_dump_size(const struct 
vm_area_struct *vma)
 return (vma-vma_end - vma-vma_start);
 }
 
-static int vma_walker(void *priv, abi_ulong start, abi_ulong end,
+static int vma_walker(void *priv, target_ulong start, target_ulong end,
   unsigned long flags)
 {
 struct mm_struct *mm = (struct mm_struct *)priv;
diff --git a/translate-all.c b/translate-all.c
index 2e0265a..ba5c840 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -1660,30 +1660,30 @@ void cpu_interrupt(CPUState *cpu, int mask)
 struct walk_memory_regions_data {
 walk_memory_regions_fn fn;
 void *priv;
-uintptr_t start;
+target_ulong start;
 int prot;
 };
 
 static int walk_memory_regions_end(struct walk_memory_regions_data *data,
-   abi_ulong end, int new_prot)
+   target_ulong end, int new_prot)
 {
-if (data-start != -1ul) {
+if (data-start != -1u) {
 int rc = data-fn(data-priv, data-start, end, data-prot);
 if (rc != 0) {
 return rc;
 }
 }
 
-data-start = (new_prot ? end : -1ul);
+data-start = (new_prot ? end : -1u);
 data-prot = new_prot;
 
 return 0;
 }
 
 static int walk_memory_regions_1(struct walk_memory_regions_data *data,
- abi_ulong base, int level, void **lp)
+ target_ulong base, int level, void **lp)
 {
-abi_ulong pa;
+target_ulong pa;
 int i, rc;
 
 if (*lp == NULL) {
@@ -1708,7 +1708,7 @@ static int walk_memory_regions_1(struct 
walk_memory_regions_data *data,
 void **pp = *lp;
 
 for (i = 0; i  V_L2_SIZE; ++i) {
-

Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough

[Kay, Allen M]

 -Original Message-
 From: Michael S. Tsirkin [mailto:m...@redhat.com]
 Sent: Tuesday, September 02, 2014 11:27 PM
 To: Kay, Allen M
 Cc: Chen, Tiejun; xen-de...@lists.xensource.com; qemu-
 de...@nongnu.org; Konrad Rzeszutek Wilk
 Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
 
 On Wed, Sep 03, 2014 at 01:40:45AM +, Kay, Allen M wrote:
 
 
   -Original Message-
   From: Chen, Tiejun
   Sent: Monday, September 01, 2014 12:50 AM
   To: Michael S. Tsirkin
   Cc: xen-de...@lists.xensource.com; Kay, Allen M;
   qemu-devel@nongnu.org; Konrad Rzeszutek Wilk
   Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix:
   create isa bridge specific to IGD passthrough
  
   On 2014/9/1 14:05, Michael S. Tsirkin wrote:
On Mon, Sep 01, 2014 at 10:50:37AM +0800, Chen, Tiejun wrote:
On 2014/8/31 16:58, Michael S. Tsirkin wrote:
On Fri, Aug 29, 2014 at 09:28:50AM +0800, Chen, Tiejun wrote:
   
   
On 2014/8/28 8:56, Chen, Tiejun wrote:
+ */
+dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
+
xen-igd-passthrough-isa-bridge);
+if (dev) {
+r = xen_host_pci_device_get(hdev, 0, 0,
+ PCI_DEVFN(0x1f,
0), 0);
+if (!r) {
+pci_config_set_vendor_id(dev-config,
   hdev.vendor_id);
+pci_config_set_device_id(dev-config,
+ hdev.device_id);
   
Can you, instead, implement the reverse logic, probing the
card and supplying the correct device id for PCH?
   
   
Here what is your so-called reverse logic as I already asked
you previously? Do you mean I should list all PCHs with a
combo illustrated with the vendor/device id in advance? Then
look up if we can find a
   
Michael,
   
   
Ping.
   
Thanks
Tiejun
   
Could you explain this exactly? Then I can try follow-up your
idea ASAP if this is necessary and possible.
   
Michel,
   
Could you give us some explanation for your reverse logic
when you're free?
   
Thanks
Tiejun
   
So future drivers will look at device ID for the card and figure
out how things should work from there.
Old drivers still poke at device id of the chipset for this, but
maybe qemu can do what newer drivers do:
look at the card and figure out what guest should do, then
present the appropriate chipset id.
   
This is based on what Jesse said:
  Practically speaking, we could probably assume specific
 GPU/PCH
   combos,
  as I don't think they're generally mixed across generations,
though
   SNB
  and IVB did have compatible sockets, so there is the
 possibility of
  mixing CPT and PPT PCHs, but those are register identical as
 far as the
  graphics driver is concerned, so even that should be safe.
   
   
Michael,
   
Thanks for your explanation.
   
so the idea is to have a reverse table mapping GPU back to PCH.
Present to guest the ID that will let it assume the correct GPU.
   
I guess you mean we should create to maintain such a table:
   
[GPU Card: device_id(s), PCH: device_id]
   
Then each time, instead of exposing that real PCH device id
directly, qemu first can get the real GPU device id to lookup
this table to present a appropriate PCH's device id to the guest.
   
And looks here that appropriate PCH's device id is not always a
that real PCH's device id. Right? If I'm wrong please correct me.
   
Exactly: we don't really care what the PCH ID is - we only need it
for the guest driver to do the right thing.
  
   Agreed.
  
   I need to ask Allen to check if one given GPU card device id is
   always corresponding to one given PCH on both HSW and BDW currently.
   If yes, I can do this quickly. Otherwise I need some time to
   establish that sort of connection.
  
 
  If I understand this correctly, the only difference is instead of reading 
  PCH
 DevID/RevID from the host hardware, QEMU inserts those values into PCH
 virtual device by looking at the reverse mapping table it maintains.
 
  I agree the downside of doing this is the reverse mapping table may be
 hard to maintain.
 
 Point is it won't be, since future devices will not need this hack.
 So we just need the table for the existing ones, build it once and forget
 about it.
 

Agree.

  What is the advantage of doing this instead of having QEMU reading it from
 the host?  Is it to test to make sure reverse mapping methods works before
 it is adopted in the new drivers?
 
 That's one.
 But a more important one is security: we don't want QEMU to poke at any
 new files in the host if we can help it, otherwise all distros have to change
 their LSM policies to allow this. In particular when using kvm with VFIO,
 QEMU does not poke at /sys/bus/pci/ at all anymore, and let's keep it that
 way.
 

OK.  I now see this is from KVM

Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough

[Kay, Allen M]

 -Original Message-
 From: Chen, Tiejun
 Sent: Monday, September 01, 2014 12:50 AM
 To: Michael S. Tsirkin
 Cc: xen-de...@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org;
 Konrad Rzeszutek Wilk
 Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create
 isa bridge specific to IGD passthrough
 
 On 2014/9/1 14:05, Michael S. Tsirkin wrote:
  On Mon, Sep 01, 2014 at 10:50:37AM +0800, Chen, Tiejun wrote:
  On 2014/8/31 16:58, Michael S. Tsirkin wrote:
  On Fri, Aug 29, 2014 at 09:28:50AM +0800, Chen, Tiejun wrote:
 
 
  On 2014/8/28 8:56, Chen, Tiejun wrote:
  + */
  +dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
  +xen-igd-passthrough-isa-bridge);
  +if (dev) {
  +r = xen_host_pci_device_get(hdev, 0, 0,
  + PCI_DEVFN(0x1f,
  0), 0);
  +if (!r) {
  +pci_config_set_vendor_id(dev-config,
 hdev.vendor_id);
  +pci_config_set_device_id(dev-config,
  + hdev.device_id);
 
  Can you, instead, implement the reverse logic, probing the card
  and supplying the correct device id for PCH?
 
 
  Here what is your so-called reverse logic as I already asked you
  previously? Do you mean I should list all PCHs with a combo
  illustrated with the vendor/device id in advance? Then look up
  if we can find a
 
  Michael,
 
 
  Ping.
 
  Thanks
  Tiejun
 
  Could you explain this exactly? Then I can try follow-up your
  idea ASAP if this is necessary and possible.
 
  Michel,
 
  Could you give us some explanation for your reverse logic when
  you're free?
 
  Thanks
  Tiejun
 
  So future drivers will look at device ID for the card and figure out
  how things should work from there.
  Old drivers still poke at device id of the chipset for this, but
  maybe qemu can do what newer drivers do:
  look at the card and figure out what guest should do, then present
  the appropriate chipset id.
 
  This is based on what Jesse said:
Practically speaking, we could probably assume specific GPU/PCH
 combos,
as I don't think they're generally mixed across generations, though
 SNB
and IVB did have compatible sockets, so there is the possibility of
mixing CPT and PPT PCHs, but those are register identical as far as the
graphics driver is concerned, so even that should be safe.
 
 
  Michael,
 
  Thanks for your explanation.
 
  so the idea is to have a reverse table mapping GPU back to PCH.
  Present to guest the ID that will let it assume the correct GPU.
 
  I guess you mean we should create to maintain such a table:
 
  [GPU Card: device_id(s), PCH: device_id]
 
  Then each time, instead of exposing that real PCH device id directly,
  qemu first can get the real GPU device id to lookup this table to
  present a appropriate PCH's device id to the guest.
 
  And looks here that appropriate PCH's device id is not always a that
  real PCH's device id. Right? If I'm wrong please correct me.
 
  Exactly: we don't really care what the PCH ID is - we only need it for
  the guest driver to do the right thing.
 
 Agreed.
 
 I need to ask Allen to check if one given GPU card device id is always
 corresponding to one given PCH on both HSW and BDW currently. If yes, I can
 do this quickly. Otherwise I need some time to establish that sort
 of connection.
 

If I understand this correctly, the only difference is instead of reading PCH 
DevID/RevID from the host hardware, QEMU inserts those values into PCH virtual 
device by looking at the reverse mapping table it maintains.

I agree the downside of doing this is the reverse mapping table may be hard to 
maintain.

What is the advantage of doing this instead of having QEMU reading it from the 
host?  Is it to test to make sure reverse mapping methods works before it is 
adopted in the new drivers?

 Thanks
 Tiejun
 
 
 
  the problem with these tables is they are hard to keep up to date
 
  Yeah. But I think currently we can just start from some modern CPU
  such as HSW and BDW, then things could be easy.
 
  Allen,
 
  Any idea to this suggestion?
 
  as new hardware comes out, but as future hardware won't need these
  hacks, we shall be fine.
 
  Yeah.
 
  Thanks
  Tiejun
 
 
 
 
  Thanks
  Tiejun
 
  matched PCH? If yes, what is that benefit you expect in
  passthrough case? Shouldn't we pass these info to VM directly in
 passthrough case?
 
  Thanks
  Tiejun
 
 
 
 
 
 
 
 
 
 
 
 

Allen

Re: [Qemu-devel] How to create PCH to support those existing driver

[Kay, Allen M]

 Allen,
 
 Could you reply this?

Let me summarized what we have discussed and learned so far:

1) Future Windows/Linux IGD drivers will be modified to restrain from accessing 
MCH/PCH devices.  We are prototyping this in Windows driver right now and will 
pass the same methodology to Linux driver once we have a workable solution.  
The goal is removing all MCH/PCH accesses in the IGD driver.

2) We want the same solution to work in both native and virtualization 
environments.  Given most driver developers test their changes only in native 
environment, doing anything specific for virtualization in the driver will 
cause frequent breakage for virtualization use cases.

3) Back porting this new code to support previous generations of HW will be 
problematic if not impossible.  Each Windows IGD driver release binary supports 
two generations of HW.  For example, 15.36 driver supports Broadwell/Haswell, 
15.33 driver supports Haswell/IvyBridge, 15.31 driver supports 
Ivybridge/Sandybridge, etc.   Once the driver is product validated, there is 
little opportunity to  go back and make high impact changes that might affect 
stability in native environment.

4) I agree there is little reason to do anything that requires driver changes 
at this point,  unless it is the final desired solution.

The question is whether/how to support IGD passthrough for previous generations 
of HW?

1) If we want to support SandyBridge/IvyBridge/Haswell/Broadwell, we will need 
most of the original QEMU patches.  We might be able to do without 
igd_pci_write().  I have tested QEMU changes without igd_pci_write() on both 
Haswell/Broadwell and Windows booted without any problems.  This will limit 
only read operations which should reduce a quite a bit of risk to the host 
platform.

2) If we want the upstream QEMU only work with future driver version, then most 
of the IGD passthrough patch is probably not needed - with exception of 
opregion mapping handlers.  The downside is products that depend on this 
feature will need to apply private patches separately to re-enable IGD 
passthrough capability.

Any advice on how should Tiejun proceed from here?

Allen

 -Original Message-
 From: Chen, Tiejun
 Sent: Monday, August 18, 2014 6:39 PM
 To: Michael S. Tsirkin
 Cc: Paolo Bonzini; Kay, Allen M; Wang, Yong Y; Don Dutile; Jesse Barnes;
 Konrad Rzeszutek Wilk; qemu-devel@nongnu.org; xen-
 de...@lists.xensource.com; intel-gfx
 Subject: Re: How to create PCH to support those existing driver
 
 
 
 On 2014/8/18 17:58, Michael S. Tsirkin wrote:
  On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote:
  On 2014/8/18 16:21, Michael S. Tsirkin wrote:
  On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:
  On 2014/8/17 18:32, Michael S. Tsirkin wrote:
  On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:
  Michael and Paolo,
 
  Please re-post discussion on list. These off list ones are just
  wasting time since they invariably have to be repeated on list again.
 
  Okay, now just reissue this discussion to all related guys. And do
  you think we need to discuss in public, qemu and xen mail list?
 
  Absolutely.
 
  Now -CC qemu, xen and intel-gfx.
 
  If I'm missing someone important please tell me as well.
 
 
 
  After I created that new machine specific to IGD passthrough,
  xenigd, now I will step next to register the PCH.
 
  IIRC, our complete solution should be as follows:
 
  #1 create a new machine based on piix, xenigd
 
  This is done with Michael help.
 
  #2 register ISA bridge
 
  1 Its still fixed at 1f.0.
  2 ISA bridge's vendor_id/device_id should be emulated but then
 
 subsystem_vendor_id = PCI_VENDOR_ID_XEN;
 subsystem_device_id = ISA Bridge's real device id
 
  This mean we need to change driver to walk with this way.
  For example, in
  case of Linux native driver,
 
  intel_detect_pch()
  {
 ...
 if (pch-subsystem_vendor == PCI_VENDOR_ID_XEN)
 id = pch-subsystem_device 
 INTEL_PCH_DEVICE_ID_MASK;
 
  Then driver can get that real device id by 'subsystem_device', right?
 
  This is fine now but how to support those existing drivers which
  are just
 
  Here correct one point, we don't need to care about supporting the
  legacy driver since the legacy driver still should work
  qemu-traditional. So we just make sure the existing driver with
  this subsystem_id way can support those existing and legacy platform.
 
  Now this is clear to me.
 
  dependent on checking real vendor_id/device_id directly,
 
 if (pch-vendor == PCI_VENDOR_ID_INTEL) {
 unsigned short id = pch-device 
 INTEL_PCH_DEVICE_ID_MASK
 
  Maybe I'm missing something, please hint me.
 
  Thanks
  Tiejun
 
  The subsystem id was just one idea.
 
  But from that email thread, RH / Intel Virtualization Engineering
  Meeting - Minutes 7/10, I didn't see other idea we should prefer
 currently.
 
  What was finally agreed for future drivers is that guests

Re: [Qemu-devel] How to create PCH to support those existing driver

[Kay, Allen M]

 -Original Message-
 From: Michael S. Tsirkin [mailto:m...@redhat.com]
 Sent: Tuesday, August 19, 2014 2:51 PM
 To: Kay, Allen M
 Cc: Chen, Tiejun; Paolo Bonzini; Wang, Yong Y; Don Dutile; Jesse Barnes;
 Konrad Rzeszutek Wilk; qemu-devel@nongnu.org; xen-
 de...@lists.xensource.com; intel-gfx; Stefano Stabellini
 (stefano.stabell...@citrix.com)
 Subject: Re: How to create PCH to support those existing driver
 
 On Tue, Aug 19, 2014 at 09:24:03PM +, Kay, Allen M wrote:
   Allen,
  
   Could you reply this?
 
  Let me summarized what we have discussed and learned so far:
 
  1) Future Windows/Linux IGD drivers will be modified to restrain from
 accessing MCH/PCH devices.  We are prototyping this in Windows driver right
 now and will pass the same methodology to Linux driver once we have a
 workable solution.  The goal is removing all MCH/PCH accesses in the IGD
 driver.
 
  2) We want the same solution to work in both native and virtualization
 environments.  Given most driver developers test their changes only in
 native environment, doing anything specific for virtualization in the driver 
 will
 cause frequent breakage for virtualization use cases.
 
  3) Back porting this new code to support previous generations of HW will
 be problematic if not impossible.  Each Windows IGD driver release binary
 supports two generations of HW.  For example, 15.36 driver supports
 Broadwell/Haswell, 15.33 driver supports Haswell/IvyBridge, 15.31 driver
 supports Ivybridge/Sandybridge, etc.   Once the driver is product validated,
 there is little opportunity to  go back and make high impact changes that
 might affect stability in native environment.
 
  4) I agree there is little reason to do anything that requires driver 
  changes
 at this point,  unless it is the final desired solution.
 
  The question is whether/how to support IGD passthrough for previous
 generations of HW?
 
  1) If we want to support SandyBridge/IvyBridge/Haswell/Broadwell, we will
 need most of the original QEMU patches.  We might be able to do without
 igd_pci_write().  I have tested QEMU changes without igd_pci_write() on
 both Haswell/Broadwell and Windows booted without any problems.  This
 will limit only read operations which should reduce a quite a bit of risk to 
 the
 host platform.
 
 Excellent. I was thinking about changing host's driver to do the writes in a
 safe manner, but if don't need that, all the better.
 As a next step, we need to limit read operations to specific set of registers
 that we can validate.
 We can't just pass through reads blindly to host, pci reads have side-effects
 and host chipset isn't protected by the iommu.
 Since these are legacy devices and drivers, it should be possible to
 enumerate all registers that they need.
 

If we limit platform support to HSW/BDW the number of register reads is quite 
small.  I believe some of the register reads are for the old Ironlake 
platforms.  I will work with Tiejun to get the smaller set for HSW/BDW systems.

 
  2) If we want the upstream QEMU only work with future driver version,
 then most of the IGD passthrough patch is probably not needed - with
 exception of opregion mapping handlers.  The downside is products that
 depend on this feature will need to apply private patches separately to re-
 enable IGD passthrough capability.
 
  Any advice on how should Tiejun proceed from here?
 
  Allen
 
 I'm fine with either trying to make existing windows and linux drivers work,
 or waiting for future drivers.
 
 To me, quick hacks that need minor changes in driver but don't avoid poking
 at MCH/PCH don't seem to have value, I know I proposed some of these
 myself but this was before I realised a cleaner solution is possible.
 
 
 --
 MST

Allen

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Kay, Allen M]

 For the MCH PCI registers that do need to be read - can you tell us which 
 ones those are?

In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads 
are passthrough to the host HW.   Some of the registers are needed by Ironlake 
GFX driver which we probably can remove.  I did a trace recently on Broadwell,  
the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, 
a4).  Given that we now have integrated MCH and GPU in the same socket, looks 
like driver can easily remove reads for offsets 0 - 0x2e.

case 0x00:/* vendor id */
case 0x02:/* device id */
case 0x08:/* revision id */
case 0x2c:/* sybsystem vendor id */
case 0x2e:/* sybsystem id */
case 0x50:/* SNB: processor graphics control register */
case 0x52:/* processor graphics control register */
case 0xa0:/* top of memory */
case 0xb0:/* ILK: BSM: should read from dev 2 offset 
0x5c */
case 0x58:/* SNB: PAVPC Offset */
case 0xa4:/* SNB: graphics base of stolen memory */
case 0xa8:/* SNB: base of GTT stolen memory */

Allen

-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] 
Sent: Friday, July 18, 2014 6:45 AM
To: Kay, Allen M
Cc: Michael S. Tsirkin; Jesse Barnes; peter.mayd...@linaro.org; 
xen-de...@lists.xensource.com; Ross Philipson; airl...@linux.ie; 
daniel.vet...@ffwll.ch; intel-...@lists.freedesktop.org; kelly.zyta...@amd.com; 
qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; 
anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel 
IGD passthrough support

On Thu, Jul 17, 2014 at 05:37:12PM +, Kay, Allen M wrote:
  That sounds great. Tiejun could you confirm that with windows driver guys 
  too?
 
 I believe windows driver can also assume specific CPU/PCH combos.  I will 
 discuss this with native Windows driver guys.  Preferably, the same code path 
 can be used for both native and virtualization cases to avoid frequent 
 breakage as most developers and QA do not test new code changes in 
 virtualization environment.
 
 I have verified that Windows driver do not need to write to any MCH PCI 
 registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI 
 registers that need to be read, we are working with HW team to get them 
 mirrored in GPU MMIO registers in future HW.
 

For the MCH PCI registers that do need to be read - can you tell us which ones 
those are?

Thank you!
 Allen
 
 -Original Message-
 From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
 Behalf Of Michael S. Tsirkin
 Sent: Thursday, July 03, 2014 1:28 PM
 To: Jesse Barnes
 Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross 
 Philipson; Konrad Rzeszutek Wilk; airl...@linux.ie; 
 daniel.vet...@ffwll.ch; intel-...@lists.freedesktop.org; 
 kelly.zyta...@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano 
 Stabellini; anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, 
 Tiejun
 Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: 
 add Intel IGD passthrough support
 
 On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
  On Thu, 3 Jul 2014 14:26:12 -0400
  Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
  
   On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
 On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
  Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
  With this long thread I lost a bit context about the 
  challenges that exists. But let me try summarizing it here 
  - which will hopefully get some consensus.
  
  1). Fix IGD hardware to not use Southbridge magic addresses.
  We can moan and moan but I doubt it is going to change.
  
  There are two problems:
  
  - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
  space addresses
 
 Right. So in  drivers/gpu/drm/i915/i915_dma.c:
 1135 #define MCHBAR_I915 0x44 

 1136 #define MCHBAR_I965 0x48 
 
 1147 int reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965 : 
 MCHBAR_I915;
 1152 if (INTEL_INFO(dev)-gen = 4)   

 1153 pci_read_config_dword(dev_priv-bridge_dev, reg 
 + 4, temp_hi); 
 1154 pci_read_config_dword(dev_priv-bridge_dev, reg, 
 temp_lo); 
 1155 mchbar_addr = ((u64)temp_hi  32) | temp_lo;
 
 
 and
 
 1139 #define

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Kay, Allen M]

 That sounds great. Tiejun could you confirm that with windows driver guys too?

I believe windows driver can also assume specific CPU/PCH combos.  I will 
discuss this with native Windows driver guys.  Preferably, the same code path 
can be used for both native and virtualization cases to avoid frequent breakage 
as most developers and QA do not test new code changes in virtualization 
environment.

I have verified that Windows driver do not need to write to any MCH PCI 
registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI 
registers that need to be read, we are working with HW team to get them 
mirrored in GPU MMIO registers in future HW.

Allen

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Michael S. Tsirkin
Sent: Thursday, July 03, 2014 1:28 PM
To: Jesse Barnes
Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross Philipson; 
Konrad Rzeszutek Wilk; airl...@linux.ie; daniel.vet...@ffwll.ch; 
intel-...@lists.freedesktop.org; kelly.zyta...@amd.com; qemu-devel@nongnu.org; 
Anthony Perard; Stefano Stabellini; anth...@codemonkey.ws; Paolo Bonzini; 
Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel 
IGD passthrough support

On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
 On Thu, 3 Jul 2014 14:26:12 -0400
 Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
 
  On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
   On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
 Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
 With this long thread I lost a bit context about the 
 challenges that exists. But let me try summarizing it here - 
 which will hopefully get some consensus.
 
 1). Fix IGD hardware to not use Southbridge magic addresses.
 We can moan and moan but I doubt it is going to change.
 
 There are two problems:
 
 - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
 space addresses

Right. So in  drivers/gpu/drm/i915/i915_dma.c:
1135 #define MCHBAR_I915 0x44   
 
1136 #define MCHBAR_I965 0x48 

1147 int reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965 : 
MCHBAR_I915;
1152 if (INTEL_INFO(dev)-gen = 4) 
 
1153 pci_read_config_dword(dev_priv-bridge_dev, reg + 
4, temp_hi); 
1154 pci_read_config_dword(dev_priv-bridge_dev, reg, 
temp_lo); 
1155 mchbar_addr = ((u64)temp_hi  32) | temp_lo;  
  

and

1139 #define DEVEN_REG 0x54 
 

1193 int mchbar_reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965 : 
MCHBAR_I915; 
1202 if (IS_I915G(dev) || IS_I915GM(dev)) { 
 
1203 pci_read_config_dword(dev_priv-bridge_dev, 
DEVEN_REG, temp);  
1204 enabled = !!(temp  DEVEN_MCHBAR_EN);  
 
1205 } else {   
 
1206 pci_read_config_dword(dev_priv-bridge_dev, 
mchbar_reg, temp); 
1207 enabled = temp  1;
 
1208 }
 
 - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
 some versions of the driver identify it by class, some versions 
 identify it by slot (1f.0).

Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
intel_detect_pch which sets the pch_type based on :

 432 if (pch-vendor == PCI_VENDOR_ID_INTEL) {  
 
 433 unsigned short id = pch-device  
INTEL_PCH_DEVICE_ID_MASK;
 434 dev_priv-pch_id = id; 
 
 435
 
 436 if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 

It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
The INTEL_PCH_DEVICE_ID_MASK is 0xff00
 
 To solve the first, make a new machine type, PIIX4-based, and 
 pass through the registers you need.  The patch must document 
 _exactly_ why the registers are safe to pass.  If they are not 
 reserved on PIIX4, the patch must document what the same 
 offsets mean on PIIX4, and why it's sensible to assume that 
 firmware for virtual machine will not read/write them.  Bonus point 
 for also documenting the same for Q35.

OK. 

[Qemu-devel] [Bug 1338277] Re: Ubuntu 14.04 + QEmu 2.0 + KSM = 1, makes Windows 2008 R2 guests to crash (BSOD)

[Christopher M. Penalver]

** Project changed: qemu = qemu (Ubuntu)

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

Title:
  Ubuntu 14.04 + QEmu 2.0 + KSM = 1, makes Windows 2008 R2 guests to
  crash (BSOD)

Status in “qemu” package in Ubuntu:
  New

Bug description:
  Guys,

  I'm trying to run Windows 2008 as a QEmu guest on my Ubuntu 14.04 but,
  after lots of tests, I figured out that it doesn't work, QEmu makes
  Windows 2008 to crash, and it is not a Windows fault, I'm pretty sure
  that it is a QEmu bug.

  Lab environment (5 servers):

  3 physical servers: Dell R610

  2 physycal servers: IBM x3650

  * Where Windows crash (5 servers tested) ?

  Ubuntu 14.04 + QEmu 2.0 + VirtIO 0.1-81 = Windows 2008 crash every
  hour

  - Installed with apt-get install ubuntu-virt-server.

  * Where Windows do not crash (5 servers tested) ?

  Ubuntu 14.04 + Xen 4.4 +  gplpv_Vista2008x64_1.0.1092.9 = Windows
  working smoothly

  - Installed with apt-get install xen-system-amd64.

  So, after removing QEmu from my environment, and using Xen instead,
  all Windows guests are now running without any crash.

  What kind of information, can I provide for you guys, to deep debug
  this QEmu problem ?

  Plus, it is interesting to note that a lot of times, all Windows
  guests (on top of QEmu / KVM) crashes at the exactly the same time!
  So, it can not be a problem within each Windows guest, but at the
  Hypervisor itself! Something happen there, that affects almost all
  Windows guests simultaneously.

  Also, it worth to mention that this problem is probably affecting
  clouds based on OpenStack IceHouse, on top of Ubuntu + QEmu 2.0...

  Screenshots:

  http://i.imgur.com/vnJSTgg.png

  http://i.imgur.com/34nADWr.png

  NOTE: I'm using KSM (Kernel Samepage Merging) with QEmu, to save RAM.
  It seems that when with Xen (+QEmu / HVM), KSM is not used :'( , but
  it is enabled ( 1  /sys/kernel/mm/ksm/run at Dom0's kernel). I did
  not tried to disable KSM to see if Windows becomes more stable on QEmu
  2.0...

  Also, I did not run tests on this environment with Ubuntu 12.04.4 (or
  12.04.4 with Ubuntu Cloud Archives, to get newer versions of QEmu (but
  not 2.0) for old LTS).

  CURIOSITY: On older hardware, like Dell R1950, and at my old Intel
  Desktop Core i7, I'm running Windows 2008 and 7, on Ubuntu 14.04 with
  QEmu 2.0 without any crash... I really like to figure out why QEmu is
  crashing Windows guests on Dell R610 and on IBM x3650...

  Attaching the VM's configuration files on next posts...

  Best,
  Thiago

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

[Qemu-devel] AArch64: QEMU fails in swapcontext

[Mian M. Hamayun]

Hello Peter  All,

I am trying to figure out a problem in qemu on aarch64 (with kvm 
enabled). I have found this problem in many different versions of qemu 
(v2.0.0-rc3/rc2/rc1/rc0, master 2d03b49), and I believe that either I am 
missing something common in all of these versions or its a genuine bug 
in qemu on aarch64.


The problem is triggered by virtqueue_notify() function (in 
virtio_ring.c) from the guest kernel and fails in the 
qemu_coroutine_new() while trying to do the swapcontext(old_uc, uc) 
(see coroutine-ucontext.c:164). The sigsetjmp(old_env, 0) just before 
the swapcontext() call seems to work fine, as it returns 0, and then we 
invoke the swapcontext().


The host kernel reports:
qemu-system-aar[596]: bad frame in sys_rt_sigreturn: pc=004462e0 
sp=7f8020f000 and kills the qemu process due to segmentation fault. The 
pc=004462e0 is for the coroutine_trampoline() but we don't actually 
reach it, when this particular crash happens.


Just to give you an idea of the code I am talking about:

$~/qemu[master]$ git blame -L 159,166 coroutine-ucontext.c
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 159) makecontext(uc, 
(void (*)(void))coroutine_trampoline,
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 160) 
2, arg.i[0], arg.i[1]);

00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 161)
6ab7e546 (Peter Maydell 2013-02-20 15:21:09 + 162) /* swapcontext() 
in, siglongjmp() back out */
6ab7e546 (Peter Maydell 2013-02-20 15:21:09 + 163) if 
(!sigsetjmp(old_env, 0)) {
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 164) 
swapcontext(old_uc, uc);

00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 165) }
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 166) return co-base;

My qemu configure/run commands are:

./configure --target-list=aarch64-softmmu   \
--cross-prefix=aarch64-linux-gnu-   \
--enable-fdt *--enable-kvm* --disable-werror  \
--audio-drv-list= --static

./qemu-system-aarch64 \
*-enable-kvm* -nographic -kernel Image\
-drive if=none,file=disk_oe64.img,id=fs \
-device virtio-blk-device,drive=fs  \
-m 1024 -M virt -cpu host   \
-append earlyprintk console=ttyAMA0 mem=1024M rootwait 
root=/dev/vda rw init=/bin/sh


Any ideas/comments on how to resolve this issue?

Best Regards,
Hamayun

Re: [Qemu-devel] AArch64: QEMU fails in swapcontext

[Mian M. Hamayun]

On 18/04/2014 16:44, Richard Henderson wrote:

On 04/18/2014 07:00 AM, Mian M. Hamayun wrote:

Hello Peter  All,

I am trying to figure out a problem in qemu on aarch64 (with kvm enabled). I
have found this problem in many different versions of qemu
(v2.0.0-rc3/rc2/rc1/rc0, master 2d03b49), and I believe that either I am
missing something common in all of these versions or its a genuine bug in qemu
on aarch64.

The problem is triggered by virtqueue_notify() function (in virtio_ring.c) from
the guest kernel and fails in the qemu_coroutine_new() while trying to do the
swapcontext(old_uc, uc) (see coroutine-ucontext.c:164). The
sigsetjmp(old_env, 0) just before the swapcontext() call seems to work fine, as
it returns 0, and then we invoke the swapcontext().

The host kernel reports:
qemu-system-aar[596]: bad frame in sys_rt_sigreturn: pc=004462e0
sp=7f8020f000 and kills the qemu process due to segmentation fault. The
pc=004462e0 is for the coroutine_trampoline() but we don't actually reach it,
when this particular crash happens.

Just to give you an idea of the code I am talking about:

$~/qemu[master]$ git blame -L 159,166 coroutine-ucontext.c
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 159) makecontext(uc,
(void (*)(void))coroutine_trampoline,
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 160) 2,
arg.i[0], arg.i[1]);
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 161)
6ab7e546 (Peter Maydell 2013-02-20 15:21:09 + 162) /* swapcontext() in,
siglongjmp() back out */
6ab7e546 (Peter Maydell 2013-02-20 15:21:09 + 163) if
(!sigsetjmp(old_env, 0)) {
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 164)
swapcontext(old_uc, uc);
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 165) }
00dccaf1 (Kevin Wolf2011-01-17 16:08:14 + 166) return co-base;

My qemu configure/run commands are:

./configure --target-list=aarch64-softmmu   \
 --cross-prefix=aarch64-linux-gnu-   \
 --enable-fdt *--enable-kvm* --disable-werror  \
 --audio-drv-list= --static

./qemu-system-aarch64 \
 *-enable-kvm* -nographic -kernel Image\
 -drive if=none,file=disk_oe64.img,id=fs \
 -device virtio-blk-device,drive=fs  \
 -m 1024 -M virt -cpu host   \
 -append earlyprintk console=ttyAMA0 mem=1024M rootwait root=/dev/vda rw
init=/bin/sh

Any ideas/comments on how to resolve this issue?

Note that a patch has just gone into glibc to rewrite setcontext et al for
aarch64.  I'd try using git glibc before looking too much deeper.


r~

It seems right to me as well, as the setcontext related bug (for 
aarch64) has recently been posted/fixed in glibc:

https://sourceware.org/bugzilla/show_bug.cgi?id=16629

I have also tested the example posted at: 
https://sourceware.org/bugzilla/attachment.cgi?id=7435

and I get the following output on x86_64:

start f2
start f1
finish f2
finish f1
{ss_sp: (nil), ss_flags: 2, ss_size: 0}
{ss_sp: (nil), ss_flags: 2, ss_size: 0}

and this one on AArch64:

start f2
start f1
finish f2
finish f1
{ss_sp: (nil), ss_flags: 2, ss_size: 0}
*{ss_sp: 0x7ff7e723f0, ss_flags: 0, ss_size: 8192}*

I will first look into updating my glibc for AArch64 before coming back 
to qemu.


Thanks for your support,
Hamayun

Re: [Qemu-devel] [PATCH 07/13] mxs/imx23: Implements the pin mux, GPIOs

[M P]

All noted, and thanks for all the bits you reviewed so far, I'll do the
changes and resubmit.

M



On 6 January 2014 15:52, Peter Maydell peter.mayd...@linaro.org wrote:

 On 11 December 2013 13:56, Michel Pollet buser...@gmail.com wrote:
  Implements the pinctrl and GPIO block for the imx23
  It handles GPIO output, and GPIO input from qemu translated
  into pin values and interrupts, if appropriate.
 
  Signed-off-by: Michel Pollet buser...@gmail.com
  ---
   hw/arm/Makefile.objs   |   2 +-
   hw/arm/imx23_pinctrl.c | 293
 +
   2 files changed, 294 insertions(+), 1 deletion(-)
   create mode 100644 hw/arm/imx23_pinctrl.c
 
  diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
  index 9adcb96..ea53988 100644
  --- a/hw/arm/Makefile.objs
  +++ b/hw/arm/Makefile.objs
  @@ -5,4 +5,4 @@ obj-y += tosa.o versatilepb.o vexpress.o virt.o
 xilinx_zynq.o z2.o
 
   obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
   obj-y += omap1.o omap2.o strongarm.o
  -obj-$(CONFIG_MXS) += imx23_digctl.o
  +obj-$(CONFIG_MXS) += imx23_digctl.o imx23_pinctrl.o
  diff --git a/hw/arm/imx23_pinctrl.c b/hw/arm/imx23_pinctrl.c
  new file mode 100644
  index 000..ecfb755
  --- /dev/null
  +++ b/hw/arm/imx23_pinctrl.c
  @@ -0,0 +1,293 @@
  +/*
  + * imx23_pinctrl.c
  + *
  + * Copyright: Michel Pollet buser...@gmail.com
  + *
  + * QEMU Licence
  + */
  +
  +/*
  + * Implements the pinctrl and GPIO block for the imx23
  + * It handles GPIO output, and GPIO input from qemu translated
  + * into pin values and interrupts, if appropriate.
  + */
  +#include hw/sysbus.h
  +#include hw/arm/mxs.h
  +
  +#define D(w)
  +
  +enum {
  +PINCTRL_BANK_COUNT = 3,
  +
  +PINCTRL_CTRL = 0,
  +PINCTRL_BANK_MUXSEL = 0x10,
  +PINCTRL_BANK_BASE = 0x40,
  +
  +/* these are not  4 register numbers, these are  8 register
 numbers */
  +PINCTRL_BANK_PULL = 0x4,
  +PINCTRL_BANK_OUT = 0x5,
  +PINCTRL_BANK_DIN = 0x6,
  +PINCTRL_BANK_DOE = 0x7,
  +PINCTRL_BANK_PIN2IRQ = 0x8,
  +PINCTRL_BANK_IRQEN = 0x9,
  +PINCTRL_BANK_IRQLEVEL = 0xa,
  +PINCTRL_BANK_IRQPOL = 0xb,
  +PINCTRL_BANK_IRQSTAT = 0xc,
  +
  +PINCTRL_BANK_INTERNAL_STATE = 0xd,
  +PINCTRL_MAX = 0xe0,
  +};
  +
  +#define PINCTRL_BANK_REG(_bank, _reg) ((_reg  8) | (_bank  4))
  +
  +enum {
  +MUX_GPIO = 0x3,
  +};
  +
  +
  +typedef struct imx23_pinctrl_state {
  +SysBusDevice busdev;
  +MemoryRegion iomem;
  +
  +uint32_t r[PINCTRL_MAX];
  +qemu_irq irq_in[3];
  +qemu_irq irq_out[PINCTRL_BANK_COUNT * 32];
  +
  +uint32_t state[PINCTRL_BANK_COUNT];
  +} imx23_pinctrl_state;
  +
  +static uint64_t imx23_pinctrl_read(
  +void *opaque, hwaddr offset, unsigned size)
  +{
  +imx23_pinctrl_state *s = (imx23_pinctrl_state *) opaque;
  +uint32_t res = 0;
  +
  +switch (offset  4) {
  +case 0 ... PINCTRL_MAX:
  +res = s-r[offset  4];
  +break;
  +default:
  +qemu_log_mask(LOG_GUEST_ERROR,
  +%s: bad offset 0x%x\n, __func__, (int) offset);
  +break;
  +}
  +
  +return res;
  +}
  +
  +static uint8_t imx23_pinctrl_getmux(
  +imx23_pinctrl_state *s, int pin)
  +{
  +int base = pin / 16, offset = pin % 16;
  +return (s-r[PINCTRL_BANK_MUXSEL + base]  (offset * 2))  0x3;
  +}
  +
  +/*
  + * usage imx23_pinctrl_getbit(s, PINCTRL_BANK_IRQEN, 48)...
  + */
  +static uint8_t imx23_pinctrl_getbit(
  +imx23_pinctrl_state *s, uint16_t reg, int pin)
  +{
  +int bank = pin / 32, offset = pin % 32;
  +uint32_t * latch = s-r[PINCTRL_BANK_REG(bank, reg)  4];
  +//printf(%s bank %d offset %d reg %d : %04x=%08x\n, __func__,
 bank, offset, reg,
  +//PINCTRL_BANK_REG(bank, reg),
  +//*latch);
  +return (*latch  offset)  0x1;
  +}
  +
  +static void imx23_pinctrl_setbit(
  +imx23_pinctrl_state *s, uint16_t reg, int pin, int value)
  +{
  +int bank = pin / 32, offset = pin % 32;
  +uint32_t * latch = s-r[PINCTRL_BANK_REG(bank, reg)  4];
  +*latch = (*latch  ~(1  offset)) | (!!value  offset);

 deposit32() will make this clearer to read.

  +}
  +
  +static void imx23_pinctrl_write_bank(
  +imx23_pinctrl_state *s, int bank,
  +int reg, uint32_t value,
  +uint32_t mask)
  +{
  +int set, pin;
  +switch (reg) {
  +/*
  + * Linux has a way of using the DOEPULL register to toggle the
 pin
  + */

 Why is this comment here? We should ideally not care what
 guest OS we run, we should just implement the h/w correctly.

  +case PINCTRL_BANK_PULL:
  +case PINCTRL_BANK_DOE:
  +/*
  + * Writing to the Data OUT register just triggers the
  + * output qemu IRQ for any further peripherals
  + */
  +case PINCTRL_BANK_OUT: {
  +while ((set = ffs(mask))  0

Re: [Qemu-devel] [PATCH 06/13] mxs/imx23: Add digctl driver

[M P]

On 6 January 2014 15:46, Peter Maydell peter.mayd...@linaro.org wrote:

 On 11 December 2013 13:56, Michel Pollet buser...@gmail.com wrote:

 This implements just enough of the digctl IO block to allow
  linux to believe it's running on (currently only) an imx23.
 
  Signed-off-by: Michel Pollet buser...@gmail.com
  ---
   hw/arm/Makefile.objs  |   1 +
   hw/arm/imx23_digctl.c | 110
 ++
   2 files changed, 111 insertions(+)
   create mode 100644 hw/arm/imx23_digctl.c
 
  diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
  index 78b5614..9adcb96 100644
  --- a/hw/arm/Makefile.objs
  +++ b/hw/arm/Makefile.objs
  @@ -5,3 +5,4 @@ obj-y += tosa.o versatilepb.o vexpress.o virt.o
 xilinx_zynq.o z2.o
 
   obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
   obj-y += omap1.o omap2.o strongarm.o
  +obj-$(CONFIG_MXS) += imx23_digctl.o
  diff --git a/hw/arm/imx23_digctl.c b/hw/arm/imx23_digctl.c
  new file mode 100644
  index 000..b7cd1ff
  --- /dev/null
  +++ b/hw/arm/imx23_digctl.c
  @@ -0,0 +1,110 @@
  +/*
  + * imx23_digctl.c
  + *
  + * Copyright: Michel Pollet buser...@gmail.com
  + *
  + * QEMU Licence
  + */
  +
  +/*
  + * This module implements a very basic IO block for the digctl of the
 imx23
  + * Basically there is no real logic, just constant registers return,
 the most
  + * used one bing the chip id that is used by the various linux drivers
  + * to differentiate between imx23 and 28.
  + *
  + * The module consists mostly of read/write registers that the
 bootloader and
  + * kernel are quite happy to 'set' to whatever value they believe they
 set...
  + */
  +
  +#include hw/sysbus.h
  +#include hw/arm/mxs.h
  +
  +enum {
  +HW_DIGCTL_RAMCTL = 0x3,
  +HW_DIGCTL_CHIPID = 0x31,
  +};
  +
  +typedef struct imx23_digctl_state {
  +SysBusDevice busdev;
  +MemoryRegion iomem;
  +
  +uint32_t   reg[0x2000 / 4];
  +} imx23_digctl_state;

 I'm not generally a fan of big reg[] array like this.
 In real hardware are these typically constant read/only
 registers, or do they actually do something? Does the
 hardware really have a full set of 2048 registers here,
 or are there gaps?


This block contains most of the 'general purpose' registers, ram timing and
all that jazz; there are a lot of write to it at init time, but it's
otherwise mostly ignored. Also, there's very little to do about it
functionally for qemu's purpose.



 I'd rather have us implement just the minimal set
 required for things to boot, with LOG_UNIMP (and
 read-zero/write-ignored) for the rest. That makes
 it easier to add actual implementations later
 (and your migration state is not 0x2000 bytes of random
 undifferentiated stuff).


I will re-add the trace for both write and read and see if I can narrow the
range down; it will be linux specific, tho, that's why I thought a
'catchall' block was more appropriate.


 thanks
 -- PMM


Thanks,
M

[Qemu-devel] [PATCH v4 2/7] Decouple vhost from kernel interface

[Mian M. Hamayun]

From: Antonios Motakis a.mota...@virtualopensystems.com

We introduce the concept of vhost-backend, which can be either vhost-kernel
or vhost-user. The existing vhost interface to the kernel is abstracted
behind the vhost-kernel backend.

We replace all direct ioctls to the kernel with a vhost_call to the backend.
vhost dev-control is referenced only in the vhost-backend (ioctl, open, close).

Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com
---
 hw/net/vhost_net.c| 13 +---
 hw/scsi/vhost-scsi.c  | 13 +---
 hw/virtio/Makefile.objs   |  2 +-
 hw/virtio/vhost-backend.c | 64 +++
 hw/virtio/vhost.c | 47 ++--
 include/hw/virtio/vhost-backend.h | 37 ++
 include/hw/virtio/vhost.h |  4 ++-
 7 files changed, 147 insertions(+), 33 deletions(-)
 create mode 100644 hw/virtio/vhost-backend.c
 create mode 100644 include/hw/virtio/vhost-backend.h

diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 006576d..4aaf0b4 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -27,7 +27,6 @@
 #include sys/socket.h
 #include linux/kvm.h
 #include fcntl.h
-#include sys/ioctl.h
 #include linux/virtio_ring.h
 #include netpacket/packet.h
 #include net/ethernet.h
@@ -113,7 +112,8 @@ struct vhost_net *vhost_net_init(NetClientState *backend, 
int devfd,
 net-dev.nvqs = 2;
 net-dev.vqs = net-vqs;
 
-r = vhost_dev_init(net-dev, devfd, /dev/vhost-net, force);
+r = vhost_dev_init(net-dev, devfd, /dev/vhost-net,
+   VHOST_BACKEND_TYPE_KERNEL, force);
 if (r  0) {
 goto fail;
 }
@@ -170,7 +170,8 @@ static int vhost_net_start_one(struct vhost_net *net,
 qemu_set_fd_handler(net-backend, NULL, NULL, NULL);
 file.fd = net-backend;
 for (file.index = 0; file.index  net-dev.nvqs; ++file.index) {
-r = ioctl(net-dev.control, VHOST_NET_SET_BACKEND, file);
+const VhostOps *vhost_ops = net-dev.vhost_ops;
+r = vhost_ops-vhost_call(net-dev, VHOST_NET_SET_BACKEND, file);
 if (r  0) {
 r = -errno;
 goto fail;
@@ -180,7 +181,8 @@ static int vhost_net_start_one(struct vhost_net *net,
 fail:
 file.fd = -1;
 while (file.index--  0) {
-int r = ioctl(net-dev.control, VHOST_NET_SET_BACKEND, file);
+const VhostOps *vhost_ops = net-dev.vhost_ops;
+int r = vhost_ops-vhost_call(net-dev, VHOST_NET_SET_BACKEND, file);
 assert(r = 0);
 }
 net-nc-info-poll(net-nc, true);
@@ -201,7 +203,8 @@ static void vhost_net_stop_one(struct vhost_net *net,
 }
 
 for (file.index = 0; file.index  net-dev.nvqs; ++file.index) {
-int r = ioctl(net-dev.control, VHOST_NET_SET_BACKEND, file);
+const VhostOps *vhost_ops = net-dev.vhost_ops;
+int r = vhost_ops-vhost_call(net-dev, VHOST_NET_SET_BACKEND, file);
 assert(r = 0);
 }
 net-nc-info-poll(net-nc, true);
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 3983a5b..3faff65 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -27,12 +27,13 @@
 static int vhost_scsi_set_endpoint(VHostSCSI *s)
 {
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
+const VhostOps *vhost_ops = s-dev.vhost_ops;
 struct vhost_scsi_target backend;
 int ret;
 
 memset(backend, 0, sizeof(backend));
 pstrcpy(backend.vhost_wwpn, sizeof(backend.vhost_wwpn), vs-conf.wwpn);
-ret = ioctl(s-dev.control, VHOST_SCSI_SET_ENDPOINT, backend);
+ret = vhost_ops-vhost_call(s-dev, VHOST_SCSI_SET_ENDPOINT, backend);
 if (ret  0) {
 return -errno;
 }
@@ -43,10 +44,11 @@ static void vhost_scsi_clear_endpoint(VHostSCSI *s)
 {
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
 struct vhost_scsi_target backend;
+const VhostOps *vhost_ops = s-dev.vhost_ops;
 
 memset(backend, 0, sizeof(backend));
 pstrcpy(backend.vhost_wwpn, sizeof(backend.vhost_wwpn), vs-conf.wwpn);
-ioctl(s-dev.control, VHOST_SCSI_CLEAR_ENDPOINT, backend);
+vhost_ops-vhost_call(s-dev, VHOST_SCSI_CLEAR_ENDPOINT, backend);
 }
 
 static int vhost_scsi_start(VHostSCSI *s)
@@ -55,13 +57,15 @@ static int vhost_scsi_start(VHostSCSI *s)
 VirtIODevice *vdev = VIRTIO_DEVICE(s);
 BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
 VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+const VhostOps *vhost_ops = s-dev.vhost_ops;
 
 if (!k-set_guest_notifiers) {
 error_report(binding does not support guest notifiers);
 return -ENOSYS;
 }
 
-ret = ioctl(s-dev.control, VHOST_SCSI_GET_ABI_VERSION, abi_version);
+ret = vhost_ops-vhost_call(s-dev,
+VHOST_SCSI_GET_ABI_VERSION, abi_version);
 if (ret  0) {
 return -errno;
 }
@@ -227,7 +231,8 @@ static void vhost_scsi_realize(DeviceState *dev,